From nobody Tue Jul 1 04:14:44 2014 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 79A931A004B; Tue, 1 Jul 2014 04:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 3t6sKfsQz5E7; Tue, 1 Jul 2014 04:14:36 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C7B1A003A; Tue, 1 Jul 2014 04:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12714; q=dns/txt; s=iport; t=1404213275; x=1405422875; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=hSOB9kb6Js931Ujogno4BUThjp+nqZD7EhZNuF96O74=; b=Uu+GJU5Lk9vaCAoMAsn9brMQj0ZXLlWHn1RcMOITXwcACFpy75u1KdY9 g8JxmCLQUE3ggnac/iUQq/xgRjMSMwUza8kh2xb+pGj9+qpWncS4GRbX9 oG6ciUowpUaURXPpBYbWbb7ZbDci+6gSI9pNIOjvg8iKGRy1LsOFogy/e w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FABSXslOtJssW/2dsb2JhbABag1+JI6JoAQEBAQEFAW4BkhIBhnBTAYEgdYQDAQEBAwEBAQFrCgEQCw4KCRYPCQMCAQIBFTAGAQwBBQIBAYg2CA3IBBeFb4N0hG5OB4RDAQSaZYFIhUGMeoNEOy8 X-IronPort-AV: E=Sophos; i="5.01,581,1400025600"; d="scan'208,217"; a="97438332" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 01 Jul 2014 11:14:32 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s61BEVHZ030234; Tue, 1 Jul 2014 11:14:31 GMT Message-ID: <53B29817.3090905@cisco.com> Date: Tue, 01 Jul 2014 13:14:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Harrington , Tero Kivinen References: <21421.29586.427961.926637@fireball.kivinen.iki.fi> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020000070409000204020306" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/EMHNwTlqazS4z1hwx6V_lg7lhCs Cc: secdir@ietf.org, draft-ietf-eman-energy-monitoring-mib.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-eman-energy-monitoring-mib-10.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: Tue, 01 Jul 2014 11:14:38 -0000 This is a multi-part message in MIME format. --------------020000070409000204020306 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi David, Tero, Thanks for your review. We will post a new draft version with this boilerplate at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security We will also correct "theeoPowerAdminState" Finally, wrt your comment: The formatting of the draft was bit wierd in places (extra ^L in the middle of page etc), but I assume those will be fixed by the RFC editor. This is one of those legacy draft published with word :-) Regards, Benoit > Hi, > > comments inline. > > dbh > > On Jun 27, 2014, at 9:37 AM, Tero Kivinen 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 describes the MIB for energy monitoring. It has mostly >> read only information about the current energy use etc, but it also >> have one important writable attribute eoPowerAdminState which can be >> used to change the power state of the device (shut it down?). The MIB >> also have second part which can be used to create notifications and >> intervals for enery usage. >> >> Both of these are pointed out in the security consideations section >> and the security considerations section mostly follows the MIB >> security guidelines text, but differs in one paragraph. The text in >> draft says: >> >> It is RECOMMENDED that implementers consider the security >> features as provided by the SNMPv3 framework (see [RFC3410], >> section 8), including full support for the SNMPv3 cryptographic >> mechanisms (for authentication and privacy). > These are the old guidelines. > >> Where the guidelines text says: >> >> Implementations SHOULD provide the security features described >> by the SNMPv3 framework (see [RFC3410]), and implementations >> claiming compliance to the SNMPv3 standard MUST include full >> support for authentication and privacy via the User-based >> Security Model (USM) [RFC3414] with the AES cipher algorithm >> [RFC3826]. Implementations MAY also provide support for the >> Transport Security Model (TSM) [RFC5591] in combination with a >> secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. >> >> Asking implementors to consider security features is something that >> cannot be verified, i.e. there is no way I can see whether the >> implementor x actually even considered the security features or not, >> thus making RECOMMENDATION to consider security feature is just >> stupid. > Yeah, but it’s the best that could be negotiated at that point in time. > >> The guidelines text instead makes SHOULD for providing >> security. >> >> Why is this text changed from the mib-security framework >> (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security). > The document was probably based on an older mib document. > It MIGHT have been based on the templates on the tools page before I got them updated. > > The document should be updated to the new boilerplate. > >> Also I think the security considerations section should mention that >> almost all of the MIB items do have privacy issues, as for example >> reading the power usage of the home TV/PC/game console/washing machine >> will give indication whether person is at home, and what he might be >> doing. Thus the first paragraph saying "Some objects may be considered >> sensitive", I would say most of the objects are sensitive in most >> environments. > without changing the boilerplate, of course … > >> Actually it seems to bit dangerous to have mostly read-only >> information in MIB where the only read-write item is the very security >> sensitive object which can be used to turn the devices off. Especially >> when the MIB name is Power and Energy MONITORING MIB. Casual operator >> might just check the MIB name and then notice there is lots of >> read-only information like "eoPowerNamePlate" or "eoPowerAccuracy", >> etc and just assume this is only for monitoring the power usage, and >> not notice that it also allows turning device on and off via one >> read-write value hidden among the read-only values. >> >> I would be more happy if that one read-write value would be moved to >> separate MIB, but I do not know if there is better place for it. If it >> is not moved, then it would be better to change the title of the draft >> o say "Power and Energy Monitoring and Control MIB" or something >> similar which indicates more clearly that this MIB can be used to >> control devices. >> >> Nits: >> >> In section 11: >> >> - Unauthorized changes to the eoPowerOperState (via >> theeoPowerAdminState ) MAY disrupt the power settings of the >> ^^^^^^^^^^^^^^^^^^^^ >> >> s/theeoPowerAdminState/the eoPowerAdminState/. >> >> The formatting of the draft was bit wierd in places (extra ^L in the >> middle of page etc), but I assume those will be fixed by the RFC >> editor. >> -- >> kivinen@iki.fi >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > . > --------------020000070409000204020306 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi David, Tero,

Thanks for your review.
We will post a new draft version with this boilerplate at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security

We will also correct "theeoPowerAdminState"

Finally, wrt your comment:
The formatting of the draft was bit wierd in places (extra ^L in the
middle of page etc), but I assume those will be fixed by the RFC
editor.
This is one of those legacy draft published with word :-)

Regards, Benoit
Hi,

comments inline.

dbh

On Jun 27, 2014, at 9:37 AM, Tero Kivinen <kivinen@iki.fi> 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 describes the MIB for energy monitoring. It has mostly
read only information about the current energy use etc, but it also
have one important writable attribute eoPowerAdminState which can be
used to change the power state of the device (shut it down?). The MIB
also have second part which can be used to create notifications and
intervals for enery usage.

Both of these are pointed out in the security consideations section
and the security considerations section mostly follows the MIB
security guidelines text, but differs in one paragraph. The text in
draft says:

      It is RECOMMENDED that implementers consider the security
      features as provided by the SNMPv3 framework (see [RFC3410],
      section 8), including full support for the SNMPv3 cryptographic
      mechanisms (for authentication and privacy).

These are the old guidelines. 


Where the guidelines text says:

     Implementations SHOULD provide the security features described
     by the SNMPv3 framework (see [RFC3410]), and implementations
     claiming compliance to the SNMPv3 standard MUST include full
     support for authentication and privacy via the User-based
     Security Model (USM) [RFC3414] with the AES cipher algorithm
     [RFC3826]. Implementations MAY also provide support for the
     Transport Security Model (TSM) [RFC5591] in combination with a
     secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].

Asking implementors to consider security features is something that
cannot be verified, i.e. there is no way I can see whether the
implementor x actually even considered the security features or not,
thus making RECOMMENDATION to consider security feature is just
stupid.

Yeah, but it’s the best that could be negotiated at that point in time.


The guidelines text instead makes SHOULD for providing
security.

Why is this text changed from the mib-security framework
(http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security).

The document was probably based on an older mib document.
It MIGHT have been based on the templates on the tools page before I got them updated.

The document should be updated to the new boilerplate.


Also I think the security considerations section should mention that
almost all of the MIB items do have privacy issues, as for example
reading the power usage of the home TV/PC/game console/washing machine
will give indication whether person is at home, and what he might be
doing. Thus the first paragraph saying "Some objects may be considered
sensitive", I would say most of the objects are sensitive in most
environments.

without changing the boilerplate, of course …


Actually it seems to bit dangerous to have mostly read-only
information in MIB where the only read-write item is the very security
sensitive object which can be used to turn the devices off. Especially
when the MIB name is Power and Energy MONITORING MIB. Casual operator
might just check the MIB name and then notice there is lots of
read-only information like "eoPowerNamePlate" or "eoPowerAccuracy",
etc and just assume this is only for monitoring the power usage, and
not notice that it also allows turning device on and off via one
read-write value hidden among the read-only values.

I would be more happy if that one read-write value would be moved to
separate MIB, but I do not know if there is better place for it. If it
is not moved, then it would be better to change the title of the draft
o say "Power and Energy Monitoring and Control MIB" or something
similar which indicates more clearly that this MIB can be used to
control devices. 

Nits:

In section 11:

      - Unauthorized changes to the eoPowerOperState (via
        theeoPowerAdminState ) MAY disrupt the power settings of the
	 ^^^^^^^^^^^^^^^^^^^^

s/theeoPowerAdminState/the eoPowerAdminState/.

The formatting of the draft was bit wierd in places (extra ^L in the
middle of page etc), but I assume those will be fixed by the RFC
editor. 
-- 
kivinen@iki.fi

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

.

--------------020000070409000204020306-- From nobody Tue Jul 1 04:24:38 2014 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 0F3541A0063; Tue, 1 Jul 2014 04:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 R8S9R37EROKf; Tue, 1 Jul 2014 04:24:33 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF871A006D; Tue, 1 Jul 2014 04:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14700; q=dns/txt; s=iport; t=1404213870; x=1405423470; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=TZh3h0YkhJnm3G6b+Lydg0Q1o4u+/JKQ0e8IS+imdvM=; b=ZxwgeAKBv8dIntG5uqQ+1ZL+8N7rq1WXGIY0tJVW1gUZ78dQ75CaZf1M eTZVJOt60sKhIxcSG1eciCN7ufVuhJt8tzehCIHrxYsPFAWGBuVO60gEH UFzjygS0LIychbiURpJAgY8+uMlmkofEkSqeGhSmbE0/pFM1Y6E5ynyuv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAGuZslOtJssW/2dsb2JhbABag1+JI6JoAQEBAQEFAW4BkhIBhnBTAYEgdYQDAQEBBAEBAWsKARALDgoJFg8JAwIBAgEVMAYBDAEFAgEBiD4Nx38XhW+DdIRuTgeEQwEEmmWBSIVBjHqDRDsv X-IronPort-AV: E=Sophos; i="5.01,581,1400025600"; d="scan'208,217"; a="97443184" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 01 Jul 2014 11:24:28 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s61BOR5P009367; Tue, 1 Jul 2014 11:24:27 GMT Message-ID: <53B29A6B.2020402@cisco.com> Date: Tue, 01 Jul 2014 13:24:27 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Harrington , Tero Kivinen References: <21421.29586.427961.926637@fireball.kivinen.iki.fi> <53B29817.3090905@cisco.com> In-Reply-To: <53B29817.3090905@cisco.com> Content-Type: multipart/alternative; boundary="------------060101060108000606010302" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/jaEbM3_cfhQpsTJF-YN2vObwBdY Cc: iesg@ietf.org, draft-ietf-eman-energy-monitoring-mib.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-eman-energy-monitoring-mib-10.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: Tue, 01 Jul 2014 11:24:36 -0000 This is a multi-part message in MIME format. --------------060101060108000606010302 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, I forgot to mention: I would be more happy if that one read-write value would be moved to separate MIB, but I do not know if there is better place for it. If it is not moved, then it would be better to change the title of the draft o say "Power and Energy Monitoring and Control MIB" or something similar which indicates more clearly that this MIB can be used to control devices. Fine with me to change the title to "Power and Energy Monitoring and Control MIB" All instances of "Power and Energy Monitoring MIB" in the draft should be changed too. Regards, Benoit > Hi David, Tero, > > Thanks for your review. > We will post a new draft version with this boilerplate at > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > > We will also correct "theeoPowerAdminState" > > Finally, wrt your comment: > > The formatting of the draft was bit wierd in places (extra ^L in the > middle of page etc), but I assume those will be fixed by the RFC > editor. > > This is one of those legacy draft published with word :-) > > Regards, Benoit >> Hi, >> >> comments inline. >> >> dbh >> >> On Jun 27, 2014, at 9:37 AM, Tero Kivinen 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 describes the MIB for energy monitoring. It has mostly >>> read only information about the current energy use etc, but it also >>> have one important writable attribute eoPowerAdminState which can be >>> used to change the power state of the device (shut it down?). The MIB >>> also have second part which can be used to create notifications and >>> intervals for enery usage. >>> >>> Both of these are pointed out in the security consideations section >>> and the security considerations section mostly follows the MIB >>> security guidelines text, but differs in one paragraph. The text in >>> draft says: >>> >>> It is RECOMMENDED that implementers consider the security >>> features as provided by the SNMPv3 framework (see [RFC3410], >>> section 8), including full support for the SNMPv3 cryptographic >>> mechanisms (for authentication and privacy). >> These are the old guidelines. >> >>> Where the guidelines text says: >>> >>> Implementations SHOULD provide the security features described >>> by the SNMPv3 framework (see [RFC3410]), and implementations >>> claiming compliance to the SNMPv3 standard MUST include full >>> support for authentication and privacy via the User-based >>> Security Model (USM) [RFC3414] with the AES cipher algorithm >>> [RFC3826]. Implementations MAY also provide support for the >>> Transport Security Model (TSM) [RFC5591] in combination with a >>> secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. >>> >>> Asking implementors to consider security features is something that >>> cannot be verified, i.e. there is no way I can see whether the >>> implementor x actually even considered the security features or not, >>> thus making RECOMMENDATION to consider security feature is just >>> stupid. >> Yeah, but it’s the best that could be negotiated at that point in time. >> >>> The guidelines text instead makes SHOULD for providing >>> security. >>> >>> Why is this text changed from the mib-security framework >>> (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security). >> The document was probably based on an older mib document. >> It MIGHT have been based on the templates on the tools page before I got them updated. >> >> The document should be updated to the new boilerplate. >> >>> Also I think the security considerations section should mention that >>> almost all of the MIB items do have privacy issues, as for example >>> reading the power usage of the home TV/PC/game console/washing machine >>> will give indication whether person is at home, and what he might be >>> doing. Thus the first paragraph saying "Some objects may be considered >>> sensitive", I would say most of the objects are sensitive in most >>> environments. >> without changing the boilerplate, of course … >> >>> Actually it seems to bit dangerous to have mostly read-only >>> information in MIB where the only read-write item is the very security >>> sensitive object which can be used to turn the devices off. Especially >>> when the MIB name is Power and Energy MONITORING MIB. Casual operator >>> might just check the MIB name and then notice there is lots of >>> read-only information like "eoPowerNamePlate" or "eoPowerAccuracy", >>> etc and just assume this is only for monitoring the power usage, and >>> not notice that it also allows turning device on and off via one >>> read-write value hidden among the read-only values. >>> >>> I would be more happy if that one read-write value would be moved to >>> separate MIB, but I do not know if there is better place for it. If it >>> is not moved, then it would be better to change the title of the draft >>> o say "Power and Energy Monitoring and Control MIB" or something >>> similar which indicates more clearly that this MIB can be used to >>> control devices. >>> >>> Nits: >>> >>> In section 11: >>> >>> - Unauthorized changes to the eoPowerOperState (via >>> theeoPowerAdminState ) MAY disrupt the power settings of the >>> ^^^^^^^^^^^^^^^^^^^^ >>> >>> s/theeoPowerAdminState/the eoPowerAdminState/. >>> >>> The formatting of the draft was bit wierd in places (extra ^L in the >>> middle of page etc), but I assume those will be fixed by the RFC >>> editor. >>> -- >>> kivinen@iki.fi >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> . >> > --------------060101060108000606010302 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi,

I forgot to mention:
I would be more happy if that one read-write value would be moved to
separate MIB, but I do not know if there is better place for it. If it
is not moved, then it would be better to change the title of the draft
o say "Power and Energy Monitoring and Control MIB" or something
similar which indicates more clearly that this MIB can be used to
control devices.
Fine with me to change the title to "Power and Energy Monitoring and Control MIB"
All instances of "Power and Energy Monitoring MIB" in the draft should be changed too.

Regards, Benoit
Hi David, Tero,

Thanks for your review.
We will post a new draft version with this boilerplate at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security

We will also correct "theeoPowerAdminState"

Finally, wrt your comment:
The formatting of the draft was bit wierd in places (extra ^L in the
middle of page etc), but I assume those will be fixed by the RFC
editor.
This is one of those legacy draft published with word :-)

Regards, Benoit
Hi,

comments inline.

dbh

On Jun 27, 2014, at 9:37 AM, Tero Kivinen <kivinen@iki.fi> 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 describes the MIB for energy monitoring. It has mostly
read only information about the current energy use etc, but it also
have one important writable attribute eoPowerAdminState which can be
used to change the power state of the device (shut it down?). The MIB
also have second part which can be used to create notifications and
intervals for enery usage.

Both of these are pointed out in the security consideations section
and the security considerations section mostly follows the MIB
security guidelines text, but differs in one paragraph. The text in
draft says:

      It is RECOMMENDED that implementers consider the security
      features as provided by the SNMPv3 framework (see [RFC3410],
      section 8), including full support for the SNMPv3 cryptographic
      mechanisms (for authentication and privacy).

These are the old guidelines. 


Where the guidelines text says:

     Implementations SHOULD provide the security features described
     by the SNMPv3 framework (see [RFC3410]), and implementations
     claiming compliance to the SNMPv3 standard MUST include full
     support for authentication and privacy via the User-based
     Security Model (USM) [RFC3414] with the AES cipher algorithm
     [RFC3826]. Implementations MAY also provide support for the
     Transport Security Model (TSM) [RFC5591] in combination with a
     secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].

Asking implementors to consider security features is something that
cannot be verified, i.e. there is no way I can see whether the
implementor x actually even considered the security features or not,
thus making RECOMMENDATION to consider security feature is just
stupid.

Yeah, but it’s the best that could be negotiated at that point in time.


The guidelines text instead makes SHOULD for providing
security.

Why is this text changed from the mib-security framework
(http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security).

The document was probably based on an older mib document.
It MIGHT have been based on the templates on the tools page before I got them updated.

The document should be updated to the new boilerplate.


Also I think the security considerations section should mention that
almost all of the MIB items do have privacy issues, as for example
reading the power usage of the home TV/PC/game console/washing machine
will give indication whether person is at home, and what he might be
doing. Thus the first paragraph saying "Some objects may be considered
sensitive", I would say most of the objects are sensitive in most
environments.

without changing the boilerplate, of course …


Actually it seems to bit dangerous to have mostly read-only
information in MIB where the only read-write item is the very security
sensitive object which can be used to turn the devices off. Especially
when the MIB name is Power and Energy MONITORING MIB. Casual operator
might just check the MIB name and then notice there is lots of
read-only information like "eoPowerNamePlate" or "eoPowerAccuracy",
etc and just assume this is only for monitoring the power usage, and
not notice that it also allows turning device on and off via one
read-write value hidden among the read-only values.

I would be more happy if that one read-write value would be moved to
separate MIB, but I do not know if there is better place for it. If it
is not moved, then it would be better to change the title of the draft
o say "Power and Energy Monitoring and Control MIB" or something
similar which indicates more clearly that this MIB can be used to
control devices. 

Nits:

In section 11:

      - Unauthorized changes to the eoPowerOperState (via
        theeoPowerAdminState ) MAY disrupt the power settings of the
	 ^^^^^^^^^^^^^^^^^^^^

s/theeoPowerAdminState/the eoPowerAdminState/.

The formatting of the draft was bit wierd in places (extra ^L in the
middle of page etc), but I assume those will be fixed by the RFC
editor. 
-- 
kivinen@iki.fi

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

.


