From nobody Wed Jul 1 05:08:17 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72301A1BEA; Wed, 1 Jul 2015 05:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfhWiT37q7hQ; Wed, 1 Jul 2015 05:08:10 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id F02B01A1BDB; Wed, 1 Jul 2015 05:08:06 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id AB07A1216C2; Wed, 1 Jul 2015 08:30:14 -0400 (EDT) Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.99]) by mail-blue.research.att.com (Postfix) with ESMTP id 802CCF0478; Wed, 1 Jul 2015 08:08:02 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by njmtcas1.research.att.com ([fe80::f1f7:6c06:d0d0:d48c%10]) with mapi; Wed, 1 Jul 2015 08:08:02 -0400 From: "MORTON, ALFRED C (AL)" To: "Xialiang (Frank)" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-bmwg-issu-meth.all@ietf.org" Date: Wed, 1 Jul 2015 08:08:01 -0400 Thread-Topic: Secdir review of draft-ietf-bmwg-issu-meth-01 Thread-Index: AdCznVhNjRYm7y6ZS9SgpDHakbeZ2QAWCOBA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0662C6E4BD@NJFPSRVEXG0.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D0662C6E4BDNJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-bmwg-issu-meth-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 12:08:13 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D0662C6E4BDNJFPSRVEXG0re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank, Thanks for your review and comments. On #1, DoS attacks: since human control is involved here, it seems unlikely that operators will begin an upgrade during a DoS attack when they know it's in-progress, IMO. Others should chime-in if they have other rationale or opinions. On #4, That's the draft date, not the expiration date. see below, Al doc shepherd Benchmarking Working Group Sarah Banks Internet Draft VSS Monitoring Intended status: Informational Fernando Calabria Expires: November 30, 2015 Cisco Systems Gery Czirjak Ramdas Machat Juniper Networks May 30, 2015 ISSU Benchmarking Methodology draft-ietf-bmwg-issu-meth-01 From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] Sent: Tuesday, June 30, 2015 9:29 PM To: secdir@ietf.org; iesg@ietf.org; draft-ietf-bmwg-issu-meth.all@ietf.org Subject: Secdir review of draft-ietf-bmwg-issu-meth-01 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comment. This draft specifies a set of common methodologies and procedures designed = to characterize the overall behavior of a Device Under Test (DUT), subject = to an ISSU event. I have the following comments: 1. Should the ISSU test methodology include the verification and test= when the DUT is under network DDoS attacks? 2. In the software download stage, in addition to compatibility check= s and verification of checksums, we should also explicitly mention that the= device should verify the authenticity and integrity of its download. I.e. = verify signatures on signed code and OCSP/CRL for the used signature. And t= hat a system must not load unverified code; 3. even in a test environment all deployed software components must b= e verified (e.g. using signatures); 4. Nits: this draft has expired on May-30, 2015 Recommendation: Ready With Issues B.R. Frank --_000_4AF73AA205019A4C8A1DDD32C034631D0662C6E4BDNJFPSRVEXG0re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Frank,

Thanks = for your review and comments.

&n= bsp;

On #1, DoS attacks: since human contr= ol is involved here,

it seems unlike= ly that operators will begin an upgrade

during a DoS attack when they know it’s in-progress, IMO.

Others should chime-in if they have other rat= ionale or opinions.

 

On #4, That’s the draft date, not the e= xpiration date.

see below,=

Al

doc sh= epherd

 

Internet D= raft            = ;            &n= bsp;            = ;      VSS Monitoring

Intended status: Informational      = ;            &n= bsp;     Fernando Calabria

Expires: November 30, 2015      &nb= sp;            =              Ci= sco Systems

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;    Gery Czirjak

=             &nb= sp;            =             &nb= sp;            =         Ramdas Machat<= /p>

         &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        Juniper Networks

        &n= bsp;            = ;             &= nbsp;           &nbs= p;            M= ay 30, 2015

    &= nbsp;           &nbs= p;     

ISS= U Benchmarking Methodology

draft-ietf= -bmwg-issu-meth-01

 <= /span>

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] Sent: Tuesday, June 30, 2015 9:29 PM
To: secdir@ietf.org;= iesg@ietf.org; draft-ietf-bmwg-issu-meth.all@ietf.org
Subject: S= ecdir review of draft-ietf-bmwg-issu-meth-01

 <= /o:p>

I = have reviewed this document as part of the security directorate's ongo= ing effort to review all IETF documents being processed by the IESG. &= nbsp;These comments were written primarily for the benefit of the secu= rity area directors.  Document editors and WG chairs should treat = ;these comments just like any other last call comment.

 = ;

This draft specifies a set of common methodologies and procedures de= signed to characterize the overall behavior of a Device Under Test (DUT), s= ubject to an ISSU event.

 

I have the following co= mments:

<= span style=3D'mso-fareast-language:ZH-CN'>1= .     = ;  Should the ISSU test methodology include the verification and test w= hen the DUT is under network DDoS attacks?

2.In the software download stage, in ad= dition to compatibility checks and verification of checksums, we should als= o explicitly mention that the device should verify the authenticity and int= egrity of its download. I.e. verify signatures on signed code and OCSP/CRL = for the used signature. And that a system must not load unverified code;

3.       even = in a test environment all deployed software components must be verified (e.= g. using signatures);

4.   &= nbsp;   Nits: this draft has expired on May-30, 2015

 

Recommendation:  Ready With Issues

=

 =

B.R.

Frank

= --_000_4AF73AA205019A4C8A1DDD32C034631D0662C6E4BDNJFPSRVEXG0re_-- From nobody Wed Jul 1 06:19:01 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA481A87BE; Wed, 1 Jul 2015 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2oMSeY0PadW; Wed, 1 Jul 2015 05:59:54 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8318F1A87B2; Wed, 1 Jul 2015 05:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24411; q=dns/txt; s=iport; t=1435755595; x=1436965195; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=AxFjaCdO/xKHMlwN9K5y8EJp7rUgGaGo+RxxzwaJJ3U=; b=B13AAA521GRVExC3/5DGzrgSq+xkttu5HgSNeR459hbYkMzv8FtsrgX5 S8Mg9Q/lN4IGX3mq4EqoUGeVZD0vsdWNfGd8H1LjBvd4bc6ZueBoI8xSd QU6lRXLxsB86sEihgK/OjWVsqXKY8NKUOKOFX4CRzZhOmf4W2wKjOIzoI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AYBAD045NV/5RdJa1bgkVMVF8GvSgJhDKDNAKBUTgUAQEBAQEBAYEKhCIBAQEELUcVAgEIEQMBAQEhBwcyFAkIAQEEARKIL8thAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKhGITFwGEKwEElBABi2CBOochjAyDXSaDem+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.15,385,1432598400"; d="scan'208,217";a="164631800" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2015 12:59:54 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t61CxrPX030194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 12:59:53 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.60]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 07:59:53 -0500 From: "Fernando Calabria (fcalabri)" To: "MORTON, ALFRED C (AL)" , "Xialiang (Frank)" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-bmwg-issu-meth.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-bmwg-issu-meth-01 Thread-Index: AdCznVhNjRYm7y6ZS9SgpDHakbeZ2QAWCOBAAAQtUQA= Date: Wed, 1 Jul 2015 12:59:52 +0000 Message-ID: References: <4AF73AA205019A4C8A1DDD32C034631D0662C6E4BD@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D0662C6E4BD@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [10.117.99.244] Content-Type: multipart/alternative; boundary="_000_D1B950B649F87fcalabriciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 01 Jul 2015 06:19:00 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-bmwg-issu-meth-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 12:59:57 -0000 --_000_D1B950B649F87fcalabriciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Frank for your review and Al for addressing # 1 and # 4 .. In regards to # 2 and #3 We also saw and considered how verifications like the authenticity of a SW= package may be a concern , even more, nowadays, with emerging SDN like= implementations , Unfortunately not all the vendors nor even software specific operating sy= stems within vendors, have =93consistent implementations" of Digital Si= gnatures nor Certificates and do not make these checks a mandatory task b= efore performing a Software upgrade. Because of it we tried to address it with a =91generic=92 statement on Sec= tions 3.1 and 3.2 that basically read: "Internal compatibility verification may be performed by the software running on the DUT, to verify the checksum of the files downloaded as well as any other pertinent checks. Depending upon vendor implementation, these mechanisms may extend to include verification that the downloaded module(s) =85" =97 Internal compatibility verification may be performed by the software running on the DUT, as part of the upgrade process itself, to verify the checksum of the files downloaded as well as any other pertinent checks=85. The authors of this document understand how these are real issues / concer= ns on managing an operating a Software environment, , but we do not bel= ieve that an specific ISSU document should addresses them in detail -Fernando From: , "ALFRED C (AL)" > Date: Wednesday, July 1, 2015 at 8:08 AM To: "Xialiang (Frank)" >, "secdir@ietf.org" >, "iesg@ietf.org" >, "draft-ietf-bmwg-issu-meth.all@ietf.org" > Subject: RE: Secdir review of draft-ietf-bmwg-issu-meth-01 Hi Frank, Thanks for your review and comments. On #1, DoS attacks: since human control is involved here, it seems unlikely that operators will begin an upgrade during a DoS attack when they know it=92s in-progress, IMO. Others should chime-in if they have other rationale or opinions. On #4, That=92s the draft date, not the expiration date. see below, Al doc shepherd Benchmarking Working Group Sarah Banks Internet Draft VSS Monitoring Intended status: Informational Fernando Calabria Expires: November 30, 2015 Cisco Systems Gery Czirjak Ramdas Machat Juniper Networks May 30, 2015 ISSU Benchmarking Methodology draft-ietf-bmwg-issu-meth-01 From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] Sent: Tuesday, June 30, 2015 9:29 PM To: secdir@ietf.org; iesg@ietf.org; draft-ietf-bmwg-issu-meth.all@ietf.org Subject: Secdir review of draft-ietf-bmwg-issu-meth-01 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comment. This draft specifies a set of common methodologies and procedures designed = to characterize the overall behavior of a Device Under Test (DUT), subject = to an ISSU event. I have the following comments: 1. Should the ISSU test methodology include the verification and test= when the DUT is under network DDoS attacks? 2. In the software download stage, in addition to compatibility check= s and verification of checksums, we should also explicitly mention that the= device should verify the authenticity and integrity of its download. I.e. = verify signatures on signed code and OCSP/CRL for the used signature. And t= hat a system must not load unverified code; 3. even in a test environment all deployed software components must b= e verified (e.g. using signatures); 4. Nits: this draft has expired on May-30, 2015 Recommendation: Ready With Issues B.R. Frank --_000_D1B950B649F87fcalabriciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7DA14B3390DD7345A2036F7DFA37DCB5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Thank you Frank for your review and Al for addressing # 1 and # 4 ..

In regards to # 2 and #3 


We also saw and considered how  verifications like the authentici= ty of a SW package may be a concern , even more,   nowadays,  wit= h emerging SDN  like implementations , 

Unfortunately   not all the vendors nor even software specific op= erating systems  within vendors,  have =93consistent  implem= entations" of  Digital Signatures nor  Certificates and do n= ot make these checks a mandatory task  before performing a Software up= grade.

Because of it  we tried to address it with a =91generic=92 statem= ent on Sections 3.1 and 3.2 that basically read:

"Internal compatibility
   verification may be performed by the software running on = the DUT, to
   verify the checksum of the files downloaded as well as an= y other
   pertinent checks. Depending upon vendor implementation, t= hese
   mechanisms may extend to include verification that the do= wnloaded
   module(s) =85"

=97

Internal compatibility verification may be
   performed by the software running on the DUT, as part of = the upgrade
   process itself, to verify the checksum of the files downl= oaded as
   well as any other pertinent checks=85.



The authors of this document understand  how these are real issue= s / concerns on managing an operating a  Software   environment, = ,  but we do not believe that an specific ISSU  document should a= ddresses them in  detail 

-Fernando 







From: <MORTON>, "ALFRED = C (AL)" <acmorton@att.com&g= t;
Date: Wednesday, July 1, 2015 at 8:= 08 AM
To: "Xialiang (Frank)" &l= t;frank.xialiang@huawei.com>, "secdir@ietf.org" &= lt;secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-bmwg-issu-met= h.all@ietf.org" <draft-ietf-bmwg-issu-meth.all@ietf.org>
Subject: RE: Secdir review of draft= -ietf-bmwg-issu-meth-01

Hi Frank,

Thanks for your review and comments.

 

On #1, DoS attacks: since human control is involved = here,

it seems unlikely that operators will begin an upgra= de

during a DoS attack when they know it=92s in-progres= s, IMO.

Others should chime-in if they have other rationale = or opinions.

 

On #4, That=92s the draft date, not the expiration d= ate.

see below,

Al

doc shepherd

 

Benchmarking Working Group    &n= bsp;            = ;            &n= bsp;    Sarah Banks

Internet Draft      &n= bsp;            = ;            &n= bsp;           VSS Monito= ring

Intended status: Informational   &nbs= p;            &= nbsp;       Fernando Calabria

Expires: November 30, 2015    &n= bsp;            = ;            &n= bsp;  Cisco Systems

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            Ger= y Czirjak

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           Ramdas Ma= chat

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Juniper Networks=

        &nbs= p;            &= nbsp;            &nb= sp;            =             May= 30, 2015

        &nbs= p;            &= nbsp;

ISSU Benchmarking Methodology

draft-ietf-bmwg-issu-meth-01

 

From:<= span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif;"> Xialiang = (Frank) [mailto:frank.xialiang= @huawei.com]
Sent: Tuesday, June 30, 2015 9:29 PM
To: secdir@ietf.org; iesg@ietf.org; draft-ietf-bmwg-issu-meth.all@ietf.org
Subject: Secdir review of draft-ietf-bmwg-issu-meth-01

 =

I have re= viewed this document as part of the security directorate's ongoing eff= ort to review all IETF documents being processed by the IESG.  Th= ese comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs = should treat these comments just like any other last call comment.

&nbs= p;

This draf= t specifies a set of common methodologies and procedures designed to charac= terize the overall behavior of a Device Under Test (DUT), subject to an ISS= U event.

&nbs= p;

I have th= e following comments:

1.       Should the ISSU test methodology include the verification and test when = the DUT is under network DDoS attacks?

2.       In the software download stage, in addition to compatibility checks and = verification of checksums, we should also explicitly mention that the devic= e should verify the authenticity and integrity of its download. I.e. verify signatures on signed code and OCSP/= CRL for the used signature. And that a system must not load unverified code= ;

3.       even in a test environment all deployed software components must be veri= fied (e.g. using signatures);

4.       Nits: this draft has expired on May-30, 2015

&nbs= p;

Recommend= ation:  Ready With Issues

&nbs= p;

B.R.=

Frank

 --_000_D1B950B649F87fcalabriciscocom_-- From nobody Wed Jul 1 14:39:17 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732A61ACDB3; Wed, 1 Jul 2015 10:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfGOl_q3aEA0; Wed, 1 Jul 2015 10:39:14 -0700 (PDT) Received: from firefly.encrypted.net (firefly.encrypted.net [72.13.81.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1851ACD68; Wed, 1 Jul 2015 10:39:01 -0700 (PDT) Received: from firefly.encrypted.net (localhost [127.0.0.1]) by firefly.encrypted.net (Postfix) with ESMTP id 59B4333E76; Wed, 1 Jul 2015 10:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at encrypted.net Received: from firefly.encrypted.net ([127.0.0.1]) by firefly.encrypted.net (firefly.encrypted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik-RAWcb8Vnv; Wed, 1 Jul 2015 10:39:00 -0700 (PDT) Received: from divinaair.global.tektronix.net (66-7-254-66.static-ip.telepacific.net [66.7.254.66]) by firefly.encrypted.net (Postfix) with ESMTPSA id 03B5633E74; Wed, 1 Jul 2015 10:39:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C06B8EEB-BD98-4923-B765-279994070D8A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Sarah Banks In-Reply-To: Date: Wed, 1 Jul 2015 10:39:03 -0700 Message-Id: <9E32EDE7-875D-400C-BC45-806C854C3AAB@encrypted.net> References: <4AF73AA205019A4C8A1DDD32C034631D0662C6E4BD@NJFPSRVEXG0.research.att.com> To: "Fernando Calabria (fcalabri)" X-Mailer: Apple Mail (2.2102) Archived-At: X-Mailman-Approved-At: Wed, 01 Jul 2015 14:39:15 -0700 Cc: "iesg@ietf.org" , "draft-ietf-bmwg-issu-meth.all@ietf.org" , ALFRED MORTON , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-bmwg-issu-meth-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 17:39:17 -0000 --Apple-Mail=_C06B8EEB-BD98-4923-B765-279994070D8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Frank, Thanks for your review! To add to what Fernando discussed below, = for your points 2 and 3, we came to this conclusion not only because = vendors don't have consistency in implementation, but also because = customers with that running code weren't asking for it either. Often, = they're downloading the code via login from the vendors' site - this = doesn't mitigate your points, but it sheds some light on why perhaps = they're not as concerned about it. I echo Fer's thoughts though, that we = feel it's as covered as it could be with the section of the draft he = quotes below - that the operator performing the ISSU should ensure the = veracity of the code before installing it. Finally, I too share Al's thought, that a DDOS wouldn't likely = be underway before an ISSU starts. A DDOS could, in theory, start after = the ISSU starts, but then, any number of corner cases could occur when = an ISSU starts, and that part might be a whole new draft. :) IMHO this = is unlikely, and I'm not moved to cover it in the draft, however, if you = have suggestions, we're willing to review them. Thanks Sarah > On Jul 1, 2015, at 5:59 AM, Fernando Calabria (fcalabri) = wrote: >=20 >=20 > Thank you Frank for your review and Al for addressing # 1 and # 4 .. >=20 > In regards to # 2 and #3=20 >=20 >=20 > We also saw and considered how verifications like the authenticity of = a SW package may be a concern , even more, nowadays, with emerging = SDN like implementations ,=20 >=20 > Unfortunately not all the vendors nor even software specific = operating systems within vendors, have =93consistent implementations" = of Digital Signatures nor Certificates and do not make these checks a = mandatory task before performing a Software upgrade. >=20 > Because of it we tried to address it with a =91generic=92 statement = on Sections 3.1 and 3.2 that basically read: >=20 > "Internal compatibility > verification may be performed by the software running on the DUT, = to > verify the checksum of the files downloaded as well as any other > pertinent checks. Depending upon vendor implementation, these > mechanisms may extend to include verification that the downloaded > module(s) =85" >=20 > =97 >=20 > Internal compatibility verification may be > performed by the software running on the DUT, as part of the = upgrade > process itself, to verify the checksum of the files downloaded as > well as any other pertinent checks=85. >=20 >=20 >=20 > The authors of this document understand how these are real issues / = concerns on managing an operating a Software environment, , but we = do not believe that an specific ISSU document should addresses them in = detail=20 >=20 > -Fernando=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: , "ALFRED C (AL)" > > Date: Wednesday, July 1, 2015 at 8:08 AM > To: "Xialiang (Frank)" >, "secdir@ietf.org = " >, = "iesg@ietf.org " >, "draft-ietf-bmwg-issu-meth.all@ietf.org = " = > > Subject: RE: Secdir review of draft-ietf-bmwg-issu-meth-01 >=20 > Hi Frank, > Thanks for your review and comments. > =20 > On #1, DoS attacks: since human control is involved here, > it seems unlikely that operators will begin an upgrade > during a DoS attack when they know it=92s in-progress, IMO. > Others should chime-in if they have other rationale or opinions. > =20 > On #4, That=92s the draft date, not the expiration date. > see below, > Al > doc shepherd > =20 > Benchmarking Working Group Sarah = Banks > Internet Draft VSS = Monitoring > Intended status: Informational Fernando = Calabria > Expires: November 30, 2015 Cisco = Systems > Gery = Czirjak > Ramdas = Machat > Juniper = Networks > May 30, = 2015 > =20 > ISSU Benchmarking Methodology > draft-ietf-bmwg-issu-meth-01 > =20 > From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com = ]=20 > Sent: Tuesday, June 30, 2015 9:29 PM > To: secdir@ietf.org ; iesg@ietf.org = ; draft-ietf-bmwg-issu-meth.all@ietf.org = > Subject: Secdir review of draft-ietf-bmwg-issu-meth-01 > =20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comment. > =20 > This draft specifies a set of common methodologies and procedures = designed to characterize the overall behavior of a Device Under Test = (DUT), subject to an ISSU event. > =20 > I have the following comments: > 1. Should the ISSU test methodology include the verification and = test when the DUT is under network DDoS attacks? > 2. In the software download stage, in addition to compatibility = checks and verification of checksums, we should also explicitly mention = that the device should verify the authenticity and integrity of its = download. I.e. verify signatures on signed code and OCSP/CRL for the = used signature. And that a system must not load unverified code; > 3. even in a test environment all deployed software components = must be verified (e.g. using signatures); > 4. Nits: this draft has expired on May-30, 2015 > =20 > Recommendation: Ready With Issues > =20 > B.R. > Frank --Apple-Mail=_C06B8EEB-BD98-4923-B765-279994070D8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Frank,
Thanks for your review! To add to = what Fernando discussed below, for your points 2 and 3, we came to this = conclusion not only because vendors don't have consistency in = implementation, but also because customers with that running code = weren't asking for it either. Often, they're downloading the code via = login from the vendors' site - this doesn't mitigate your points, but it = sheds some light on why perhaps they're not as concerned about it. I = echo Fer's thoughts though, that we feel it's as covered as it could be = with the section of the draft he quotes below - that the operator = performing the ISSU should ensure the veracity of the code before = installing it.

= Finally, I too share Al's thought, that a DDOS wouldn't likely be = underway before an ISSU starts. A DDOS could, in theory, start after the = ISSU starts, but then, any number of corner cases could occur when an = ISSU starts, and that part might be a whole new draft. :) IMHO this is = unlikely, and I'm not moved to cover it in the draft, however, if you = have suggestions, we're willing to review them.

Thanks
Sarah


On Jul 1, 2015, at 5:59 AM, Fernando Calabria (fcalabri) = <fcalabri@cisco.com> wrote:


Thank you Frank for your review and Al for = addressing # 1 and # 4 ..

In = regards to # 2 and #3 


We also saw and considered how  verifications like = the authenticity of a SW package may be a concern , even more,   = nowadays,  with emerging SDN  like implementations = , 

Unfortunately   not all = the vendors nor even software specific operating systems  within = vendors,  have =93consistent  implementations" of =  Digital Signatures nor  Certificates and do not make these = checks a mandatory task  before performing a Software = upgrade.

Because of it  we tried = to address it with a =91generic=92 statement on Sections 3.1 and 3.2 = that basically read:

"Internal compatibility
  =  verification may be performed by the software running on the DUT, = to
   verify the checksum of the files downloaded as = well as any other
   pertinent checks. Depending upon vendor = implementation, these
   mechanisms may = extend to include verification that the downloaded
   module(s) =85"

=97

Internal = compatibility verification may be
  =  performed by the software running on the DUT, as part of the = upgrade
   process itself, to verify the = checksum of the files downloaded as
  =  well as any other pertinent checks=85.



The = authors of this document understand  how these are real issues / = concerns on managing an operating a  Software   environment, , =  but we do not believe that an specific ISSU  document should = addresses them in  detail 

-Fernando 







From: <MORTON>, = "ALFRED C (AL)" <acmorton@att.com>
Date: Wednesday, July 1, = 2015 at 8:08 AM
To: "Xialiang (Frank)" = <frank.xialiang@huawei.com>,= "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-bmwg-issu-meth.all@ietf.org" <draft-ietf-bmwg-issu-meth.all@ietf.org>
Subject: RE: Secdir review of = draft-ietf-bmwg-issu-meth-01

Hi Frank,
Thanks for your review and comments.
 
On #1, = DoS attacks: since human control is involved here,
it seems unlikely that operators will begin = an upgrade
during a DoS attack when they = know it=92s in-progress, IMO.
Others = should chime-in if they have other rationale or opinions.
 
On #4, = That=92s the draft date, not the expiration date.
see below,
Al
doc = shepherd
 
Benchmarking Working = Group           &nb= sp;            = ;          Sarah Banks
Internet = Draft           &nb= sp;            = ;            &= nbsp;      VSS Monitoring
Intended status: = Informational          &= nbsp;           &nb= sp; Fernando Calabria
Expires:= November 30, = 2015           &nbs= p;            =         Cisco Systems
          &nb= sp;            = ;            &= nbsp;           &nb= sp;           Gery = Czirjak
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          Ramdas = Machat
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       Juniper Networks
          &nb= sp;            = ;         =             &n= bsp;           &nbs= p;  May 30, 2015
          &nb= sp;           
ISSU Benchmarking Methodology
draft-ietf-bmwg-issu-meth-01
 
From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] 
Sent: Tuesday, June 30, 2015 9:29 = PM
To: secdir@ietf.org; iesg@ietf.org; draft-ietf-bmwg-issu-meth.all@ietf.org
Subject: Secdir review of = draft-ietf-bmwg-issu-meth-01
 
I = have reviewed this document as part of the security = directorate's ongoing effort to review all IETF documents being = processed by the IESG.  These comments were written primarily = for the benefit of the security area directors.  Document = editors and WG chairs should treat these comments just like any = other last call comment.
 
This draft specifies a = set of common methodologies and procedures designed to characterize the = overall behavior of a Device Under Test (DUT), subject to an ISSU = event.
 
I have the following = comments:
1.       Should the ISSU test methodology include the verification and = test when the DUT is under network DDoS attacks?
2.       In the software download stage, in addition to compatibility = checks and verification of checksums, we should also explicitly mention = that the device should verify the authenticity and integrity of its = download. I.e. verify signatures on signed code and OCSP/CRL for the = used signature. And that a system must not load unverified code;
3.       even in a test environment all deployed software components = must be verified (e.g. using signatures);
4.       Nits: this draft has expired on May-30, 2015
 
Recommendation:  Ready = With Issues
 
B.R.
Frank

= --Apple-Mail=_C06B8EEB-BD98-4923-B765-279994070D8A-- From nobody Wed Jul 1 14:39:18 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6021AD05C; Wed, 1 Jul 2015 14:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1435785804; bh=UEFjwP2aWfgf684PO3EgeoAgO+vGj8rA1YFVOd9WlCY=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=f9VYaFRZbSHVCHyQtIDVCNR/b5dgYDI3JsJ3v9UujAXz6qSpnHdkQv4uaBPYoY//2 CBFUQAKd4HYibE+fbcFJ9a54o2Eq/N6shkgLzWJDrCGKWmjeSo60gQ2ADwZ1j+ZK0f ZP7M8zAlxWZZztXFKMmpBuCznFhrf+/4NbPZvyv8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D894D1AD05C for ; Wed, 1 Jul 2015 14:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gKErZHllea8 for ; Wed, 1 Jul 2015 14:23:22 -0700 (PDT) Received: from jay.w3.org (jay.w3.org [128.30.52.169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4FF1ACF5E for ; Wed, 1 Jul 2015 14:23:21 -0700 (PDT) Received: from 31-35-157.wireless.csail.mit.edu ([128.31.35.157] helo=31-35-194.wireless.csail.mit.edu) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZAPTU-0004QB-4w for new-work@ietf.org; Wed, 01 Jul 2015 17:23:20 -0400 To: new-work@ietf.org Date: Wed, 01 Jul 2015 17:23:24 -0400 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 01 Jul 2015 14:39:15 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: XML Activity Proposal and Charters (until 2015-07-30) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 21:23:24 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the XML Activity [0] (see the W3C Process Document description of Activity Proposals [1]): http://www.w3.org/XML/2015/05/activity-proposal.html This proposal includes draft charters for the following XML Activity working groups: Efficient XML Interchange Working Group XML Query Working Group XML Core Working Group XML Processing Model Working Group XSLT Working Group XForms Working Group As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2015-07-30 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Liam Quin, XML Activity Lead . Thank you, Coralie Mercier, Acting Head of W3C Marketing & Communications [0] http://www.w3.org/XML/Activity [1] http://www.w3.org/2014/Process-20140801/#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Jul 1 15:00:09 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9A41B2AA5; Wed, 1 Jul 2015 14:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1435787279; bh=cbRaR9n+CZGy2fiuWquH+kX7uqOPyrRm4KKNtJMfrIg=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=MLb1e0B4BzzEB0VSO+sXGTvOyLWkf50fQJpc1AUCTn9irsoueOXzclGjPpMnvlTo8 F+2kcEs++IJ1WG6dKFNMCdCb6RSdrhrf18AyfBgPu9zkJ14oVdYIHnvE2TFMQmI6nZ JuTmd7qWrn7ZK0WI0S5rn6O3Wo0GYDorRN79awvA= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F231B2AA7; Wed, 1 Jul 2015 14:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.9 X-Spam-Level: X-Spam-Status: No, score=-81.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_SBL=20, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4yfAX15Py36; Wed, 1 Jul 2015 14:47:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B02301B2AA4; Wed, 1 Jul 2015 14:47:55 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150701214755.7004.47410.idtracker@ietfa.amsl.com> Date: Wed, 01 Jul 2015 14:47:55 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 01 Jul 2015 15:00:08 -0700 Subject: [secdir] [new-work] WG Review: Label Generation Rules (lager) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 21:48:00 -0000 A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-07-08. Label Generation Rules (lager) ------------------------------------------------ Current Status: Proposed WG Chairs: Scott Hollenbeck Marc Blanchet Assigned Area Director: Barry Leiba Mailing list Address: lager@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lager Archive: https://mailarchive.ietf.org/arch/browse/lager/ Charter: Domain registries, particularly those implementing IDNA (RFC 5890 et.al), usually maintain a set of criteria (or "ruleset") that governs permissible labels allowed for registration, such as [IANAIDNTABLES]. These rulesets are commonly a mixture of eligible code points along with contextual criteria that must be met concerning the positioning of certain code points. Some registries also specify rules regarding variant labels and how they are to be handled. Domain registries commonly need to share these rules, but there is no interoperable format that can be used that can support many common use cases. This group seeks to produce such a format, which will enable re-use and simpler implementation of rulesets in registries. A comprehensive format specification has been developed, named Label Generation Rules, primarily to support the rules to be used for the DNS Root Zone [Davies]. This group will use this specification as a starting point to develop a common XML language that provides a superset of functionality of current specifications [RFC 3743, RFC 4290, et.al], along with other known use cases. This single format is expected to supersede existing formats, and form the basis for future rulesets used at different levels of the DNS hierarchy. Work items: - Standard Track Specification of the Label Generation Rules References: [Davies] https://datatracker.ietf.org/doc/draft-davies-idntables/ [IANAIDNTABLES] https://www.iana.org/domains/idn-tables Milestones: Dec 2015 - Send the Label Generation Rules specification to the IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Jul 1 15:15:18 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505821A802E; Wed, 1 Jul 2015 15:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ5WWv3xKXDn; Wed, 1 Jul 2015 15:15:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84681A1AB3; Wed, 1 Jul 2015 15:15:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mMH1D5wRgzCmS; Thu, 2 Jul 2015 00:15:12 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=K1/T7vEH X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yhxViBc7HlGp; Thu, 2 Jul 2015 00:15:11 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 2 Jul 2015 00:15:11 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B5C4C80058; Wed, 1 Jul 2015 18:15:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435788910; bh=zAixQ39BnxEBXWez50UTMK+ZLk6eSbHuOPP1sk8HHhc=; h=Date:From:To:Subject; b=K1/T7vEHNNP2XEMKT3fDDsYhHmnLYx2+yW8qXNVyuqn57dFest1vELL1uIxTSUZpv dgo8qJBrpxp29o2WsFbrZwilPiMT3Vb+zQVrRu9nn69xO6PgnwwxhLdyWe8v0ZFhAl qG3FcwX6zpbQEtmFlUhaUbJ7QkqDAxjqujgG3Uwo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t61MFAw6008752; Wed, 1 Jul 2015 18:15:10 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Jul 2015 18:15:10 -0400 (EDT) From: Paul Wouters To: iesg@ietf.org, secdir@ietf.org, draft-ietf-appsawg-text-markdown-use-casas.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Subject: [secdir] Secdir review of draft-ietf-appsawg-text-markdown-use-cases X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 22:15:17 -0000 I have reviewed this document as part of the security directorate's effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comment. This document describes use cases and sometimes existing deployed code on handling "markdown" text. As such, the document introduces no new security considerations, and the Security Considerations section points to other documents that further document the respective markdown variants and their own security considerations. Recommendation:  Ready with Issues I wanted to point out two use cases (or existing deployed code?) that uses some features that might be considered a security issue. 2.1 talks about filesystem "extended attributes" and suggests to add a resource named "variant". This name might be a little too generic to only apply to markdown and might cause a name spaec collision that could potentially be a security risk. If this is a use case without deployed code, I would recommend renaming this resource to something more specific, eg "markdown-varient". If it describes actual code, then I guess that ship has sailed. 2.4 talks about MIME aware clients saving a "batch script" to disk for later execution. These kind of "autorun" or "preview" features are a security nightmare, so here too I would hope this has not yet been coded. And if not, to reconsider not supporting such a feature. Paul From nobody Wed Jul 1 19:08:15 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172071A0013; Wed, 1 Jul 2015 19:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ7DhHcO9U8a; Wed, 1 Jul 2015 19:08:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B708A1A000A; Wed, 1 Jul 2015 19:08:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYF71725; Thu, 02 Jul 2015 02:08:03 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 2 Jul 2015 03:07:59 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.143]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Thu, 2 Jul 2015 10:07:55 +0800 From: "Xialiang (Frank)" To: Sarah Banks , "Fernando Calabria (fcalabri)" Thread-Topic: Secdir review of draft-ietf-bmwg-issu-meth-01 Thread-Index: AdCznVhNjRYm7y6ZS9SgpDHakbeZ2QAWCOBAAAQtUQD//7clgP/+/KZQ Date: Thu, 2 Jul 2015 02:07:54 +0000 Message-ID: References: <4AF73AA205019A4C8A1DDD32C034631D0662C6E4BD@NJFPSRVEXG0.research.att.com> <9E32EDE7-875D-400C-BC45-806C854C3AAB@encrypted.net> In-Reply-To: <9E32EDE7-875D-400C-BC45-806C854C3AAB@encrypted.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADE739FSZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-bmwg-issu-meth.all@ietf.org" , ALFRED MORTON , "secdir@ietf.org" Subject: [secdir] =?gb2312?b?tPC4tDogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRm?= =?gb2312?b?LWJtd2ctaXNzdS1tZXRoLTAx?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 02:08:12 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADE739FSZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYXV0aG9ycywNClRoYW5rIHlvdSBmb3IgdGhlIGRldGFpbGVkIGZlZWRiYWNrcy4gSXQgaGVs cHMgbWUgdW5kZXJzdGFuZCB5b3VyIGNvbnNpZGVyYXRpb24gYW5kIGRlY2lzaW9uIG1vcmUgY2xl YXIuIEkgdGhpbmsgIHdlIGFsbCBhZ3JlZSB3aXRoIHRoZSBpbXBvcnRhbmNlIG9mIGF1dGhlbnRp Y2l0eSBhbmQgaW50ZWdyaXR5IHZlcmlmaWNhdGlvbiBmb3IgU1cgcGFja2FnZS4NClNpbmNlIHRo ZSB0ZXN0IG1ldGhvZCBhaW1zIHRvIG1pbWljIHRoZSByZWFsIG5ldHdvcmsgYXBwbGljYXRpb24s IGFuZCB0aGUgY29tcGxleGl0eSBhbmQgcmlza3Mgb2YgcmVhbCBuZXR3b3JrIHdpbGwgY2F1c2Ug dGhlICB1bnZlcmlmaWVkIFNXIHBhY2thZ2UgcXVpdGUgcG9zc2libGUsIHNvIEkgc3VnZ2VzdCB0 byBjb25zaWRlciB0aGUgcmVsYXRlZCB0ZXN0IHN0ZXBzLg0KT2YgY291cnNlLCB5b3UgY2FuIG1h a2UgdGhlIHRlc3Qgc3RlcHMgdG8gYmUgb3B0aW9uYWwsIG5vdCBtYW5kYXRvcnksIGR1ZSB0byB0 aGUgcmVhbGl0eS4NCg0KQW55d2F5LCBpdKGvcyBqdXN0IG15IHN1Z2dlc3Rpb24sIHlvdSBjYW4g ZGVjaWRlIGJ5IHlvdXIgb3duLg0KDQpCLlIuDQpGcmFuaw0KDQq3orz+yMs6IFNhcmFoIEJhbmtz IFttYWlsdG86c2JhbmtzQGVuY3J5cHRlZC5uZXRdDQq3osvNyrG85DogMjAxNcTqN9TCMsjVIDE6 MzkNCsrVvP7IyzogRmVybmFuZG8gQ2FsYWJyaWEgKGZjYWxhYnJpKQ0Ks63LzTogQUxGUkVEIE1P UlRPTjsgWGlhbGlhbmcgKEZyYW5rKTsgc2VjZGlyQGlldGYub3JnOyBpZXNnQGlldGYub3JnOyBk cmFmdC1pZXRmLWJtd2ctaXNzdS1tZXRoLmFsbEBpZXRmLm9yZw0K1vfM4jogUmU6IFNlY2RpciBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1ibXdnLWlzc3UtbWV0aC0wMQ0KDQpIaSBGcmFuaywNCiAgICAg ICBUaGFua3MgZm9yIHlvdXIgcmV2aWV3ISBUbyBhZGQgdG8gd2hhdCBGZXJuYW5kbyBkaXNjdXNz ZWQgYmVsb3csIGZvciB5b3VyIHBvaW50cyAyIGFuZCAzLCB3ZSBjYW1lIHRvIHRoaXMgY29uY2x1 c2lvbiBub3Qgb25seSBiZWNhdXNlIHZlbmRvcnMgZG9uJ3QgaGF2ZSBjb25zaXN0ZW5jeSBpbiBp bXBsZW1lbnRhdGlvbiwgYnV0IGFsc28gYmVjYXVzZSBjdXN0b21lcnMgd2l0aCB0aGF0IHJ1bm5p bmcgY29kZSB3ZXJlbid0IGFza2luZyBmb3IgaXQgZWl0aGVyLiBPZnRlbiwgdGhleSdyZSBkb3du bG9hZGluZyB0aGUgY29kZSB2aWEgbG9naW4gZnJvbSB0aGUgdmVuZG9ycycgc2l0ZSAtIHRoaXMg ZG9lc24ndCBtaXRpZ2F0ZSB5b3VyIHBvaW50cywgYnV0IGl0IHNoZWRzIHNvbWUgbGlnaHQgb24g d2h5IHBlcmhhcHMgdGhleSdyZSBub3QgYXMgY29uY2VybmVkIGFib3V0IGl0LiBJIGVjaG8gRmVy J3MgdGhvdWdodHMgdGhvdWdoLCB0aGF0IHdlIGZlZWwgaXQncyBhcyBjb3ZlcmVkIGFzIGl0IGNv dWxkIGJlIHdpdGggdGhlIHNlY3Rpb24gb2YgdGhlIGRyYWZ0IGhlIHF1b3RlcyBiZWxvdyAtIHRo YXQgdGhlIG9wZXJhdG9yIHBlcmZvcm1pbmcgdGhlIElTU1Ugc2hvdWxkIGVuc3VyZSB0aGUgdmVy YWNpdHkgb2YgdGhlIGNvZGUgYmVmb3JlIGluc3RhbGxpbmcgaXQuDQoNCiAgICAgICBGaW5hbGx5 LCBJIHRvbyBzaGFyZSBBbCdzIHRob3VnaHQsIHRoYXQgYSBERE9TIHdvdWxkbid0IGxpa2VseSBi ZSB1bmRlcndheSBiZWZvcmUgYW4gSVNTVSBzdGFydHMuIEEgRERPUyBjb3VsZCwgaW4gdGhlb3J5 LCBzdGFydCBhZnRlciB0aGUgSVNTVSBzdGFydHMsIGJ1dCB0aGVuLCBhbnkgbnVtYmVyIG9mIGNv cm5lciBjYXNlcyBjb3VsZCBvY2N1ciB3aGVuIGFuIElTU1Ugc3RhcnRzLCBhbmQgdGhhdCBwYXJ0 IG1pZ2h0IGJlIGEgd2hvbGUgbmV3IGRyYWZ0LiA6KSBJTUhPIHRoaXMgaXMgdW5saWtlbHksIGFu ZCBJJ20gbm90IG1vdmVkIHRvIGNvdmVyIGl0IGluIHRoZSBkcmFmdCwgaG93ZXZlciwgaWYgeW91 IGhhdmUgc3VnZ2VzdGlvbnMsIHdlJ3JlIHdpbGxpbmcgdG8gcmV2aWV3IHRoZW0uDQoNClRoYW5r cw0KU2FyYWgNCg0KDQpPbiBKdWwgMSwgMjAxNSwgYXQgNTo1OSBBTSwgRmVybmFuZG8gQ2FsYWJy aWEgKGZjYWxhYnJpKSA8ZmNhbGFicmlAY2lzY28uY29tPG1haWx0bzpmY2FsYWJyaUBjaXNjby5j b20+PiB3cm90ZToNCg0KDQpUaGFuayB5b3UgRnJhbmsgZm9yIHlvdXIgcmV2aWV3IGFuZCBBbCBm b3IgYWRkcmVzc2luZyAjIDEgYW5kICMgNCAuLg0KDQpJbiByZWdhcmRzIHRvICMgMiBhbmQgIzMN Cg0KDQpXZSBhbHNvIHNhdyBhbmQgY29uc2lkZXJlZCBob3cgIHZlcmlmaWNhdGlvbnMgbGlrZSB0 aGUgYXV0aGVudGljaXR5IG9mIGEgU1cgcGFja2FnZSBtYXkgYmUgYSBjb25jZXJuICwgZXZlbiBt b3JlLCAgIG5vd2FkYXlzLCAgd2l0aCBlbWVyZ2luZyBTRE4gIGxpa2UgaW1wbGVtZW50YXRpb25z ICwNCg0KVW5mb3J0dW5hdGVseSAgIG5vdCBhbGwgdGhlIHZlbmRvcnMgbm9yIGV2ZW4gc29mdHdh cmUgc3BlY2lmaWMgb3BlcmF0aW5nIHN5c3RlbXMgIHdpdGhpbiB2ZW5kb3JzLCAgaGF2ZSChsGNv bnNpc3RlbnQgIGltcGxlbWVudGF0aW9ucyIgb2YgIERpZ2l0YWwgU2lnbmF0dXJlcyBub3IgIENl cnRpZmljYXRlcyBhbmQgZG8gbm90IG1ha2UgdGhlc2UgY2hlY2tzIGEgbWFuZGF0b3J5IHRhc2sg IGJlZm9yZSBwZXJmb3JtaW5nIGEgU29mdHdhcmUgdXBncmFkZS4NCg0KQmVjYXVzZSBvZiBpdCAg d2UgdHJpZWQgdG8gYWRkcmVzcyBpdCB3aXRoIGEgoa5nZW5lcmljoa8gc3RhdGVtZW50IG9uIFNl Y3Rpb25zIDMuMSBhbmQgMy4yIHRoYXQgYmFzaWNhbGx5IHJlYWQ6DQoNCiJJbnRlcm5hbCBjb21w YXRpYmlsaXR5DQogICB2ZXJpZmljYXRpb24gbWF5IGJlIHBlcmZvcm1lZCBieSB0aGUgc29mdHdh cmUgcnVubmluZyBvbiB0aGUgRFVULCB0bw0KICAgdmVyaWZ5IHRoZSBjaGVja3N1bSBvZiB0aGUg ZmlsZXMgZG93bmxvYWRlZCBhcyB3ZWxsIGFzIGFueSBvdGhlcg0KICAgcGVydGluZW50IGNoZWNr cy4gRGVwZW5kaW5nIHVwb24gdmVuZG9yIGltcGxlbWVudGF0aW9uLCB0aGVzZQ0KICAgbWVjaGFu aXNtcyBtYXkgZXh0ZW5kIHRvIGluY2x1ZGUgdmVyaWZpY2F0aW9uIHRoYXQgdGhlIGRvd25sb2Fk ZWQNCiAgIG1vZHVsZShzKSChrSINCg0KoaoNCg0KSW50ZXJuYWwgY29tcGF0aWJpbGl0eSB2ZXJp ZmljYXRpb24gbWF5IGJlDQogICBwZXJmb3JtZWQgYnkgdGhlIHNvZnR3YXJlIHJ1bm5pbmcgb24g dGhlIERVVCwgYXMgcGFydCBvZiB0aGUgdXBncmFkZQ0KICAgcHJvY2VzcyBpdHNlbGYsIHRvIHZl cmlmeSB0aGUgY2hlY2tzdW0gb2YgdGhlIGZpbGVzIGRvd25sb2FkZWQgYXMNCiAgIHdlbGwgYXMg YW55IG90aGVyIHBlcnRpbmVudCBjaGVja3OhrS4NCg0KDQoNClRoZSBhdXRob3JzIG9mIHRoaXMg ZG9jdW1lbnQgdW5kZXJzdGFuZCAgaG93IHRoZXNlIGFyZSByZWFsIGlzc3VlcyAvIGNvbmNlcm5z IG9uIG1hbmFnaW5nIGFuIG9wZXJhdGluZyBhICBTb2Z0d2FyZSAgIGVudmlyb25tZW50LCAsICBi dXQgd2UgZG8gbm90IGJlbGlldmUgdGhhdCBhbiBzcGVjaWZpYyBJU1NVICBkb2N1bWVudCBzaG91 bGQgYWRkcmVzc2VzIHRoZW0gaW4gIGRldGFpbA0KDQotRmVybmFuZG8NCg0KDQoNCg0KDQoNCg0K RnJvbTogPE1PUlRPTj4sICJBTEZSRUQgQyAoQUwpIiA8YWNtb3J0b25AYXR0LmNvbTxtYWlsdG86 YWNtb3J0b25AYXR0LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgMSwgMjAxNSBhdCA4OjA4 IEFNDQpUbzogIlhpYWxpYW5nIChGcmFuaykiIDxmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tPG1h aWx0bzpmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tPj4sICJzZWNkaXJAaWV0Zi5vcmc8bWFpbHRv OnNlY2RpckBpZXRmLm9yZz4iIDxzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBpZXRmLm9y Zz4+LCAiaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4iIDxpZXNnQGlldGYub3Jn PG1haWx0bzppZXNnQGlldGYub3JnPj4sICJkcmFmdC1pZXRmLWJtd2ctaXNzdS1tZXRoLmFsbEBp ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ibXdnLWlzc3UtbWV0aC5hbGxAaWV0Zi5vcmc+IiA8 ZHJhZnQtaWV0Zi1ibXdnLWlzc3UtbWV0aC5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt Ym13Zy1pc3N1LW1ldGguYWxsQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBTZWNkaXIgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtYm13Zy1pc3N1LW1ldGgtMDENCg0KSGkgRnJhbmssDQpUaGFua3MgZm9y IHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4NCg0KT24gIzEsIERvUyBhdHRhY2tzOiBzaW5jZSBo dW1hbiBjb250cm9sIGlzIGludm9sdmVkIGhlcmUsDQppdCBzZWVtcyB1bmxpa2VseSB0aGF0IG9w ZXJhdG9ycyB3aWxsIGJlZ2luIGFuIHVwZ3JhZGUNCmR1cmluZyBhIERvUyBhdHRhY2sgd2hlbiB0 aGV5IGtub3cgaXShr3MgaW4tcHJvZ3Jlc3MsIElNTy4NCk90aGVycyBzaG91bGQgY2hpbWUtaW4g aWYgdGhleSBoYXZlIG90aGVyIHJhdGlvbmFsZSBvciBvcGluaW9ucy4NCg0KT24gIzQsIFRoYXSh r3MgdGhlIGRyYWZ0IGRhdGUsIG5vdCB0aGUgZXhwaXJhdGlvbiBkYXRlLg0Kc2VlIGJlbG93LA0K QWwNCmRvYyBzaGVwaGVyZA0KDQpCZW5jaG1hcmtpbmcgV29ya2luZyBHcm91cCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTYXJhaCBCYW5rcw0KSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVlNTIE1vbml0b3JpbmcNCkludGVu ZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgIEZlcm5hbmRv IENhbGFicmlhDQpFeHBpcmVzOiBOb3ZlbWJlciAzMCwgMjAxNSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQ2lzY28gU3lzdGVtcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHZXJ5IEN6aXJqYWsNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSYW1kYXMgTWFjaGF0 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SnVuaXBlciBOZXR3b3Jrcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNYXkgMzAsIDIwMTUNCg0KSVNTVSBCZW5jaG1hcmtpbmcgTWV0 aG9kb2xvZ3kNCmRyYWZ0LWlldGYtYm13Zy1pc3N1LW1ldGgtMDENCg0KRnJvbTogWGlhbGlhbmcg KEZyYW5rKSBbbWFpbHRvOmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5 LCBKdW5lIDMwLCAyMDE1IDk6MjkgUE0NClRvOiBzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2Rp ckBpZXRmLm9yZz47IGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBkcmFmdC1p ZXRmLWJtd2ctaXNzdS1tZXRoLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ibXdnLWlz c3UtbWV0aC5hbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWll dGYtYm13Zy1pc3N1LW1ldGgtMDENCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMg cGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZp ZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNl IGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBz ZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwg Y29tbWVudC4NCg0KVGhpcyBkcmFmdCBzcGVjaWZpZXMgYSBzZXQgb2YgY29tbW9uIG1ldGhvZG9s b2dpZXMgYW5kIHByb2NlZHVyZXMgZGVzaWduZWQgdG8gY2hhcmFjdGVyaXplIHRoZSBvdmVyYWxs IGJlaGF2aW9yIG9mIGEgRGV2aWNlIFVuZGVyIFRlc3QgKERVVCksIHN1YmplY3QgdG8gYW4gSVNT VSBldmVudC4NCg0KSSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHM6DQoxLiAgICAgICBTaG91 bGQgdGhlIElTU1UgdGVzdCBtZXRob2RvbG9neSBpbmNsdWRlIHRoZSB2ZXJpZmljYXRpb24gYW5k IHRlc3Qgd2hlbiB0aGUgRFVUIGlzIHVuZGVyIG5ldHdvcmsgRERvUyBhdHRhY2tzPw0KMi4gICAg ICAgSW4gdGhlIHNvZnR3YXJlIGRvd25sb2FkIHN0YWdlLCBpbiBhZGRpdGlvbiB0byBjb21wYXRp YmlsaXR5IGNoZWNrcyBhbmQgdmVyaWZpY2F0aW9uIG9mIGNoZWNrc3Vtcywgd2Ugc2hvdWxkIGFs c28gZXhwbGljaXRseSBtZW50aW9uIHRoYXQgdGhlIGRldmljZSBzaG91bGQgdmVyaWZ5IHRoZSBh dXRoZW50aWNpdHkgYW5kIGludGVncml0eSBvZiBpdHMgZG93bmxvYWQuIEkuZS4gdmVyaWZ5IHNp Z25hdHVyZXMgb24gc2lnbmVkIGNvZGUgYW5kIE9DU1AvQ1JMIGZvciB0aGUgdXNlZCBzaWduYXR1 cmUuIEFuZCB0aGF0IGEgc3lzdGVtIG11c3Qgbm90IGxvYWQgdW52ZXJpZmllZCBjb2RlOw0KMy4g ICAgICAgZXZlbiBpbiBhIHRlc3QgZW52aXJvbm1lbnQgYWxsIGRlcGxveWVkIHNvZnR3YXJlIGNv bXBvbmVudHMgbXVzdCBiZSB2ZXJpZmllZCAoZS5nLiB1c2luZyBzaWduYXR1cmVzKTsNCjQuICAg ICAgIE5pdHM6IHRoaXMgZHJhZnQgaGFzIGV4cGlyZWQgb24gTWF5LTMwLCAyMDE1DQoNClJlY29t bWVuZGF0aW9uOiAgUmVhZHkgV2l0aCBJc3N1ZXMNCg0KQi5SLg0KRnJhbmsNCg0K --_000_C02846B1344F344EB4FAA6FA7AF481F12ADE739FSZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi authors= ,

Thank you = for the detailed feedbacks. It helps me understand your consideration and d= ecision more clear. I think  we all agree with the importance of authenticity and integrity verification for SW package.

Since the = test method aims to mimic the real network application, and the complexity = and risks of real network will cause the  unverified SW package quite possible, so I suggest to consider the related test steps.

Of course,= you can make the test steps to be optional, not mandatory, due to the real= ity.

 = ;

Anyway, it= =A1=AFs just my suggestion, you can decide by your own.

 = ;

B.R.<= /o:p>

Frank=

 = ;

=B7=A2=BC=FE=C8=CB: Sarah B= anks [mailto:sbanks@encrypted.net]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA7=D4=C22=C8=D5 1:39
=CA=D5=BC=FE=C8=CB: Fernando Calabria (fcalabri)
=B3=AD=CB=CD: ALFRED MORTON; Xialiang (Frank); secdir@ietf.org; iesg@ietf.org; draft-ie= tf-bmwg-issu-meth.all@ietf.org
=D6=F7=CC=E2: Re: Secdir review of draft-ietf-bmwg-issu-meth-01

 

Hi Frank,

=        Thanks for your review! To add to what Fernando= discussed below, for your points 2 and 3, we came to this conclusion not o= nly because vendors don't have consistency in implementation, but also beca= use customers with that running code weren't asking for it either. Often, they're downloading the code via logi= n from the vendors' site - this doesn't mitigate your points, but it sheds = some light on why perhaps they're not as concerned about it. I echo Fer's t= houghts though, that we feel it's as covered as it could be with the section of the draft he quotes below - = that the operator performing the ISSU should ensure the veracity of the cod= e before installing it.

 

=        Finally, I too share Al's thought, that a DDOS = wouldn't likely be underway before an ISSU starts. A DDOS could, in theory,= start after the ISSU starts, but then, any number of corner cases could oc= cur when an ISSU starts, and that part might be a whole new draft. :) IMHO this is unlikely, and I'm not mov= ed to cover it in the draft, however, if you have suggestions, we're willin= g to review them.

 

Thanks

Sarah

 

 

On Jul 1, 2015, at 5:59 AM, Fer= nando Calabria (fcalabri) <fcalabr= i@cisco.com> wrote:

 


Thank you Frank for your review and Al for addressing # 1 and # 4 ..

 =

In regards to # 2 and #3=  

 =

 =

We also saw and consider= ed how  verifications like the authenticity of a SW package may be a c= oncern , even more,   nowadays,  with emerging SDN  like imp= lementations , 

 =

Unfortunately   not= all the vendors nor even software specific operating systems  within = vendors,  have =A1=B0consistent  implementations" of  D= igital Signatures nor  Certificates and do not make these checks a mandatory task  = ;before performing a Software upgrade.

 =

Because of it  we t= ried to address it with a =A1=AEgeneric=A1=AF statement on Sections 3.1 and= 3.2 that basically read:

 =

"Internal compatibi= lity

   verificatio= n may be performed by the software running on the DUT, to=

   verify the = checksum of the files downloaded as well as any other

   pertinent c= hecks. Depending upon vendor implementation, these

   mechanisms = may extend to include verification that the downloaded

   module(s) = =A1=AD"

 =

=A1=AA=

 =

Internal compatibility v= erification may be

   performed b= y the software running on the DUT, as part of the upgrade=

   process its= elf, to verify the checksum of the files downloaded as

   well as any= other pertinent checks=A1=AD.

 =

 =

 =

The authors of this docu= ment understand  how these are real issues / concerns on managing an o= perating a  Software   environment, ,  but we do not believe= that an specific ISSU  document should addresses them in  detail = ;

 =

-Fernando 

 =

 =

 =

 =

 =

 =

 =

From: &= lt;MORTON>, "ALFRED C (AL)" <acmorton@att.com>
Date: Wednesday, J= uly 1, 2015 at 8:08 AM
To: "Xialiang= (Frank)" <frank.xialiang@huawei.com>, "secdir@ietf.org" <secdir= @ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-bmwg-issu-meth.all@ietf.org" = <draft-ietf-bmwg-issu-meth.all@ietf.org>
Subject: RE: Secdi= r review of draft-ietf-bmwg-issu-meth-01

 =

Hi Frank,

Thanks for your review and comments.

 <= /p>

On #1, DoS attacks: since human control is involved here,

it seems unlikely that operators will begin an upgrade

during a DoS attack when they know it=A1=AFs in-progress, IM= O.

Others should chime-in if they have other rationale or opini= ons.

 <= /p>

On #4, That=A1=AFs the draft date, not the expiration date.<= /span>

see below,

Al

doc shepherd

 <= /p>

Benchmarking Working Group     &nbs= p;            &= nbsp;           &nbs= p;   Sarah Banks

Internet Draft       &nbs= p;            &= nbsp;           &nbs= p;          VSS Monitoring

Intended status: Informational     =             &nb= sp;      Fernando Calabria

Expires: November 30, 2015     &nbs= p;            &= nbsp;           &nbs= p; Cisco Systems

          =             &nb= sp;            =             &nb= sp;           Gery Czirja= k

          =             &nb= sp;            =             &nb= sp;          Ramdas Machat

          =             &nb= sp;            =             &nb= sp;       Juniper Networks

          =             &nb= sp;             = ;            &n= bsp;          May 30, 201= 5

          =             

ISSU Benchmarking Methodology

draft-ietf-bmwg-issu-meth-01

 <= /p>

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] 
Sent: Tuesday, Jun= e 30, 2015 9:29 PM
To: secdir@ietf.org; iesg@ietf.org; draft-ietf-bmwg-issu-m= eth.all@ietf.org
Subject: Secdir re= view of draft-ietf-bmwg-issu-meth-01

 =

I have reviewed this document as part of = the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were writ= ten primarily for the benefit of the security area directors.  Do= cument editors and WG chairs should treat these comments just like any= other last call comment.

 

This draft specifies a set of common meth= odologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event.

 

I have the following comments:=

1.       Should the ISSU test methodology include the verification and test when the DUT i= s under network DDoS attacks?

2.       In the software download stage, in addition to compatibility checks and verif= ication of checksums, we should also explicitly mention that the device sho= uld verify the authenticity and integrity of its download. I.e. verify sign= atures on signed code and OCSP/CRL for the used signature. And that a system must not load unverified code;

3.       even in a test environment all deployed software components must be verified (e= .g. using signatures);

4.       Nits: this draft has expired on May-30, 2015

 

Recommendation:  Ready With Issues

 

B.R.

Frank

 

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADE739FSZXEMA502MBSchi_-- From nobody Wed Jul 1 22:19:37 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63561B2ECA for ; Wed, 1 Jul 2015 22:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZygKULI_7JuN for ; Wed, 1 Jul 2015 22:19:34 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108AA1B2EC8 for ; Wed, 1 Jul 2015 22:19:34 -0700 (PDT) Received: by qget71 with SMTP id t71so28490658qge.2 for ; Wed, 01 Jul 2015 22:19:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=MBA39cwMFP/qI3dRSF3xsXmLykLmlXD7a7I3u+WCtAI=; b=RJIVt8BYPRAPouTbiTKp4pnDaQ3Edd62ZYGqltbn92If2BxwDnJmbW6tuY+qyJJuWS 1yngPKYAcvlE/LtJyWqGcWshloPz+dtcCwrMHUYVy18YRmvFHc5BybYZEFFeL0WM7c8b 8ZQLLEymQcq/3168IvgK3YnsRvM92BzaW53yLtsd3w7dBg8sYhrhhFmNP/G7v2AZIHn6 pCe8jdKpwFxTQ8SuPVxx68VOU4Jl6b2VSFCQNndmdd9UfWQQydpD0jBh54C2O6IIS0h9 munEXWMwsRH0SBmDzZWp7JTKqi9yW5mJpp0Srj80YBwWIrdtrLZJwi+WXujhWsyIf12S ZFyg== X-Gm-Message-State: ALoCoQlDqMiL0IS38ZNWD3d1t66PqUd8IZP+nMPEyCV5da/U6eee5BprStlana14ao9GRJ0M9g4G MIME-Version: 1.0 X-Received: by 10.140.235.71 with SMTP id g68mr40429616qhc.41.1435814373237; Wed, 01 Jul 2015 22:19:33 -0700 (PDT) Received: by 10.96.161.169 with HTTP; Wed, 1 Jul 2015 22:19:33 -0700 (PDT) Date: Wed, 1 Jul 2015 22:19:33 -0700 Message-ID: From: Joseph Salowey To: The IESG , secdir , draft-ietf-tzdist-service.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a1135620eae78140519dd95f3 Archived-At: Subject: [secdir] secdir review of draft-ietf-tzdist-service-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 05:19:35 -0000 --001a1135620eae78140519dd95f3 Content-Type: text/plain; charset=UTF-8 First, I apologize for the late review. It appears that you may have already had a secdir review from the revision notes, but I could not find the review in my archive. In general it seems the document is in good shape and understandable. I think the document is ready with nits. Here are a few minor issues: 1) it might be useful to add something about what is in scope and out of scope for this document. What I have in mind is to state the assumption that the TZ data has been securely transmitted from the contributors to the publishers to the root provider with its integrity intact and that the servers are expected to maintain the integrity of the data. 2) It might be useful to qualify the 3rd paragraph as applicable when discovery is done through DNS SRV records. Cheers, Joe --001a1135620eae78140519dd95f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, I apologize for the late review. It appears that yo= u may have already had a secdir review from the revision notes, but I could= not find the review in my archive. =C2=A0=C2=A0

In gene= ral it seems the document is in good shape and understandable. I think the = document is ready with nits.=C2=A0 Here are a few minor issues:
<= br>
1) it might be useful to add something about what is in scope= and out of scope for this document.=C2=A0 What I have in mind is to state = the assumption that the TZ data has been securely transmitted from the cont= ributors to the publishers to the root provider with its integrity intact a= nd that the servers are expected to maintain the integrity of the data.=C2= =A0

2) It might be useful to qualify the 3rd parag= raph as applicable when discovery is done through DNS SRV records. =C2=A0

Cheers,

Joe
--001a1135620eae78140519dd95f3-- From nobody Wed Jul 1 22:57:27 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15161B2F08; Wed, 1 Jul 2015 22:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDt2f1tZVaz1; Wed, 1 Jul 2015 22:57:22 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0EE91B2F06; Wed, 1 Jul 2015 22:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5635; q=dns/txt; s=iport; t=1435816642; x=1437026242; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=LpQPCLQYWkmMaCCR2/VyVB1NM9GAB3ko+bGDWn24CtU=; b=LMKeNaIzJSfts9SdUt80qEjNLoqRe+xeVHZTTqAbrDkW5ItQ4EEP0AEI zBdbKx3Tpp6CIb4slHjXiHRit7lh3KD6Heeo4Qw6RKIoKOhcz3/1Ui9PB Q3qQAyKldUQNPhPPIpQwcbVmdj69Zf8TCHKgEldN84CKO3iUHQaXXiCe9 M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ByAwDN0ZRV/xbLJq1bh2S6GwmHZgKBfhQBAQEBAQEBgQqEIgEBAQMBI1UGCwsECgoJFgsCAgkDAgECAUUGAQwIAQGIIwi2EJZkAQEBAQEBAQMBAQEBAQEBARqLSoUNgmiBQwEElBCCJ4FRh2mBOoZ/jC+DXSaCDByBVDyCeQEBAQ X-IronPort-AV: E=Sophos;i="5.15,390,1432598400"; d="asc'?scan'208,217";a="552060966" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 02 Jul 2015 05:57:20 +0000 Received: from [10.61.100.74] (dhcp-10-61-100-74.cisco.com [10.61.100.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t625vJGM031269; Thu, 2 Jul 2015 05:57:19 GMT Message-ID: <5594D2BE.8000105@cisco.com> Date: Thu, 02 Jul 2015 07:57:18 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Joseph Salowey , The IESG , secdir , draft-ietf-tzdist-service.all@tools.ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6nCtxXEVnhRbKNo5mRRWsTno2v63B8xkL" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tzdist-service-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 05:57:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6nCtxXEVnhRbKNo5mRRWsTno2v63B8xkL Content-Type: multipart/alternative; boundary="------------070503090904050601020500" This is a multi-part message in MIME format. --------------070503090904050601020500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joe, On 7/2/15 7:19 AM, Joseph Salowey wrote: > First, I apologize for the late review. It appears that you may have > already had a secdir review from the revision notes, but I could not > find the review in my archive. The document did already receive a review several months ago, but thank you anyway for your comments. > > In general it seems the document is in good shape and understandable. > I think the document is ready with nits. Here are a few minor issues: > > 1) it might be useful to add something about what is in scope and out > of scope for this document. What I have in mind is to state the > assumption that the TZ data has been securely transmitted from the > contributors to the publishers to the root provider with its integrity > intact and that the servers are expected to maintain the integrity of > the data. I think what you are asking for is clearly stated in the converse already in the Introduction as follows: > This specification defines a time zone data distribution service > protocol that allows for fast, reliable and accurate delivery of tim= e > zone data and leap second information to client systems.=20 > > 2) It might be useful to qualify the 3rd paragraph as applicable when > discovery is done through DNS SRV records. Perhaps you can provide some small amount of text as to what you are suggesting, keeping in mind that it's rather late in the day for this document. Regards, Eliot --------------070503090904050601020500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joe,

On 7/2/15 7:19 AM, Joseph Salowey wrote:
First, I apologize for the late review. It appears= that you may have already had a secdir review from the revision notes, but I could not find the review in my archive.

The document did already receive a review several months ago, but thank you anyway for your comments.

In general it seems the document is in good shape and understandable. I think the document is ready with nits.=C2=A0 = Here are a few minor issues:

1) it might be useful to add something about what is in scope and out of scope for this document.=C2=A0 What I have in = mind is to state the assumption that the TZ data has been securely transmitted from the contributors to the publishers to the root provider with its integrity intact and that the servers are expected to maintain the integrity of the data.

I think what you are asking for is clearly stated in the converse already in the Introduction as follows:

=C2=A0=C2=A0 This specification defines a t= ime zone data distribution service
=C2=A0=C2=A0 protocol that allows for fast, reliable and accurate d= elivery of time
=C2=A0=C2=A0 zone data and leap second information to client system= s.=C2=A0


2) It might be useful to qualify the 3rd paragraph as applicable when discovery is done through DNS SRV records.

Perhaps you can provide some small amount of text as to what you are suggesting, keeping in mind that it's rather late in the day for this document.

Regards,

Eliot
--------------070503090904050601020500-- --6nCtxXEVnhRbKNo5mRRWsTno2v63B8xkL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVlNK/AAoJEIe2a0bZ0nozHRMIANLeFDbYnoUyJ9g84ktbAMc1 AacgvaetV1vw5USBiCmrysjHnrSUSGisrJGsdmZ+ML+cqpA5O8U27efq0yDW+IBK V6Z3Xxg6DmEUEYFlq5JWeBSJqUu16ndW7/Ybm/tWpjaweL+Z6yA3gSsRiCaF/UpK Ta+FKrlQI9YA1uBbCgRAURGJghShqATTyiqc4VQ5F4R1mEg/A3dvPDO99JHNgNE1 AfdpDp54CkvItWS1ndIP6YyN8++vWckOymShlyKFcoXb+c18U6bkBdLX6tRHi5LM wCgvV/umiWGqaWVF5Nj5xs+lcloRXAujZ48zvY9VJOCszNZur8yts5tKKk7DKcQ= =4QNS -----END PGP SIGNATURE----- --6nCtxXEVnhRbKNo5mRRWsTno2v63B8xkL-- From nobody Thu Jul 2 02:40:24 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521BE1A1A5A; Wed, 1 Jul 2015 21:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTbyW_ITTx1m; Wed, 1 Jul 2015 21:37:15 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0137.outbound.protection.outlook.com [207.46.100.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598B91B2E31; Wed, 1 Jul 2015 21:37:15 -0700 (PDT) Received: from BY2PR05MB791.namprd05.prod.outlook.com (10.141.225.22) by BY2PR05MB791.namprd05.prod.outlook.com (10.141.225.22) with Microsoft SMTP Server (TLS) id 15.1.201.16; Thu, 2 Jul 2015 04:37:13 +0000 Received: from BY2PR05MB791.namprd05.prod.outlook.com ([10.141.225.22]) by BY2PR05MB791.namprd05.prod.outlook.com ([10.141.225.22]) with mapi id 15.01.0201.000; Thu, 2 Jul 2015 04:37:13 +0000 From: Ramdas Machat To: "Fernando Calabria (fcalabri)" , "MORTON, ALFRED C (AL)" , "Xialiang (Frank)" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-bmwg-issu-meth.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-bmwg-issu-meth-01 Thread-Index: AdCznVhNjRYm7y6ZS9SgpDHakbeZ2QAWCOBAAAQtUQAAKndLAA== Date: Thu, 2 Jul 2015 04:37:13 +0000 Message-ID: References: <4AF73AA205019A4C8A1DDD32C034631D0662C6E4BD@NJFPSRVEXG0.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.13] x-microsoft-exchange-diagnostics: 1; BY2PR05MB791; 5:y+k2IQEL+sjBS4Hie3AXc8U0T2cWN45Z/Wlyn6//itRYAULT8Jb6dWOuGXd7kY3ChahDNN2BHwxO9W+p/y5SMmt4g6b/LoMHaQ4AwZaVrwoF6idfyEtlqgmeZw5WYhLGAB0rUdEBLgnLg9NT89c1uw==; 24:wM9btRu6XJ809kXmKpoB/INvs120zfxlOgE9hdD7VfOeb3eQYlrBbUWY1q4MhEr2uE5scUppri8HZnybbq9/fnA/VyVc5Df5GDXtWXpmgR8=; 20:PS5FDtQQ0FZq5HR9IhGbTRzDGq+Y8vbSnaDjgXbnV7CHo8Fv4bbk/9wuZFLvtfWNQ00BZC29+WCX3BMi2X04xw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB791; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2PR05MB791; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB791; x-forefront-prvs: 06259BA5A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(99286002)(19300405004)(50986999)(76176999)(54356999)(230783001)(19625215002)(15187005004)(16236675004)(2201001)(2501003)(66066001)(4001350100001)(5001960100002)(2950100001)(2900100001)(107886002)(102836002)(5001770100001)(15975445007)(77096005)(36756003)(189998001)(5002640100001)(46102003)(83506001)(40100003)(19580405001)(92566002)(19580395003)(77156002)(2656002)(62966003)(87936001)(122556002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB791; H:BY2PR05MB791.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1BABC9116DA5rmachatjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2015 04:37:13.4311 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB791 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 02:40:23 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-bmwg-issu-meth-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 04:37:18 -0000 --_000_D1BABC9116DA5rmachatjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Frank, Thank you for your comments. #1 I agree with Al. ISSU upgrade is a manual procedure, and usually operators = would well prepare for this event. Given this an ISSU upgrade during the Do= S attack is very unlikely done by Operators. #2, #3 It is a valid concern, since the images are huge and bulky, running into in= tegrity and corruption issues are very likely. I conquer with Fernando on h= is response. This has been addressed in section 3.1. -Ramdas From: "Fernando Calabria (fcalabri)" > Date: Wednesday, July 1, 2015 at 6:29 PM To: "MORTON, ALFRED C (AL)" >, "X= ialiang (Frank)" >, "secdir@ietf.org" >, "iesg@ietf.org" >, "draft-ietf-bmwg-issu-meth.all@ietf.org" > Subject: Re: Secdir review of draft-ietf-bmwg-issu-meth-01 Thank you Frank for your review and Al for addressing # 1 and # 4 .. In regards to # 2 and #3 We also saw and considered how verifications like the authenticity of a SW= package may be a concern , even more, nowadays, with emerging SDN like= implementations , Unfortunately not all the vendors nor even software specific operating sy= stems within vendors, have =93consistent implementations" of Digital Si= gnatures nor Certificates and do not make these checks a mandatory task b= efore performing a Software upgrade. Because of it we tried to address it with a =91generic=92 statement on Sec= tions 3.1 and 3.2 that basically read: "Internal compatibility verification may be performed by the software running on the DUT, to verify the checksum of the files downloaded as well as any other pertinent checks. Depending upon vendor implementation, these mechanisms may extend to include verification that the downloaded module(s) =85" =97 Internal compatibility verification may be performed by the software running on the DUT, as part of the upgrade process itself, to verify the checksum of the files downloaded as well as any other pertinent checks=85. The authors of this document understand how these are real issues / concer= ns on managing an operating a Software environment, , but we do not bel= ieve that an specific ISSU document should addresses them in detail -Fernando From: , "ALFRED C (AL)" > Date: Wednesday, July 1, 2015 at 8:08 AM To: "Xialiang (Frank)" >, "secdir@ietf.org" >, "iesg@ietf.org" >, "draft-ietf-bmwg-issu-meth.all@ietf.org" > Subject: RE: Secdir review of draft-ietf-bmwg-issu-meth-01 Hi Frank, Thanks for your review and comments. On #1, DoS attacks: since human control is involved here, it seems unlikely that operators will begin an upgrade during a DoS attack when they know it=92s in-progress, IMO. Others should chime-in if they have other rationale or opinions. On #4, That=92s the draft date, not the expiration date. see below, Al doc shepherd Benchmarking Working Group Sarah Banks Internet Draft VSS Monitoring Intended status: Informational Fernando Calabria Expires: November 30, 2015 Cisco Systems Gery Czirjak Ramdas Machat Juniper Networks May 30, 2015 ISSU Benchmarking Methodology draft-ietf-bmwg-issu-meth-01 From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] Sent: Tuesday, June 30, 2015 9:29 PM To: secdir@ietf.org; iesg@ietf.org; draft-ietf-bmwg-issu-meth.all@ietf.org Subject: Secdir review of draft-ietf-bmwg-issu-meth-01 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comment. This draft specifies a set of common methodologies and procedures designed = to characterize the overall behavior of a Device Under Test (DUT), subject = to an ISSU event. I have the following comments: 1. Should the ISSU test methodology include the verification and test= when the DUT is under network DDoS attacks? 2. In the software download stage, in addition to compatibility check= s and verification of checksums, we should also explicitly mention that the= device should verify the authenticity and integrity of its download. I.e. = verify signatures on signed code and OCSP/CRL for the used signature. And t= hat a system must not load unverified code; 3. even in a test environment all deployed software components must b= e verified (e.g. using signatures); 4. Nits: this draft has expired on May-30, 2015 Recommendation: Ready With Issues B.R. Frank --_000_D1BABC9116DA5rmachatjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Frank,
Thank = you for your comments.
  #1 
I agre= e with Al. ISSU upgrade is a manual procedure, and usually operators would = well prepare for this event. Given this an ISSU upgrade during the DoS atta= ck is very unlikely done by Operators.
#2, #3=
It is = a valid concern, since the images are huge and bulky, running into integrit= y and corruption issues are very likely. I conquer with Fernando on his res= ponse. This has been addressed in section 3.1. 

 =
-Ramdas



Thank you Frank for your review and Al for addressing # 1 and # 4 ..

In regards to # 2 and #3 


We also saw and considered how  verifications like the authentici= ty of a SW package may be a concern , even more,   nowadays,  wit= h emerging SDN  like implementations , 

Unfortunately   not all the vendors nor even software specific op= erating systems  within vendors,  have =93consistent  implem= entations" of  Digital Signatures nor  Certificates and do n= ot make these checks a mandatory task  before performing a Software up= grade.

Because of it  we tried to address it with a =91generic=92 statem= ent on Sections 3.1 and 3.2 that basically read:

"Internal compatibility
   verification may be performed by the software running on = the DUT, to
   verify the checksum of the files downloaded as well as an= y other
   pertinent checks. Depending upon vendor implementation, t= hese
   mechanisms may extend to include verification that the do= wnloaded
   module(s) =85"

=97

Internal compatibility verification may be
   performed by the software running on the DUT, as part of = the upgrade
   process itself, to verify the checksum of the files downl= oaded as
   well as any other pertinent checks=85.



The authors of this document understand  how these are real issue= s / concerns on managing an operating a  Software   environment, = ,  but we do not believe that an specific ISSU  document should a= ddresses them in  detail 

-Fernando 







From: <MORTON>, "ALFRED = C (AL)" <acmorton@att.com&g= t;
Date: Wednesday, July 1, 2015 at 8:= 08 AM
To: "Xialiang (Frank)" &l= t;frank.xialiang@huawei.com>, "secdir@ietf.org" &= lt;secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-bmwg-issu-met= h.all@ietf.org" <draft-ietf-bmwg-issu-meth.all@ietf.org>
Subject: RE: Secdir review of draft= -ietf-bmwg-issu-meth-01

Hi Frank,

Thanks for your review and comments.

 

On #1, DoS attacks: since human control is involved = here,

it seems unlikely that operators will begin an upgra= de

during a DoS attack when they know it=92s in-progres= s, IMO.

Others should chime-in if they have other rationale = or opinions.

 

On #4, That=92s the draft date, not the expiration d= ate.

see below,

Al

doc shepherd

 

Benchmarking Working Group    &n= bsp;            = ;            &n= bsp;    Sarah Banks

Internet Draft      &n= bsp;            = ;            &n= bsp;           VSS Monito= ring

Intended status: Informational   &nbs= p;            &= nbsp;       Fernando Calabria

Expires: November 30, 2015    &n= bsp;            = ;            &n= bsp;  Cisco Systems

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            Ger= y Czirjak

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           Ramdas Ma= chat

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Juniper Networks=

        &nbs= p;            &= nbsp;            &nb= sp;            =             May= 30, 2015

        &nbs= p;            &= nbsp;

ISSU Benchmarking Methodology

draft-ietf-bmwg-issu-meth-01

 

From:<= span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif;"> Xialiang = (Frank) [mailto:frank.xialiang= @huawei.com]
Sent: Tuesday, June 30, 2015 9:29 PM
To: secdir@ietf.org; iesg@ietf.org; draft-ietf-bmwg-issu-meth.all@ietf.org
Subject: Secdir review of draft-ietf-bmwg-issu-meth-01

 =

I have re= viewed this document as part of the security directorate's ongoing eff= ort to review all IETF documents being processed by the IESG.  Th= ese comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs = should treat these comments just like any other last call comment.

&nbs= p;

This draf= t specifies a set of common methodologies and procedures designed to charac= terize the overall behavior of a Device Under Test (DUT), subject to an ISS= U event.

&nbs= p;

I have th= e following comments:

1.       Should the ISSU test methodology include the verification and test when = the DUT is under network DDoS attacks?

2.       In the software download stage, in addition to compatibility checks and = verification of checksums, we should also explicitly mention that the devic= e should verify the authenticity and integrity of its download. I.e. verify signatures on signed code and OCSP/= CRL for the used signature. And that a system must not load unverified code= ;

3.       even in a test environment all deployed software components must be veri= fied (e.g. using signatures);

4.       Nits: this draft has expired on May-30, 2015

&nbs= p;

Recommend= ation:  Ready With Issues

&nbs= p;

B.R.=

Frank

 --_000_D1BABC9116DA5rmachatjunipernet_-- From nobody Thu Jul 2 02:40:26 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB31B3100; Thu, 2 Jul 2015 02:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J63bgw1ybtXE; Thu, 2 Jul 2015 02:25:19 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D4F1B30EC; Thu, 2 Jul 2015 02:25:18 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t629PErG026157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2015 18:25:15 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629PDdB007249; Thu, 2 Jul 2015 18:25:13 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 591; Thu, 2 Jul 2015 18:25:13 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t629PDov007245; Thu, 2 Jul 2015 18:25:13 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id t629PDL0001683; Thu, 2 Jul 2015 18:25:13 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id UAA01675; Thu, 2 Jul 2015 18:25:12 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t629PCcf019752; Thu, 2 Jul 2015 18:25:12 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t629PBGW019145; Thu, 2 Jul 2015 18:25:11 +0900 (JST) Received: from [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8] (unknown [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id B2B9518F4D9; Thu, 2 Jul 2015 18:25:11 +0900 (JST) Message-ID: <55950377.3020000@toshiba.co.jp> Date: Thu, 02 Jul 2015 18:25:11 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: roll@ietf.org, iesg@ietf.org, secdir@ietf.org References: <5BE572AB-D17A-4890-8385-B0F9A16C2A3F@cisco.com> In-Reply-To: <5BE572AB-D17A-4890-8385-B0F9A16C2A3F@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp id t629PDov007245 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 02:40:23 -0700 Cc: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org Subject: Re: [secdir] [Roll] Secdir review of draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 09:25:20 -0000 Brian, Thank you very much for your review. I submitted revised version (-06, no= t -05, sorry for unfixed nits). On 2015-06-26 05:18, Brian Weis (bew) wrote: > 1. Describing a resource consumption threat ("excessive layer-2 > broadcasting=93) resulting from a man-in-the-middle modifying policy > sent within an option. If there is a suggested mitigation (e.g., a > means of integrity protecting the DHCPv6 traffic between the client > and server) this would be worth noting. But I=92m not sure if there > any available mitigation in a ROLL environment. I added some text on network level protection case in addition to use of = DHCPv6 security, including filter on the border router in a ROLL network. > 2. Making a requirement that a server implementation choose > reasonable policy values. This might be more useful if it were > phrased as a threat, something like =93Server implementations need to > take care in setting reasonable bounds for each parameter in order to > avoid overloading the network." Thanks. I used your text with 'server and client implementations.' > 3. Making a requirement that the "DHCP server or the network itself > shall be trusted by some means including network access control or > DHCP authentication=94. Is this this =93shall=94 intended to be an RFC > 2119 =93MUST=94? No. I think making secure network properly to use DHCPv6 option is just a= generic requirement and it's beyond the scope of this document. Best Regards, Yusuke From nobody Thu Jul 2 07:59:10 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08751A8A6D for ; Thu, 2 Jul 2015 07:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYw8LE8p206P for ; Thu, 2 Jul 2015 07:59:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD421A8A8B for ; Thu, 2 Jul 2015 07:59:01 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t62EwwB1005309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 2 Jul 2015 17:58:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t62EwwBD019649; Thu, 2 Jul 2015 17:58:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21909.20914.175931.377652@fireball.kivinen.iki.fi> Date: Thu, 2 Jul 2015 17:58:58 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 14:59:08 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Phillip Hallam-Baker is next in the rotation. For telechat 2015-07-09 Reviewer LC end Draft Shaun Cooley T 2015-07-02 draft-ietf-appsawg-text-markdown-08 Chris Lonvick TR2015-06-09 draft-ietf-6lo-btle-14 Matthew Miller T 2015-06-11 draft-ietf-homenet-prefix-assignment-07 Takeshi Takahashi T 2015-07-03 draft-ietf-karp-isis-analysis-06 Sean Turner T 2015-06-29 draft-ietf-dhc-dhcpv6-active-leasequery-03 David Waltermire T 2015-06-29 draft-ietf-pcp-authentication-12 Sam Weiler T 2015-06-29 draft-ietf-pcp-proxy-08 For telechat 2015-08-05 Tina TSOU T 2015-06-24 draft-ietf-dane-ops-13 Last calls and special requests: John Bradley 2015-07-08 draft-ietf-xmpp-posh-04 Dave Cridland 2015-07-27 draft-bradner-iaoc-terms-01 Alan DeKok 2015-07-09 draft-ietf-intarea-gre-ipv6-10 Donald Eastlake 2015-07-13 draft-ietf-6man-ipv6-address-generation-privacy-07 Shawn Emery 2015-07-10 draft-ietf-precis-nickname-18 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Olafur Gudmundsson 2015-07-29 draft-mm-netconf-time-capability-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Hannes Tschofenig 2015-07-07 draft-wkumari-dhc-capport-13 Carl Wallace 2015-06-29 draft-ietf-ipsecme-chacha20-poly1305-10 Tom Yu 2015-07-02 draft-ietf-grow-filtering-threats-06 Dacheng Zhang 2015-07-08 draft-ietf-opsec-ipv6-host-scanning-07 -- kivinen@iki.fi From nobody Thu Jul 2 21:09:42 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22B51B2B3B; Thu, 2 Jul 2015 21:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUfyly_BRqrS; Thu, 2 Jul 2015 21:09:38 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2970A1A9250; Thu, 2 Jul 2015 21:09:38 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id t6349aUU022953; Fri, 3 Jul 2015 13:09:36 +0900 (JST) Received: from TakeVaioVJP13 (vrrp.ssh.nict.go.jp [133.243.3.48] (may be forged)) by gw2.nict.go.jp with ESMTP id t6349Zt5022937; Fri, 3 Jul 2015 13:09:35 +0900 (JST) From: "Takeshi Takahashi" To: Date: Fri, 3 Jul 2015 13:09:44 +0900 Message-ID: <005801d0b546$17c06f90$47414eb0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdC1RZp1NKJ94rslRLaB6U6NutZdxQ== Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.5 at zenith2 X-Virus-Status: Clean Archived-At: Cc: karp-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: [secdir] Secdir review of draft-ietf-karp-isis-analysis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 04:09:39 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication. [summary of this document] This document analyzes the threats of IS-IS protocol. It first summarizes the current state of the IS-IS protocol, with special focus on key usage and key management (in section 2), and then analyzes the security gaps in order to identify security requirements (in section 3). In the summary of the current state of the protocol (section 2), it already mentioned the threats of the protocol, i.e. replay attack and spoofing attack, for each of the three message types of IS-IS protocol. Section 3 summarizes, organizes, and develops the threat analysis and provides candidate direction to cope with the threats by listing requirements and by listing related I-D works. [minor comment] As mentioned in the security consideration section, this draft does not modify any of the existing protocols. It thus does not produce any new security concerns. So, the security consideration section seems adequate. The authors could consider citing RFC 5310 in Section 5, since I feel like that this draft does not discuss all the content of the consideration section of the rfc (it does discuss major parts of the section, though). Cheers, Take From nobody Fri Jul 3 06:39:44 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6228F1B2FDB; Fri, 3 Jul 2015 06:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-GbcGOZLRAv; Fri, 3 Jul 2015 06:39:42 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30311B2FB5; Fri, 3 Jul 2015 06:39:41 -0700 (PDT) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id t63Dddkn026253; Fri, 3 Jul 2015 22:39:39 +0900 (JST) Received: from TakeVaioVJP13 (vrrp.ssh.nict.go.jp [133.243.3.48] (may be forged)) by gw1.nict.go.jp with ESMTP id t63DdcwN026250; Fri, 3 Jul 2015 22:39:39 +0900 (JST) From: "Takeshi Takahashi" To: References: In-Reply-To: Date: Fri, 3 Jul 2015 22:39:47 +0900 Message-ID: <006f01d0b595$baae8b20$300ba160$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdC1RZp1NKJ94rslRLaB6U6NutZdxQAT8Zqg Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.5 at zenith1 X-Virus-Status: Clean Archived-At: Cc: karp-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-karp-isis-analysis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 13:39:43 -0000 Let me add one more comment here. We could probably discourage the use of HMAC-MD5, and encourage the use of HMAC-SHA family instead. Take > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Friday, July 3, 2015 1:10 PM > To: 'draft-ietf-karp-isis-analysis.all@tools.ietf.org' > Cc: 'iesg@ietf.org'; 'secdir@ietf.org'; 'karp-chairs@tools.ietf.org' > Subject: Secdir review of draft-ietf-karp-isis-analysis-04 > > Hello, > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > This document is ready for publication. > > [summary of this document] > > This document analyzes the threats of IS-IS protocol. > It first summarizes the current state of the IS-IS protocol, with special focus > on key usage and key management (in section 2), and then analyzes the security > gaps in order to identify security requirements (in section 3). > > In the summary of the current state of the protocol (section 2), it already > mentioned the threats of the protocol, i.e. replay attack and spoofing attack, > for each of the three message types of IS-IS protocol. > Section 3 summarizes, organizes, and develops the threat analysis and provides > candidate direction to cope with the threats by listing requirements and by > listing related I-D works. > > [minor comment] > > As mentioned in the security consideration section, this draft does not modify > any of the existing protocols. > It thus does not produce any new security concerns. > So, the security consideration section seems adequate. > The authors could consider citing RFC 5310 in Section 5, since I feel like that > this draft does not discuss all the content of the consideration section of > the rfc (it does discuss major parts of the section, though). > > Cheers, > Take > From nobody Sun Jul 5 06:47:09 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E591A88EF; Sun, 5 Jul 2015 06:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.291 X-Spam-Level: **** X-Spam-Status: No, score=4.291 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEEmQueKkTTH; Sun, 5 Jul 2015 06:47:05 -0700 (PDT) Received: from BLU004-OMC2S21.hotmail.com (blu004-omc2s21.hotmail.com [65.55.111.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E6F1A8880; Sun, 5 Jul 2015 06:47:01 -0700 (PDT) Received: from BLU436-SMTP157 ([65.55.111.72]) by BLU004-OMC2S21.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 5 Jul 2015 06:47:00 -0700 X-TMN: [FvjhkNSz7euSCW/RyzCoUKiqsKONGQIX] X-Originating-Email: [zhang_dacheng@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_8170D665-0530-4692-A2FD-A72FCE65A8A3" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dacheng In-Reply-To: Date: Sun, 5 Jul 2015 21:46:49 +0800 References: To: "secdir@ietf.org" , "iesg@ietf.org" X-Mailer: Apple Mail (2.1878.6) X-OriginalArrivalTime: 05 Jul 2015 13:46:59.0573 (UTC) FILETIME=[10B73A50:01D0B729] Archived-At: Cc: "draft-ietf-opsec-ipv6-host-scanning.all@ietf.org" Subject: [secdir] =?gb2312?b?U2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW9wc2Vj?= =?gb2312?b?LWlwdjYtaG9zdC1zY2FubmluZ6OtMDc=?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 13:47:06 -0000 --Apple-Mail=_8170D665-0530-4692-A2FD-A72FCE65A8A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="GB2312" I have reviewed this document as part of the security directorate=A1=AFs = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document explores the topic of Network Reconnaissance in IPv6 = networks. It analyzes the feasibility of address-scan attacks in IPv6 = networks in different scenarios and proposes comments to mitigate to = certain issues.=20 Follows are two comments: 1) There are overlaps in the contents of the security consideration and = conclusions. Maybe it is reasonable to integrate the the conclusions = into security considerations. In addition, the security consideration = section is normally about the new issues or concerns raised by the = proposed work. However, this memo does not propose any new mechanism and = so introduce no security vulnerability. I suggest the authors clarify = this in the security consideration section.=20 2) There is a very big section and a lot of short sections. I suggest to = combine sections 4-14 into a single one to make the lengths of different = sections more balanced.=20 Anyway, the analysis in this work is quite extensive. I really enjoy = reading it. I think this document is nearly ready for publication with = some tiny modifications.=20 Cheers Dacheng --Apple-Mail=_8170D665-0530-4692-A2FD-A72FCE65A8A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="GB2312"
I have reviewed this document = as part of the security directorate=A1=AFs ongoing effort to review = all IETF documents being processed by the IESG. These comments were = written primarily for the benefit of the security area directors. =  Document editors and WG chairs should treat these comments = just like any other last call comments.

This document explores the =
topic of Network Reconnaissance in IPv6 networks. It analyzes the =
feasibility of address-scan attacks in IPv6 networks in different =
scenarios and proposes comments to mitigate to certain issues. =

Follows are =
two comments:
1) There are overlaps in the contents of the security =
consideration and conclusions. Maybe it is reasonable to integrate the =
the conclusions into security considerations. In addition, the security =
consideration section is normally about the new issues or concerns =
raised by the proposed work. However, this memo does not propose any new =
mechanism and so introduce no security vulnerability. I suggest the =
authors clarify this in the security consideration section. =
2) There is a very big section and a lot of short sections. I = suggest to combine sections 4-14 into a single one to make the lengths = of different sections more balanced. 
Anyway,  the  analysis in this =
work is quite extensive. I really enjoy reading it. I think this =
document is nearly ready for publication with some tiny modifications. =

Cheers
Dacheng


= --Apple-Mail=_8170D665-0530-4692-A2FD-A72FCE65A8A3-- From nobody Sun Jul 5 12:09:01 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1421ACDEA for ; Sun, 5 Jul 2015 12:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xya4v8BCjEjk for ; Sun, 5 Jul 2015 12:08:56 -0700 (PDT) Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02861ACDE5 for ; Sun, 5 Jul 2015 12:08:55 -0700 (PDT) Received: by qkeo142 with SMTP id o142so104964226qke.1 for ; Sun, 05 Jul 2015 12:08:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xP1uwdyQYJ/IrUdwSQ6S2rL+CzXqJ/i5cOd8LdNhtXE=; b=l3C2N8d5EClJzy8cQG/i+6AMXgV6kJ06G5SMdCiNGnkL8nk8H87Y1nl7He7w//qnMP zng3GGufAn6KmjQiz5+DdhcnDrOC9sbasihE5NWE6okJmtAdGJJa48I9D1p1jgPjezsD eQwMtP+KiLfTh/HzwIfRWTSow7q61Jj/A+AC6SbI9T9jLWrMmsc8IgS9kHgENzoLELSz tCD7nuobgQp5b6uCiVbzGG52GNlLJ3OQkh+Gr7qQAwb4dagIzG7joSpddY2kU6Ghkjqh np1U3Sp6nJ44cW4YtBloNanxA5vqZP7D6QX+aW6p4dXMo24br9t5Bntyj11URNQkNLj6 7omg== X-Gm-Message-State: ALoCoQm1ZMD04RSR7nFFwYXcrart5C8lCWz3ewAtIBHZHK+pCgaysSBh6O1WN0FlqrP6c8yG9arl MIME-Version: 1.0 X-Received: by 10.140.104.147 with SMTP id a19mr68394425qgf.71.1436123335033; Sun, 05 Jul 2015 12:08:55 -0700 (PDT) Received: by 10.96.161.169 with HTTP; Sun, 5 Jul 2015 12:08:54 -0700 (PDT) In-Reply-To: <5594D2BE.8000105@cisco.com> References: <5594D2BE.8000105@cisco.com> Date: Sun, 5 Jul 2015 12:08:54 -0700 Message-ID: From: Joseph Salowey To: Eliot Lear Content-Type: multipart/alternative; boundary=001a1134f58e3d2d84051a2585d2 Archived-At: Cc: draft-ietf-tzdist-service.all@tools.ietf.org, The IESG , secdir Subject: Re: [secdir] secdir review of draft-ietf-tzdist-service-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 19:08:57 -0000 --001a1134f58e3d2d84051a2585d2 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 1, 2015 at 10:57 PM, Eliot Lear wrote: > Hi Joe, > > On 7/2/15 7:19 AM, Joseph Salowey wrote: > > First, I apologize for the late review. It appears that you may have > already had a secdir review from the revision notes, but I could not find > the review in my archive. > > > The document did already receive a review several months ago, but thank > you anyway for your comments. > > > In general it seems the document is in good shape and understandable. I > think the document is ready with nits. Here are a few minor issues: > > 1) it might be useful to add something about what is in scope and out of > scope for this document. What I have in mind is to state the assumption > that the TZ data has been securely transmitted from the contributors to the > publishers to the root provider with its integrity intact and that the > servers are expected to maintain the integrity of the data. > > > I think what you are asking for is clearly stated in the converse already > in the Introduction as follows: > > This specification defines a time zone data distribution service > protocol that allows for fast, reliable and accurate delivery of time > zone data and leap second information to client systems. > > > [Joe] I'm OK with this. > > 2) It might be useful to qualify the 3rd paragraph as applicable when > discovery is done through DNS SRV records. > > > Perhaps you can provide some small amount of text as to what you are > suggesting, keeping in mind that it's rather late in the day for this > document. > > [Joe] Sure, how about: "A malicious attacker with access to the DNS server data, or able to get spoofed answers cached in a recursive resolver, can potentially cause clients to connect to any server chosen by the attacker. When performing DNS SRV based discovery in the absence of a secure DNS option, clients SHOULD check that the..." > Regards, > > > --001a1134f58e3d2d84051a2585d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 1, 2015 at 10:57 PM, Eliot Lear <lear@cisco.com> wrote:
=20 =20 =20
Hi Joe,

On 7/2/15 7:19 AM, Joseph Salowey wrote:
=20
First, I apologize for the late review. It appears that you may have already had a secdir review from the revision notes, but I could not find the review in my archive.

 The document did already receive a review several months ago, but thank you anyway for your comments.

In general it seems the document is in good shape and understandable. I think the document is ready with nits.=C2=A0 He= re are a few minor issues:

1) it might be useful to add something about what is in scope and out of scope for this document.=C2=A0 What I have in mi= nd is to state the assumption that the TZ data has been securely transmitted from the contributors to the publishers to the root provider with its integrity intact and that the servers are expected to maintain the integrity of the data.

I think what you are asking for is clearly stated in the converse already in the Introduction as follows:

=C2=A0=C2=A0 This specification defines a tim= e zone data distribution service
=C2=A0=C2=A0 protocol that allows for fast, reliable and accurate del= ivery of time
=C2=A0=C2=A0 zone data and leap second information to client systems.= =C2=A0

[Joe] =C2=A0I'm OK with this.=C2= =A0
=C2=A0

2) It might be useful to qualify the 3rd paragraph as applicable when discovery is done through DNS SRV records.

 Perhaps you can provide some small amount of text as to what you are suggesting, keeping in mind that it's rather late in the day for this document.


[Joe] Sure, how about:
=

=C2=A0"A malicious attacker with access to the DNS server data, o= r able to=C2=A0get spoofed answers cached in a recursive resolver, can potentia= lly=C2=A0cause clients to connect= to any server chosen by the attacker.=C2=A0= When=C2=A0performing DNS SRV base= d discovery in the absence of a secure DNS option, clients SHOULD check that th= e..."


=C2=A0
Regards,



--001a1134f58e3d2d84051a2585d2-- From nobody Sun Jul 5 17:53:48 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480911B29D3; Sun, 5 Jul 2015 17:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpyYAjghfpFL; Sun, 5 Jul 2015 17:53:44 -0700 (PDT) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4F91B29D5; Sun, 5 Jul 2015 17:53:41 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id A2BE846BB5; Sun, 5 Jul 2015 20:53:40 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.9/8.14.9) with ESMTP id t660reQN083464; Sun, 5 Jul 2015 20:53:40 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.9/8.14.9/Submit) with ESMTP id t660reKm083461; Sun, 5 Jul 2015 20:53:40 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 5 Jul 2015 20:53:40 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org, iesg@ietf.org, draft-ietf-pcp-proxy@tools.ietf.org Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Sun, 05 Jul 2015 20:53:40 -0400 (EDT) Archived-At: Subject: [secdir] secdir review of draft-ietf-pcp-proxy-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 00:53:45 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: document is ready for publication (with mild reservation). My thanks to the document editors for producing a readable document. Mild reservation: when I look at the use cases for PCP Proxy in this document (e.g. a consumer router doing NAT, connected to hotel NAT, connected to carrier NAT), it's hard to imagine that operational environment often fitting within the description of PCP's "simple threat model" (RFC6887, section 18.1). And once you reject the simplifying assumptions in that "simple threat model", RFC6877 says PCP needs a security mechanism (section 18.2 of RFC6877). Maybe this document should explicity reinforce that need, perhaps citing and blocking on draft-ietf-pcp-authentication? From nobody Sun Jul 5 22:41:38 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D201A87AC for ; Sun, 5 Jul 2015 22:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjoqC2kGTfTh for ; Sun, 5 Jul 2015 22:41:35 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647131A87AA for ; Sun, 5 Jul 2015 22:41:35 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t665fY47001320 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Jul 2015 05:41:34 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t665fWAO018197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Jul 2015 05:41:34 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t665fWcX025029; Mon, 6 Jul 2015 05:41:32 GMT Received: from [10.154.102.248] (/10.154.102.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 05 Jul 2015 22:41:32 -0700 Message-ID: <559A155B.6080505@oracle.com> Date: Sun, 05 Jul 2015 23:42:51 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: secdir@ietf.org References: <554FE6F0.7000908@oracle.com> In-Reply-To: <554FE6F0.7000908@oracle.com> X-Forwarded-Message-Id: <554FE6F0.7000908@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: draft-ietf-precis-nickname.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-precis-nickname-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 05:41:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft provides guidance on how to process Unicode string nicknames. The security considerations section does exist and refers to the PRECIS framework's security consideration in relation to this draft's use of the string class "FreeformClass" and visually similar characters. UTS #39 is also referenced for security considerations of Unicode characters in general and of visually similar characters. I agree that the references adequately covers considerations for nicknames in Unicode strings. General comments: None. Editorial comments: None. Shawn. -- From nobody Sun Jul 5 22:48:48 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4DA1A87CB; Sun, 5 Jul 2015 22:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCTF-2DnR_zm; Sun, 5 Jul 2015 22:48:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BD91A87B3; Sun, 5 Jul 2015 22:48:37 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 9DE8D2ACB0F; Mon, 6 Jul 2015 07:48:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 7B1E3C805C; Mon, 6 Jul 2015 07:48:33 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Mon, 6 Jul 2015 07:48:33 +0200 From: To: Samuel Weiler , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-pcp-proxy@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-pcp-proxy-08 Thread-Index: AQHQt4Y9L/3mYbO23E6RJFYfa2cppp3N6zZQ Date: Mon, 6 Jul 2015 05:48:32 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933005355010@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.6.52416 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-pcp-proxy-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 05:48:39 -0000 Dear Samuel, Many thanks for the review.=20 FWIW, PCP auth is not cited in this document because we followed the same a= pproach as in RFC6887 and RFC6970.=20 Blocking on draft-ietf-pcp-authentication is not justified IMHO because the= proxy can be enabled with ACLs enabled at the client, server and the netwo= rk in between.=20 Cheers, Med > -----Message d'origine----- > De=A0: Samuel Weiler [mailto:weiler@watson.org] > Envoy=E9=A0: lundi 6 juillet 2015 02:54 > =C0=A0: secdir@ietf.org; iesg@ietf.org; draft-ietf-pcp-proxy@tools.ietf.o= rg > Objet=A0: secdir review of draft-ietf-pcp-proxy-08 >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > Summary: document is ready for publication (with mild reservation). >=20 > My thanks to the document editors for producing a readable document. >=20 > Mild reservation: when I look at the use cases for PCP Proxy in this > document (e.g. a consumer router doing NAT, connected to hotel NAT, > connected to carrier NAT), it's hard to imagine that operational > environment often fitting within the description of PCP's "simple > threat model" (RFC6887, section 18.1). And once you reject the > simplifying assumptions in that "simple threat model", RFC6877 says > PCP needs a security mechanism (section 18.2 of RFC6877). Maybe this > document should explicity reinforce that need, perhaps citing and > blocking on draft-ietf-pcp-authentication? From nobody Mon Jul 6 04:14:25 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DC51A01EA; Mon, 6 Jul 2015 04:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtG4B2aG8OIa; Mon, 6 Jul 2015 04:14:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545BD1A01AA; Mon, 6 Jul 2015 04:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1165; q=dns/txt; s=iport; t=1436181260; x=1437390860; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=QK5rO32vETeTyNSZifUy7m8vvs9C23WYBP0PAkRyJBE=; b=CloC+cU6PHv3EOUjxkCCgtYAq10mcwmjB9lPdrFh56wF+7Kbyz/bpu2q hz4veLWAQVwG8Z9VgjuA1vgRghg/5V/KRAC1F66hgcCt1EZf5CnnfHnMi e0KVWrP3lF0c/9Pi7L1xLOXgUwJ0F+wn2SO1/NtGKMWMA1MCNGbIvAvor U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CsBwCRYppV/51dJa1cgxJUYAaDGbo3CYFmhy04FAEBAQEBAQGBCkEFhAcPAUU2AgUWCwILAwIBAgE1FgEMBgIBAYgqskmVcgEBAQEBBQEBAQEBARgEgSGSH4FDBY0IhCmCZIRihwaIPJAaJoILHYFyUIFHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,414,1432598400"; d="scan'208";a="9194641" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 06 Jul 2015 11:14:19 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t66BEIId017768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jul 2015 11:14:18 GMT Received: from [10.89.10.75] (10.89.10.75) by xhc-aln-x02.cisco.com (173.36.12.76) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 6 Jul 2015 06:14:18 -0500 Message-ID: <559A6311.3060202@cisco.com> Date: Mon, 6 Jul 2015 05:14:25 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: , IETF Security Directorate , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.89.10.75] Archived-At: Subject: [secdir] SecDir Review of draft-ietf-homenet-prefix-assignment-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:14:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments that arrive in timely manner, and not significantly belated. OVERALL: This document is ready. DETAILS: I have no concerns with the document. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVmmMQAAoJEDWi+S0W7cO1ymgH/172NQtXs8EvTJqyE2cYh/pB adtM16jNMyF23to2eMgrBiIkYK/+FSD1JjoJNM6a10GYLbqdtO3gA2QJoqlsgtYv UMt2qoVrpata7KL/ls6D2NymmIT+v5byEBguanNwKWmUASIOYatJi7YK2CmOPurR 1LLH3OqBxkryCPanSsMgpzTevd51sowVIsJy3KFnnEx49N4h3NCNx5QK961KxCTC MJm9DBJutvbgCdxsDtyYwMlaQCkF3tggZMOKC7vKGRjq1egQ960KfBJA08PKnuSv DlhZGYYqBQtCL7Q/dTtP8o1O18QVfhm8n66HFXWekNZ+RwZqsM31uilMc6a8zME= =e7Ku -----END PGP SIGNATURE----- From nobody Mon Jul 6 04:29:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF6B1A8876; Mon, 6 Jul 2015 04:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaGBYAp7VrLW; Mon, 6 Jul 2015 04:29:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29771A0276; Mon, 6 Jul 2015 04:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1316; q=dns/txt; s=iport; t=1436182180; x=1437391780; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=hQful7zokYZfgrdlpmYUT8BwM8qdAhpVP4QaLWmQUIo=; b=biwqldnVTqt3NZkyOx7KsUffaXJZ+7hfgnT7b45M32yAWn9+73h6OtJ8 NclrxWx1qInOhrkCMohfb3QEmTtEFfSw4JcSPinQZ1dXp8avIpR49w0Wm gYz0w4gs8T5pep/nogz8hPv4gPNXW8ikYKKTHRjkUwva/unZMCtMFZpDK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DxAwAvZZpV/40NJK1cgxJUYAaDGbo3CYFmhy44FAEBAQEBAQGBCoRNVTYCBRYLAgsDAgECATUWAQwGAgEBiCqyWZVyAQEBAQEBBAEBAQEBARgEgSGOTREBg0CBQwWNCIQpgmSEYocGgTqEFYJtkBomggsdgXJQgQ06gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,414,1432598400"; d="scan'208";a="12937377" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jul 2015 11:29:40 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t66BTdE9021021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jul 2015 11:29:40 GMT Received: from [10.89.10.75] (10.89.10.75) by xhc-aln-x02.cisco.com (173.36.12.76) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 6 Jul 2015 06:29:39 -0500 Message-ID: <559A66A3.4010006@cisco.com> Date: Mon, 6 Jul 2015 05:29:39 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: The IESG , IETF Security Directorate , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.89.10.75] Archived-At: Subject: [secdir] SecDir Review of draft-ietf-homenet-prefix-assignment-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:29:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [ resending with the correct email addresses. Please ignore any previous message from me with the same subject. My apologies for the confusion ] Hello all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments that arrive in timely manner, and not significantly belated. OVERALL: This document is ready. DETAILS: I have no concerns with the document. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVmmajAAoJEDWi+S0W7cO17akIAJTj1KPO3TjzeZIJ2KLsgwVM 6L3WhnE0Yr24fBwg+NoDVVX1ZbRtDQ8SGElR64UvuRZ3WGvw3JHTqhS0IdEIVNij dX75e+tMTCQULJIJSNTSh/OkyymK1/78mYB2OimlVm3gFWtuGgzHz+gSk4k4KAbV UItoSMhBU3BuMQVLTezJ9WD1GDck7yVlaV3wc25AiT0hGfIu6HirokD+fb1cFVhj Ay/meYdcY28Nnd5TfHYCcYLMUbA/G0HT3g36mTjgbwaeS+3yFXihBR0mjn59A6zx m21fzsI6gFSeH9W03Ub2NwX01666RwYBB09jxFt8tpTX0iW3Osz/RNPnylOefaM= =23Oa -----END PGP SIGNATURE----- From nobody Mon Jul 6 09:03:20 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1501A90A6; Mon, 6 Jul 2015 09:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKUlx12hSpx3; Mon, 6 Jul 2015 09:03:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1591A1A89A8; Mon, 6 Jul 2015 09:03:12 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t66G32c2019216 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 6 Jul 2015 11:03:03 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <559AA6B2.3@nostrum.com> Date: Mon, 06 Jul 2015 11:02:58 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Takeshi Yoshino References: <558B1E9C.8080505@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070408070604080409070400" Archived-At: Cc: draft-ietf-hybi-permessage-compression.all@ietf.org, hybi@ietf.org, "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 16:03:19 -0000 This is a multi-part message in MIME format. --------------070408070604080409070400 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit (adding the hybi list) It seems to me that this effectively adding an actor (the intermediary) , and defining (not as explicitly as I think it needs to be) protocol mechanics for that actor in ways that the base specification did not anticipate. I'm not comfortable that the consequences of these new mechanics (specifically - that the intermediary can directly participate in the extension negotiations, and change the results) are well understood. The additions to the text you propose will certainly help point out that there might be some, and the message that the endpoint won't have insight into how its messages are handled beyond the intermediary needs to be prominent. But I wonder if the mechanics of an intermediary _changing the protocol signalling_ is something the working group should explicitly work on writing down? RjS On 6/30/15 3:42 AM, Takeshi Yoshino wrote: > Thank you for review, Robert. > > On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks > wrote: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: Ready with issues > > (fwiw, I also reviewed up through version -24). > > Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other. > (If that's not what it's trying to set up, please clarify). > > OK. So, I'd like to change the text as follows: > > When an intermediary proxies ... Per-message Compression of messages > received from one peer, and then forward the messages to the other > peer, if the intermediary ... > > It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that? > Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently. > > It's not well discussed in RFC6455. Right. AFAIK, there's no such > extension defined, yet. > > I understand that this text (intermediary section in the I-D) works > just not to disallow change of compression but there's nothing in > RFC6455 that guarantees that such transformation doesn't cause any > issue with other infrastructure of the WebSocket protocol. > > I believe that unless any extension that interferes with the other > negotiated extensions (e.g. counting the number of negotiated > extensions, relying on PMCE, etc.), the core WebSocket protocol > (things defined in RFC6455) should work. If such an extension is > introduced, it would be just considered to be incompatible with PMCEs, > or that extension should describe how to coordinate with change on > PMCE in the intermediaries section of its RFC. > > I think this is more reasonable than prohibiting change on Per-message > Compression by intermediaries. > > This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document? > > Ah, right. Maybe some text like: > > "It's not guaranteed that the PMCE which an endpoint has negotiated in > the opening handshake is preserved in the whole path to the peer > endpoint." > > It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected. > > > As a general discussion to cover other extensions (if they want. by > referring to this to-be-RFC) like the section defining terms to > complement RFC6455 [1]? > > [1] > https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-24#section-3 --------------070408070604080409070400 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit (adding the hybi list)

It seems to me that this effectively adding an actor (the intermediary) , and defining (not as explicitly as I think it needs to be) protocol mechanics for that actor in ways that the base specification did not anticipate.

I'm not comfortable that the consequences of these new mechanics (specifically - that the intermediary can directly participate in the extension negotiations, and change the results) are well understood. The additions to the text you propose will certainly help point out that there might be some, and the message that the endpoint won't have insight into how its messages are handled beyond the intermediary needs to be prominent.

But I wonder if the mechanics of an intermediary _changing the protocol signalling_ is something the working group should explicitly work on writing down?

RjS

On 6/30/15 3:42 AM, Takeshi Yoshino wrote:
Thank you for review, Robert.

On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: Ready with issues

(fwiw, I also reviewed up through version -24).

Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other.
(If that's not what it's trying to set up, please clarify).
OK. So, I'd like to change the text as follows:

When an intermediary proxies ... Per-message Compression of messages received from one peer, and then forward the messages to the other peer, if the intermediary ...
 
It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that?
Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently.
It's not well discussed in RFC6455. Right. AFAIK, there's no such extension defined, yet.

I understand that this text (intermediary section in the I-D) works just not to disallow change of compression but there's nothing in RFC6455 that guarantees that such transformation doesn't cause any issue with other infrastructure of the WebSocket protocol.

I believe that unless any extension that interferes with the other negotiated extensions (e.g. counting the number of negotiated extensions, relying on PMCE, etc.), the core WebSocket protocol (things defined in RFC6455) should work. If such an extension is introduced, it would be just considered to be incompatible with PMCEs, or that extension should describe how to coordinate with change on PMCE in the intermediaries section of its RFC.

I think this is more reasonable than prohibiting change on Per-message Compression by intermediaries.
This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document?
Ah, right. Maybe some text like:

"It's not guaranteed that the PMCE which an endpoint has negotiated in the opening handshake is preserved in the whole path to the peer endpoint."
 
It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected.

As a general discussion to cover other extensions (if they want. by referring to this to-be-RFC) like the section defining terms to complement RFC6455 [1]?

 

--------------070408070604080409070400-- From nobody Mon Jul 6 11:39:44 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA611B2FE1; Mon, 6 Jul 2015 11:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npnhs57va7oH; Mon, 6 Jul 2015 11:39:41 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997261B2FCC; Mon, 6 Jul 2015 11:39:41 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZCBIn-0006sY-1A; Mon, 06 Jul 2015 20:39:37 +0200 Message-ID: <559ACB32.3060609@si6networks.com> Date: Mon, 06 Jul 2015 15:38:42 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dacheng , "secdir@ietf.org" , "iesg@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-opsec-ipv6-host-scanning.all@ietf.org" Subject: Re: [secdir] =?utf-8?q?Secdir_review_of_draft-ietf-opsec-ipv6-host-sc?= =?utf-8?b?YW5uaW5n77yNMDc=?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:39:43 -0000 Hi, Dacheng, Thanks so much for your feedback! Please find my comments in-line.... On 07/05/2015 10:46 AM, Dacheng wrote: > > Follows are two comments: > > 1) There are overlaps in the contents of the security consideration > and conclusions. It would seem that we could move the "Conclusions" section as Section 3.6? (Tim?) Some overlap is usually fine, anyway -- particularly with the Intro and Sec Cons sections... > Maybe it is reasonable to integrate the the > conclusions into security considerations. In addition, the security > consideration section is normally about the new issues or concerns > raised by the proposed work. However, this memo does not propose any > new mechanism and so introduce no security vulnerability. I suggest > the authors clarify this in the security consideration section. How about changing the fist sentence of the Sec Cons section to: " This document explores the topic of Network Reconnaissance in IPv6 networks, but does not introduce any new security issues." -- although one might argue that we do introduce new *concerns*. > 2) There is a very big section and a lot of short sections. I suggest > to combine sections 4-14 into a single one to make the lengths of > different sections more balanced. The sections have been split on a "topic" rather than "length" basis. While the length is unbalanced, it makes it easy to reference each specific reconnaissance technique (e.g., from the table earlier in the document). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 6 12:55:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC81B1B3169; Mon, 6 Jul 2015 12:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqowKStYcOfq; Mon, 6 Jul 2015 12:55:39 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637FF1B316B; Mon, 6 Jul 2015 12:55:35 -0700 (PDT) X-AuditID: c6180641-f794d6d000001dfb-82-559a75f923de Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 03.BA.07675.9F57A955; Mon, 6 Jul 2015 14:35:06 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Mon, 6 Jul 2015 15:55:32 -0400 From: Uma Chunduri To: Takeshi Takahashi , "draft-ietf-karp-isis-analysis.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-karp-isis-analysis-04 Thread-Index: AdC1RZp1NKJ94rslRLaB6U6NutZdxQAT8ZqgAKKxUJA= Date: Mon, 6 Jul 2015 19:55:32 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F749A8C@eusaamb105.ericsson.se> References: <006f01d0b595$baae8b20$300ba160$@nict.go.jp> In-Reply-To: <006f01d0b595$baae8b20$300ba160$@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXSPt+6v0lmhBm9O8Fr8+buF2WLGn4nM FnPfXmS3+LDwIYvF4v5QB1aPJUt+Mnm8OLqd3ePL5c9sAcxRXDYpqTmZZalF+nYJXBm9M+4y FayXqHjZ3s3ewPhKuIuRk0NCwESia9EMJghbTOLCvfVsXYxcHEICRxklNr5czQzhLGOU2Plu BiNIFZuAnsTHqT/ZQWwRgfmMEi93JoLYzAKtjBLXNml1MXJwCAvYSRzvlYQosZeY0XeUDcK2 krj+9TZYK4uAisSSpX8ZQcp5BXwlJm30AAkLCVhInG3sA7uHU8BSovXRC2YQmxHotu+n1jBB bBKXuPVkPtTNAhJL9pxnhrBFJV4+/scKYStJTFp6jhWiXkdiwe5PbBC2tsSyha/B6nkFBCVO znzCMoFRbBaSsbOQtMxC0jILScsCRpZVjBylxalluelGhpsYgZF0TILNcQfjgk+WhxgFOBiV eHgTLWaGCrEmlhVX5h5ilOZgURLnlfbLCxUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAKGF2 8eDe3590z8xM3L5uq9OVhMOPjj5muGM0a5udBMOe4rb+kEVnvsnuCRATNfGoCF1xqqVB97HB j62thQsiTvySnfaZtVmsqiJIoNeAdfY39oTvOVsZX9VvfrKf7YJ0aNvZWbr5+tvV7t/2euQg m5zzuS1Hgdfrbb9Dc9rGoMsm28Ulw0rPKbEUZyQaajEXFScCAIccgP6FAgAA Archived-At: Cc: "karp-chairs@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-karp-isis-analysis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:55:41 -0000 Hi Take, Thanks for your review and comments. Shall address both your comments in t= he next update i.e., a. Ref. to 5310 in Section 4 b. Shall recommend usage of RFC 5310 instead of RFC 5304 (HMAC-MD5) " In view of openly published attack vectors, as noted in Section 1 of [RF= C5310] on HMAC-MD5 cryptographic authentication mechanism,=20 IS-IS deployments SHOULD use HMAC-SHA family [RFC5310] instead of HMAC-= MD5 [RFC5304] for protecting IS-IS PDUs." Please suggest if the above is sufficient to address #b (or happy to consid= er better text). Thx! -- Uma C. -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]=20 Sent: Friday, July 03, 2015 6:40 AM To: draft-ietf-karp-isis-analysis.all@tools.ietf.org Cc: iesg@ietf.org; secdir@ietf.org; karp-chairs@tools.ietf.org Subject: RE: Secdir review of draft-ietf-karp-isis-analysis-04 Let me add one more comment here. We could probably discourage the use of HMAC-MD5, and encourage the use of = HMAC-SHA family instead. Take > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Friday, July 3, 2015 1:10 PM > To: 'draft-ietf-karp-isis-analysis.all@tools.ietf.org' > Cc: 'iesg@ietf.org'; 'secdir@ietf.org'; 'karp-chairs@tools.ietf.org' > Subject: Secdir review of draft-ietf-karp-isis-analysis-04 >=20 > Hello, >=20 > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security=20 > area directors. > Document editors and WG chairs should treat these comments just like=20 > any other > last call comments. >=20 > This document is ready for publication. >=20 > [summary of this document] >=20 > This document analyzes the threats of IS-IS protocol. > It first summarizes the current state of the IS-IS protocol, with=20 > special focus > on key usage and key management (in section 2), and then analyzes the security > gaps in order to identify security requirements (in section 3). >=20 > In the summary of the current state of the protocol (section 2), it already > mentioned the threats of the protocol, i.e. replay attack and spoofing attack, > for each of the three message types of IS-IS protocol. > Section 3 summarizes, organizes, and develops the threat analysis and provides > candidate direction to cope with the threats by listing requirements=20 > and by > listing related I-D works. >=20 > [minor comment] >=20 > As mentioned in the security consideration section, this draft does=20 > not modify > any of the existing protocols. > It thus does not produce any new security concerns. > So, the security consideration section seems adequate. > The authors could consider citing RFC 5310 in Section 5, since I feel=20 > like that > this draft does not discuss all the content of the consideration=20 > section of > the rfc (it does discuss major parts of the section, though). >=20 > Cheers, > Take >=20 From nobody Mon Jul 6 17:21:29 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6291A6FF8; Mon, 6 Jul 2015 17:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2Cu1Gj5MDYO; Mon, 6 Jul 2015 17:21:26 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235471A6F03; Mon, 6 Jul 2015 17:21:26 -0700 (PDT) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id t670LHMB050773; Tue, 7 Jul 2015 09:21:17 +0900 (JST) Received: from TakeVaioVJP13 (vrrp.ssh.nict.go.jp [133.243.3.48] (may be forged)) by gw1.nict.go.jp with ESMTP id t670LGH4050768; Tue, 7 Jul 2015 09:21:17 +0900 (JST) From: "Takeshi Takahashi" To: "'Uma Chunduri'" , References: <006f01d0b595$baae8b20$300ba160$@nict.go.jp> <1B502206DFA0C544B7A60469152008633F749A8C@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F749A8C@eusaamb105.ericsson.se> Date: Tue, 7 Jul 2015 09:21:20 +0900 Message-ID: <024901d0b84a$d9735790$8c5a06b0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHAav37aHmKEmJW9EJGsrkITV/1WgHulHjEneBKMJA= Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.5 at zenith1 X-Virus-Status: Clean Archived-At: Cc: karp-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-karp-isis-analysis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 00:21:28 -0000 Hi Uma, The proposed sentence is fine to me, thank you for addressing my comments. Regards, Take > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Tuesday, July 7, 2015 4:56 AM > To: Takeshi Takahashi; draft-ietf-karp-isis-analysis.all@tools.ietf.org > Cc: iesg@ietf.org; secdir@ietf.org; karp-chairs@tools.ietf.org > Subject: RE: Secdir review of draft-ietf-karp-isis-analysis-04 > > Hi Take, > > Thanks for your review and comments. Shall address both your comments in the > next update i.e., a. Ref. to 5310 in Section 4 b. Shall recommend usage of > RFC 5310 instead of RFC 5304 (HMAC-MD5) > > " In view of openly published attack vectors, as noted in Section 1 of > [RFC5310] on HMAC-MD5 cryptographic authentication mechanism, > IS-IS deployments SHOULD use HMAC-SHA family [RFC5310] instead of HMAC-MD5 > [RFC5304] for protecting IS-IS PDUs." > > Please suggest if the above is sufficient to address #b (or happy to consider > better text). Thx! > > -- > Uma C. > > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Friday, July 03, 2015 6:40 AM > To: draft-ietf-karp-isis-analysis.all@tools.ietf.org > Cc: iesg@ietf.org; secdir@ietf.org; karp-chairs@tools.ietf.org > Subject: RE: Secdir review of draft-ietf-karp-isis-analysis-04 > > Let me add one more comment here. > We could probably discourage the use of HMAC-MD5, and encourage the use of > HMAC-SHA family instead. > > Take > > > -----Original Message----- > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > Sent: Friday, July 3, 2015 1:10 PM > > To: 'draft-ietf-karp-isis-analysis.all@tools.ietf.org' > > Cc: 'iesg@ietf.org'; 'secdir@ietf.org'; 'karp-chairs@tools.ietf.org' > > Subject: Secdir review of draft-ietf-karp-isis-analysis-04 > > > > Hello, > > > > I have reviewed this document as part of the security directorate's > ongoing > > effort to review all IETF documents being processed by the IESG. > > These comments were written primarily for the benefit of the security > > area directors. > > Document editors and WG chairs should treat these comments just like > > any > other > > last call comments. > > > > This document is ready for publication. > > > > [summary of this document] > > > > This document analyzes the threats of IS-IS protocol. > > It first summarizes the current state of the IS-IS protocol, with > > special > focus > > on key usage and key management (in section 2), and then analyzes the > security > > gaps in order to identify security requirements (in section 3). > > > > In the summary of the current state of the protocol (section 2), it > already > > mentioned the threats of the protocol, i.e. replay attack and spoofing > attack, > > for each of the three message types of IS-IS protocol. > > Section 3 summarizes, organizes, and develops the threat analysis and > provides > > candidate direction to cope with the threats by listing requirements > > and > by > > listing related I-D works. > > > > [minor comment] > > > > As mentioned in the security consideration section, this draft does > > not > modify > > any of the existing protocols. > > It thus does not produce any new security concerns. > > So, the security consideration section seems adequate. > > The authors could consider citing RFC 5310 in Section 5, since I feel > > like > that > > this draft does not discuss all the content of the consideration > > section > of > > the rfc (it does discuss major parts of the section, though). > > > > Cheers, > > Take > > From nobody Tue Jul 7 00:47:50 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036751A1A33 for ; Tue, 7 Jul 2015 00:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTEMWVLcQ5cr for ; Tue, 7 Jul 2015 00:47:46 -0700 (PDT) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [207.82.80.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5111A1A31 for ; Tue, 7 Jul 2015 00:47:45 -0700 (PDT) Received: from emea-cam-gw2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-34-ci01NyRYRPezvuIzYJoRaQ-2 Received: from george.Emea.Arm.com ([fe80::4c19:a8f:5c9a:76df]) by emea-cam-gw2.Emea.Arm.com ([::1]) with mapi; Tue, 7 Jul 2015 08:47:42 +0100 From: Hannes Tschofenig To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-wkumari-dhc-capport.all@tools.ietf.org" Date: Tue, 7 Jul 2015 08:47:41 +0100 Thread-Topic: Secdir review of draft-wkumari-dhc-capport-13 Thread-Index: AdC4h4BNZm0gzjebRZ6h7hBcyjl2vw== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 X-MC-Unique: ci01NyRYRPezvuIzYJoRaQ-2 Content-Type: multipart/alternative; boundary="_000_F01D8B85CFF58440B2A13965FBA90CA4013459D8EC0FGEORGEEmeaA_" Archived-At: Subject: [secdir] Secdir review of draft-wkumari-dhc-capport-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 07:47:49 -0000 --_000_F01D8B85CFF58440B2A13965FBA90CA4013459D8EC0FGEORGEEmeaA_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's effort = to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area = directors. Document editors and WG chairs should treat these comments just= like any other last call comment. This document communicates the presence of a captive portal in a WiFi netwo= rk using DHCP and RAs. Recommendation: Ready The motivation of the document makes sense, namely to avoid interception of= traffic, and the document is an easy extension to already available mechan= isms (RA/DHCP). I was expecting to see a reference to Hotspot 2.0, which ai= ms to make the interaction between hotspot providers and end devices more i= ntelligent (but covers a much larger scope). Minor nit: In Section 4 you write: "This document defines two DHCP Captive-Portal options, one for IPv6 and one for IPv6." It should of course read "..., one for IPv4 and one for IPv6." Ciao Hannes -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 --_000_F01D8B85CFF58440B2A13965FBA90CA4013459D8EC0FGEORGEEmeaA_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the secu= rity directorate's effort to review all IETF documents being processed by t= he IESG.

These comments were written primarily for the ben= efit of the security area directors.  Document editors and WG cha= irs should treat these comments just like any other last call comment.=

 

This document communicates the presence of a capt= ive portal in a WiFi network using DHCP and RAs.

 

Recommendation:  Ready

 

The motivation of the document makes sense, namely to avoid intercepti=
on of traffic, and the document is an easy extension to already available m=
echanisms (RA/DHCP). I was expecting to see a reference to Hotspot 2.0, whi=
ch aims to make the interaction between hotspot providers and end devices m=
ore intelligent (but covers a much larger scope).

 

Minor nit:

 

In Section 4 you write:

 

“This document defines two DHCP Captive-Portal options, one for =
IPv6
   and one for IPv6.”
 
It should of course read “…, one for IPv4 and one for IPv6=
.”
 

Ciao

Hannes

 

-- IMPORTANT NOTICE: The co= ntents of this email and any attachments are confidential and may also be p= rivileged. If you are not the intended recipient, please notify the sender = immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782
 --_000_F01D8B85CFF58440B2A13965FBA90CA4013459D8EC0FGEORGEEmeaA_-- From nobody Tue Jul 7 06:35:36 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF681A896D for ; Tue, 7 Jul 2015 06:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9zKPXDYhnSG for ; Tue, 7 Jul 2015 06:35:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA0F1A8879 for ; Tue, 7 Jul 2015 06:35:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 44260BE4C for ; Tue, 7 Jul 2015 14:35:33 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iD0EYhocEvCh for ; Tue, 7 Jul 2015 14:35:33 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 211E8BDF9 for ; Tue, 7 Jul 2015 14:35:33 +0100 (IST) Message-ID: <559BD5A5.4030804@cs.tcd.ie> Date: Tue, 07 Jul 2015 14:35:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "secdir@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] need a secdir review break? if so, let us know... X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 13:35:35 -0000 Hiya, First, thanks again for all your reviews, they really do help us as ADs and to ensure we end up with better documents. Kathleen and I have noticed that the percentage of dropped balls seems to be going up a little recently which may indicate that some of you might need a break or that you have less time for secdir reviews, either of which is entirely understandable. So if you would like to take a bit of a break from the secdir rotation, please just send us a note (to Kathleen and I and/or Tero) and Tero can take you out of the rotation for a while. Doing so is entirely fine, and it's really a better thing to be taking a break than to see more missed reviews, so don't be shy! Cheers & thanks again for all the work, S & K. PS: We'll also be sending a few mails to folks who've not managed to do a few reviews recently to check directly with you - don't worry if you do/don't get one of those though, we're just trying to make sure we know who has and hasn't time for doing reviews and we still think you're all great! From nobody Tue Jul 7 08:36:26 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAE91A88F6; Tue, 7 Jul 2015 08:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY3FIz0fyG8v; Tue, 7 Jul 2015 08:36:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3A81A88EF; Tue, 7 Jul 2015 08:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5480; q=dns/txt; s=iport; t=1436283381; x=1437492981; h=from:to:subject:date:message-id:mime-version; bh=LshyFgOI4gmJuVfr4lIKS2ON/5HkTpKzc8B4H/Nkmvk=; b=SpSKRnbWYLMTMDdr3grbpnaocaxQvTEam69h8ILjh5TQmtR41Na0aSpp 7jfMGM9W+vijijE1a1gnLfj+mpMXuop9xU92ldZ6CH089G/mRqB0F7Vqu Dz2W5VuBYuSN35fA+eCTOsbOxYHM0zH6K2Dd28v9j5JlJQ9RUCT9n7Q0A w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BuAwBC8ZtV/5xdJa1bgkVNVGa9ZgmHZgIcgTc4FAEBAQEBAQGBCoQlAQQjCl4BDB4gAgQwJgEEARqIJrVXlnIBAQEBAQEBAQEBAQEBAQEBAQEBGZAggyAvgRQFlBgBpEImg3uCNoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,424,1432598400"; d="scan'208,217";a="166255428" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 07 Jul 2015 15:36:21 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t67FaL0v029699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 15:36:21 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.25]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 10:36:21 -0500 From: "Shaun Cooley (shcooley)" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-appsawg-text-markdown.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-appsawg-text-markdown Thread-Index: AdC4ybGU/kv1wgpYRA2Ni0a4gEMS7Q== Date: Tue, 7 Jul 2015 15:36:20 +0000 Message-ID: <187A7B1DA239514F9146FC78B19AADE356D1966E@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.187.24] Content-Type: multipart/alternative; boundary="_000_187A7B1DA239514F9146FC78B19AADE356D1966Exmbalnx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: [secdir] secdir review of draft-ietf-appsawg-text-markdown X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 15:36:23 -0000 --_000_187A7B1DA239514F9146FC78B19AADE356D1966Exmbalnx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4g IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoaXMgZG9jdW1l bnQgcmVnaXN0ZXJzIHRoZSDigJh0ZXh0L21hcmtkb3du4oCZIG1lZGlhIHR5cGUuICBTcGVjaWZp Y2FsbHkgZXhjbHVkaW5nIGFueSBwb3RlbnRpYWwgc2VjdXJpdHkgY29uY2VybnMgcmVnYXJkaW5n IGJyb3dzZXJzIHJlbmRlcmluZyBNYXJrZG93biBmaWxlcyBpbiB0aGUgZnV0dXJlLCB0aGVyZSBh cmUgbm8gZGlyZWN0IGludGVybmV0IHNlY3VyaXR5IGltcGxpY2F0aW9ucyBhc3NvY2lhdGVkIHdp dGggdGhlIHJlZ2lzdHJhdGlvbiBvZiB0aGlzIG1lZGlhIHR5cGUuDQoNCkkgY29uc2lkZXIgdGhp cyBkb2N1bWVudCByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNCi1TaGF1bg0K --_000_187A7B1DA239514F9146FC78B19AADE356D1966Exmbalnx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBy ZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl J3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9j ZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmlt YXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4mbmJz cDsgRG9jdW1lbnQNCiBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNv bW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0aGUg4oCYdGV4dC9tYXJrZG93 buKAmSBtZWRpYSB0eXBlLiZuYnNwOyBTcGVjaWZpY2FsbHkgZXhjbHVkaW5nIGFueSBwb3RlbnRp YWwgc2VjdXJpdHkgY29uY2VybnMgcmVnYXJkaW5nIGJyb3dzZXJzIHJlbmRlcmluZyBNYXJrZG93 biBmaWxlcyBpbiB0aGUgZnV0dXJlLCB0aGVyZSBhcmUgbm8gZGlyZWN0IGludGVybmV0IHNlY3Vy aXR5IGltcGxpY2F0aW9ucyBhc3NvY2lhdGVkIHdpdGgNCiB0aGUgcmVnaXN0cmF0aW9uIG9mIHRo aXMgbWVkaWEgdHlwZS4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY29uc2lkZXIgdGhpcyBk b2N1bWVudCByZWFkeSBmb3IgcHVibGljYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1T aGF1bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_187A7B1DA239514F9146FC78B19AADE356D1966Exmbalnx10ciscoc_-- From nobody Tue Jul 7 12:10:18 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634B11A8703; Tue, 7 Jul 2015 12:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuqlPgo20uP5; Tue, 7 Jul 2015 12:10:15 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB531A1B6A; Tue, 7 Jul 2015 12:10:15 -0700 (PDT) X-AuditID: 12074424-f79b46d000001e7f-df-559c24169d29 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 62.52.07807.6142C955; Tue, 7 Jul 2015 15:10:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t67JADIr018061; Tue, 7 Jul 2015 15:10:14 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t67JABYr016548; Tue, 7 Jul 2015 15:10:12 -0400 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-grow-filtering-threats.all@tools.ietf.org Date: Tue, 07 Jul 2015 15:10:11 -0400 Message-ID: Lines: 41 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUixG6noiumMifUYHG7osWfxUfZLGb8mchs 8WHhQxYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK6O15xlzwUW+iue/9rI3MHbydDFy ckgImEhcXrqCFcIWk7hwbz0biC0ksJhJov+TXBcjF5C9gVHi6aTFLBCJ14wSe1vFQGw2AWmJ 45d3MYHYIgKJEpt3HgGrERawk+i5PB9oKAcHi4CqxOXNlSBhXgFdiX3TJ4Pt4hHglPi98Q0z RFxQ4uTMJ2CtzAJaEjf+vWSawMg7C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbrm ermZJXqpKaWbGMHh5KKyg7H5kNIhRgEORiUe3hsSs0OFWBPLiitzDzFKcjApifJ+/woU4kvK T6nMSCzOiC8qzUktPsQowcGsJMK7V3FOqBBvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU 1ILUIpisDAeHkgTvYiWgRsGi1PTUirTMnBKENBMHJ8hwHqDhO0BqeIsLEnOLM9Mh8qcYFaXE eVNBEgIgiYzSPLheWLy/YhQHekWY9zRIFQ8wVcB1vwIazAQ0eLnuLJDBJYkIKakGRpnZAT/V ll1YtTduj0qj5KRC+/qLldY/l3uFL4x8V+pobvnoe+0+w9qc5wJGascWtuw77bNNo+q9VdyU 4qDFXiaSs2S6ff/eOWLz9tFz9hBj/w3b4ybe/Xz2AlfWO/Gdc2d+WhcgH2jicO+thnR+8I0E NdHbUgcnR/6Y+vPJtDyX3He9khV3uZRYijMSDbWYi4oTAYdQc0XSAgAA Archived-At: Subject: [secdir] secdir review of draft-ietf-grow-filtering-threats-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 19:10:17 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready with nits Consider adding text to the Introduction mentioning malicious activity as a possible cause of these unexpected traffic flows, rather than leaving it toward the end of the document in the Security Considerations. The Security Considerations (Section 6) text describes possible malicious activity by an AS to deliberately cause unexpected traffic flow through another AS. Although the first paragraph of the Security Considerations says "The objective of this document is to inform on this potential routing security issue", there appears to be no prior mention in this document of possibility of maliciously induced unexpected traffic flow. The current Introduction characterizes the unexpected traffic flows primarily as side effects of filtering or other configuration, but appears not to include the possibility of a malicious cause. Editorial: In the second paragraph of Section 1: "While BGP" should be "Although BGP", to avoid implying dependency or temporal coincidence. In the first two paragraphs of Section 3.1, "his" should be "its". Please avoid the unnecessary use of gendered pronouns. In the first paragraph of Section 3.2, delete "data" from "as much data information as possible". For the title of Section 4, consider dropping one instance of the word "traffic". In the last paragraph of Section 4.1, in the sentence "...neighboring AS... opposes the peering agreement", consider replacing "opposes" with "contravenes", "infringes", or another synonym. From nobody Wed Jul 8 07:34:25 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFBC1B36CD; Wed, 8 Jul 2015 07:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3xwufCnyBb9; Wed, 8 Jul 2015 07:34:21 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F711B3469; Wed, 8 Jul 2015 07:34:21 -0700 (PDT) Received: by obdbs4 with SMTP id bs4so151830133obd.3; Wed, 08 Jul 2015 07:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RC4eAfT10iykulqo1ONmKKpoK8Y0hTKefQrYT0uLQWQ=; b=wsvP3OSleZWUCuumSmyLz0miOA1xiIr3a3knIoMN7rqqBnUOjBXuVPVkdsfjQ8/BKB RHDqgrhGcle/Q5WdSf5rYg6Mqt5u7Rf3VTGIWqJ1NXwUhz6yFZmdzvN2A/NqfRqV23Mc 3lJRO/1hba+QfXiuRbo3JTOpC1QAfoKNmFEje2uqwAkApm1mgzQ6esHncZpAc97CTFiD ImzxRXEBqIlo+4JynS06/lbQRzh9WsYhCAeMl4E8nXaqOh5o6m/PqjGIA1TkdcO6DAGV i8dQEIpOiVfbe8VADyBZT76A8tzNhgG+qGf/GTtQKaLGnnRkKKPVV/1TIcPHiwdvLEmN CGwQ== X-Received: by 10.202.91.212 with SMTP id p203mr9482699oib.108.1436366060902; Wed, 08 Jul 2015 07:34:20 -0700 (PDT) Received: from Chriss-MacBook-Air.local ([2601:2c0:8000:4fc0:940c:797d:f9de:3646]) by smtp.googlemail.com with ESMTPSA id mg19sm992603oeb.10.2015.07.08.07.34.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 07:34:20 -0700 (PDT) Message-ID: <559D34EB.1080100@gmail.com> Date: Wed, 08 Jul 2015 09:34:19 -0500 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-6lo-btle.all@tools.ietf.org References: <556F8C89.1020500@gmail.com> In-Reply-To: <556F8C89.1020500@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6lo-btle-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 14:34:23 -0000 Hi, I have re-reviewed this document. Overall, a lot of very good changes have been made. I appreciate the additions to the Security Considerations section. Both of those are well written and give appropriate guidance. I went back and re-read what I had asked about discussing multicast as a malicious attack vector. My apologies, but I didn't make myself clear. I was asking about what would happen if a device on the Internet were to start sending multicast packets to the 6LBR attempting to get it to forward them to the 6LNs. I'm thinking that would cause a great deal of overhead processing on the 6LBR and perhaps overwhelm the Bluetooth network. Is there a way to prevent or mitigate that? Best regards, Chris On 6/3/15 6:23 PM, Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Overall, the document is well written and explains the concepts well. > > I saw that a "test interface" is defined in Section 2.1. I would like > to see some guidance in the Security Considerations section about this. > Hopefully the guidance will describe how the interface is secured, or > that it can be secured by an operator. > > Multicast is mentioned several times throughout the document mostly > saying that the Bluetooth LE link layer does not support it. I > would like to see this addressed in the Security Considerations section > as well to alert implementers and operators that this may be a point > of attack. Any guidance on how to prevent an active, malicious denial > of service attack using multicast would be appreciated. > From nobody Wed Jul 8 08:08:24 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538201A0023; Wed, 8 Jul 2015 08:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7psFJPxpIuKE; Wed, 8 Jul 2015 08:05:45 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1701A001A; Wed, 8 Jul 2015 08:05:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 2955B1B922E; Wed, 8 Jul 2015 17:03:44 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyWl-H44u7ZM; Wed, 8 Jul 2015 17:03:43 +0200 (CEST) Received: from [10.61.202.106] (unknown [173.38.220.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id A45A01B922D; Wed, 8 Jul 2015 17:03:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_37852847-3CCF-4EC3-AC65-76D922BB1648"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Pierre Francois In-Reply-To: Date: Wed, 8 Jul 2015 17:05:26 +0200 Message-Id: <1A2F3643-49F9-4242-B67A-995DE3132AAA@imdea.org> References: To: Tom Yu X-Mailer: Apple Mail (2.2070.6) Archived-At: X-Mailman-Approved-At: Wed, 08 Jul 2015 08:08:22 -0700 Cc: draft-ietf-grow-filtering-threats.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-grow-filtering-threats-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 15:05:49 -0000 --Apple-Mail=_37852847-3CCF-4EC3-AC65-76D922BB1648 Content-Type: multipart/alternative; boundary="Apple-Mail=_90163BF8-0DA2-47F8-9C7A-160296BB2874" --Apple-Mail=_90163BF8-0DA2-47F8-9C7A-160296BB2874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom, Thanks a lot for your review. Comments inline. Pierre. > On 07 Jul 2015, at 21:10, Tom Yu wrote: >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the = IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. >=20 > Summary: Ready with nits >=20 > Consider adding text to the Introduction mentioning malicious activity > as a possible cause of these unexpected traffic flows, rather than > leaving it toward the end of the document in the Security > Considerations. >=20 > The Security Considerations (Section 6) text describes possible > malicious activity by an AS to deliberately cause unexpected traffic > flow through another AS. Although the first paragraph of the Security > Considerations says "The objective of this document is to inform on = this > potential routing security issue", there appears to be no prior = mention > in this document of possibility of maliciously induced unexpected > traffic flow. The current Introduction characterizes the unexpected > traffic flows primarily as side effects of filtering or other > configuration, but appears not to include the possibility of a = malicious > cause. We agree. However, we got feedback in the past that the same technical = situation can occur without malicious intent and so were asked to reword the draft without implying malicious intent. We heard at the mic = =E2=80=9CI=E2=80=99ve done it and I am not evil=E2=80=9D, =E2=80=9CThis = is traffic engineering, not an attack=E2=80=9D. Still, we were recommended to put this explanation in the security = consideration section because, well, it can also happen due to malicious = intent (gaining reach for cheap through another party's network). I=E2=80=99m afraid that by changing this again, I=E2=80=99d be starting = another revolution (in the mathematical sense) here=E2=80=A6 but what = about: Introduction: OLD: The objective of this draft is to shed light on possible side = effects associated with more specific prefix filtering. This document = presents examples of such side effects and discusses approaches towards = solutions to the problem. NEW: The objective of this draft is to shed light on possible side = effects associated with such more specific prefix filtering. Such actions can be explained by traffic engineering action, = misconfiguration, or malicious intent. This document presents examples of such side effects and discusses = approaches towards solutions to the problem. >=20 > Editorial: >=20 > In the second paragraph of Section 1: "While BGP" should be "Although > BGP", to avoid implying dependency or temporal coincidence. >=20 > In the first two paragraphs of Section 3.1, "his" should be "its". > Please avoid the unnecessary use of gendered pronouns. >=20 > In the first paragraph of Section 3.2, delete "data" from "as much = data > information as possible". >=20 > For the title of Section 4, consider dropping one instance of the word > "traffic". >=20 > In the last paragraph of Section 4.1, in the sentence "...neighboring > AS... opposes the peering agreement", consider replacing "opposes" = with > "contravenes", "infringes", or another synonym. Thank you ! Cheers, Pierre. --Apple-Mail=_90163BF8-0DA2-47F8-9C7A-160296BB2874 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tom, 

Thanks a lot for your review. Comments = inline. 

Pierre.


On 07 Jul 2015, at 21:10, Tom Yu <tlyu@MIT.EDU> = wrote:

I = have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed = by the IESG.
These comments were written primarily for the = benefit of the security
area directors.  Document = editors and WG chairs should treat these
comments just = like any other last call comments.

Summary: = Ready with nits

Consider adding text to the = Introduction mentioning malicious activity
as a possible = cause of these unexpected traffic flows, rather than
leaving= it toward the end of the document in the Security
Considerations.

The Security = Considerations (Section 6) text describes possible
malicious= activity by an AS to deliberately cause unexpected traffic
flow through another AS.  Although the first paragraph = of the Security
Considerations says "The objective of this = document is to inform on this
potential routing security = issue", there appears to be no prior mention
in this = document of possibility of maliciously induced unexpected
traffic flow.  The current Introduction characterizes = the unexpected
traffic flows primarily as side effects of = filtering or other
configuration, but appears not to = include the possibility of a malicious
cause.


We agree. However, we got feedback in the past = that the same technical situation can occur without malicious intent and = so were asked to reword
the draft without implying malicious = intent. We heard at the mic =E2=80=9CI=E2=80=99ve done it and I am not = evil=E2=80=9D, =E2=80=9CThis is traffic engineering, not an = attack=E2=80=9D.

Still, we were = recommended to put this explanation in the security consideration = section because, well, it can also happen due to malicious = intent 
(gaining reach for cheap through another party's = network).

I=E2=80=99m afraid that by = changing this again, I=E2=80=99d be starting another revolution (in the = mathematical sense) here=E2=80=A6 but what about:


Introduction:

OLD: The objective of this draft is to shed light on possible side effects = associated with more specific prefix filtering. This document presents examples of = such side effects and discusses approaches towards solutions to the = problem.

NEW:  The objective of this draft is to shed light on = possible side effects associated with such more specific prefix = filtering.
Such actions can be explained by traffic = engineering action, misconfiguration, or malicious intent.
This document presents examples of such = side effects and discusses approaches towards solutions to the = problem.



Editorial:

In the second = paragraph of Section 1: "While BGP" should be "Although
BGP", to avoid implying dependency or temporal = coincidence.

In the first two paragraphs of = Section 3.1, "his" should be "its".
Please avoid the = unnecessary use of gendered pronouns.

In = the first paragraph of Section 3.2, delete "data" from "as much data
information as possible".

For = the title of Section 4, consider dropping one instance of the word
"traffic".

In the last paragraph = of Section 4.1, in the sentence "...neighboring
AS... = opposes the peering agreement", consider replacing "opposes" with
"contravenes", "infringes", or another synonym.


Thank you !

Cheers, 

Pierre.



= --Apple-Mail=_90163BF8-0DA2-47F8-9C7A-160296BB2874-- --Apple-Mail=_37852847-3CCF-4EC3-AC65-76D922BB1648 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVnTw2AAoJEFVsgKhDmVUFe40QALRPgHmp6IA4UFbYaCxn4RHX QNjJvUUeO6REjR5IoXEtk1xvcNC3MoK7puwxpoXoeezEPf/W0Gq97xLZlLVtSDqG BDcTeQQfvxNb4zZEjzvLnVFT+0hdtWuX6QZuKD7huKQhDc/2jjcKFXazhBFoMe5Y EOKDkPqkCsYkGBcvjqKlP3t0R0kG+H+NcEyEKNuswx7uirQ3oIW9NBoXwrYsGMU+ ZFeJka09WicJAiCxuvliUO0nsKew8cs12+mcRFbk5M5M8huioQ5Ah4Xzirljj405 YcFTSE6g+b/1KAwjeTxg/0oym2fYpF0BBnD81+JHr1UWplHSvrjm8GGd8hktIr3R F8knNLYCVKEHvDB30sy2jpRrPuW1g//HiZthJ1yMb3DkXkO8NmqErz2hOWm79VeH nHm837BhYffXx4PKSeAKakwhf69DTfFQWpUiLX37ZnkEcaYS9bQl9Tge/nnxJzii cnKBAUuFNUWxixhgsTWs/F4oMLW1PtMT2YPEYMPD1ssZgsZocQgOakacZkG7pj3i QWBd8Gdla/O2B0aFnAMdtplZfJDzQ+lbESHftIHZDqE9Q+5qU4iGGzjloQtuFKtt yJkuSMJomC/ZrXUKiET6hKhlZ+RWfb2AaQJpA4XP7NFDckNJ7eQ2xLokS/7fp3fF nJfBCXVk8IJOxjI1PlVf =ALPk -----END PGP SIGNATURE----- --Apple-Mail=_37852847-3CCF-4EC3-AC65-76D922BB1648-- From nobody Wed Jul 8 08:29:28 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D429F1A002C for ; Wed, 8 Jul 2015 08:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Addr4UWIUsGJ for ; Wed, 8 Jul 2015 08:29:22 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34581A0056 for ; Wed, 8 Jul 2015 08:28:58 -0700 (PDT) Received: by oiab3 with SMTP id b3so50130089oia.1 for ; Wed, 08 Jul 2015 08:28:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kFwL2dEc9gA13A8owocMzPRmK6fn56//D5ZL6CP0jfY=; b=FrSdcnrGQ7R9W2a3tQcSlFutwstidn3CK2twjgF0JgNTHaGVVVtr8Jakn2Kc2iGkji TVTRDDqyvgxE7mQ3U6Q/7ifguuCeD8waUulySzNEhJ4QuGGtGFq37ddN7Bs2yZ9I/Psp k0VqRpJBMtfjzeUk0YTAMgHbwNGBfBfWaBuNn2ntfxwR5+d9FYlq80VGztIWnxJGmGqb HenQTe4sKDg3fTvbkJPD4Q+ZrJmNn7wSZCD6ebWYlaHUTEPE2qsXHsPr38RrMjBk9bqN Lz5xBKqchB68cW7L7TG2/o5HixiT1HrgnwbigYHTH1rfC878OBmhjP6ztd7YmQNdpAmf gtRg== X-Gm-Message-State: ALoCoQmOzLhuTF5BucqnRgE8MjwpaEopPca+JwTf/N4sNhNHjKS21SvORBG8wQY9qXjEo0lgt4DT MIME-Version: 1.0 X-Received: by 10.202.1.209 with SMTP id 200mr9900936oib.86.1436369338376; Wed, 08 Jul 2015 08:28:58 -0700 (PDT) Received: by 10.202.232.1 with HTTP; Wed, 8 Jul 2015 08:28:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Jul 2015 11:28:58 -0400 Message-ID: From: Warren Kumari To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-wkumari-dhc-capport.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-wkumari-dhc-capport-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 15:29:24 -0000 [ Off-list ] On Tue, Jul 7, 2015 at 3:47 AM, Hannes Tschofenig wrote: > I have reviewed this document as part of the security directorate's effor= t > to review all IETF documents being processed by the IESG. > > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comment. > Thank you for the review.... > > > This document communicates the presence of a captive portal in a WiFi > network using DHCP and RAs. > > > > Recommendation: Ready > > > > The motivation of the document makes sense, namely to avoid interception = of > traffic, and the document is an easy extension to already available > mechanisms (RA/DHCP). I was expecting to see a reference to Hotspot 2.0, > which aims to make the interaction between hotspot providers and end devi= ces > more intelligent (but covers a much larger scope). I originally had this as an editor's note: https://github.com/wkumari/draft-wkumari-dhc-capport/blob/de293471faef56251= 7978b709aaca762d1d78dbe/README.md "[ Ed note: This solution is somewhat similar / complements 802.11u / WiFi Passpoint Online Sign-up, but is much simpler, easier to deploy, and works on wired as well ] " I spent some time looking at the Hotspot 2.0 stuff, but after slogging through much 4 color glossy type material it seemed that it more allowed you to use different reaming providers / snap a RADIUS connection back to another provider. I even spent some $$$ on purchasing a spec, which I found largely unintelligible. So, I decided to remove the vague / editorial note... :-) If you happen to have any suggested text I'm happy to stick it in... > > > > Minor nit: > > > > In Section 4 you write: > > > > =E2=80=9CThis document defines two DHCP Captive-Portal options, one for I= Pv6 > > and one for IPv6.=E2=80=9D > > > > It should of course read =E2=80=9C=E2=80=A6, one for IPv4 and one for IPv= 6.=E2=80=9D Thanks. I've fixed it in the editor version. W > > > > Ciao > > Hannes > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf On Tue, Jul 7, 2015 at 3:47 AM, Hannes Tschofenig wrote: > I have reviewed this document as part of the security directorate's effor= t > to review all IETF documents being processed by the IESG. > > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comment. > > > > This document communicates the presence of a captive portal in a WiFi > network using DHCP and RAs. > > > > Recommendation: Ready > > > > The motivation of the document makes sense, namely to avoid interception = of > traffic, and the document is an easy extension to already available > mechanisms (RA/DHCP). I was expecting to see a reference to Hotspot 2.0, > which aims to make the interaction between hotspot providers and end devi= ces > more intelligent (but covers a much larger scope). > > > > Minor nit: > > > > In Section 4 you write: > > > > =E2=80=9CThis document defines two DHCP Captive-Portal options, one for I= Pv6 > > and one for IPv6.=E2=80=9D > > > > It should of course read =E2=80=9C=E2=80=A6, one for IPv4 and one for IPv= 6.=E2=80=9D > > > > Ciao > > Hannes > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Jul 8 12:29:12 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC491A1BC2 for ; Wed, 8 Jul 2015 12:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUCnfYXQS97V for ; Wed, 8 Jul 2015 12:29:09 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9EDB1A1B6D for ; Wed, 8 Jul 2015 12:29:08 -0700 (PDT) Received: by wiclp1 with SMTP id lp1so89991499wic.0 for ; Wed, 08 Jul 2015 12:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fuss/9037ZUcTDQnkynSIa0f8UisW/l9iUMNu0zFQgY=; b=LTwMP49WaS3yBcOs643Sa/3G0nXT5fDLrLscQv4ehgIpS6vrppwfC6XmMH2zgLiSZL TP1sqxjPPb8yhgmOJOPZh8H2No0wJ700WuRp1VrbG8t2+YXSgfZMGTZ2DlpiE6GaESwk KLOuWpRkFZEdrVUHl+6PTRpOHIIZX4ObV6T5aIRoFuStflR+yUBeF7PopzkqNSRQs/+9 KZ5jlWJle0BjpuxEm00aNfqPCI9CPd9kchNHil0yQmxmTM/X2yCYuDFykoEkFtAeicL8 hI6NoviWsQQfHOmNdPrDW4uvZaJ1jIOSSYvpEGFZvhwJ3dKolWDxnlkAPwBCc8ssgoQb OLGA== MIME-Version: 1.0 X-Received: by 10.180.9.75 with SMTP id x11mr73772110wia.80.1436383747503; Wed, 08 Jul 2015 12:29:07 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Wed, 8 Jul 2015 12:29:07 -0700 (PDT) Date: Wed, 8 Jul 2015 15:29:07 -0400 Message-ID: From: Kathleen Moriarty To: "secdir@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2413607fac4051a622724 Archived-At: Subject: [secdir] DHCP IPv6 help needed X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 19:29:10 -0000 --001a11c2413607fac4051a622724 Content-Type: text/plain; charset=UTF-8 Hello, We have a request for a security person to assist with DHCP work early on. This is specific to IPv6. Is anyone interested to volunteer? Thank you! -- Best regards, Kathleen & Stephen --001a11c2413607fac4051a622724 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

We have a request for a security= person to assist with DHCP work early on.=C2=A0 This is specific to IPv6.= =C2=A0 Is anyone interested to volunteer?

Thank yo= u!

--

Best regards,
Kathleen & Stephen
--001a11c2413607fac4051a622724-- From nobody Wed Jul 8 15:15:28 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AFE1A88C5 for ; Wed, 8 Jul 2015 15:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRQPs2XJz5yN for ; Wed, 8 Jul 2015 15:15:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7961A88AB for ; Wed, 8 Jul 2015 15:15:22 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t68MFIED014958 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 9 Jul 2015 01:15:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t68MFIcB014841; Thu, 9 Jul 2015 01:15:18 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21917.41206.673059.923758@fireball.acr.fi> Date: Thu, 9 Jul 2015 01:15:18 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 22:15:27 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sam Hartman is next in the rotation. For telechat 2015-07-09 Reviewer LC end Draft Chris Lonvick TR2015-06-09 draft-ietf-6lo-btle-14 Sean Turner T 2015-06-29 draft-ietf-dhc-dhcpv6-active-leasequery-03 Carl Wallace T 2015-06-29 draft-ietf-ipsecme-chacha20-poly1305-11 David Waltermire T 2015-06-29 draft-ietf-pcp-authentication-13 For telechat 2015-08-05 Tina TSOU T 2015-06-24 draft-ietf-dane-ops-13 For telechat 2015-08-19 Dan Harkins T 2015-08-05 draft-vinapamula-softwire-dslite-prefix-binding-07 Last calls and special requests: John Bradley 2015-07-08 draft-ietf-xmpp-posh-04 Dave Cridland 2015-07-27 draft-bradner-iaoc-terms-01 Alan DeKok 2015-07-09 draft-ietf-intarea-gre-ipv6-10 Donald Eastlake 2015-07-13 draft-ietf-6man-ipv6-address-generation-privacy-07 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Olafur Gudmundsson 2015-07-29 draft-mm-netconf-time-capability-05 Phillip Hallam-Baker 2015-07-20 draft-ietf-dime-4over6-provisioning-03 Steve Hanna 2015-08-04 draft-sparks-genarea-review-tracker-02 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 -- kivinen@iki.fi From nobody Thu Jul 9 20:42:21 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE4E1A87C8; Thu, 9 Jul 2015 20:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK7KGPw8_E79; Thu, 9 Jul 2015 20:42:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C950F1A87C5; Thu, 9 Jul 2015 20:42:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUZ96857; Fri, 10 Jul 2015 03:42:15 +0000 (GMT) Received: from SZXEML428-HUB.china.huawei.com (10.82.67.183) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jul 2015 04:42:14 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.175]) by szxeml428-hub.china.huawei.com ([10.82.67.183]) with mapi id 14.03.0158.001; Fri, 10 Jul 2015 11:42:07 +0800 From: Tina TSOU To: "iesg@ietf.org" , IETF Security Directorate , "draft-ietf-dane-ops.all@tools.ietf.org" Thread-Topic: SecDir Review of draft-ietf-dane-ops-12 Thread-Index: AQHQusJkWYK6y6gAhUWN1LafIW5+LQ== Date: Fri, 10 Jul 2015 03:42:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.87.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [secdir] SecDir Review of draft-ietf-dane-ops-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 03:42:18 -0000 Dear all, =20 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments that arrive in timely manner, and not significantl= y belated. I've found this document well-written. I believe it is ready for publicatio= n modulo some small issues that can hopefully be addressed prior to publica= tion: **** Technical ***** * Meta: I would have liked to find (if anything, in an appendix) the ration= ale for he changes being proposed by this document. Since the changes are s= aid to originate on operational experience, I think that codifying the less= ons (problems found, and a rationale for the workarounds). There seems to b= e a bit of this throughout the document, but not for most of the changes pr= oposed. * Section 4.8, page 8: > Therefore, when a TLS client > authenticates the TLS server via a TLSA record with usage DANE-EE(3), > CT checks SHOULD NOT be performed. What are the valid reasons for performing th CT checks? If there are not an= y, why not make this requirement a "MUST NOT" instead? * Section 5.1, page 10: > Servers SHOULD NOT rely on > "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication > data for raw public keys. Same here. * Section 7, page 17: > Though CNAMEs are illegal on the right hand side of most indirection > records, such as MX and SRV records, they are supported by some > implementations. For example, if the MX or SRV host is a CNAME > alias, some implementations may "chase" the CNAME. If they do, they > SHOULD use the target hostname as the preferred TLSA base domain as > described above (and if the TLSA records are found there, use the > CNAME expanded domain also in SNI and certificate name checks). If CNAMES on the right hand side of most indirection records are illegal, w= hy trying to process them in the first place? * Section 9, page 21: > This order SHOULD be configurable by the MTA > administrator.=20 Please expand "MTA". Also, why make the explanation mail-specific? * Section 13, page 26: > The signature validity period for TLSA records should also not be too > long. Signed DNSSEC records can be replayed by an MiTM attacker > provided the signatures have not yet expired.=20 Please expand "MiTM". **** Nits ***** Section 1.1, Page 4: > difficult to host multiple Customer Domains at the same IP- > addressed based TLS service endpoint (i.e., "secure virtual > hosting"). s/addressed based/address-based/ Section 4.2, page 8: > Publication of the server > certificate or public key (digest) in a TLSA record in a DNSSEC > signed zone by the domain owner assures the TLS client that the > certificate is not an unauthorized certificate issued by a rogue CA > without the domain owner's consent. Avoiding the double-negation improves clarity... i.e., please change to "..= .is an authorized certificate issued by a rogue CA without the domain owner's consent" * Section 5.1, page 9: > With DANE-EE(3) servers that know all the connecting clients are > making use of DANE, they need not employ SNI I'm having trouble parsing this sentence... could you please take a look an= d tweak it if necessary? Thank you, Tina From nobody Thu Jul 9 21:40:46 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3D91A888E; Thu, 9 Jul 2015 21:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-g4Euy4Ve7d; Thu, 9 Jul 2015 21:40:40 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F621A888B; Thu, 9 Jul 2015 21:40:40 -0700 (PDT) Received: by vnbg129 with SMTP id g129so30567889vnb.11; Thu, 09 Jul 2015 21:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9hsornuxukEQHth6R7lto6pH5SkTuwtajiHczazWDiE=; b=w1mzSsvXaaI7U3K1xM84GuRZiBxTf9/1A+iDL0IxXBq93u5YnK68RPvAgfylRb3FdW 3cNIyh6Q31qXaukGnmiO40Oj1TPWWPRChskpdy4wblqeNiezGTVDvSs+lQWMapcYq6ar 8866X7Lm6F+9ydvsQoOyFLG6c6lvYNxyIWAmB7PdYqtCqiDc6/S5UuzTuw8pVkR7e6My DONULNbMRy9Sg6f6GpbVBlReGBwKUfWEg4AIhITUS1+b8zGjVB+EqoiMDHLtinni9GnY a7MrJH67f0YAynkOYiEEpldwaRjjDY3UTmtkKCMtHmql/jJeJ1DKxAc6pjK8uPzmUiLe zK9w== MIME-Version: 1.0 X-Received: by 10.52.38.197 with SMTP id i5mr14145084vdk.52.1436503239365; Thu, 09 Jul 2015 21:40:39 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Thu, 9 Jul 2015 21:40:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Jul 2015 00:40:39 -0400 X-Google-Sender-Auth: bK-Je20qxWopjFIaGXWMK-C7yVY Message-ID: From: Barry Leiba To: Tina TSOU Content-Type: multipart/alternative; boundary=bcaec51d205a4d1d12051a7df973 Archived-At: Cc: "draft-ietf-dane-ops.all@tools.ietf.org" , "iesg@ietf.org" , IETF Security Directorate Subject: Re: [secdir] SecDir Review of draft-ietf-dane-ops-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 04:40:41 -0000 --bcaec51d205a4d1d12051a7df973 Content-Type: text/plain; charset=UTF-8 Thanks for the review, Tina. Just reponding to one point: Section 4.2, page 8: > > Publication of the server > > certificate or public key (digest) in a TLSA record in a DNSSEC > > signed zone by the domain owner assures the TLS client that the > > certificate is not an unauthorized certificate issued by a rogue CA > > without the domain owner's consent. > > Avoiding the double-negation improves clarity... i.e., please change to > "...is an authorized certificate issued by a rogue CA > without the domain owner's consent" > You're right that it's best to avoid double negatives, but this actually isn't one, and your suggestion changes the meaning completely. Using parentheses to show the word groupings, this is not saying that "the certificate is (not an unauthorized certificate) issued by a rogue CA". It's saying that "the certificate is not (an unauthorized certificate issued by a rogue CA)". And this really is the best way to say that. I can't think of a way to reword it that isn't clunky and awkward. Barry --bcaec51d205a4d1d12051a7df973 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the review, Tina.

Just reponding to one point= :

Section 4.2, page 8:
> Publication of the server
>=C2=A0 =C2=A0 certificate or public key (digest) in a TLSA record in a = DNSSEC
>=C2=A0 =C2=A0 signed zone by the domain owner assures the TLS client th= at the
>=C2=A0 =C2=A0 certificate is not an unauthorized certificate issued by = a rogue CA
>=C2=A0 =C2=A0 without the domain owner's consent.

Avoiding the double-negation improves clarity... i.e., please change to &qu= ot;...is an authorized certificate issued by a rogue CA
=C2=A0 =C2=A0 without the domain owner's consent"

You're right that it's best to avo= id double negatives, but this actually isn't one, and your suggestion c= hanges the meaning completely.=C2=A0 Using parentheses to show the word gro= upings, this is not saying that "the certificate is (not an unauthoriz= ed certificate) issued by a rogue CA". =C2=A0=C2=A0It's saying tha= t "the certificate is not (an unauthorized certificate issued by a rog= ue CA)".=C2=A0 And this really is the best way to say that.=C2=A0 I ca= n't think of a way to reword it that isn't clunky and awkward.

Barry

--bcaec51d205a4d1d12051a7df973-- From nobody Fri Jul 10 02:22:28 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98D1A88B9; Thu, 9 Jul 2015 22:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx57UFt_F7UA; Thu, 9 Jul 2015 22:05:09 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332A91A889D; Thu, 9 Jul 2015 22:05:09 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3AB38284D69; Fri, 10 Jul 2015 05:05:08 +0000 (UTC) Date: Fri, 10 Jul 2015 05:05:08 +0000 From: Viktor Dukhovni To: Tina TSOU Message-ID: <20150710050507.GQ28047@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-Mailman-Approved-At: Fri, 10 Jul 2015 02:22:27 -0700 Cc: "draft-ietf-dane-ops.all@tools.ietf.org" , "iesg@ietf.org" , IETF Security Directorate Subject: Re: [secdir] SecDir Review of draft-ietf-dane-ops-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 05:05:10 -0000 On Fri, Jul 10, 2015 at 03:42:06AM +0000, Tina TSOU wrote: > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments that arrive in timely manner, and not > significantly belated. Note that -13 has been published in the mean time and addresses at least one of the concerns: If it reasonable to ask you to glance over the diff from -12 to -13 to see whether that introduces new issues or resolves any of the ones you listed? > * Section 9, page 21: > > This order SHOULD be configurable by the MTA > > administrator. > > Please expand "MTA". Also, why make the explanation mail-specific? This text was modified in -13 to not mention MTAs. -- Viktor. From nobody Fri Jul 10 09:19:52 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F4D1B2CF0; Fri, 10 Jul 2015 09:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgzkgXcI7wHB; Fri, 10 Jul 2015 09:19:48 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79ECA1B2CE8; Fri, 10 Jul 2015 09:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10999; q=dns/txt; s=iport; t=1436545188; x=1437754788; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cEGsdcYlCqQY0JdyD3yZ1Il3BHn9dDgw8zNLlsSBGhE=; b=dMbL8xhUI4PQd0qGTuuKod7d4tYFvqw7o+jryqQAwznkFYY/NciEL3gT Dqp2U4QqXKNCziBsrFJEE5Nsq7B/SruuD0+caCkC93giRyn0u6XEkQ8B0 FD/xfZJF0H48MB46hIpecPUVaTysskFEhXdnRw7reH0anq9xa6rPYifQD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BfAwBX8J9V/5FdJa1SBgOCRU2BNAa7LQmHaAKBSjgUAQEBAQEBAYEKhCMBAQEDAWcXCQICAQgRAwECKAcbFxQJCAIEARKIJgjQKQEBAQEBAQEBAQEBAQEBAQEBAQEZBItHhCMHCgElGwELDBGEGgWMLIUcgmkBjAOYayaCB4F0bwGBDDqBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,447,1432598400"; d="scan'208,217";a="167148088" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP; 10 Jul 2015 16:19:38 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6AGJcJJ025172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jul 2015 16:19:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.38]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 10 Jul 2015 11:19:38 -0500 From: "Sri Gundavelli (sgundave)" To: Catherine Meadows , "draft-ietf-dhc-access-network-identifier.all@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: secdir review of draft-ietf-dhc-access-network-identifier-08 Thread-Index: AQHQr1cxQgFsakfaFEigKP+HYJIb8p3U2DaA Date: Fri, 10 Jul 2015 16:19:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.32.246.217] Content-Type: multipart/alternative; boundary="_000_D1C53A5B1CA8B1sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:19:50 -0000 --_000_D1C53A5B1CA8B1sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Catherine, Thanks for the review. > However, what needs to be go in the Security Considerations Section is a = discussion of the security risks raised by *this* document and possible mit= igation. The information about DHCP security risks is useful, but not of p= rimary importance. Agree with this comment. The draft is defining some new information elemen= ts that are carried between the DHCP entities and any new security consider= ations are around exposing that data to third parties. "The information elements that this draft is exposing is the client=92s acc= ess-network information. These pertains to the access network to which the = client is attached, such as Access Technology Type (Ex: WLAN, Ethernet=85et= c), Access Point Identity (Name, BSSID), Operator Id/Realm. Exposing these = information elements to has no implication on the end-user security. But, = in deployments where this information is considered secure and when such th= reat cannot be mitigated using the currently available security tools, then= the administrators have to consider disabling this capability on the DHCP = entities." Is this sufficient ? Regards Sri From: Catherine Meadows > Date: Thursday, June 25, 2015 at 7:56 AM To: "draft-ietf-dhc-access-network-identifier.all@tools.ietf.org" >, "secdir@ietf.org" >, "iesg@ietf.org" > Cc: Catherine Meadows > Subject: secdir review of draft-ietf-dhc-access-network-identifier-08 Resent-From: > Resent-To: > Resent-Date: Thursday, June 25, 2015 at 7:56 AM I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies the format and mechanisms used for encoding network id= entifiers in DHCPv4 and DHCPv6 by defining new access identifier options an= d sub-options. The Security Considerations section gives a discussion of the security risk= s in using DHCP and their mitigation. However, what needs to be go in the = Security Considerations Section is a discussion of the security risks raised by *this* document and= possible mitigation. The information about DHCP security risks is useful,= but not of primary importance. My impression is that this document gives formats for presenting fields who= se use is already discussed in previous RFC=92s, e.g. RFC3315, in which cas= e there are no new security considerations. If that is so, then the Security Considerations S= ection should include (preferably begin with) a statement to the effect that, since this = document only gives instructions for formatting and encoding fields whose u= se has already been specified in these previous RFC=92s, it presents no additional security consideration= s beyond what is covered in those RFCs. If that is not the case, you shoul= d say what new security risks are introduced by *this* draft, e.g. does it enable a use of DHCP that was not possible be= fore and could cause a new type of security risk if DHCP was used without a= uthentication? Recommendation: Ready With Issues Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --_000_D1C53A5B1CA8B1sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Catherine,

Thanks for the review.

> However, what needs to be go in the Security Considerations Secti= on is a discussion of the security risks raised by *this* document and poss= ible mitigation.  The information about DHCP security risks is useful,= but not of primary importance.

Agree with this comment. The  draft is defining some new informat= ion elements that are carried between the DHCP entities and any new securit= y considerations are around exposing that data to third parties.


"The information elements that this draft is exposing is the clie= nt=92s access-network information. These pertains to the access network to = which the client is attached, such as Access Technology Type (Ex: WLAN, Eth= ernet=85etc), Access Point Identity (Name, BSSID), Operator Id/Realm. Exposing these information elements to  ha= s no implication on the end-user security. But, in deployments where this i= nformation is considered secure and when such threat cannot be mitigated us= ing the currently available security tools, then the administrators have to consider disabling this capability = on the DHCP entities."


Is this sufficient ?


Regards
Sri





I have reviewed this document as part of the security directorate's  ongoing effort to review all IETF documents being processed by the  IESG.  These comments were written primarily for the benefit of the&nb= sp;
security area directors.  Document editors and WG chairs should treat&= nbsp;
these comments just like any other last call comments.


This draft specifies the format and mechanisms used for encoding network id= entifiers in DHCPv4 and DHCPv6 by defining new access identifier options an= d sub-options.
The Security Considerations section gives a discussion of the security risk= s in using DHCP and their mitigation.  However, what needs to be go in= the Security Considerations
Section is a discussion of the security risks raised by *this* document and= possible mitigation.  The information about DHCP security risks is us= eful, but not of primary importance.

My impression is that this document gives formats for presenting fields who= se use is already discussed in previous RFC=92s, e.g. RFC3315, in which cas= e there are no new
security considerations.  If that is so, then the Security Considerati= ons Section should
include (preferably begin with) a statement to the effect that, since this = document only gives instructions for formatting and encoding fields whose u= se has already been specified
in these previous RFC=92s, it presents no additional security consideration= s beyond what is covered in those RFCs.  If that is not the case, you = should say what new security risks are introduced
by *this* draft, e.g. does it enable a use of DHCP that was not possible be= fore and could cause a new type of security risk if DHCP was used without a= uthentication?

Recommendation:  Ready With Issues

Cathy Meadows


Cathe= rine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.mea= dows@nrl.navy.mil

 --_000_D1C53A5B1CA8B1sgundaveciscocom_-- From nobody Fri Jul 10 09:27:33 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B6A1A9174; Fri, 10 Jul 2015 09:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtoaVyISbTGr; Fri, 10 Jul 2015 09:27:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1721A90D2; Fri, 10 Jul 2015 09:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25456; q=dns/txt; s=iport; t=1436545644; x=1437755244; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3mItTEoIW0nWb9FPQI7/J1PLjrr4fq4eQExT/Jy4nmY=; b=Ar3PNk7TkIYnlti8Z7E0V/JfXlnymMJjAry/pwQjVvFNoKZLN4zYaAc/ zPer48i6sq4xu6xCB8IM1nYWZeO5ddFWP1oSZE/nOIlCuFa5E5Oze/Viy 1U4u80BRcbnvGfa/mMpJskiA6cSm30yLYW5pcw0E3Kzk/MEI41WT8DYM8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BgAwAy8Z9V/4kNJK1SBgOCRU1UUw0Guy0Jh2gCgUo4FAEBAQEBAQGBCoQjAQEBAwEtOhIFCQICAQgRAwEBAQsWBwcbFxQJCAIEDgUIiB4I0CkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBItHhCMHCgEGGgUbAQsFBgEGC4MGgRQFjCyFHIJpAaRuJoIHgXRvAYEMOoEEAQEB X-IronPort-AV: E=Sophos; i="5.15,447,1432598400"; d="scan'208,217"; a="14377470" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jul 2015 16:27:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6AGRLLG012331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jul 2015 16:27:21 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Fri, 10 Jul 2015 11:27:21 -0500 From: "Bernie Volz (volz)" To: "Sri Gundavelli (sgundave)" Thread-Topic: secdir review of draft-ietf-dhc-access-network-identifier-08 Thread-Index: AQHQr1cxQKLuwYkBPkiaZWo79FHtqZ3VTZGA//+s30A= Date: Fri, 10 Jul 2015 16:27:20 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CB6B149@xmb-rcd-x04.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.1.196] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1CB6B149xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dhc-access-network-identifier.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:27:29 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1CB6B149xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Something happened at "elements to has no". The IETF is a strange place these days with all of the pervasive monitoring= concerns :). If people can capture relay traffic (since we're only adding = this now there), there's a lot more that they can monitor. Ah well. And, actually the RFC 3315 IPsec requirements for relay traffic can apply h= ere: 21.1. Security of Messages Sent Between Servers and Relay Agents Relay agents and servers that exchange messages securely use the IPsec mechanisms for IPv6 [7]. If a client message is relayed IPsec should also hide this information from pervasive monitoring (though h= ow much IPsec is in use is an open question). Note also that as this is rel= ay to server (or relay to relay) communication, one would hope that most SP= s have taken measures to 'secure' this traffic either by using IPsec or VPN= s. - Bernie From: Sri Gundavelli (sgundave) Sent: Friday, July 10, 2015 12:20 PM To: Catherine Meadows; draft-ietf-dhc-access-network-identifier.all@tools.i= etf.org; secdir@ietf.org; iesg@ietf.org Subject: Re: secdir review of draft-ietf-dhc-access-network-identifier-08 Hi Catherine, Thanks for the review. > However, what needs to be go in the Security Considerations Section is a = discussion of the security risks raised by *this* document and possible mit= igation. The information about DHCP security risks is useful, but not of p= rimary importance. Agree with this comment. The draft is defining some new information elemen= ts that are carried between the DHCP entities and any new security consider= ations are around exposing that data to third parties. "The information elements that this draft is exposing is the client's acces= s-network information. These pertains to the access network to which the cl= ient is attached, such as Access Technology Type (Ex: WLAN, Ethernet...etc)= , Access Point Identity (Name, BSSID), Operator Id/Realm. Exposing these in= formation elements to has no implication on the end-user security. But, in= deployments where this information is considered secure and when such thre= at cannot be mitigated using the currently available security tools, then t= he administrators have to consider disabling this capability on the DHCP en= tities." Is this sufficient ? Regards Sri From: Catherine Meadows > Date: Thursday, June 25, 2015 at 7:56 AM To: "draft-ietf-dhc-access-network-identifier.all@tools.ietf.org" >, "secdir@ietf.org" >, "iesg@ietf.org" > Cc: Catherine Meadows > Subject: secdir review of draft-ietf-dhc-access-network-identifier-08 Resent-From: > Resent-To: > Resent-Date: Thursday, June 25, 2015 at 7:56 AM I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies the format and mechanisms used for encoding network id= entifiers in DHCPv4 and DHCPv6 by defining new access identifier options an= d sub-options. The Security Considerations section gives a discussion of the security risk= s in using DHCP and their mitigation. However, what needs to be go in the = Security Considerations Section is a discussion of the security risks raised by *this* document and= possible mitigation. The information about DHCP security risks is useful,= but not of primary importance. My impression is that this document gives formats for presenting fields who= se use is already discussed in previous RFC's, e.g. RFC3315, in which case = there are no new security considerations. If that is so, then the Security Considerations S= ection should include (preferably begin with) a statement to the effect that, since this = document only gives instructions for formatting and encoding fields whose u= se has already been specified in these previous RFC's, it presents no additional security considerations = beyond what is covered in those RFCs. If that is not the case, you should = say what new security risks are introduced by *this* draft, e.g. does it enable a use of DHCP that was not possible be= fore and could cause a new type of security risk if DHCP was used without a= uthentication? Recommendation: Ready With Issues Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --_000_489D13FBFA9B3E41812EA89F188F018E1CB6B149xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Something happened at = 220;elements to  has no”.

 <= /p>

The IETF is a strange pla= ce these days with all of the pervasive monitoring concerns :). If people c= an capture relay traffic (since we’re only adding this now there), there’s a lot more that they can monitor. Ah well.

 <= /p>

And, actually the RFC 331= 5 IPsec requirements for relay traffic can apply here:

 <= /p>

21.1. Security of Messages S= ent Between Servers and Relay Agents

 

   Relay agents an= d servers that exchange messages securely use the

   IPsec mechanism= s for IPv6 [7].  If a client message is relayed

 <= /p>

IPsec should also hide th= is information from pervasive monitoring (though how much IPsec is in use i= s an open question). Note also that as this is relay to server (or relay to relay) communication, one would hope that most SPs hav= e taken measures to ‘secure’ this traffic either by using IPsec= or VPNs.

 <= /p>

- =          Bernie=

 <= /p>

From: Sri Gund= avelli (sgundave)
Sent: Friday, July 10, 2015 12:20 PM
To: Catherine Meadows; draft-ietf-dhc-access-network-identifier.all@= tools.ietf.org; secdir@ietf.org; iesg@ietf.org
Subject: Re: secdir review of draft-ietf-dhc-access-network-identifi= er-08

 

Hi Catherine,

 

Thanks for the review.=

 

> However, what needs to= be go in the Security Considerations Section is a discussion of the securi= ty risks raised by *this* document and possible mitigation.  The information about DHCP security risks is useful, but not of prim= ary importance.

 

Agree with this comment. Th= e  draft is defining some new information elements that are carried be= tween the DHCP entities and any new security considerations are around exposing that data to third parties.

 

 

"The information eleme= nts that this draft is exposing is the client’s access-network inform= ation. These pertains to the access network to which the client is attached, such as Access Technology Type (Ex: WLAN, Ethernet…etc), A= ccess Point Identity (Name, BSSID), Operator Id/Realm. Exposing these infor= mation elements to  has no implication on the end-user security. But, = in deployments where this information is considered secure and when such threat cannot be mitigated using the currently availa= ble security tools, then the administrators have to consider disabling this= capability on the DHCP entities."

 

 

Is this sufficient ?

 

 

Regards

Sri

 

 

 

 

 

I have reviewed this docume= nt as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the  IESG.  These comments were written primarily for the benefit of the&nb= sp;
security area directors.  Document editors and WG chairs should treat&= nbsp;
these comments just like any other last call comments.


This draft specifies the format and mechanisms used for encoding network id= entifiers in DHCPv4 and DHCPv6 by defining new access identifier options an= d sub-options.
The Security Considerations section gives a discussion of the security risk= s in using DHCP and their mitigation.  However, what needs to be go in= the Security Considerations
Section is a discussion of the security risks raised by *this* document and= possible mitigation.  The information about DHCP security risks is us= eful, but not of primary importance.

My impression is that this document gives formats for presenting fields who= se use is already discussed in previous RFC’s, e.g. RFC3315, in which= case there are no new
security considerations.  If that is so, then the Security Considerati= ons Section should
include (preferably begin with) a statement to the effect that, since this = document only gives instructions for formatting and encoding fields whose u= se has already been specified
in these previous RFC’s, it presents no additional security considera= tions beyond what is covered in those RFCs.  If that is not the case, = you should say what new security risks are introduced
by *this* draft, e.g. does it enable a use of DHCP that was not possible be= fore and could cause a new type of security risk if DHCP was used without a= uthentication?

Recommendation:  Ready With Issues

 

Cathy Meadows

 

--_000_489D13FBFA9B3E41812EA89F188F018E1CB6B149xmbrcdx04ciscoc_-- From nobody Fri Jul 10 09:35:26 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D3B1A908F; Fri, 10 Jul 2015 09:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0wVd_Xz_9iP; Fri, 10 Jul 2015 09:35:22 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10B21A0025; Fri, 10 Jul 2015 09:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28091; q=dns/txt; s=iport; t=1436546122; x=1437755722; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HNcJ4dQcVRQAHoHKwc7t3TYQ3nLa1zoC2hhtZ6NUMhA=; b=ZbpIYzTdPj05aAdfJg9BBYy9t3B/enl3ehHlK/QcY8sl2lHAA/JS8dtz K4OjpFzChirtYrmXw87+MqzqDHOgYRYNCmpUVbtGu+dqwpYMvT+mBPZ0O H1vpj/eA4mK8uxpvXx32zNQPsTnd2AakCCCUntW9vGdFkHb6OsBidBOn/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BgAwDP859V/5tdJa1SBgOCRU1UUw0Guy0Jh2gCgUo4FAEBAQEBAQGBCoQjAQEBAwEtOhIFCQICAQgRAwEBASEHBxsXFAkIAgQOBYgmCNAwAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSLR4QjBwoBBh8bAQsFBgEGC4QaBYwshRyCaQGMA5hrJoIHgXRvAYEMOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,447,1432598400"; d="scan'208,217";a="167550504" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 16:35:20 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6AGZKvx009583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jul 2015 16:35:20 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.38]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 10 Jul 2015 11:35:20 -0500 From: "Sri Gundavelli (sgundave)" To: "Bernie Volz (volz)" Thread-Topic: secdir review of draft-ietf-dhc-access-network-identifier-08 Thread-Index: AQHQr1cxQgFsakfaFEigKP+HYJIb8p3U2DaAgAB3gwD//4zhAA== Date: Fri, 10 Jul 2015 16:35:19 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E1CB6B149@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CB6B149@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.32.246.217] Content-Type: multipart/alternative; boundary="_000_D1C540E71CA8DBsgundaveciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dhc-access-network-identifier.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:35:25 -0000 --_000_D1C540E71CA8DBsgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > =93Exposing these information elements to < > " Strange =85 it disappeared. I was debating which Govt/Organization :) to point to, but then got distrac= ted. Regards Sri From: "Bernie Volz (volz)" > Date: Friday, July 10, 2015 at 9:27 AM To: Sri Gundavelli > Cc: Catherine Meadows >, "draft-ietf-dhc-access-network-identifier.all@tools.iet= f.org" = >, "secdir@ietf.org" >, "iesg@iet= f.org" > Subject: RE: secdir review of draft-ietf-dhc-access-network-identifier-08 Something happened at =93elements to has no=94. The IETF is a strange place these days with all of the pervasive monitoring= concerns :). If people can capture relay traffic (since we=92re only addin= g this now there), there=92s a lot more that they can monitor. Ah well. And, actually the RFC 3315 IPsec requirements for relay traffic can apply h= ere: 21.1. Security of Messages Sent Between Servers and Relay Agents Relay agents and servers that exchange messages securely use the IPsec mechanisms for IPv6 [7]. If a client message is relayed IPsec should also hide this information from pervasive monitoring (though h= ow much IPsec is in use is an open question). Note also that as this is rel= ay to server (or relay to relay) communication, one would hope that most SP= s have taken measures to =91secure=92 this traffic either by using IPsec or= VPNs. - Bernie From: Sri Gundavelli (sgundave) Sent: Friday, July 10, 2015 12:20 PM To: Catherine Meadows; draft-ietf-dhc-access-network-identifier.all@tools.i= etf.org= ; secdir@ietf.org; iesg@ietf.org Subject: Re: secdir review of draft-ietf-dhc-access-network-identifier-08 Hi Catherine, Thanks for the review. > However, what needs to be go in the Security Considerations Section is a = discussion of the security risks raised by *this* document and possible mit= igation. The information about DHCP security risks is useful, but not of p= rimary importance. Agree with this comment. The draft is defining some new information elemen= ts that are carried between the DHCP entities and any new security consider= ations are around exposing that data to third parties. "The information elements that this draft is exposing is the client=92s acc= ess-network information. These pertains to the access network to which the = client is attached, such as Access Technology Type (Ex: WLAN, Ethernet=85et= c), Access Point Identity (Name, BSSID), Operator Id/Realm. Exposing these = information elements to has no implication on the end-user security. But, = in deployments where this information is considered secure and when such th= reat cannot be mitigated using the currently available security tools, then= the administrators have to consider disabling this capability on the DHCP = entities." Is this sufficient ? Regards Sri From: Catherine Meadows > Date: Thursday, June 25, 2015 at 7:56 AM To: "draft-ietf-dhc-access-network-identifier.all@tools.ietf.org" >, "secdir@ietf.org" >, "iesg@ietf.org" > Cc: Catherine Meadows > Subject: secdir review of draft-ietf-dhc-access-network-identifier-08 Resent-From: > Resent-To: > Resent-Date: Thursday, June 25, 2015 at 7:56 AM I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies the format and mechanisms used for encoding network id= entifiers in DHCPv4 and DHCPv6 by defining new access identifier options an= d sub-options. The Security Considerations section gives a discussion of the security risk= s in using DHCP and their mitigation. However, what needs to be go in the = Security Considerations Section is a discussion of the security risks raised by *this* document and= possible mitigation. The information about DHCP security risks is useful,= but not of primary importance. My impression is that this document gives formats for presenting fields who= se use is already discussed in previous RFC=92s, e.g. RFC3315, in which cas= e there are no new security considerations. If that is so, then the Security Considerations S= ection should include (preferably begin with) a statement to the effect that, since this = document only gives instructions for formatting and encoding fields whose u= se has already been specified in these previous RFC=92s, it presents no additional security consideration= s beyond what is covered in those RFCs. If that is not the case, you shoul= d say what new security risks are introduced by *this* draft, e.g. does it enable a use of DHCP that was not possible be= fore and could cause a new type of security risk if DHCP was used without a= uthentication? Recommendation: Ready With Issues Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --_000_D1C540E71CA8DBsgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
> =93Exposing these information elements to < > "

Strange =85 it disappeared.

I was debating which Govt/Organization :) to point to, but then got di= stracted.


Regards
Sri


From: "Bernie Volz (volz)"= ; <volz@cisco.com>
Date: Friday, July 10, 2015 at 9:27= AM
To: Sri Gundavelli <sgundave@cisco.com>
Cc: Catherine Meadows <catherine.meadows@nrl.navy.mil>, "draft-ietf-dhc-access-network-identifier.all@tools.ietf.o= rg" <draft-ietf-dhc-access-network-identifier.all@tools.ietf.org>= ;, "secdir@ietf.org" <<= a href=3D"mailto:secdir@ietf.org">secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: RE: secdir review of draft= -ietf-dhc-access-network-identifier-08

Something happened at =93elements to  has no=94.=

 

The IETF is a strange place these d= ays with all of the pervasive monitoring concerns :). If people can capture= relay traffic (since we=92re only adding this now there), there=92s a lot more that they can monitor. Ah well.=

 

And, actually the RFC 3315 IPsec re= quirements for relay traffic can apply here:

 

21.1. Security of Messages Sent Betw= een Servers and Relay Agents

 

   Relay agents and server= s that exchange messages securely use the

   IPsec mechanisms for IP= v6 [7].  If a client message is relayed

 

IPsec should also hide this informa= tion from pervasive monitoring (though how much IPsec is in use is an open = question). Note also that as this is relay to server (or relay to relay) communication, one would hope that mos= t SPs have taken measures to =91secure=92 this traffic either by using IPse= c or VPNs.

 

-          Bernie

 

From: Sri Gundavelli (sgundave)
Sent: Friday, July 10, 2015 12:20 PM
To: Catherine Meadows; draft-ietf-dhc-access-network-identifier.all@tools.ietf.org; secdir@ietf.org; iesg@ietf.org
Subject: Re: secdir review of draft-ietf-dhc-access-network-identifi= er-08

 

Hi Catherine,

 

Thanks for the review.

 

> However, what needs to be go in the Sec= urity Considerations Section is a discussion of the security risks raised b= y *this* document and possible mitigation.  The information about DHCP security risks is useful, but not of prim= ary importance.

 

Agree with this comment. The  draft is = defining some new information elements that are carried between the DHCP en= tities and any new security considerations are around exposing that data to third parties.

 

 

"The information elements that this dra= ft is exposing is the client=92s access-network information. These pertains= to the access network to which the client is attached, such as Access Technology Type (Ex: WLAN, Ethernet=85etc), Ac= cess Point Identity (Name, BSSID), Operator Id/Realm. Exposing these inform= ation elements to  has no implication on the end-user security. But, i= n deployments where this information is considered secure and when such threat cannot be mitigated using the curre= ntly available security tools, then the administrators have to consider dis= abling this capability on the DHCP entities."

 

 

Is this sufficient ?

 

 

Regards

Sri

 

 

 

 

 

I have reviewed this document as part of the= security directorate's 
ongoing effort to review all IETF documents being processed by the  IESG.  These comments were written primarily for the benefit of the&nb= sp;
security area directors.  Document editors and WG chairs should treat&= nbsp;
these comments just like any other last call comments.


This draft specifies the format and mechanisms used for encoding network id= entifiers in DHCPv4 and DHCPv6 by defining new access identifier options an= d sub-options.
The Security Considerations section gives a discussion of the security risk= s in using DHCP and their mitigation.  However, what needs to be go in= the Security Considerations
Section is a discussion of the security risks raised by *this* document and= possible mitigation.  The information about DHCP security risks is us= eful, but not of primary importance.

My impression is that this document gives formats for presenting fields who= se use is already discussed in previous RFC=92s, e.g. RFC3315, in which cas= e there are no new
security considerations.  If that is so, then the Security Considerati= ons Section should
include (preferably begin with) a statement to the effect that, since this = document only gives instructions for formatting and encoding fields whose u= se has already been specified
in these previous RFC=92s, it presents no additional security consideration= s beyond what is covered in those RFCs.  If that is not the case, you = should say what new security risks are introduced
by *this* draft, e.g. does it enable a use of DHCP that was not possible be= fore and could cause a new type of security risk if DHCP was used without a= uthentication?

Recommendation:  Ready With Issues

 

Cathy Meadows

 
--_000_D1C540E71CA8DBsgundaveciscocom_-- From nobody Fri Jul 10 10:27:57 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3901A020D; Fri, 10 Jul 2015 10:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXF3R-y8q_Yd; Fri, 10 Jul 2015 10:27:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D731A0187; Fri, 10 Jul 2015 10:27:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 65EE6BE5D; Fri, 10 Jul 2015 18:27:49 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6v9dd0mYgpC; Fri, 10 Jul 2015 18:27:48 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.23.241]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9D7E9BE5C; Fri, 10 Jul 2015 18:27:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436549268; bh=imulHR88q9sZGW5TPNxNZYEC1h1/gl+GHSxzwvEmkXc=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=P4HyFQYwttFlsiiXQDunsdxCdtfcyM+e1e+ms4mVXjh3n2VD6mZC37VsfbaltlQt8 9YeFvpyQ8MCQ+JxgwMqnTBP4MKrPA3TYy7q5/qi4VU4Lv3fhGwcjsqsS8OyyY8G/Ol 7930VN0iLTHPJIsa4np5ICzfzKIJG80h+H1pHgCA= Message-ID: <55A00090.6060303@cs.tcd.ie> Date: Fri, 10 Jul 2015 18:27:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Bernie Volz (volz)" , "Sri Gundavelli (sgundave)" References: <489D13FBFA9B3E41812EA89F188F018E1CB6B149@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CB6B149@xmb-rcd-x04.cisco.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-dhc-access-network-identifier.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 17:27:53 -0000 Hiya, On 10/07/15 17:27, Bernie Volz (volz) wrote: > IPsec should also hide this information from pervasive monitoring > (though how much IPsec is in use is an open question). Note also that > as this is relay to server (or relay to relay) communication, one > would hope that most SPs have taken measures to 'secure' this traffic > either by using IPsec or VPNs. Do we have any data as to whether or not such protection does get deployed? I'd not be surprised if there's not much public, but if there were it'd be good to know. I also believe we have had reported cases where pieces of the network infrastructure of various kinds of operator have been targeted for PM purposes, so while yes, it is really strange that someone would want to do that, it seems to be a real, and not notional, threat. Ta, S. From nobody Fri Jul 10 10:43:39 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B282E1A036E; Fri, 10 Jul 2015 10:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO6gd33DQ5ZI; Fri, 10 Jul 2015 10:43:33 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10ADE1A0366; Fri, 10 Jul 2015 10:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2542; q=dns/txt; s=iport; t=1436550213; x=1437759813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JezFCv1Il0IQQ3hVKnNT28MimkicUWO1/Rw46GugUpU=; b=PaTeLIhej9u+dtmn1EAWlM0w/Sm0+OBGXk8VlDjyArO1mgHN+i7nX00i zyJXjaTtVQxP1BUUu2fRHT/xQ6Ho1BPha2BX+PMDdm6iElNjW4upvg1lv kcGoW/PFfctXnuHZqm505vPDQacZi+i9xdBemEVnpr9CfTxm9o5GPicRA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C0AwD8AqBV/4ENJK1bgxKBNAaDGrgRCYdqAhyBLjgUAQEBAQEBAYEKhCMBAQEEIxFFDAQCAQgRBAEBAQICBh0DAgICMBQBCAgCBAENBQiIJrl4ljgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKKoQ7GhYbBwaCYi+BFAEElDEBjUKTTYNfJoN7bwGBRoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,448,1432598400"; d="scan'208";a="167569885" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 17:43:30 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6AHhRPE009570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jul 2015 17:43:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 10 Jul 2015 12:43:27 -0500 From: "Bernie Volz (volz)" To: Stephen Farrell , "Sri Gundavelli (sgundave)" Thread-Topic: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08 Thread-Index: AQHQr1cxQKLuwYkBPkiaZWo79FHtqZ3VTZGA//+s30CAAGYpAP//rZEg Date: Fri, 10 Jul 2015 17:43:26 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CB6B426@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1CB6B149@xmb-rcd-x04.cisco.com> <55A00090.6060303@cs.tcd.ie> In-Reply-To: <55A00090.6060303@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.1.196] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dhc-access-network-identifier.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 17:43:34 -0000 SSBhbSBub3QgYXdhcmUgb2Ygc3VjaCBkYXRhLiBNeSBndWVzcyBpcyB0aGF0IG1vc3QgU1BzIHBs YWNlIHRoaXMga2luZCBvZiB0cmFmZmljIGluIHdoYXQgdGhleSBob3BlIHRvIGJlIGFuIGlzb2xh dGVkIG5ldHdvcmsgKGkuZS4sIGJlaGluZCBmaXJld2FsbHMsIC4uLikuDQoNCkFsc28sIG11Y2gg b2YgdGhpcyBkYXRhIGlzIHByZXR0eSBlYXN5IHRvIGZpbmQgYW55d2F5IC4uLiBTU0lEcyBhcmUg bW9zdGx5IGJyb2FkY2FzdCAob3IgZWFzeSB0byBzbm9vcCBmb3IpLCB3aGljaCBtb2JpbGUgb3Bl cmF0b3IgeW91IHVzZSBpcyBwcm9iYWJseSBkaXNjb3ZlcmFibGUgaW4gc2Vjb25kcyAoaGVjayBJ IGJldCB5b3XigJlkIGFuc3dlciBpZiBJIGFza2VkLCBvciBpZiBJIGhhZCB5b3VyIG51bWJlciBh IGdvb2dsZSBxdWVyeSB3b3VsZCBwcm9iYWJseSB0ZWxsIG1lIC4uLikuIFNvLCBJJ20gbm90IHJl YWxseSBzdXJlIGhvdyBjcml0aWNhbCB0aGlzIGluZm9ybWF0aW9uIHRlbmRzIHRvIGJlLiBCdXQs IHlldCBwcm90ZWN0aW5nIGl0IGlzIGJldHRlciB0aGFuIG5vdCBwcm90ZWN0aW5nIGl0LiBCdXQg SSB0aGluayBzdGVwcyBzaG91bGQgaGF2ZSBiZWVuIHRha2VuIGZvciB0aGUgb3RoZXIgZGF0YSBp biBESENQIChyZWxheSB0byBzZXJ2ZXIpLg0KDQotIEJlcm5pZQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZV0gDQpTZW50OiBGcmlkYXksIEp1bHkgMTAsIDIwMTUgMToyOCBQTQ0KVG86IEJl cm5pZSBWb2x6ICh2b2x6KTsgU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKQ0KQ2M6IGRyYWZ0LWll dGYtZGhjLWFjY2Vzcy1uZXR3b3JrLWlkZW50aWZpZXIuYWxsQHRvb2xzLmlldGYub3JnOyBpZXNn QGlldGYub3JnOyBzZWNkaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2VjZGlyXSBzZWNkaXIg cmV2aWV3IG9mIGRyYWZ0LWlldGYtZGhjLWFjY2Vzcy1uZXR3b3JrLWlkZW50aWZpZXItMDgNCg0K DQpIaXlhLA0KDQpPbiAxMC8wNy8xNSAxNzoyNywgQmVybmllIFZvbHogKHZvbHopIHdyb3RlOg0K PiBJUHNlYyBzaG91bGQgYWxzbyBoaWRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSBwZXJ2YXNpdmUg bW9uaXRvcmluZyANCj4gKHRob3VnaCBob3cgbXVjaCBJUHNlYyBpcyBpbiB1c2UgaXMgYW4gb3Bl biBxdWVzdGlvbikuIE5vdGUgYWxzbyB0aGF0IA0KPiBhcyB0aGlzIGlzIHJlbGF5IHRvIHNlcnZl ciAob3IgcmVsYXkgdG8gcmVsYXkpIGNvbW11bmljYXRpb24sIG9uZSANCj4gd291bGQgaG9wZSB0 aGF0IG1vc3QgU1BzIGhhdmUgdGFrZW4gbWVhc3VyZXMgdG8gJ3NlY3VyZScgdGhpcyB0cmFmZmlj IA0KPiBlaXRoZXIgYnkgdXNpbmcgSVBzZWMgb3IgVlBOcy4NCg0KRG8gd2UgaGF2ZSBhbnkgZGF0 YSBhcyB0byB3aGV0aGVyIG9yIG5vdCBzdWNoIHByb3RlY3Rpb24gZG9lcyBnZXQgZGVwbG95ZWQ/ IEknZCBub3QgYmUgc3VycHJpc2VkIGlmIHRoZXJlJ3Mgbm90IG11Y2ggcHVibGljLCBidXQgaWYg dGhlcmUgd2VyZSBpdCdkIGJlIGdvb2QgdG8ga25vdy4NCg0KSSBhbHNvIGJlbGlldmUgd2UgaGF2 ZSBoYWQgcmVwb3J0ZWQgY2FzZXMgd2hlcmUgcGllY2VzIG9mIHRoZSBuZXR3b3JrIGluZnJhc3Ry dWN0dXJlIG9mIHZhcmlvdXMga2luZHMgb2Ygb3BlcmF0b3IgaGF2ZSBiZWVuIHRhcmdldGVkIGZv ciBQTSBwdXJwb3Nlcywgc28gd2hpbGUgeWVzLCBpdCBpcyByZWFsbHkgc3RyYW5nZSB0aGF0IHNv bWVvbmUgd291bGQgd2FudCB0byBkbyB0aGF0LCBpdCBzZWVtcyB0byBiZSBhIHJlYWwsIGFuZCBu b3Qgbm90aW9uYWwsIHRocmVhdC4NCg0KVGEsDQpTLg0K From nobody Sat Jul 11 09:43:53 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F4A1A9005; Sat, 11 Jul 2015 09:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDphNiOW59vO; Sat, 11 Jul 2015 09:43:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5090D1A9004; Sat, 11 Jul 2015 09:43:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2880E284D6A; Sat, 11 Jul 2015 16:43:49 +0000 (UTC) Date: Sat, 11 Jul 2015 16:43:49 +0000 From: Viktor Dukhovni To: Tina TSOU Message-ID: <20150711164349.GP28047@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "draft-ietf-dane-ops.all@tools.ietf.org" , IETF Security Directorate , "iesg@ietf.org" , dane@ietf.org Subject: Re: [secdir] SecDir Review of draft-ietf-dane-ops-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 16:43:52 -0000 > * Meta: I would have liked to find (if anything, in an appendix) the > rationale for he changes being proposed by this document. Since the changes > are said to originate on operational experience, I think that codifying > the lessons (problems found, and a rationale for the workarounds). There > seems to be a bit of this throughout the document, but not for most of > the changes proposed. I'll reread the draft and see where additional rationale text might usefully be added. Specific pointers to such places, if anyone has any in mind, would be great. > * Section 4.8, page 8: > > Therefore, when a TLS client > > authenticates the TLS server via a TLSA record with usage DANE-EE(3), > > CT checks SHOULD NOT be performed. > > What are the valid reasons for performing th CT checks? If there are not > any, why not make this requirement a "MUST NOT" instead? CT checks are designed to help keep public CAs honest (detect surreptitiously misissued certificates). With DANE-EE(3), no public CA is involved, so CT (for the X.509 WebPKI) is logically out of scope. If there is some day a CT for DNSSEC (or just DANE records validated via DNSSEC), then this new CT might be applicable to keep registries from signing rogue DS RRs, rogue evidence of non-existence of DS RRs or rogue absense of delegation of a domain. The present the experimental CT does not apply to DNSSEC. Also see changes in the CT language in -13. > * Section 5.1, page 10: > > Servers SHOULD NOT rely on > > "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication > > data for raw public keys. I am open to MUST NOT, if that's better. Note that the impact of such inadvisable reliance, is that some clients capable of using raw public keys (but also capable of handling certificate chains) might choose to not do so. And other clients, that support only raw public keys, might go the extra mile and support extracing the public key from a "3 0 0" record, assuming they can parse X.509 certificates (part of the rationale for RPK is to allow clients to shed such code). So using "3 0 0" reduces opportunities to use RPK, and might fail to interoperate with RPK-only DANE clients that don't go the extra mile to support "3 0 0" (e.g. they may lack code to parse X.509 certificates). Is that enough reason to say "MUST NOT rely"? Is 2119 language appropriate here, we're not telling servers to not publish "3 0 0", rather we're telling them that if they do, they can't (must not) expect RPK to work. Is "MUST NOT rely" or "SHOULD NOT rely" a suitable means to say that, or should this be downcased to non-normative english text? > * Section 7, page 17: > > > Though CNAMEs are illegal on the right hand side of most indirection > > records, such as MX and SRV records, they are supported by some > > implementations. For example, if the MX or SRV host is a CNAME > > alias, some implementations may "chase" the CNAME. If they do, they > > SHOULD use the target hostname as the preferred TLSA base domain as > > described above (and if the TLSA records are found there, use the > > CNAME expanded domain also in SNI and certificate name checks). > > If CNAMES on the right hand side of most indirection records are illegal, > why trying to process them in the first place? Because this "illegal" configuration is both widely supported, and actually practiced, sometimes by accident. There are a lot of domains with boiler-plate records configured by naive registrars or users along the lines of: example.com. IN A 192.0.2.1 example.com. IN MX 0 mail.example.com. ; Note, no explicit mail.example.com RRsets *.example.com IN CNAME example.com. What this amounts to is that that the MX host for example.com is mail.example.com which is in turn a CNAME right back to example.com. Most MTAs seem to support this, RFCs notwithstanding. So the draft explains what to do when such records are supported. (A concession to the fact that MX hosts that are CNAMES are illegal in theory, but not in practice). > * Section 9, page 21: > > This order SHOULD be configurable by the MTA > > administrator. > > Please expand "MTA". Also, why make the explanation mail-specific? Fixed in -13. > * Section 13, page 26: > > The signature validity period for TLSA records should also not be too > > long. Signed DNSSEC records can be replayed by an MiTM attacker > > provided the signatures have not yet expired. > > Please expand "MiTM". This was done in the introduction, but I notice a case difference (MiTM vs MITM). This should probably be made consistent in the final version. Queued for -14. > Section 1.1, Page 4: > > difficult to host multiple Customer Domains at the same IP- > > addressed based TLS service endpoint (i.e., "secure virtual > > hosting"). > > s/addressed based/address-based/ Thanks, queued for -14. > * Section 5.1, page 9: > > > With DANE-EE(3) servers that know all the connecting clients are > > making use of DANE, they need not employ SNI > > I'm having trouble parsing this sentence... could you please take a look and tweak it if necessary? This was changed in -13: If a server uses just DANE-EE(3) TLSA records, and all its clients are DANE clients, the server need not employ SNI (i.e., they may ignore the client's SNI message) even when the server is known via multiple domain names that would otherwise require separate certificates. I notice a singular/plural mismatch above, so in -14 I've queued-up s/they may/it may/. Is the final result better? -- Viktor. From nobody Sun Jul 12 19:54:22 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0921ACD80; Sun, 12 Jul 2015 19:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AizfT2seN91C; Sun, 12 Jul 2015 19:54:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8553D1ACD7B; Sun, 12 Jul 2015 19:54:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mV8h363c5z1H8; Mon, 13 Jul 2015 04:54:11 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=CBca+BIO X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id h2FJR7k9N15E; Mon, 13 Jul 2015 04:54:10 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Jul 2015 04:54:10 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 132F780042; Sun, 12 Jul 2015 22:54:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1436756049; bh=KoykGpZ+3auXyfoF/MTusWD5vv79qjP1tVtmRETvXaU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CBca+BIOztBym8h6MSJqYz3z6tz9ONqOX3APTGKajBQQ2/TprXO7kB559NTmR4zxH ePXNeuBqbX1HZzawMy+ENau3i9o111weLwEd0tJ0bwaZSlysXVZAm0OqIcyVcmS/di gSAzsM5CzUUgISdzsW2/8F5bKm5gaCQ8ZlZWFC2Y= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6D2s7Ya012828; Sun, 12 Jul 2015 22:54:08 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 12 Jul 2015 22:54:07 -0400 (EDT) From: Paul Wouters To: Viktor Dukhovni In-Reply-To: <20150711164349.GP28047@mournblade.imrryr.org> Message-ID: References: <20150711164349.GP28047@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "draft-ietf-dane-ops.all@tools.ietf.org" , IETF Security Directorate , "iesg@ietf.org" , dane@ietf.org Subject: Re: [secdir] [dane] SecDir Review of draft-ietf-dane-ops-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 02:54:17 -0000 On Sat, 11 Jul 2015, Viktor Dukhovni wrote: >> * Section 4.8, page 8: >>> Therefore, when a TLS client >>> authenticates the TLS server via a TLSA record with usage DANE-EE(3), >>> CT checks SHOULD NOT be performed. >> >> What are the valid reasons for performing th CT checks? If there are not >> any, why not make this requirement a "MUST NOT" instead? CT auditors log EE-certs. Checking the CT logs also provides a way to signal rogue EE-certs to the original webserver via a gossip/client protocol. So I would not say Usage 3 should never check the CT logs. > CT checks are designed to help keep public CAs honest (detect > surreptitiously misissued certificates). It's a litte more than just that: Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates. The logs are publicly auditable so that it is possible for anyone to verify the correctness of each log and to monitor when new certificates are added to it. > With DANE-EE(3), no public > CA is involved, so CT (for the X.509 WebPKI) is logically out of > scope. I don't think that whether or not public/private CA's are in used in the TLSA record matters. A client that wants to confirm an EE-cert via DNSSEC _and_ CT should be able to do so. >> * Section 5.1, page 10: >>> Servers SHOULD NOT rely on >>> "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication >>> data for raw public keys. > > I am open to MUST NOT, if that's better. > > Note that the impact of such inadvisable reliance, is that some > clients capable of using raw public keys (but also capable of > handling certificate chains) might choose to not do so. And other > clients, that support only raw public keys, might go the extra mile > and support extracing the public key from a "3 0 0" record, assuming > they can parse X.509 certificates (part of the rationale for RPK > is to allow clients to shed such code). You keep trying to force different policies for raw public keys versus (possibly throw away) x509 container based public keys. Because we know software will only upgrade over a very long slow time, we know there is going to be a substantial amount of time when "basically" raw keys will go into a throw-away x509 container. Therefor, as I said before, it is not wise to differentiate between the two. An EE-cert could be a raw public key in disguise purely for compatibility reasons. > So using "3 0 0" reduces opportunities to use RPK, and might fail > to interoperate with RPK-only DANE clients that don't go the extra > mile to support "3 0 0" (e.g. they may lack code to parse X.509 > certificates). Is that enough reason to say "MUST NOT rely"? > > Is 2119 language appropriate here, we're not telling servers to > not publish "3 0 0", rather we're telling them that if they do, > they can't (must not) expect RPK to work. Is "MUST NOT rely" > or "SHOULD NOT rely" a suitable means to say that, or should > this be downcased to non-normative english text? No, I think you should not try to dictate the local policy behaviour. > This was changed in -13: > > If a server uses just DANE-EE(3) TLSA records, and all its clients > are DANE clients, the server need not employ SNI (i.e., they may > ignore the client's SNI message) even when the server is known via > multiple domain names that would otherwise require separate > certificates. I am confused. If DANE is only talking about how to verify a certain certificate received over TLS, I do not think this document should modify the TLS protocol with respect to SNI. It's out of scope. Paul From nobody Sun Jul 12 20:29:59 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220E71A0358; Sun, 12 Jul 2015 20:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyWCCogufohP; Sun, 12 Jul 2015 20:29:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAF51A0354; Sun, 12 Jul 2015 20:29:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C439E284D6A; Mon, 13 Jul 2015 03:29:50 +0000 (UTC) Date: Mon, 13 Jul 2015 03:29:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150713032950.GI28047@mournblade.imrryr.org> References: <20150711164349.GP28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF Security Directorate , "iesg@ietf.org" Subject: Re: [secdir] [dane] SecDir Review of draft-ietf-dane-ops-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 03:29:54 -0000 On Sun, Jul 12, 2015 at 10:54:07PM -0400, Paul Wouters wrote: > >>What are the valid reasons for performing th CT checks? If there are not > >>any, why not make this requirement a "MUST NOT" instead? > > CT auditors log EE-certs. Checking the CT logs also provides a way to > signal rogue EE-certs to the original webserver via a gossip/client > protocol. So I would not say Usage 3 should never check the CT logs. DANE-EE(3) certs are often self-signed, and there's no way to control the "spam" problem on the CT logs with DANE-EE(3). Furthermore such a certificate is only ever "rogue" if DNSSEC is compromised to publish rogue TLSA RRs. So the "CA" we're keeping honest is the zone signing the TLSA RRset. I don't believe we have a CT specification for that yet. > >CT checks are designed to help keep public CAs honest (detect > >surreptitiously misissued certificates). > > It's a litte more than just that: > > Certificate transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, append-only, untrusted > logs of all issued certificates. The logs are publicly auditable so > that it is possible for anyone to verify the correctness of each log > and to monitor when new certificates are added to it. Well, with DANE-EE(3) there is no X.509 trusted issuer to keep honest. With "3 1 1" an attacker can replace anything in the certificate other than the public key, giving an astronomical number of potential certificates to that match the TLSA RRset and might be logged. It makes no sense to log the "certificate" it is just excess baggage. The TLSA RRset, with DS/DNSKEY/RRSIG records all the way back to the root ZONE make a lot more sense here, but there is no CT spec for that I am aware of. > > With DANE-EE(3), no public > >CA is involved, so CT (for the X.509 WebPKI) is logically out of > >scope. > > I don't think that whether or not public/private CA's are in used in > the TLSA record matters. A client that wants to confirm an EE-cert > via DNSSEC _and_ CT should be able to do so. Perhaps if it were possible, but I'm afraid it is not. From the CT FAQ: Each CT log will have the power to choose which CAs it accepts certificates from. This could lead to a situation where a Root Certificate is trusted by one or more browsers, but is not permitted to submit newly issued certs to any of the trusted CT logs. How can we ensure that this sort of situation doesn't happen? We recommend that all logs accept a liberal list of CAs including at least the Apple, Microsoft and Opera roots. The CA check is for anti-spam and attribution only, so we do not foresee this becoming a problem in practice. Thus CT logs will not accept self-signed, domain-issued, ... certificates. Since CT is just keeping the public CAs honest, and DANE-EE(3) or DANE-TA(2) with a private CA do not use public CAs, CT simply does not apply. > >So using "3 0 0" reduces opportunities to use RPK, and might fail > >to interoperate with RPK-only DANE clients that don't go the extra > >mile to support "3 0 0" (e.g. they may lack code to parse X.509 > >certificates). Is that enough reason to say "MUST NOT rely"? > > > >Is 2119 language appropriate here, we're not telling servers to > >not publish "3 0 0", rather we're telling them that if they do, > >they can't (must not) expect RPK to work. Is "MUST NOT rely" > >or "SHOULD NOT rely" a suitable means to say that, or should > >this be downcased to non-normative english text? > > No, I think you should not try to dictate the local policy behaviour. You're misreading the text. It is warning server operators that "3 0 0" is less suitable for serving RPK clients (if that's what the server wants) than "3 1 X" is. This is true, because clients that want to deal with just keys would have to support extracing those from a "3 0 0" RRset, where-as with "3 1 X" the key or its digest is right there. Thus no local policy is dictated, rather server operators are advised to be conservative in what they send. > >This was changed in -13: > > > > If a server uses just DANE-EE(3) TLSA records, and all its clients > > are DANE clients, the server need not employ SNI (i.e., they may > > ignore the client's SNI message) even when the server is known via > > multiple domain names that would otherwise require separate > > certificates. > > I am confused. If DANE is only talking about how to verify a certain > certificate received over TLS, I do not think this document should > modify the TLS protocol with respect to SNI. It's out of scope. You're confused. The server is free to ignore the client's SNI extension when it has a single certificate that works for all hosted domains, because clients authenticate the server via the certificate or key digest, and don't care about what name is in the certificate. We're not modifying TLS, we're explaining that the server is free to ignore the client's SNI extension. -- Viktor. From nobody Sun Jul 12 20:37:21 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366521A036C; Sun, 12 Jul 2015 20:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhMSrGZKdNio; Sun, 12 Jul 2015 20:37:12 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64E11A036B; Sun, 12 Jul 2015 20:37:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mV9dd49G7z20h; Mon, 13 Jul 2015 05:37:09 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=R21MlG5w X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cQc7989KHoBK; Mon, 13 Jul 2015 05:37:08 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Jul 2015 05:37:08 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C2BB1800EF; Sun, 12 Jul 2015 23:37:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1436758627; bh=wmp/36CtovY312LYOcFNVmQzhyvMqdwOPwgr/mPFxdA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=R21MlG5wolAnJKO+w9x1l/oztwImaLZlCKWHTvom/UZVXamVbmhQ3haK0IlPvpzGF SU9g09p8OMCSI+ae/ca0h43XzHGEyg02afnGfRhvon1J+V0HM6ezJgBwMpBIN0G6DS piv3KQZ2n/nDd69u61cb/eTciofY9iRiRtT1UFjQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6D3b7MH014969; Sun, 12 Jul 2015 23:37:07 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 12 Jul 2015 23:37:07 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150713032950.GI28047@mournblade.imrryr.org> Message-ID: References: <20150711164349.GP28047@mournblade.imrryr.org> <20150713032950.GI28047@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "iesg@ietf.org" , IETF Security Directorate Subject: Re: [secdir] [dane] SecDir Review of draft-ietf-dane-ops-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 03:37:13 -0000 On Mon, 13 Jul 2015, Viktor Dukhovni wrote: >> CT auditors log EE-certs. Checking the CT logs also provides a way to >> signal rogue EE-certs to the original webserver via a gossip/client >> protocol. So I would not say Usage 3 should never check the CT logs. > > DANE-EE(3) certs are often self-signed, and there's no way to > control the "spam" problem on the CT logs with DANE-EE(3). You don't know what audit logs will use for policies. Perhaps some audit logs will be dedicated to only self-signed certs. I do not think the dane document should dictate CT behaviour. > Furthermore such a certificate is only ever "rogue" if DNSSEC is > compromised to publish rogue TLSA RRs. Not if they use a CT log for prepublishing somehow. Although that is unlikely to happen with SCT's without a CA, I still think you should not make those decisions on this document. >> I don't think that whether or not public/private CA's are in used in >> the TLSA record matters. A client that wants to confirm an EE-cert >> via DNSSEC _and_ CT should be able to do so. > > Perhaps if it were possible, but I'm afraid it is not. From the > CT FAQ: > Thus CT logs will not accept self-signed, domain-issued, ... The CT FAQ is not an IETF document. > You're misreading the text. It is warning server operators that > "3 0 0" is less suitable for serving RPK clients (if that's what We disagree on the concept of "RPK" clients. >> I am confused. If DANE is only talking about how to verify a certain >> certificate received over TLS, I do not think this document should >> modify the TLS protocol with respect to SNI. It's out of scope. > > You're confused. The server is free to ignore the client's SNI > extension when it has a single certificate that works for all hosted > domains, because clients authenticate the server via the certificate > or key digest, and don't care about what name is in the certificate. > We're not modifying TLS, we're explaining that the server is free > to ignore the client's SNI extension. How is that not modifying TLS server behaviour? Paul From nobody Sun Jul 12 21:01:03 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0132F1A1A0C; Sun, 12 Jul 2015 21:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avyQhruVr6pw; Sun, 12 Jul 2015 21:01:00 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7831A19E4; Sun, 12 Jul 2015 21:01:00 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2E0A4284D6A; Mon, 13 Jul 2015 04:00:59 +0000 (UTC) Date: Mon, 13 Jul 2015 04:00:59 +0000 From: Viktor Dukhovni To: Paul Wouters Message-ID: <20150713040058.GJ28047@mournblade.imrryr.org> References: <20150711164349.GP28047@mournblade.imrryr.org> <20150713032950.GI28047@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF Security Directorate , "iesg@ietf.org" , dane@ietf.org Subject: Re: [secdir] [dane] SecDir Review of draft-ietf-dane-ops-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 04:01:02 -0000 On Sun, Jul 12, 2015 at 11:37:07PM -0400, Paul Wouters wrote: > >DANE-EE(3) certs are often self-signed, and there's no way to > >control the "spam" problem on the CT logs with DANE-EE(3). > > You don't know what audit logs will use for policies. Perhaps some > audit logs will be dedicated to only self-signed certs. I do not > think the dane document should dictate CT behaviour. The problem is that the CT documents are otherwise liable to dictate DANE behaviour. For example, require SCTs in DANE-EE validated certs. That would be unfortunate. This document notes that the present experimental CT in RFC 6962 is inapplicable to DANE. CT logs that record leaf certificates would be essentially useless, A rogue TLSA RRset with a "3 1 1" binding will work regardless of the certificate content, just based on the public key. A misissued TLSA RRset will bind a certificate that contains no information as to which domain was compromised. Here's a certificate with an empty subject and issuer name, what will the CT log make of that? -----BEGIN CERTIFICATE----- MIIBRjCB7aADAgECAgkAleIk6aMkXRwwCgYIKoZIzj0EAwIwADAeFw0xNTA3MTMw MzUwNTlaFw0xNTA4MTIwMzUwNTlaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC AAR50eOHUyMeHOMJNZTIXuj4QBJRbQrOLbYIftmZwzatO3/rG5BRyuUIfTQnzAq5 3K7A1pfq4hfseiOfT6prKKIVo1AwTjAdBgNVHQ4EFgQU7GD7zL/aLrBUaQIIKksc cc6or+0wHwYDVR0jBBgwFoAU7GD7zL/aLrBUaQIIKksccc6or+0wDAYDVR0TBAUw AwEB/zAKBggqhkjOPQQDAgNIADBFAiBr51OuJXf8N4Z79rStIXCIuYm6drChz39G RBWvumsuhgIhANoW5K3bSqIFpIp2aXzH2PiiSgxnC3T9Mp5O70tXGS4L -----END CERTIFICATE----- And yet it will match _25._tcp.smtp.example.com. IN TLSA 3 1 1 20041CBFD6570C48ACD8D526572137B9090E8037D115FB3C21218D9E9992A9C2 The *only* way to do CT for DANE TLSA is to do CT for DNS, and there is no CT for DNS in RFC 6962. > >Furthermore such a certificate is only ever "rogue" if DNSSEC is > >compromised to publish rogue TLSA RRs. > > Not if they use a CT log for prepublishing somehow. Although that is > unlikely to happen with SCT's without a CA, I still think you should > not make those decisions on this document. It is not a policy decision, it is just logic. The impossible cannot be done. > >You're confused. The server is free to ignore the client's SNI > >extension when it has a single certificate that works for all hosted > >domains, because clients authenticate the server via the certificate > >or key digest, and don't care about what name is in the certificate. > >We're not modifying TLS, we're explaining that the server is free > >to ignore the client's SNI extension. > > How is that not modifying TLS server behaviour? It is not modifying the TLS protocol, servers are already free to ignore SNI and return whatever certificate chain they please. This document explains that with DANE-EE(3) this yields results that are satisfactory to the client. As for modifying TLS, we're for example mandating the transmission of self-signed roots with DANE-TA(2), and that too is within the realm of what TLS can do, we're just defining a behaviour profile that makes DANE-TA(2) work (it does not otherwise). -- Viktor. From nobody Mon Jul 13 14:38:33 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DB21A0055; Mon, 13 Jul 2015 14:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r80x_STn_kPM; Mon, 13 Jul 2015 14:23:54 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751071A004E; Mon, 13 Jul 2015 14:23:54 -0700 (PDT) Received: from smize.t-mobile.com (unknown [162.248.119.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 082E5509C0; Mon, 13 Jul 2015 17:23:36 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_08B047B4-449F-4FDC-BFBF-5D36F0EC5D1E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Mon, 13 Jul 2015 14:22:58 -0700 Message-Id: <5D2E6DCF-6AFE-44EA-B367-DE30DDAC7CEF@seantek.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Mon, 13 Jul 2015 14:38:32 -0700 Cc: secdir@ietf.org, The IESG , IETF Apps Discuss , draft-ietf-appsawg-text-markdown-use-cases.all@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-appsawg-text-markdown-use-cases (fwd) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 21:23:57 -0000 --Apple-Mail=_08B047B4-449F-4FDC-BFBF-5D36F0EC5D1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thank you. Responses below. On Jul 1, 2015, at 3:17 PM, Paul Wouters wrote: >=20 > Sorry for the typo :) >=20 > Paul >=20 > ---------- Forwarded message ---------- > Date: Wed, 1 Jul 2015 18:15:10 > From: Paul Wouters > To: iesg@ietf.org, secdir@ietf.org, > draft-ietf-appsawg-text-markdown-use-casas.all@tools.ietf.org > Subject: Secdir review of draft-ietf-appsawg-text-markdown-use-cases >=20 >=20 > I have reviewed this document as part of the security directorate's > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comment. >=20 > This document describes use cases and sometimes existing deployed code > on handling "markdown" text. As such, the document introduces no new > security considerations, and the Security Considerations section = points > to other documents that further document the respective markdown > variants and their own security considerations. >=20 > Recommendation: Ready with Issues >=20 > I wanted to point out two use cases (or existing deployed code?) > that uses some features that might be considered a security issue. >=20 > 2.1 talks about filesystem "extended attributes" and suggests to add a > resource named "variant". This name might be a little too generic = to > only apply to markdown and might cause a name spaec collision that > could potentially be a security risk. If this is a use case = without > deployed code, I would recommend renaming this resource to = something > more specific, eg "markdown-varient". If it describes actual code, > then I guess that ship has sailed. It does describe some actual code. I can change the text to: {{ The variant identifier itself should be stored in a resource with a name = including the term =93variant=94 (possibly including other decorations = to avoid namespace collisions). }} How is that? >=20 > 2.4 talks about MIME aware clients saving a "batch script" to disk for > later execution. These kind of "autorun" or "preview" features are > a security nightmare, so here too I would hope this has not yet = been > coded. And if not, to reconsider not supporting such a feature. The purpose of this section was to suggest that if, for example, = =93pandoc=94 is the recipient=92s preferred Markdown processor, and the = recipient receives Markdown content in some other variant that pandoc = supports (let=92s say original Markdown), then the recipient can send = the Markdown through pandoc with the markdown_strict option; the = recipient does not need to have or use Gruber=92s original Markdown.pl = implementation to get at what the sender wanted. It is not necessary for = the recipient to have millions of different Markdown implementations, = only that it has one (or a small handful) of implementations that are = good enough for the purpose. There was significant discussion on apps-discuss (see around October = 2014?) about how it is bad for the sender to be able to specify specific = processing instructions, e.g., command-line commands or options that get = sent directly to a command interpreter. So, that approach was jettisoned = at that time. The text in Section 2.4 says: This strategy is to **translate** the processing instructions **inferred = from** the [parameters] into a sequence of commands in the **local = convention**, storing those commands in a batch script [=85] that are = **appropriate (and safe) for the local system**. (Emphasis mine.) I think those emphasized parts capture the point that = whatever code gets executed has to be appropriate and safe for the local = system. I am happy to reword this paragraph somehow, but if that is seen as = necessary, I would appreciate a counterproposal. A parenthetical note: Section 2.5 of text-markdown-use-cases (=93Process = the Markdown=94) is a bit ambiguous. The point is to process the = Markdown before the recipient sees it. Thus if you are composing an = e-mail in Markdown, the point would be that your sending MUA (or an = intermediary) would convert it to HTML before recipients receive the = e-mail. However, your Markdown-aware sending MUA could save drafts in = Markdown before the message is sent. Proposed text: {{ 2.5. Process the Markdown In Advance This strategy is to process the Markdown into the formal markup, before = a recipient receives it, which eliminates ambiguities. Once the Markdown = is processed into (for example) valid XHTML, an application can save a = file as "doc.xhtml" or can send MIME content as application/xhtml+xml = with no further loss of metadata. While unambiguous, this process may = not be reversible. }} Thanks, Sean --Apple-Mail=_08B047B4-449F-4FDC-BFBF-5D36F0EC5D1E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwNzEzMjEyMzMwWjAjBgkqhkiG9w0BCQQxFgQUGTEyxhlxbXsLPpAdJ8kQ35CykTAwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAFXPNKsbB6HoXH3C0vfGeaI4l6m6DNLHksUIv31AZKwwpMOz7HvSILKi7wZGNTifOS3b oodXa7P57rf40u9r8gIb2EZoZsLgpoGFXNZEzZDXJ77Ov7/6Xx1F26oXh6aZisYg28mnZvx8JrXF ifn3SZZNSG7bjrNk9kgRtdUHiPg5XEXQUJVggzkYPlujSoKkF5cOt56u1C1K6TEQiQV6HArVwjgo +vyXsboXaYZQ2XVFyQiTqZ9dxCjLaiP7EwoJvKEHMnMuonWbD7T/fcedpmyfyVUYigeM9iTcuSZ9 4p4uNISz8qIXW7jOnPKZLbbcqHi2rQ8HuVN/nZQ4InRkuYUAAAAAAAA= --Apple-Mail=_08B047B4-449F-4FDC-BFBF-5D36F0EC5D1E-- From nobody Mon Jul 13 19:02:33 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7A11A8908; Mon, 13 Jul 2015 19:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dydH4WXzt0Y6; Mon, 13 Jul 2015 19:02:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCCF1A8901; Mon, 13 Jul 2015 19:02:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mVlTr51zgzpL; Tue, 14 Jul 2015 04:02:24 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=UiDUV7qH X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id l1FAwpm1W5bC; Tue, 14 Jul 2015 04:02:23 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 14 Jul 2015 04:02:23 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9BF3680042; Mon, 13 Jul 2015 22:02:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1436839342; bh=hbl2kFmOj1HtaZA8FPptKPZ5gZb+V1qI3mOHtaNypaA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UiDUV7qHUXhTGSWhCd5JerSmq3yrj10rBNsEwIIbdLD1WsJGcVrDGX53+Mgw/fv0I IdZlBRouHRIIBXPjVsh/qWG4cwfS4/uHN4GEl0irNYB9y+sO0WzN4HaUrqgdlgQ9EL 83cigfOZhjw5lUik+l0LOeH386VfMjo8zzWuHMNA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6E22LHJ024251; Mon, 13 Jul 2015 22:02:21 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 13 Jul 2015 22:02:21 -0400 (EDT) From: Paul Wouters To: Sean Leonard In-Reply-To: <5D2E6DCF-6AFE-44EA-B367-DE30DDAC7CEF@seantek.com> Message-ID: References: <5D2E6DCF-6AFE-44EA-B367-DE30DDAC7CEF@seantek.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: secdir@ietf.org, The IESG , IETF Apps Discuss , draft-ietf-appsawg-text-markdown-use-cases.all@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-appsawg-text-markdown-use-cases (fwd) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 02:02:29 -0000 On Mon, 13 Jul 2015, Sean Leonard wrote: >> 2.1 talks about filesystem "extended attributes" and suggests to add a >> resource named "variant". This name might be a little too generic to >> only apply to markdown and might cause a name spaec collision that >> could potentially be a security risk. If this is a use case without >> deployed code, I would recommend renaming this resource to something >> more specific, eg "markdown-varient". If it describes actual code, >> then I guess that ship has sailed. > > It does describe some actual code. > > I can change the text to: > {{ > The variant identifier itself should be stored in a resource with a name including the term “variant” (possibly including other decorations to avoid namespace collisions). > }} > > How is that? Perfect. >> 2.4 talks about MIME aware clients saving a "batch script" to disk for >> later execution. These kind of "autorun" or "preview" features are >> a security nightmare, so here too I would hope this has not yet been >> coded. And if not, to reconsider not supporting such a feature. > > The purpose of this section was to suggest that if, for example, “pandoc” is the recipient’s preferred Markdown processor, and the recipient receives Markdown content in some other variant that pandoc supports (let’s say original Markdown), then the recipient can send the Markdown through pandoc with the markdown_strict option; the recipient does not need to have or use Gruber’s original Markdown.pl implementation to get at what the sender wanted. It is not necessary for the recipient to have millions of different Markdown implementations, only that it has one (or a small handful) of implementations that are good enough for the purpose. > > There was significant discussion on apps-discuss (see around October 2014?) about how it is bad for the sender to be able to specify specific processing instructions, e.g., command-line commands or options that get sent directly to a command interpreter. So, that approach was jettisoned at that time. > > The text in Section 2.4 says: > > This strategy is to **translate** the processing instructions **inferred from** the [parameters] into a sequence of commands in the **local convention**, storing those commands in a batch script […] that are **appropriate (and safe) for the local system**. > > > (Emphasis mine.) I think those emphasized parts capture the point that whatever code gets executed has to be appropriate and safe for the local system. > > I am happy to reword this paragraph somehow, but if that is seen as necessary, I would appreciate a counterproposal. No that's fine. If you already had that discussion, and this is the outcome of that, that is good enough for me. Although perhaps an additional warning in the Security Section could be used to clarify this a little more. > A parenthetical note: Section 2.5 of text-markdown-use-cases (“Process the Markdown”) is a bit ambiguous. The point is to process the Markdown before the recipient sees it. Thus if you are composing an e-mail in Markdown, the point would be that your sending MUA (or an intermediary) would convert it to HTML before recipients receive the e-mail. However, your Markdown-aware sending MUA could save drafts in Markdown before the message is sent. > > Proposed text: > {{ > 2.5. Process the Markdown In Advance > > This strategy is to process the Markdown into the formal markup, before a recipient receives it, which eliminates ambiguities. Once the Markdown is processed into (for example) valid XHTML, an application can save a file as "doc.xhtml" or can send MIME content as application/xhtml+xml with no further loss of metadata. While unambiguous, this process may not be reversible. > }} Sounds good too. Paul From nobody Tue Jul 14 01:32:59 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6451E1A909D for ; Tue, 14 Jul 2015 01:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_0cd3WsqCFb for ; Tue, 14 Jul 2015 01:32:45 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306E61A909A for ; Tue, 14 Jul 2015 01:32:39 -0700 (PDT) Received: by obbop1 with SMTP id op1so1732862obb.2 for ; Tue, 14 Jul 2015 01:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0cKQrYW7Zcze47Q+t4aZtQSNrkeNnaJ2wAXSCjn1CYM=; b=SBtFAbR+Nt9SrdDDny6qDnBi98BXoyEW3s6jLxhuSYCI96EhV+b6sH5yc3LJqCUXpK o0tFMjV0vqlimT7pflddR521fVSmRz4bhz6DjFERSCS7f7YnVVNIvZGQQ3xxf550gr/l X2zxVnahJeHSzNTLT0ygXvixdRo9aGFffoAI3HcXa1r5icJI8HK4Jk5xNRdNXIr61NuW Vc7zkhCQ7AN0+eQ5APMGgL9j3mRwnPO2NqiH8otq3k6t2ob0sTHRr+WUJPXteCNXpwRf NHSWlCbfzQFgMaDuWHXign8+oCWNNRvz+9CJ2IpaAAv42lMsU9yR308sFQWShwxn5ahj uWEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0cKQrYW7Zcze47Q+t4aZtQSNrkeNnaJ2wAXSCjn1CYM=; b=bzO2CydTOq2CNXsWsAVSp+MUMRYB9D/e3j3GBN2K9oODjg9jXV7Itsvk0e26IohOAc aalXg5Dffuqof2Yqr5W0m9fyU1WSctr4hZSS1ludtv+Lb0MDkKUTs0yU0viJ5OWL/OJU cc9p13vyb46kMg2TV4BJ/BvEXG3uflXfPIzk02cE5wor2BxzKVfsNSudamsB9gdsjKp5 JqFnJSCp86fgy1Cu24LSRzqR066Uv7agB+PaT7Ld8g0jh5OhWHaDB/7Fi7laJLXkAI07 v0+xmp5iG51spxmrR1Oqwlh6Suk7z1e4t4KD1acN4duVMjWp0cyIGh4TGEsJzcZxPACC /TDw== X-Gm-Message-State: ALoCoQnZayuZFDIARAoDlylZ9rOepfY5vSUgOnmfP/br6poDvLWt46Zxc8MmecFaMzZMHvQzx9kZ X-Received: by 10.202.57.137 with SMTP id g131mr30373347oia.122.1436862758457; Tue, 14 Jul 2015 01:32:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.66.130 with HTTP; Tue, 14 Jul 2015 01:32:18 -0700 (PDT) In-Reply-To: <559AA6B2.3@nostrum.com> References: <558B1E9C.8080505@nostrum.com> <559AA6B2.3@nostrum.com> From: Takeshi Yoshino Date: Tue, 14 Jul 2015 17:32:18 +0900 Message-ID: To: Robert Sparks Content-Type: multipart/alternative; boundary=001a113cee2a4f350f051ad1ae75 Archived-At: Cc: draft-ietf-hybi-permessage-compression.all@ietf.org, "hybi@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 08:32:47 -0000 --001a113cee2a4f350f051ad1ae75 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2015 at 1:02 AM, Robert Sparks wrote: > (adding the hybi list) > Hi Robert, Sorry for delay. > > It seems to me that this effectively adding an actor (the intermediary) , > and defining (not as explicitly as I think it needs to be) protocol > mechanics for that actor in ways that the base specification did not > anticipate. > > Done more archaeology... This text originates from the intermediaries section introduced on update between draft-tyoshino-hybi-websocket-perframe-deflate-06 and draft-ietf-hybi-websocket-perframe-compression-00 I couldn't find the original proposal which led to this text from my mail box. I thought someone made one on HyBi, but only found my comment on publish of -00. As far as I remember, we initially didn't intend to add any requirement, expectation, etc. to the main (RFC 6455) spec by this spec. The text now looks like an additional requirements to complement the main spec just unexpectedly (unexpectedly at least for me). I added this text just to note a fact that when one wants to change compression, handshake should be also altered appropriately, otherwise, it doesn't work. Maybe the following texts in RFC 6455 have a similar role. o As control frames cannot be fragmented, an intermediary MUST NOT ... o An intermediary MUST NOT change the fragmentation of a message if ... o An intermediary MUST NOT change the fragmentation of any message ... > I'm not comfortable that the consequences of these new mechanics > (specifically - that the intermediary can directly participate in the > extension negotiations, and change the results) are well understood. > Did you mean "not well understood"? > The additions to the text you propose will certainly help point out that > there might be some, and the message that the endpoint won't have insight > into how its messages are handled beyond the intermediary needs to be > prominent. > Yeah. But now I'm wondering if it's in the scope of protocol standardization or not. Seems the text should be changed to look like a warning (don't do this or your stack won't work) as discussed above. > > But I wonder if the mechanics of an intermediary _changing the protocol > signalling_ is something the working group should explicitly work on > writing down? > > I've been viewing the PMCE from the view point of a browser developer. Like fragmentation, permessage-deflate is also just a transport-level thing which is invisible/transparent to the final user of the communication (e.g. JavaScript using the WebSocket API). My comments are based on this idea. But with your comment, I just noticed that it's not trivial. Actually, the extensions under use is exposed to the user of the protocol via _Extensions in Use_. We should have been aware of that. > RjS > > > On 6/30/15 3:42 AM, Takeshi Yoshino wrote: > > Thank you for review, Robert. > > On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks > wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> Summary: Ready with issues >> >> (fwiw, I also reviewed up through version -24). >> >> Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other. >> (If that's not what it's trying to set up, please clarify). >> >> OK. So, I'd like to change the text as follows: > > When an intermediary proxies ... Per-message Compression of messages > received from one peer, and then forward the messages to the other peer, if > the intermediary ... > > >> It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that? >> Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently. >> >> It's not well discussed in RFC6455. Right. AFAIK, there's no such > extension defined, yet. > > I understand that this text (intermediary section in the I-D) works just > not to disallow change of compression but there's nothing in RFC6455 that > guarantees that such transformation doesn't cause any issue with other > infrastructure of the WebSocket protocol. > > I believe that unless any extension that interferes with the other > negotiated extensions (e.g. counting the number of negotiated extensions, > relying on PMCE, etc.), the core WebSocket protocol (things defined in > RFC6455) should work. If such an extension is introduced, it would be just > considered to be incompatible with PMCEs, or that extension should describe > how to coordinate with change on PMCE in the intermediaries section of its > RFC. > > I think this is more reasonable than prohibiting change on Per-message > Compression by intermediaries. > >> This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document? >> >> Ah, right. Maybe some text like: > > "It's not guaranteed that the PMCE which an endpoint has negotiated in > the opening handshake is preserved in the whole path to the peer endpoint." > > >> It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected. >> >> > As a general discussion to cover other extensions (if they want. by > referring to this to-be-RFC) like the section defining terms to complement > RFC6455 [1]? > > [1] > https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-24#section-3 > > > > --001a113cee2a4f350f051ad1ae75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 7, 2015 at 1:02 AM, Robert Sparks <rjsparks@nostrum.com>= wrote:
=20 =20 =20
(adding the hybi list)

Hi Rob= ert,

Sorry for delay.
=C2=A0

It seems to me that this effectively adding an actor (the intermediary) , and defining (not as explicitly as I think it needs to be) protocol mechanics for that actor in ways that the base specification did not anticipate.


Done more=C2=A0archaeology..= .

This text originates from the intermediaries sec= tion introduced on update between
draft-tyoshino-hybi-websocket-p= erframe-deflate-06 and
draft-ietf-hybi-websocket-perframe-compres= sion-00

I couldn't find the original proposal = which led to this text from my mail box. I thought someone made one on HyBi= , but only found my comment on publish of -00.

As = far as I remember, we initially didn't intend to add any requirement, e= xpectation, etc. to the main (RFC 6455) spec by this spec. The text now loo= ks like an additional requirements to complement the main spec just unexpec= tedly (unexpectedly at least for me). I added this text just to note a fact= that when one wants to change compression, handshake should be also altere= d appropriately, otherwise, it doesn't work. Maybe the following texts = in RFC 6455 have a similar role.

=C2=A0 =C2= =A0o =C2=A0As control frames cannot be fragmented, an intermediary MUST NOT= ...

=C2=A0 =C2=A0o =C2=A0An intermediary MUST NOT= change the fragmentation of a message if ...

=C2= =A0 =C2=A0o =C2=A0An intermediary MUST NOT change the fragmentation of any = message ...
=C2=A0
I'm not comfortable that the consequences of these new mechanics (specifically - that the intermediary can directly participate in the extension negotiations, and change the results) are well understood.

Did you mean "n= ot well understood"?
=C2=A0
The additions to the text you propose will = certainly help point out that there might be some, and the message that the endpoint won't have insight into how its messages are handled beyon= d the intermediary needs to be prominent.
Yeah. But now I'm wondering if it's in the scope of pro= tocol standardization or not. Seems the text should be changed to look like= a warning (don't do this or your stack won't work) as discussed ab= ove.
=C2=A0

But I wonder if the mechanics of an intermediary _changing the protocol signalling_ is something the working group should explicitly work on writing down?


I've been viewing the PM= CE from the view point of a browser developer. Like fragmentation, permessa= ge-deflate is also just a transport-level thing which is invisible/transpar= ent to the final user of the communication (e.g. JavaScript using the WebSo= cket API). My comments are based on this idea. But with your comment, I jus= t noticed that it's not trivial.

Actually, the= extensions under use is exposed to the user of the protocol via _Extension= s in Use_. We should have been aware of that.
=C2=A0
RjS


On 6/30/15 3:42 AM, Takeshi Yoshino wrote:
Thank you for review, Robert.

On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
I have reviewed this document as part of the security =
directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.

Summary: Ready with issues

(fwiw, I also reviewed up through version -24).

Section 7 (Intermediaries) should be more explicit that it's talking ab=
out an intermediary doing compression on one side and not (or doing differe=
nt compression) on the other.
(If that's not what it's trying to set up, please clarify).
OK. So, I'd like to change the text as follows:

When an intermediary proxies ... Per-message Compression of messages received from one peer, and then forward the messages to the other peer, if the intermediary ...
=C2=A0
It's not clear from reading RFC6455 that the idea =
of intermediaries changing the contents of the websocket extension negotiat=
ion mechanism was considered - have I missed the text in that RFC that disc=
usses that?
Are there other extensions that suggest similar behavior? It's not imme=
diately clear that the protocol mechanics do the right thing when the diffe=
rent negotiations on each side of the proxy fail differently.
It's not well discussed in RFC6455. Right. AFAIK, there's no such extension defined, yet.

I understand that this text (intermediary section in the I-D) works just not to disallow change of compression but there's nothing in RFC6455 that guarantees that such transformation doesn't cause any issue with other infrastructure of the WebSocket protocol.

I believe that unless any extension that interferes with the other negotiated extensions (e.g. counting the number of negotiated extensions, relying on PMCE, etc.), the core WebSocket protocol (things defined in RFC6455) should work. If such an extension is introduced, it would be just considered to be incompatible with PMCEs, or that extension should describe how to coordinate with change on PMCE in the intermediaries section of its RFC.

I think this is more reasonable than prohibiting change on Per-message Compression by intermediaries.
This also seems to put an endpoint in a position where=
 it has no say on what an intermediary does with the traffic on the other s=
ide of it. Is that worth discussing in the document?
Ah, right. Maybe some text like:

"It's not guaranteed that the PMCE which an endpo= int has negotiated in the opening handshake is preserved in the whole path to the peer endpoint."
=C2=A0
It would be good to point to, or provide, a discussion=
 of how the extension negotiation mechanism in WebSockets is meant to be pr=
otected.

As a general discussion to cover other extensions (if they want. by referring to this to-be-RFC) like the section defining terms to complement RFC6455 [1]?

=C2=A0


--001a113cee2a4f350f051ad1ae75-- From nobody Thu Jul 16 01:31:42 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666791A87B2 for ; Thu, 16 Jul 2015 01:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF4OUcPH-jqE for ; Thu, 16 Jul 2015 01:31:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C87A1A00C7 for ; Thu, 16 Jul 2015 01:31:39 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t6G8VaCq029857 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 16 Jul 2015 11:31:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t6G8VaKN026985; Thu, 16 Jul 2015 11:31:36 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21927.27624.29073.56703@fireball.acr.fi> Date: Thu, 16 Jul 2015 11:31:36 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 08:31:41 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Leif Johansson is next in the rotation. For telechat 2015-08-06 Reviewer LC end Draft John Bradley T 2015-07-08 draft-ietf-xmpp-posh-04 Jeffrey Hutzelman T 2015-07-23 draft-ietf-sidr-rfc6490-bis-04 For telechat 2015-08-20 Dan Harkins T 2015-08-05 draft-vinapamula-softwire-dslite-prefix-binding-07 Last calls and special requests: Dave Cridland 2015-07-27 draft-bradner-iaoc-terms-01 Alan DeKok 2015-07-09 draft-ietf-intarea-gre-ipv6-10 Donald Eastlake 2015-07-13 draft-ietf-6man-ipv6-address-generation-privacy-07 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Olafur Gudmundsson 2015-07-29 draft-mm-netconf-time-capability-05 Phillip Hallam-Baker 2015-07-20 draft-ietf-dime-4over6-provisioning-03 Steve Hanna 2015-08-04 draft-sparks-genarea-review-tracker-02 Sam Hartman 2015-07-23 draft-ietf-ccamp-flexi-grid-fwk-05 Paul Hoffman 2015-07-27 draft-ietf-dime-ovli-08 Christian Huitema 2015-08-11 draft-ietf-dnsop-onion-tld-00 Chris Inacio 2015-07-29 draft-ietf-homenet-dncp-07 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 -- kivinen@iki.fi From nobody Mon Jul 20 01:09:52 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746271A038E for ; Mon, 20 Jul 2015 01:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVrmUzB5bQou for ; Mon, 20 Jul 2015 01:09:48 -0700 (PDT) Received: from xsmtp11.mail2web.com (xsmtp11.mail2web.com [168.144.250.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4216D1A038D for ; Mon, 20 Jul 2015 01:09:48 -0700 (PDT) Received: from [10.5.2.11] (helo=xmail01.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ZH68v-00008U-3Q for secdir@ietf.org; Mon, 20 Jul 2015 04:09:47 -0400 Received: (qmail 9617 invoked from network); 20 Jul 2015 08:09:44 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[31.133.170.71]) (envelope-sender ) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 20 Jul 2015 08:09:44 -0000 From: "Christian Huitema" To: "'The IESG'" , "'secdir'" , Date: Mon, 20 Jul 2015 10:09:52 +0200 Message-ID: <007601d0c2c3$7615b610$62412230$@huitema.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01D0C2D4.399F4960" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdDCwrgI+PKUtFTlQwu24Fnrr5jdag== Content-Language: en-us Archived-At: Subject: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 08:09:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0077_01D0C2D4.399F4960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments = just like any other last call comments. The document proposes to reserve the =93.onion=94 TLD for special use by = the TOR project. The document is short and easy to read, went through the last = call process, and is probably ready to publish. I just wish there was a = clearer structure to the security section.=20 I am a bit puzzled by the way the security section is written. Since the purpose of the draft is to reserve the =93.onion=94 TLD, I would expect = the security section to present the security issues mitigated or introduced = by this TLD reservation. As far as I understand, the main security issues = come from client confusion, which could cause =93.onion=94 names to be = resolved through the standard DNS process. A number of bad things happen then, = from simple information disclosure that a client is trying to access a TOR service, to potential spoofing of secure TOR services. In fact, the main reason for the registration request is to mitigate these security = issues, by requesting that standard DNS resolvers and servers recognize = =93.onion=94 requests and refuse to forward them. The security section makes all these points, but it also mixes in a description of the structure of .onion names and their cryptographic components. I believe the issues would be easier to understand if the = main body of the document included a short description of the TOR naming = process and name resolution. The security section also does not explain how the =93leakage of = names=94 issue is mitigated for legacy systems. By definition, these systems have not = been updated and do not perform special treatment of =93.onion=94 names. The = TLD reservation probably helps somewhat, but this is not discussed. Then, the security section also does not discuss how malicious name resolvers could be deployed in order to attack the TOR network. For = example, if TOR security relies on DNS servers =93black holing=94 misrouted = request to resolve =93.onion=94 names, what happens if malicious servers replace = the suggested black-holing with some malicious tampering? -- Christian Huitema =20 =20 =20 ------=_NextPart_000_0077_01D0C2D4.399F4960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have reviewed this = document as part of the security directorate's ongoing effort to review = all IETF documents being processed by the IESG.=A0 These comments were = written primarily for the benefit of the security area directors.=A0 = Document editors and WG chairs should treat these comments just like any = other last call comments.

The document proposes to = reserve the “.onion” TLD for special use by the TOR project. = The document is short and easy to read, went through the last call = process, and is probably ready to publish. I just wish there was a = clearer structure to the security section. =

I am a = bit puzzled by the way the security section is written. Since the = purpose of the draft is to reserve the “.onion” TLD, I would = expect the security section to present the security issues mitigated or = introduced by this TLD reservation. As far as I understand, the main = security issues come from client confusion, which could cause = “.onion” names to be resolved through the standard DNS = process. A number of bad things happen then, from simple information = disclosure that a client is trying to access a TOR service, to potential = spoofing of secure TOR services. In fact, the main reason for the = registration request is to mitigate these security issues, by requesting = that standard DNS resolvers and servers recognize “.onion” = requests and refuse to forward them.

The security section makes = all these points, but it also mixes in a description of the structure of = .onion names and their cryptographic components. I believe the issues = would be easier to understand if the main body of the document included = a short description of the TOR naming process and name = resolution.

The security section also = does not explain how the “leakage of names” issue is = mitigated for legacy systems. By definition, these systems have not been = updated and do not perform special treatment of “.onion” = names. The TLD reservation probably helps somewhat, but this is not = discussed.

Then, the security section = also does not discuss how malicious name resolvers could be deployed in = order to attack the TOR network. For example, if TOR security relies on = DNS servers “black holing” misrouted request to resolve = “.onion” names, what happens if malicious servers replace = the suggested black-holing with some malicious = tampering?

-- Christian = Huitema

 

 

 

------=_NextPart_000_0077_01D0C2D4.399F4960-- From nobody Tue Jul 21 00:15:24 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAA61A0032; Tue, 21 Jul 2015 00:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1437462692; bh=git++hzTBcqsdqjW/N4DtgGHQY8ogmwq04hjza9mQPA=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=keOdfezf5o0Zhbj9fSc1NOGGU7/zcgiKFwJt1SabmqqWxAKW/7EFkqN8RI7VTvhHN FULI7cFC3SNXDZYpB6bzMOIbmA99oaVdkHfILOcldqnSGHNqETrznpMIHkqNF3VjKj dKkPTQis/7DcKGVhDy9TEcwX95+BePqqRXqm+CLs= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278361A0026 for ; Tue, 21 Jul 2015 00:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DouX8DnHudQ for ; Tue, 21 Jul 2015 00:11:28 -0700 (PDT) Received: from jay.w3.org (jay.w3.org [128.30.52.169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341231A0032 for ; Tue, 21 Jul 2015 00:11:28 -0700 (PDT) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZHRi2-0006cE-U4 for new-work@ietf.org; Tue, 21 Jul 2015 03:11:27 -0400 To: new-work@ietf.org Date: Tue, 21 Jul 2015 09:11:25 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 21 Jul 2015 00:15:22 -0700 Subject: [secdir] [new-work] Proposed W3C WAI Charters (until 2015-07-30) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 07:11:32 -0000 Hello, With apologies for the delay, this is to let you know that early this month, the W3C Advisory Committee Representatives received a Proposal to revise the Web Accessibility Initiative (see the W3C Process Document description of Activity Proposals [1]). This proposal includes draft charters for the following groups: 1) WCAG WG: Web Content Accessibility Guidelines WG Proposed: http://www.w3.org/2015/04/draft-wcag-charter WG Page: http://www.w3.org/WAI/GL/ 2) ATAG WG: Authoring Tool Accessibility Guidelines WG Proposed: http://www.w3.org/WAI/AU/2015/draft_auwg_charter.html WG Page: http://www.w3.org/WAI/AU/ 3) UAWG: User Agent Accessibility Guidelines WG Proposed: http://www.w3.org/WAI/UA/2015/draft_uawg_charter.html WG Page: http://www.w3.org/WAI/UA/ 4) APA WG: Accessible Platform Architectures WG (formerly PFWG) Proposed: http://www.w3.org/2015/04/draft-spec-charter WG Page: http://www.w3.org/WAI/PF/ (current WG page, pre-split) 5) ARIA WG: Accessible Rich Internet Applications Working Group Proposed: http://www.w3.org/2015/04/draft-aria-charter WG Page: http://www.w3.org/WAI/PF/ (current WG page, pre-split) 6) EOWG: Education and Outreach WG Proposed: http://www.w3.org/WAI/EO/2015/charter6-2015 WG Page: http://www.w3.org/WAI/EO/ 7) WAI Interest Group Proposed: http://www.w3.org/WAI/IG/charter5.html WG Page: http://www.w3.org/WAI/IG/ As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2015-07-30 on the proposed charters. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Judy Brewer, WAI Domain Lead . Thank you, Coralie Mercier, Acting Head of W3C Marketing & Communications [1] http://www.w3.org/2014/Process-20140801/#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Jul 22 04:51:55 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9901B2EEF for ; Wed, 22 Jul 2015 04:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NoxWQaPzF2R for ; Wed, 22 Jul 2015 04:51:52 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52F71B2F90 for ; Wed, 22 Jul 2015 04:51:35 -0700 (PDT) Received: by oihq81 with SMTP id q81so142005090oih.2 for ; Wed, 22 Jul 2015 04:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eGLRaCucGfcLJTrb2pY/EfghQC+95y1tf/NvnbrXXRk=; b=lLS2FY7qk4dKsGoIaaDkoTwcDh9zD8kAAOtZzOmYgHwEMU5YgQWznVyNHZVBTX1TTu uAzYyVjDyop7tkq0gCtHGyflAJwsFsWNc25Y+utF2pxFSp5ascMP+qEnMYoQY6Gr060u Y4XSF3HhOAJi1FZdabcl/SSCiXYNrldK9M7NN2z2807LdXAucmQgYqBSd4oKcdSYCGwE NAqbhzJs+Qr4+RgDRAsSA32jddevyioOL4jTl1qnG0hB0dvd6JRq3ycddANubTMBY5Ur pmcOtWtf8vugeQ5NEciFC0jTZmPz6iJQBSo75ihKC1DbEonNAzARdddgjiGUXJgWLUEe XiVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eGLRaCucGfcLJTrb2pY/EfghQC+95y1tf/NvnbrXXRk=; b=Afa486JK2df/s2Qy9b8QQjYdnCRO9419PtvV1t7ah2GQQypdnlAC8Eifbvowpz7Gfv 8K582QTUpB6YCl6+gjliKZ2p2P0finw+JIqYVflsFQMf8vpYn9JIpX9bFTEyV8fmo9Wf CHfZJFLO6HiC/p10cfjk4sy0eX+oXslUeXSKFrK95Q/Zw2h7QmLQwumwlnj30zUjkqgv KduhACfBFiTNtJh+agFuWr0PliW7dMVK86zI2rT7Aok628ML4s3Va+FUPUGKSUCwAuYx GIMIbbHP4FQgId2piaKBiyvDj41KiPUxIkkU1CEfZzZ7VnBwgrUIwzmI0HADoffOiBt+ TJaw== X-Gm-Message-State: ALoCoQmUQF3Y+u3IqzwQeQ7lhnMi/Gx+9RuyiAsO37+zPHGSH4PmhU0iWHtac6bY3loSHDC+DUBi X-Received: by 10.182.199.103 with SMTP id jj7mr1982759obc.49.1437565895138; Wed, 22 Jul 2015 04:51:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.66.130 with HTTP; Wed, 22 Jul 2015 04:51:15 -0700 (PDT) In-Reply-To: References: <558B1E9C.8080505@nostrum.com> <559AA6B2.3@nostrum.com> From: Takeshi Yoshino Date: Wed, 22 Jul 2015 20:51:15 +0900 Message-ID: To: Robert Sparks Content-Type: multipart/alternative; boundary=e89a8ff1c9ec85962c051b756409 Archived-At: Cc: draft-ietf-hybi-permessage-compression.all@ietf.org, "hybi@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:51:55 -0000 --e89a8ff1c9ec85962c051b756409 Content-Type: text/plain; charset=UTF-8 HyBi people, Please respond to this thread if you want to keep the section as-is (or with some improvement. texts welcome). I plan to revise it by replacing with a warning (saying "don't change the compression unless you don't know it") unless anyone objects to it. Takeshi On Tue, Jul 14, 2015 at 5:32 PM, Takeshi Yoshino wrote: > On Tue, Jul 7, 2015 at 1:02 AM, Robert Sparks > wrote: > >> (adding the hybi list) >> > > Hi Robert, > > Sorry for delay. > > >> >> It seems to me that this effectively adding an actor (the intermediary) , >> and defining (not as explicitly as I think it needs to be) protocol >> mechanics for that actor in ways that the base specification did not >> anticipate. >> >> > Done more archaeology... > > This text originates from the intermediaries section introduced on update > between > draft-tyoshino-hybi-websocket-perframe-deflate-06 and > draft-ietf-hybi-websocket-perframe-compression-00 > > I couldn't find the original proposal which led to this text from my mail > box. I thought someone made one on HyBi, but only found my comment on > publish of -00. > > As far as I remember, we initially didn't intend to add any requirement, > expectation, etc. to the main (RFC 6455) spec by this spec. The text now > looks like an additional requirements to complement the main spec just > unexpectedly (unexpectedly at least for me). I added this text just to note > a fact that when one wants to change compression, handshake should be also > altered appropriately, otherwise, it doesn't work. Maybe the following > texts in RFC 6455 have a similar role. > > o As control frames cannot be fragmented, an intermediary MUST NOT ... > > o An intermediary MUST NOT change the fragmentation of a message if ... > > o An intermediary MUST NOT change the fragmentation of any message ... > > >> I'm not comfortable that the consequences of these new mechanics >> (specifically - that the intermediary can directly participate in the >> extension negotiations, and change the results) are well understood. >> > > Did you mean "not well understood"? > > >> The additions to the text you propose will certainly help point out that >> there might be some, and the message that the endpoint won't have insight >> into how its messages are handled beyond the intermediary needs to be >> prominent. >> > > Yeah. But now I'm wondering if it's in the scope of protocol > standardization or not. Seems the text should be changed to look like a > warning (don't do this or your stack won't work) as discussed above. > > >> >> But I wonder if the mechanics of an intermediary _changing the protocol >> signalling_ is something the working group should explicitly work on >> writing down? >> >> > I've been viewing the PMCE from the view point of a browser developer. > Like fragmentation, permessage-deflate is also just a transport-level thing > which is invisible/transparent to the final user of the communication (e.g. > JavaScript using the WebSocket API). My comments are based on this idea. > But with your comment, I just noticed that it's not trivial. > > Actually, the extensions under use is exposed to the user of the protocol > via _Extensions in Use_. We should have been aware of that. > > >> RjS >> >> >> On 6/30/15 3:42 AM, Takeshi Yoshino wrote: >> >> Thank you for review, Robert. >> >> On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks >> wrote: >> >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should treat >>> these comments just like any other last call comments. >>> >>> Summary: Ready with issues >>> >>> (fwiw, I also reviewed up through version -24). >>> >>> Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other. >>> (If that's not what it's trying to set up, please clarify). >>> >>> OK. So, I'd like to change the text as follows: >> >> When an intermediary proxies ... Per-message Compression of messages >> received from one peer, and then forward the messages to the other peer, if >> the intermediary ... >> >> >>> It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that? >>> Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently. >>> >>> It's not well discussed in RFC6455. Right. AFAIK, there's no such >> extension defined, yet. >> >> I understand that this text (intermediary section in the I-D) works >> just not to disallow change of compression but there's nothing in RFC6455 >> that guarantees that such transformation doesn't cause any issue with other >> infrastructure of the WebSocket protocol. >> >> I believe that unless any extension that interferes with the other >> negotiated extensions (e.g. counting the number of negotiated extensions, >> relying on PMCE, etc.), the core WebSocket protocol (things defined in >> RFC6455) should work. If such an extension is introduced, it would be just >> considered to be incompatible with PMCEs, or that extension should describe >> how to coordinate with change on PMCE in the intermediaries section of its >> RFC. >> >> I think this is more reasonable than prohibiting change on Per-message >> Compression by intermediaries. >> >>> This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document? >>> >>> Ah, right. Maybe some text like: >> >> "It's not guaranteed that the PMCE which an endpoint has negotiated in >> the opening handshake is preserved in the whole path to the peer endpoint." >> >> >>> It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected. >>> >>> >> As a general discussion to cover other extensions (if they want. by >> referring to this to-be-RFC) like the section defining terms to complement >> RFC6455 [1]? >> >> [1] >> https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-24#section-3 >> >> >> >> > --e89a8ff1c9ec85962c051b756409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HyBi people,

Please respond to this thr= ead if you want to keep the section as-is (or with some improvement. texts = welcome).

I plan to revise it by replacing with a = warning (saying "don't change the compression unless you don't= know it") unless anyone objects to it.

Takeshi
=

On Tue, Jul 14, 2015 at 5:32 PM, Takeshi Yos= hino <tyoshino@google.com> wrote:
On Tue, Jul 7, 2015 at 1:02 AM, Robert Sparks <<= a href=3D"mailto:rjsparks@nostrum.com" target=3D"_blank">rjsparks@nostrum.c= om> wrote:
=20 =20 =20
(adding the hybi list)

Hi Rob= ert,

Sorry for delay.
= =C2=A0

It seems to me that this effectively adding an actor (the intermediary) , and defining (not as explicitly as I think it needs to be) protocol mechanics for that actor in ways that the base specification did not anticipate.


Done more=C2=A0archae= ology...

This text originates from the intermediar= ies section introduced on update between
draft-tyoshino-hybi-webs= ocket-perframe-deflate-06 and
draft-ietf-hybi-websocket-perframe-= compression-00

I couldn't find the original pr= oposal which led to this text from my mail box. I thought someone made one = on HyBi, but only found my comment on publish of -00.

<= div>As far as I remember, we initially didn't intend to add any require= ment, expectation, etc. to the main (RFC 6455) spec by this spec. The text = now looks like an additional requirements to complement the main spec just = unexpectedly (unexpectedly at least for me). I added this text just to note= a fact that when one wants to change compression, handshake should be also= altered appropriately, otherwise, it doesn't work. Maybe the following= texts in RFC 6455 have a similar role.

=C2= =A0 =C2=A0o =C2=A0As control frames cannot be fragmented, an intermediary M= UST NOT ...

=C2=A0 =C2=A0o =C2=A0An intermediary M= UST NOT change the fragmentation of a message if ...

=C2=A0 =C2=A0o =C2=A0An intermediary MUST NOT change the fragmentation o= f any message ...
=C2=A0
I'm not comfortable that the consequences of these new mechanics (specifically - that the intermediary can directly participate in the extension negotiations, and change the results) are well understood.

Did you mean = "not well understood"?
=C2=A0
The additions to th= e text you propose will certainly help point out that there might be some, and the message that the endpoint won't have insight into how its messages are handled beyon= d the intermediary needs to be prominent.
Yeah. But now I'm wondering if it's in the scope= of protocol standardization or not. Seems the text should be changed to lo= ok like a warning (don't do this or your stack won't work) as discu= ssed above.
=C2=A0

But I wonder if the mechanics of an intermediary _changing the protocol signalling_ is something the working group should explicitly work on writing down?


I've been viewing= the PMCE from the view point of a browser developer. Like fragmentation, p= ermessage-deflate is also just a transport-level thing which is invisible/t= ransparent to the final user of the communication (e.g. JavaScript using th= e WebSocket API). My comments are based on this idea. But with your comment= , I just noticed that it's not trivial.

Actual= ly, the extensions under use is exposed to the user of the protocol via _Ex= tensions in Use_. We should have been aware of that.
=C2=A0
RjS


On 6/30/15 3:42 AM, Takeshi Yoshino wrote:
Thank you for review, Robert.

On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
I have reviewed this document as part of the security =
directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.

Summary: Ready with issues

(fwiw, I also reviewed up through version -24).

Section 7 (Intermediaries) should be more explicit that it's talking ab=
out an intermediary doing compression on one side and not (or doing differe=
nt compression) on the other.
(If that's not what it's trying to set up, please clarify).
OK. So, I'd like to change the text as follows:

When an intermediary proxies ... Per-message Compression of messages received from one peer, and then forward the messages to the other peer, if the intermediary ...
=C2=A0
It's not clear from reading RFC6455 that the idea =
of intermediaries changing the contents of the websocket extension negotiat=
ion mechanism was considered - have I missed the text in that RFC that disc=
usses that?
Are there other extensions that suggest similar behavior? It's not imme=
diately clear that the protocol mechanics do the right thing when the diffe=
rent negotiations on each side of the proxy fail differently.
It's not well discussed in RFC6455. Right. AFAIK, there's no such extension defined, yet.

I understand that this text (intermediary section in the I-D) works just not to disallow change of compression but there's nothing in RFC6455 that guarantees that such transformation doesn't cause any issue with other infrastructure of the WebSocket protocol.

I believe that unless any extension that interferes with the other negotiated extensions (e.g. counting the number of negotiated extensions, relying on PMCE, etc.), the core WebSocket protocol (things defined in RFC6455) should work. If such an extension is introduced, it would be just considered to be incompatible with PMCEs, or that extension should describe how to coordinate with change on PMCE in the intermediaries section of its RFC.

I think this is more reasonable than prohibiting change on Per-message Compression by intermediaries.
This also seems to put an endpoint in a position where=
 it has no say on what an intermediary does with the traffic on the other s=
ide of it. Is that worth discussing in the document?
Ah, right. Maybe some text like:

"It's not guaranteed that the PMCE which an endpo= int has negotiated in the opening handshake is preserved in the whole path to the peer endpoint."
=C2=A0
It would be good to point to, or provide, a discussion=
 of how the extension negotiation mechanism in WebSockets is meant to be pr=
otected.

As a general discussion to cover other extensions (if they want. by referring to this to-be-RFC) like the section defining terms to complement RFC6455 [1]?

=C2=A0



--e89a8ff1c9ec85962c051b756409-- From nobody Wed Jul 22 17:14:10 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536B31B2FD8 for ; Wed, 22 Jul 2015 17:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrgFGx98aQ4a for ; Wed, 22 Jul 2015 17:14:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723341B2FD0 for ; Wed, 22 Jul 2015 17:14:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.140.179; From: "Susan Hares" To: Date: Wed, 22 Jul 2015 20:13:52 -0400 Message-ID: <000001d0c4dc$77336310$659a2930$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D0C4BA.F02349B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDE23b7Xa25AqLISlutvO7hs14pcg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Alvaro Retana' , 'Kathleen Moriarty' , 'Alia Atlas' Subject: [secdir] Would you help the I2RS chairs with a QA review of security requirments and Security environment documents X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 00:14:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D0C4BA.F02349B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Security directorate: You reviewed our I2RS architecture document and provided really helpful comments. I2RS is preparing to work on the I2RS protocol - which is Netconf/restconf + additions. We have prepare two requirements documents: draft-hares-i2rs-auth-trans-04 - security requirements for protocol draft-mglt-i2rs-security-requirements-00 - security requirements for environment. The Netconf review expressed some concerns regarding whether these were complete enough for the security directorate. So, in parallel with doing a WG adoption call I would like to request a QA review of these documents. Also, if the person who does the review can read the secdir review of the architecture document to determine if we have resolved in these documents the questions from the architecture review. Due to the Netconf review, we would ask the person to review in 3 weeks from now. Could you let me know if this is possible? As chairs, we really value the advice of the security directorate. Sue Hares and Jeff Haas ------=_NextPart_000_0001_01D0C4BA.F02349B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Security = directorate:

 

You reviewed our I2RS architecture document and = provided really helpful comments.  I2RS is preparing to work on the = I2RS protocol – which is Netconf/restconf + additions.   = We have prepare two requirements documents:

 

draft-hares-i2rs-auth-trans-04  - = security requirements for protocol

draft-mglt-i2rs-security-requirements-00 –= security requirements for environment.

 

The Netconf = review expressed some concerns regarding whether these were complete = enough for the security directorate.   So, in parallel with = doing a WG adoption call I would like to request a QA review of these = documents.   Also, if the person who does the review can read = the secdir review of the architecture document to determine if we have = resolved in these documents the questions from the architecture review. =

 

Due to the = Netconf review, we would ask the person to review in 3 weeks from = now.  Could you let me know if this is possible?  As chairs, = we really value the advice of the security directorate.   =

 

Sue Hares = and Jeff Haas

 

 

------=_NextPart_000_0001_01D0C4BA.F02349B0-- From nobody Thu Jul 23 03:42:19 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25DA1A026F for ; Thu, 23 Jul 2015 03:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9DnaHrds0y2 for ; Thu, 23 Jul 2015 03:42:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735621A1A06 for ; Thu, 23 Jul 2015 03:42:13 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t6NAgA6h003464 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 23 Jul 2015 13:42:10 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t6NAgAff027391; Thu, 23 Jul 2015 13:42:10 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21936.50434.310305.874755@fireball.acr.fi> Date: Thu, 23 Jul 2015 13:42:10 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 10:42:15 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Warren Kumari is next in the rotation. For telechat 2015-08-06 Reviewer LC end Draft John Bradley T 2015-07-08 draft-ietf-xmpp-posh-04 Alan DeKok T 2015-07-09 draft-ietf-intarea-gre-ipv6-11 Donald Eastlake T 2015-07-13 draft-ietf-6man-ipv6-address-generation-privacy-07 Jeffrey Hutzelman T 2015-07-23 draft-ietf-sidr-rfc6490-bis-04 For telechat 2015-08-20 Dan Harkins T 2015-08-05 draft-vinapamula-softwire-dslite-prefix-binding-07 Last calls and special requests: Dave Cridland 2015-07-27 draft-bradner-iaoc-terms-01 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Olafur Gudmundsson 2015-07-29 draft-mm-netconf-time-capability-05 Phillip Hallam-Baker 2015-07-20 draft-ietf-dime-4over6-provisioning-04 Steve Hanna 2015-08-04 draft-sparks-genarea-review-tracker-02 Sam Hartman 2015-07-23 draft-ietf-ccamp-flexi-grid-fwk-05 Paul Hoffman 2015-07-27 draft-ietf-dime-ovli-08 Christian Huitema 2015-08-11 draft-ietf-dnsop-onion-tld-00 Chris Inacio 2015-07-29 draft-ietf-homenet-dncp-08 Leif Johansson 2015-08-17 draft-iab-crypto-alg-agility-06 Simon Josefsson 2015-08-02 draft-ietf-ccamp-wson-signal-compatibility-ospf-15 Charlie Kaufman 2015-08-04 draft-ietf-httpbis-cice-01 Scott Kelly 2015-08-04 draft-ietf-precis-mappings-11 Tero Kivinen 2014-06-06 draft-housley-implementer-obligations-02 -- kivinen@iki.fi From nobody Thu Jul 23 04:02:06 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7729F1A3B9C; Thu, 23 Jul 2015 04:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJv1_IvCYesK; Thu, 23 Jul 2015 04:02:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A761A701A; Thu, 23 Jul 2015 04:02:04 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t6NB22Sc005263 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Jul 2015 14:02:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t6NB22of004965; Thu, 23 Jul 2015 14:02:02 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21936.51625.952477.450949@fireball.acr.fi> Date: Thu, 23 Jul 2015 14:02:01 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-housley-implementer-obligations.all@tools.ietf.org X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Subject: [secdir] Secdir review of draft-housley-implementer-obligations-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:02:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the exceptations of implementers of IETF protocols, and security consideration section properly points out that following specifications might not be enough, maintenance is also needed to fix issues found later. It also provides nice example why security processing is exception to Postel's Law: For example, a password that is close, but not exactly right, is not sufficient to gain access. I think this document is ready. -- kivinen@iki.fi From nobody Thu Jul 23 13:08:32 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 830261B29FF; Thu, 23 Jul 2015 10:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1437673261; bh=4rTQb4uMOrh8F3ZVYCNqQ/EvmSl4gr/2FsiUYwr7fWA=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=AVfKLcE4xQZ3DTvcVHsh45sfPIIx4Bc1AzxrDtDFaYFzjA868uQcOqSzjb6k5ZaVc vTgnlzAwu+Zn1U8f9unW+0YfSbzpLOdwSJRcoXoXhtOJU4J2ZoZKeNlLoFpcregwPR 1xvK4zeOnYzFBiQ0YkdmPpg8F3ApDz04XlEGC/Kg= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CDF1B29FF for ; Thu, 23 Jul 2015 10:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtxFluV2QNUF for ; Thu, 23 Jul 2015 10:40:58 -0700 (PDT) Received: from jay.w3.org (jay.w3.org [128.30.52.169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4952F1B29F8 for ; Thu, 23 Jul 2015 10:40:58 -0700 (PDT) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith-wifi.sophia.w3.org) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZIKUK-0002H7-OB for new-work@ietf.org; Thu, 23 Jul 2015 13:40:56 -0400 To: new-work@ietf.org Date: Thu, 23 Jul 2015 19:40:56 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 23 Jul 2015 13:08:30 -0700 Subject: [secdir] [new-work] Proposed updated W3C Charter: Digital Publishing Interest Group (until 2015-08-20) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 17:41:01 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Digital Publishing Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Digital Publishing Interest Group: http://www.w3.org/2015/09/digpubig As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2015-08-20 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Ivan Herman, Digital Publishing Activity Lead . Thank you, Coralie Mercier, Acting Head of W3C Marketing & Communications [0] http://www.w3.org/dpub/ [1] http://www.w3.org/2014/Process-20140801/#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jul 24 07:30:30 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786AF1A1ABF for ; Fri, 24 Jul 2015 07:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43CCK-JBhS0Z for ; Fri, 24 Jul 2015 07:30:27 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963FD1A1A82 for ; Fri, 24 Jul 2015 07:30:27 -0700 (PDT) Received: from [10.47.60.67] (chwl001.hbnet.cz [62.168.35.67] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t6OEUPrk019723 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Jul 2015 07:30:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host chwl001.hbnet.cz [62.168.35.67] (may be forged) claimed to be [10.47.60.67] From: "Paul Hoffman" To: secdir Date: Fri, 24 Jul 2015 16:30:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [secdir] Secdir review of draft-ietf-dime-ovli X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 14:30:29 -0000 Greetings again. This document, "Diameter Overload Indication Conveyance", is a way for a Diameter server in a cluster to tell other servers in the cluster "don't send so many requests to me". It is pretty complex and fiddly, but seems sensible. The security considerations are numerous, but fairly well covered in the extensive Security Considerations section. Note that there is not much that can really be done here to address the biggest concern of spoofing. As the document says: Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This may cause complications when sending overload reports between non- adjacent nodes. (Nice use of "may" there...) So, there isn't much that can be demanded of this document without some obvious controls. Still, the Security Considerations section covers the likely attacks and problems. --Paul Hoffman From nobody Mon Jul 27 06:21:01 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494CD1B2D2F for ; Mon, 27 Jul 2015 06:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNGN2QNbpJAv for ; Mon, 27 Jul 2015 06:20:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9B91B2D20 for ; Mon, 27 Jul 2015 06:20:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 68EA4BE98; Mon, 27 Jul 2015 14:20:54 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4nv4w-VftXe; Mon, 27 Jul 2015 14:20:54 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 01458BEB5; Mon, 27 Jul 2015 14:20:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438003218; bh=1+MnorEAJxXzFsQ5U371w0DbvckFAuZgdQyJtacLSk8=; h=Date:From:To:CC:Subject:From; b=tTXmdaX9zb4ggKzb4BpC6ay1xfrKQ8kM1sqORcLTmhWGXndqecPJdBYob+349YEnT kKnX56YMIwy03GQgYvGe0JQ5aZ/NuRa6hsYnnd9LWp6DGurqwvXstfLhIvzd5f8X6c Z2G4KUfAjwhxumFd36ReBIrsLmnmbyPxW1htN18o= Message-ID: <55B63011.5040701@cs.tcd.ie> Date: Mon, 27 Jul 2015 14:20:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "secdir@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Kathleen Moriarty Subject: [secdir] Running a bit of an experiment and maybe you can help... X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 13:21:00 -0000 Hiya, One of the things about being an AD is that it takes too much time. The IESG are constantly trying to (find the time to:-) figure out ways to reduce the time needed for doing the AD gig. One of the things I'm going to try for a while is to limit the time I spend on document review/balloting, and you can maybe help a bit with that. Reviewing the on average 366 pages of Internet draft for each telechat is one of the most time-consuming parts of the AD job. For a while (until IETF94 or until it has been seen to not work), I'm going to not start reading documents for IESG telechats until the day before. In my timezone that gives me 1.5 days to go over the lot. (I'll slide the 1.5 day window about as needed when other stuff's going on.) I'll try keep some measures and report back at IETF94. (Feel free to suggest useful and easy things to measure.) That's more likely to work out if you good folks can a) try a little harder to make sure we've gotten a secdir review before telechat-3 days, (that is, by the Monday before) either by doing your review when assigned or by letting Tero know early you can't get to it so he can assign someone else and b) if you can try to write the reviews in such a way that I could just post the review as a ballot (assuming the reviewer and I agree about stuff, which is common), and (c) if you're willing to stay copied on the discussion of the draft beyond the telechat that can also really help. (Just note that in your review if you remember to.) Wrt point (a), if there is something we can change to make the assignments more visible, please let us and Tero know so you don't inadvertently drop one. Point (b) means that the review text is better written so as to be ok to send to say the WG that produced the draft and so that the set of actions that'd be needed to address the comment are as clear as possible and are such that someone could relatively easily check if they've been done or not when looking at a diff. (If you've time and can look at the ballot history for some documents you've reviewed it'd be great if you could better characterise those differences.) WRT (c), as we said in Prague, it's entirely ok if you don't want to or can't deal with extended discussion on a draft. When that's the case, just let us know and we'll take care of it. Whilst I'm trying this Kathleen will be operating as normal so we hope to not badly drop any balls no matter how this works out. (If we do, blame me though:-) Cheers, S. From nobody Mon Jul 27 09:24:41 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7749E1B303F; Mon, 27 Jul 2015 09:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WriZOQ7j9Ka; Mon, 27 Jul 2015 09:24:38 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFE41B3042; Mon, 27 Jul 2015 09:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9076; q=dns/txt; s=iport; t=1438014278; x=1439223878; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+diT8OcaScKsUUeYXbpkxtMKl8obxbsD8RU3TIbk9JY=; b=fta5vSZjCgmTcASkXFAwyeLRwr+ZBy2g8XZUtIOmNpdD++ByEj24OvUy dvNdTcy8Ai5qjfN0uYg5T27k3DICD7M1ZXnDivUHpV+YsimON+gAqs1bW z/MpqKxSTbP7ko5XgnlmtCQSOaelDpYDYAq2jubSNxX9Xc8KlxE7Dnkf6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2AwCwWrZV/5xdJa1SCYJITYE9BrwSCYdwAoFDOBQBAQEBAQEBgQqEIwEBAQR5DAQCAQgRBAEBKAcyFAkIAgQBDQWILtFTAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tOhCsRRgUGAQaEJgEEjEWFJ4J9AYxAgUWEHY9ig2ImggmBdG8BgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,555,1432598400"; d="scan'208,217";a="172765556" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 27 Jul 2015 16:24:37 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6RGObqi026267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 16:24:37 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.38]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 11:24:37 -0500 From: "Sri Gundavelli (sgundave)" To: "Bernie Volz (volz)" , Stephen Farrell , Catherine Meadows Thread-Topic: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08 Thread-Index: AQHQr1cxQgFsakfaFEigKP+HYJIb8p3U2DaAgAB3gwCAABDgAIAABGMAgBosQAA= Date: Mon, 27 Jul 2015 16:24:36 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E1CB6B149@xmb-rcd-x04.cisco.com> <55A00090.6060303@cs.tcd.ie> <489D13FBFA9B3E41812EA89F188F018E1CB6B426@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CB6B426@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.32.246.217] Content-Type: multipart/alternative; boundary="_000_D1DBA7071CD95Csgundaveciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dhc-access-network-identifier.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 16:24:40 -0000 --_000_D1DBA7071CD95Csgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Stephen /Catherine, Please lets us know if this text is sufficient to resolve this comment. Slightly tweaking the text per Bernie=92s comment. Now including IPsec refe= rence. "The information elements that this draft is exposing is the client=92s acc= ess-network information. These pertains to the access network to which the = client is attached, such as Access Technology Type (Ex: WLAN, Ethernet=85et= c), Access Point Identity (Name, BSSID), Operator Id/Realm. Exposing these = information elements to an eavesdropper has no implication on the end-user = security. But, in deployments where this information is considered secure a= nd when such threat cannot be mitigated using IPsec [RFC4301] or other secu= rity protocols, then the administrators have to consider disabling the capa= bility specified in this document on the DHCP entities." Regards Sri On 7/10/15, 10:43 AM, "Bernie Volz (volz)" > wrote: I am not aware of such data. My guess is that most SPs place this kind of t= raffic in what they hope to be an isolated network (i.e., behind firewalls,= ...). Also, much of this data is pretty easy to find anyway ... SSIDs are mostly = broadcast (or easy to snoop for), which mobile operator you use is probably= discoverable in seconds (heck I bet you=92d answer if I asked, or if I had= your number a google query would probably tell me ...). So, I'm not really= sure how critical this information tends to be. But, yet protecting it is = better than not protecting it. But I think steps should have been taken for= the other data in DHCP (relay to server). - Bernie -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, July 10, 2015 1:28 PM To: Bernie Volz (volz); Sri Gundavelli (sgundave) Cc: draft-ietf-dhc-access-network-identifier.all@tools.ietf.org; iesg@ietf.org; secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identi= fier-08 Hiya, On 10/07/15 17:27, Bernie Volz (volz) wrote: IPsec should also hide this information from pervasive monitoring (though how much IPsec is in use is an open question). Note also that as this is relay to server (or relay to relay) communication, one would hope that most SPs have taken measures to 'secure' this traffic either by using IPsec or VPNs. Do we have any data as to whether or not such protection does get deployed?= I'd not be surprised if there's not much public, but if there were it'd be= good to know. I also believe we have had reported cases where pieces of the network infra= structure of various kinds of operator have been targeted for PM purposes, = so while yes, it is really strange that someone would want to do that, it s= eems to be a real, and not notional, threat. Ta, S. --_000_D1DBA7071CD95Csgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <397BA896424848469DFD789C8CB5B9BF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Stephen /Catherine,=


Please lets us know if= this text is sufficient to resolve this comment.


Slightly tweaking the = text per Bernie=92s comment. Now including IPsec reference.

"The inform= ation elements that this draft is exposing is the client=92s access-network= information. These pertains to the access network to which the client is a= ttached, such as Access Technology Type (Ex: WLAN, Ethernet=85etc), Access Point Identity (Name, BSSID), Operator Id/Re= alm. Exposing these information elements to an eavesdropper has no implicat= ion on the end-user security. But, in deployments where this information is= considered secure and when such threat cannot be mitigated using IPsec [RFC4301] or other security protocols, the= n the administrators have to consider disabling the capability specified in= this document on the DHCP entities."



Regards
Sri





On 7/10/15, 10:43 AM, = "Bernie Volz (volz)" <volz@c= isco.com> wrote:

I am not aware of such data. My guess is that most SPs place this kind= of traffic in what they hope to be an isolated network (i.e., behind firew= alls, ...).

Also, much of this data is pretty easy to find anyway ... SSIDs are mo= stly broadcast (or easy to snoop for), which mobile operator you use is pro= bably discoverable in seconds (heck I bet you=92d answer if I asked, or if = I had your number a google query would probably tell me ...). So, I'm not really sure how critical this informati= on tends to be. But, yet protecting it is better than not protecting it. Bu= t I think steps should have been taken for the other data in DHCP (relay to= server).

- Bernie

-----Original Message-----
From: Stephen Farrell [ma= ilto:stephen.farrell@cs.tcd.ie]
Sent: Friday, July 10, 2015 1:28 PM
To: Bernie Volz (volz); Sri Gundavelli (sgundave)
Cc: draft-ietf-dhc-access-network-identifier.all@tools.ietf.org; iesg@ietf.org; secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-i= dentifier-08


Hiya,

On 10/07/15 17:27, Bernie Volz (volz) wrote:
IPsec should also hide this information from pervasive monitoring
(though how much IPsec is in use is an open question). Note also that =
as this is relay to server (or relay to relay) communication, one
would hope that most SPs have taken measures to 'secure' this traffic =
either by using IPsec or VPNs.

Do we have any data as to whether or not such protection does get depl= oyed? I'd not be surprised if there's not much public, but if there were it= 'd be good to know.

I also believe we have had reported cases where pieces of the network = infrastructure of various kinds of operator have been targeted for PM purpo= ses, so while yes, it is really strange that someone would want to do that,= it seems to be a real, and not notional, threat.

Ta,
S.

--_000_D1DBA7071CD95Csgundaveciscocom_-- From nobody Wed Jul 29 09:24:11 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0371AC3C7; Wed, 29 Jul 2015 09:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1438186772; bh=HEoR/JIIop1YVWLHjuSZDXpUZTKXbwfEQnfxrIVU2Vk=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=UCJ8Yjuow9+tzNWcwxCOjWCZs9/S7DmMsqIco8po9CbR2vuHzG2DeFe2PAf5arDE4 5trdEgoInewd+FMMA4g+VdwFoZqjA+yjEM+LPd7m+JvYL0KCzbQhpuMl99VL0+8XlA qL1TJ9BMaweuRBbFupOrSf7aNGO5v5YtFkguqcdk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4431AC3C7 for ; Wed, 29 Jul 2015 09:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BbHeHvMq0aw for ; Wed, 29 Jul 2015 09:19:27 -0700 (PDT) Received: from jay.w3.org (jay.w3.org [128.30.52.169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B1C1AC3BE for ; Wed, 29 Jul 2015 09:19:27 -0700 (PDT) Received: from eb.bleuazur.com ([88.173.33.195] helo=gillie.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZKU4j-00063m-TG for new-work@ietf.org; Wed, 29 Jul 2015 12:19:26 -0400 To: new-work@ietf.org Date: Wed, 29 Jul 2015 18:19:25 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 29 Jul 2015 09:24:05 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Platform and Timed Media Working Groups (until 2015-09-10) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 16:19:32 -0000 Hello, Today W3C Advisory Committee Representatives received a call for review that includes draft charters the following groups: * Web Platform Working Group: http://www.w3.org/2015/07/web-platform-wg.html * Timed Media Working Group http://www.w3.org/2015/07/timed-media-wg.html As part of ensuring that the community is aware of proposed work at W3C, the draft charters are public during the Advisory Committee review period. W3C invites public comments through 2015-09-10 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Philippe Le Hegaret, Interaction Domain Lead . Thank you, Coralie Mercier, Acting Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Jul 29 14:16:03 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DB21B2BE9 for ; Wed, 29 Jul 2015 14:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUVnfSLaEkgH for ; Wed, 29 Jul 2015 14:16:00 -0700 (PDT) Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5831B2C16 for ; Wed, 29 Jul 2015 14:15:54 -0700 (PDT) Received: from smtp27.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E6794180163; Wed, 29 Jul 2015 17:15:53 -0400 (EDT) Received: by smtp27.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id EBBC718030F; Wed, 29 Jul 2015 17:15:51 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Wed, 29 Jul 2015 21:15:53 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_08155B96-9374-4C8C-B080-406CA3DF0941" Date: Wed, 29 Jul 2015 17:15:51 -0400 Message-Id: To: ietf , netconf@ietf.org, draft-mm-netconf-time-capability.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Cc: secdir@ietf.org Subject: [secdir] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 21:16:01 -0000 --Apple-Mail=_08155B96-9374-4C8C-B080-406CA3DF0941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document is ready for publication The document is well written. The security considerations are clear and accurate. I would like = highlight one omission though. =20 This capability allows an attacker once it has gained access to schedule = events in the future even=20 though attackers access has been detected and revoked.=20 Olafur=20= --Apple-Mail=_08155B96-9374-4C8C-B080-406CA3DF0941 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I have reviewed = this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed = by the 
IESG.  These comments were written = primarily for the benefit of the 
security area = directors.  Document editors and WG chairs should = treat 
these comments just like any other last = call comments.

This document is = ready for publication
The document is well written.
The security considerations are clear = and accurate. I would like highlight one omission though. =  
This capability allows an attacker once it has gained = access to schedule events in the future even 
though attackers access has been detected and = revoked. 

Olafur 
= --Apple-Mail=_08155B96-9374-4C8C-B080-406CA3DF0941-- From nobody Wed Jul 29 14:39:55 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4190C1B2DA0 for ; Wed, 29 Jul 2015 14:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdzYoIZK4rX5 for ; Wed, 29 Jul 2015 14:39:52 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BA11B2D9C for ; Wed, 29 Jul 2015 14:39:43 -0700 (PDT) Received: by lbbud7 with SMTP id ud7so11556330lbb.3 for ; Wed, 29 Jul 2015 14:39:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3SSd7U0mfpRtILoNxpZr4mNRqP4/6E8RAuaYIFoidz0=; b=d92T+Wi2nWhBkVUeXApcbWywUJZCzxQWzn+PmbTr1RN3+f12GZ1lBs74oUX3ZfhQmM LXemDjMLj3apqoUXJ2utLuYEmQTAPmO8mBB/gAh3PD9hFf6UKolR90tTxP4wSPcUCkEr 9AVxfdWmq/6FBAmfuXhQxNLCJF1//SUc5YmYROeBOjjJ8wWjSaerkqijLyMU0ySVupfd pfIn2PIuEPGNsr8dmVMposMNNyNN6j0WUp/DEFotRdPM7hAtUoVxlIy1zXyqj7inde0r 2cMOe3OD2dKTz3krO2+klr3wf+uH1rI2Tmgtp5vO3FZbxA0Gd1PUDT0WNi0p65Lp1nwH KAiQ== X-Gm-Message-State: ALoCoQl0Ve6bSiYaGrvF/E+tULl3y5S9nhRKSxHWWAIzPw/2fDYilug0vklWwqMFgNAvaFKbDg6O MIME-Version: 1.0 X-Received: by 10.152.87.205 with SMTP id ba13mr39778711lab.37.1438205982133; Wed, 29 Jul 2015 14:39:42 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 29 Jul 2015 14:39:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2015 14:39:42 -0700 Message-ID: From: Andy Bierman To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=001a11c3539aade3af051c0a6c2e Archived-At: Cc: secdir@ietf.org, draft-mm-netconf-time-capability.all@ietf.org, ietf , Netconf Subject: Re: [secdir] [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 21:39:54 -0000 --001a11c3539aade3af051c0a6c2e Content-Type: text/plain; charset=UTF-8 Hi, I am curious if this is a security concern. When an event is scheduled, the ID and its scheduled time are sent out in a notification to potentially all clients. notification netconf-scheduled-message { leaf schedule-id { type string; description "The ID of the scheduled message."; } leaf scheduled-time { type yang:date-and-time; description "The time at which the RPC is scheduled to be performed."; } description "Indicates that a scheduled message was received."; reference "draft-mm-netconf-time-capability : Time Capability in NETCONF"; } Any client can get these notifications and know the ID (to cancel it) and the scheduled time. Is is a security issue that any client can get the schedule-id and use it to cancel the scheduled RPC? Andy On Wed, Jul 29, 2015 at 2:15 PM, Olafur Gudmundsson wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document is ready for publication > The document is well written. > > The security considerations are clear and accurate. I would like highlight > one omission though. > This capability allows an attacker once it has gained access to schedule > events in the future even > though attackers access has been detected and revoked. > > Olafur > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c3539aade3af051c0a6c2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am curious if this is a security = concern.
When an event is scheduled, the ID and its scheduled tim= e
are sent out in a notification to potentially all clients.

notification netc=
onf-scheduled-message {
        leaf schedule-id {
          type string;
          description
            "The ID of the scheduled message.";
        }

        leaf scheduled-time {
          type yang:date-and-time;
          description
            "The time at which the RPC is scheduled to be performed.&q=
uot;;
        }

        description
          "Indicates that a scheduled message was received.";

        reference
          "draft-mm-netconf-time-capability:
           Time Capability in NETCONF";
      }


Any client can get these n= otifications and know the ID (to cancel it)
and the scheduled time.

Is is a security issue that any client can get the sched= ule-id
and use it to cancel the scheduled R= PC?

Andy

On Wed, Ju= l 29, 2015 at 2:15 PM, Olafur Gudmundsson <ogud@ogud.com> wrote:=
I have reviewed this= document as part of the security directorate's=C2=A0
ongoing effort to review a= ll IETF documents being processed by the=C2=A0
IESG.=C2=A0 These comments were written= primarily for the benefit of the=C2=A0
security area directors.=C2=A0 Document editor= s and WG chairs should treat=C2=A0
these comments just like any other last call commen= ts.

This document= is ready for publication
The document is well written.

The security considerations are clear and accur= ate. I would like highlight one omission though. =C2=A0
This capability allows an atta= cker once it has gained access to schedule events in the future even=C2=A0<= /div>
though atta= ckers access has been detected and revoked.=C2=A0

Olafur=C2=A0

____________________________= ___________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--001a11c3539aade3af051c0a6c2e-- From nobody Wed Jul 29 23:43:11 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FD41A8849; Wed, 29 Jul 2015 23:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVTLXE9zgHgH; Wed, 29 Jul 2015 23:43:08 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9231A870F; Wed, 29 Jul 2015 23:43:08 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t6U6YfdI024771; Wed, 29 Jul 2015 23:43:07 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 1vv91rpu8d-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jul 2015 23:43:06 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 30 Jul 2015 09:43:03 +0300 Received: from IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a]) by IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.1044.021; Thu, 30 Jul 2015 09:43:03 +0300 From: Tal Mizrahi To: Andy Bierman , Olafur Gudmundsson Thread-Topic: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx Thread-Index: AQHQykcigNupE2ajyEaQCVpIBzXexJ3zkGIg Date: Thu, 30 Jul 2015 06:43:02 +0000 Message-ID: <0960eb5365954b73afde1c70ba5164a0@IL-EXCH01.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: multipart/alternative; boundary="_000_0960eb5365954b73afde1c70ba5164a0ILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-07-30_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1507300120 Archived-At: Cc: Netconf , "draft-mm-netconf-time-capability.all@ietf.org" , ietf , "secdir@ietf.org" Subject: Re: [secdir] [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 06:43:10 -0000 --_000_0960eb5365954b73afde1c70ba5164a0ILEXCH01marvellcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KWW91IG1ha2UgYSBnb29kIHBvaW50Lg0KV2UgaW50ZW5kIHRvIGFkZCB0ZXh0 IChzZWUgYmVsb3cpIHRoYXQgZGVzY3JpYmVzIHRoaXMgcG9pbnQgaW4gdGhlIG5leHQgdmVyc2lv biBvZiB0aGUgZHJhZnQuDQpQbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgZnVydGhlciBj b21tZW50cy4NCg0KDQpIZXJlIGlzIHRoZSB1cGRhdGVkIHRleHQgb24gdGhlIGxhc3QgcGFyYWdy YXBoIG9mIHRoZSBzZWN1cml0eSBzZWN0aW9uOg0KDQpUaGlzIFlBTkcgbW9kdWxlIGRlZmluZXMg dGhlIDxjYW5jZWwtc2NoZWR1bGU+IFJQQy4gVGhpcyBSUEMgbWF5IGJlIGNvbnNpZGVyZWQgc2Vu c2l0aXZlIG9yIHZ1bG5lcmFibGUgaW4gc29tZSBuZXR3b3JrIGVudmlyb25tZW50cy4gU2luY2Ug dGhlIHZhbHVlIG9mIHRoZSA8c2NoZWR1bGUtaWQ+IGlzIGtub3duIHRvIGFsbCB0aGUgY2xpZW50 cyB0aGF0IGFyZSBzdWJzY3JpYmVkIHRvIG5vdGlmaWNhdGlvbnMgZnJvbSB0aGUgc2VydmVyLCB0 aGUgPGNhbmNlbC1zY2hlZHVsZT4gUlBDIG1heSBiZSB1c2VkIG1hbGljaW91c2x5IHRvIGF0dGFj ayBzZXJ2ZXJzIGJ5IGNhbmNlbGluZyB0aGVpciBwZW5kaW5nIFJQQ3MuIFRoaXMgYXR0YWNrIGlz IGFkZHJlc3NlZCBpbiB0d28gbGF5ZXJzOiAoaSkgc2VjdXJpdHkgYXQgdGhlIHRyYW5zcG9ydCBs YXllciwgbGltaXRpbmcgdGhlIGF0dGFjayBvbmx5IHRvIGNsaWVudHMgdGhhdCBoYXZlIHN1Y2Nl c3NmdWxseSBpbml0aWF0ZWQgYSBzZWN1cmUgc2Vzc2lvbiB3aXRoIHRoZSBzZXJ2ZXIsIGFuZCAo aWkpIHRoZSBhdXRob3JpemF0aW9uIGxldmVsIHJlcXVpcmVkIHRvIGNhbmNlbCBhbiBSUEMgc2hv dWxkIGJlIHRoZSBzYW1lIGFzIHRoZSBsZXZlbCByZXF1aXJlZCB0byBzY2hlZHVsZSBpdCwgbGlt aXRpbmcgdGhlIGF0dGFjayBvbmx5IHRvIGF0dGFja2VycyB3aXRoIGFuIGF1dGhvcml6YXRpb24g bGV2ZWwgdGhhdCBpcyBlcXVhbCB0byBvciBoaWdoZXIgdGhhbiB0aGF0IG9mIHRoZSBjbGllbnQg dGhhdCBpbml0aWF0ZWQgdGhlIHNjaGVkdWxlZCBSUEMuDQoNCg0KVGhhbmtzLA0KVGFsLg0KDQoN CkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDMwLCAyMDE1IDEyOjQwIEFN DQpUbzogT2xhZnVyIEd1ZG11bmRzc29uDQpDYzogc2VjZGlyQGlldGYub3JnOyBkcmFmdC1tbS1u ZXRjb25mLXRpbWUtY2FwYWJpbGl0eS5hbGxAaWV0Zi5vcmc7IGlldGY7IE5ldGNvbmYNClN1Ympl Y3Q6IFJlOiBbTmV0Y29uZl0gU2VjLURpciBSZXZpZXc6IGRyYWZ0LW1tLW5ldGNvbmYtdGltZS1j YXBhYmlsaXR5LTA1LnR4DQoNCkhpLA0KDQpJIGFtIGN1cmlvdXMgaWYgdGhpcyBpcyBhIHNlY3Vy aXR5IGNvbmNlcm4uDQpXaGVuIGFuIGV2ZW50IGlzIHNjaGVkdWxlZCwgdGhlIElEIGFuZCBpdHMg c2NoZWR1bGVkIHRpbWUNCmFyZSBzZW50IG91dCBpbiBhIG5vdGlmaWNhdGlvbiB0byBwb3RlbnRp YWxseSBhbGwgY2xpZW50cy4NCg0KDQpub3RpZmljYXRpb24gbmV0Y29uZi1zY2hlZHVsZWQtbWVz c2FnZSB7DQoNCiAgICAgICAgbGVhZiBzY2hlZHVsZS1pZCB7DQoNCiAgICAgICAgICB0eXBlIHN0 cmluZzsNCg0KICAgICAgICAgIGRlc2NyaXB0aW9uDQoNCiAgICAgICAgICAgICJUaGUgSUQgb2Yg dGhlIHNjaGVkdWxlZCBtZXNzYWdlLiI7DQoNCiAgICAgICAgfQ0KDQoNCg0KICAgICAgICBsZWFm IHNjaGVkdWxlZC10aW1lIHsNCg0KICAgICAgICAgIHR5cGUgeWFuZzpkYXRlLWFuZC10aW1lOw0K DQogICAgICAgICAgZGVzY3JpcHRpb24NCg0KICAgICAgICAgICAgIlRoZSB0aW1lIGF0IHdoaWNo IHRoZSBSUEMgaXMgc2NoZWR1bGVkIHRvIGJlIHBlcmZvcm1lZC4iOw0KDQogICAgICAgIH0NCg0K DQoNCiAgICAgICAgZGVzY3JpcHRpb24NCg0KICAgICAgICAgICJJbmRpY2F0ZXMgdGhhdCBhIHNj aGVkdWxlZCBtZXNzYWdlIHdhcyByZWNlaXZlZC4iOw0KDQogICAgICAgIHJlZmVyZW5jZQ0KDQog ICAgICAgICAgImRyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5PGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eT46DQoNCiAgICAg ICAgICAgVGltZSBDYXBhYmlsaXR5IGluIE5FVENPTkYiOw0KDQogICAgICB9DQoNCg0KDQpBbnkg Y2xpZW50IGNhbiBnZXQgdGhlc2Ugbm90aWZpY2F0aW9ucyBhbmQga25vdyB0aGUgSUQgKHRvIGNh bmNlbCBpdCkNCmFuZCB0aGUgc2NoZWR1bGVkIHRpbWUuDQoNCklzIGlzIGEgc2VjdXJpdHkgaXNz dWUgdGhhdCBhbnkgY2xpZW50IGNhbiBnZXQgdGhlIHNjaGVkdWxlLWlkDQphbmQgdXNlIGl0IHRv IGNhbmNlbCB0aGUgc2NoZWR1bGVkIFJQQz8NCg0KDQpBbmR5DQoNCg0KT24gV2VkLCBKdWwgMjks IDIwMTUgYXQgMjoxNSBQTSwgT2xhZnVyIEd1ZG11bmRzc29uIDxvZ3VkQG9ndWQuY29tPG1haWx0 bzpvZ3VkQG9ndWQuY29tPj4gd3JvdGU6DQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh cyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQpvbmdvaW5nIGVmZm9ydCB0byBy ZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUNCklFU0cuICBU aGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0 aGUNCnNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hh aXJzIHNob3VsZCB0cmVhdA0KdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0 IGNhbGwgY29tbWVudHMuDQoNClRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9u DQpUaGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuLg0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgYXJlIGNsZWFyIGFuZCBhY2N1cmF0ZS4gSSB3b3VsZCBsaWtlIGhpZ2hsaWdodCBvbmUg b21pc3Npb24gdGhvdWdoLg0KVGhpcyBjYXBhYmlsaXR5IGFsbG93cyBhbiBhdHRhY2tlciBvbmNl IGl0IGhhcyBnYWluZWQgYWNjZXNzIHRvIHNjaGVkdWxlIGV2ZW50cyBpbiB0aGUgZnV0dXJlIGV2 ZW4NCnRob3VnaCBhdHRhY2tlcnMgYWNjZXNzIGhhcyBiZWVuIGRldGVjdGVkIGFuZCByZXZva2Vk Lg0KDQpPbGFmdXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRj b25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mDQoNCg== --_000_0960eb5365954b73afde1c70ba5164a0ILEXCH01marvellcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWVubG87DQoJcGFub3NlLTE6 MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uaG9lbnpiDQoJe21zby1z dHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91IG1ha2Ug YSBnb29kIHBvaW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGludGVuZCB0 byBhZGQgdGV4dCAoc2VlIGJlbG93KSB0aGF0IGRlc2NyaWJlcyB0aGlzIHBvaW50IGluIHRoZSBu ZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Q bGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgZnVydGhlciBjb21tZW50cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZXJlIGlzIHRoZSB1cGRhdGVk IHRleHQgb24gdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoZSBzZWN1cml0eSBzZWN0aW9uOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhpcyBZQU5HIG1vZHVsZSBkZWZpbmVzIHRoZSAmbHQ7Y2FuY2VsLXNjaGVkdWxlJmd0 OyBSUEMuIFRoaXMgUlBDIG1heSBiZSBjb25zaWRlcmVkIHNlbnNpdGl2ZSBvciB2dWxuZXJhYmxl IGluIHNvbWUgbmV0d29yayBlbnZpcm9ubWVudHMuIFNpbmNlIHRoZSB2YWx1ZSBvZiB0aGUNCiAm bHQ7c2NoZWR1bGUtaWQmZ3Q7IGlzIGtub3duIHRvIGFsbCB0aGUgY2xpZW50cyB0aGF0IGFyZSBz dWJzY3JpYmVkIHRvIG5vdGlmaWNhdGlvbnMgZnJvbSB0aGUgc2VydmVyLCB0aGUgJmx0O2NhbmNl bC1zY2hlZHVsZSZndDsgUlBDIG1heSBiZSB1c2VkIG1hbGljaW91c2x5IHRvIGF0dGFjayBzZXJ2 ZXJzIGJ5IGNhbmNlbGluZyB0aGVpciBwZW5kaW5nIFJQQ3MuIFRoaXMgYXR0YWNrIGlzIGFkZHJl c3NlZCBpbiB0d28gbGF5ZXJzOiAoaSkgc2VjdXJpdHkgYXQgdGhlDQogdHJhbnNwb3J0IGxheWVy LCBsaW1pdGluZyB0aGUgYXR0YWNrIG9ubHkgdG8gY2xpZW50cyB0aGF0IGhhdmUgc3VjY2Vzc2Z1 bGx5IGluaXRpYXRlZCBhIHNlY3VyZSBzZXNzaW9uIHdpdGggdGhlIHNlcnZlciwgYW5kIChpaSkg dGhlIGF1dGhvcml6YXRpb24gbGV2ZWwgcmVxdWlyZWQgdG8gY2FuY2VsIGFuIFJQQyBzaG91bGQg YmUgdGhlIHNhbWUgYXMgdGhlIGxldmVsIHJlcXVpcmVkIHRvIHNjaGVkdWxlIGl0LCBsaW1pdGlu ZyB0aGUgYXR0YWNrDQogb25seSB0byBhdHRhY2tlcnMgd2l0aCBhbiBhdXRob3JpemF0aW9uIGxl dmVsIHRoYXQgaXMgZXF1YWwgdG8gb3IgaGlnaGVyIHRoYW4gdGhhdCBvZiB0aGUgY2xpZW50IHRo YXQgaW5pdGlhdGVkIHRoZSBzY2hlZHVsZWQgUlBDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBCaWVybWFuPGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDMwLCAyMDE1IDEyOjQwIEFNPGJyPg0KPGI+VG86 PC9iPiBPbGFmdXIgR3VkbXVuZHNzb248YnI+DQo8Yj5DYzo8L2I+IHNlY2RpckBpZXRmLm9yZzsg ZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHkuYWxsQGlldGYub3JnOyBpZXRmOyBOZXRj b25mPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gU2VjLURpciBSZXZpZXc6IGRy YWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5LTA1LnR4PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBjdXJpb3VzIGlmIHRoaXMgaXMgYSBzZWN1 cml0eSBjb25jZXJuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2hlbiBhbiBldmVudCBpcyBzY2hlZHVsZWQsIHRoZSBJRCBhbmQgaXRzIHNjaGVk dWxlZCB0aW1lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hcmUgc2VudCBvdXQgaW4gYSBub3RpZmljYXRpb24gdG8gcG90ZW50aWFsbHkgYWxsIGNs aWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5ub3RpZmljYXRpb24gbmV0Y29uZi1zY2hlZHVsZWQtbWVzc2FnZSB7PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgc2NoZWR1bGUtaWQg ezxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 eXBlIHN0cmluZzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhlIElEIG9mIHRoZSBzY2hlZHVs ZWQgbWVzc2FnZS4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVh ZiBzY2hlZHVsZWQtdGltZSB7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHR5cGUgeWFuZzpkYXRlLWFuZC10aW1lOzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmcXVvdDtUaGUgdGltZSBhdCB3aGljaCB0aGUgUlBDIGlzIHNjaGVkdWxlZCB0byBiZSBwZXJm b3JtZWQuJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt9 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0 aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZxdW90O0luZGljYXRlcyB0aGF0IGEgc2NoZWR1bGVkIG1lc3NhZ2Ugd2FzIHJlY2VpdmVkLiZx dW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJlbmNl PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tbS1uZXRjb25m LXRpbWUtY2FwYWJpbGl0eSI+ZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHk8L2E+Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW55IGNsaWVudCBjYW4gZ2V0IHRoZXNlIG5vdGlmaWNhdGlvbnMgYW5k IGtub3cgdGhlIElEICh0byBjYW5jZWwgaXQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgdGhlIHNjaGVkdWxlZCB0aW1lLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyBpcyBhIHNlY3Vy aXR5IGlzc3VlIHRoYXQgYW55IGNsaWVudCBjYW4gZ2V0IHRoZSBzY2hlZHVsZS1pZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHVzZSBpdCB0 byBjYW5jZWwgdGhlIHNjaGVkdWxlZCBSUEM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1bCAyOSwgMjAxNSBhdCAyOjE1IFBNLCBP bGFmdXIgR3VkbXVuZHNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpvZ3VkQG9ndWQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+b2d1ZEBvZ3VkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O01lbmxvJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5vbmdvaW5nIGVmZm9ydCB0 byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+SUVTRy4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2VyZSB3 cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPnNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPnRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxv JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ VGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+VGhlIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWVubG8mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBhcmUgY2xlYXIgYW5kIGFjY3VyYXRlLiBJIHdvdWxkIGxpa2UgaGlnaGxpZ2h0IG9uZSBv bWlzc2lvbiB0aG91Z2guICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGlzIGNhcGFi aWxpdHkgYWxsb3dzIGFuIGF0dGFja2VyIG9uY2UgaXQgaGFzIGdhaW5lZCBhY2Nlc3MgdG8gc2No ZWR1bGUgZXZlbnRzIGluIHRoZSBmdXR1cmUgZXZlbiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTQuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij50aG91Z2ggYXR0YWNrZXJzIGFjY2VzcyBoYXMgYmVlbiBkZXRlY3RlZCBhbmQgcmV2b2tl ZC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjVwdDtmb250LWZhbWlseTomcXVv dDtNZW5sbyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojODg4ODg4Ij5PbGFmdXImbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_0960eb5365954b73afde1c70ba5164a0ILEXCH01marvellcom_-- From nobody Wed Jul 29 23:44:36 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136FC1A8A47; Wed, 29 Jul 2015 23:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeNKks0xoKEt; Wed, 29 Jul 2015 23:44:30 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5441A88A0; Wed, 29 Jul 2015 23:44:30 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t6U6ZNkH015227; Wed, 29 Jul 2015 23:44:28 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 1vv9yp5qxm-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jul 2015 23:44:28 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 30 Jul 2015 09:44:26 +0300 Received: from IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a]) by IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.1044.021; Thu, 30 Jul 2015 09:44:26 +0300 From: Tal Mizrahi To: Olafur Gudmundsson , ietf , "netconf@ietf.org" , "draft-mm-netconf-time-capability.all@ietf.org" Thread-Topic: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx Thread-Index: AQHQykPII6R5rilafEWsJYafMYxlJp3zkXSQ Date: Thu, 30 Jul 2015 06:44:26 +0000 Message-ID: <0bde13a98445401fb9a19a1c950f77f2@IL-EXCH01.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: multipart/alternative; boundary="_000_0bde13a98445401fb9a19a1c950f77f2ILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-07-30_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1507300120 Archived-At: Cc: "secdir@ietf.org" Subject: Re: [secdir] [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 06:44:32 -0000 --_000_0bde13a98445401fb9a19a1c950f77f2ILEXCH01marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Olafur, Thanks for the feedback. >This capability allows an attacker once it has gained access to schedule e= vents in the future even >though attackers access has been detected and revoked. We will add a paragraph that describes this potential threat to the next ve= rsion of the draft. Thanks, Tal. From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Olafur Gudmund= sson Sent: Thursday, July 30, 2015 12:16 AM To: ietf; netconf@ietf.org; draft-mm-netconf-time-capability.all@ietf.org Cc: secdir@ietf.org Subject: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-05.tx I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication The document is well written. The security considerations are clear and accurate. I would like highlight = one omission though. This capability allows an attacker once it has gained access to schedule ev= ents in the future even though attackers access has been detected and revoked. Olafur --_000_0bde13a98445401fb9a19a1c950f77f2ILEXCH01marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Olafur,

 <= /p>

Thanks for the feedback.<= o:p>

 <= /p>

>This capability allows an attacker once it= has gained access to schedule events in the future even 

>though attackers access has been detected = and revoked. 

 <= /p>

We will add a paragraph t= hat describes this potential threat to the next version of the draft.<= /o:p>

 <= /p>

Thanks,=

Tal.

 <= /p>

From: Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of Olafur Gudmundsson
Sent: Thursday, July 30, 2015 12:16 AM
To: ietf; netconf@ietf.org; draft-mm-netconf-time-capability.all@iet= f.org
Cc: secdir@ietf.org
Subject: [Netconf] Sec-Dir Review: draft-mm-netconf-time-capability-= 05.tx

 

I have reviewed this document as part of the s= ecurity directorate's 

ongoing effort to review all IETF documents be= ing processed by the 

IESG.  These comments were written primar= ily for the benefit of the 

security area directors.  Document editor= s and WG chairs should treat 

these comments just like any other last call c= omments.

 

This document is ready for publication

The document is well written.

 

The security considerations are clear and accu= rate. I would like highlight one omission though.  <= /p>

This capability allows an attacker once it has= gained access to schedule events in the future even 

though attackers access has been detected and = revoked. 

 

Olafur 

--_000_0bde13a98445401fb9a19a1c950f77f2ILEXCH01marvellcom_-- From nobody Thu Jul 30 01:04:18 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381C11B2B8B for ; Thu, 30 Jul 2015 01:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH6DJOfyG8qs for ; Thu, 30 Jul 2015 01:04:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC9F1B2B89 for ; Thu, 30 Jul 2015 01:04:14 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t6U84BsA016949 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Jul 2015 11:04:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t6U84BOt019331; Thu, 30 Jul 2015 11:04:11 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21945.55931.178837.741850@fireball.acr.fi> Date: Thu, 30 Jul 2015 11:04:11 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 08:04:17 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview David Mandelberg is next in the rotation. For telechat 2015-08-06 Reviewer LC end Draft John Bradley T 2015-07-08 draft-ietf-xmpp-posh-04 Alan DeKok T 2015-07-09 draft-ietf-intarea-gre-ipv6-11 Donald Eastlake T 2015-07-13 draft-ietf-6man-ipv6-address-generation-privacy-07 Phillip Hallam-Baker T 2015-07-20 draft-ietf-dime-4over6-provisioning-04 Sam Hartman T 2015-07-23 draft-ietf-ccamp-flexi-grid-fwk-05 Jeffrey Hutzelman T 2015-07-23 draft-ietf-sidr-rfc6490-bis-04 Simon Josefsson T 2015-08-02 draft-ietf-ccamp-wson-signal-compatibility-ospf-15 For telechat 2015-08-20 Dan Harkins T 2015-08-05 draft-vinapamula-softwire-dslite-prefix-binding-07 Last calls and special requests: Dave Cridland 2015-07-27 draft-bradner-iaoc-terms-01 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Steve Hanna 2015-08-04 draft-sparks-genarea-review-tracker-02 Chris Inacio 2015-07-29 draft-ietf-homenet-dncp-08 Leif Johansson 2015-08-17 draft-iab-crypto-alg-agility-06 Charlie Kaufman 2015-08-04 draft-ietf-httpbis-cice-01 Scott Kelly 2015-08-04 draft-ietf-precis-mappings-11 Warren Kumari 2015-08-11 draft-ietf-ippm-2679-bis-03 Ben Laurie 2015-08-11 draft-ietf-dnsop-dns-terminology-03 Matt Lepinski 2015-08-11 draft-ietf-dnsop-root-loopback-02 Chris Lonvick 2015-08-11 draft-ietf-ippm-2680-bis-03 -- kivinen@iki.fi From nobody Thu Jul 30 14:33:12 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296C21ACE3D; Thu, 30 Jul 2015 14:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbdfqLV1HgOJ; Thu, 30 Jul 2015 14:33:08 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292641ACE3A; Thu, 30 Jul 2015 14:33:07 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t6ULX4j9030018 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 30 Jul 2015 23:33:05 +0200 X-Hashcash: 1:22:150730:iesg@ietf.org::Zr4Ek+IA1hW9SgYf:0cu5F X-Hashcash: 1:22:150730:secdir@ietf.org::+Gwva1PQ39XPYEb9:68yH X-Hashcash: 1:22:150730:draft-ietf-ccamp-wson-signal-compatibility-ospf.all@tools.ietf.org::HoGf544FEMq2WKmt:z1B From: Simon Josefsson To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ccamp-wson-signal-compatibility-ospf.all@tools.ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Thu, 30 Jul 2015 23:33:03 +0200 Message-ID: <87bnetuy9c.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [secdir] Review of draft-ietf-ccamp-wson-signal-compatibility-ospf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 21:33:09 -0000 --=-=-= Content-Type: text/plain I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes GMPLS OSPF improvements to support WSON network elements. I don't find any security relevant matters in the document, so I believe the document is Ready. The Security Considerations section could refer to the remaining normative references' Security Considerations for completeness, but those documents does not add anything juicy, so I don't find this particulary important. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVupgPAAoJEIYLf7sy+BGdo3oH/jHa5AMshdj8+z3f+61TK3R4 WQLo+FyEYBijKB0CweMXDYChlou3ClQE90JBHIlfq/IgZLy5+yMyoPzAFPWbAXKD 4fPrsenrMQrgSD1FU38egJsGsb2Abivu+IETdqCgFr16+lwxteExOIkOg4lgFCFr y2L3CpS9q96kby3cKAuQ3Ho6mqM7mLu3TYl3KzGpwqIrpB4SyzOCtUEUs+CFK5H3 Pfv/O+AAEJjsdCKtr4boXhEwj3Ma5YBdFdhYICuHJG5K3ZRWOFj0mB56AwO0s0ax J5AFzbEONB1YAsvghyEtHJqkLbv9OoDsQxFwCna+6loty9I3X1Pl1mxTAG8kl+I= =vKjb -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 31 07:52:24 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8501A896E; Fri, 31 Jul 2015 07:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu5bnXa3ARPD; Fri, 31 Jul 2015 07:52:20 -0700 (PDT) Received: from BAY004-OMC2S19.hotmail.com (bay004-omc2s19.hotmail.com [65.54.190.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6974F1A8971; Fri, 31 Jul 2015 07:52:18 -0700 (PDT) Received: from BAY167-W85 ([65.54.190.123]) by BAY004-OMC2S19.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 31 Jul 2015 07:52:18 -0700 X-TMN: [JEndHmVC+8Fh9J6bNdL2LprQUnFucEdU/F4+1klYqH0=] X-Originating-Email: [charliekaufman@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_24e52a2c-3627-4740-8241-1ec52fa68101_" From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-httpbis-cice.all@tools.ietf.org" Date: Fri, 31 Jul 2015 07:52:17 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jul 2015 14:52:18.0249 (UTC) FILETIME=[7F2B3B90:01D0CBA0] Archived-At: Subject: [secdir] secdir review of draft-ietf-httpbis-cice-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 14:52:23 -0000 --_24e52a2c-3627-4740-8241-1ec52fa68101_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. This pleasantly short document proposes a small extension to http whereby a= server indicates to a client what encodings of the payload sent with the r= equest would have been accepted=2C and is aimed mainly at allowing clients = to learn whether the server supports gzip compression. I agree with the aut= hors that the addition of this information does not introduce any new secur= ity considerations. The information retrieved must be considered only a "hi= nt" because the acceptable encodings can change at any time without notice= =2C so the values returned are not a fully reliable indicator of what encod= ings will be acceptable on a subsequent request. There are some challenges associated with this method of delivering a confi= guration hint. As the document notes=2C the acceptable encodings might not = be global to a server=2C but rather might vary for different resources on t= he same server=2C or even with different request methods for the same resou= rce. In practice=2C clients are likely to guess the encodings supported acc= ording to responses it has received for other resources and methods on the = same server. If the client guesses wrong=2C it might end up wasting bandwid= th by sending some large payload uncompressed when it could have been compr= essed or - worse - compressed and subsequently uncompressed when the initia= l request is rejected. One way to avoid this possibility that might be worthwhile if the payload w= ere large enough would be to first make a request with some "known bad" enc= oding specified and an empty body. When the server rejected the request bas= ed on the bad encoding=2C it would specify what encodings were acceptable. = If would be architecturally cleaner is there were some reserved encoding na= me that could be guaranteed never to be valid=2C though in practice clients= could choose an encoding name like UNSUPPORTED or INVALID and be pretty co= nfident no one would ever standardize that as an encoding name. While this specification recommends that the Accept-Encoding header only be= returned on successes and on failures where the problem was an invalid enc= oding=2C clients can never count on that behavior because implementations t= hat don't implement this specification will never return that header even i= f it is a problem with the encoding. --Charlie = --_24e52a2c-3627-4740-8241-1ec52fa68101_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as= part of the security directorate's ongoing effort to review all IETF docum= ents being processed by the IESG. These comments were written primarily for= the benefit of the security area directors. Document editors and WG chairs= should treat these comments just like any other last call comments. This pleasantly short document proposes a small extension to http whereby a= server indicates to a client what encodings of the payload sent with the r= equest would have been accepted=2C and is aimed mainly at allowing clients = to learn whether the server supports gzip compression. I agree with the aut= hors that the addition of this information does not introduce any new secur= ity considerations. The information retrieved must be considered only a "hi= nt" because the acceptable encodings can change at any time without notice= =2C so the values returned are not a fully reliable indicator of what encod= ings will be acceptable on a subsequent request. There are some challenges associated with this method of delivering a confi= guration hint. As the document notes=2C the acceptable encodings might not = be global to a server=2C but rather might vary for different resources on t= he same server=2C or even with different request methods for the same resou= rce. In practice=2C clients are likely to guess the encodings supported acc= ording to responses it has received for other resources and methods on the = same server. If the client guesses wrong=2C it might end up wasting bandwid= th by sending some large payload uncompressed when it could have been compr= essed or - worse - compressed and subsequently uncompressed when the initia= l request is rejected. One way to avoid this possibility that might be worthwhile if the payload w= ere large enough would be to first make a request with some "known bad" enc= oding specified and an empty body. When the server rejected the request bas= ed on the bad encoding=2C it would specify what encodings were acceptable. = If would be architecturally cleaner is there were some reserved encoding na= me that could be guaranteed never to be valid=2C though in practice clients= could choose an encoding name like UNSUPPORTED or INVALID and be pretty co= nfident no one would ever standardize that as an encoding name. While this specification recommends that the Accept-Encoding header only be= returned on successes and on failures where the problem was an invalid enc= oding=2C clients can never count on that behavior because implementations t= hat don't implement this specification will never return that header even i= f it is a problem with the encoding. --Charlie
= --_24e52a2c-3627-4740-8241-1ec52fa68101_-- From nobody Fri Jul 31 08:02:05 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8B51A8991; Fri, 31 Jul 2015 08:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oivUy9jXqMe; Fri, 31 Jul 2015 08:01:59 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8829E1A8F43; Fri, 31 Jul 2015 08:01:58 -0700 (PDT) Received: from [192.168.1.197] (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id A508915A0295; Fri, 31 Jul 2015 17:01:55 +0200 (CEST) To: Charlie Kaufman , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-httpbis-cice.all@tools.ietf.org" References: From: Julian Reschke Message-ID: <55BB8DE3.5070608@greenbytes.de> Date: Fri, 31 Jul 2015 17:01:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-httpbis-cice-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 15:02:03 -0000 On 2015-07-31 16:52, Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. This pleasantly short > document proposes a small extension to http whereby a server indicates > to a client what encodings of the payload sent with the request would > have been accepted, and is aimed mainly at allowing clients to learn > whether the server supports gzip compression. I agree with the authors > that the addition of this information does not introduce any new > security considerations. The information retrieved must be considered > only a "hint" because the acceptable encodings can change at any time > without notice, so the values returned are not a fully reliable > indicator of what encodings will be acceptable on a subsequent request. > There are some challenges associated with this method of delivering a > configuration hint. As the document notes, the acceptable encodings > might not be global to a server, but rather might vary for different > resources on the same server, or even with different request methods for > the same resource. In practice, clients are likely to guess the > encodings supported according to responses it has received for other > resources and methods on the same server. If the client guesses wrong, I disagree that this is likely. > it might end up wasting bandwidth by sending some large payload > uncompressed when it could have been compressed or - worse - compressed > and subsequently uncompressed when the initial request is rejected. One > way to avoid this possibility that might be worthwhile if the payload > were large enough would be to first make a request with some "known bad" > encoding specified and an empty body. When the server rejected the > request based on the bad encoding, it would specify what encodings were > acceptable. If would be architecturally cleaner is there were some That would be one additional round trip with an unclear outcome on broken servers. If the additional round trip is acceptable, using OPTIONS might make more sense. > reserved encoding name that could be guaranteed never to be valid, > though in practice clients could choose an encoding name like > UNSUPPORTED or INVALID and be pretty confident no one would ever > standardize that as an encoding name. While this specification > recommends that the Accept-Encoding header only be returned on successes > and on failures where the problem was an invalid encoding, clients can > never count on that behavior because implementations that don't > implement this specification will never return that header even if it is > a problem with the encoding. --Charlie That is true, but I'm not sure what to make out of it. Do you have a specific text change in mind? Best regards, Julian -- bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 From nobody Fri Jul 31 08:08:58 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD231A21BD; Fri, 31 Jul 2015 08:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKdIcLuW3WsE; Fri, 31 Jul 2015 08:08:55 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110641A21B8; Fri, 31 Jul 2015 08:08:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0A0B520778; Fri, 31 Jul 2015 11:08:07 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_0igvm567e9; Fri, 31 Jul 2015 11:08:06 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 31 Jul 2015 11:08:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 679608271A; Fri, 31 Jul 2015 11:08:53 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org,iesg@ietf.org Date: Fri, 31 Jul 2015 11:08:53 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: draft-ietf-ccamp-flexi-grid-fwk-05.all@tools.ietf.org Subject: [secdir] Secdir Review of draft-ietf-ccamp-flexi-grid-fwk-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 15:08:57 -0000 I've been assigned at the secdir reviewer for draft-ietf-ccamp-flexi-grid-fwk-05. This document appears ready for publication. This document describes a framework and requirements for the GMPLS control plane for flexible grid DWDM optical transport networks. The basic change is that rather than having a fixed grid of frequencies, the frequency and slot widthof each media channel are parameters of the control plane. I read through section 1, 2, good chunks of section3, 4 and 7. The authors claim in section 7 that the security implications are the same between a flexible grid network and a fixed grip netwerk. This seems to generally be true. I think that the flexible grid network introduces new ways that attacks can result. As an example, the control plane might be able to loosen restrictions on a filter so that an attacker was able to see more than they should. (my physics is entirely inadequate to the task of figuring out whether this is interesting or would for example just create a DOS) It might be harder to express this particular misconfiguration/attack in a fixed network. However it seems that the general issue is as the authors claim present in the fixed grid network. Which is to say, that I don't think the security is identical, but I agree with the authors that the security considerations seem substantially similar. I don't see value for changes in the text in this document. I did not read the cited references and confirm that the described security considerations in those documents are adequate. Thanks for a well-written document.