--------------060101060108000606010302-- From nobody Tue Jul 1 04:26:11 2014 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 BF2361A003A for ; Tue, 1 Jul 2014 04:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 i_vG_VbuOLpv for ; Tue, 1 Jul 2014 04:26:06 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3D11A0047 for ; Tue, 1 Jul 2014 04:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4965; q=dns/txt; s=iport; t=1404213966; x=1405423566; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=JCJEVDv6L8iLBaY74CQr6Mc3QPiqdlCpTzupwtPZoZA=; b=Yz3BWeuVkrKcqVKw/MCjRLWRxa/r7J/FSqs4EZ7ex+ydiW1RmtKXgX9/ HG4KfsGNMqrDsG22czUXMGleS4shQuUgW+U7oaqJPZsCIqZKPSSNXOahH itAoj09NjrYKKnXBpkZS9jkksBASMVJY8NO397CyvMu1mrYBFqiu2hU6w c=; X-IronPort-AV: E=Sophos;i="5.01,581,1400025600"; d="scan'208";a="97466749" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 01 Jul 2014 11:26:05 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s61BQ3xe011468; Tue, 1 Jul 2014 11:26:04 GMT Message-ID: <53B29ACB.6050108@cisco.com> Date: Tue, 01 Jul 2014 13:26:03 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Kent , secdir , jparello@cisco.com, moulchan@cisco.com, n.brownlee@auckland.ac.nz, tnadeau@lucidvision.com, joel jaeggli References: <53A99DB2.5050707@bbn.com> <20140624204718.GB19710@elstar.local> In-Reply-To: <20140624204718.GB19710@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/DbKMXdH4am4S5tLrk-fQ_aywbbo Subject: Re: [secdir] SECDIR review of draft-ietf-eman-energy-aware-mib-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: Tue, 01 Jul 2014 11:26:08 -0000 Hi Stephen, Thanks for your review. We will post a new draft version with this boilerplate at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security Our mistake for using a previous boilerplate. Regards, Benoit > Hi, > > there is a security boilerplate that we are following. > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > > If you think this is not appropriate anymore, we need to have a > discussion to update the boilerplate instead of debating specific MIB > modules. Note that this topic comes up periodically - usually without > much changes to the boilerplate at the end. Lets see the result this > time. ;-) > > /js > > On Tue, Jun 24, 2014 at 11:48:02AM -0400, Stephen Kent wrote: >> I 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. Since I am not a MIB expert, my >> comments are strictly related to the security-relevant aspects of this >> document. >> >> This document, as its name implies, defines a MIB for energy management >> devices. Given increasing concern over security in the so-called >> "cyber-physical" realm, a MIB for such devices clearly merits scrutiny. >> Also, to the extent that such devices (e.g., meters) might be associated >> with residences, there are personal privacy issues that ought to be >> addressed, in the PERPASS era. >> >> The document is clearly written; my compliments to the authors in that >> regard. The one odd thing I noted was that Sections 11.1 and 11.2 appear >> between Sections 6 and 7! I think this was a cut and paste error that is >> easily remedied. >> >> The Security Considerations section (7) is about one-half page in >> length. I have several concerns with the text here. >> >> First, the text says "It is thus important to control even GET and/or >> NOTIFY access to these objects and possibly to even encrypt the values >> of these objects when sending them over the network via SNMP." This >> seems to be an understatement. I'd like to see the text here RECOMMEND >> use of encryption to provide confidentiality. This would be supportive >> of personal privacy, in residential contexts, and physical security in >> residential and enterprise settings. I can imagine a movie in which >> burglars use a lack of encryption to gain critical information about >> building infrastructure from a an energy MIB J. >> >> The text later says "There are a number of management objects defined in >> these MIB modules with a MAX-ACCESS clause of read-write and/or >> read-create.Such objects MAY be considered sensitive or vulnerable in >> some network environments.The support for SET operations in a non-secure >> environment without proper protection can have a negative effect on >> network operations. Again, this strikes me as a significant >> understatement, i.e., the scope of the "negative effect" could be much >> broader that just a network. (Power outlets are cited as examples of >> objects, so anything plugged into an outlet could be effected, right?) >> There should be more emphasis on the need for access control. >> >> The text later says "SNMP versions prior to SNMPv3 did not include >> adequate security. Even if the network itself is secure (for example, by >> using IPsec), there is still no secure control over who on the secure >> network is allowed to access and GET/SET (read/change/create/delete) the >> objects in these MIB modules." This is a misleading. IPsec natively >> provides access control. It would be accurate to say that the access >> controls offered by IPsec would only limit who could access the MIB. >> What the authors seem to suggest here is finer-grained access control, >> so that one can manage GET/SET privileges for the set of individuals who >> are authorized to connect to the MIB via the SMTP port, right? >> >> The text discussing use of SNMPv3 security is a bit confusing. >> >> It RECOMMENDS that implementers "consider" SMNPv3 security features, but >> then says deployment of SNMP versions prior to v3 is NOT RECOMMENDED. >> The first paragraph discussing this topic deals with thinking about >> support (vs. use) of SNMPv3, while the second paragraph makes a much >> stronger statement about deployment. It would be more consistent to >> mandate support (MUST or SHOULD) for SNMPv3 in entities that incorporate >> this MIB. Separately the document can RECOMMEND enabling SNMPv3 security >> features in deployments, for the reasons cited. >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Tue Jul 1 06:23:08 2014 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 7C2861A02E6 for ; Tue, 1 Jul 2014 06:23:07 -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 CyEpXgxnA93w for ; Tue, 1 Jul 2014 06:23:06 -0700 (PDT) Received: from smtp130.ord.emailsrvr.com (smtp130.ord.emailsrvr.com [173.203.6.130]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5AEC1A02C1 for ; Tue, 1 Jul 2014 06:23:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp29.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 0C12C28013D; Tue, 1 Jul 2014 09:23:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp29.relay.ord1a.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 82E43280136; Tue, 1 Jul 2014 09:23:05 -0400 (EDT) From: Scott Kelly Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jul 2014 06:23:06 -0700 Message-Id: <892FE251-707A-459E-BE8F-ACEF99610DDA@hyperthought.com> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-eman-battery-mib.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rpmsbDlZigWqxgC6SDUBfUjdOB8 Subject: [secdir] secdir review of draft-ietf-eman-battery-mib-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: Tue, 01 Jul 2014 13:23:07 -0000 This is a day late, sorry! 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 defines a MIB that provides information on the status of = batteries in managed devices. The security considerations section = recommends snmpv3 due to the potential sensitivity of the information. I = see no additional security issues.= From nobody Tue Jul 1 07:45:39 2014 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 3EDF21B27ED for ; Tue, 1 Jul 2014 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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, RP_MATCHES_RCVD=-0.651, 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 fc6ZRlBoUffy for ; Tue, 1 Jul 2014 07:45:36 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A497B1A03EC for ; Tue, 1 Jul 2014 07:45:35 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id x12so7845473qac.35 for ; Tue, 01 Jul 2014 07:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EWw2HatA+uziywEzZ8BKfgOUbZmdvZd0fNMYr8dzTfg=; b=GbVX13Sih8VSFwChvi79VqtVz3qnIvJETdkIi/U6t4DwcbC3L1UicBXhR/fI2JF59g YxwMJMc+gRjbnWBuj9ivxyJq6LusFkoy0buBx5Jd9IX8ArQbtV3+HKJJyAyO7XHpOuMm 77s8SiHK/IkG/QjWnkXTCsLFHtDTw6IthN1s/PtoeZCC9McrysXEEtdsB0tkslc13qVR HYoyQWraxBF6OnVsvbLDH8zrSgxuSuNg8X2fVlM98M0obEtaJu2xsOqQ13XSrMj9MEkd LAIzBgj2BXe9wYpIY20zi5PH3WhSx9jUeUIoB+zJAJcYIZaUQOyjlR8/s/IkmonkQpC0 vfgw== 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=EWw2HatA+uziywEzZ8BKfgOUbZmdvZd0fNMYr8dzTfg=; b=KvsPgutHr/MLgBIcAOVD9GmYOhGwFBzH6Hn57bRJuuEFwFwPiYaHL4v8v2TD1hwodx TJnNmpVxnXIe46YaeekamBkhCEle14XRQuKYmFwqsnJq5dWr/hUH0OFhNgnUTTMO799v A1ShEpWhU4CBV+KGVF7ousc7QL3NliCq1A2flh7K5ZS6PYvUZS4FYXkDYyOrqhrLK+l7 DnlY+fWVvQrnK3C6+EqFgyWO4TgKmSW1V0uaWH+DVxHipuSMXDur/ftHhDhngefulT3f /3V/xxgAyjjTJzHAftsmvjC56yCAlpqzfOjqFqNU60xv7pGgfCQny/HmkdG9k45HUryf fGpA== X-Gm-Message-State: ALoCoQksk9ok9LUsRMH+6lLrIWK5rBJZVX0lpzcxOBNyvo/8S0WUqY9AKAe5zhRVhw3mRJDN0ePS MIME-Version: 1.0 X-Received: by 10.224.134.201 with SMTP id k9mr73673415qat.59.1404225934739; Tue, 01 Jul 2014 07:45:34 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Tue, 1 Jul 2014 07:45:34 -0700 (PDT) Date: Tue, 1 Jul 2014 15:45:34 +0100 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-pce-questions.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ip4hx1L7FTM5XZRxU0Zg5tckheg Subject: [secdir] Security review of draft-ietf-pce-questions-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, 01 Jul 2014 14:45: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. Status: ready with issues. The security considerations section makes this claim: "This informational document does not define any new protocol elements or mechanism. As such, it does not introduce any new security issues." I agree with the premise, but not the conclusion: just because an RFC does not introduce new security issues, that does not mean that there are no security considerations. Indeed, this RFC discusses many things that have quite serious security considerations, without mentioning any of them. For example, section 4 "How Do I Find My PCE?" (the very first question) advocates a number of potentially completely insecure mechanisms with no mention of their security properties (or otherwise). This is obviously pervasive, given the stance taken in the security considerations. The document does mention that RFC 6952 gives a security analysis for PCEP, and perhaps this is sufficient but it seems to me that a document intended to give useful background information to noobs should include security directly in that information rather than defer to another giant document (which mixes PCEP info with other protocols). From nobody Thu Jul 3 04:16:15 2014 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 5813F1B288B for ; Thu, 3 Jul 2014 04:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] 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 pw-1qDiQ1pTB for ; Thu, 3 Jul 2014 04:16:09 -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 82C6E1B2883 for ; Thu, 3 Jul 2014 04:16:09 -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 s63BG6SN002908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 3 Jul 2014 14:16:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s63BG6Cw003608; Thu, 3 Jul 2014 14:16:06 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21429.15222.331829.570675@fireball.kivinen.iki.fi> Date: Thu, 3 Jul 2014 14:16:06 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/jOBbzstkcBl-OPAeN88uScL5rqc 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, 03 Jul 2014 11:16:12 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Takeshi Takahashi is next in the rotation. For telechat 2014-07-10 Reviewer LC end Draft Jeffrey Hutzelman T 2014-06-20 draft-ietf-mmusic-rtsp-nat-21 Catherine Meadows T 2014-07-07 draft-ietf-paws-protocol-12 Russ Mundy T 2014-07-03 draft-ietf-sidr-cps-04 Sandy Murphy T 2014-07-04 draft-ietf-stir-threats-03 Magnus Nystrom T 2014-07-04 draft-ietf-xmpp-websocket-07 Ondrej Sury T 2014-05-28 draft-ietf-ipfix-text-adt-06 Last calls and special requests: Shawn Emery R2014-07-16 draft-ietf-tictoc-security-requirements-10 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Sam Hartman 2014-06-23 draft-ietf-dnsop-child-syncronization-01 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Leif Johansson 2014-06-24 draft-ietf-netext-wifi-epc-eap-attributes-08 Warren Kumari 2014-07-02 draft-ietf-netext-pmip-cp-up-separation-05 Alexey Melnikov 2014-07-04 draft-ietf-p2psip-service-discovery-13 Hilarie Orman 2014-07-07 draft-ietf-xrblock-rtcp-xr-psi-decodability-04 Eric Osterweil 2014-07-15 draft-ietf-l2vpn-etree-frwk-06 Radia Perlman 2014-06-30 draft-ietf-ppsp-survey-08 Vincent Roca 2014-07-14 draft-ietf-trill-active-active-connection-prob-05 Joe Salowey 2014-07-21 draft-ietf-trill-loss-delay-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Zach Shelby 2014-07-21 draft-ietf-trill-oam-fm-06 Melinda Shore E None draft-ietf-websec-key-pinning-17 Ondrej Sury 2014-07-15 draft-kivinen-ipsecme-signature-auth-06 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Jul 3 05:03:58 2014 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 C31F91B28ED; Thu, 3 Jul 2014 05:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zarorWxEgF9H; Thu, 3 Jul 2014 05:03:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A301A0A74; Thu, 3 Jul 2014 05:03:48 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 0D13AC0BA3; Thu, 3 Jul 2014 14:03:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id E0B3FC807B; Thu, 3 Jul 2014 14:03:46 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Thu, 3 Jul 2014 14:03:47 +0200 From: To: Charlie Kaufman , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-6man-multicast-addr-arch-update-05 Thread-Index: Ac+SiKW4XRhXv3zlTOeprxoPra3d/wEKgMQw Date: Thu, 3 Jul 2014 12:03:46 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002BAA3@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <5e3dd927cd2c401bb107b3c3c7f617da@BL2PR03MB498.namprd03.prod.outlook.com> In-Reply-To: <5e3dd927cd2c401bb107b3c3c7f617da@BL2PR03MB498.namprd03.prod.outlook.com> 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.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.3.74221 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/R8-mrWgNIFfXX_sO_NcbWA_WiDo Cc: "draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-6man-multicast-addr-arch-update-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: Thu, 03 Jul 2014 12:03:51 -0000 Dear Charlie, Thank you for the review.=20 Please see inline.=20 Cheers, Med >-----Message d'origine----- >De=A0: Charlie Kaufman [mailto:charliek@microsoft.com] >Envoy=E9=A0: samedi 28 juin 2014 07:11 >=C0=A0: secdir@ietf.org >Cc=A0: draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org; >iesg@ietf.org >Objet=A0: Secdir review of draft-ietf-6man-multicast-addr-arch-update-05 > >I have reviewed this document as part of the security directorate's ongoin= g >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 jus= t >like any other last call comments. > >This document tightens the wording around the usage of flag bits specified >in RFCs 3306 and 3956. I don't believe it would require changes to any >existing implementations, and it would be a real stretch to claim it has >any security implications at all. The document's security considerations >section references the security considerations sections of other documents= . >This seems appropriate. [Med] Great, thanks. > >This document addresses an issue that I personally am very passionate >about, and I believe this document takes what is already a bad situation i= n >those earlier RFCs and makes it worse. (It is possible there is some >subtlety in the issues surrounding IP Multicast Addresses that makes my >arguments invalid, but please hear me out and think about it.) > >There are too many documents that have fields labelled "flags" or >"undefined" or "reserved for future use" and they expect implementers to d= o >the right thing with them. Documents should always specify what a sender >should send and what recipients should do with received values. A good >default policy for implementers to follow is to always send packets with >such fields set to zero and always ignore values seen in these fields. But >if that is the desired policy, the spec should say so, and there are times >when a different policy makes more sense. For example, it might also be >useful to have a reserved for future use field where a sender always sends >zero and a recipient treats any message containing a non-zero value as >invalid. That would allow a new implementation to send a message that >another new implementation would process correctly and an old >implementation would reject as invalid rather than processing incorrectly. > >The reason for specifying behavior carefully is that future revisions to >the protocol may want to encode information in these fields, but to do so >safely it must be possible to predict what existing implementations will d= o >when interacting with the new ones. That is only possible if we know what >existing systems are going to send and what existing systems will do when >they receive newly defined values. [Med] FWIW, this is in part one of motivations for this draft (see the exam= ples provided in Section 3 of the draft). This document reiterates that fla= g bits are to be treated as separate bits. Remaining flag bits that are not= associated yet with a meaning can be set to 0 or 1. After checking the tex= t, I found this is clearly mentioned for X but not for r bits. I made a cha= nge for r bits (see below) =20 > >RFCs 3306 and 3956 break these rules by saying things like "The behavior i= s >unspecified if P or T is not set to 1". Behavior should never be >unspecified. Either the values of P and T should be ignored, or the addres= s >should be treated as invalid if P or T is not set to 1, or some other >behavior should be specified. The sender should have a specified behavior >of always setting them to 1. [Med] I agree with your point. I suggest to remove that sentence from the U= PDARED text because valid P&T values when R is set are clearly indicated.=20 > >This I-D, while trying to correct some ambiguities, actually makes it >worse. It says things like "X may be set to 0 or 1" (where X is a flag >bit). It would be fine to say X MUST be ignored on receipt. [Med] Ignoring an undefined flag or expecting an undefined flag to be set t= o 0 or 1 have the same consequences, no? Explicitly saying an undefined fla= g can be set to 0 or 1 is IMHO superior in case an implementation does not = treat flags as separate bits acts on prefix ranges.=20 But it should >specify that it MUST be sent as zero.=20 [Med] This does not apply for this specification because this will lead to = exclude a range of valid addresses for a given flag; see the example in Sec= tion 3. Otherwise, implementations of the >spec are free to set it to zero or one and no future modification to the >protocol can ascribe any meaning to the value set because when >interoperating with an old implementation the received value is >unpredictable and meaningless. > >It divides a 4 bit "reserved" field into four 1 bit "flag" fields, but >still does not specify what values those flags should be set to (presumabl= y >zero) nor what an implementation should do if they are non-zero on receipt >(perhaps ignore them, or perhaps reject the address... I can't guess the >intent. [Med] Good point. I made this change: OLD: where "rrrr" are for future assignment as additional flag bits. NEW: where "rrrr" are for future assignment as additional flag bits. r bits may each be set to 0 or 1. > >It might be too late to do an optimal job of specifying the desired >behaviors with respect to these flags because that might "break" existing >implementations. But we certainly shouldn't make it worse by permitting >useless flexibility unless it was already promised in the earlier >documents. > > --Charlie Kaufman From nobody Thu Jul 3 09:42:33 2014 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 23E721B2A67; Thu, 3 Jul 2014 09:42:32 -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 1GGsnJERFuZi; Thu, 3 Jul 2014 09:42:31 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F291B2A22; Thu, 3 Jul 2014 09:42:31 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so507344pab.1 for ; Thu, 03 Jul 2014 09:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:from:to:cc:subject:importance:date :in-reply-to:references:content-type; bh=SggN4OZeNzTg4pHKbvF+fX1kZtQ86xzt7EDJJmS28Mw=; b=eJv6C+EpQ+tVKKbq6GrlGupr2f2kt/AQqy8rxt0/xfrhnblb8AFmamSA3IDbdZkDf0 E6XyCDqagr5YgEdljxSa9JNAp3K2+2A4qsobdtlE9f4JRg+iAtGpe5aEf6T/6mTOplms L+tPNgqJQmp8SC65AMxVpTyV/Nqi6Hnf3KQ0vd2nj8gsm1etjc14kGEc7aDTnWW/yYfI ujGxVoxGeCmC6cs/kY9HuGm0WYUbyGTRsRx+TSbogsJZG0Bv1hkdQZlBmCTqR47eCYHE tRBt/uG2qtbajNnLBhWn+xNIVQBMFg+KPkp4FyVAiVSSr8DL1J7R/QpnCnLCSt572iKm PJ+Q== X-Received: by 10.68.241.68 with SMTP id wg4mr5941619pbc.66.1404405750636; Thu, 03 Jul 2014 09:42:30 -0700 (PDT) Received: from MAGNUSDevbox2.ntdev.corp.microsoft.com ([2001:4898:80e0:ee43::4]) by mx.google.com with ESMTPSA id no9sm41524542pbc.83.2014.07.03.09.42.28 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Jul 2014 09:42:29 -0700 (PDT) Message-ID: <53b587f5.09d5440a.44eb.2126@mx.google.com> MIME-Version: 1.0 From: To: "=?utf-8?Q?secdir@ietf.org?=" , "=?utf-8?Q?draft-ietf-xmpp-websocket@tools.ietf.org?=" Importance: Normal Date: Thu, 3 Jul 2014 16:39:08 +0000 In-Reply-To: References: Content-Type: multipart/alternative; boundary="_8DA0322D-C687-4EC2-9294-6A96D48C1B59_" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Qp8Tj0EMjEDDjs9G9aNs-HE9i-Q Cc: "=?utf-8?Q?iesg@ietf.org?=" Subject: [secdir] =?utf-8?q?Secdir_review_of_draft-ietf-xmpp-websocket-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: Thu, 03 Jul 2014 16:42:32 -0000 --_8DA0322D-C687-4EC2-9294-6A96D48C1B59_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" DQoNCg0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1 cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1 bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdy aXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJl Y3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2Ug Y29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCiANCg0K VGhpcyBkb2N1bWVudCBkZWZpbmVzIHdlYiBzb2NrZXRzIGFzIGEgdHJhbnNwb3J0IHByb3RvY29s IGZvciBYTVBQLiAgVGhlIFNlYyBDb25zIHNlY3Rpb25zIGxvb2tzIGFkZXF1YXRlIHRvIG1lLiBP bmUgZWRpdG9yaWFsIHF1ZXN0aW9uIG9uIFNlY3Rpb24gMy45Og0KDQpTaG91bGQNCg0K4oCcd2hl biBUTFMgaXMgdXNlZCwgaXQgTVVTVCBiZSBlbmFibGVkIHRoZSBXZWJTb2NrZXQgbGF5ZXIg4oCd IGhhdmUgcmVhZCDigJx3aGVuIFRMUyBpcyB1c2VkLCBpdCBNVVNUIGJlIGVuYWJsZWQgYXQgdGhl IFdlYlNvY2tldCBsYXllciDigJ0NCg0KPw0KDQoNCg0KDQoNCg0KDQpUaGFua3MsDQoNCi0tIE1h Z251cw== --_8DA0322D-C687-4EC2-9294-6A96D48C1B59_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwNDk4Ij4KPHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+PCEt LQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0b206 MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7Cm1hcmdpbjowaW47Cm1hcmdpbi1ib3R0 b206LjAwMDFwdDsKfQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJh Z3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCAKcC5Nc29MaXN0 UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGRpdi5N c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBs aS5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3Qg ewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1h cmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsK fQotLT48L3N0eWxlPjwvaGVhZD4KPGJvZHkgZGlyPSJsdHIiPgo8ZGl2IGRhdGEtZXh0ZXJuYWxz dHlsZT0iZmFsc2UiIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDYWxpYnJpJywgJ1Nl Z29lIFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5n SGVpIFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZic7Zm9udC1zaXplOjEycHQ7Ij48 ZGl2Pjxicj48L2Rpdj48ZGl2IGRhdGEtc2lnbmF0dXJlYmxvY2s9InRydWUiPjxkaXY+SSBoYXZl IHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3Jh dGUncyAKb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBw cm9jZXNzZWQgYnkgdGhlIDxzcGFuPklFU0c8L3NwYW4+LgogVGhlc2UgY29tbWVudHMgd2VyZSB3 cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IAphcmVhIGRp cmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVz ZSAKY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPC9kaXY+ PC9kaXY+PGRpdiBkaXI9Imx0ciI+Jm5ic3A7PC9kaXY+PGRpdiBkaXI9Imx0ciI+VGhpcyBkb2N1 bWVudCBkZWZpbmVzJm5ic3A7d2ViIHNvY2tldHMgYXMgYSB0cmFuc3BvcnQgcHJvdG9jb2wgZm9y IFhNUFAuJm5ic3A7Jm5ic3A7VGhlIFNlYyBDb25zIHNlY3Rpb25zIGxvb2tzIGFkZXF1YXRlIHRv IG1lLiBPbmUgZWRpdG9yaWFsIHF1ZXN0aW9uIG9uIFNlY3Rpb24gMy45OjwvZGl2PjxkaXYgZGly PSJsdHIiPlNob3VsZDwvZGl2PjxkaXYgZGlyPSJsdHIiPuKAnHdoZW4gVExTIGlzIHVzZWQsIGl0 IE1VU1QgYmUgZW5hYmxlZCB0aGUgV2ViU29ja2V0IGxheWVyIOKAnSBoYXZlIHJlYWQmbmJzcDvi gJx3aGVuIFRMUyBpcyB1c2VkLCBpdCBNVVNUIGJlIGVuYWJsZWQgYXQgdGhlIFdlYlNvY2tldCBs YXllciDigJ08L2Rpdj48ZGl2IGRpcj0ibHRyIj4/PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRlci1sZWZ0 LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsiIGRpcj0ibHRyIj48ZGl2IGRp cj0ibHRyIj4KPC9kaXY+PC9ibG9ja3F1b3RlPjxkaXYgZGlyPSJsdHIiPjxicj48L2Rpdj48ZGl2 IGRpcj0ibHRyIj5UaGFua3MsPC9kaXY+PGRpdiBkaXI9Imx0ciI+LS0gTWFnbnVzCjwvZGl2Pjxk aXY+CjwvZGl2PjwvZGl2Pgo8L2JvZHk+CjwvaHRtbD4K --_8DA0322D-C687-4EC2-9294-6A96D48C1B59_-- From nobody Thu Jul 3 14:43:52 2014 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 9CE481B2A40; Thu, 3 Jul 2014 14:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 U9WCpImgXiG5; Thu, 3 Jul 2014 14:43:46 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBDE1B2A3B; Thu, 3 Jul 2014 14:43:45 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s63LhgVd012867; Thu, 3 Jul 2014 22:43:42 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s63LheIO012816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jul 2014 22:43:40 +0100 From: "Adrian Farrel" To: "'Ben Laurie'" , "'The IESG'" , , References: In-Reply-To: Date: Thu, 3 Jul 2014 22:43:34 +0100 Message-ID: <0cf001cf9707$d88083e0$89818ba0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGtyNQpOj8eDn9j3srLWrUG7dsJjpvSfRmg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20796.002 X-TM-AS-Result: No--5.255-10.0-31-10 X-imss-scan-details: No--5.255-10.0-31-10 X-TMASE-MatchedRID: +c13yJDs902nykMun0J1wpmug812qIbzC/ExpXrHizw4YKAM3oRt9mn7 AlTb8W2xmbgtFJbseiaV2J8ChOmkc6XgCCul34T6TQh9A4m9EtFCdUZFvvy+kFpbYq2f4jz+UA/ QkP482j8IS5UXqe5IMYAy6p60ZV62mCXhewl0apKDGx/OQ1GV8mrz/G/ZSbVq+gtHj7OwNO2+Ij sEEOIzYupnAjXr3+OFNfID9bjStg1BIYSy4CaxJd0+kgVCxoLn Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rCr0JQ6NQo9WU5HD3jlsu2XX1Ws Subject: Re: [secdir] Security review of draft-ietf-pce-questions-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 21:43:47 -0000 Hi Ben, Thanks for reading and letting us know your thoughts. > 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. Could I please ask you to re-send your mail to the IETF list "just like = any other last call comments" so that we can respond to them there as = part of the consensus process. That is, of course, unless you feel that = your comments fall into the escape clause in the last call announcement = : "Exceptionally, comments may be sent to iesg@ietf.org instead." Cheers, Adrian From nobody Fri Jul 4 05:08:38 2014 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 436581B2D68 for ; Fri, 4 Jul 2014 05:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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, RP_MATCHES_RCVD=-0.651, 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 FrAfdWve4If2 for ; Fri, 4 Jul 2014 05:08:29 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5881B2D63 for ; Fri, 4 Jul 2014 05:08:29 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so1399299qcv.38 for ; Fri, 04 Jul 2014 05:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XlhqoxhQ8iE2ZdPkZ7N+qOYzF7x3L2L8eIH+Uymvk5c=; b=lnVzES93JAirl4QsmGFzM6WCYP/lpfI+lvHbrq/FD1G6d+XEodo7bagrzUf48e4pLs tXXK4aT5PI3E0izE9RsAHJaPwEESEq42zQrEgeSjBHFcEtjBYsdgZifLaK+jIn7zFRQD BOkgN/5TUV/HKjyKqLfW8TfMpyBFJW4zRXNXYHkEh/jcil2WF/eOKE7rkxZXNt3x4zTz n4aKJmU2BhSx6nxcy6hwW4f168TH0BeDIOzqxfQf3R4GK4xW+g+RoY7Hm+TBbDXOspzh TPDY9SxKZkkTasQPAaeOZvFL+so8r9yEEzYvc5W5uZn4R3qcr3ztk+nGUG42Dsh3p48d mjCg== 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=XlhqoxhQ8iE2ZdPkZ7N+qOYzF7x3L2L8eIH+Uymvk5c=; b=F1z/yYnmAb74cTxL2sIw+zbv5JuCBRsZIrWuVW53tfVTyx0Vg87U5ADpBZpRMRi89z goAzcGT+k9cfsxiKmMuj4NuGk62a1/19Exh+6CVLnAcctgtAEVryoekXFVA/ab9WUKUV tmrPnH5leWdYUKmnwwywibf5gA1sqTCg/2ycpIRZ/v+w/66YX4DnGvlXxYOxGxL2rx06 auXmdu2CNRDePaxx3IBsUxc2BNFAJuugjfD4cM3EjBkLPIgYxaSEodFDYKD1WfCi0Y6W jT9v929M6+xogDf2GJr+V3hXuPUTdF2jLU+0IBmwb5bsaEejKaHEavIa4eiiWfyARG+2 xAkw== X-Gm-Message-State: ALoCoQnLdOObMWJU/kQcXiB18TPHt7oYqOAFjqSdNm+VnlieP5oPgSLY2ueavKixEfh/rnZGxyfz MIME-Version: 1.0 X-Received: by 10.224.80.201 with SMTP id u9mr17826684qak.82.1404475708981; Fri, 04 Jul 2014 05:08:28 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Fri, 4 Jul 2014 05:08:28 -0700 (PDT) In-Reply-To: <0cf001cf9707$d88083e0$89818ba0$@olddog.co.uk> References: <0cf001cf9707$d88083e0$89818ba0$@olddog.co.uk> Date: Fri, 4 Jul 2014 13:08:28 +0100 Message-ID: From: Ben Laurie To: adrian@olddog.co.uk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/bKxVqE2SkR5F-GwcnWG7VjWeAco Cc: draft-ietf-pce-questions.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Security review of draft-ietf-pce-questions-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: Fri, 04 Jul 2014 12:08:31 -0000 On 3 July 2014 22:43, Adrian Farrel wrote: > Hi Ben, > > Thanks for reading and letting us know your thoughts. > >> 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. > > Could I please ask you to re-send your mail to the IETF list "just like a= ny other last call comments" so that we can respond to them there as part o= f the consensus process. That is, of course, unless you feel that your comm= ents fall into the escape clause in the last call announcement : "Exception= ally, comments may be sent to iesg@ietf.org instead." I am following the Security Directorate process here: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview. But sure, I'll send a copy to the IETF list. From nobody Fri Jul 4 05:09:56 2014 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 0B2D31B2D63 for ; Fri, 4 Jul 2014 05:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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, RP_MATCHES_RCVD=-0.651, 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 6ETaGxQYLHYB for ; Fri, 4 Jul 2014 05:09:53 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA84E1B286A for ; Fri, 4 Jul 2014 05:09:52 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so1433640qcz.14 for ; Fri, 04 Jul 2014 05:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EWw2HatA+uziywEzZ8BKfgOUbZmdvZd0fNMYr8dzTfg=; b=NTHZWCNcDzgJHquxitGibAPPM96uiT2kI4If5uy+yk7whW0Zf1OOSH5wFSoF4u57g0 Se/cwNzOYExe9B7vhPh9FNlg+pQkDaiwtlA1EMkFFlCzjY0rtTo0AVeuzGb87SE1toWV qziH7rTI9JQOc+Mn5ik9SlVSheSReSB9zKADZyjKZFHgF5+zz5WaxwcpjGS8oZ4wEbEf syjtPddRzlhB+N0R0ZeS9LhJYHfI6pf5Aek88N5kKQ60KMCAI4cHyj3XVOm73ZTnqImP 6Ig190KcJxyypHH1p0cq/UwSVROtaBQkESGQVYTvSOkfKHIZn7yi8kaIVtOdMyvCcKsD dM/A== 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=EWw2HatA+uziywEzZ8BKfgOUbZmdvZd0fNMYr8dzTfg=; b=gVmtL+YTwXJikQkGGNSc0pGKeDJKG3PZ3cNeNdaS7sthfJjl+8S3iAVTD1JuUb0Shx ptd/wT9f9uORlpVwSJhzKKctwiRrQZfRI2jCs746D/h1gGJbp24IKkIegB5m0cQ25HZT Ukd01pbc4Zc2/W5Xrexu+tS1n7gK1p8kDxdNlC7U2bcxTPy7/C0UkyzgD6wMyS8ovRsn 8EvvSOMq+ClSIPGtRz8D2h9IuTMXDVlIpC5AHTiXmBgP8RPsHnIqLXUKvgGLwNOSYkvF 0KY+hAJjMxFuF3ACXH4wvEunGFCxCZO2s/0ol6Nt8ZtWk6tyg75dHiXvAgmf6i3AchsX y5GA== X-Gm-Message-State: ALoCoQkhnpEFMuCENpuxmuktF6uHZ/QWP1Xjwub+gGKHrkVtsWwj2beQQz619aycj/hG0/8KL8J2 MIME-Version: 1.0 X-Received: by 10.229.127.9 with SMTP id e9mr17484700qcs.5.1404475792168; Fri, 04 Jul 2014 05:09:52 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Fri, 4 Jul 2014 05:09:52 -0700 (PDT) Date: Fri, 4 Jul 2014 13:09:52 +0100 Message-ID: From: Ben Laurie To: IETF Discussion List , "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/IQuixD5p6JosC4KkI1eflrjDMzg Subject: [secdir] Security review of draft-ietf-pce-questions-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: Fri, 04 Jul 2014 12:09:54 -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. Status: ready with issues. The security considerations section makes this claim: "This informational document does not define any new protocol elements or mechanism. As such, it does not introduce any new security issues." I agree with the premise, but not the conclusion: just because an RFC does not introduce new security issues, that does not mean that there are no security considerations. Indeed, this RFC discusses many things that have quite serious security considerations, without mentioning any of them. For example, section 4 "How Do I Find My PCE?" (the very first question) advocates a number of potentially completely insecure mechanisms with no mention of their security properties (or otherwise). This is obviously pervasive, given the stance taken in the security considerations. The document does mention that RFC 6952 gives a security analysis for PCEP, and perhaps this is sufficient but it seems to me that a document intended to give useful background information to noobs should include security directly in that information rather than defer to another giant document (which mixes PCEP info with other protocols). From nobody Fri Jul 4 07:01:55 2014 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 D92761B297B for ; Thu, 3 Jul 2014 19:30:49 -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, 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 hcAm3buXJDFG for ; Thu, 3 Jul 2014 19:30:48 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0643C1B298B for ; Thu, 3 Jul 2014 19:30:46 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id fp1so1159697pdb.25 for ; Thu, 03 Jul 2014 19:30:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5jp7ssa4ZDuyUnV5HqgJtNJeBetX4mrY5ee+CL3iIVw=; b=VXVqIIvkOD6nlY2XfXcRc0WYwdcgpZD/OStJgPGdCk6WoZbd2mYHqHlwDxRksA4Hbb +Lwk3vtxYKmQY4kJ/Zy9f2xnsWQA5Pd46dtP7CC4PMbNap9EIZU+2nuckbikNKomJZV1 WJjm46nxumspy9JVFr2nrZ7wdM7J/FWv4B2PuSAaIXHSExsTh6a8MzH3WDOrsU7HjQaN K3YyRojhdg42sUNer8VUM0rgqTkHk6oPROBxdIbQAO3hrlO2t2GfExMudaLQHYjw4bkI FJhVruhExf0YMe+FPMseYQ29elLCtozPtMJ78ykAaiik+aOyXGbYEqTZca/QTKYg/bG6 PSJA== X-Gm-Message-State: ALoCoQmC9Sk5TslCYdnUHoL2zKepR8vbH7YOyPOyeN5uILPwetxkwOtE/M99ClRiWHcHhEpbkmam X-Received: by 10.70.15.225 with SMTP id a1mr7552927pdd.13.1404441046639; Thu, 03 Jul 2014 19:30:46 -0700 (PDT) Received: from [10.0.1.172] (68-186-83-170.dhcp.knwc.wa.charter.com. [68.186.83.170]) by mx.google.com with ESMTPSA id h15sm6709498pdl.5.2014.07.03.19.30.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 19:30:45 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1F4FC48B-2C42-4B9B-A09F-838E4C7BB53A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Lance Stout In-Reply-To: <53b587f5.09d5440a.44eb.2126@mx.google.com> Date: Thu, 3 Jul 2014 19:30:43 -0700 Message-Id: <46B2A4E0-236E-4B1C-8060-C8641E0CA012@andyet.net> References: <53b587f5.09d5440a.44eb.2126@mx.google.com> To: "iesg@ietf.org" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/WzVzvcZb7m286xYFg_f9-K81xvs X-Mailman-Approved-At: Fri, 04 Jul 2014 07:01:54 -0700 Cc: ops-dir@ietf.org, "secdir@ietf.org" , ops-ads@tools.ietf.org, "gen-art@ietf.org" , "Romascanu, Dan \(Dan\)" , draft-ietf-xmpp-websocket.all@tools.ietf.org, "draft-ietf-xmpp-websocket@tools.ietf.org" Subject: Re: [secdir] Reviews of draft-ietf-xmpp-websocket-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: Fri, 04 Jul 2014 02:30:50 -0000 --Apple-Mail=_1F4FC48B-2C42-4B9B-A09F-838E4C7BB53A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Closing in on the end of LC for draft-ietf-xmpp-websocket-07, so = replying to the feedback generated so far. We'll publish a -08 draft addressing these = issues, which have all been minor or editorial points. On Jul 3, 2014, at 9:39 AM, = wrote: > Should =93when TLS is used, it MUST be enabled the WebSocket layer =94 = have read > =93when TLS is used, it MUST be enabled at the WebSocket layer =94 ? Yes, that is the intended wording. On Jul 2, 2014, at 6:00 AM, Romascanu, Dan (Dan) = wrote: > 1. In order to accommodate the Websocket binding this document = describes several > deviations from RFC6120. For example, in Section 3.3 it says: The = WebSocket > XMPP sub-protocol deviates from the standard method of constructing = and using > XML streams as defined in [RFC6120] by adopting the message framing = provided by > WebSocket to delineate the stream open and close headers, stanzas, and = other > top-level stream elements. I am wondering whether it would not be = appropriate to > reflect this in the document header by adding Updates RFC6120 This is a separate binding from the TCP binding defined in RFC6120, so I = don't think saying Updates RFC6120 would be accurate. Nothing in RFC6120 is = modified by this document. > 2. In Section 3.6.1: >=20 > If the server wishes at any point to instruct the client to move to = a > different WebSocket endpoint (e.g. for load balancing purposes), = the server > MAY send a element and set the "see-other-uri" attribute = to the > URI of the new connection endpoint (which MAY be for a different = transport > method, such as BOSH (see [XEP-0124] and [XEP-0206]). >=20 > I do not understand the usage of MAY in this paragraph. Is = there another > method to move to a different Web socket endpoint that is described = here or some > other place? In not, why is not the first MAY at least a SHOULD? The = second > usage seems to describe a state of facts, so it needs not be = capitalized at all. That is the only method, so I agree that can be a SHOULD, and also agree = on the second point. > In Section 3.1 I believe that the example should be preceded by some = text > that indicates that this is an example, such as: =91An example of a = successful > handshake and start of session follows:=92 +1, will add that. On Jun 25, 2014, at 11:55 PM, Juergen Schoenwaelder wrote: > - Sec 1: The term 'raw socket' can be potentially mis-understood, = perhaps simply > remove 'over row sockets' completely (I think the message of the = sentence > remains intact without these words). +1 will change > - Sec 3.1: The text says that both client and server MUST have |xmpp| = in the > list of protocols for the |Sec-WebSocket-Protocol| header. The text = does not > detail what happens if this is not the case. Is there be a defined = behavior if > this protocol negotiation fails? Good catch, RFC6455 doesn't describe what to do in that case, so we'll = need to address it. If the server does not reply with 'xmpp' in the Sec-WebSocket-Protocol = handshake reply, then the client MUST close the connection. > - Sec 3.6.1: There is a closing parenthesis missing at the end of the = first > paragraph. Noted, will fix. - Lance --Apple-Mail=_1F4FC48B-2C42-4B9B-A09F-838E4C7BB53A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM5jCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGqjCCBZKg AwIBAgICL6UwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MzAzMTQwNTM1MTJaFw0xNTAzMTUyMjMyMzZaMIGMMRkwFwYDVQQNExBQTDAxbVhKMjhha3BBRzVj MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3RvbjESMBAGA1UEBxMJS2VubmV3aWNrMRQw EgYDVQQDEwtMYW5jZSBTdG91dDEjMCEGCSqGSIb3DQEJARYUbGFuY2VzdG91dEBnbWFpbC5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr0XNL4SLaoBR9y72zNo3eAefV7vk1UaEx xML9TqPKZHV9gGxA/XO5YilACUU/l5In+8akri5djy/haORYEm5HwsR/R1vxhOK7cBEyXMCY41Vg KyqnQPJlidJ0L5PMinz1cwo0wyLlh8WhxIBHBjgLbA8XAoDC7FL6KzDq+qoJdsBbehu4W9fVscRr T7XeM41zHjc7FqJOD8I2n9Z5CIlEeWwaIEZO0HpxOlcbD5EGVaC7Wbji/nEOuQ1OI6iGId/7Xakg JrGfjSg1wQ5dXIBMzbSZmw3B6WmDdNgpCzHYL+QrCLrFenO0u2D6ZR/dZQgIkPRhL6I7PqniJ3FN 0hJpAgMBAAGjggMSMIIDDjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFggdjTZDgsglI1DBpZiCB24Ub+ZMB8GA1UdIwQYMBaA FK5Vg2/sMcq59x36r2sx88gd46y7MFcGA1UdEQRQME6BFGxhbmNlc3RvdXRAZ21haWwuY29tgRRs YW5jZXN0b3V0QGdtYWlsLmNvbYEObGFuY2VAbGFuY2UuaW2BEGxhbmNlQGFuZHlldC5uZXQwggFM BgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBh Y2NvcmRpbmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0 YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2Ug aW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIu Y2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20v MA0GCSqGSIb3DQEBBQUAA4IBAQALnAVqIrddlyGYqOAb4TfJ25u3sOtC352yAF7VaQdhkV/Z7Rum OPpsEN7rwLfHOphYhafI4IxKy39NZbFBjzzcW8Kx6OJ1L/eDEW5Dbt1XzaBF4VVM1/DZyg/l3C0N 9/YrumhcgdSUgxLL2d/GzEk1dNTcZLpLJABf6L1W5RszU4HSPyVppLzYVVq5yLwmKnlIcnDjEdMr jmsFq8b0Duk1j05IE2KBiWNy/Q0H9Hj/943/rvQOx7464jzuEGkWYO8AU7Nmq3h2DLoo8GECFwxy e7rSL0o3KFkAQHC0YE/8GbaT05Jo7xnF/9X/IOWd0rSvBmTVkreGARQywViv35eCMYIDbDCCA2gC AQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFz cyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwCQYFKw4DAhoFAKCCAa0wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNzA0MDIzMDQzWjAjBgkq hkiG9w0BCQQxFgQUkbx6X4tfYC99lLwhqpYUkY0sFEAwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAjQ/OkfnnRD2+JIBt 3XaU9fOUds0kL5YiFB2U5d3aPrLOmNy0CaA55xabQ0NkK3yUAj1praxKUF4xBNelCcQxFhFT+xBJ Pdn+Mm6ViVCGP9sAd8pFOyuKOrASXPIKsp2FJkBiJrZBDAZrgcliOAHypIHapIx9VZlyp0/Y+4Gu O6iWmOXJ9OR3XdrEHRfgPd8BK+wVmjczicX4u68vcv1drrtIEKMvZlkkD+MVIGkAR8huHKb9TITu Spvd8BfvT8Q81X2guo34bdQKN0YNMBxt0l46FwRF/lOEZsGH+PZlUt5O+8x6VGDb25eltcqOIoJU kasLZEMTPLU+jTDQIfbIWgAAAAAAAA== --Apple-Mail=_1F4FC48B-2C42-4B9B-A09F-838E4C7BB53A-- From nobody Fri Jul 4 07:30:21 2014 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 1E9CA1B2CEF; Fri, 4 Jul 2014 07:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 7_zgXoFJc617; Fri, 4 Jul 2014 07:30:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F108C1B2D4A; Fri, 4 Jul 2014 07:30:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 94453BE04; Fri, 4 Jul 2014 15:30:13 +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 pKx3nQ6-J76W; Fri, 4 Jul 2014 15:30:13 +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 4DF4EBDFE; Fri, 4 Jul 2014 15:30:13 +0100 (IST) Message-ID: <53B6BA75.3070407@cs.tcd.ie> Date: Fri, 04 Jul 2014 15:30:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Laurie , adrian@olddog.co.uk References: <0cf001cf9707$d88083e0$89818ba0$@olddog.co.uk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_-iljC3Yx9TN-87e-_GIlv1ZQ4o Cc: draft-ietf-pce-questions.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: [secdir] where to send reviews (was: Re: Security review of draft-ietf-pce-questions-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: Fri, 04 Jul 2014 14:30:20 -0000 Hi Adrian, all, Thanks for those reviews, they really help so keep 'em coming! Adrian asked Ben to re-tx his review to the IETF list, and Ben replied: On 04/07/14 13:08, Ben Laurie wrote: > I am following the Security Directorate process here: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview. > > But sure, I'll send a copy to the IETF list. We debate this from time to time and so far always land where we started, which is the above guidance:-) A substantial number of reviews are nits only and folks don't feel that sending to the main IETF list is worth it for those. And sometimes some reviewers are probably worried that sending to the main IETF list might lead to a thread that consumes more time than the reviewer has available. Anyway, for anyone who's new to this and not sure, or has forgotten, the above URL is worth a look, and just use your judgement as to whether or not you send your review to the main IETF list. Equally, its just fine if someone asks that the review be re-tx'd as Adrian did, so I hope folks just do that in those cases, as Ben did:-) Cheers, S. From nobody Fri Jul 4 08:12:37 2014 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 799951B2AE3; Fri, 4 Jul 2014 08:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 xz0Sy-uXpiB4; Fri, 4 Jul 2014 08:12:30 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE181B2AD3; Fri, 4 Jul 2014 08:12:30 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s64FCQ8q008127; Fri, 4 Jul 2014 16:12:26 +0100 Received: from 950129200 (82-71-74-86.dsl.in-addr.zen.co.uk [82.71.74.86]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s64FCNBf008095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Jul 2014 16:12:24 +0100 From: "Adrian Farrel" To: "'Ben Laurie'" References: <0cf001cf9707$d88083e0$89818ba0$@olddog.co.uk> In-Reply-To: Date: Fri, 4 Jul 2014 16:12:18 +0100 Message-ID: <0e6601cf979a$59c42be0$0d4c83a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGtyNQpOj8eDn9j3srLWrUG7dsJjgH1UdaCAlIVYjKbsWeDEA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20796.007 X-TM-AS-Result: No--13.630-10.0-31-10 X-imss-scan-details: No--13.630-10.0-31-10 X-TMASE-MatchedRID: HXSqh3WYKfunykMun0J1whiTH2TyLmz+1kqyrcMalqXFJnEpmt9OE4r7 HXyN6mJM/z6hPQmCTlv2UlIkcWMFbA5xGkgZNT4Q8eSmTJSmEv1R3sGN+j7mNBHHVlBjhe3y2Uw BLM8az1QFtJDHvWPuiDeT288mssTU1G8rrdJV3qAF8rFt9xmDKToSfZud5+GgNOnYXKcDRxCNZk luV6XYGe9ECUe5voFdSHCGonA+tRbxlOJuQNHlfe9VsdrlGzy3Pj366R4tj3WbKItl61J/ybLn+ 0Vm71Lcq7rFUcuGp/EgBwKKRHe+r/6zrNjMVVuOkWieinlg6/+7CwCL6zmFtnKaVGMyPwNCej/q PJhYD4g= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hn6Fm4cHjKcVWo52sj7ey_Qzk9U Cc: draft-ietf-pce-questions.all@tools.ietf.org, 'The IESG' , secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-pce-questions-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:12:32 -0000 Thanks Ben, Much appreciated. I think your comments as Last Call comments deserve = public discussion as they might need substantial changes to the = document, so the issue is one of establishing consensus. A > -----Original Message----- > From: Ben Laurie [mailto:benl@google.com] > Sent: 04 July 2014 13:08 > To: adrian@olddog.co.uk > Cc: The IESG; secdir@ietf.org; = draft-ietf-pce-questions.all@tools.ietf.org > Subject: Re: Security review of draft-ietf-pce-questions-06 >=20 > On 3 July 2014 22:43, Adrian Farrel wrote: > > Hi Ben, > > > > Thanks for reading and letting us know your thoughts. > > > >> 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. > > > > Could I please ask you to re-send your mail to the IETF list "just = like any other > last call comments" so that we can respond to them there as part of = the > consensus process. That is, of course, unless you feel that your = comments fall > into the escape clause in the last call announcement : "Exceptionally, = comments > may be sent to iesg@ietf.org instead." >=20 > I am following the Security Directorate process here: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview. >=20 > But sure, I'll send a copy to the IETF list. From nobody Sun Jul 6 21:49:52 2014 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 A2EBE1A0AEB; Sun, 6 Jul 2014 21:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_12LTRDOM=0.099, 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 YmOmlV9s-Tzy; Sun, 6 Jul 2014 21:49:49 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DDE1A01AD; Sun, 6 Jul 2014 21:49:49 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1X40s7-0000e7-LN; Sun, 06 Jul 2014 22:49:47 -0600 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1X40s4-0004v7-Ud; Sun, 06 Jul 2014 22:49:47 -0600 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id s674nd2O020241; Sun, 6 Jul 2014 22:49:39 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id s674ndEX020239; Sun, 6 Jul 2014 22:49:39 -0600 Date: Sun, 6 Jul 2014 22:49:39 -0600 Message-Id: <201407070449.s674ndEX020239@sylvester.rhmr.com> From: "Hilarie Orman" To: secdir@ietf.org X-XM-AID: U2FsdGVkX1+HBhROjPKz+ojK/C/bBaHD X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 13:58:17 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Z7hw5BoA8q-bZucTabdxPoT1YyA Cc: draft-ietf-xrblock-rtcp-xr-psi-decodability@tools.ietf.org, iesg@ietf.org Subject: [secdir] Security review of draft-ietf-xrblock-rtcp-xr-psi-decodability-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 04:49:50 -0000 Security review of draft-ietf-xrblock-rtcp-xr-psi-decodability-04 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics reporting Do not be alarmed. 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 purpose of the document is to define a new block type for reporting of data about MPEG2 transport consistency tests. The security considerations are the same as those described in RFC 3611 "RTP Control Protocol Extended Reports (RTCP XR)". Those considerations fall under the technical rubric of "funky", but the draft under discussion does not add any new wrinkles. Hilarie Orman From nobody Mon Jul 7 01:18:54 2014 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 7814D1B27A8; Mon, 7 Jul 2014 01:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, 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 FUaP_gdFEVfD; Mon, 7 Jul 2014 01:18:50 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 2E84D1B27A7; Mon, 7 Jul 2014 01:18:50 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s678IlNl023858 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jul 2014 10:18:47 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s678IiOD006663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2014 10:18:47 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [193.10.94.125] ([193.10.94.125]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)); Mon, 7 Jul 2014 10:18:43 +0200 Message-ID: <53BA57E3.8080300@sunet.se> Date: Mon, 07 Jul 2014 10:18:43 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: secdir@ietf.org, IESG , draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09MnkiLLj - f784cdb89a0a - 20140707 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/WaqUqAn-JYdn4nkQbSRD3p8hQVI Subject: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes 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, 07 Jul 2014 08:18:52 -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. The drafts define a set of EAP attributes for signalling wifi handover from 3gpp devices. In general the draft is well written. I believe the draft is more or less ready. I have two comments, one of which is stylistic and the other may be just me misunderstanding the EAP-AKA handshake... 1. In a few places the draft sais that the defined attributes SHOULD be used. I would qualify this to say that "mobile nodes implementing the spec SHOULD" since EAP is used in a lot of situations where 3gpp _could_ be used but isn't. 2. It seems like AT_CONNECTIVITY_TYPE is signalled before the EAP challenge is completed. Unless I misunderstood something I think this warrants a discussion in the Security Considerations section. Currently the text in that section only talks about when attributes are to be processed but there is no discussion of possible threats based on when attributes are transmitted. Cheers Leif From nobody Mon Jul 7 15:57:14 2014 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 273991B297C; Mon, 7 Jul 2014 15:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 POdAP6HLYgyv; Mon, 7 Jul 2014 15:51:31 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1C61B2985; Mon, 7 Jul 2014 15:51:24 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 07 Jul 2014 15:45:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,621,1400050800"; d="scan'208";a="569635041" Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by orsmga002.jf.intel.com with ESMTP; 07 Jul 2014 15:51:23 -0700 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Jul 2014 15:51:22 -0700 Received: from fmsmsx105.amr.corp.intel.com ([169.254.5.225]) by FMSMSX112.amr.corp.intel.com ([10.18.116.6]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 15:51:23 -0700 From: "Koodli, Rajeev" To: Leif Johansson , "secdir@ietf.org" , IESG , "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" Thread-Topic: secdir review odraft-ietf-netext-wifi-epc-eap-attributes Thread-Index: AQHPmbxSp13TgeTpn02AF6Q7mf9UjZuVOHsA Date: Mon, 7 Jul 2014 22:51:21 +0000 Message-ID: References: <53BA57E3.8080300@sunet.se> In-Reply-To: <53BA57E3.8080300@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.72.145] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7FC6FCA9AC48A14D8ABEF6622C4E559E@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Jr9LZdgNuYpL1zitT-K6HbqESsw X-Mailman-Approved-At: Mon, 07 Jul 2014 15:57:13 -0700 Subject: Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes 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, 07 Jul 2014 22:51:32 -0000 Hi Leif, Thanks for the review. Please see inline: On 7/7/14, 1:18 AM, "Leif Johansson" 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. > >The drafts define a set of EAP attributes for signalling wifi handover >from 3gpp devices. In general the draft is well written. > >I believe the draft is more or less ready. I have two comments, one of >which is stylistic and the other may be just me misunderstanding the >EAP-AKA handshake... > >1. In a few places the draft sais that the defined attributes SHOULD be >used. I would qualify this to say that "mobile nodes implementing the >spec SHOULD" since EAP is used in a lot of situations where 3gpp _could_ >be used but isn't. You mean the =B3SHOULD=B2 should be made specific to 3GPP? If so, we can clarify at the beginning itself. > >2. It seems like AT_CONNECTIVITY_TYPE is signalled before the EAP >challenge is completed. Unless I misunderstood something I think this >warrants a discussion in the Security Considerations section. Currently >the text in that section only talks about when attributes are to be >processed but there is no discussion of possible threats based on when >attributes are transmitted. We can clarify this. The AT_CONNECTIVITY_TYPE attribute indicates what connectivity type MN wants to use. The Network (=B33GPP AAA Server=B2) communicates with the subscriber database ("3GPP HSS") to retrieve MN credentials, but this is outside the scope of this ID and is specific to 3GPP. Regardless, the Network provides back to the MN what is supported (based on the credentials obtained from the subscriber database). So, the MN signaling the attribute does not create new threats. Thanks. -Rajeev =20 > > Cheers Leif From nobody Tue Jul 8 00:15:53 2014 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 7E4DA1B2A7B for ; Tue, 8 Jul 2014 00:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 v6djONq8Ow7e for ; Tue, 8 Jul 2014 00:15:49 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120B91B2A5C for ; Tue, 8 Jul 2014 00:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32918; q=dns/txt; s=iport; t=1404803748; x=1406013348; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=W/8+Zoi7ehUxlyxG64dx1KlyJ/VMjqHjP5Q4B+quaSY=; b=fmqgjVe+bzMiQPM5/UBeT71tsHfpl+fsZ0H5ZVwdG0QQEi6dwdfX2wbT vlmEqk1HaLvzdbQoyWULimogjb/Ue9Y7d5xHwgtHWupJwQm+xPtbbwufR Z8Y4LAathljmJv6kVYYZ/Oc3ZNIvAmnLTxAWeGTITvKnLG9yrTL+QVYJk o=; X-IronPort-AV: E=Sophos;i="5.01,624,1400025600"; d="scan'208,217";a="102341140" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Jul 2014 07:15:46 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s687Fi5L005265; Tue, 8 Jul 2014 07:15:45 GMT Message-ID: <53BB9A9F.1090601@cisco.com> Date: Tue, 08 Jul 2014 09:15:43 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Kent , secdir , jparello@cisco.com, moulchan@cisco.com, n.brownlee@auckland.ac.nz, tnadeau@lucidvision.com, joel jaeggli References: <53A99DB2.5050707@bbn.com> In-Reply-To: <53A99DB2.5050707@bbn.com> Content-Type: multipart/alternative; boundary="------------000607030408020401050601" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/tXpVOfSXexlyVIujND8L7jcnUnw Subject: Re: [secdir] SECDIR review of draft-ietf-eman-energy-aware-mib-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: Tue, 08 Jul 2014 07:15:51 -0000 This is a multi-part message in MIME format. --------------000607030408020401050601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen, draft-ietf-eman-energy-aware-mib-v16 has been posted with the correct Security boilerplate. Regards, Benoit > > I 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. Since I am not a MIB expert, > my comments are strictly related to the security-relevant aspects of > this document. > > This document, as its name implies, defines a MIB for energy > management devices. Given increasing concern over security in the > so-called "cyber-physical" realm, a MIB for such devices clearly > merits scrutiny. Also, to the extent that such devices (e.g., meters) > might be associated with residences, there are personal privacy issues > that ought to be addressed, in the PERPASS era. > > The document is clearly written; my compliments to the authors in that > regard. The one odd thing I noted was that Sections 11.1 and 11.2 > appear between Sections 6 and 7! I think this was a cut and paste > error that is easily remedied. > > The Security Considerations section (7) is about one-half page in > length. I have several concerns with the text here. > > First, the text says "It is thus important to control even GET and/or > NOTIFY access to these objects and possibly to even encrypt the values > of these objects when sending them over the network via SNMP." This > seems to be an understatement. I'd like to see the text here RECOMMEND > use of encryption to provide confidentiality. This would be supportive > of personal privacy, in residential contexts, and physical security in > residential and enterprise settings. I can imagine a movie in which > burglars use a lack of encryption to gain critical information about > building infrastructure from a an energy MIB J. > > The text later says "There are a number of management objects defined > in these MIB modules with a MAX-ACCESS clause of read-write and/or > read-create.Such objects MAY be considered sensitive or vulnerable in > some network environments.The support for SET operations in a > non-secure environment without proper protection can have a negative > effect on network operations. Again, this strikes me as a significant > understatement, i.e., the scope of the "negative effect" could be much > broader that just a network. (Power outlets are cited as examples of > objects, so anything plugged into an outlet could be effected, right?) > There should be more emphasis on the need for access control. > > The text later says "SNMP versions prior to SNMPv3 did not include > adequate security. Even if the network itself is secure (for example, > by using IPsec), there is still no secure control over who on the > secure network is allowed to access and GET/SET > (read/change/create/delete) the objects in these MIB modules." This is > a misleading. IPsec natively provides access control. It would be > accurate to say that the access controls offered by IPsec would only > limit who could access the MIB. What the authors seem to suggest here > is finer-grained access control, so that one can manage GET/SET > privileges for the set of individuals who are authorized to connect to > the MIB via the SMTP port, right? > > The text discussing use of SNMPv3 security is a bit confusing. > > It RECOMMENDS that implementers "consider" SMNPv3 security features, > but then says deployment of SNMP versions prior to v3 is NOT > RECOMMENDED. The first paragraph discussing this topic deals with > thinking about support (vs. use) of SNMPv3, while the second paragraph > makes a much stronger statement about deployment. It would be more > consistent to mandate support (MUST or SHOULD) for SNMPv3 in entities > that incorporate this MIB. Separately the document can RECOMMEND > enabling SNMPv3 security features in deployments, for the reasons cited. --------------000607030408020401050601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Stephen,

draft-ietf-eman-energy-aware-mib-v16 has been posted with the correct Security boilerplate.

Regards, Benoit

I 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. Since I am not a MIB expert, my comments are strictly related to the security-relevant aspects of this document.

 

This document, as its name implies, defines a MIB for energy management devices. Given increasing concern over security in the so-called “cyber-physical” realm, a MIB for such devices clearly merits scrutiny. Also, to the extent that such devices (e.g., meters) might be associated with residences, there are personal privacy issues that ought to be addressed, in the PERPASS era.

 

The document is clearly written; my compliments to the authors in that regard. The one odd thing I noted was that Sections 11.1 and 11.2 appear between Sections 6 and 7! I think this was a cut and paste error that is easily remedied.

 

The Security Considerations section (7) is about one-half page in length. I have several concerns with the text here.

 

First, the text says “It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP.” This seems to be an understatement. I’d like to see the text here RECOMMEND use of encryption to provide confidentiality. This would be supportive of personal privacy, in residential contexts, and physical security in residential and enterprise settings. I can imagine a movie in which burglars use a lack of encryption to gain critical information about building infrastructure from a an energy MIB J.

 

The text later says “There are a number of management objects defined in these MIB modules with a MAX-ACCESS clause of read-write and/or read-create.  Such objects MAY be considered sensitive or vulnerable in some network environments.  The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Again, this strikes me as a significant understatement, i.e., the scope of the “negative effect” could be much broader that just a network. (Power outlets are cited as examples of objects, so anything plugged into an outlet could be effected, right?)  There should be more emphasis on the need for access control.

 

The text later says “SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), there is still no secure control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules.” This is a misleading. IPsec natively provides access control. It would be accurate to say that the access controls offered by IPsec would only limit who could access the MIB. What the authors seem to suggest here is finer-grained access control, so that one can manage GET/SET privileges for the set of individuals who are authorized to connect to the MIB via the SMTP port, right?

 

The text discussing use of SNMPv3 security is a bit confusing.

It RECOMMENDS that implementers “consider” SMNPv3 security features, but then says deployment of SNMP versions prior to v3 is NOT RECOMMENDED. The first paragraph discussing this topic deals with thinking about support (vs. use) of SNMPv3, while the second paragraph makes a much stronger statement about deployment. It would be more consistent to mandate support (MUST or SHOULD) for SNMPv3 in entities that incorporate this MIB. Separately the document can RECOMMEND enabling SNMPv3 security features in deployments, for the reasons cited.

--------------000607030408020401050601-- From nobody Tue Jul 8 00:20:53 2014 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 096461B2A62; Tue, 8 Jul 2014 00:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 K3wqJXcQV7Gp; Tue, 8 Jul 2014 00:20:48 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167331B2A5C; Tue, 8 Jul 2014 00:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13635; q=dns/txt; s=iport; t=1404804047; x=1406013647; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=iPOp14hh5KmN8uL3V7fCYb2E5IiRV2bHsDpHTy0HARw=; b=Gt9iy00f/K+3dFJHyu1Sh909Zw0ybhXUrUAg5r21BzKpAHEAP4JutJwt gcREYewZCseQ55mWpdgOB8NVe1bEXYvEb9WocteW14tqsNPLXyQnD9B96 WntoqgT+ViluJUXkpPHYCvVQN2kI6yJkciFGrLM4SbN1Dpm2nRDcnBRRc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEAHCbu1OtJssW/2dsb2JhbABZg2C/TAGGcFMBgSt1hAMBAQEDAQEBAWsKAQULCw4KCRYPCQMCAQIBFTAGAQwBBQIBAYg2CA3JFxeJZYRvTgeEQwEEmnaBSIVHjH2DRTsv X-IronPort-AV: E=Sophos;i="5.01,624,1400025600"; d="scan'208,217";a="102366113" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 08 Jul 2014 07:20:45 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s687Kird030827; Tue, 8 Jul 2014 07:20:44 GMT Message-ID: <53BB9BCB.8090907@cisco.com> Date: Tue, 08 Jul 2014 09:20:43 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Harrington , Tero Kivinen References: <21421.29586.427961.926637@fireball.kivinen.iki.fi> <53B29817.3090905@cisco.com> In-Reply-To: <53B29817.3090905@cisco.com> Content-Type: multipart/alternative; boundary="------------020409020505040702000102" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/1UBeFNPM-sNf-2JhrGXiFf6YFzk Cc: iesg@ietf.org, draft-ietf-eman-energy-monitoring-mib.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-eman-energy-monitoring-mib-10.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: Tue, 08 Jul 2014 07:20:50 -0000 This is a multi-part message in MIME format. --------------020409020505040702000102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear all, draft-ietf-eman-energy-monitoring-mib-12 has been posted with the correct boilerplate. Regards, Bneoit > Hi David, Tero, > > Thanks for your review. > We will post a new draft version with this boilerplate at > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > > We will also correct "theeoPowerAdminState" > > Finally, wrt your comment: > > The formatting of the draft was bit wierd in places (extra ^L in the > middle of page etc), but I assume those will be fixed by the RFC > editor. > > This is one of those legacy draft published with word :-) > > Regards, Benoit >> Hi, >> >> comments inline. >> >> dbh >> >> On Jun 27, 2014, at 9:37 AM, Tero Kivinen 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 describes the MIB for energy monitoring. It has mostly >>> read only information about the current energy use etc, but it also >>> have one important writable attribute eoPowerAdminState which can be >>> used to change the power state of the device (shut it down?). The MIB >>> also have second part which can be used to create notifications and >>> intervals for enery usage. >>> >>> Both of these are pointed out in the security consideations section >>> and the security considerations section mostly follows the MIB >>> security guidelines text, but differs in one paragraph. The text in >>> draft says: >>> >>> It is RECOMMENDED that implementers consider the security >>> features as provided by the SNMPv3 framework (see [RFC3410], >>> section 8), including full support for the SNMPv3 cryptographic >>> mechanisms (for authentication and privacy). >> These are the old guidelines. >> >>> Where the guidelines text says: >>> >>> Implementations SHOULD provide the security features described >>> by the SNMPv3 framework (see [RFC3410]), and implementations >>> claiming compliance to the SNMPv3 standard MUST include full >>> support for authentication and privacy via the User-based >>> Security Model (USM) [RFC3414] with the AES cipher algorithm >>> [RFC3826]. Implementations MAY also provide support for the >>> Transport Security Model (TSM) [RFC5591] in combination with a >>> secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. >>> >>> Asking implementors to consider security features is something that >>> cannot be verified, i.e. there is no way I can see whether the >>> implementor x actually even considered the security features or not, >>> thus making RECOMMENDATION to consider security feature is just >>> stupid. >> Yeah, but it’s the best that could be negotiated at that point in time. >> >>> The guidelines text instead makes SHOULD for providing >>> security. >>> >>> Why is this text changed from the mib-security framework >>> (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security). >> The document was probably based on an older mib document. >> It MIGHT have been based on the templates on the tools page before I got them updated. >> >> The document should be updated to the new boilerplate. >> >>> Also I think the security considerations section should mention that >>> almost all of the MIB items do have privacy issues, as for example >>> reading the power usage of the home TV/PC/game console/washing machine >>> will give indication whether person is at home, and what he might be >>> doing. Thus the first paragraph saying "Some objects may be considered >>> sensitive", I would say most of the objects are sensitive in most >>> environments. >> without changing the boilerplate, of course … >> >>> Actually it seems to bit dangerous to have mostly read-only >>> information in MIB where the only read-write item is the very security >>> sensitive object which can be used to turn the devices off. Especially >>> when the MIB name is Power and Energy MONITORING MIB. Casual operator >>> might just check the MIB name and then notice there is lots of >>> read-only information like "eoPowerNamePlate" or "eoPowerAccuracy", >>> etc and just assume this is only for monitoring the power usage, and >>> not notice that it also allows turning device on and off via one >>> read-write value hidden among the read-only values. >>> >>> I would be more happy if that one read-write value would be moved to >>> separate MIB, but I do not know if there is better place for it. If it >>> is not moved, then it would be better to change the title of the draft >>> o say "Power and Energy Monitoring and Control MIB" or something >>> similar which indicates more clearly that this MIB can be used to >>> control devices. >>> >>> Nits: >>> >>> In section 11: >>> >>> - Unauthorized changes to the eoPowerOperState (via >>> theeoPowerAdminState ) MAY disrupt the power settings of the >>> ^^^^^^^^^^^^^^^^^^^^ >>> >>> s/theeoPowerAdminState/the eoPowerAdminState/. >>> >>> The formatting of the draft was bit wierd in places (extra ^L in the >>> middle of page etc), but I assume those will be fixed by the RFC >>> editor. >>> -- >>> kivinen@iki.fi >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> . >> > --------------020409020505040702000102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear all,

draft-ietf-eman-energy-monitoring-mib-12 has been posted with the correct boilerplate.

Regards, Bneoit

Hi David, Tero,

Thanks for your review.
We will post a new draft version with this boilerplate at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security

We will also correct "theeoPowerAdminState"

Finally, wrt your comment:
The formatting of the draft was bit wierd in places (extra ^L in the
middle of page etc), but I assume those will be fixed by the RFC
editor.
This is one of those legacy draft published with word :-)

Regards, Benoit
Hi,

comments inline.

dbh

On Jun 27, 2014, at 9:37 AM, Tero Kivinen <kivinen@iki.fi> 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 describes the MIB for energy monitoring. It has mostly
read only information about the current energy use etc, but it also
have one important writable attribute eoPowerAdminState which can be
used to change the power state of the device (shut it down?). The MIB
also have second part which can be used to create notifications and
intervals for enery usage.

Both of these are pointed out in the security consideations section
and the security considerations section mostly follows the MIB
security guidelines text, but differs in one paragraph. The text in
draft says:

      It is RECOMMENDED that implementers consider the security
      features as provided by the SNMPv3 framework (see [RFC3410],
      section 8), including full support for the SNMPv3 cryptographic
      mechanisms (for authentication and privacy).

These are the old guidelines. 


Where the guidelines text says:

     Implementations SHOULD provide the security features described
     by the SNMPv3 framework (see [RFC3410]), and implementations
     claiming compliance to the SNMPv3 standard MUST include full
     support for authentication and privacy via the User-based
     Security Model (USM) [RFC3414] with the AES cipher algorithm
     [RFC3826]. Implementations MAY also provide support for the
     Transport Security Model (TSM) [RFC5591] in combination with a
     secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].

Asking implementors to consider security features is something that
cannot be verified, i.e. there is no way I can see whether the
implementor x actually even considered the security features or not,
thus making RECOMMENDATION to consider security feature is just
stupid.

Yeah, but it’s the best that could be negotiated at that point in time.


The guidelines text instead makes SHOULD for providing
security.

Why is this text changed from the mib-security framework
(http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security).

The document was probably based on an older mib document.
It MIGHT have been based on the templates on the tools page before I got them updated.

The document should be updated to the new boilerplate.


Also I think the security considerations section should mention that
almost all of the MIB items do have privacy issues, as for example
reading the power usage of the home TV/PC/game console/washing machine
will give indication whether person is at home, and what he might be
doing. Thus the first paragraph saying "Some objects may be considered
sensitive", I would say most of the objects are sensitive in most
environments.

without changing the boilerplate, of course …


Actually it seems to bit dangerous to have mostly read-only
information in MIB where the only read-write item is the very security
sensitive object which can be used to turn the devices off. Especially
when the MIB name is Power and Energy MONITORING MIB. Casual operator
might just check the MIB name and then notice there is lots of
read-only information like "eoPowerNamePlate" or "eoPowerAccuracy",
etc and just assume this is only for monitoring the power usage, and
not notice that it also allows turning device on and off via one
read-write value hidden among the read-only values.

I would be more happy if that one read-write value would be moved to
separate MIB, but I do not know if there is better place for it. If it
is not moved, then it would be better to change the title of the draft
o say "Power and Energy Monitoring and Control MIB" or something
similar which indicates more clearly that this MIB can be used to
control devices. 

Nits:

In section 11:

      - Unauthorized changes to the eoPowerOperState (via
        theeoPowerAdminState ) MAY disrupt the power settings of the
	 ^^^^^^^^^^^^^^^^^^^^

s/theeoPowerAdminState/the eoPowerAdminState/.

The formatting of the draft was bit wierd in places (extra ^L in the
middle of page etc), but I assume those will be fixed by the RFC
editor. 
-- 
kivinen@iki.fi

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

.


--------------020409020505040702000102-- From nobody Tue Jul 8 06:31:36 2014 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 A86CC1B283E; Tue, 8 Jul 2014 06:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, 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 uqnPrTDLaYaW; Tue, 8 Jul 2014 06:31:28 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 246921B282B; Tue, 8 Jul 2014 06:31:27 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s68DVOTC010262 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jul 2014 15:31:24 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s68DVI4E018774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2014 15:31:21 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [109.105.104.196] ([109.105.104.196]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)); Tue, 8 Jul 2014 15:31:17 +0200 Message-ID: <53BBF2A5.10506@sunet.se> Date: Tue, 08 Jul 2014 15:31:17 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Koodli, Rajeev" , "secdir@ietf.org" , IESG , "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" References: <53BA57E3.8080300@sunet.se> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09MnNvoAu - 5fe47dd6c817 - 20140708 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rsH_nPIvACe7POLv7-rH6eM0gzQ Subject: Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes 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, 08 Jul 2014 13:31:30 -0000 On 2014-07-08 00:51, Koodli, Rajeev wrote: > > Hi Leif, > > Thanks for the review. > > Please see inline: > > > On 7/7/14, 1:18 AM, "Leif Johansson" 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. >> >> The drafts define a set of EAP attributes for signalling wifi handover >>from 3gpp devices. In general the draft is well written. >> >> I believe the draft is more or less ready. I have two comments, one of >> which is stylistic and the other may be just me misunderstanding the >> EAP-AKA handshake... >> >> 1. In a few places the draft sais that the defined attributes SHOULD be >> used. I would qualify this to say that "mobile nodes implementing the >> spec SHOULD" since EAP is used in a lot of situations where 3gpp _could_ >> be used but isn't. > > You mean the ³SHOULD² should be made specific to 3GPP? If so, we can > clarify at the beginning itself. > Thx > >> >> 2. It seems like AT_CONNECTIVITY_TYPE is signalled before the EAP >> challenge is completed. Unless I misunderstood something I think this >> warrants a discussion in the Security Considerations section. Currently >> the text in that section only talks about when attributes are to be >> processed but there is no discussion of possible threats based on when >> attributes are transmitted. > > We can clarify this. > > The AT_CONNECTIVITY_TYPE attribute indicates what connectivity type MN > wants to use. The Network (³3GPP AAA Server²) communicates with the > subscriber database ("3GPP HSS") to retrieve MN credentials, but this is > outside the scope of this ID and is specific to 3GPP. Regardless, the > Network provides back to the MN what is supported (based on the > credentials obtained from the subscriber database). So, the MN signaling > the attribute does not create new threats. > Yeah I understand how the attribute works. What I don't understand is how the MN knows it gets the AT_CONNECTIVITY_TYPE from the right source since this handshake happens before the EAP authentication has finished. Again - I may just be confused about EAP... Cheers Leif From nobody Tue Jul 8 09:10:43 2014 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 960711B2B62; Tue, 8 Jul 2014 09:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 7oh1eigVu2RO; Tue, 8 Jul 2014 09:10:39 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C991A0104; Tue, 8 Jul 2014 09:10:38 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s68GAaff018786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 12:10:37 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_B320056C-9B0B-4F4A-81E7-FDCDAB379C9E" Date: Tue, 8 Jul 2014 12:10:36 -0400 Message-Id: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-paws-protocol.all@tools.ietg.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0Y1VTNvpVx8L7GIPXwVKgT3BLDQ Subject: [secdir] Secdir Review of draft-ietf-paws-protocol 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, 08 Jul 2014 16:10:41 -0000 --Apple-Mail=_B320056C-9B0B-4F4A-81E7-FDCDAB379C9E 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 ID describes a protocol, PAWS, that allows wireless devices to = access currently unused portions of the radio spectrum. The protocol works between a geospatial database and a device with = geolocation capabilities. The device reports its location and other relevant information to the database, which in turns gives it = information about which portions of the spectrum is available to it. This removes the responsibility for managing the complex information = about spectrum available from the device and to the database, which is better equipped to handle it. =20 The ID has a very thorough and well-written Security Considerations = section, which covers the security threats against such a protocol. = They identify two main threats By using the PAWS protocol, the Master Device and the Database expose themselves to the following risks: o Accuracy: The Master Device receives incorrect spectrum availability information. o Privacy: An unauthorized entity intercepts identifying data for the Master Device or its Slave Devices, such as serial number and location. Note that core PAWS does not address client authentication, on the = grounds that unauthorized clients could find out the existence of white space on their own without the help of PAWS, and in that case there = would be nothing preventing them from using it. The ID does point out = though that client authentication may be required by specific regulatory = domains, and so it is possible for the Database to require client authentication, = e.g. by TLS. The authors appropriately point out the limitations of = using TLS for authentication, particularly when the keys are trusted to small ubiquitous devices. =20 I believe this draft is ready. 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 --Apple-Mail=_B320056C-9B0B-4F4A-81E7-FDCDAB379C9E 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 = ID describes a protocol, PAWS,  that allows wireless devices to = access currently unused portions of the radio spectrum.
The protocol = works between a geospatial database and a device with geolocation = capabilities.  The device reports its location
and other = relevant information to the database, which in turns gives it = information about which portions of the spectrum is available to = it.
This removes the responsibility for managing the complex = information about spectrum available from the device and to the = database,
which is better equipped to handle it. =  

The ID has a very thorough and = well-written Security Considerations section, which  covers the = security threats against such a protocol.  They identify = two
main threats

 By using the = PAWS protocol, the Master Device and the Database expose
themselves = to the following risks:
o Accuracy: The Master Device receives = incorrect spectrum availability
information.
o Privacy: An = unauthorized entity intercepts identifying data for
the Master Device = or its Slave Devices, such as serial number = and
location.

Note that core PAWS does not = address client authentication, on the grounds that unauthorized clients = could find out the existence of white
space on their own = without the help of PAWS, and in that case there would be nothing = preventing them from using it. The ID does point out though that client = authentication may be required by specific regulatory = domains,
and so it is possible for the Database to require = client authentication, e.g. by TLS.  The authors appropriately = point out the limitations of using TLS for authentication, = particularly
when the keys are trusted to small ubiquitous = devices.   

I believe this draft is = ready.


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

= --Apple-Mail=_B320056C-9B0B-4F4A-81E7-FDCDAB379C9E-- From nobody Tue Jul 8 09:17:57 2014 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 87E9C1B2B88; Tue, 8 Jul 2014 09:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 f0AVti-PUJsU; Tue, 8 Jul 2014 09:17:52 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB901B2B87; Tue, 8 Jul 2014 09:17:51 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s68GHo2D024037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 12:17:50 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_881663D6-920F-4515-98FE-B506B5772880" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Catherine Meadows In-Reply-To: Date: Tue, 8 Jul 2014 12:17:50 -0400 Message-Id: References: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-paws-protocol.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/UuzIr9v_FF_fbJ7zFHgni58xD9g Subject: Re: [secdir] Secdir Review of draft-ietf-paws-protocol 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, 08 Jul 2014 16:17:53 -0000 --Apple-Mail=_881663D6-920F-4515-98FE-B506B5772880 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am resending this, because I got one of the email addresses wrong. Cathy 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 On Jul 8, 2014, at 12:10 PM, Catherine Meadows = 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. >=20 >=20 > This ID describes a protocol, PAWS, that allows wireless devices to = access currently unused portions of the radio spectrum. > The protocol works between a geospatial database and a device with = geolocation capabilities. The device reports its location > and other relevant information to the database, which in turns gives = it information about which portions of the spectrum is available to it. > This removes the responsibility for managing the complex information = about spectrum available from the device and to the database, > which is better equipped to handle it. =20 >=20 > The ID has a very thorough and well-written Security Considerations = section, which covers the security threats against such a protocol. = They identify two > main threats >=20 > By using the PAWS protocol, the Master Device and the Database expose > themselves to the following risks: > o Accuracy: The Master Device receives incorrect spectrum availability > information. > o Privacy: An unauthorized entity intercepts identifying data for > the Master Device or its Slave Devices, such as serial number and > location. >=20 > Note that core PAWS does not address client authentication, on the = grounds that unauthorized clients could find out the existence of white > space on their own without the help of PAWS, and in that case there = would be nothing preventing them from using it. The ID does point out = though that client authentication may be required by specific regulatory = domains, > and so it is possible for the Database to require client = authentication, e.g. by TLS. The authors appropriately point out the = limitations of using TLS for authentication, particularly > when the keys are trusted to small ubiquitous devices. =20 >=20 > I believe this draft is ready. >=20 >=20 > 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 >=20 --Apple-Mail=_881663D6-920F-4515-98FE-B506B5772880 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am = resending this, because I got one of the email addresses = wrong.

Cathy


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

On Jul 8, 2014, at 12:10 PM, Catherine Meadows <catherine.meadows@nrl.navy.= mil> 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 ID describes a = protocol, PAWS,  that allows wireless devices to access currently = unused portions of the radio spectrum.
The protocol works between a = geospatial database and a device with geolocation capabilities. =  The device reports its location
and other relevant = information to the database, which in turns gives it information about = which portions of the spectrum is available to it.
This = removes the responsibility for managing the complex information about = spectrum available from the device and to the database,
which = is better equipped to handle it.  

The ID = has a very thorough and well-written Security Considerations section, = which  covers the security threats against such a protocol. =  They identify two
main = threats

 By using the PAWS protocol, the = Master Device and the Database expose
themselves to the following = risks:
o Accuracy: The Master Device receives incorrect spectrum = availability
information.
o Privacy: An unauthorized entity = intercepts identifying data for
the Master Device or its Slave = Devices, such as serial number = and
location.

Note that core PAWS does not = address client authentication, on the grounds that unauthorized clients = could find out the existence of white
space on their own = without the help of PAWS, and in that case there would be nothing = preventing them from using it. The ID does point out though that client = authentication may be required by specific regulatory = domains,
and so it is possible for the Database to require = client authentication, e.g. by TLS.  The authors appropriately = point out the limitations of using TLS for authentication, = particularly
when the keys are trusted to small ubiquitous = devices.   

I believe this draft is = ready.


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


= --Apple-Mail=_881663D6-920F-4515-98FE-B506B5772880-- From nobody Tue Jul 8 09:18:13 2014 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 CE36C1B2B99; Tue, 8 Jul 2014 09:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.102 X-Spam-Level: X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 5-Ryjc_4NQox; Tue, 8 Jul 2014 09:17:57 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 245511B2B95; Tue, 8 Jul 2014 09:17:57 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 08 Jul 2014 09:17:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,625,1400050800"; d="scan'208";a="566800142" Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by fmsmga002.fm.intel.com with ESMTP; 08 Jul 2014 09:17:51 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 09:17:51 -0700 Received: from fmsmsx105.amr.corp.intel.com ([169.254.5.225]) by fmsmsx111.amr.corp.intel.com ([169.254.12.83]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 09:17:51 -0700 From: "Koodli, Rajeev" To: Leif Johansson , "secdir@ietf.org" , IESG , "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" Thread-Topic: secdir review odraft-ietf-netext-wifi-epc-eap-attributes Thread-Index: AQHPmbxSp13TgeTpn02AF6Q7mf9UjZuVOHsAgAFrL4D//7k5gA== Date: Tue, 8 Jul 2014 16:17:50 +0000 Message-ID: References: <53BA57E3.8080300@sunet.se> <53BBF2A5.10506@sunet.se> In-Reply-To: <53BBF2A5.10506@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.93.52] Content-Type: text/plain; charset="euc-kr" Content-ID: <4CB080EACC8D624A840EDDCA60DE7B90@intel.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7B6rWHPFyQifrO-nLazVGzn7tIg Subject: Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes 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, 08 Jul 2014 16:17:59 -0000 DQoNCk9uIDcvOC8xNCwgNjozMSBBTSwgIkxlaWYgSm9oYW5zc29uIiA8bGVpZmpAc3VuZXQuc2U+ IHdyb3RlOg0KDQo+T24gMjAxNC0wNy0wOCAwMDo1MSwgS29vZGxpLCBSYWplZXYgd3JvdGU6DQo+ PiANCj4+Pg0KPj4+IDIuIEl0IHNlZW1zIGxpa2UgQVRfQ09OTkVDVElWSVRZX1RZUEUgaXMgc2ln bmFsbGVkIGJlZm9yZSB0aGUgRUFQDQo+Pj4gY2hhbGxlbmdlIGlzIGNvbXBsZXRlZC4gVW5sZXNz IEkgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmcgSSB0aGluayB0aGlzDQo+Pj4gd2FycmFudHMgYSBk aXNjdXNzaW9uIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLiBDdXJyZW50 bHkNCj4+PiB0aGUgdGV4dCBpbiB0aGF0IHNlY3Rpb24gb25seSB0YWxrcyBhYm91dCB3aGVuIGF0 dHJpYnV0ZXMgYXJlIHRvIGJlDQo+Pj4gcHJvY2Vzc2VkIGJ1dCB0aGVyZSBpcyBubyBkaXNjdXNz aW9uIG9mIHBvc3NpYmxlIHRocmVhdHMgYmFzZWQgb24gd2hlbg0KPj4+IGF0dHJpYnV0ZXMgYXJl IHRyYW5zbWl0dGVkLg0KPj4gDQo+PiBXZSBjYW4gY2xhcmlmeSB0aGlzLg0KPj4gDQo+PiBUaGUg QVRfQ09OTkVDVElWSVRZX1RZUEUgYXR0cmlidXRlIGluZGljYXRlcyB3aGF0IGNvbm5lY3Rpdml0 eSB0eXBlIE1ODQo+PiB3YW50cyB0byB1c2UuIFRoZSBOZXR3b3JrICip+DNHUFAgQUFBIFNlcnZl cqn3KSBjb21tdW5pY2F0ZXMgd2l0aCB0aGUNCj4+IHN1YnNjcmliZXIgZGF0YWJhc2UgKCIzR1BQ IEhTUyIpIHRvIHJldHJpZXZlIE1OIGNyZWRlbnRpYWxzLCBidXQgdGhpcyBpcw0KPj4gb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpcyBJRCBhbmQgaXMgc3BlY2lmaWMgdG8gM0dQUC4gUmVnYXJkbGVz cywgdGhlDQo+PiBOZXR3b3JrIHByb3ZpZGVzIGJhY2sgdG8gdGhlIE1OIHdoYXQgaXMgc3VwcG9y dGVkIChiYXNlZCBvbiB0aGUNCj4+IGNyZWRlbnRpYWxzIG9idGFpbmVkIGZyb20gdGhlIHN1YnNj cmliZXIgZGF0YWJhc2UpLiBTbywgdGhlIE1OIHNpZ25hbGluZw0KPj4gdGhlIGF0dHJpYnV0ZSBk b2VzIG5vdCBjcmVhdGUgbmV3IHRocmVhdHMuDQo+PiANCj4NCj5ZZWFoIEkgdW5kZXJzdGFuZCBo b3cgdGhlIGF0dHJpYnV0ZSB3b3Jrcy4gV2hhdCBJIGRvbid0IHVuZGVyc3RhbmQgaXMNCj5ob3cg dGhlIE1OIGtub3dzIGl0IGdldHMgdGhlIEFUX0NPTk5FQ1RJVklUWV9UWVBFIGZyb20gdGhlIHJp Z2h0IHNvdXJjZQ0KPnNpbmNlIHRoaXMgaGFuZHNoYWtlIGhhcHBlbnMgYmVmb3JlIHRoZSBFQVAg YXV0aGVudGljYXRpb24gaGFzIGZpbmlzaGVkLg0KPg0KPkFnYWluIC0gSSBtYXkganVzdCBiZSBj b25mdXNlZCBhYm91dCBFQVAuLi4NCg0KDQpUaGUgTU4gdmVyaWZpZXMgdGhlIEFVVE4gKEFLQSBw YXJhbWV0ZXIpIHNlbnQgaW4gRUFQLVJlcXVlc3QvQUtBLUNoYWxsZW5nZQ0KdG8gY29uY2x1ZGUg dGhlIGxlZ2l0aW1hY3kgb2YgdGhlIHNvdXJjZS4gQXQgdGhpcyBwb2ludCwgRUFQLUFLQSBoYXMg bm90DQpjb21wbGV0ZWQgeWV0LiBJZiBBVVROIHZlcmlmaWNhdGlvbiBpcyBzdWNjZXNzZnVsLCB0 aGUgTU4gcmVzcG9uZHMgYmFjaw0Kd2l0aCBFQVAtUmVzcG9uZS9BS0EtQ2hhbGxlbmdlLiBTZWUg UkZDIDQxODcsIFNlY3Rpb24gMzoNCg0KIlRoZSBwZWVyIHJ1bnMgdGhlIEFLQSBhbGdvcml0aG0g KHR5cGljYWxseSB1c2luZyBhbiBpZGVudGl0eSBtb2R1bGUpDQogICBhbmQgdmVyaWZpZXMgdGhl IEFVVE4uICBJZiB0aGlzIGlzIHN1Y2Nlc3NmdWwsIHRoZSBwZWVyIGlzIHRhbGtpbmcgdG8NCiAg IGEgbGVnaXRpbWF0ZSBFQVAgc2VydmVyIGFuZCBwcm9jZWVkcyB0byBzZW5kIHRoZSBFQVAtUmVz cG9uc2UvDQogICBBS0EtQ2hhbGxlbmdloaahsQ0KDQotUmFqZWV2DQoNCg0KDQo+DQo+CUNoZWVy cyBMZWlmDQo+DQoNCg== From nobody Tue Jul 8 10:15:29 2014 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 59D2B1A036E; Tue, 8 Jul 2014 10:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.702 X-Spam-Level: X-Spam-Status: No, score=-12.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 V4miTkvU3DUq; Tue, 8 Jul 2014 10:15:23 -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 9752D1B2B56; Tue, 8 Jul 2014 10:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3264; q=dns/txt; s=iport; t=1404839725; x=1406049325; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hEQUGSR8hhx9GNLbcsA7d4IwOVVwf+yECLRpPEuDALA=; b=JGVvhh/lc6zsq5tiygmn1bopipXED1AUjVdM5a5tL4EX7mP5JO6vzujK 6uCeEft8WY1+v15b97SoLjnywa+2YZBCTl/BrvXF7vvrFzjVomcgcMMSn c5Fy8zZRrs1Dr3rCJsz+gKbyV9/UYfUgDX1XFr7RmhRk0FzPBiK1706kH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHQmvFOtJA2B/2dsb2JhbABRCYMOUlqCb7wUCIZuUwEZfxZ1hAMBAQEDAQEBATE6CxACAQYCGAQoAgIlCyUCBA4FiDoIDZJBnB8GmUMXgSaNQSgYGweCcTyBFgWadoFIkkSDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,626,1400025600"; d="scan'208";a="59195544" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 08 Jul 2014 17:15:24 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s68HFLI6003494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 17:15:21 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 12:15:21 -0500 From: "Joseph Salowey (jsalowey)" To: "Koodli, Rajeev" Thread-Topic: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes Thread-Index: AQHPmbxSp13TgeTpn02AF6Q7mf9UjZuVOHsAgAFrL4D//7k5gIAAY+eA Date: Tue, 8 Jul 2014 17:15:21 +0000 Message-ID: <298C55D6-7F96-4BB5-9313-BA02A2B4D2F2@cisco.com> References: <53BA57E3.8080300@sunet.se> <53BBF2A5.10506@sunet.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.44] Content-Type: text/plain; charset="euc-kr" Content-ID: <245DFF5B68F71C44A2000454473F1D63@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vnXnw2xfC3mQQHSqRfWJxvoLPCo Cc: IESG , "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes 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, 08 Jul 2014 17:15:25 -0000 DQpPbiBKdWwgOCwgMjAxNCwgYXQgOToxNyBBTSwgS29vZGxpLCBSYWplZXYgPHJhamVldi5rb29k bGlAaW50ZWwuY29tPiB3cm90ZToNCg0KPiANCj4gDQo+IE9uIDcvOC8xNCwgNjozMSBBTSwgIkxl aWYgSm9oYW5zc29uIiA8bGVpZmpAc3VuZXQuc2U+IHdyb3RlOg0KPiANCj4+IE9uIDIwMTQtMDct MDggMDA6NTEsIEtvb2RsaSwgUmFqZWV2IHdyb3RlOg0KPj4+IA0KPj4+PiANCj4+Pj4gMi4gSXQg c2VlbXMgbGlrZSBBVF9DT05ORUNUSVZJVFlfVFlQRSBpcyBzaWduYWxsZWQgYmVmb3JlIHRoZSBF QVANCj4+Pj4gY2hhbGxlbmdlIGlzIGNvbXBsZXRlZC4gVW5sZXNzIEkgbWlzdW5kZXJzdG9vZCBz b21ldGhpbmcgSSB0aGluayB0aGlzDQo+Pj4+IHdhcnJhbnRzIGEgZGlzY3Vzc2lvbiBpbiB0aGUg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi4gQ3VycmVudGx5DQo+Pj4+IHRoZSB0ZXh0 IGluIHRoYXQgc2VjdGlvbiBvbmx5IHRhbGtzIGFib3V0IHdoZW4gYXR0cmlidXRlcyBhcmUgdG8g YmUNCj4+Pj4gcHJvY2Vzc2VkIGJ1dCB0aGVyZSBpcyBubyBkaXNjdXNzaW9uIG9mIHBvc3NpYmxl IHRocmVhdHMgYmFzZWQgb24gd2hlbg0KPj4+PiBhdHRyaWJ1dGVzIGFyZSB0cmFuc21pdHRlZC4N Cj4+PiANCj4+PiBXZSBjYW4gY2xhcmlmeSB0aGlzLg0KPj4+IA0KPj4+IFRoZSBBVF9DT05ORUNU SVZJVFlfVFlQRSBhdHRyaWJ1dGUgaW5kaWNhdGVzIHdoYXQgY29ubmVjdGl2aXR5IHR5cGUgTU4N Cj4+PiB3YW50cyB0byB1c2UuIFRoZSBOZXR3b3JrICip+DNHUFAgQUFBIFNlcnZlcqn3KSBjb21t dW5pY2F0ZXMgd2l0aCB0aGUNCj4+PiBzdWJzY3JpYmVyIGRhdGFiYXNlICgiM0dQUCBIU1MiKSB0 byByZXRyaWV2ZSBNTiBjcmVkZW50aWFscywgYnV0IHRoaXMgaXMNCj4+PiBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzIElEIGFuZCBpcyBzcGVjaWZpYyB0byAzR1BQLiBSZWdhcmRsZXNzLCB0aGUN Cj4+PiBOZXR3b3JrIHByb3ZpZGVzIGJhY2sgdG8gdGhlIE1OIHdoYXQgaXMgc3VwcG9ydGVkIChi YXNlZCBvbiB0aGUNCj4+PiBjcmVkZW50aWFscyBvYnRhaW5lZCBmcm9tIHRoZSBzdWJzY3JpYmVy IGRhdGFiYXNlKS4gU28sIHRoZSBNTiBzaWduYWxpbmcNCj4+PiB0aGUgYXR0cmlidXRlIGRvZXMg bm90IGNyZWF0ZSBuZXcgdGhyZWF0cy4NCj4+PiANCj4+IA0KPj4gWWVhaCBJIHVuZGVyc3RhbmQg aG93IHRoZSBhdHRyaWJ1dGUgd29ya3MuIFdoYXQgSSBkb24ndCB1bmRlcnN0YW5kIGlzDQo+PiBo b3cgdGhlIE1OIGtub3dzIGl0IGdldHMgdGhlIEFUX0NPTk5FQ1RJVklUWV9UWVBFIGZyb20gdGhl IHJpZ2h0IHNvdXJjZQ0KPj4gc2luY2UgdGhpcyBoYW5kc2hha2UgaGFwcGVucyBiZWZvcmUgdGhl IEVBUCBhdXRoZW50aWNhdGlvbiBoYXMgZmluaXNoZWQuDQo+PiANCj4+IEFnYWluIC0gSSBtYXkg anVzdCBiZSBjb25mdXNlZCBhYm91dCBFQVAuLi4NCj4gDQo+IA0KPiBUaGUgTU4gdmVyaWZpZXMg dGhlIEFVVE4gKEFLQSBwYXJhbWV0ZXIpIHNlbnQgaW4gRUFQLVJlcXVlc3QvQUtBLUNoYWxsZW5n ZQ0KPiB0byBjb25jbHVkZSB0aGUgbGVnaXRpbWFjeSBvZiB0aGUgc291cmNlLiBBdCB0aGlzIHBv aW50LCBFQVAtQUtBIGhhcyBub3QNCj4gY29tcGxldGVkIHlldC4gSWYgQVVUTiB2ZXJpZmljYXRp b24gaXMgc3VjY2Vzc2Z1bCwgdGhlIE1OIHJlc3BvbmRzIGJhY2sNCj4gd2l0aCBFQVAtUmVzcG9u ZS9BS0EtQ2hhbGxlbmdlLiBTZWUgUkZDIDQxODcsIFNlY3Rpb24gMzoNCj4gDQo+ICJUaGUgcGVl ciBydW5zIHRoZSBBS0EgYWxnb3JpdGhtICh0eXBpY2FsbHkgdXNpbmcgYW4gaWRlbnRpdHkgbW9k dWxlKQ0KPiAgIGFuZCB2ZXJpZmllcyB0aGUgQVVUTi4gIElmIHRoaXMgaXMgc3VjY2Vzc2Z1bCwg dGhlIHBlZXIgaXMgdGFsa2luZyB0bw0KPiAgIGEgbGVnaXRpbWF0ZSBFQVAgc2VydmVyIGFuZCBw cm9jZWVkcyB0byBzZW5kIHRoZSBFQVAtUmVzcG9uc2UvDQo+ICAgQUtBLUNoYWxsZW5nZaGmobEN Cj4gDQoNCltKb2VdIElzIHRoZSBhdHRyaWJ1dGUgaW4gcXVlc3Rpb24gcHJvdGVjdGVkIGJ5IEFU X01BQz8gIElmIG5vdCwgaXRzIHBvc3NpYmxlIHRoYXQgaXQgY291bGQgYmUgbW9kaWZpZWQgaW4g dHJhbnNpdC4gIA0KDQo+IC1SYWplZXYNCj4gDQo+IA0KPiANCj4+IA0KPj4gCUNoZWVycyBMZWlm DQo+PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHNlY2RpciBtYWlsaW5nIGxpc3QNCj4gc2VjZGlyQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlyDQo+IHdpa2k6IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGlyUmV2aWV3DQoNCg== From nobody Tue Jul 8 10:17:00 2014 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 1A0041B2B9E; Tue, 8 Jul 2014 10:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, 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 DeNsmAp3qOOg; Tue, 8 Jul 2014 10:16:57 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 942D41A0386; Tue, 8 Jul 2014 10:16:57 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s68HGkMt031799 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jul 2014 19:16:46 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s68HGhsO028990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2014 19:16:45 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.115] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)); Tue, 8 Jul 2014 19:16:41 +0200 Message-ID: <53BC2779.70506@sunet.se> Date: Tue, 08 Jul 2014 19:16:41 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" , "Koodli, Rajeev" References: <53BA57E3.8080300@sunet.se> <53BBF2A5.10506@sunet.se> <298C55D6-7F96-4BB5-9313-BA02A2B4D2F2@cisco.com> In-Reply-To: <298C55D6-7F96-4BB5-9313-BA02A2B4D2F2@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09MnRgK0f - d53adbd07f39 - 20140708 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Utn7EyTzxA2XUJuJUdZZ2vPbIN0 Cc: "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes 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, 08 Jul 2014 17:16:59 -0000 >> > > [Joe] Is the attribute in question protected by AT_MAC? If not, its possible that it could be modified in transit. > yeah what Joe said From nobody Tue Jul 8 15:20:13 2014 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 8E55D1A015B; Tue, 8 Jul 2014 15:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 OcEKc3mrEEBI; Tue, 8 Jul 2014 15:20:07 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id E34121A015F; Tue, 8 Jul 2014 15:20:06 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 08 Jul 2014 15:20:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,628,1400050800"; d="scan'208";a="454662192" Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by azsmga001.ch.intel.com with ESMTP; 08 Jul 2014 15:20:05 -0700 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 15:20:05 -0700 Received: from fmsmsx105.amr.corp.intel.com ([169.254.5.225]) by fmsmsx158.amr.corp.intel.com ([169.254.15.197]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 15:20:05 -0700 From: "Koodli, Rajeev" To: Leif Johansson , "Joseph Salowey (jsalowey)" Thread-Topic: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes Thread-Index: AQHPmtBxgT3VMa/gaUKZ1gsnr5fLR5uWv+aA Date: Tue, 8 Jul 2014 22:20:03 +0000 Message-ID: References: <53BA57E3.8080300@sunet.se> <53BBF2A5.10506@sunet.se> <298C55D6-7F96-4BB5-9313-BA02A2B4D2F2@cisco.com> <53BC2779.70506@sunet.se> In-Reply-To: <53BC2779.70506@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.71.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5790423FF246AD4D87F014D21CEB4CF4@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/SkWxq715AyXZrgSR0XNWI6PWYGU Cc: "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes 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, 08 Jul 2014 22:20:08 -0000 RFC 4187: "8.2 Protocol Extensibility EAP-AKA can be extended by specifying new attribute types. If skippable attributes are used, it is possible to extend the protocol without breaking old implementations. As specified in Section 10.13, if new attributes are specified for EAP-Request/AKA-Identity or EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to integrity protect the new attributes.=B2 So, this applies for the attribute in question. -Rajeev On 7/8/14, 10:16 AM, "Leif Johansson" wrote: > >>> >>=20 >> [Joe] Is the attribute in question protected by AT_MAC? If not, its >>possible that it could be modified in transit. >>=20 > >yeah what Joe said > > From nobody Tue Jul 8 21:48:37 2014 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 13BC91A0341; Tue, 8 Jul 2014 21:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 YpQkFohn2S0Q; Tue, 8 Jul 2014 21:48:22 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1301A033B; Tue, 8 Jul 2014 21:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1376; q=dns/txt; s=iport; t=1404881306; x=1406090906; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v6th8TU6KbzyLyLxgD3ALnK86wn+gU7GGxxvZSI7EmM=; b=monASJMUFuW3adRUoyfJzkKcaIm6R7MPUMKH5lSL26TZrfFfBm/cwnVJ l06gXv2MiD5wfN8vHUbcXwahve2uHLa+OudOqzjEv+3gS+e3U/PdEd1lm xmvbPfN27MV/KsalLajCGKwcnd8yBYAd3X9wyV0W77WzWslxQzfPGsd4w Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAC/IvFOtJA2M/2dsb2JhbABRCYMOgSzGcgGBGBZ1hAMBAQEDAXkQAgEIGC4yJQIEDgWIOgjIQBeOZygzB4MtgRYBBIoXkF+UDINDgjA X-IronPort-AV: E=Sophos;i="5.01,630,1400025600"; d="scan'208";a="59325428" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 09 Jul 2014 04:48:25 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s694mLxE030627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 04:48:21 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 23:48:20 -0500 From: "Joseph Salowey (jsalowey)" To: "Koodli, Rajeev" Thread-Topic: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes Thread-Index: AQHPmvvKKnDgmCmS9UGIfsPwnOgiRJuXf+WA Date: Wed, 9 Jul 2014 04:48:19 +0000 Message-ID: <3C10F572-C486-4D3D-8BFF-AB5507831B24@cisco.com> References: <53BA57E3.8080300@sunet.se> <53BBF2A5.10506@sunet.se> <298C55D6-7F96-4BB5-9313-BA02A2B4D2F2@cisco.com> <53BC2779.70506@sunet.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.44] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QjoNpf7jIrU3aTFBUVTge-Ktxis Cc: IESG , "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes 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, 09 Jul 2014 04:48:33 -0000 On Jul 8, 2014, at 3:20 PM, Koodli, Rajeev wrote: >=20 > RFC 4187: >=20 > "8.2 Protocol Extensibility >=20 > EAP-AKA can be extended by specifying new attribute types. If > skippable attributes are used, it is possible to extend the protocol > without breaking old implementations. As specified in Section 10.13, > if new attributes are specified for EAP-Request/AKA-Identity or > EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to > integrity protect the new attributes.=B2 >=20 [Joe] Makes sense. Although it is redundant with RFC4187, It might be wor= th mentioning in the security considerations section that AT_CHECKCODE prot= ects the attributes in the EAP/AKA-Identity messages once it has be verifie= d by a valid AT_MAC. This would help clarify that the attributes are prot= ected and at what point they are authenticated. It might also help remind = implementers that they need to implement AT_CHECKCODE. =20 >=20 > So, this applies for the attribute in question. >=20 > -Rajeev >=20 >=20 >=20 > On 7/8/14, 10:16 AM, "Leif Johansson" wrote: >=20 >>=20 >>>>=20 >>>=20 >>> [Joe] Is the attribute in question protected by AT_MAC? If not, its >>> possible that it could be modified in transit. >>>=20 >>=20 >> yeah what Joe said >>=20 >>=20 >=20 From nobody Tue Jul 8 22:32:58 2014 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 B2CC51A033B; Tue, 8 Jul 2014 22:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_BASE64_BLANKS=0.001, RP_MATCHES_RCVD=-0.651, 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 vdb5J2n-Qw3d; Tue, 8 Jul 2014 22:32:55 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 D4E711A0331; Tue, 8 Jul 2014 22:32:54 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s695Wi4w019179 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jul 2014 07:32:44 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s695Wda9006770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 07:32:42 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [62.102.145.131] ([62.102.145.131]) by kerio.sunet.se (Kerio Connect 8.2.4); Wed, 9 Jul 2014 07:32:37 +0200 From: "Leif Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Mime-Version: 1.0 (1.0) Message-Id: <616EA2AC-8CF2-4014-88F8-E1560BB268F4@sunet.se> Date: Wed, 9 Jul 2014 07:32:39 +0200 References: <53BA57E3.8080300@sunet.se> <53BBF2A5.10506@sunet.se> <298C55D6-7F96-4BB5-9313-BA02A2B4D2F2@cisco.com> <53BC2779.70506@sunet.se> <3C10F572-C486-4D3D-8BFF-AB5507831B24@cisco.com> To: "Joseph Salowey (jsalowey)" In-Reply-To: <3C10F572-C486-4D3D-8BFF-AB5507831B24@cisco.com> X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Mo5wIiM - d9be30ee0314 - 20140709 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/uoZ5v0Pq-2LSpdBR3M-Sl_31ttg Cc: "Koodli, Rajeev" , "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes 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, 09 Jul 2014 05:32:56 -0000 DQoNCj4gOSBqdWwgMjAxNCBrbC4gMDY6NDggc2tyZXYgIkpvc2VwaCBTYWxvd2V5IChqc2Fsb3dl eSkiIDxqc2Fsb3dleUBjaXNjby5jb20+Og0KPiANCj4gDQo+PiBPbiBKdWwgOCwgMjAxNCwgYXQg MzoyMCBQTSwgS29vZGxpLCBSYWplZXYgPHJhamVldi5rb29kbGlAaW50ZWwuY29tPiB3cm90ZToN Cj4+IA0KPj4gDQo+PiBSRkMgNDE4NzoNCj4+IA0KPj4gIjguMiBQcm90b2NvbCBFeHRlbnNpYmls aXR5DQo+PiANCj4+ICBFQVAtQUtBIGNhbiBiZSBleHRlbmRlZCBieSBzcGVjaWZ5aW5nIG5ldyBh dHRyaWJ1dGUgdHlwZXMuICBJZg0KPj4gIHNraXBwYWJsZSBhdHRyaWJ1dGVzIGFyZSB1c2VkLCBp dCBpcyBwb3NzaWJsZSB0byBleHRlbmQgdGhlIHByb3RvY29sDQo+PiAgd2l0aG91dCBicmVha2lu ZyBvbGQgaW1wbGVtZW50YXRpb25zLiAgQXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gMTAuMTMsDQo+ PiAgaWYgbmV3IGF0dHJpYnV0ZXMgYXJlIHNwZWNpZmllZCBmb3IgRUFQLVJlcXVlc3QvQUtBLUlk ZW50aXR5IG9yDQo+PiAgRUFQLVJlc3BvbnNlL0FLQS1JZGVudGl0eSwgdGhlbiB0aGUgQVRfQ0hF Q0tDT0RFIE1VU1QgYmUgdXNlZCB0bw0KPj4gIGludGVncml0eSBwcm90ZWN0IHRoZSBuZXcgYXR0 cmlidXRlcy7Csg0KPiANCj4gW0pvZV0gIE1ha2VzIHNlbnNlLiAgQWx0aG91Z2ggaXQgaXMgcmVk dW5kYW50IHdpdGggUkZDNDE4NywgSXQgbWlnaHQgYmUgd29ydGggbWVudGlvbmluZyBpbiB0aGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0aGF0IEFUX0NIRUNLQ09ERSBwcm90ZWN0 cyB0aGUgYXR0cmlidXRlcyBpbiB0aGUgRUFQL0FLQS1JZGVudGl0eSBtZXNzYWdlcyBvbmNlIGl0 IGhhcyBiZSB2ZXJpZmllZCBieSBhIHZhbGlkIEFUX01BQy4gICBUaGlzIHdvdWxkIGhlbHAgY2xh cmlmeSB0aGF0IHRoZSBhdHRyaWJ1dGVzIGFyZSBwcm90ZWN0ZWQgYW5kIGF0IHdoYXQgcG9pbnQg dGhleSBhcmUgYXV0aGVudGljYXRlZC4gIEl0IG1pZ2h0IGFsc28gaGVscCByZW1pbmQgaW1wbGVt ZW50ZXJzIHRoYXQgdGhleSBuZWVkIHRvIGltcGxlbWVudCBBVF9DSEVDS0NPREUuICANCg0KYWdy ZWUhDQoNCj4gDQo+PiANCj4+IFNvLCB0aGlzIGFwcGxpZXMgZm9yIHRoZSBhdHRyaWJ1dGUgaW4g cXVlc3Rpb24uDQo+PiANCj4+IC1SYWplZXYNCj4+IA0KPj4gDQo+PiANCj4+PiBPbiA3LzgvMTQs IDEwOjE2IEFNLCAiTGVpZiBKb2hhbnNzb24iIDxsZWlmakBzdW5ldC5zZT4gd3JvdGU6DQo+Pj4g DQo+Pj4gDQo+Pj4+IA0KPj4+PiBbSm9lXSBJcyB0aGUgYXR0cmlidXRlIGluIHF1ZXN0aW9uIHBy b3RlY3RlZCBieSBBVF9NQUM/ICBJZiBub3QsIGl0cw0KPj4+PiBwb3NzaWJsZSB0aGF0IGl0IGNv dWxkIGJlIG1vZGlmaWVkIGluIHRyYW5zaXQuDQo+Pj4gDQo+Pj4geWVhaCB3aGF0IEpvZSBzYWlk DQo+IA0K From nobody Wed Jul 9 01:55:18 2014 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 4344D1A03B6; Wed, 9 Jul 2014 01:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 dGDEEVxKO6YL; Wed, 9 Jul 2014 01:55:15 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672C21A03B1; Wed, 9 Jul 2014 01:55:15 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s698tCad015023; Wed, 9 Jul 2014 09:55:12 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s698t926014974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Jul 2014 09:55:10 +0100 From: "Adrian Farrel" To: "'Ben Laurie'" , "'IETF Discussion List'" , References: In-Reply-To: Date: Wed, 9 Jul 2014 09:55:11 +0100 Message-ID: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4uJ9KXH6Wajq6HAA2wc6J8Axr9ptFMQaQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20806.005 X-TM-AS-Result: No--12.720-10.0-31-10 X-imss-scan-details: No--12.720-10.0-31-10 X-TMASE-MatchedRID: byfwvk+IcRmnykMun0J1wnBRIrj8R47F1kqyrcMalqVq4coTktrGX6+2 iUhw8uh44SA+/zgG+aNpjVjI+jMPM2hYmQszDsXl+mHRL3uzOiJyawdArtww57KeTtOdjMy6dgv 7yq6FdLNUNb4KGOm2sMg1Zg1hNKhj8a3GP7g242JIOSHptb5tx5RaYX0SmKrqSs2HWVCds5mj23 zlnPdxqJ6vrY2L+tTo48o86hCPxmWKMKSXOU/Gp9PNaYYJeRf5UAjrAJWsTe/G/Q7e2G2ERD84a DM0eBNkSPH8ly2RYDOX+cT5KI7shirmjHD28Kviw4PlNTUpnLm/yN2q8U674vdsGrGaOKdNDQ9K DzwhHMMa60S5yaTEp7/duX0pgBjTY3q3LBCbBAyeAiCmPx4NwJXxsKTUj1Z+cl9zWW7buV6y5/t FZu9S3Ku6xVHLhqfxIAcCikR3vq8h46iNBoiE5mj9AZ8h2gilpNbH4grRrU9Ex2NgktUEWud356 u8yqUH Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8PKyeWG0Us-foTN9DqRXJyhlnFo Cc: iesg@ietf.org Subject: Re: [secdir] Security review of draft-ietf-pce-questions-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 08:55:17 -0000 Hi Ben, Thanks for taking the time to review this document and for posting your = comments to the IETF discussion list so that we can consider them as = last call comments. [snip] > The security considerations section makes this claim: >=20 > "This informational document does not define any new protocol elements > or mechanism. As such, it does not introduce any new security > issues." >=20 > I agree with the premise, but not the conclusion: just because an RFC > does not introduce new security issues, that does not mean that there > are no security considerations. >=20 > Indeed, this RFC discusses many things that have quite serious > security considerations, without mentioning any of them. For example, > section 4 "How Do I Find My PCE?" (the very first question) advocates > a number of potentially completely insecure mechanisms with no mention > of their security properties (or otherwise). This is obviously > pervasive, given the stance taken in the security considerations. >=20 > The document does mention that RFC 6952 gives a security analysis for > PCEP, and perhaps this is sufficient but it seems to me that a > document intended to give useful background information to noobs > should include security directly in that information rather than defer > to another giant document (which mixes PCEP info with other > protocols). I don't believe that this document is strong on "advocacy", but = discusses which tools are out there and what some people do. Previous PCE RFCs have given some attention to security concerns in the = use of PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088. RFC 5089), and = the PCEP (RFC 4657 and RFC 5440). As such, "PCE Security" was not deemed = by the authors to be a previously "unanswered question" and so did not = need attention in this document. That said, you are correct that the various sections do not discuss the = security implications relating to those sections. I would be pretty = loathe to add security text to each section in this document: I think = that would make the document heavy and less likely to be read by its = intended consumers (it is not targeting "noobs" although they are = welcome to read it). Perhaps a solution to this *is* to treat Security as an unanswered = question and add a section "How Secure is my PCE-Enabled System?" I = can't think of a lot to add there except for general egg-sucking = guidance, but there would be a pointer to the TCP-AO discussions = currently going on in the WG. What do you think of that as a way = forward? Thanks, Adrian From nobody Wed Jul 9 02:05:49 2014 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 EE9891A03B7; Wed, 9 Jul 2014 02:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 4LVK913L-nUB; Wed, 9 Jul 2014 02:05:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 9FDFD1A0337; Wed, 9 Jul 2014 02:05:42 -0700 (PDT) Received: from [192.168.131.128] ([80.92.116.212]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LsUDg-1WcS7v0Jq4-0121tY; Wed, 09 Jul 2014 11:05:39 +0200 Message-ID: <53BD05DF.7080709@gmx.net> Date: Wed, 09 Jul 2014 11:05:35 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Ben Laurie' , 'IETF Discussion List' , secdir@ietf.org References: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> In-Reply-To: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bNvcckO4RVGA1Qm9VQEEXfwxH9D7kvvLi" X-Provags-ID: V03:K0:mTHeb6i3c/MRmfWQfqjswmZltMZkmGJSw+iMK3NenKqaxWsxTcA Ap+OaRbi8Y55aEmsXewbCWe55/IRbmfvwTCdWaz/3Sthg4K3oWYKCy00VJsYhk7cRefSoyB WJO+Z6cPYYobMgon+bTiCP2DoNiga+N5Mtx/KTPcnCiJZAOcgl3UJBoFmnt9l331/BE7SOH Eigs0jTeumCLaHvk3OL0w== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/W0h69QJB8U9IY0FaWbhB_FkO0ek Cc: iesg@ietf.org Subject: Re: [secdir] Security review of draft-ietf-pce-questions-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, 09 Jul 2014 09:05:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bNvcckO4RVGA1Qm9VQEEXfwxH9D7kvvLi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/09/2014 10:55 AM, Adrian Farrel wrote: > I would be pretty loathe to add security text to each section in this d= ocument: I think that would make the document heavy and less likely to be= read by its intended consumers I like that one. I think I will quote you in the future as someone who had said "Adding security text to a specification makes the document heavy and less likely to be read by its intended consumers." Ciao Hannes --bNvcckO4RVGA1Qm9VQEEXfwxH9D7kvvLi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTvQXfAAoJEGhJURNOOiAtbVIIAIyc7G6nFup5sP1QLZ/0PLM3 b7Bnttqha0uEyneDOnbylxWSpf/z/fqI7zJMIMmwITa8zp1D2pDnudVScTrI4e6O ZCCOjOPkC16K8CoKdtSa2KKMwkdOGifJ2aaC1QCjQWO5wVXn3qTUt6o2ZLsbuBvM c6lsteUXa5Q0eyrFsJ5jRE6NJfefDIOBG5Ur3XmCMfYCKNaxcTVQYwLbn/bUw2L7 Val3O/2mkB08absWKEGz/H1UNsJ58XbfAMQW8gqw6FHEc7W4M0LJp8rs8nAELvWj +CqEudRzV1xCFOPY+UD/sFa2RRWiaI+Nxqrpy1RfaAd6Hnw8BllQn1KyutDWG+U= =SFPa -----END PGP SIGNATURE----- --bNvcckO4RVGA1Qm9VQEEXfwxH9D7kvvLi-- From nobody Wed Jul 9 07:04:37 2014 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 831AB1A03A1 for ; Wed, 9 Jul 2014 07:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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, RP_MATCHES_RCVD=-0.651, 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 a8tpWiUd6-dh for ; Wed, 9 Jul 2014 07:04:29 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA42C1A050E for ; Wed, 9 Jul 2014 07:04:28 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so6061883qaq.24 for ; Wed, 09 Jul 2014 07:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zsbnmCneC6P+pwY5+AL5vfpB6+cntXX/P8DawNXaDN4=; b=EYmAtKyFf66LxzFnz7g1lQ1350fy04eq4T5nGI+n9WZFn7c6MM7QyPAPjk+Jy7h8Ir NNm7qHZyZtl3H+Xgc1TpInbBOk/VlF7EuSDZKjxEr1Unp/OHAuTGF+aCZ5x1Vpuf0b3E flecxy1a1p7PYeUH+wpwEvQnJgMxvChvaIHzZ8hmEsB8cM4LMbHJvQxfZ/kFOwEyRfN5 4wDEnfjlVqP3PB8mNTJSe+13WYEfhlLdJQbd1oSgHmMGlAuaU7Kg5yNPDBKj+QxnhqVI erSth+lx3uk3ez6wUAAjK/f4QfaQLOTGKpheJtUuCby61VuKr884IzQfs71bxsLGgJAW jq1Q== 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=zsbnmCneC6P+pwY5+AL5vfpB6+cntXX/P8DawNXaDN4=; b=F1f3ZdFVzN2T8N7/f8A6q+CxK3zewnoU5vanHW3mjoLEd00v2aIcjdkrnkepIY/n2Q 5Z582NutU/Js1Uxljzxk/BJ8iJmTukUrct8RuVTciWtVFQcWo22AGTWrprKdpiaNkAs0 /Dt6PiuIdCxKb0a1PYw0e9lQJ0AC7MYuPzKZ0AINWO2GinD3+1Hwof260MlvcRLFKg71 UX5lrTzBWkrMEtgWK5BTCwWbHfJMm1tNBwOHTbhATjEK5ttxJPfyg17QFSVnpak4NwNi yH4jenF/msebp9vORPDoTgF3zrsxHT6KEgbjMpN/vrmkGcmQOiL6IsBOTK3Jv3eW6z26 B9sA== X-Gm-Message-State: ALoCoQk4z62cdjGOkSXlaxLVTWtIrs78IPfmeJgsQt1Ks/Y21zfE+fKneWaDDX9oGYeO56ptQL6m MIME-Version: 1.0 X-Received: by 10.224.134.201 with SMTP id k9mr71000586qat.59.1404914667797; Wed, 09 Jul 2014 07:04:27 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Wed, 9 Jul 2014 07:04:27 -0700 (PDT) In-Reply-To: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> References: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> Date: Wed, 9 Jul 2014 15:04:27 +0100 Message-ID: From: Ben Laurie To: adrian@olddog.co.uk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2vW6WdYn3VbU5Fll_9GMenFVdRE Cc: The IESG , IETF Discussion List , "secdir@ietf.org" Subject: Re: [secdir] Security review of draft-ietf-pce-questions-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, 09 Jul 2014 14:04:30 -0000 On 9 July 2014 09:55, Adrian Farrel wrote: > Hi Ben, > > Thanks for taking the time to review this document and for posting your c= omments to the IETF discussion list so that we can consider them as last ca= ll comments. > > [snip] > >> The security considerations section makes this claim: >> >> "This informational document does not define any new protocol elements >> or mechanism. As such, it does not introduce any new security >> issues." >> >> I agree with the premise, but not the conclusion: just because an RFC >> does not introduce new security issues, that does not mean that there >> are no security considerations. >> >> Indeed, this RFC discusses many things that have quite serious >> security considerations, without mentioning any of them. For example, >> section 4 "How Do I Find My PCE?" (the very first question) advocates >> a number of potentially completely insecure mechanisms with no mention >> of their security properties (or otherwise). This is obviously >> pervasive, given the stance taken in the security considerations. >> >> The document does mention that RFC 6952 gives a security analysis for >> PCEP, and perhaps this is sufficient but it seems to me that a >> document intended to give useful background information to noobs >> should include security directly in that information rather than defer >> to another giant document (which mixes PCEP info with other >> protocols). > > I don't believe that this document is strong on "advocacy", but discusses= which tools are out there and what some people do. > > Previous PCE RFCs have given some attention to security concerns in the u= se of PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088. RFC 5089), and the= PCEP (RFC 4657 and RFC 5440). As such, "PCE Security" was not deemed by th= e authors to be a previously "unanswered question" and so did not need atte= ntion in this document. > > That said, you are correct that the various sections do not discuss the s= ecurity implications relating to those sections. I would be pretty loathe t= o add security text to each section in this document: I think that would ma= ke the document heavy and less likely to be read by its intended consumers = (it is not targeting "noobs" although they are welcome to read it). Your position appears to be that they will then go on to read much heavier documents in order to discover the security properties of the solutions you suggest, which seems a little unlikely, particularly if there's no mention of the necessity to do so. Or perhaps you think security is not important? > Perhaps a solution to this *is* to treat Security as an unanswered questi= on and add a section "How Secure is my PCE-Enabled System?" I can't think o= f a lot to add there except for general egg-sucking guidance, but there wou= ld be a pointer to the TCP-AO discussions currently going on in the WG. Wha= t do you think of that as a way forward? I have no idea what discussions are going on, but once more, if you are concerned about "heaviness" of documentation, pointing at ongoing discussions does not strike me as a route to lightness. From nobody Wed Jul 9 09:17:04 2014 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 27FF01A040B; Wed, 9 Jul 2014 09:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 ZFBv0P0um-S6; Wed, 9 Jul 2014 09:16:58 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 97DFD1A009E; Wed, 9 Jul 2014 09:16:57 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 09 Jul 2014 09:16:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,632,1400050800"; d="scan'208";a="455025778" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by azsmga001.ch.intel.com with ESMTP; 09 Jul 2014 09:16:52 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 9 Jul 2014 09:16:52 -0700 Received: from fmsmsx105.amr.corp.intel.com ([169.254.5.225]) by FMSMSX102.amr.corp.intel.com ([169.254.2.147]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 09:16:51 -0700 From: "Koodli, Rajeev" To: Leif Johansson , "Joseph Salowey (jsalowey)" Thread-Topic: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes Thread-Index: AQHPmtBxgT3VMa/gaUKZ1gsnr5fLR5uWv+aAgADh04CAAAxjgIAAPqeA Date: Wed, 9 Jul 2014 16:16:51 +0000 Message-ID: References: <53BA57E3.8080300@sunet.se> <53BBF2A5.10506@sunet.se> <298C55D6-7F96-4BB5-9313-BA02A2B4D2F2@cisco.com> <53BC2779.70506@sunet.se> <3C10F572-C486-4D3D-8BFF-AB5507831B24@cisco.com> <616EA2AC-8CF2-4014-88F8-E1560BB268F4@sunet.se> In-Reply-To: <616EA2AC-8CF2-4014-88F8-E1560BB268F4@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.71.165] Content-Type: text/plain; charset="euc-kr" Content-ID: <9591FF21F4D02B4BB3C02482AD7516C6@intel.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/zajDHJtsXiu3Y2rylReKoxJ2iYA Cc: "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes 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, 09 Jul 2014 16:16:59 -0000 DQpGaW5lIHdpdGggbWUuDQoNClRoYW5rcy4NCg0KLVJhamVldg0KDQoNCk9uIDcvOC8xNCwgMTA6 MzIgUE0sICJMZWlmIEpvaGFuc3NvbiIgPGxlaWZqQHN1bmV0LnNlPiB3cm90ZToNCg0KPg0KPg0K Pj4gOSBqdWwgMjAxNCBrbC4gMDY6NDggc2tyZXYgIkpvc2VwaCBTYWxvd2V5IChqc2Fsb3dleSki DQo+Pjxqc2Fsb3dleUBjaXNjby5jb20+Og0KPj4gDQo+PiANCj4+PiBPbiBKdWwgOCwgMjAxNCwg YXQgMzoyMCBQTSwgS29vZGxpLCBSYWplZXYgPHJhamVldi5rb29kbGlAaW50ZWwuY29tPg0KPj4+ d3JvdGU6DQo+Pj4gDQo+Pj4gDQo+Pj4gUkZDIDQxODc6DQo+Pj4gDQo+Pj4gIjguMiBQcm90b2Nv bCBFeHRlbnNpYmlsaXR5DQo+Pj4gDQo+Pj4gIEVBUC1BS0EgY2FuIGJlIGV4dGVuZGVkIGJ5IHNw ZWNpZnlpbmcgbmV3IGF0dHJpYnV0ZSB0eXBlcy4gIElmDQo+Pj4gIHNraXBwYWJsZSBhdHRyaWJ1 dGVzIGFyZSB1c2VkLCBpdCBpcyBwb3NzaWJsZSB0byBleHRlbmQgdGhlIHByb3RvY29sDQo+Pj4g IHdpdGhvdXQgYnJlYWtpbmcgb2xkIGltcGxlbWVudGF0aW9ucy4gIEFzIHNwZWNpZmllZCBpbiBT ZWN0aW9uIDEwLjEzLA0KPj4+ICBpZiBuZXcgYXR0cmlidXRlcyBhcmUgc3BlY2lmaWVkIGZvciBF QVAtUmVxdWVzdC9BS0EtSWRlbnRpdHkgb3INCj4+PiAgRUFQLVJlc3BvbnNlL0FLQS1JZGVudGl0 eSwgdGhlbiB0aGUgQVRfQ0hFQ0tDT0RFIE1VU1QgYmUgdXNlZCB0bw0KPj4+ICBpbnRlZ3JpdHkg cHJvdGVjdCB0aGUgbmV3IGF0dHJpYnV0ZXMuqfcNCj4+IA0KPj4gW0pvZV0gIE1ha2VzIHNlbnNl LiAgQWx0aG91Z2ggaXQgaXMgcmVkdW5kYW50IHdpdGggUkZDNDE4NywgSXQgbWlnaHQgYmUNCj4+ d29ydGggbWVudGlvbmluZyBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0 aGF0DQo+PkFUX0NIRUNLQ09ERSBwcm90ZWN0cyB0aGUgYXR0cmlidXRlcyBpbiB0aGUgRUFQL0FL QS1JZGVudGl0eSBtZXNzYWdlcw0KPj5vbmNlIGl0IGhhcyBiZSB2ZXJpZmllZCBieSBhIHZhbGlk IEFUX01BQy4gICBUaGlzIHdvdWxkIGhlbHAgY2xhcmlmeQ0KPj50aGF0IHRoZSBhdHRyaWJ1dGVz IGFyZSBwcm90ZWN0ZWQgYW5kIGF0IHdoYXQgcG9pbnQgdGhleSBhcmUNCj4+YXV0aGVudGljYXRl ZC4gIEl0IG1pZ2h0IGFsc28gaGVscCByZW1pbmQgaW1wbGVtZW50ZXJzIHRoYXQgdGhleSBuZWVk IHRvDQo+PmltcGxlbWVudCBBVF9DSEVDS0NPREUuDQo+DQo+YWdyZWUhDQo+DQo+PiANCj4+PiAN Cj4+PiBTbywgdGhpcyBhcHBsaWVzIGZvciB0aGUgYXR0cmlidXRlIGluIHF1ZXN0aW9uLg0KPj4+ IA0KPj4+IC1SYWplZXYNCj4+PiANCj4+PiANCj4+PiANCj4+Pj4gT24gNy84LzE0LCAxMDoxNiBB TSwgIkxlaWYgSm9oYW5zc29uIiA8bGVpZmpAc3VuZXQuc2U+IHdyb3RlOg0KPj4+PiANCj4+Pj4g DQo+Pj4+PiANCj4+Pj4+IFtKb2VdIElzIHRoZSBhdHRyaWJ1dGUgaW4gcXVlc3Rpb24gcHJvdGVj dGVkIGJ5IEFUX01BQz8gIElmIG5vdCwgaXRzDQo+Pj4+PiBwb3NzaWJsZSB0aGF0IGl0IGNvdWxk IGJlIG1vZGlmaWVkIGluIHRyYW5zaXQuDQo+Pj4+IA0KPj4+PiB5ZWFoIHdoYXQgSm9lIHNhaWQN Cj4+IA0KDQo= From nobody Wed Jul 9 22:42:28 2014 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 983651B279C; Wed, 9 Jul 2014 22:42:25 -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 1lcEe4QYU2d9; Wed, 9 Jul 2014 22:42:23 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CFD1B2797; Wed, 9 Jul 2014 22:42:23 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so5615584lan.26 for ; Wed, 09 Jul 2014 22:42:21 -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:cc:content-type; bh=A1rYxhZuOjGoUM63GmOlGYo2iXhof+hazkiTuvKiKMc=; b=Zk8a+YUHIHIM+zO7cktO2xtk/Gq1MN5RIE8/dLaQYjZkT+8CgeaLJsCjmzDmBPpHOC fuhozARd73onWqqZ39kswxLM0iL0OTsMItIQgh8ZBtKDhCwozlYjw7DYpIcVAw6SdtpO 4yLDqp6MlmbYVvv5s67/VElP27Ugqi6O3VKhkTEJLfHMZRD91NZO1LHtluIGZXAdXI+e rHkGabXUD7sG6f5FApFRpTBLRv6HWrmCAicKJZ/OWTd7FKD4UhqmWBJfbwfBuz6NSaVK J94xWRVXfs0gdm05FnoH3Orl3dqLQxFy+fEM4UcZIRgeOKBHGv8rkrkQ4BGeKOl39BLp G0Mg== MIME-Version: 1.0 X-Received: by 10.112.142.33 with SMTP id rt1mr1721189lbb.45.1404970941636; Wed, 09 Jul 2014 22:42:21 -0700 (PDT) Received: by 10.112.50.49 with HTTP; Wed, 9 Jul 2014 22:42:21 -0700 (PDT) Date: Wed, 9 Jul 2014 22:42:21 -0700 Message-ID: From: Radia Perlman To: "secdir@ietf.org" Content-Type: multipart/alternative; boundary=001a11c36b72e565a004fdd049bb Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Htae4R8tf4rjNMsnk3NGldvA228 Cc: draft-ietf-ppsp-survey.all@tools.ietf.org, The IESG Subject: [secdir] secdir review of draft-ietf-ppsp-survey-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: Thu, 10 Jul 2014 05:42:25 -0000 --001a11c36b72e565a004fdd049bb Content-Type: text/plain; charset=UTF-8 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. This document minimally documents and functionally compares eight different deployed peer-to-peer streaming applications targeting video distribution. The security considerations section describes how the various protocols are secured and compares the security guarantees. I applaud the publication of such documents, since it allows someone new to the field to quickly get a feel for how the protocols compare and it includes in references where to get detailed information about each one. I think it is even very useful for people who are not new to the field, since it is easy to miss the broader conceptual comparison of various protocols when getting lost in the weeds of the bits and bytes details. It is also great to see comparisons. It would be good if there were more such =E2=80=9Csurvey documents=E2=80=9D available in different areas. The docume= nt is well written and =E2=80=93 assuming it is accurate (I have no way of knowing) ma= kes a real contribution to this space. Radia --001a11c36b72e565a004fdd049bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

=C2=A0

This = document minimally documents and functionally compares eight different depl= oyed peer-to-peer streaming applications targeting video distribution. The = security considerations section describes how the various protocols are sec= ured and compares the security guarantees.

=C2=A0

I a= pplaud the publication of such documents, since it allows someone new to th= e field to quickly get a feel for how the protocols compare and it includes= in references where to get detailed information about each one.
=C2=A0
I think it is= even very useful for people who are not=C2=A0new to the field, since it is= easy to miss the broader conceptual comparison of various protocols when g= etting lost in the weeds of the bits and bytes details. It is also=C2=A0gre= at to see comparisons.=C2=A0It would be good if there were more such =E2=80= =9Csurvey documents=E2=80=9D available in different areas. The document is = well written and =E2=80=93 assuming it is accurate (I have no way of knowin= g) makes a real contribution to this space.
=C2=A0
Radia
--001a11c36b72e565a004fdd049bb-- From nobody Thu Jul 10 02:20:08 2014 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 8C1261B27D8 for ; Thu, 10 Jul 2014 02:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] 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 gF17VqZdyJ79 for ; Thu, 10 Jul 2014 02:20: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 0D8161A03B9 for ; Thu, 10 Jul 2014 02:20:04 -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 s6A9K0dN021662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Jul 2014 12:20:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6A9K0mX027447; Thu, 10 Jul 2014 12:20:00 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21438.23232.630040.974501@fireball.kivinen.iki.fi> Date: Thu, 10 Jul 2014 12:20:00 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hpnoe8aLrWDPJT4eQ_f6mqzzeDg 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, 10 Jul 2014 09:20:07 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sam Weiler is next in the rotation. For telechat 2014-07-10 Reviewer LC end Draft Jeffrey Hutzelman T 2014-06-20 draft-ietf-mmusic-rtsp-nat-21 Russ Mundy T 2014-07-03 draft-ietf-sidr-cps-04 Sandy Murphy T 2014-07-04 draft-ietf-stir-threats-03 Ondrej Sury T 2014-05-28 draft-ietf-ipfix-text-adt-06 For telechat 2014-08-07 Melinda Shore T 2014-08-01 draft-ietf-websec-key-pinning-19 Sean Turner T 2014-07-17 draft-ietf-appsawg-nullmx-05 Carl Wallace T 2014-08-05 draft-ietf-isis-tlv-codepoints-00 Last calls and special requests: Shawn Emery R2014-07-16 draft-ietf-tictoc-security-requirements-10 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Sam Hartman 2014-06-23 draft-ietf-dnsop-child-syncronization-02 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Warren Kumari 2014-07-02 draft-ietf-netext-pmip-cp-up-separation-05 Alexey Melnikov 2014-07-04 draft-ietf-p2psip-service-discovery-13 Eric Osterweil 2014-07-15 draft-ietf-l2vpn-etree-frwk-06 Vincent Roca 2014-07-14 draft-ietf-trill-active-active-connection-prob-05 Joe Salowey 2014-07-21 draft-ietf-trill-loss-delay-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Zach Shelby 2014-07-21 draft-ietf-trill-oam-fm-06 Ondrej Sury 2014-07-15 draft-kivinen-ipsecme-signature-auth-06 Takeshi Takahashi 2014-08-05 draft-dukhovni-opportunistic-security-01 Tina TSOU 2014-07-21 draft-ietf-appsawg-multimailbox-search-01 David Waltermire 2014-08-04 draft-masotta-tftpexts-windowsize-opt-10 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Jul 10 04:16:09 2014 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 27DAF1B2884; Thu, 10 Jul 2014 04:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 YHzt9Nw_XdYE; Thu, 10 Jul 2014 04:11:38 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4861B287F; Thu, 10 Jul 2014 04:11:37 -0700 (PDT) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 10 Jul 2014 13:11:38 +0200 Received: from [145.100.100.60] (130.37.253.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 10 Jul 2014 13:11:35 +0200 Message-ID: <53BE74F0.6080908@cs.vu.nl> Date: Thu, 10 Jul 2014 13:11:44 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Harrington , "iesg@ietf.org IESG" , , References: <78982690-9233-4763-9FA2-0904BD683BBF@comcast.net> In-Reply-To: <78982690-9233-4763-9FA2-0904BD683BBF@comcast.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [130.37.253.20] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/VpKpEUiEebrIddxFC47rxHqWPYU X-Mailman-Approved-At: Thu, 10 Jul 2014 04:16:06 -0700 Subject: Re: [secdir] secdir review of draft-ietf-ppsp-peer-protocol X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: arno@cs.vu.nl List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 11:11:44 -0000 Hello David and SecDir thanks for your review. Please see our responses inline. To focus the discussion, we would like to respond to the editorial issues later. On 30/06/2014 22:56, David Harrington wrote: > > I will say that, being both an opsdir and secdir reviewer, I was > greatly encouraged by the table of contents, which shows that a lot > of consideration was given to security and ops and mgmt. But then I > started reading the text in the main part of the document, and was > severely disappointed by what I found. I chose to sample sections of > the document to see if maybe it was just the opening text that was > problematic. I don’t think so. > Would you be willing to help us with a full review to remove the ambiguities you observe? > 6) tech: I feel uncomfortable with section 2 containing examples that > describe the overall flow. Examples are non-normative text, usually > contained in a non-normative appendix. These examples describe the > order of messages, and it is > (Some text appears to be lost here.) We want to give the reader an impression of the operation of the protocol before providing the details. Is there any acceptable way to do this without resorting to an appendix? > 7) in example 2.2, the integrity hash is provided by the peer that is > providing the (potentially maliciously modified) content. Isn’t that > like asking the fox to verify that the henhouse is safe? > No. The hashes provided by untrusted peers can be verified against the trusted swarm ID, by virtue of the Merkle hash tree used, as explained in Section 5 and 6. > 9) in 3, paragraph 1, it says “this behavior”, but I’m not sure which > behavior it is referencing. It is unclear whether not sending error > messages, or discarding messages, or stopping communication, or > classifying peers is the behavior that allows a peer to deal with > slow, crashed, or silent peers. I don’t understand HOW any of the > behaviors mentioned would allow a peer to deal with slow, crashed, or > silent peers. I do not understand on what basis peers are judged > “good” or “bad”. > A peer that responds with chunks is classified as good, a peer that does not respond, or does not respond in time is classified as bad, as it does not help the requester progress. The idea is that in a peer-to-peer system the content is available from multiple sources (unlike HTTP), so a peer should not invest too much effort in trying to obtain it from one particular one. > 10) in 3, paragraph 2, it says, "Multiple messages are multiplexed > into a single datagram for > > transmission. Messages in a single datagram MUST be processed in > the strict order in which they appear in the datagram.” While this > might be true for UDP, is this also accurate for TCP or other > non-datagram transports? > This version of the protocol describes just an UDP encapsulation. If in the future, TCP would be enabled as a transport, the TCP encapsulation will address this. > 11) in 3, paragraph 3, the second sentence seems to contradict the > first sentence, and since neither is written using RFC2119 keywords, > it seems to really leave the whole question open to implementer > interpretation. > Perhaps we should rephrase this. We do not prescribe the container format for the audio/video content, so a content publisher can choose to use a format that contains multiple assets, or versions of an asset. A higher-level layer with knowledge of this format should then instruct the peer protocol on which chunks to download when. > “ I find “MUST use UDP” inconsistent with “”can also run over other > transport protocols”, and “MUST use LEDBAT” inconsistent with “or > use different congestion control protocols”. > The peer protocol was designed with multiple transports in mind. At this point in time we only define one mapping/encapsulation: UDP. This may be us not knowing how to convey this multi-protocol intent right. Can you propose alternative phrasing? > [jumping ahead …] In 8.3, there is a discussion of multiple swarms > sharing a UDP port. I’m unsure whether this would work, but since UDP > is stateless, it might. Do channels work for protocols like TCP? > It does (cf. the two implementations that exist and are in use). The concept of channels as a way of multiplexing communication over a single port also has benefit for TCP. It allows you to maximize the usefulness of the existing TCP connection that may have been complex to set up in a NAT environment. > "A SIGNED_INTEGRITY message (type 0x07) consists of a chunk > specification, a 64-bit NTP timestamp [RFC5905] and a digital > signature encoded as a Signature field in a RRSIG record in DNSSEC > without the BASE-64 encoding [RFC4034].” > > Can this work in an implementation with no NTP support? > Yes, we are just using the NTP format. We can change the phrasing to make that more clear. > 8.14 describes a keep alive message format, but no processing > instructions. > > Are receiving implementations required to do anything with this > message? are they supposed to respond somehow? > No, they are not. More people have remarked on this, we will make it more clear. > How does the sender of a keep alive determine that the connection is > still live? > By monitoring the incoming traffic from its peer, as per Section 8.15. > There is no message type for keep alive. If the first octet of the > keep alive happens to be 0x0a, how does the receiver know whether > this is a keep alive or a CHOKE message? > Keep alives "are just simple datagrams consisting of the 4-byte channel ID of the destination only." (Sec. 8.14). By definition, they are only sent when there are no other messages to send (Sec. 3.12) > I think this document would be well served by describing the message > types and formats and their processing in a transport-neutral manner, > and then describing the transport-specific mapping details, so it is > clear and unambiguous how the mapping of message sequences to > datagrams is handled for UDP and DCCP, and how the mapping of message > sequences should be handled for stream-based protocols like TCP. > There are some message types, notably keep alive, that I am not sure > apply in the same way to different transports. > That has been our intention by describing the messages in abstract in Section 3 and providing a section on how they are mapped to UDP in Section 8. But apparently this is not clear? What are you missing to put you on the right foot? > Multiple messages are multiplexed in a datagram. How are the messages > delimited? If there is any corruption in one message, how does the > receiver find the end of the message and the start of the next > message? If I understand correctly, invalid messages are discarded > and no error code is sent. If one of the messages are found to be > invalid, are all messages in that datagram discarded? or are all > subsequent messages in that datagram discarded? or is it valid to > process the remaining messages in the datagram after an invalid > message is detected? If so, would that conflict with the rule that > all messages must be processed in order? > Messages are fixed size, or contain size fields. The phrase "Invalid messages are discarded, and further communication with the peer SHOULD be stopped." is supposed to imply that a datagram is discarded as soon as one offending message is found in it. We will make this more clear. Regards, Arno Bakker et al. From nobody Thu Jul 10 08:55:36 2014 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 6AE061A0385; Thu, 10 Jul 2014 08:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 vsQ7RfaOtJhf; Thu, 10 Jul 2014 08:55:31 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB471A010D; Thu, 10 Jul 2014 08:55:30 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6AFtRIr023142; Thu, 10 Jul 2014 16:55:27 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6AFtP0C023084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jul 2014 16:55:25 +0100 From: "Adrian Farrel" To: "'Hannes Tschofenig'" , "'Ben Laurie'" , "'IETF Discussion List'" , References: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> <53BD05DF.7080709@gmx.net> In-Reply-To: <53BD05DF.7080709@gmx.net> Date: Thu, 10 Jul 2014 16:55:27 +0100 Message-ID: <0cbd01cf9c57$5f570520$1e050f60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4uJ9KXH6Wajq6HAA2wc6J8Axr9gJ/ZfD4AZgXldmbJoAA0A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20810.000 X-TM-AS-Result: No--20.513-10.0-31-10 X-imss-scan-details: No--20.513-10.0-31-10 X-TMASE-MatchedRID: L8tZF6zWW2rZeYBBoew7ALFNas5NPrTanaU0BOrP3M/F7duWDXiFErCx 9OEvXmLWxbiM85UWHqDqUmpMo8B4izPAnsAORqSfvHKClHGjjr1TqCCOtYNzZtp1biJhIyNRp7u eaEkDqTPmzWi0ELzEedxrFItJ4VaVHodpx3o6GrvXIwmz2YEJxYyzstdwoG+PnvbaEOoeixObJx j/y/77pNePBxJDl9ljSCqwxKAlXmr2De4YrmWQbqMVgdN9w+TCLn/JO5jDOiWbKItl61J/ycnjL TA/UDoApPKClyoUSzyNo+PRbWqfRJBlLa6MK1y4 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yaenmelK0YrI29NkKx6SDraeOAA Cc: iesg@ietf.org Subject: Re: [secdir] Security review of draft-ietf-pce-questions-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:55:33 -0000 Hannes, You can say what you like, but I would appreciate not being misquoted on serious matters even in jest. Yes, you cut from my email correctly. Then you entirely missed the point and reworded differently. That is neither helpful nor constructive. Doing so in a sarcastic or caustic manner is not good for the atmosphere on this list. >From time to time people complain to me (as AD, I'm an author for this document) about the tone on this list and the way it harms participation of newcomers. Please don't put yourself into that category. Adrian > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: 09 July 2014 10:06 > To: adrian@olddog.co.uk; 'Ben Laurie'; 'IETF Discussion List'; secdir@ietf.org > Cc: iesg@ietf.org > Subject: Re: [secdir] Security review of draft-ietf-pce-questions-06 > > > > On 07/09/2014 10:55 AM, Adrian Farrel wrote: > > I would be pretty loathe to add security text to each section in this document: I > think that would make the document heavy and less likely to be read by its > intended consumers > > I like that one. > > I think I will quote you in the future as someone who had said > > "Adding security text to a specification makes the document heavy and > less likely to be read by its intended consumers." > > Ciao > Hannes From nobody Thu Jul 10 08:58:58 2014 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 0A74C1A0653; Thu, 10 Jul 2014 08:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 EefnNnmwpkAz; Thu, 10 Jul 2014 08:58:47 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9310A1A0601; Thu, 10 Jul 2014 08:58:47 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6AFwNcO029251; Thu, 10 Jul 2014 16:58:23 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6AFwKlx029237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jul 2014 16:58:21 +0100 From: "Adrian Farrel" To: "'Ben Laurie'" , References: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> In-Reply-To: Date: Thu, 10 Jul 2014 16:58:23 +0100 Message-ID: <0cc101cf9c57$c8706290$595127b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4uJ9KXH6Wajq6HAA2wc6J8Axr9gJ/ZfD4Aiae7QabIg1WwA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20810.000 X-TM-AS-Result: No--25.609-10.0-31-10 X-imss-scan-details: No--25.609-10.0-31-10 X-TMASE-MatchedRID: rYpa/RC+czH+rCF+A3NH6WzBijri5+RV1kqyrcMalqVcKZwALwMGs49/ 6wlLhvp43FAeMcQT06IQFC2M7Gafii5hcDOdPMLoSEQN/D/3cG5BrawMcuRDTtnu97SXKBPYmIX 3Wgl6rhJbHAuWwt+omPFPDHhQkgxy3ePzweGh0Y0pa6LJktEjgBmyTBaqiJvcipSe9U1/foO5p6 xgf5MBjIrDTlvpMEO+lJAE8IIWUIETRGXFaPaaz2gws6g0ewz2u2rcU2ygxCAlqzvkoGQh5mtUy gsbhDwBpqhkLR9s7v1U19puFD6wgWwZCxj8Vzu7KhQHv3RCSer+rFFXesuqjdJgDNnoqapaggnZ d3SBgl/YOJK6UUeDpl1ruMLZOzrlv6BXK4P/i1an1yJegn+la4UGhajERJYJnit3Tv6ke8CNiJg dHjlC55lz2oMcDp6D5HVzqUQQrYmp4uKKROpzg+lvTv6LG/B52O0N82YJflogUEQTkIWiYg0PSg 88IRzDGutEucmkxKe/3bl9KYAY0xs98PuvpWvFRqd7O4ywqbt9LQinZ4QefNQdB5NUNSsi1GcRA JRT6POOhzOa6g8KrZRMZUCEHkRt Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/B9N-rfyeL10TrFJCkup0D49vMiA Cc: 'The IESG' , 'IETF Discussion List' , secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-pce-questions-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:58:51 -0000 Hi Ben, So you don't like my proposed solution? I am not quite sure what you do consider a resolution to your concern. I = can see three options: 1. Add security-related text to each section of this document. 2. Beef up the Security Considerations section with a subsection related = to each section of the document. 3. Add a new section "How Secure is my PCE-Enabled System?" as I = suggested. Do you have a preference among these, or is there another option you = like better? Thanks, Adrian > -----Original Message----- > From: Ben Laurie [mailto:benl@google.com] > Sent: 09 July 2014 15:04 > To: adrian@olddog.co.uk > Cc: IETF Discussion List; secdir@ietf.org; The IESG > Subject: Re: Security review of draft-ietf-pce-questions-06 >=20 > On 9 July 2014 09:55, Adrian Farrel wrote: > > Hi Ben, > > > > Thanks for taking the time to review this document and for posting = your > comments to the IETF discussion list so that we can consider them as = last call > comments. > > > > [snip] > > > >> The security considerations section makes this claim: > >> > >> "This informational document does not define any new protocol = elements > >> or mechanism. As such, it does not introduce any new security > >> issues." > >> > >> I agree with the premise, but not the conclusion: just because an = RFC > >> does not introduce new security issues, that does not mean that = there > >> are no security considerations. > >> > >> Indeed, this RFC discusses many things that have quite serious > >> security considerations, without mentioning any of them. For = example, > >> section 4 "How Do I Find My PCE?" (the very first question) = advocates > >> a number of potentially completely insecure mechanisms with no = mention > >> of their security properties (or otherwise). This is obviously > >> pervasive, given the stance taken in the security considerations. > >> > >> The document does mention that RFC 6952 gives a security analysis = for > >> PCEP, and perhaps this is sufficient but it seems to me that a > >> document intended to give useful background information to noobs > >> should include security directly in that information rather than = defer > >> to another giant document (which mixes PCEP info with other > >> protocols). > > > > I don't believe that this document is strong on "advocacy", but = discusses which > tools are out there and what some people do. > > > > Previous PCE RFCs have given some attention to security concerns in = the use of > PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088. RFC 5089), and the = PCEP (RFC > 4657 and RFC 5440). As such, "PCE Security" was not deemed by the = authors to be > a previously "unanswered question" and so did not need attention in = this > document. > > > > That said, you are correct that the various sections do not discuss = the security > implications relating to those sections. I would be pretty loathe to = add security > text to each section in this document: I think that would make the = document > heavy and less likely to be read by its intended consumers (it is not = targeting > "noobs" although they are welcome to read it). >=20 > Your position appears to be that they will then go on to read much > heavier documents in order to discover the security properties of the > solutions you suggest, which seems a little unlikely, particularly if > there's no mention of the necessity to do so. >=20 > Or perhaps you think security is not important? >=20 > > Perhaps a solution to this *is* to treat Security as an unanswered = question and > add a section "How Secure is my PCE-Enabled System?" I can't think of = a lot to > add there except for general egg-sucking guidance, but there would be = a pointer > to the TCP-AO discussions currently going on in the WG. What do you = think of > that as a way forward? >=20 > I have no idea what discussions are going on, but once more, if you > are concerned about "heaviness" of documentation, pointing at ongoing > discussions does not strike me as a route to lightness. From nobody Thu Jul 10 09:02:18 2014 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 C8C1B1A0601 for ; Thu, 10 Jul 2014 09:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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, RP_MATCHES_RCVD=-0.651, 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 pc1qvNuOU0dg for ; Thu, 10 Jul 2014 09:02:12 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CFA1A0653 for ; Thu, 10 Jul 2014 09:02:12 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id r5so8018109qcx.39 for ; Thu, 10 Jul 2014 09:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y3pXtWv0/nIdgO6DBLWFk+5rs6ueYyqUz3jNEAwoASk=; b=oZhNCwNTwYE+q0fzySUtQIZ2ptjySaYnkVHZey3s2m3BdAH67P8j5lCEg4104Ac3sh l6AgQLwhgyXh7JhliK2vGqN7JJDa8rFezCOMPOhhVhF3LvjPfPyd/vCAPBk/m5d4KdUU YoEKnA+m44hpIDqHqFIwuFeMFWL34T/wDLA0dvzPl+SefUYrhhSMOvk3+jwol7IubIP7 X04HHtrQfpH35rGh9nLD6IWMwKMQXE3SFWjRjbtvMMXkt7oDQq9YI/gjWnVAcQ7rUtdH rhAedYHFZN0KuZOCVdtGU6Kg1Lv/vsOzsziW9nyPdqx/ZH4IUhYbWrIb62B7CVRpQC9N ywjw== 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=y3pXtWv0/nIdgO6DBLWFk+5rs6ueYyqUz3jNEAwoASk=; b=gP6suaaBSaPNAV7/pztYbuxkhfoEXyejinBC5+dq1gE4e8JFLwRXrbztDOy9HU9Cm2 2YkuMymeJaBWdhmSsIvL6SfABNmgHJ3kvE+bsnxhR4SNHU6VnsjRv/zknY+ZfCpRR6Re IB9KMdeMZw+KhsHT6BbavLJ41jhp7SkuTsudo/FFmJsaXEqpWM3rAgnaDvOeT4NNDb13 WWoYaopzKYalqIOEda8P5zNGN/BAWglEFvYExvEonKuo+NFzCmHLOgfpbvc4e8f2l/eN Fhu7Dpn8jks/FTmYJUJQBTn8nm3pawnYqqjEQHNTJzwVZDbK2TeMs5oRqKSWEiJ5sOhx RD8w== X-Gm-Message-State: ALoCoQnWG39KlwcQS9KmN3Uwv7Zp4LuNz3prQd3aBe2W2Pd2L3UyBDJ3JQyIgr8xkxBDBZd4AZ6c MIME-Version: 1.0 X-Received: by 10.140.82.113 with SMTP id g104mr79541653qgd.55.1405008131679; Thu, 10 Jul 2014 09:02:11 -0700 (PDT) Received: by 10.229.162.15 with HTTP; Thu, 10 Jul 2014 09:02:11 -0700 (PDT) In-Reply-To: <0cc101cf9c57$c8706290$595127b0$@olddog.co.uk> References: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> <0cc101cf9c57$c8706290$595127b0$@olddog.co.uk> Date: Thu, 10 Jul 2014 17:02:11 +0100 Message-ID: From: Ben Laurie To: adrian@olddog.co.uk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MVaopqKxSW_w05rObzH6U2axYGI Cc: The IESG , IETF Discussion List , "secdir@ietf.org" Subject: Re: [secdir] Security review of draft-ietf-pce-questions-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: Thu, 10 Jul 2014 16:02:16 -0000 On 10 July 2014 16:58, Adrian Farrel wrote: > Hi Ben, > > So you don't like my proposed solution? > > I am not quite sure what you do consider a resolution to your concern. I can see three options: > > 1. Add security-related text to each section of this document. > 2. Beef up the Security Considerations section with a subsection related to each section of the document. > 3. Add a new section "How Secure is my PCE-Enabled System?" as I suggested. > > Do you have a preference among these, or is there another option you like better? I prefer 1, that way the security advice is likely to be read by whoever reads that section - that is, by the people who are likely to benefit from it. > > Thanks, > Adrian > > >> -----Original Message----- >> From: Ben Laurie [mailto:benl@google.com] >> Sent: 09 July 2014 15:04 >> To: adrian@olddog.co.uk >> Cc: IETF Discussion List; secdir@ietf.org; The IESG >> Subject: Re: Security review of draft-ietf-pce-questions-06 >> >> On 9 July 2014 09:55, Adrian Farrel wrote: >> > Hi Ben, >> > >> > Thanks for taking the time to review this document and for posting your >> comments to the IETF discussion list so that we can consider them as last call >> comments. >> > >> > [snip] >> > >> >> The security considerations section makes this claim: >> >> >> >> "This informational document does not define any new protocol elements >> >> or mechanism. As such, it does not introduce any new security >> >> issues." >> >> >> >> I agree with the premise, but not the conclusion: just because an RFC >> >> does not introduce new security issues, that does not mean that there >> >> are no security considerations. >> >> >> >> Indeed, this RFC discusses many things that have quite serious >> >> security considerations, without mentioning any of them. For example, >> >> section 4 "How Do I Find My PCE?" (the very first question) advocates >> >> a number of potentially completely insecure mechanisms with no mention >> >> of their security properties (or otherwise). This is obviously >> >> pervasive, given the stance taken in the security considerations. >> >> >> >> The document does mention that RFC 6952 gives a security analysis for >> >> PCEP, and perhaps this is sufficient but it seems to me that a >> >> document intended to give useful background information to noobs >> >> should include security directly in that information rather than defer >> >> to another giant document (which mixes PCEP info with other >> >> protocols). >> > >> > I don't believe that this document is strong on "advocacy", but discusses which >> tools are out there and what some people do. >> > >> > Previous PCE RFCs have given some attention to security concerns in the use of >> PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088. RFC 5089), and the PCEP (RFC >> 4657 and RFC 5440). As such, "PCE Security" was not deemed by the authors to be >> a previously "unanswered question" and so did not need attention in this >> document. >> > >> > That said, you are correct that the various sections do not discuss the security >> implications relating to those sections. I would be pretty loathe to add security >> text to each section in this document: I think that would make the document >> heavy and less likely to be read by its intended consumers (it is not targeting >> "noobs" although they are welcome to read it). >> >> Your position appears to be that they will then go on to read much >> heavier documents in order to discover the security properties of the >> solutions you suggest, which seems a little unlikely, particularly if >> there's no mention of the necessity to do so. >> >> Or perhaps you think security is not important? >> >> > Perhaps a solution to this *is* to treat Security as an unanswered question and >> add a section "How Secure is my PCE-Enabled System?" I can't think of a lot to >> add there except for general egg-sucking guidance, but there would be a pointer >> to the TCP-AO discussions currently going on in the WG. What do you think of >> that as a way forward? >> >> I have no idea what discussions are going on, but once more, if you >> are concerned about "heaviness" of documentation, pointing at ongoing >> discussions does not strike me as a route to lightness. > From nobody Thu Jul 10 09:21:14 2014 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 342751A0ABA; Thu, 10 Jul 2014 09:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 9Asl9VdYMbT1; Thu, 10 Jul 2014 09:21:08 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC251A0AAC; Thu, 10 Jul 2014 09:21:07 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6AGL5CU013255; Thu, 10 Jul 2014 17:21:05 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6AGL3wv013237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jul 2014 17:21:04 +0100 From: "Adrian Farrel" To: "'Ben Laurie'" References: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> <0cc101cf9c57$c8706290$595127b0$@olddog.co.uk> In-Reply-To: Date: Thu, 10 Jul 2014 17:21:06 +0100 Message-ID: <0cd601cf9c5a$f44424d0$dccc6e70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4uJ9KXH6Wajq6HAA2wc6J8Axr9gJ/ZfD4Aiae7QYBwMxQOAHFIfgBmwXk4TA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20810.000 X-TM-AS-Result: No--28.071-10.0-31-10 X-imss-scan-details: No--28.071-10.0-31-10 X-TMASE-MatchedRID: ZFzIhWOuIzunykMun0J1wpYsKSXWWrsHPj366R4tj3XadW4iYSMjUae7 nmhJA6kzFAnBoo0Pp7WnVOsT1h4vuE/duQ27+ZC8JrUxoq6hvw9+Mk6ACsw4JsbKqwGV3sczoCy y4pUARDfIszd8hbsSk15jMjt/ssG1C2s6EMq6ZtICNMj/7qB/gzZ/CJoFmAP8WltirZ/iPP5nUd ymW7X2SBqP7ooyOJMoJRg3YNJWWclQswgj0HOv3IlmrWVDo+jrIn5jqTs5ZsOynk7TnYzMulFOY nWOPByHcWhCjuUHQ73Ook4C+bdGpiU7cVZWimBbvGTc5oROod4wzcMmTIyMCg/lQ3BSNJwUiaVw q6xoriErQWrFYasPNDnxJLckdnJtzB1CJ6qmdNoj2wh8RSKcGPZpw431D6ue2Fq6de/aaIal9B9 6i8GPKNePBxJDl9ljlzl0kfrFbqFKvovRq1s4LJCYtcHXhxbaOL9BEHibhshFrqj9UzH9x6I2Wn OddDR+RVbSSCWAdDuPF2gkgF535cA1NzRSkHsOjWe5HOFKvuMW40XiUkbrG78DZBgldq9Oo8WMk QWv6iWhMIDkR/KfwI2j49Ftap9EkGUtrowrXLg= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/mPaw_KvRthrM637G3djLli-HnQ8 Cc: 'The IESG' , 'IETF Discussion List' , secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-pce-questions-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 16:21:10 -0000 OK, thanks, that's clear what you'd like. Not sure I like the approach, but I now have something to chew on. I'll = get back to you. A > -----Original Message----- > From: Ben Laurie [mailto:benl@google.com] > Sent: 10 July 2014 17:02 > To: adrian@olddog.co.uk > Cc: IETF Discussion List; secdir@ietf.org; The IESG > Subject: Re: Security review of draft-ietf-pce-questions-06 >=20 > On 10 July 2014 16:58, Adrian Farrel wrote: > > Hi Ben, > > > > So you don't like my proposed solution? > > > > I am not quite sure what you do consider a resolution to your = concern. I can see > three options: > > > > 1. Add security-related text to each section of this document. > > 2. Beef up the Security Considerations section with a subsection = related to each > section of the document. > > 3. Add a new section "How Secure is my PCE-Enabled System?" as I = suggested. > > > > Do you have a preference among these, or is there another option you = like > better? >=20 > I prefer 1, that way the security advice is likely to be read by > whoever reads that section - that is, by the people who are likely to > benefit from it. >=20 > > > > Thanks, > > Adrian > > > > > >> -----Original Message----- > >> From: Ben Laurie [mailto:benl@google.com] > >> Sent: 09 July 2014 15:04 > >> To: adrian@olddog.co.uk > >> Cc: IETF Discussion List; secdir@ietf.org; The IESG > >> Subject: Re: Security review of draft-ietf-pce-questions-06 > >> > >> On 9 July 2014 09:55, Adrian Farrel wrote: > >> > Hi Ben, > >> > > >> > Thanks for taking the time to review this document and for = posting your > >> comments to the IETF discussion list so that we can consider them = as last call > >> comments. > >> > > >> > [snip] > >> > > >> >> The security considerations section makes this claim: > >> >> > >> >> "This informational document does not define any new protocol = elements > >> >> or mechanism. As such, it does not introduce any new security > >> >> issues." > >> >> > >> >> I agree with the premise, but not the conclusion: just because = an RFC > >> >> does not introduce new security issues, that does not mean that = there > >> >> are no security considerations. > >> >> > >> >> Indeed, this RFC discusses many things that have quite serious > >> >> security considerations, without mentioning any of them. For = example, > >> >> section 4 "How Do I Find My PCE?" (the very first question) = advocates > >> >> a number of potentially completely insecure mechanisms with no = mention > >> >> of their security properties (or otherwise). This is obviously > >> >> pervasive, given the stance taken in the security = considerations. > >> >> > >> >> The document does mention that RFC 6952 gives a security = analysis for > >> >> PCEP, and perhaps this is sufficient but it seems to me that a > >> >> document intended to give useful background information to noobs > >> >> should include security directly in that information rather than = defer > >> >> to another giant document (which mixes PCEP info with other > >> >> protocols). > >> > > >> > I don't believe that this document is strong on "advocacy", but = discusses > which > >> tools are out there and what some people do. > >> > > >> > Previous PCE RFCs have given some attention to security concerns = in the use > of > >> PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088. RFC 5089), and = the PCEP > (RFC > >> 4657 and RFC 5440). As such, "PCE Security" was not deemed by the = authors to > be > >> a previously "unanswered question" and so did not need attention in = this > >> document. > >> > > >> > That said, you are correct that the various sections do not = discuss the > security > >> implications relating to those sections. I would be pretty loathe = to add security > >> text to each section in this document: I think that would make the = document > >> heavy and less likely to be read by its intended consumers (it is = not targeting > >> "noobs" although they are welcome to read it). > >> > >> Your position appears to be that they will then go on to read much > >> heavier documents in order to discover the security properties of = the > >> solutions you suggest, which seems a little unlikely, particularly = if > >> there's no mention of the necessity to do so. > >> > >> Or perhaps you think security is not important? > >> > >> > Perhaps a solution to this *is* to treat Security as an = unanswered question > and > >> add a section "How Secure is my PCE-Enabled System?" I can't think = of a lot to > >> add there except for general egg-sucking guidance, but there would = be a > pointer > >> to the TCP-AO discussions currently going on in the WG. What do you = think of > >> that as a way forward? > >> > >> I have no idea what discussions are going on, but once more, if you > >> are concerned about "heaviness" of documentation, pointing at = ongoing > >> discussions does not strike me as a route to lightness. > > From nobody Thu Jul 10 16:13:46 2014 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 DC9AF1A008B; Thu, 10 Jul 2014 16:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 4qQLP7SSIXM6; Thu, 10 Jul 2014 16:13:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3A41A0078; Thu, 10 Jul 2014 16:13:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1X5NX1-0002B6-EQ; Thu, 10 Jul 2014 23:13:40 +0000 Date: Fri, 11 Jul 2014 08:13:38 +0900 Message-ID: From: Randy Bush To: "Adam W. Montville" In-Reply-To: <468FCC23-2398-4165-BACA-E9F0AEF742E7@stoicsecurity.com> References: <468FCC23-2398-4165-BACA-E9F0AEF742E7@stoicsecurity.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8WvSIO2_RIUP-u7RgObnQXSrzjc Cc: draft-ietf-sidr-bgpsec-reqs.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-reqs-11 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, 10 Jul 2014 23:13:44 -0000 > 2. Requirement 3.13 indicates that BGPsec =E2=80=9CMUST provide backward > compatibility=E2=80=9D, but we are left to assume that downgrade preve= ntion > is enabled. We might assume that it is, but it=E2=80=99s probably bet= ter > not to. Perhaps adding a statement to the effect of =E2=80=9CMUST pro= vide > backward compatibility=E2=80=A6. but also allow for strict BGPsec > adherence=E2=80=9D or something similar. I also recognize that there = may > be obviating circumstances behind this requirement (i.e. it=E2=80=99s = not > practical to *not* allow strict adherence), which I might also > assume as a reader. i have added the following to sec cons, The requirement of backward compatibility to BGP4 may open an avenue to downgrade attacks. > 4. In the Security Considerations section (6) it seems that more > explanation pertaining to the following sentence might be > warranted: =E2=80=9CThe data plane might not follow the control plane.= =E2=80=9D > This might be readily apparent to anyone in-the-know, but it=E2=80=99s= not > so apparent to those not-in-the-know. per alia atlas The data plane might not follow the path signaled by the control plane. randy From nobody Mon Jul 14 09:46:19 2014 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 510081A0AE5; Mon, 14 Jul 2014 09:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1405356164; bh=VSUO7RQoBrG/YmSVjwYP8ulLJKboH0CjBo9MhK7qLy0=; 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=xe3O2GXJW2D+VvXInaKWuIBqQnpMIHm54jU901yO1pqJo+XbCkZf4o5XJF2R6nSsU gO6Ko910m5d9wYx1u1HmzZC+Uc71PiOsVoxNEF5KNH8IU3DlZugtekqk94a6z5Ov3C h6fSjqPEvLGZctesbegKKVqertyDh6ad8CWdHO2w= 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 09DF01A0AE9; Mon, 14 Jul 2014 09:42:36 -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] 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 IvuJxy6Bdw-9; Mon, 14 Jul 2014 09:42:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7AD1A0AE0; Mon, 14 Jul 2014 09:42:29 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140714164229.22986.76433.idtracker@ietfa.amsl.com> Date: Mon, 14 Jul 2014 09:42:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/-AhExQXNJg570CXEKVvdYfCMt88 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: http://mailarchive.ietf.org/arch/msg/secdir/sbd1j6-yeyTSB8cNpcJcRDOvF2Q X-Mailman-Approved-At: Mon, 14 Jul 2014 09:46:18 -0700 Subject: [secdir] [new-work] WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc) X-BeenThere: secdir@ietf.org Reply-To: ietf@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 16:42:44 -0000 A new IETF working group has been proposed in the Applications 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 2014-07-24. Domain-based Message Authentication, Reporting & Conformance (dmarc) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Pete Resnick Mailing list Address: dmarc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dmarc Archive: http://www.ietf.org/mail-archive/web/dmarc/ Charter: Domain-based Message Authentication, Reporting & Conformance (DMARC) uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field. DMARC uses DNS records to add policy-related requests for receivers and defines a feedback mechanism from receivers back to domain owners. This allows a domain owner to advertise that mail can safely receive differential handling, such as rejection, when the use of the domain name in the From field is not authenticated. Existing deployment of DMARC has demonstrated utility at internet scale, in dealing with significant email abuse, and has permitted simplifying some mail handling processes. The existing base specification is being submitted as an Independent Submission to become an Informational RFC. However, DMARC is problematic for mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox. Examples of such "indirect" flows are mailing lists, publish-to-friend functionality, mailbox forwarding (".forward"), and third-party services that send on behalf of clients. The working group will explore possible updates and extensions to the specifications in order to address limitations and/or add capabilities. It will also provide technical implementation guidance and review possible enhancements elsewhere in the mail handling sequence that could improve could DMARC compatibility. Specifications produced by the working group will ensure preservation of DMARC utility for detecting unauthorized use of domain names, while improving the identification of legitimate sources that do not currently conform to DMARC requirements. Issues based on operational experience and/or data aggregated from multiple sources will be given priority. The working group will seek to preserve interoperability with the installed base of DMARC systems, and provide detailed justification for any non-interoperability. As the working group develops solutions to deal with indirect mail flows, it will seek to maintain the end-to-end nature of existing identifier fields in mail, in particular avoiding solutions that require rewriting of originator fields. Working group activities will pursue three tracks: 1. Addressing the issues with indirect mail flows The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. Among the choices for addressing these issues are: - A form of DKIM signature that is better able to survive transit through intermediaries. - Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results. - Message modification by an intermediary, to avoid authentication failures, such as by using specified conventions for changing the aligned identity. Consideration also will be given to survivable authentication through sequences of multiple intermediaries. 2. Reviewing and improving the base DMARC specification The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable. The base specification relies on the ability of an email receiver to determine the organizational domain responsible for sending mail. An organizational domain is the 'base' name that is allocated from a public registry; examples of registries include ".com" or ".co.uk". While the common practice is to use a "public suffix" list to determine organizational domain, it is widely recognized that this solution will not scale, and that the current list often is inaccurate. The task of defining a standard mechanism for identifying organizational domain is out of scope for this working group. However the working group can consider extending the base DMARC specification to accommodate such a standard, should it be developed during the life of this working group. Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: - Enumeration of data elements required in "Failure" reports (specifically to address privacy issues) - Handling potential reporting abuse - Aggregate reporting to support additional reporting scenarios - Alternate reporting channels - Utility of arbitrary identifier alignment - Utility of a formalized policy exception mechanism 3. DMARC Usage The working group will document operational practices in terms of configuration, installation, monitoring, diagnosis and reporting. It will catalog currently prevailing guidelines as well as developing advice on practices that are not yet well-established but which are believed to be appropriate. The group will consider separating configuration and other deployment information that needs to be in the base spec, from information that should be in a separate guide. Among the topics anticipated to be included in the document are: - Identifier alignment configuration options - Implementation decisions regarding "pct" - Determining effective RUA sending frequency - Leveraging policy caching - Various options for integrating within an existing flow - Defining a useful, common set of options for the addresses to which feedback reports are to be sent - When and how to use local policy override options Work Items ---------- Phase I: Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them. Phase II: Specification of DMARC improvements to support indirect mail flows Draft Guide on DMARC Usage Phase III: Review and refinement of the DMARC specification Completion of Guide on DMARC Usage References ---------- DMARC - http://dmarc.org SPF - RFC7208 DKIM - RFC6376 Internet Message Format - RFC5322 OAR / Original Authentication Results - draft-kucherawy-original-authres Using DMARC - draft-crocker-dmarc-bcp-03 Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Jul 14 17:33:04 2014 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 1EF2D1B27C6; Mon, 14 Jul 2014 17:33:02 -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 SgDzC9HVS1sw; Mon, 14 Jul 2014 17:32:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198381B27B7; Mon, 14 Jul 2014 17:32:59 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0221.namprd09.prod.outlook.com (25.160.92.143) with Microsoft SMTP Server (TLS) id 15.0.985.8; Tue, 15 Jul 2014 00:32:56 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0985.008; Tue, 15 Jul 2014 00:32:56 +0000 From: "Waltermire, David A." To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-masotta-tftpexts-windowsize-opt.all@tools.ietf.org" Thread-Topic: secdir review of draft-masotta-tftpexts-windowsize-opt-10 Thread-Index: Ac+fv7NcsGmC4KKQSM2oT4Q8+MLMbA== Date: Tue, 15 Jul 2014 00:32:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.225.82] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 027367F73D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(76482001)(46102001)(99396002)(50986999)(54356999)(101416001)(229853001)(86362001)(4396001)(107886001)(2656002)(74502001)(33646002)(87936001)(74662001)(79102001)(83322001)(107046002)(77982001)(99286002)(21056001)(31966008)(95666004)(74316001)(105586002)(106356001)(83072002)(85852003)(2201001)(92566001)(81342001)(20776003)(64706001)(76576001)(77096002)(80022001)(81542001)(85306003)(66066001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0221; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/9WNvKiLKwyQPLlyBig2Fkg3mfQ0 Subject: [secdir] secdir review of draft-masotta-tftpexts-windowsize-opt-10 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, 15 Jul 2014 00:33:02 -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 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 comments. Status: Almost ready - There are a few security and other related concerns = with this draft summarized below. The draft defines a method for overriding the default step-wise acknowledge= ment (ACK) behavior of TFTP. This extension suppresses the standard step-wi= se ACK response until a negotiated window size of blocks have been sent. A = single ACK is then sent indicating that all blocks in the window were trans= mitted. This results in a general reduction in the number of ACKs over the = exchange, allowing for higher transfer rates than using block size negotiat= ion alone (RFC2348). Security Concerns: The specific security considerations statement appears to be copied from RF= C2347. It acknowledges that TFTP does not have any explicit security mechan= ism and that the extension does not add any additional security risk beyond= the base specification. Instead of copying the text from the other RFCs, t= his text should be replaced with text that references the security consider= ations from RFC1350, RFC2347, and probably RFC5405. Additionally, it seems like this option requires a state machine, involving= both the client and server, to track the exchange of blocks within a windo= w to support retransmission of failed blocks. If I am understanding this co= rrectly, it looks like a potential attack vector exists where a malicious c= lient (or server) could cause abnormal consumption of system and network re= sources through the use of large window sizes across a number of sessions. = This malicious actor would need to selectively cause retransmission of bloc= ks that still conform with max retry, timeout, and delay constraints. In pa= rt, the second paragraph (and the following example) in the "Congestion and= Error Control" section provide some error handling guidance that also addr= esses this security consideration. At minimum a discussion of this attack v= ector and a reference back to this explanation should be included in the se= curity considerations section. It would also be valuable to include some di= scussion on reasonable limits for window sizes, retry, timeout, and delay p= arameters, or at least some guidelines around determining them based on the= characteristics of the data link layer protocol used. Other concerns: In the abstract: - The abstract should mention that this memo extends RFC1350 by adding a ne= w option extension for ... based on RFC2347. In section "Windowsize Option Specification": - The text in this section should be updated to make use of RFC2119 capital= ized keywords. - A specification for the Read and Write requests is provided along with an= example. The specification of the corresponding OACK should be provided wi= th the same degree of rigor. - The draft describes the ACK behavior for data exchange in the definition = of the windowsize "#blocks" field. The actual requirements should be define= d using RFC2119 language in a new paragraph after the discussion of option = negotiation. This new text should express the actual windowing behavior req= uirements for implementations of the protocol extension. It should also mak= e explicit which block number to send in the ACK, which I infer to be the l= ast block sent in the window. General nits: There are a number of grammatical and punctuation issues throughout the doc= ument. Some of these make it more difficult to understand the document. A q= uick editorial pass through the document should address this concern. I am = happy to provide a few specifics/suggestions in this regard if the author w= ould like. Also, the nits tool reported: - An issue with 3 pages being longer than the required 58 lines per page. - The abstract contains bracketed references. See previous comment. - Whitespace warnings Regards, Dave Waltermire From nobody Mon Jul 14 17:42:28 2014 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 8B3BE1B27C5; Mon, 14 Jul 2014 17:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 4n93yt_Vc2kh; Mon, 14 Jul 2014 17:42:24 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87491A01F9; Mon, 14 Jul 2014 17:42:24 -0700 (PDT) Received: from mbp.local ([172.56.41.85]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s6F0gL9k002712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 00:42:22 GMT (envelope-from joelja@bogus.com) Message-ID: <53C478E7.2030902@bogus.com> Date: Mon, 14 Jul 2014 17:42:15 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Waltermire, David A." , "iesg@ietf.org" , "secdir@ietf.org" , "draft-masotta-tftpexts-windowsize-opt.all@tools.ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2dU6SfvHFNqps2enAjHkiQK6LqLkVHthl" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 15 Jul 2014 00:42:24 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/BGzNDg4qSNnEern0hJhoSIY57w4 Subject: Re: [secdir] secdir review of draft-masotta-tftpexts-windowsize-opt-10 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, 15 Jul 2014 00:42:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2dU6SfvHFNqps2enAjHkiQK6LqLkVHthl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks! I think these are reasonable suggestions and will confer with the author. joel On 7/14/14 5:32 PM, Waltermire, David A. wrote: > I have reviewed this document as part of the security directorate's ong= oing effort 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 ju= st like any other last call comments. > > Status: Almost ready - There are a few security and other related conce= rns with this draft summarized below. > > The draft defines a method for overriding the default step-wise acknowl= edgement (ACK) behavior of TFTP. This extension suppresses the standard s= tep-wise ACK response until a negotiated window size of blocks have been = sent. A single ACK is then sent indicating that all blocks in the window = were transmitted. This results in a general reduction in the number of AC= Ks over the exchange, allowing for higher transfer rates than using block= size negotiation alone (RFC2348). > > Security Concerns: > > The specific security considerations statement appears to be copied fro= m RFC2347. It acknowledges that TFTP does not have any explicit security = mechanism and that the extension does not add any additional security ris= k beyond the base specification. Instead of copying the text from the oth= er RFCs, this text should be replaced with text that references the secur= ity considerations from RFC1350, RFC2347, and probably RFC5405. > > Additionally, it seems like this option requires a state machine, invol= ving both the client and server, to track the exchange of blocks within a= window to support retransmission of failed blocks. If I am understanding= this correctly, it looks like a potential attack vector exists where a m= alicious client (or server) could cause abnormal consumption of system an= d network resources through the use of large window sizes across a number= of sessions. This malicious actor would need to selectively cause retran= smission of blocks that still conform with max retry, timeout, and delay = constraints. In part, the second paragraph (and the following example) in= the "Congestion and Error Control" section provide some error handling g= uidance that also addresses this security consideration. At minimum a dis= cussion of this attack vector and a reference back to this explanation sh= ould be included in the security considerations section. It would also be= valuable to include some discussion on reasonable limits for window size= s, retry, timeout, and delay parameters, or at least some guidelines arou= nd determining them based on the characteristics of the data link layer p= rotocol used. > > Other concerns: > > In the abstract: > > - The abstract should mention that this memo extends RFC1350 by adding = a new option extension for ... based on RFC2347. > > In section "Windowsize Option Specification": > > - The text in this section should be updated to make use of RFC2119 cap= italized keywords. > - A specification for the Read and Write requests is provided along wit= h an example. The specification of the corresponding OACK should be provi= ded with the same degree of rigor. > - The draft describes the ACK behavior for data exchange in the definit= ion of the windowsize "#blocks" field. The actual requirements should be = defined using RFC2119 language in a new paragraph after the discussion of= option negotiation. This new text should express the actual windowing be= havior requirements for implementations of the protocol extension. It sho= uld also make explicit which block number to send in the ACK, which I inf= er to be the last block sent in the window. > > General nits: > > There are a number of grammatical and punctuation issues throughout the= document. Some of these make it more difficult to understand the documen= t. A quick editorial pass through the document should address this concer= n. I am happy to provide a few specifics/suggestions in this regard if th= e author would like. > > Also, the nits tool reported: > - An issue with 3 pages being longer than the required 58 lines per pag= e. > - The abstract contains bracketed references. See previous comment. > - Whitespace warnings > > Regards, > Dave Waltermire > > --2dU6SfvHFNqps2enAjHkiQK6LqLkVHthl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPEeOcACgkQ8AA1q7Z/VrL+hQCeISzBKpELIjgtOiGiThEc//Oy R3UAn1OI6RKs9rtgd2gAMoLPyl5Dwiwq =bVs6 -----END PGP SIGNATURE----- --2dU6SfvHFNqps2enAjHkiQK6LqLkVHthl-- From nobody Mon Jul 14 17:53:56 2014 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 919471B27EC; Mon, 14 Jul 2014 17:53:49 -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 6_-5BgtfOqoQ; Mon, 14 Jul 2014 17:53:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8795C1B27F4; Mon, 14 Jul 2014 17:53:41 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0222.namprd09.prod.outlook.com (25.160.92.144) with Microsoft SMTP Server (TLS) id 15.0.985.8; Tue, 15 Jul 2014 00:53:39 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0985.008; Tue, 15 Jul 2014 00:53:39 +0000 From: "Waltermire, David A." To: joel jaeggli , "iesg@ietf.org" , "secdir@ietf.org" , "draft-masotta-tftpexts-windowsize-opt.all@tools.ietf.org" Thread-Topic: secdir review of draft-masotta-tftpexts-windowsize-opt-10 Thread-Index: Ac+fv7NcsGmC4KKQSM2oT4Q8+MLMbAABeweAAAAQAWA= Date: Tue, 15 Jul 2014 00:53:37 +0000 Message-ID: <25df6a98f9de45a1bfbc54153db42584@DM2PR09MB0224.namprd09.prod.outlook.com> References: <53C478E7.2030902@bogus.com> In-Reply-To: <53C478E7.2030902@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.225.82] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 027367F73D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(51704005)(479174003)(164054003)(189002)(377454003)(41574002)(13464003)(24454002)(54356999)(85852003)(20776003)(64706001)(105586002)(99396002)(46102001)(50986999)(87936001)(80022001)(81342001)(33646002)(99286002)(66066001)(21056001)(2201001)(81542001)(19580395003)(107886001)(4396001)(107046002)(79102001)(106356001)(77096002)(86362001)(101416001)(76576001)(74316001)(74662001)(74502001)(15202345003)(92566001)(76176999)(83322001)(31966008)(77982001)(83072002)(15975445006)(95666004)(76482001)(2656002)(19580405001)(85306003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0222; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2o3mrU5lo_nxN63rkKwTFUoKp6Y Subject: Re: [secdir] secdir review of draft-masotta-tftpexts-windowsize-opt-10 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, 15 Jul 2014 00:53:49 -0000 Joel, Thanks. I was just looking at the email threads pertaining to this draft an= d there was a concern about registering the "windowsize" option string with= IANA. http://www.ietf.org/mail-archive/web/tsv-area/current/msg01102.html This seems like a reasonable request, but there doesn't seem to be an assoc= iated IANA registry defined in RFC2347. I'm not sure if this should be a go= ing forward concern or not, but it is worth highlighting. Thanks, Dave -----Original Message----- From: joel jaeggli [mailto:joelja@bogus.com]=20 Sent: Monday, July 14, 2014 8:42 PM To: Waltermire, David A.; iesg@ietf.org; secdir@ietf.org; draft-masotta-tft= pexts-windowsize-opt.all@tools.ietf.org Subject: Re: secdir review of draft-masotta-tftpexts-windowsize-opt-10 Thanks! I think these are reasonable suggestions and will confer with the = author. joel On 7/14/14 5:32 PM, Waltermire, David A. wrote: > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. > > Status: Almost ready - There are a few security and other related concern= s with this draft summarized below. > > The draft defines a method for overriding the default step-wise acknowled= gement (ACK) behavior of TFTP. This extension suppresses the standard step-= wise ACK response until a negotiated window size of blocks have been sent. = A single ACK is then sent indicating that all blocks in the window were tra= nsmitted. This results in a general reduction in the number of ACKs over th= e exchange, allowing for higher transfer rates than using block size negoti= ation alone (RFC2348). > > Security Concerns: > > The specific security considerations statement appears to be copied from = RFC2347. It acknowledges that TFTP does not have any explicit security mech= anism and that the extension does not add any additional security risk beyo= nd the base specification. Instead of copying the text from the other RFCs,= this text should be replaced with text that references the security consid= erations from RFC1350, RFC2347, and probably RFC5405. > > Additionally, it seems like this option requires a state machine, involvi= ng both the client and server, to track the exchange of blocks within a win= dow to support retransmission of failed blocks. If I am understanding this = correctly, it looks like a potential attack vector exists where a malicious= client (or server) could cause abnormal consumption of system and network = resources through the use of large window sizes across a number of sessions= . This malicious actor would need to selectively cause retransmission of bl= ocks that still conform with max retry, timeout, and delay constraints. In = part, the second paragraph (and the following example) in the "Congestion a= nd Error Control" section provide some error handling guidance that also ad= dresses this security consideration. At minimum a discussion of this attack= vector and a reference back to this explanation should be included in the = security considerations section. It would also be valuable to include some = discussion on reasonable limits for window sizes, retry, timeout, and delay= parameters, or at least some guidelines around determining them based on t= he characteristics of the data link layer protocol used. > > Other concerns: > > In the abstract: > > - The abstract should mention that this memo extends RFC1350 by adding a = new option extension for ... based on RFC2347. > > In section "Windowsize Option Specification": > > - The text in this section should be updated to make use of RFC2119 capit= alized keywords. > - A specification for the Read and Write requests is provided along with = an example. The specification of the corresponding OACK should be provided = with the same degree of rigor. > - The draft describes the ACK behavior for data exchange in the definitio= n of the windowsize "#blocks" field. The actual requirements should be defi= ned using RFC2119 language in a new paragraph after the discussion of optio= n negotiation. This new text should express the actual windowing behavior r= equirements for implementations of the protocol extension. It should also m= ake explicit which block number to send in the ACK, which I infer to be the= last block sent in the window. > > General nits: > > There are a number of grammatical and punctuation issues throughout the d= ocument. Some of these make it more difficult to understand the document. A= quick editorial pass through the document should address this concern. I a= m happy to provide a few specifics/suggestions in this regard if the author= would like. > > Also, the nits tool reported: > - An issue with 3 pages being longer than the required 58 lines per page. > - The abstract contains bracketed references. See previous comment. > - Whitespace warnings > > Regards, > Dave Waltermire > > From nobody Mon Jul 14 19:19:53 2014 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 52CB01B27E7; Mon, 14 Jul 2014 19:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 yTUwTAxzazlP; Mon, 14 Jul 2014 19:19:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB101B27F4; Mon, 14 Jul 2014 19:19:45 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s6F2JipP003279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 02:19:45 GMT (envelope-from joelja@bogus.com) Message-ID: <53C48FBB.8000802@bogus.com> Date: Mon, 14 Jul 2014 19:19:39 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: "Waltermire, David A." , "iesg@ietf.org" , "secdir@ietf.org" , "draft-masotta-tftpexts-windowsize-opt.all@tools.ietf.org" References: <53C478E7.2030902@bogus.com> <25df6a98f9de45a1bfbc54153db42584@DM2PR09MB0224.namprd09.prod.outlook.com> In-Reply-To: <25df6a98f9de45a1bfbc54153db42584@DM2PR09MB0224.namprd09.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CLekxGVf7I3RvLmEB7pEwQ4VR9AEqTJdv" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 15 Jul 2014 02:19:45 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/B9FmJNgfUyazc4g8dVwFl_zs764 Subject: Re: [secdir] secdir review of draft-masotta-tftpexts-windowsize-opt-10 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, 15 Jul 2014 02:19:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CLekxGVf7I3RvLmEB7pEwQ4VR9AEqTJdv Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/14/14, 5:53 PM, Waltermire, David A. wrote: > Joel, >=20 > Thanks. I was just looking at the email threads pertaining to this > draft and there was a concern about registering the "windowsize" > option string with IANA. >=20 > http://www.ietf.org/mail-archive/web/tsv-area/current/msg01102.html >=20 > This seems like a reasonable request, but there doesn't seem to be an > associated IANA registry defined in RFC2347. I'm not sure if this > should be a going forward concern or not, but it is worth > highlighting. Yeah it's a standards track document at this point so I'm ok with the idea of it creating a registry, I'd probably adjust the iana considerations section accordingly, but I expect both the IESG review and the IANA review to clarify how we should approach that, or if we shou= ld. regards joel >=20 > Thanks, Dave >=20 > -----Original Message----- From: joel jaeggli > [mailto:joelja@bogus.com] Sent: Monday, July 14, 2014 8:42 PM To: > Waltermire, David A.; iesg@ietf.org; secdir@ietf.org; > draft-masotta-tftpexts-windowsize-opt.all@tools.ietf.org Subject: Re: > secdir review of draft-masotta-tftpexts-windowsize-opt-10 >=20 > Thanks! I think these are reasonable suggestions and will confer > with the author. >=20 > joel >=20 > On 7/14/14 5:32 PM, Waltermire, David A. 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. >>=20 >> Status: Almost ready - There are a few security and other related >> concerns with this draft summarized below. >>=20 >> The draft defines a method for overriding the default step-wise >> acknowledgement (ACK) behavior of TFTP. This extension suppresses >> the standard step-wise ACK response until a negotiated window size >> of blocks have been sent. A single ACK is then sent indicating that >> all blocks in the window were transmitted. This results in a >> general reduction in the number of ACKs over the exchange, allowing >> for higher transfer rates than using block size negotiation alone >> (RFC2348). >>=20 >> Security Concerns: >>=20 >> The specific security considerations statement appears to be copied >> from RFC2347. It acknowledges that TFTP does not have any explicit >> security mechanism and that the extension does not add any >> additional security risk beyond the base specification. Instead of >> copying the text from the other RFCs, this text should be replaced >> with text that references the security considerations from RFC1350, >> RFC2347, and probably RFC5405. >>=20 >> Additionally, it seems like this option requires a state machine, >> involving both the client and server, to track the exchange of >> blocks within a window to support retransmission of failed blocks. >> If I am understanding this correctly, it looks like a potential >> attack vector exists where a malicious client (or server) could >> cause abnormal consumption of system and network resources through >> the use of large window sizes across a number of sessions. This >> malicious actor would need to selectively cause retransmission of >> blocks that still conform with max retry, timeout, and delay >> constraints. In part, the second paragraph (and the following >> example) in the "Congestion and Error Control" section provide some >> error handling guidance that also addresses this security >> consideration. At minimum a discussion of this attack vector and a >> reference back to this explanation should be included in the >> security considerations section. It would also be valuable to >> include some discussion on reasonable limits for window sizes, >> retry, timeout, and delay parameters, or at least some guidelines >> around determining them based on the characteristics of the data >> link layer protocol used. >>=20 >> Other concerns: >>=20 >> In the abstract: >>=20 >> - The abstract should mention that this memo extends RFC1350 by >> adding a new option extension for ... based on RFC2347. >>=20 >> In section "Windowsize Option Specification": >>=20 >> - The text in this section should be updated to make use of RFC2119 >> capitalized keywords. - A specification for the Read and Write >> requests is provided along with an example. The specification of >> the corresponding OACK should be provided with the same degree of >> rigor. - The draft describes the ACK behavior for data exchange in >> the definition of the windowsize "#blocks" field. The actual >> requirements should be defined using RFC2119 language in a new >> paragraph after the discussion of option negotiation. This new text >> should express the actual windowing behavior requirements for >> implementations of the protocol extension. It should also make >> explicit which block number to send in the ACK, which I infer to be >> the last block sent in the window. >>=20 >> General nits: >>=20 >> There are a number of grammatical and punctuation issues throughout >> the document. Some of these make it more difficult to understand >> the document. A quick editorial pass through the document should >> address this concern. I am happy to provide a few >> specifics/suggestions in this regard if the author would like. >>=20 >> Also, the nits tool reported: - An issue with 3 pages being longer >> than the required 58 lines per page. - The abstract contains >> bracketed references. See previous comment. - Whitespace warnings >>=20 >> Regards, Dave Waltermire >>=20 >>=20 >=20 >=20 >=20 --CLekxGVf7I3RvLmEB7pEwQ4VR9AEqTJdv 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPEj7sACgkQ8AA1q7Z/VrIdoACggznw3Hb0xm8O9sCa+CiYwxaU KhEAn3lt3uyYbS04JhOt8+cIlUbvnEH+ =Ziba -----END PGP SIGNATURE----- --CLekxGVf7I3RvLmEB7pEwQ4VR9AEqTJdv-- From nobody Wed Jul 16 18:14:43 2014 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 DE7941A03C8; Wed, 16 Jul 2014 18:14:38 -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, 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 i5p7E1zCThT5; Wed, 16 Jul 2014 18:14:37 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD15A1A03C7; Wed, 16 Jul 2014 18:14:36 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-31-53c6d0da8983 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E1.C8.05330.AD0D6C35; Wed, 16 Jul 2014 21:22:02 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 21:14:35 -0400 From: Eric Gray To: "adrian@olddog.co.uk" , 'Ben Laurie' , 'IETF Discussion List' , "secdir@ietf.org" Thread-Topic: Security review of draft-ietf-pce-questions-06 Thread-Index: AQHPl4DqkyRlMMPM/0m6wotMzCFTMpuXuweAgAvMroA= Date: Thu, 17 Jul 2014 01:14:34 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632B0F109@eusaamb107.ericsson.se> References: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> In-Reply-To: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXSPt+6tC8eCDdoXSVv86LnBbLHh8zU2 ixl/JjJbPNs4n8Xiw8KHLA6sHgs2lXosWfKTyWPF5pWMAcxRXDYpqTmZZalF+nYJXBnbH6xh LPinWvHqmloDY4NqFyMnh4SAicS/ZUfYIGwxiQv31gPZXBxCAkcZJSZcPssM4SxnlDj/cgsL SBWbgIbEsTtrGUESIgILGCVeX93IDpJgFlCWuHnkFTOILSxgLfHx4X2gOAdQkY3EtD91IGER ASuJ2U+Og21jEVCV+Lx9BxOIzSvgK9H7+R0rxLJGRomdWzeAzeQEmnP960wwmxHovO+n1jBB 7BKXuPVkPhPE2QISS/acZ4awRSVePv7HCmErSUxaeo4V5AZmAU2J9bv0IVoVJaZ0P2SH2Cso cXLmE5YJjGKzkEydhdAxC0nHLCQdCxhZVjFylBanluWmGxlsYgRG0jEJNt0djHteWh5iFOBg VOLhVfA9FizEmlhWXJl7iFGag0VJnHdW7bxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwe XFbp+kVLixqXfFjsN//c0Zf1ibdF3TWdPWtfP5zyY+/k5y+Crki2Ha9XYpo1u3uHl48zj6lx StVe9qQT1orv/V1iTtzN2P+L+enXZTHNC32ubdK8Ub3HaMKFhGDu60r/fKKn8OR7TEx9IfHZ UqqhNTjIlb3j49EFl2MDjxxgvJAo9nrt9V4lluKMREMt5qLiRACtZynphQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/F6Ll5idNbDjmCJ3xhP1YL5Px5UE Cc: "iesg@ietf.org" Subject: Re: [secdir] Security review of draft-ietf-pce-questions-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: Thu, 17 Jul 2014 01:14:39 -0000 QWRyaWFuLA0KDQoJSSB0aGluayBpdCBtaWdodCBiZSB1c2VmdWwgdG8gaGF2ZSBhIGxpdHRsZSBt b3JlIGluZm9ybWF0aW9uIGluIHRoZSBTZWN1cml0eSANCkNvbnNpZGVyYXRpb25zIHNlY3Rpb24u DQoNCglGb3IgdGhlIGV4YW1wbGUgQmVuIGdpdmVzLCBmb3IgZXhhbXBsZSwgdGhlIGRyYWZ0IGNv dWxkIGluY2x1ZGUgdGV4dCBpbiANCnRoZSBTQyBzZWN0aW9uIHRoYXQgbWFrZXMgdGhlIHBvaW50 IEJlbiBtYWRlIGFuZCByZWZlcnMgdG8gdGhlIFJGQ3MgKG9yIG90aGVyIA0KcGxhY2VzKSB3aGVy ZSB0aGVzZSBpc3N1ZXMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBvciBhZGRyZXNzZWQuDQoNCglJIGFt IG5vdCBzdXJlIHRoZSBzdWdnZXN0aW9uIHdhcyB0byBwdXQgc2VjdXJpdHkgdGV4dCBpbiBlYWNo IHNlY3Rpb24gc28NCm11Y2ggYXMgdG8gcHV0IHBvaW50ZXJzIHRvIHJlbGV2YW50IHBsYWNlcyB3 aGVyZSAoYWRtaXR0ZWRseSBub3QgbmV3KSBzZWN1cml0eSANCmlzc3VlcyBoYXZlIGFscmVhZHkg YmVlbiBoYXNoZWQgb3V0Lg0KDQoJSSBkb24ndCB0aGluayB0aGlzIHdvdWxkIGJlIHRoZSBmaXJz dCBkcmFmdCB0aGF0IGhhZCBhbiBTQyBzZWN0aW9uIGxpc3RpbmcNCnRoZSBpc3N1ZXMgKG9sZCBv ciBuZXcpIHRoYXQgYXBwbHkgdG8gb3RoZXIgc2VjdGlvbnMgaW4gdGhlIHNhbWUgZHJhZnQuDQoN Ci0tDQpFcmljDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpZXRmIFttYWls dG86aWV0Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbA0KU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDA5LCAyMDE0IDQ6NTUgQU0NClRvOiAnQmVuIExhdXJpZSc7ICdJ RVRGIERpc2N1c3Npb24gTGlzdCc7IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGllc2dAaWV0Zi5vcmcN ClN1YmplY3Q6IFJFOiBTZWN1cml0eSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wY2UtcXVlc3Rpb25z LTA2DQoNCkhpIEJlbiwNCg0KVGhhbmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmV2aWV3IHRo aXMgZG9jdW1lbnQgYW5kIGZvciBwb3N0aW5nIHlvdXIgY29tbWVudHMgdG8gdGhlIElFVEYgZGlz Y3Vzc2lvbiBsaXN0IHNvIHRoYXQgd2UgY2FuIGNvbnNpZGVyIHRoZW0gYXMgbGFzdCBjYWxsIGNv bW1lbnRzLg0KDQpbc25pcF0NCg0KPiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlv biBtYWtlcyB0aGlzIGNsYWltOg0KPiANCj4gIlRoaXMgaW5mb3JtYXRpb25hbCBkb2N1bWVudCBk b2VzIG5vdCBkZWZpbmUgYW55IG5ldyBwcm90b2NvbCBlbGVtZW50cyANCj4gb3IgbWVjaGFuaXNt LiAgQXMgc3VjaCwgaXQgZG9lcyBub3QgaW50cm9kdWNlIGFueSBuZXcgc2VjdXJpdHkgDQo+IGlz c3Vlcy4iDQo+IA0KPiBJIGFncmVlIHdpdGggdGhlIHByZW1pc2UsIGJ1dCBub3QgdGhlIGNvbmNs dXNpb246IGp1c3QgYmVjYXVzZSBhbiBSRkMgDQo+IGRvZXMgbm90IGludHJvZHVjZSBuZXcgc2Vj dXJpdHkgaXNzdWVzLCB0aGF0IGRvZXMgbm90IG1lYW4gdGhhdCB0aGVyZSANCj4gYXJlIG5vIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zLg0KPiANCj4gSW5kZWVkLCB0aGlzIFJGQyBkaXNjdXNzZXMg bWFueSB0aGluZ3MgdGhhdCBoYXZlIHF1aXRlIHNlcmlvdXMgDQo+IHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zLCB3aXRob3V0IG1lbnRpb25pbmcgYW55IG9mIHRoZW0uIEZvciBleGFtcGxlLCANCj4g c2VjdGlvbiA0ICJIb3cgRG8gSSBGaW5kIE15IFBDRT8iICh0aGUgdmVyeSBmaXJzdCBxdWVzdGlv bikgYWR2b2NhdGVzIA0KPiBhIG51bWJlciBvZiBwb3RlbnRpYWxseSBjb21wbGV0ZWx5IGluc2Vj dXJlIG1lY2hhbmlzbXMgd2l0aCBubyBtZW50aW9uIA0KPiBvZiB0aGVpciBzZWN1cml0eSBwcm9w ZXJ0aWVzIChvciBvdGhlcndpc2UpLiBUaGlzIGlzIG9idmlvdXNseSANCj4gcGVydmFzaXZlLCBn aXZlbiB0aGUgc3RhbmNlIHRha2VuIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCj4g DQo+IFRoZSBkb2N1bWVudCBkb2VzIG1lbnRpb24gdGhhdCBSRkMgNjk1MiBnaXZlcyBhIHNlY3Vy aXR5IGFuYWx5c2lzIGZvciANCj4gUENFUCwgYW5kIHBlcmhhcHMgdGhpcyBpcyBzdWZmaWNpZW50 IGJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0IGEgDQo+IGRvY3VtZW50IGludGVuZGVkIHRvIGdpdmUg dXNlZnVsIGJhY2tncm91bmQgaW5mb3JtYXRpb24gdG8gbm9vYnMgDQo+IHNob3VsZCBpbmNsdWRl IHNlY3VyaXR5IGRpcmVjdGx5IGluIHRoYXQgaW5mb3JtYXRpb24gcmF0aGVyIHRoYW4gZGVmZXIg DQo+IHRvIGFub3RoZXIgZ2lhbnQgZG9jdW1lbnQgKHdoaWNoIG1peGVzIFBDRVAgaW5mbyB3aXRo IG90aGVyIA0KPiBwcm90b2NvbHMpLg0KDQpJIGRvbid0IGJlbGlldmUgdGhhdCB0aGlzIGRvY3Vt ZW50IGlzIHN0cm9uZyBvbiAiYWR2b2NhY3kiLCBidXQgZGlzY3Vzc2VzIHdoaWNoIHRvb2xzIGFy ZSBvdXQgdGhlcmUgYW5kIHdoYXQgc29tZSBwZW9wbGUgZG8uDQoNClByZXZpb3VzIFBDRSBSRkNz IGhhdmUgZ2l2ZW4gc29tZSBhdHRlbnRpb24gdG8gc2VjdXJpdHkgY29uY2VybnMgaW4gdGhlIHVz ZSBvZiBQQ0UgKFJGQyA0NjU1KSwgUENFIGRpc2NvdmVyeSAoUkZDIDQ2NzQsIFJGQyA1MDg4LiBS RkMgNTA4OSksIGFuZCB0aGUgUENFUCAoUkZDIDQ2NTcgYW5kIFJGQyA1NDQwKS4gQXMgc3VjaCwg IlBDRSBTZWN1cml0eSIgd2FzIG5vdCBkZWVtZWQgYnkgdGhlIGF1dGhvcnMgdG8gYmUgYSBwcmV2 aW91c2x5ICJ1bmFuc3dlcmVkIHF1ZXN0aW9uIiBhbmQgc28gZGlkIG5vdCBuZWVkIGF0dGVudGlv biBpbiB0aGlzIGRvY3VtZW50Lg0KDQpUaGF0IHNhaWQsIHlvdSBhcmUgY29ycmVjdCB0aGF0IHRo ZSB2YXJpb3VzIHNlY3Rpb25zIGRvIG5vdCBkaXNjdXNzIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlv bnMgcmVsYXRpbmcgdG8gdGhvc2Ugc2VjdGlvbnMuIEkgd291bGQgYmUgcHJldHR5IGxvYXRoZSB0 byBhZGQgc2VjdXJpdHkgdGV4dCB0byBlYWNoIHNlY3Rpb24gaW4gdGhpcyBkb2N1bWVudDogSSB0 aGluayB0aGF0IHdvdWxkIG1ha2UgdGhlIGRvY3VtZW50IGhlYXZ5IGFuZCBsZXNzIGxpa2VseSB0 byBiZSByZWFkIGJ5IGl0cyBpbnRlbmRlZCBjb25zdW1lcnMgKGl0IGlzIG5vdCB0YXJnZXRpbmcg Im5vb2JzIiBhbHRob3VnaCB0aGV5IGFyZSB3ZWxjb21lIHRvIHJlYWQgaXQpLg0KDQpQZXJoYXBz IGEgc29sdXRpb24gdG8gdGhpcyAqaXMqIHRvIHRyZWF0IFNlY3VyaXR5IGFzIGFuIHVuYW5zd2Vy ZWQgcXVlc3Rpb24gYW5kIGFkZCBhIHNlY3Rpb24gIkhvdyBTZWN1cmUgaXMgbXkgUENFLUVuYWJs ZWQgU3lzdGVtPyIgSSBjYW4ndCB0aGluayBvZiBhIGxvdCB0byBhZGQgdGhlcmUgZXhjZXB0IGZv ciBnZW5lcmFsIGVnZy1zdWNraW5nIGd1aWRhbmNlLCBidXQgdGhlcmUgd291bGQgYmUgYSBwb2lu dGVyIHRvIHRoZSBUQ1AtQU8gZGlzY3Vzc2lvbnMgY3VycmVudGx5IGdvaW5nIG9uIGluIHRoZSBX Ry4gV2hhdCBkbyB5b3UgdGhpbmsgb2YgdGhhdCBhcyBhIHdheSBmb3J3YXJkPw0KDQpUaGFua3Ms DQpBZHJpYW4NCg0KDQoNCg== From nobody Thu Jul 17 04:58:09 2014 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 39D951A01DC; Thu, 17 Jul 2014 04:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 MKBXmGy5QuNT; Thu, 17 Jul 2014 04:58:00 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7861A0AD9; Thu, 17 Jul 2014 04:57:59 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6HBvtrB026815; Thu, 17 Jul 2014 12:57:55 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6HBvr1Q026778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Jul 2014 12:57:53 +0100 From: "Adrian Farrel" To: "'Eric Gray'" , "'Ben Laurie'" , "'IETF Discussion List'" , References: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> <48E1A67CB9CA044EADFEAB87D814BFF632B0F109@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632B0F109@eusaamb107.ericsson.se> Date: Thu, 17 Jul 2014 12:57:58 +0100 Message-ID: <041801cfa1b6$5a810b40$0f8321c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4uJ9KXH6Wajq6HAA2wc6J8Axr9gJ/ZfD4AWXJRCqbMtETEA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20822.007 X-TM-AS-Result: No--23.044-10.0-31-10 X-imss-scan-details: No--23.044-10.0-31-10 X-TMASE-MatchedRID: gzVbiXtWD9vRhEyb9f1sjvHkpkyUphL9fkSt9GqmKVVcKZwALwMGs49/ 6wlLhvp4qyDt8DBUTDmued80oPVHSslBBl8WJYU/BEfU2vugRF3QFyJP0HTtvja39Upg7qzqp7u eaEkDqTMUCcGijQ+ntadU6xPWHi+4q87gT7hcKkJT46Ow+EhYOH5Lmbb/xUuaZ5yuplze9psDXU JoExxkYST9NCas8YSASAQzjYmjIgFQswgj0HOv3JpWgCLYjjT9oddeo3DnwAvF8BOx7bOWqIzRE xx/TfU2cim13LKEE7DINWYNYTSoY/Gtxj+4NuNiSDkh6bW+bceUWmF9Epiq6krNh1lQnbOZo9t8 5Zz3caier62Ni/rU6ElFud27bG08Y0pFVhY0RJyzI1v7J4hECiR8aOC0Z4AonSPw4pGdVDwbBER RNLx2o9ePBxJDl9ljP9QK0j0PSltCFB88XbRv2T2wBi8e6DsKIaVkFIrQFhscZFsYO/SuCC6rIz 8N2yWt585VzGMOFzABi3kqJOK62QtuKBGekqUpPjKoPgsq7cA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/KR_ryumHGjsvxDsDKA-U2_UEWug Cc: iesg@ietf.org Subject: Re: [secdir] Security review of draft-ietf-pce-questions-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 11:58:02 -0000 Hi Eric, Ben has clarified... > I prefer 1 [Add security-related text to each section of this = document], that > way the security advice is likely to be read by whoever reads that = section -=20 > that is, by the people who are likely to benefit from it. I've agreed to look at this, but i find myself a tiny bit busy. There is = a meeting I have to go to at the end of the week and I have to prepare = some material. Will get to this in due course. A > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: 17 July 2014 02:15 > To: adrian@olddog.co.uk; 'Ben Laurie'; 'IETF Discussion List'; = secdir@ietf.org > Cc: iesg@ietf.org > Subject: RE: Security review of draft-ietf-pce-questions-06 >=20 > Adrian, >=20 > I think it might be useful to have a little more information in the = Security > Considerations section. >=20 > For the example Ben gives, for example, the draft could include text = in > the SC section that makes the point Ben made and refers to the RFCs = (or other > places) where these issues have been discussed or addressed. >=20 > I am not sure the suggestion was to put security text in each section = so > much as to put pointers to relevant places where (admittedly not new) = security > issues have already been hashed out. >=20 > I don't think this would be the first draft that had an SC section = listing > the issues (old or new) that apply to other sections in the same = draft. >=20 > -- > Eric >=20 > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, July 09, 2014 4:55 AM > To: 'Ben Laurie'; 'IETF Discussion List'; secdir@ietf.org > Cc: iesg@ietf.org > Subject: RE: Security review of draft-ietf-pce-questions-06 >=20 > Hi Ben, >=20 > Thanks for taking the time to review this document and for posting = your > comments to the IETF discussion list so that we can consider them as = last call > comments. >=20 > [snip] >=20 > > The security considerations section makes this claim: > > > > "This informational document does not define any new protocol = elements > > or mechanism. As such, it does not introduce any new security > > issues." > > > > I agree with the premise, but not the conclusion: just because an = RFC > > does not introduce new security issues, that does not mean that = there > > are no security considerations. > > > > Indeed, this RFC discusses many things that have quite serious > > security considerations, without mentioning any of them. For = example, > > section 4 "How Do I Find My PCE?" (the very first question) = advocates > > a number of potentially completely insecure mechanisms with no = mention > > of their security properties (or otherwise). This is obviously > > pervasive, given the stance taken in the security considerations. > > > > The document does mention that RFC 6952 gives a security analysis = for > > PCEP, and perhaps this is sufficient but it seems to me that a > > document intended to give useful background information to noobs > > should include security directly in that information rather than = defer > > to another giant document (which mixes PCEP info with other > > protocols). >=20 > I don't believe that this document is strong on "advocacy", but = discusses which > tools are out there and what some people do. >=20 > Previous PCE RFCs have given some attention to security concerns in = the use of > PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088. RFC 5089), and the = PCEP (RFC > 4657 and RFC 5440). As such, "PCE Security" was not deemed by the = authors to be > a previously "unanswered question" and so did not need attention in = this > document. >=20 > That said, you are correct that the various sections do not discuss = the security > implications relating to those sections. I would be pretty loathe to = add security > text to each section in this document: I think that would make the = document > heavy and less likely to be read by its intended consumers (it is not = targeting > "noobs" although they are welcome to read it). >=20 > Perhaps a solution to this *is* to treat Security as an unanswered = question and > add a section "How Secure is my PCE-Enabled System?" I can't think of = a lot to > add there except for general egg-sucking guidance, but there would be = a pointer > to the TCP-AO discussions currently going on in the WG. What do you = think of > that as a way forward? >=20 > Thanks, > Adrian >=20 >=20 From nobody Thu Jul 17 08:07:21 2014 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 E48DA1B28C7; Tue, 15 Jul 2014 08:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1405439104; bh=GmPKi48PqKZNW8LBHkQV7zTEktRt234FQO2jXThfX0g=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=G/1ZOuadLgt8sGkNQjiR+6B8M+2z/38SB2HekI/9eWPGbHmClP+I7ct1kh3si6EXI Q9URtYdiQzzndZv9RvYgqUejFLu8JbRVG3rDikFNJ3wi/TbEBI4IS2uPMFhjchik1p 8AEmSkRBR5Yg/HsQNqze4A4Fs4y/2atnYD2em7zY= 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 D10621B28C5 for ; Tue, 15 Jul 2014 08:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.654 X-Spam-Level: X-Spam-Status: No, score=-5.654 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 D6jf56AaFvjc for ; Tue, 15 Jul 2014 08:44:56 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995981B28C4 for ; Tue, 15 Jul 2014 08:44:56 -0700 (PDT) Received: from 205-178-89-72.c3-0.nwb-ubr1.chi-nwb.il.cable.rcn.com ([205.178.89.72] helo=[192.168.1.100]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1X74uV-00089F-Iu; Tue, 15 Jul 2014 11:44:55 -0400 From: Ian Jacobs Date: Tue, 15 Jul 2014 10:44:02 -0500 To: "new-work@ietf.org" Message-Id: <5ADC8C86-9DC6-4961-8BD2-EFA54C7B828F@w3.org> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/ckhPS0vMdpk9oDsfj_p4ZwOknEU X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ztQEHvua7ZWhhLTNAKczvrxd4Vo X-Mailman-Approved-At: Thu, 17 Jul 2014 08:07:16 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Annotation Working Group (until 2014-08-19) 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, 15 Jul 2014 15:45:05 -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 Annotation Working Group: http://www.w3.org/2014/annotation/charter/ 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 2014-08-19 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. For more background, W3C recently held a Web Annotations workshop; the workshop report is available: http://www.w3.org/2014/04/annotation/report.html If you should have any questions or need further information, please contact Ivan Herman, Digital Publishing Activity Lead , or Doug Schepers . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/dpub [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs http://www.w3.org/People/Jacobs Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Jul 17 10:29:03 2014 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 0C1EF1A0067 for ; Thu, 17 Jul 2014 10:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.578 X-Spam-Level: * X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, 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 lRyaI-BwPNc5 for ; Thu, 17 Jul 2014 10:28:16 -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 493831A000B for ; Thu, 17 Jul 2014 10:28:16 -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 s6HHSDK8014966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Jul 2014 20:28:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6HHSC5A005270; Thu, 17 Jul 2014 20:28:12 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21448.1963.902982.65218@fireball.kivinen.iki.fi> Date: Thu, 17 Jul 2014 20:28:11 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_aPv5UDuPepioOAF_U1rojk5I94 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, 17 Jul 2014 17:28:19 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tom Yu is next in the rotation. For telechat 2014-08-07 Reviewer LC end Draft Charlie Kaufman TR2014-07-02 draft-ietf-6man-multicast-addr-arch-update-07 Warren Kumari T 2014-07-02 draft-ietf-netext-pmip-cp-up-separation-05 Melinda Shore T 2014-08-01 draft-ietf-websec-key-pinning-19 Sean Turner T 2014-07-17 draft-ietf-appsawg-nullmx-05 Carl Wallace T 2014-07-25 draft-ietf-isis-tlv-codepoints-00 Paul Wouters T 2014-08-01 draft-ietf-appsawg-email-auth-codes-04 Last calls and special requests: Shawn Emery R2014-07-16 draft-ietf-tictoc-security-requirements-10 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Sam Hartman 2014-06-23 draft-ietf-dnsop-child-syncronization-02 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Alexey Melnikov 2014-07-04 draft-ietf-p2psip-service-discovery-13 Eric Osterweil 2014-07-15 draft-ietf-l2vpn-etree-frwk-06 Vincent Roca 2014-07-14 draft-ietf-trill-active-active-connection-prob-05 Joe Salowey 2014-07-21 draft-ietf-trill-loss-delay-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Zach Shelby 2014-07-21 draft-ietf-trill-oam-fm-06 Ondrej Sury 2014-07-30 draft-ietf-ipfix-text-adt-07 Ondrej Sury 2014-07-15 draft-kivinen-ipsecme-signature-auth-06 Takeshi Takahashi 2014-08-05 draft-dukhovni-opportunistic-security-01 Tina TSOU 2014-07-21 draft-ietf-appsawg-multimailbox-search-01 Sam Weiler 2014-08-12 draft-ietf-karp-bfd-analysis-04 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 Brian Weis 2014-07-29 draft-ietf-dnsop-rfc6304bis-03 Klaas Wierenga 2014-07-29 draft-ietf-dnsop-as112-dname-04 -- kivinen@iki.fi From nobody Fri Jul 18 03:33:29 2014 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 D094F1A01E5; Fri, 18 Jul 2014 03:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.907 X-Spam-Level: *** X-Spam-Status: No, score=3.907 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-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 J-wrdpiwl4zf; Fri, 18 Jul 2014 03:33:23 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B531A015B; Fri, 18 Jul 2014 03:33:23 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id s6IAXLMZ020845; Fri, 18 Jul 2014 19:33:21 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id s6IAXLe2003724; Fri, 18 Jul 2014 19:33:21 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 670D92C9A1; Fri, 18 Jul 2014 19:33:21 +0900 (JST) Received: from VAIO (unknown [133.243.119.184]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 610E52C902; Fri, 18 Jul 2014 19:33:21 +0900 (JST) From: "Takeshi Takahashi" To: , , Date: Fri, 18 Jul 2014 19:33:22 +0900 Message-ID: <004101cfa273$b2c9c4a0$185d4de0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+iaeTkN6eXeOd8TQarQkZUIC9lqg== Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith1 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/YX8qwQC3q1yrhYn4CvoOvj-a8w4 Subject: [secdir] Secdir review of draft-dukhovni-opportunistic-security-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, 18 Jul 2014 10:33:25 -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 defines the term "opportunistic security" and describes its design philosophy. The document begins with describing the difficulties to realize perfect security and talks about the benefit of having opportunistic security. The term "opportunistic security" is roughly defined at the end of section 1, and section 2 describes the design principles that realize the opportunistic security. Finally, the 2nd last paragraph of the section 2 clearly defines the term "opportunistic security" It is an interesting document, and I think it is ready. Considering the intensive discussions in these months(on the saag mailing list) and the nature of the document (informational), I see no reason to block the document moving forward. Below are minor comments. 1. In addition to defining the term "opportunistic security", this document also describes the design philosophy of opportunistic security (in section 2). The abstract could be changed so that it can say this document also talks about the design philosophy. 2. It is really just a comment. When I was reading this document for the first time, I was feeling a bit uneasy; I was expecting to see the clear definition of the term first, then to see the design philosophy, but this document describes the design philosophy of the opportunistic security before having clear definition of the term(2nd last paragraph of section 2, starting with "In summary"). Having said that, the current structure is also fine, since this document is short and concise. Moreover, readers can have clear picture of the opportunistic security in mind by the time they reach the sentences defining the term. 3. The security consideration is fairly short, but I think it is ok. All it says is that opportunistic security is not the maximal security, but it is much secure than no security. That explanation is fine for me. Kind regards, Take From nobody Fri Jul 18 05:19:37 2014 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 EEA5D1B299A; Fri, 18 Jul 2014 05:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1405685676; bh=IPRjvVsnFzHaqMY4X9q5G+78EyV0VIgGTwOmDkyWzrE=; 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=I27Q542GTdoQIb8EI+pero3BX9Xu+OAngdFmX32JLgBPji1ZY/sdrjqNqHpqp/wRy +jKkkUt6/L31iqQEJBweE7rhBT/y8gHa672GcHvY8GKu2cn2dhxkTYKm8gVmAXOjkr 3LBv4UgoamAGcTscZGY55HDhJ396jt1NxoYLoz4w= 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 E22431B29A4; Fri, 18 Jul 2014 05:14:27 -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] 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 j9H3Jnx8_1dg; Fri, 18 Jul 2014 05:14:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFBF1B2998; Fri, 18 Jul 2014 05:14:21 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140718121421.7871.45220.idtracker@ietfa.amsl.com> Date: Fri, 18 Jul 2014 05:14:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/7wBZZBFeYPxrvkyAFAMGcVnxbg4 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: http://mailarchive.ietf.org/arch/msg/secdir/8UQ__ECfEJtHtlh3c4z-57difzg X-Mailman-Approved-At: Fri, 18 Jul 2014 05:19:34 -0700 Subject: [secdir] [new-work] WG Review: Transport Services (taps) 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: Fri, 18 Jul 2014 12:14:36 -0000 A new IETF working group has been proposed in the Transport 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 2014-07-31. Transport Services (taps) ------------------------------------------------ Current Status: Proposed WG Chairs: TBD Assigned Area Director: Spencer Dawkins Mailing list Address: taps@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/taps Archive: http://www.ietf.org/mail-archive/web/taps/ Charter: In the TAPS charter, the term "Transport Service" means any service provided by the transport layer that can only be correctly implemented with information from the application. The vast majority of Internet applications make use of the Transport Services provided by TCP (a reliable, in-order stream protocol) or UDP (an unreliable datagram protocol). Other transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism extend the set of available Transport Services beyond those provided to applications by TCP and UDP. For example, SCTP provides potentially faster reliable delivery for applications that can accept blocks of data out of order, and LEDBAT provides low-priority "scavenger" communication. Application programmers face difficulty when they use protocols other than TCP or UDP. Most network stacks only support TCP and UDP, and many firewalls only pass TCP and UDP, so using other transport protocols risks having an application not work in many environments. Applications, therefore, must always be able to fall back to TCP or UDP, and once the application programmer has committed to making an application work on TCP or UDP, there is little incentive to try other transport protocols before falling back. Further, different protocols can provide the same services in different ways. Layering decisions must be made (for example, whether a protocol is used natively or tunneled through UDP). Because of these complications, programmers often resort to either using TCP or implementing their own customized "transport services" over UDP. When application developers re-implement transport features already available elsewhere, they open the door to problems that simply TCP would have avoided, and ensure that the applications can't benefit from other transport protocols as they become available. Alternatively, programmers may simply give up on using transport protocols direcly, relying instead on "HTTP as a Substrate". BCP 56 identified many issues with this strategy, but assuming that if "any protocol is available on a given network path and on the hosts that will be communicating, that protocol will be HTTP" is a reasonable strategy for today's Internet. The IESG has agreed with this viewpoint enough to publish the Websockets protocol on the standards track. The Working Group deliverables will help an application programmers identify the important Transport Services for applications and determine if those Transport Services are available on the end points and along the path in the network. The Working Group will not define a richer set of Transport Services for applications, although the TAPS deliverables could inform proposals for future chartered work on Transport Services. The Working Group will: - Identify Transport Services provided by existing IETF protocols and congestion control mechanisms. The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain Transport Service. As a starting point, the working group will consider: ordering/sequence preservation, degree of reliability, and latency vs throughput, but is not prohibited from considering others. - Specify the subset of those Transport Services, as identified in item 1, that end systems supporting TAPS will provide, and give guidance on choosing among available mechanisms and protocols. - Specify experimental mechanisms to provide a given Transport Service. This document will explain how to select and engage an appropriate protocol and how to discover which protocols are available for a given connection. Futher, it will provide a basis for incremental deployment. The following topics are out of scope for this Working Group: - Quality-of-Service (QoS) and tunneling mechanisms and services - Definition of new encapsulations and tunneling mechanisms - Extension or modification of transport protocols - Language-specific APIs TAPS is not chartered to perform detailed analysis of the security aspects of transport protocols, but TAPS is being chartered almost simultaneously with TCPINC, which is developing the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams, and TAPS will work with TCPINC to ensure that TAPS will be able to accommodate the protocol extensions that TCPINC defines. Milestones: M9: Submit summary of the services provided by IETF transport protocols and congestion control mechanisms to IESG. M15: Submit end system transport services to IESG. M18: Submit specification of how the transport services can be provided to IESG. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jul 18 07:48:44 2014 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 7E40D1B29D9; Fri, 18 Jul 2014 07:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1405694878; bh=5DizFawHw1HzT2tr4tpCRREDCpNpnPHoQp3XagWT/lc=; 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=Nm5WnOrS9TfghrkZri/5gw705JbZ2FREhiWFTN7GdjyVBTgJdkebVZjx3JSOPCqXR YQo/YzHhUdqgRtfosaZGnw3U+fMeapL77V6yF5WFyKKDTshYakPgC450hHpr6fb/XG spg3zsHd+Un55H/Pi3NJgLCfkneRK9UVvB0Gzm2I= 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 1A2771B29CB; Fri, 18 Jul 2014 07:47:57 -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] 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 AcfZZ_W3XWuC; Fri, 18 Jul 2014 07:47:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCFD1A8BB3; Fri, 18 Jul 2014 07:47:54 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140718144754.28695.60552.idtracker@ietfa.amsl.com> Date: Fri, 18 Jul 2014 07:47:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/13mGrOrPM88jLfG1wI6sdJNIFnU 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: http://mailarchive.ietf.org/arch/msg/secdir/jeUN4Jw7XAAT6rN9ZuDESOxUUQY X-Mailman-Approved-At: Fri, 18 Jul 2014 07:48:41 -0700 Subject: [secdir] [new-work] WG Review: Time Zone Data Distribution Service (tzdist) X-BeenThere: secdir@ietf.org Reply-To: ietf@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 14:47:58 -0000 A new IETF working group has been proposed in the Applications 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 2014-07-28. Time Zone Data Distribution Service (tzdist) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Mailing list Address: tzdist@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tzdist Archive: http://www.ietf.org/mail-archive/web/tzdist/ Charter: Time Zone Data Distribution Service (tzdist) ----------------------------------------------------------- A time zone is a region that has a uniform local time for legal, commercial, and social purposes, with some regions using daylight saving time (DST) rules for part of the year. A local time is defined as a standard offset from Coordinated Universal Time (UTC), and a set of DST rules. Time zone data represents the history, current, and future local time rules for these regions, together with an associated time zone identifier. Time zone data is a critical element of computer systems and devices that make use of local time. In particular, it is critical to any calendaring and scheduling system, such as iCalendar (RFC 5545). Daylight saving time rules, which affect local UTC offsets, can change - sometimes at very short notice (just a few days) - as those rules are typically defined by political processes. Currently, there is no efficient, fast way to ensure that time zone data is updated in a timely and reliable manner on devices that need it. Time zone changes are often delivered as operating system updates, and are thus tied to release schedules that can trail the actual time zone changes by a significant period of time. A service is needed that can provide timely, reliable updates. One added benefit of such a service for iCalendar is the ability for calendaring clients and servers to agree on common, standard definitions of time zone data, removing the need to pass time zone data directly "by value" in iCalendar data. By allowing clients and servers to use time zones "by reference" significant network bandwidth and storage savings can be achieved. This working group will: - Define a time zone data distribution protocol that allows for efficient, timely updates of time zone data to be delivered to clients. This protocol must scale to vast numbers of clients, such as the potential "internet of things" devices, as well as to today's desktop computers and servers. - Define an extension to CalDAV (RFC 4791) to allow clients and servers to use time zones "by reference" to improve the efficiency of the overall protocol. The working group will use the following drafts as initial input for its work: draft-douglass-timezone-service-11 draft-daboo-caldav-timezone-ref-01 The working group will work under the following parameters: - The time zone data distribution protocol will initially be targeted at iCalendar-based clients, but should be flexible enough to deliver time zone data in other formats. - The time zone data will be based on the Time Zone Database (http://www.iana.org/time-zones) but must be able to include any source of time zone data. - The time zone data distribution protocol should also offer an API to allow thin clients to easily make use of time zone data by querying for UTC offsets, offloading the sometimes complex work of expanding recurrence rules to the service. This API should be extensible to support other types of time zone operations in the future. - The time zone data distribution protocol will use current security protocols to protect the integrity and confidentiality of the data as it is distributed, and may also address these issues with respect to retrieval of data from its original source (such as the Time Zone Database). Even public time zone data can represent a significant privacy exposure when it is associated with the user or endpoint that is retrieving it. The following are Out of scope for the working group: - Any changes to the Time Zone Database process or infrastructure, as documented in RFC 6557. However, the WG may work with IANA in order to make integrity checking information, such as public keys, readily accessible for protocol use. - The naming process for time zone identifiers. The working group can consider adding a mechanism, such as a "namespace" prefix, to differentiate different time zone sources, but the nature of the time zone identifiers used will be controlled by the sources themselves. - Lookup protocols or APIs to map a location to a time zone. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jul 18 09:15:09 2014 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 E14261B2894; Fri, 18 Jul 2014 09:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1405699805; bh=XIsSuhZ+ra/pih9kOdT4e78jmupKBvZoiYy1j0biy7Y=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=Sp1dklHPrJCqjosn5IYuJYQQv8MBTijYumTftS0RnYAWl2om+WPPu4F18N4UXkarb Oy6CDC4wmo4b2M1hTRpGrAUC2QbUbhG/Xmwc9UPIAuAi8An2Po3PP6AVw4ZKOoOEOF 2prZKF0mvbjiGPj4vvY9sZF/oq896zOosuyRrUws= 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 2B1781A045B; Fri, 18 Jul 2014 06:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 5Dy8woQwlYT6; Fri, 18 Jul 2014 06:23:16 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CBA1A01DC; Fri, 18 Jul 2014 06:23:15 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0C5138008E; Fri, 18 Jul 2014 09:23:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1405689794; bh=ra+LxNIQGKMmFlDnb+3lQhdqWBi1GxplhwTqQ5P9CpA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ln/ViG288vlB8HqmH5jAAM61HHGvRLHZSTvxQ8dK2szBB8g8ILMXGYN1LvDXyInMb bThFSRSAU3g5KY0Cw6r1tr72Q26w8f8GtqUS0sQr08q0XMC84NG+0bhXIyBiB8RMV3 WfG75AEEd7hrssLNstGV1Z+wwLx15DyWJESkqp4c= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6IDND8l012470; Fri, 18 Jul 2014 09:23:13 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 18 Jul 2014 09:23:13 -0400 (EDT) From: Paul Wouters To: The IESG In-Reply-To: <20140718121421.7871.45220.idtracker@ietfa.amsl.com> Message-ID: References: <20140718121421.7871.45220.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/T0ia4vxgND1jO-cQEnXAjGJ7S-s X-Mailman-Approved-At: Fri, 18 Jul 2014 09:10:03 -0700 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" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vipjEFllzI6xvhTf-hEof3gv0rM X-Mailman-Approved-At: Fri, 18 Jul 2014 09:14:59 -0700 Cc: new-work@ietf.org Subject: Re: [secdir] [new-work] WG Review: Transport Services (taps) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 16:10:06 -0000 On Fri, 18 Jul 2014, The IESG wrote: > Subject: [secdir] [new-work] WG Review: Transport Services (taps) > Transport Services (taps) The name "taps" really implies it might be doing something related tp "tapping traffic". It is a very unfortunate name, and I would recommend coming up with another name for this work. Paul _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Jul 21 18:38:16 2014 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 CB8311A006B; Mon, 21 Jul 2014 15:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 OUR0eSKLpq9z; Mon, 21 Jul 2014 15:21:53 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0DE41A0010; Mon, 21 Jul 2014 15:21:52 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s6LMLnF0004172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jul 2014 17:21:50 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6LMLmBt023929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 00:21:48 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 22 Jul 2014 00:21:48 +0200 From: "DRAGE, Keith (Keith)" To: Hilarie Orman , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-cuss-sip-uui-isdn@tools.ietf.org" Thread-Topic: Security review of draft-ietf-cuss-sip-uui-isdn-08 Thread-Index: AQHPbUtrL3XuyQ4tCUiRjqvt3knxH5uriSxw Date: Mon, 21 Jul 2014 22:21:48 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B20CC42@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <201405111817.s4BIHWWk012198@sylvester.rhmr.com> In-Reply-To: <201405111817.s4BIHWWk012198@sylvester.rhmr.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8peoll5SsG1IscjmGI3C4UAn8XY X-Mailman-Approved-At: Mon, 21 Jul 2014 18:38:14 -0700 Subject: Re: [secdir] Security review of draft-ietf-cuss-sip-uui-isdn-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, 21 Jul 2014 22:21:59 -0000 Our proposal is to delete the offending sentence in the first paragraph of = the security considerations. We spent some time trying to work out why this= sentence was written in the first place, and it goes back to the very earl= y days of the author draft. We could not remember. The text makes more sens= e without this sentence. Keith=20 > -----Original Message----- > From: Hilarie Orman [mailto:ho@alum.mit.edu]=20 > Sent: 11 May 2014 19:18 > To: iesg@ietf.org; secdir@ietf.org;=20 > draft-ietf-cuss-sip-uui-isdn@tools.ietf.org > Subject: Security review of draft-ietf-cuss-sip-uui-isdn-08 >=20 > Security review of draft-ietf-cuss-sip-uui-isdn-08=20 > Interworking ISDN Call Control User Information with SIP >=20 > Do not be alarmed. I have reviewed this document as part of=20 > the security directorate's ongoing effort to review all IETF=20 > documents being processed by the IESG. These comments were=20 > written primarily for the benefit of the security area=20 > directors. Document editors and WG chairs should treat these=20 > comments just like any other last call comments. >=20 > This document defines a usage (a new package) of the SIP=20 > User-to-User header field to enable interworking with ISDN=20 > services transporting the ITU-T DSS1 User-user information=20 > data element and is limited to the ISDN UUS1 implicit=20 > supplementary service. Because the element may contain=20 > information related to user privacy, one should consider the=20 > impact of transmitting it in this context. >=20 > The document begins by noting the the User-to-User header=20 > field is defined in "A Mechanism for Transporting User to=20 > User Call Control Information in SIP"=20 > (draft-ietf-cuss-sip-uui-16). That document notes security=20 > requirements deriving from an earlier document, RFC6567 SIP=20 > UUI Reqs, which states: >=20 > The next three requirements capture the UUI security requirements. > REQ-13: The mechanism will allow integrity protection of the UUI. > ... > REQ-14: The mechanism will allow end-to-end privacy of the UUI. > ... >=20 > REQ-15: The mechanism will allow both end-to-end and hop-by-hop > security models. > ... >=20 > The document under review and draft-ietf-cuss-sip-uui-16 note=20 > that because ISDN offers only hop-by-hop security, the SIP=20 > UAs must provide any necessary authenticity, integrity and=20 > privacy protection for sensitive parts of the UUI. >=20 > It is not clear to me if the SIP endpoints are aware of=20 > intermediary ISDNs, nor if they might be unaware of the ISDN=20 > transit and thus misled into thinking that the SIP=20 > infrastructure provided adequate security controls for the=20 > protection of UUI data. >=20 > The document gives the guidance that "data that is used to=20 > assist in selecting which SIP UA should respond to the call=20 > would not be expected to carry any higher level of security=20 > than a media feature tag". I'm not sure how to interpret=20 > that. When should the "level of security" be expected to be=20 > lower than a media feature tag? Or does it mean something=20 > else, like: (a) the data should not be more sensitive than=20 > that in a media feature tag or (b) the data should be=20 > protected (authenticity, integrity, privacy) to at least the=20 > level of a media feature tag or (c) the UUI data and the=20 > media feature tag data are so similar that they should have=20 > the same level of protection? >=20 > That's my impression from reading over the security considerations. > My apologies if I've missed the point. >=20 > Hilarie >=20 >=20 >=20 >=20 >=20 > = From nobody Tue Jul 22 08:37:25 2014 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 9D6211A0173 for ; Tue, 22 Jul 2014 08:37:24 -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, RP_MATCHES_RCVD=-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 Vw4ihAPTq0lf for ; Tue, 22 Jul 2014 08:37:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8011A0143 for ; Tue, 22 Jul 2014 08:37:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 11767BDDC for ; Tue, 22 Jul 2014 16:37:22 +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 RazV2xurR-4d for ; Tue, 22 Jul 2014 16:37:21 +0100 (IST) Received: from [31.133.188.75] (dhcp-bc4b.meeting.ietf.org [31.133.188.75]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E017EBDD7 for ; Tue, 22 Jul 2014 16:37:20 +0100 (IST) Message-ID: <53CE8530.4050006@cs.tcd.ie> Date: Tue, 22 Jul 2014 16:37:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/EUIi5oMRx_StkcYjAucbCmQ2sSw Subject: [secdir] secdir lunch 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, 22 Jul 2014 15:37:24 -0000 In case you can't find that mail: we're in confederation 3 S. From nobody Tue Jul 22 09:29:05 2014 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 E48C71B29E1 for ; Tue, 22 Jul 2014 09:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.777 X-Spam-Level: X-Spam-Status: No, score=0.777 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, 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 qvLOArHxTXJS for ; Tue, 22 Jul 2014 09:28:55 -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 665B31A01F2 for ; Tue, 22 Jul 2014 09:28:48 -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 s6MGSjLO027795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Jul 2014 19:28:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6MGSiZK010072; Tue, 22 Jul 2014 19:28:44 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21454.37180.724701.377108@fireball.kivinen.iki.fi> Date: Tue, 22 Jul 2014 19:28:44 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 22 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/RFJAy_o8C55_OGsKDQef6JXLwcU Subject: [secdir] Link to the area review tool of secdir 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, 22 Jul 2014 16:28:57 -0000 The area review tool can be found in http://art.tools.ietf.org/tools/art/secdir/ You can use the tool to mark yourself as being away (vacation, etc), and that will take you out from the rotation until given time. If you do that, also send me an email, so I will know that you are away. Note, that the availibity only affects new assignments, rereviews can still be assigned back to you, as I always assign them to same person who did the original review. -- kivinen@iki.fi From nobody Wed Jul 23 08:08:59 2014 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 1D8861B28D8; Wed, 23 Jul 2014 08:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 l_iuw3_h4JSL; Wed, 23 Jul 2014 08:08:51 -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 96BBF1B28F5; Wed, 23 Jul 2014 08:08:49 -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 BKL40540; Wed, 23 Jul 2014 15:08:47 +0000 (GMT) Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 16:08:44 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.34]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 23:08:39 +0800 From: Tina TSOU To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-appsawg-multimailbox-search.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-appsawg-multimailbox-search-02 Thread-Index: AQHPpof7Uxf/53YXPkGqfWNk0XiuVw== Date: Wed, 23 Jul 2014 15:08:39 +0000 Message-ID: References: <004101cfa273$b2c9c4a0$185d4de0$@nict.go.jp> In-Reply-To: <004101cfa273$b2c9c4a0$185d4de0$@nict.go.jp> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.219] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/1GeUOqYAagebslxwnVnmacngXGU Subject: [secdir] Secdir review of draft-ietf-appsawg-multimailbox-search-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: Wed, 23 Jul 2014 15:08:56 -0000 Dear 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 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 comments. **** Technical: **** The two numbered bullets in page 5 (section 2.2) and the first and third bu= llets in page 6 (Section 2.2) should use RFC2119 language. **** Nits: **** Section 1: > his extension allows a client to search multiple mailboxes > with one command, limiting round trips delay Maybe something like "transaction delay" or something along those lines wou= ld be better? Section 1: > There is > now implementation experience, giving confidence in the protocol, so > this document puts the extension on the Standards Track, with some > minor updates that were informed by the implementation experience. You may want to replace "informed" with "motivated". Thank you, Tina From nobody Wed Jul 23 08:22:31 2014 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 090491A031D; Wed, 23 Jul 2014 08:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 NbCca1q5oZME; Wed, 23 Jul 2014 08:22:26 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98861A0117; Wed, 23 Jul 2014 08:22:25 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v6so1020238lbi.39 for ; Wed, 23 Jul 2014 08:22:23 -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=vr7vhHoOEptU6c+0F1Db3nsBYl/TxJPlAerXkivD608=; b=UVig7Dn8tpbG24NWj0VuzMSppqxvbTaz5q3crTR9CmfhVh8Y1JmFJi6wVY4E5OZwjh iue4TKGwyiiLlx6Hi3qmEEkQ9ZHCZowQ/dihobjYocz1nFsDSs1OGTVsscswMUF9ruJG XWM6wO2ZjWwIQudiRfM5dKE45DxcxK5WjXsa/9WVikEg7dfX8TGDS8gAbFvXcVkZuAbP HKjJQRqxxCCidi+4jxg2KXymb02zn94H0T0WWi7Ev1PoBEePgxPf+wYy6CGMyW43n9YA 4jvkGSD57Dm2SRsL2UZ01ZcUPOO6gjB3rPnFCDD1NJRea2/3pN8mLtNMIDryk1QLtYvi q8jA== MIME-Version: 1.0 X-Received: by 10.152.206.105 with SMTP id ln9mr2284125lac.45.1406128943774; Wed, 23 Jul 2014 08:22:23 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Wed, 23 Jul 2014 08:22:23 -0700 (PDT) In-Reply-To: References: <004101cfa273$b2c9c4a0$185d4de0$@nict.go.jp> Date: Wed, 23 Jul 2014 11:22:23 -0400 X-Google-Sender-Auth: flVkYJmNz9eoNrBptilay9RROOg Message-ID: From: Barry Leiba To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/52twP-LzLKzypu-O84rIXF2LSuo Cc: "draft-ietf-appsawg-multimailbox-search.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-appsawg-multimailbox-search-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: Wed, 23 Jul 2014 15:22:27 -0000 Hi, Tina, and thanks for the review. > The two numbered bullets in page 5 (section 2.2) and the first and > third bullets in page 6 (Section 2.2) should use RFC2119 language. I very much disagree; I think it's quite fine as it is, and says exactly what it needs to. Is the language unclear? >> his extension allows a client to search multiple mailboxes >> with one command, limiting round trips delay > > Maybe something like "transaction delay" or something along > those lines would be better? No, the Introduction section is clear that we want to talk about round trips. What you're quoting is from the Abstract. Lots of App-layer stuff talks about round trips. But, yes, "round trips delay" is awkward. I think this might work better: OLD This extension allows a client to search multiple mailboxes with one command, limiting round trips delay, and not requiring disruption of the currently selected mailbox. NEW This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips, and not requiring disruption of the currently selected mailbox. END >> There is >> now implementation experience, giving confidence in the protocol, so >> this document puts the extension on the Standards Track, with some >> minor updates that were informed by the implementation experience. > > You may want to replace "informed" with "motivated". I very much don't. "Informed" is actually the right word. This odd use of "motivate" has become popular in the tech world in recent years, but it's not correct English usage, and I've always found it icky.[1] Barry [1] "Icky" is, of course, perfectly correct English.... From nobody Thu Jul 24 09:41:04 2014 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 D25E01A0402 for ; Thu, 24 Jul 2014 09:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 1xTChrhfLMTc for ; Thu, 24 Jul 2014 09:41:02 -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 973A81A031C for ; Thu, 24 Jul 2014 09:41: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 s6OGewm8025393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 24 Jul 2014 19:40:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6OGewpj007941; Thu, 24 Jul 2014 19:40:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21457.14106.741262.497065@fireball.kivinen.iki.fi> Date: Thu, 24 Jul 2014 19:40:58 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/NxdUlwR5m-8PkYAqPlg4sNNIySM 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, 24 Jul 2014 16:41:04 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Alan DeKok is next in the rotation. For telechat 2014-08-07 Reviewer LC end Draft Sam Hartman T 2014-06-23 draft-ietf-dnsop-child-syncronization-02 Charlie Kaufman TR2014-07-02 draft-ietf-6man-multicast-addr-arch-update-07 Warren Kumari T 2014-07-02 draft-ietf-netext-pmip-cp-up-separation-05 Vincent Roca T 2014-07-14 draft-ietf-trill-active-active-connection-prob-05 Joe Salowey T 2014-07-21 draft-ietf-trill-loss-delay-05 Zach Shelby T 2014-07-21 draft-ietf-trill-oam-fm-06 Melinda Shore T 2014-08-01 draft-ietf-websec-key-pinning-19 Sean Turner T 2014-07-17 draft-ietf-appsawg-nullmx-05 Carl Wallace T 2014-07-25 draft-ietf-isis-tlv-codepoints-00 Paul Wouters T 2014-08-01 draft-ietf-appsawg-email-auth-codes-05 For telechat 2014-08-21 Shaun Cooley T 2014-08-08 draft-ietf-tram-auth-problems-02 Shawn Emery TR2014-07-16 draft-ietf-tictoc-security-requirements-11 Last calls and special requests: Derek Atkins 2014-08-09 draft-ietf-l3vpn-pmsi-registry-03 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Alexey Melnikov 2014-07-04 draft-ietf-p2psip-service-discovery-13 Eric Osterweil 2014-07-15 draft-ietf-l2vpn-etree-frwk-07 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-07-30 draft-ietf-ipfix-text-adt-07 Ondrej Sury 2014-07-15 draft-kivinen-ipsecme-signature-auth-07 Sam Weiler 2014-08-12 draft-ietf-karp-bfd-analysis-04 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 Brian Weis 2014-07-29 draft-ietf-dnsop-rfc6304bis-03 Klaas Wierenga 2014-07-29 draft-ietf-dnsop-as112-dname-04 Tom Yu 2014-08-09 draft-ietf-forces-model-extension-03 Dacheng Zhang 2014-08-07 draft-ietf-l2vpn-ipls-14 -- kivinen@iki.fi From nobody Wed Jul 30 07:14:10 2014 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 F36211A005C; Wed, 30 Jul 2014 07:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 WY0b87EYr7be; Wed, 30 Jul 2014 07:14:05 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5291A0060; Wed, 30 Jul 2014 07:14:04 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,764,1400018400"; d="scan'208,217"; a="73357924" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 30 Jul 2014 16:14:02 +0200 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_0F04A5F2-D956-44E3-A6B6-2824D4A54B81" Date: Wed, 30 Jul 2014 16:14:02 +0200 Message-Id: To: IESG , secdir@ietf.org, draft-ietf-trill-active-active-connection-prob@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7hjJTm_LuAieSe9FoVAQ5ertK2I Subject: [secdir] Secdir review of draft-ietf-trill-active-active-connection-prob-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: Wed, 30 Jul 2014 14:14:07 -0000 --Apple-Mail=_0F04A5F2-D956-44E3-A6B6-2824D4A54B81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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. IMHO, the document is ready. I just have one comment: The authors say that =AB as an informational overview, this draft does = not introduce any extra security risks =BB and explain that future documents = that specify practical solutions will detail the security aspects. They also = refer to [RFC6325] for general TRILL security considerations. I may agree. However an informal document discussing problems and goals that practical solutions will have to address is also a good place to = discuss general security aspects. Future documents could easily refer to this = document while going further into details. Too bad. Cheers, Vincent --Apple-Mail=_0F04A5F2-D956-44E3-A6B6-2824D4A54B81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
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.

IMHO, the document = is ready. I just have one = comment:

The authors say that =AB as an = informational overview, this draft does not
introduce any = extra security risks =BB and explain that future documents = that
specify practical solutions will detail the security = aspects. They also refer to
[RFC6325] for general TRILL = security considerations.

I may agree. However an = informal document discussing problems and goals
that practical = solutions will have to address is also a good place to = discuss
general security aspects. Future documents could = easily refer to this document
while going further into = details. = Too bad.

Cheers,

&n= bsp;  Vincent

= --Apple-Mail=_0F04A5F2-D956-44E3-A6B6-2824D4A54B81-- From nobody Thu Jul 31 08:23:09 2014 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 B0F601A02A3; Wed, 30 Jul 2014 08:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1406733942; bh=DnX5at5ooO1yo7t99swr7uE3SFRtj+bUo133LmbcRY0=; 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=MEOqSb5jfpV2kj9WpU+H8wpyZehLskIUo22BlAZPy6R/Ye1nTz6vtoGKM5yMScxWO Ff/E6DRVMscizz+CAtwLH6Mg0HewvTiCRtWUd9Xa0m1JHTeN7kySTAP2Xy07nZQJSN 89MYCuTbzRuwElLKVGdbdIpzsVessCMf7gpHVoa0= 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 460C81A0295 for ; Wed, 30 Jul 2014 08:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 0-u32eHmKATZ for ; Wed, 30 Jul 2014 08:25:28 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AABC1A0199 for ; Wed, 30 Jul 2014 08:24:20 -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:32) (Exim 4.72) (envelope-from ) id 1XCVjn-00017M-6g; Wed, 30 Jul 2014 11:24:19 -0400 To: new-work@ietf.org Date: Wed, 30 Jul 2014 17:24:17 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/qhuaeQ3pkX7bX0MPhWtNrCW-roo X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/AC-CwR9MpgKgPcZnBw-XuT8V6UQ X-Mailman-Approved-At: Thu, 31 Jul 2014 08:23:06 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Second Screen Presentation Working Group (until 2014-09-12) 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, 30 Jul 2014 15:25:42 -0000 CgpIZWxsbywKClRvZGF5IFczQyBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmVzIHJl Y2VpdmVkIGEgUHJvcG9zYWwgdG8gcmV2aWV3ICAKdGhlIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBT ZWNvbmQgU2NyZWVuIFByZXNlbnRhdGlvbiBXb3JraW5nIEdyb3VwOgogICBodHRwOi8vd3d3Lncz Lm9yZy8yMDE0L3NlY29uZHNjcmVlbi9jaGFydGVyLWRyYWZ0Lmh0bWwKCkFzIHBhcnQgb2YgZW5z dXJpbmcgdGhhdCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsgYXQgVzND LCAgCnRoaXMgZHJhZnQgY2hhcnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21t aXR0ZWUgcmV2aWV3IHBlcmlvZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdo IDIwMTQtMDktMTIgb24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIuICAKUGxlYXNlIHNlbmQgY29tbWVu dHMgdG8gcHVibGljLW5ldy13b3JrQHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6 CiAgIGh0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8K Ck90aGVyIHRoYW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZp c29yeSBDb21taXR0ZWUgIApSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEg cmVzcG9uc2UgdG8KY29tbWVudHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBw bGVhc2UgY29vcmRpbmF0ZSB5b3VyICAKY29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1p dHRlZSBSZXByZXNlbnRhdGl2ZS4gRm9yIGV4YW1wbGUsIHlvdSBtYXkgIAp3aXNoIHRvIG1ha2Ug cHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxpc3QgYW5kIGhhdmUgeW91ciBBZHZpc29yeSAgCkNv bW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0byBpdCBmcm9tIGhpcyBvciBoZXIgZm9ybWFs IHJldmlldyAgCmNvbW1lbnRzLgoKSWYgeW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3Ig bmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9uLCBwbGVhc2UgIApjb250YWN0IEZyYW7Dp29pcyBEYW91 c3QgPGZkQHczLm9yZz4sIFN0YWZmIENvbnRhY3QuCgpUaGFuayB5b3UsCgpDb3JhbGllIE1lcmNl ciwgVzNDIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9N ZW1iZXIvTGlzdAoKCi0tIAogIENvcmFsaWUgTWVyY2llciAgLSAgVzNDIENvbW11bmljYXRpb25z IFRlYW0gIC0gIGh0dHA6Ly93d3cudzMub3JnCm1haWx0bzpjb3JhbGllQHczLm9yZyArMzM2IDQz MjIgMDAwMSBodHRwOi8vd3d3LnczLm9yZy9QZW9wbGUvQ01lcmNpZXIvCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5nIGxpc3QK bmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXctd29yawo=