From nobody Fri May 1 09:31:58 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806A91A8935; Fri, 1 May 2015 09:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEtOkYfGn64y; Fri, 1 May 2015 09:31:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 391DB1A8AA7; Fri, 1 May 2015 09:31:50 -0700 (PDT) Received: from [192.168.2.100] ([79.246.25.249]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MTSrf-1Yfjdr3pyh-00SQp5; Fri, 01 May 2015 18:31:49 +0200 Message-ID: <5543AA71.5030702@gmx.net> Date: Fri, 01 May 2015 18:31:45 +0200 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tony@yaanatech.com, saag@ietf.org, sacm@ietf.org, ietf@ietf.org, OPSAWG@ietf.org References: <5540ED82.5060905@gmx.net> <5542974B.9080208@yaanatech.com> In-Reply-To: <5542974B.9080208@yaanatech.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hRGVc6/5ST5b4qHWzzc1rxUu1AuMIrOwfylxQhajmxXfm2S+Be7 MDs7GRaSbTGFE+HUz8HwRidjkO9hUxqg+ezxw4MPk8XHggNTM+RzTfwf52SWQGAbu8r7bUL bGupLzaVXOskKrCK6M06DzDjX64UcGCRxmtQEMkBG6hvyupKl1XBq5c92WWU4ojNitL4IoB O7ME09PkVgTFH+390HqFg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [saag] [sacm] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 16:31:53 -0000 Hi Tony, thanks for your question. You are not the first one who ask in context to STIX or CybOX. So this seems to be an important point, which I have to take care about. The STIX project is very interesting and covers a wide field of cyber security. Currently I make me still familiarise with STIX and CybOX with special focus on interoperability with and provisions by IDPEF. My work is close to the IDMEF and IDXP of the IETF and is focused on IDS federation and interoperability only. So I decide at the start of IDPEF to be close to IDMEF and IDXP. By my point of view the STIX project is more focussed on communication of standardized cyber threat information (reporting). The focus of IDPEF is to improve the management of IDS under one independent central management system for all operated IDS Anlayzers. So IDPEF customizes the Analyzer to the individual environment and implementation of the IDS entity. So STIX is more the output of an IDS and IDPEF more the interoperability and combination between IDS Analyzers under one independent central Manager. For me this are two separate working focus. I am open to align IDPEF closer to other frameworks like STIX, CybOX, etc. but by now the structure and notation of IDPEF is close to IODEF and IDMEF. Currently all standardization is focussed on reporting and alerting to exchange threat and incident information structured and in a secure manner (STIX, IODEF, IDMEF, etc.). IDPEF intended usage is to operate all IDS Analyzers under a independent management system. So IDPEF focus is more the interoperability and combination between IDS Analyzers under one independent central Manager. For me this are two separate working focus. Did you have an other point of view, please let us discus so that I have the chance to adjust IDPEF closer to STIX. A small STIX notation based on an example of Appendix A will be great and very helpful for me. Thanks. Kind regards Bjoern-C. Am 30.04.2015 um 22:57 schrieb Tony Rutkowski: > How is this not like STIX? > > -t > > On 2015-04-29 10:41 AM, B.-C. Boesch wrote: >> Abstract >> >> The Intrusion Detection Parametrization Exchange Format (IDPEF) >> defines data formats and exchange procedures to standardize >> parametrization information exchange into intrusion detection and >> response systems from an independent central Manager to any Analyzer. >> The IDPEF enables a combination of different (vendor and analyzing >> technique) IDS Analyzers under one independent central Manager. A >> separate operations of IDS is not longer needed. Base is a new >> parametrization methodology where IDS operating parameters >> (configurations) are separated in an environmental parametrization >> part and a vendor-specific analyzing part. >> >> This Internet-Draft describes a data model to represent >> parametrization information of intrusion detection system entities, >> and explains the rationale for using this model. An implementation of >> the data model in the Extensible Markup Language (XML) is presented, >> a XML Document Type Definition is developed, and parametrization >> examples are provided. > > From nobody Fri May 1 14:00:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0641A0067 for ; Fri, 1 May 2015 14:00:30 -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, 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 OutUn038ivQn for ; Fri, 1 May 2015 14:00:28 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 818C01A00A8 for ; Fri, 1 May 2015 14:00:27 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 122339A4020 for ; Fri, 1 May 2015 17:00:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id ill0s9OIZGIt for ; Fri, 1 May 2015 16:59:56 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-145-93.washdc.fios.verizon.net [96.255.145.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 411669A401B for ; Fri, 1 May 2015 16:59:56 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2015 16:59:45 -0400 Message-Id: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> To: IETF SAAG Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [saag] draft-iab-crypto-alg-agility-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:00:30 -0000 A new version (-03) has been submitted for draft-iab-crypto-alg-agility: https://www.ietf.org/internet-drafts/draft-iab-crypto-alg-agility-03.txt I tried to capture the discussion from last month. Please review and = comment. Russ From nobody Sat May 2 05:32:48 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267BE1A8739; Sat, 2 May 2015 05:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4LTmEAe_1mS; Sat, 2 May 2015 05:32:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 EA7F71A8738; Sat, 2 May 2015 05:32:42 -0700 (PDT) Received: from [192.168.2.105] ([79.246.2.1]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M3d9B-1Z6Bs60wSH-00rFSq; Sat, 02 May 2015 14:32:39 +0200 Message-ID: <5544C3E2.5020807@gmx.net> Date: Sat, 02 May 2015 14:32:34 +0200 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Randy Presuhn , ietf@ietf.org, OPSAWG@ietf.org, saag@ietf.org, sacm@ietf.org References: <21625111.1430433958137.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> In-Reply-To: <21625111.1430433958137.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:BBzRzFzrebAHwmzWbUmZzhuhlJABLbGNbZrzEEpi8JgGmt6tzkd LndxLaAS9F1kfutyENK4rKGCnm+k0gOp/e59AzbyRPhZXjgqRY6SX6ifY8ddAEkg7VID7cA 9A+yXtMvAj+PZ7Xc1DGVWzR5uXnQUWhfVbhF06slrc6Gale9F7nNaPFUwnZVgNJaWtJGDnm b8oVfxi1UsxZXb2Kyxoog== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [saag] [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 12:32:45 -0000 Hi Randy, thanks for your feedback and the start of a discussion about IDPEF and its management features / options. IDXP provide already an interface for configuration exchange. Therefore IDPEF was developed close to IDMEF and IDXP. An important argument was that only one transport protocol is need for configuration and signalling. That reduces the probability of vulnerabilities in the implementation (one implementation instead of two). The key point for IDPEF is that the parametrization of the Analyzer will be harmonized and the Manager become independent. Based on this you are able to combine different (vendor and analyzing technique) IDS Analyzers under one independent central Manager. With YANG and netconf the configuration will be still vendor-specific and vendor-specific adjustments are still needed on site of the central Manager. That is why I preferred a specialized format. Maybe there are some other good points which plead for YANG as IDS configuration format that we should put focus on. Kind regards Bjoern-C. Am 01.05.2015 um 00:45 schrieb Randy Presuhn: > Hi - > > Has there been some discussion of the reasons why this work > doesn't emply one of the established management information > data modeling languages, such as Yang or SNMP SMI? > > Randy > > -----Original Message----- >> From: "B.-C. Boesch" >> Sent: Apr 29, 2015 7:41 AM >> To: saag@ietf.org, sacm@ietf.org, ietf@ietf.org, OPSAWG@ietf.org, Kathleen Moriarty >> Cc: Stephen Farrell >> Subject: [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) >> >> Dear community, >> >> I have post the attached draft and looking for feedback from people with >> security management and / or security (IDS) operations expertise >> (including IDS developer). I am particularly interested in your opinions >> on the communication proceedings, the parametrization methodology and >> the provided attributes (and such I did not think of). If the text needs >> updating by your point of view, please let me know that as well. Here is >> the link to the new draft: >> >> http://www.ietf.org/id/draft-boesch-idxp-idpef-01.txt >> >> At the first view the draft looks very long but after page 44 a lot of >> examples and definitions are included for better understanding. So the >> first 43 pages are primary in scope for feedback but feedback for the >> other pages is welcome, too. >> >> Abstract >> >> The Intrusion Detection Parametrization Exchange Format (IDPEF) defines >> data formats and exchange procedures to standardize parametrization >> information exchange into intrusion detection and response systems from >> an independent central Manager to any Analyzer. The IDPEF enables a >> combination of different (vendor and analyzing technique) IDS Analyzers >> under one independent central Manager. A separate operations of IDS is >> not longer needed. Base is a new parametrization methodology where IDS >> operating parameters (configurations) are separated in an environmental >> parametrization part and a vendor-specific analyzing part. >> >> This Internet-Draft describes a data model to represent parametrization >> information of intrusion detection system entities, and explains the >> rationale for using this model. An implementation of the data model in >> the Extensible Markup Language (XML) is presented, a XML Document Type >> Definition is developed, and parametrization examples are provided. >> >> >> >> I am looking forward to your suggestions, feedback, notations, hints, >> recommendations, etc. to improve the Internet Draft. Also native speaker >> feedback with scope on wording and typo is welcome. >> >> Kind regards, >> >> Bjoern-C. >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg From nobody Sat May 2 07:40:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC9B1A88C1 for ; Sat, 2 May 2015 07:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4YXnFL0B5_h for ; Sat, 2 May 2015 07:40:21 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FEC1A88BD for ; Sat, 2 May 2015 07:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10181; q=dns/txt; s=iport; t=1430577621; x=1431787221; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=loE6bQMc9NaA8Qe3JfSoNVlOTJ8x/bN/peEEnv6Nc+4=; b=Q8wlJT9d/vyPtPy9brEf4I20N22r2mFwJrkU8E4G35b0oJ0F6Ihziz23 dP7geA3ZsqBt1IhRm/9+55z/jhhIrqAnCi/kXWrH+VQo4o/a3EZyRUKJx rOz+Wogs78HBxqpdGRSkx3coZj38V357DiMtJAEiFuzLl3uDc3pt7Oqme Q=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AwCs4ERV/xbLJq1ch1jCPwmHWgKCCBQBAQEBAQEBgQqEIQEBAwEjQgYNBgsLIRYLAgIJAwIBAgFFBgEMCAEBiB8IswaTBAEBAQEBAQEDAQEBAQEBAQEaizmFDIJogUUBBJQJgTmHHYEkhiOLBYNSI4FlHQUcgVM8gnYBAQE X-IronPort-AV: E=Sophos;i="5.13,355,1427760000"; d="asc'?scan'208,217";a="459404139" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 02 May 2015 14:40:17 +0000 Received: from [10.61.80.161] (ams3-vpn-dhcp4258.cisco.com [10.61.80.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t42EeHkO001219; Sat, 2 May 2015 14:40:17 GMT Message-ID: <5544E1D0.8010307@cisco.com> Date: Sat, 02 May 2015 16:40:16 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Russ Housley , IETF SAAG References: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> In-Reply-To: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xcSaanFkNckDcfDDUuVjLHdFx79Aiv0ux" Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 14:40:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xcSaanFkNckDcfDDUuVjLHdFx79Aiv0ux Content-Type: multipart/alternative; boundary="------------010707030605010403040802" This is a multi-part message in MIME format. --------------010707030605010403040802 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, Some comments: Bottom of the introduction: > Experience shows that many people are > unwilling to disable older weaker algorithms; it seems that these > people prefer to live with weaker algorithms, sometimes seriously > flawed ones, to maintain interoperability with older software well > after experts recommend migration. There are a myriad of reasons, and this is just one important one. It may be that they are *unable* to make the changes because there is hardware involved that cannot support the new algorithm (footprint issues, accelerator problems, or what-have-you). I will hazard a guess that a more common scenario is that they have no idea *how* to make the changes or even that the changes are needed. My suggestion is either don't get into the "it seems..." business or to cover all the ground. Section 2/Section 3: There is a minor organizational issue here, and perhaps Housley's Law applies (the one about the document not being finished until all excess verbiage has been removed). It looks like part of Section 3 could be merged with Section 2 (I got initially confused by some ambiguous advice in 2.1 that was cleared up in 3.1). Some of Section 3 belongs with the text in Section 4. Specifically, 3.3 is really tied quite closely to 4.2, 4.3, and 4.4. Section 2.2: > For this reason, the > protocol MUST specify one or more mandatory-to-implement algorithm o= r > suite. It may be worth reminding people that "mandatory to implement !=3D mandatory to deploy" and holding some discussion on this point. For instance, some environments may find the MTI insufficient for their purposes. Section 2.4: > > When selecting a suite of cryptographic algorithms, the strength of > each algorithm SHOULD be considered. It needs to be considered at > the time a protocol is designed. It also needs to be considered at > the time a protocol implementation is deployed and configured. > Advice from from experts is useful, but in reality, it is not often > available to system administrators that are deploying and configurin= g > a protocol implementation. For this reason, protocol designers > SHOULD provide clear guidance to implementors, leading to balanced > options being available at the time of deployment and configuration.= I'll note that most of us applications people need current advice (like some that's in this draft) just like using what's out there and available in tools like OpenSSL, but these libraries generally do *not* provide that advice. Perhaps it would be useful to even have an appendix that includes translation of the advice in the draft to choices in the various libraries. No, I'm not offering to write it, and I'd understand if it gets missed because nobody else does either. Section 4.3: I was surprised to find that you did not follow up your earlier philosophical statement in Section 4.2 ("The idea is to have an implemented and deployed algorithm as a fallback") with some sort of SHOULD or MUST around that, either in 4.2 or 4.3. Maybe it belongs in 2.2 next to the MUST at the top. Maybe I missed it? Section 4.4: This advice is largely around what happens when there is some user interface to configure systems. That is unlikely to be the case with the Internet of Many Tiny Little Things (IoMTLT). Do you want to give some more specific advice to top off what is being said wrt smart objects (following up from the tech plenary)? Nittiest nit: > Algorithm agility is achieved when a protocol can easily migrate fro= m > one algorithm suite to another, more desirable one, over time. I think the "," after "another" is unneeded. Eliot --------------010707030605010403040802 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ,

Some comments:

Bottom of the introduction:

=C2=A0=C2=A0 Experience shows that many peo= ple are
=C2=A0=C2=A0 unwilling to disable older weaker algorithms; it seems= that these
=C2=A0=C2=A0 people prefer to live with weaker algorithms, sometime= s seriously
=C2=A0=C2=A0 flawed ones, to maintain interoperability with older s= oftware well
=C2=A0=C2=A0 after experts recommend migration.

There are a myriad of reasons, and this is just one important one.=C2= =A0 It may be that they are unable to make the changes because there is hardware involved that cannot support the new algorithm (footprint issues, accelerator problems, or what-have-you).=C2=A0 I w= ill hazard a guess that a more common scenario is that they have no idea how to make the changes or even that the changes are needed.=C2= =A0 My suggestion is either don't get into the "it seems..." business or to cover all the ground.

Section 2/Section 3:

There is a minor organizational issue here, and perhaps Housley's Law applies (the one about the document not being finished until all excess verbiage has been removed).=C2=A0 It looks like part of Sectio= n 3 could be merged with Section 2 (I got initially confused by some ambiguous advice in 2.1 that was cleared up in 3.1).=C2=A0 Some of Section 3 belongs with the text in Section 4.=C2=A0 Specifically, 3.3= is really tied quite closely to 4.2, 4.3, and 4.4.


Section 2.2:
=C2=A0=C2=A0 For this reason, the
=C2=A0=C2=A0 protocol MUST specify one or more mandatory-to-impleme= nt algorithm or
=C2=A0=C2=A0 suite.

It may be worth reminding people that "mandatory to implement !=3D mandatory to deploy" and holding some discussion on this point.=C2=A0= For instance, some environments may find the MTI insufficient for their purposes.

Section 2.4:


=C2=A0=C2=A0 When selecting a suite of cryptographic algorithms, th= e strength of
=C2=A0=C2=A0 each algorithm SHOULD be considered.=C2=A0 It needs to= be considered at
=C2=A0=C2=A0 the time a protocol is designed.=C2=A0 It also needs t= o be considered at
=C2=A0=C2=A0 the time a protocol implementation is deployed and con= figured.
=C2=A0=C2=A0 Advice from from experts is useful, but in reality, it= is not often
=C2=A0=C2=A0 available to system administrators that are deploying = and configuring
=C2=A0=C2=A0 a protocol implementation.=C2=A0 For this reason, prot= ocol designers
=C2=A0=C2=A0 SHOULD provide clear guidance to implementors, leading= to=C2=A0 balanced
=C2=A0=C2=A0 options being available at the time of deployment and configuration.

I'll note that most of us applications people need current advice (like some that's in this draft) just like using what's out there and available in tools like OpenSSL, but these libraries generally do not provide that advice.=C2=A0 Perhaps it would be useful t= o even have an appendix that includes translation of the advice in the draft to choices in the various libraries.=C2=A0 No, I'm not offering= to write it, and I'd understand if it gets missed because nobody else does either.

Section 4.3:

I was surprised to find that you did not follow up your earlier philosophical statement in Section 4.2 ("The idea is to have an implemented and deployed algorithm as a fallback") with some sort of SHOULD or MUST around that, either in 4.2 or 4.3.=C2=A0 Maybe it belo= ngs in 2.2 next to the MUST at the top.=C2=A0 Maybe I missed it?

Section 4.4:

This advice is largely around what happens when there is some user interface to configure systems.=C2=A0 That is unlikely to be the case= with the Internet of Many Tiny Little Things (IoMTLT).=C2=A0 Do you w= ant to give some more specific advice to top off what is being said wrt smart objects (following up from the tech plenary)?

Nittiest nit:

=C2=A0=C2=A0 Algorithm agility is achieved = when a protocol can easily migrate from
=C2=A0=C2=A0 one algorithm suite to another, more desirable one, ov= er time.

I think the "," after "another" is unneeded.

Eliot
--------------010707030605010403040802-- --xcSaanFkNckDcfDDUuVjLHdFx79Aiv0ux 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 iQEcBAEBCAAGBQJVROHQAAoJEIe2a0bZ0nozPwcIALcWgHoal2pS9lZARsFFA9dd Spl0N5PUTateo/Xy95lgmijkAKXFjvNfWhkupx00UJ8M6xhm8sdCpJETkMIpSDL9 Uf0dFvIp4R+kyKt2UQgURJGLmj96RDPLU938KWrOwIlT8pQY/+hip0I85PRy8SBa JBnAz0GqYGtXlcVO+hGwbpBuZ0aAUWksGfgZU65DdvuUivlzvJBQFq2a7yJ5fxNH xN2hsFjzkcz7IWJYZZ0ajKr9Yy+gGhFrx0uD08FO3MpPqUNLH53U9GuvKoEPRfE1 CcZBz+3gJbfw8eutuPXuM4eM+lQ8xpY9oRFSv0BL0prRudnr2+ooidwMaBFI2rE= =M6QI -----END PGP SIGNATURE----- --xcSaanFkNckDcfDDUuVjLHdFx79Aiv0ux-- From nobody Sat May 2 10:35:34 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5401A892A; Sat, 2 May 2015 10:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyLhojP3Sxiu; Sat, 2 May 2015 10:35:28 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A22D1A86E3; Sat, 2 May 2015 10:35:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B18D1F8F; Sat, 2 May 2015 19:35:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id O2x9gAYu5x_M; Sat, 2 May 2015 19:35:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 2 May 2015 19:35:26 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BD212002C; Sat, 2 May 2015 19:35:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id INR4_zrXXwor; Sat, 2 May 2015 19:35:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCFEB20013; Sat, 2 May 2015 19:35:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E7E6533026A0; Sat, 2 May 2015 19:35:21 +0200 (CEST) Date: Sat, 2 May 2015 19:35:21 +0200 From: Juergen Schoenwaelder To: "B.-C. Boesch" Message-ID: <20150502173521.GA60090@elstar.local> Mail-Followup-To: "B.-C. Boesch" , Randy Presuhn , ietf@ietf.org, OPSAWG@ietf.org, saag@ietf.org, sacm@ietf.org References: <21625111.1430433958137.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <5544C3E2.5020807@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5544C3E2.5020807@gmx.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , OPSAWG@ietf.org, ietf@ietf.org, sacm@ietf.org, saag@ietf.org Subject: Re: [saag] [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 17:35:30 -0000 On Sat, May 02, 2015 at 02:32:34PM +0200, B.-C. Boesch wrote: > > [...] With YANG and netconf the > configuration will be still vendor-specific and vendor-specific > adjustments are still needed on site of the central Manager. > This argument likely needs an explanation. There are people working quite hard towards standardized YANG models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat May 2 11:19:06 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7950C1A87E2; Sat, 2 May 2015 11:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNj3czYnwz0m; Sat, 2 May 2015 11:19:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 01AEF1A8731; Sat, 2 May 2015 11:19:02 -0700 (PDT) Received: from [192.168.2.105] ([79.246.2.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M8m7Q-1YyYAg3dF6-00C7vL; Sat, 02 May 2015 20:18:59 +0200 Message-ID: <5545150E.80207@gmx.net> Date: Sat, 02 May 2015 20:18:54 +0200 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Randy Presuhn , ietf@ietf.org, OPSAWG@ietf.org, saag@ietf.org, sacm@ietf.org References: <21625111.1430433958137.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <5544C3E2.5020807@gmx.net> <20150502173521.GA60090@elstar.local> In-Reply-To: <20150502173521.GA60090@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:kxJJX4304WEkBJCeyON0wPyTh7LBoF/oM51rU8Fot9adguBid4v 0gqD2W0IuwbzO42aXP5kDqYaxFZCpzf4zxMtJFXPm/Kdw88LBZFhNHOgCuoUv9JIRv6svXF S8JlH0Hj/8HFYerS2IcnbhlqW1F0wwRKZOhJWvDPVH09pee/93xEhZhvs3F8gtviqskJ3XI Qm708KdiLVeHeOi+IizQQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [saag] [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 18:19:03 -0000 Hi Jürgen, netconf will be used between a netconf server (Manager) and a networking device (netconf client = Analyzer). IDPEF standardize the exchanged content so that no additional information is needed at the Manager to interpret the exchanged data. With IDPEF it is not relevant which vendors of Analyzers and Manager are combined. How could the Manager interpret the configuration data of the Analyzer without any additional information (e.g. MIB) in the YANG environment? How could I change options (e.g. thresholds) of an IDS signature of any IDS vendor with YANG without additional information on the netconf server? kind regards Björn-C. Am 02.05.2015 um 19:35 schrieb Juergen Schoenwaelder: > On Sat, May 02, 2015 at 02:32:34PM +0200, B.-C. Boesch wrote: >> [...] With YANG and netconf the >> configuration will be still vendor-specific and vendor-specific >> adjustments are still needed on site of the central Manager. >> > This argument likely needs an explanation. There are people working > quite hard towards standardized YANG models. > > /js > From nobody Sat May 2 13:05:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140C21A8FD2; Sat, 2 May 2015 13:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 476GyfgsQ7id; Sat, 2 May 2015 13:05:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED5B1A8F4E; Sat, 2 May 2015 13:04:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 31110FC6; Sat, 2 May 2015 22:04:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2tbQCUWdR6XW; Sat, 2 May 2015 22:04:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 2 May 2015 22:04:39 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BBB82002B; Sat, 2 May 2015 22:04:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0TTBQBBkI_Q1; Sat, 2 May 2015 22:04:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64C8820013; Sat, 2 May 2015 22:04:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 798933302773; Sat, 2 May 2015 22:04:36 +0200 (CEST) Date: Sat, 2 May 2015 22:04:35 +0200 From: Juergen Schoenwaelder To: "B.-C. Boesch" Message-ID: <20150502200435.GA60318@elstar.local> Mail-Followup-To: "B.-C. Boesch" , Randy Presuhn , ietf@ietf.org, OPSAWG@ietf.org, saag@ietf.org, sacm@ietf.org References: <21625111.1430433958137.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <5544C3E2.5020807@gmx.net> <20150502173521.GA60090@elstar.local> <5545150E.80207@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <5545150E.80207@gmx.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , OPSAWG@ietf.org, ietf@ietf.org, sacm@ietf.org, saag@ietf.org Subject: Re: [saag] [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 20:05:06 -0000 I am confused by 'netconf server (Manager) and a networking device (netconf client = Analyzer)'. This is not how NETCONF usually works: A device runs a NETCONF server and a management application a NETCONF client. Anyway, the way things work with NETCONF and YANG is that you define a YANG data model that is understood by both the NETCONF server and the NETCONF client. I admit that I do not know much about your specific use case but if you make statements that sound like YANG models have to proprietary and hence IDPEF has an advantage because it is standardized, then you need to be able to defend that. /js On Sat, May 02, 2015 at 08:18:54PM +0200, B.-C. Boesch wrote: > Hi Jürgen, > > netconf will be used between a netconf server (Manager) and a networking > device (netconf client = Analyzer). IDPEF standardize the exchanged > content so that no additional information is needed at the Manager to > interpret the exchanged data. With IDPEF it is not relevant which > vendors of Analyzers and Manager are combined. How could the Manager > interpret the configuration data of the Analyzer without any additional > information (e.g. MIB) in the YANG environment? How could I change > options (e.g. thresholds) of an IDS signature of any IDS vendor with > YANG without additional information on the netconf server? > > kind regards > > Björn-C. > > Am 02.05.2015 um 19:35 schrieb Juergen Schoenwaelder: > >On Sat, May 02, 2015 at 02:32:34PM +0200, B.-C. Boesch wrote: > >>[...] With YANG and netconf the > >>configuration will be still vendor-specific and vendor-specific > >>adjustments are still needed on site of the central Manager. > >> > >This argument likely needs an explanation. There are people working > >quite hard towards standardized YANG models. > > > >/js > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun May 3 12:54:02 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B215F1A87D5 for ; Sun, 3 May 2015 12:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 9LH6INlHlhvz for ; Sun, 3 May 2015 12:53:58 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA091A1BFF for ; Sun, 3 May 2015 12:53:58 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 41AA76D71F; Sun, 3 May 2015 15:53:57 -0400 (EDT) Message-ID: <55467CD2.7080605@iang.org> Date: Sun, 03 May 2015 20:53:54 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> <5544E1D0.8010307@cisco.com> In-Reply-To: <5544E1D0.8010307@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 19:54:00 -0000 On 2/05/2015 15:40 pm, Eliot Lear wrote: > Hi Russ, > > Some comments: > > Bottom of the introduction: > >> Experience shows that many people are >> unwilling to disable older weaker algorithms; it seems that these >> people prefer to live with weaker algorithms, sometimes seriously >> flawed ones, to maintain interoperability with older software well >> after experts recommend migration. > > There are a myriad of reasons, and this is just one important one. It > may be that they are *unable* to make the changes because there is > hardware involved that cannot support the new algorithm (footprint > issues, accelerator problems, or what-have-you). I will hazard a guess > that a more common scenario is that they have no idea *how* to make the > changes or even that the changes are needed. My suggestion is either > don't get into the "it seems..." business or to cover all the ground. One way to look at the disable process is to ask "so what?" If we've decided in our wisdom that alg X is bad and people should upgrade to Y, so what? If the software is working for some company C, and there isn't much a of likelihood of any harm to it, why not carry on? The problem arises when Company C is talking to Company D, and the damage lands on the latter not the former. (If it lands on neither, for all combinations C & D, then we've got it wrong apparently.) So damage lands on D due to inaction by C. Sucks to be D. At this point, we might have to make a judgement call that involves the body public, because it isn't an individual equation any more, and we can't appeal to individual goodness. Hence question 1. Who is the organisation / where is the manual / who signs off on that call? How is it that we (hypothetically) issue a death notice for RC4? But, we also need some form of stick to push the laggards. That stick could be soft, or hard. For what it's worth, I see the only sensible stick being an informed opinion (of the above person) that the thing is insecure, where before it was secure. Such an informed opinion then becomes distributed, promulgated, respected, and eventually becomes evidence in court. This is often expressed as "security updates withdrawn" as per software. If hypothetically, the IETF were to issue a "RFW" or request for withdrawal, that would have the effect of creating a cost for all those laggards who didn't upgrade, leaving them to analyse their costs. Question 2, then, is what is the stick? > Section 2.4: > >> >> When selecting a suite of cryptographic algorithms, the strength of >> each algorithm SHOULD be considered. It needs to be considered at >> the time a protocol is designed. It also needs to be considered at >> the time a protocol implementation is deployed and configured. >> Advice from from experts is useful, but in reality, it is not often >> available to system administrators that are deploying and configuring >> a protocol implementation. For this reason, protocol designers >> SHOULD provide clear guidance to implementors, leading to balanced >> options being available at the time of deployment and configuration. > > I'll note that most of us applications people need current advice (like > some that's in this draft) just like using what's out there and > available in tools like OpenSSL, but these libraries generally do *not* > provide that advice. Perhaps it would be useful to even have an > appendix that includes translation of the advice in the draft to choices > in the various libraries. No, I'm not offering to write it, and I'd > understand if it gets missed because nobody else does either. The problem with bit strengths is particularly clear -- we don't actually agree with a lot of the advice out there. NIST for example runs around and tells everyone that they have to use RSA2048 but hints from Snowden at that meeting the other day indicate that RSA1024 is still cool, and others swear that 4096 must be used. Without getting into the wherefores and whys of that debate, the point is that it leads to endless wheel spinning and never seems to actually improve the security. For this reason, I suggest things like 1TCS -- because it's one go, and done. No more discussions about the numbers, as the public (which in this case is anyone after the original author) is more than likely going to get it wrong. Make the author get it right, save the effort. If I can take the author's advice on protocol design then I can take her advice on the numbers too. (The same goes for choice of different algorithms, mixing and matching, etc.) iang From nobody Sun May 3 13:27:48 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20161A88A3 for ; Sun, 3 May 2015 13:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdnhMBg1W2ZL for ; Sun, 3 May 2015 13:27:45 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1341A889F for ; Sun, 3 May 2015 13:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3693; q=dns/txt; s=iport; t=1430684865; x=1431894465; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=ObPCUlS12t2c8qjukaiRJ4xQ7ujJiLjoI8vxy0lSgSk=; b=GESyz75tWjXFgObvTaIrqC8k7YrXPOnYZEbtkpRvGlb2z+wXQzrxis4v G1GMFF3VzkLfrfKIX7ODt/48cQKprv3NohvgXhDZauQZRU09i0dcpHFIV tdWh+Z6j9/FB8+z+ewaHYrDYWajQiytnstQAINz/Ou1Ke12go4JyJzAOr U=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AwBBg0ZV/xbLJq1ch1jCWgmHWgKBdxQBAQEBAQEBgQqEIQEBAwEjQgYNEQshFgsCAgkDAgECAUUGAQwIAQGIHwiyCpJzAQEBAQEBAQMBAQEBAQEBG4s5hQyCaIFFAQSUCYE5hx2HR45XI4FlHYF0PIJ2AQEB X-IronPort-AV: E=Sophos;i="5.13,361,1427760000"; d="asc'?scan'208";a="461389441" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 May 2015 20:27:42 +0000 Received: from [10.61.80.115] (ams3-vpn-dhcp4212.cisco.com [10.61.80.115]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t43KRfgv022122; Sun, 3 May 2015 20:27:41 GMT Message-ID: <554684BD.6080700@cisco.com> Date: Sun, 03 May 2015 22:27:41 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> <5544E1D0.8010307@cisco.com> <55467CD2.7080605@iang.org> In-Reply-To: <55467CD2.7080605@iang.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XLxEIpPm1kK9MRVddwa6NGvohElS0MH2e" Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 20:27:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XLxEIpPm1kK9MRVddwa6NGvohElS0MH2e Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ian, On 5/3/15 9:53 PM, ianG wrote: > > > One way to look at the disable process is to ask "so what?" =20 I wasn't going to get into the discussion of externalities, but it would be wrong to state that there is a single reason for why devices continue to support insecure algorithms. There are many reasons. > > >> Section 2.4: >> >>> >>> When selecting a suite of cryptographic algorithms, the strength o= f >>> each algorithm SHOULD be considered. It needs to be considered at= >>> the time a protocol is designed. It also needs to be considered a= t >>> the time a protocol implementation is deployed and configured. >>> Advice from from experts is useful, but in reality, it is not ofte= n >>> available to system administrators that are deploying and >>> configuring >>> a protocol implementation. For this reason, protocol designers >>> SHOULD provide clear guidance to implementors, leading to balanced= >>> options being available at the time of deployment and configuratio= n. >> >> I'll note that most of us applications people need current advice (lik= e >> some that's in this draft) just like using what's out there and >> available in tools like OpenSSL, but these libraries generally do *not= * >> provide that advice. Perhaps it would be useful to even have an >> appendix that includes translation of the advice in the draft to choic= es >> in the various libraries. No, I'm not offering to write it, and I'd >> understand if it gets missed because nobody else does either. > > > The problem with bit strengths is particularly clear -- we don't > actually agree with a lot of the advice out there. NIST for example > runs around and tells everyone that they have to use RSA2048 but hints > from Snowden at that meeting the other day indicate that RSA1024 is > still cool, and others swear that 4096 must be used. Without getting > into the wherefores and whys of that debate, the point is that it > leads to endless wheel spinning and never seems to actually improve > the security. > > For this reason, I suggest things like 1TCS -- because it's one go, > and done. No more discussions about the numbers, as the public (which > in this case is anyone after the original author) is more than likely > going to get it wrong. Make the author get it right, save the > effort. If I can take the author's advice on protocol design then I > can take her advice on the numbers too. > If there is such a suggestion, that would be helpful. Otherwise, laying out the decision path in as much detail as is practical would be good.=20 I don't know if it needs to be in this draft, but I know this sort of information is useful. Eliot --XLxEIpPm1kK9MRVddwa6NGvohElS0MH2e 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 iQEcBAEBCAAGBQJVRoS9AAoJEIe2a0bZ0noz26gH/1FdlEDMFVz2pBsMvkOYJSw5 A2WSMgAqRDCcczCxewhVRASFIZlN/zA2T5L/8SN7/D4SQBjXKaX7sYYl+XvVJIo2 uF4lW7y0iSK+pdP+HEsdYgSGO0BbA5F3prJILEzzZNHgTDltSp20zDmbXCKy9ff+ O34MqtVoQ5Ak/OQr45LMyhuT37K5sO5fGpGCUYovWo7oWTnRzHBsFozLWOCc/dJX u8goJoT0S3IwHwNJ3HA+sdzYucBgppHIMm3UMdoM/hifz7X95mUHJfw/sOdBbDIj O6J895NKxPpu1rghwOZ53qY83LtgJazz4+L+eIWwSuxQHhYmgBSYcRARQdZkho4= =kRYO -----END PGP SIGNATURE----- --XLxEIpPm1kK9MRVddwa6NGvohElS0MH2e-- From nobody Tue May 5 05:36:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6661ACAD4 for ; Tue, 5 May 2015 05:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 KroCc0FVJRQp for ; Tue, 5 May 2015 05:36:36 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B651A92E3 for ; Tue, 5 May 2015 05:34:04 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 1567D6D7B8; Tue, 5 May 2015 08:34:02 -0400 (EDT) Message-ID: <5548B8BA.4020208@iang.org> Date: Tue, 05 May 2015 13:34:02 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Eliot Lear , saag@ietf.org References: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> <5544E1D0.8010307@cisco.com> <55467CD2.7080605@iang.org> <554684BD.6080700@cisco.com> In-Reply-To: <554684BD.6080700@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] draft-iab-crypto-alg-agility-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 12:36:43 -0000 Hi Eliot, On 3/05/2015 21:27 pm, Eliot Lear wrote: > Hi Ian, > > On 5/3/15 9:53 PM, ianG wrote: >> One way to look at the disable process is to ask "so what?" > > I wasn't going to get into the discussion of externalities, but it would > be wrong to state that there is a single reason for why devices continue > to support insecure algorithms. There are many reasons. And, to add salt to the wound, we're in the business of predicting the future. When a WG sets down a cipher suite, it decides on today info, but has to predict out to 5, 10, 20 year timeframes. The fact that we don't do well at predicting the future all the time doesn't obviate the need for some form of process/plan/etc... >>> Section 2.4: >>> >>>> >>>> When selecting a suite of cryptographic algorithms, the strength of >>>> each algorithm SHOULD be considered. It needs to be considered at >>>> the time a protocol is designed. It also needs to be considered at >>>> the time a protocol implementation is deployed and configured. >>>> Advice from from experts is useful, but in reality, it is not often >>>> available to system administrators that are deploying and >>>> configuring >>>> a protocol implementation. For this reason, protocol designers >>>> SHOULD provide clear guidance to implementors, leading to balanced >>>> options being available at the time of deployment and configuration. >>> >>> I'll note that most of us applications people need current advice (like >>> some that's in this draft) just like using what's out there and >>> available in tools like OpenSSL, but these libraries generally do *not* >>> provide that advice. Perhaps it would be useful to even have an >>> appendix that includes translation of the advice in the draft to choices >>> in the various libraries. No, I'm not offering to write it, and I'd >>> understand if it gets missed because nobody else does either. >> >> >> The problem with bit strengths is particularly clear -- we don't >> actually agree with a lot of the advice out there. NIST for example >> runs around and tells everyone that they have to use RSA2048 but hints >> from Snowden at that meeting the other day indicate that RSA1024 is >> still cool, and others swear that 4096 must be used. Without getting >> into the wherefores and whys of that debate, the point is that it >> leads to endless wheel spinning and never seems to actually improve >> the security. >> >> For this reason, I suggest things like 1TCS -- because it's one go, >> and done. No more discussions about the numbers, as the public (which >> in this case is anyone after the original author) is more than likely >> going to get it wrong. Make the author get it right, save the >> effort. If I can take the author's advice on protocol design then I >> can take her advice on the numbers too. >> > > If there is such a suggestion, that would be helpful. I don't know who else has made this suggestion, but I first wrote about it here: "Hypothesis #1 -- The One True Cipher Suite" http://iang.org/ssl/h1_the_one_true_cipher_suite.html 8th November 2007 iang > Otherwise, laying > out the decision path in as much detail as is practical would be good. > I don't know if it needs to be in this draft, but I know this sort of > information is useful. > > Eliot > > From nobody Tue May 5 05:56:09 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC621AC3EF for ; Tue, 5 May 2015 05:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIEXvBdwa1gT for ; Tue, 5 May 2015 05:56:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C501AC3FC for ; Tue, 5 May 2015 05:56:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1F24EBED5 for ; Tue, 5 May 2015 13:56:00 +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 nq2fFWbvEDx3 for ; Tue, 5 May 2015 13:55:57 +0100 (IST) Received: from [10.67.44.99] (unknown [31.55.4.234]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9F5E5BEA1 for ; Tue, 5 May 2015 13:55:57 +0100 (IST) Message-ID: <5548BDDC.4010409@cs.tcd.ie> Date: Tue, 05 May 2015 13:55:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <37B38B41-84A2-4804-AE15-B68F39B67EB0@netapp.com> In-Reply-To: <37B38B41-84A2-4804-AE15-B68F39B67EB0@netapp.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <37B38B41-84A2-4804-AE15-B68F39B67EB0@netapp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [saag] Fwd: [irtf-discuss] Call for Nominations: 2016 Applied Networking Research Prize (ANRP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 12:56:07 -0000 If there is interesting alredy-published security or privacy work you've seen that would be good to get presented at an IETF meeting, then please nominate that for the ANRP. Thanks, S. -------- Forwarded Message -------- Subject: [irtf-discuss] Call for Nominations: 2016 Applied Networking Research Prize (ANRP) Date: Tue, 5 May 2015 10:54:53 +0000 From: Eggert, Lars Reply-To: anrp@irtf.org To: irtf-discuss@irtf.org CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2016 http://irtf.org/anrp ******************************************************************** *** Submit nominations for the 2016 award period of the *** *** Applied Networking Research Prize until October 31, 2015! *** *** *** *** (Please share this announcement with your colleagues.) *** ******************************************************************** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recent results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: • cash prize of $500 (USD) • invited talk at the IRTF Open Meeting • travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) • recognition at the IETF plenary • invitation to related social activities • potential for additional travel grants to future IETF meetings, based on community feedback The Applied Networking Research Prize will be awarded once per calendar year. Each year, several winners will be chosen and invited to present their work at one of the three IETF meetings during the year. HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, original journal, conference or workshop paper they authored, which was recently published or accepted for publication. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one’s own paper) and third-party nominations (nominating someone else’s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year’s IETF meetings in person and in its entirety. Nominations must include: • the name and email address of the nominee • a bibliographic reference to the published (or accepted) nominated paper • a PDF copy of the nominated paper • a statement that describes how the nominated paper fulfills the goals of the award • a statement about which of the year’s IETF meetings the nominee would be available to attend in person and in its entirety • a brief biography or CV of the nominee • optionally, any other supporting information (link to nominee’s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2016/. In exceptional cases, nominations may also be submitted by email to anrp@irtf.org. IMPORTANT DATES Applications close: October 31, 2015 (hard) Notifications: December 1, 2015 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2016-flyer.pdf From nobody Tue May 5 13:50:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F1B1ACDD7 for ; Tue, 5 May 2015 13:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_NbdwlJGyAa for ; Tue, 5 May 2015 13:50:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED32D1ACD6A for ; Tue, 5 May 2015 13:50:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C701DBEA1; Tue, 5 May 2015 21:50:01 +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 OPabd6-SY2gc; Tue, 5 May 2015 21:50:00 +0100 (IST) Received: from [10.67.44.99] (host86-187-113-0.range86-187.btcentralplus.com [86.187.113.0]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 483A5BEB3; Tue, 5 May 2015 21:50:00 +0100 (IST) Message-ID: <55492CF5.9050904@cs.tcd.ie> Date: Tue, 05 May 2015 21:49:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "saag@ietf.org" , "cfrg@irtf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] FYI: ETSI quantum safe crypto work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 20:50:04 -0000 We've been liaised with. [1] Cheers, S. [1] https://datatracker.ietf.org/liaison/1398/ From nobody Fri May 8 08:35:22 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FE31A9034 for ; Fri, 8 May 2015 08:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 EODijL7qvGEz for ; Fri, 8 May 2015 08:35:19 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.112]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA051A9037 for ; Fri, 8 May 2015 08:35:18 -0700 (PDT) Received: from [193.109.255.99] by server-8.bemta-14.messagelabs.com id 93/04-03204-5B7DC455; Fri, 08 May 2015 15:35:17 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-7.tower-48.messagelabs.com!1431099316!9227264!1 X-Originating-IP: [195.232.244.134] X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2653 invoked from network); 8 May 2015 15:35:17 -0000 Received: from mailout02.vodafone.com (HELO mailout02.vodafone.com) (195.232.244.134) by server-7.tower-48.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 May 2015 15:35:17 -0000 Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout02.vodafone.com (Postfix) with ESMTP id 3ljwhh5jNmzbdNS for ; Fri, 8 May 2015 17:35:16 +0200 (CEST) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3ljwhh4JvDzxP4y for ; Fri, 8 May 2015 17:35:16 +0200 (CEST) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3ljwhh4GBDzxPtN for ; Fri, 8 May 2015 17:35:16 +0200 (CEST) Received: from VOEXC21W.internal.vodafone.com (145.230.103.126) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 8 May 2015 17:35:16 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.66]) by VOEXC21W.internal.vodafone.com ([145.230.103.126]) with mapi id 14.03.0224.002; Fri, 8 May 2015 17:35:15 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: "saag@ietf.org" Thread-Topic: [saag] draft-smith-encrypted-traffic-management Thread-Index: AdCJn5fS+Xrq26bHQVW9BI8AtxFFEw== Date: Fri, 8 May 2015 15:35:15 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] draft-smith-encrypted-traffic-management X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 15:35:21 -0000 Dear all, I've posted a draft on 'Network management of encrypted traffic' [1]. This = follows up from the acknowledgement in both the 'Pervasive Monitoring is an= attack' BCP [2] and the IAB statement on Internet confidentiality [3] to = strike a balance that allows non-intrusive network management to continue t= o operate. The aim of the draft is to list ways to enable this, including n= ew work (such as SPUD) looking into the problem. As such it intends to prov= ide privacy-aware solutions to the effects of encryption raised in [2]. All comments and feedback very welcome. Thanks for your time! Kevin Kevin Smith, Vodafone R&D [1] https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-manageme= nt/=20 [2] https://tools.ietf.org/html/rfc7258=20 [3] https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentialit= y/=20 [4] https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ =20 From nobody Fri May 8 09:01:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE261AC445 for ; Fri, 8 May 2015 09:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwsHLmozswGT for ; Fri, 8 May 2015 09:01:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F601AC444 for ; Fri, 8 May 2015 09:01:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 28C56BE87; Fri, 8 May 2015 17:01:29 +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 3u77T3VTIibt; Fri, 8 May 2015 17:01:29 +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 F225BBE3F; Fri, 8 May 2015 17:01:28 +0100 (IST) Message-ID: <554CDDD8.8010101@cs.tcd.ie> Date: Fri, 08 May 2015 17:01:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Smith, Kevin, (R&D) Vodafone Group" , "saag@ietf.org" References: In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] draft-smith-encrypted-traffic-management X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 16:01:33 -0000 Hi Kevin, Thanks for writing that up. I think Kathleen's maybe travelling now (or just about to) so it might be a day or so but I'm sure she'll get back about possibly merging bits of this text with [4]. Cheers, S. On 08/05/15 16:35, Smith, Kevin, (R&D) Vodafone Group wrote: > Dear all, > > I've posted a draft on 'Network management of encrypted traffic' [1]. This follows up from the acknowledgement in both the 'Pervasive Monitoring is an attack' BCP [2] and the IAB statement on Internet confidentiality [3] to strike a balance that allows non-intrusive network management to continue to operate. The aim of the draft is to list ways to enable this, including new work (such as SPUD) looking into the problem. As such it intends to provide privacy-aware solutions to the effects of encryption raised in [2]. > > All comments and feedback very welcome. Thanks for your time! > > Kevin > > Kevin Smith, Vodafone R&D > > [1] https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-management/ > [2] https://tools.ietf.org/html/rfc7258 > [3] https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ > [4] https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Fri May 8 12:59:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDA21B2F91 for ; Fri, 8 May 2015 12:59:12 -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, 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 PI_r3UyJ7SPU for ; Fri, 8 May 2015 12:59:11 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 257491B2EF5 for ; Fri, 8 May 2015 12:59:11 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 93EF29A4040 for ; Fri, 8 May 2015 15:59:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id jjQwxtQ7QBdw for ; Fri, 8 May 2015 15:58:39 -0400 (EDT) Received: from [10.67.45.117] (host217-39-8-233.in-addr.btopenworld.com [217.39.8.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2F3E79A404F for ; Fri, 8 May 2015 15:58:39 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 8 May 2015 15:57:52 -0400 Message-Id: <4D62C17D-9EB7-4D67-A9B9-651D66917B1F@vigilsec.com> To: IETF SAAG Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [saag] NIST Workshop on Elliptic Curve Cryptography Standards X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 19:59:12 -0000 Workshop on Elliptic Curve Cryptography Standards June 11-12, 2015 Agenda now available! The National Institute of Standards and Technology (NIST) will host a = Workshop on Elliptic Curve Cryptography Standards at NIST headquarters = in Gaithersburg, MD on June 11-12, 2015. The workshop will provide a = venue to engage the cryptographic community, including academia, = industry, and government users to discuss possible approaches to promote = the adoption of secure, interoperable and efficient elliptic curve = mechanisms. Register by June 4, 2015. There is no on-site registration for meetings = held at NIST. Agenda, registration and workshop details are available at the workshop = website: http://www.nist.gov/itl/csd/ct/ecc-workshop.cfm =20= From nobody Fri May 8 13:55:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147C21A88F1 for ; Fri, 8 May 2015 13:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue0XPazgHpnm for ; Fri, 8 May 2015 13:55:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770F31A8899 for ; Fri, 8 May 2015 13:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2298; q=dns/txt; s=iport; t=1431118543; x=1432328143; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fZigCXil9d4QHe2/5yn/oZG4IBqFara28mpHwDykAOI=; b=O+PbRCoGnV0PZn3cgzXVTC0osT/s/FbQOaDwBlTY9d86HTUS5q2I6jfq pnyso5xrX0b3tVMMpBcRRmg9Yel/9GMbayySQqcH4bmzYlPO6utPATlJT hTUaMs9JuWbIBvqZ+QQ8NWRDtn8v2/Rbk8+Dazt1uq5Um0wOzogh2VTy7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCBQCAIk1V/4kNJK1cgw5UXgbEI4I9CoYFAoE0TAEBAQEBAYELhCABAQEEAQEBCywrCRcEAgEIEQQBAQEKFAkHJwsUCQgCBAESCBOIEQ3IfgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEizqBT4MFOAaDEYEWBZI7hByHaZFYg1Ujg3dvgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,393,1427760000"; d="scan'208";a="418254379" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 08 May 2015 20:55:25 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t48KtOjh000562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 May 2015 20:55:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.74]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 8 May 2015 15:55:24 -0500 From: "Panos Kampanakis (pkampana)" To: "Smith, Kevin, (R&D) Vodafone Group" , "saag@ietf.org" Thread-Topic: [saag] draft-smith-encrypted-traffic-management Thread-Index: AQHQiahJMFVeuqPKlEKGBYr8H+rBOp1yhHdA Date: Fri, 8 May 2015 20:55:23 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A752658DEB8@xmb-rcd-x10.cisco.com> References: <554CDDD8.8010101@cs.tcd.ie> In-Reply-To: <554CDDD8.8010101@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.223.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] draft-smith-encrypted-traffic-management X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 20:55:45 -0000 Hi Kevin, I just wanted to point out a couple of similar to SPUD options. The PCP Flo= wdata option that was proposed in https://tools.ietf.org/html/draft-wing-pc= p-flowdata-00 is another option that operates in the same context of the en= dpoint communicating with the network to give context about the flows witho= ut compromising privacy. Also https://tools.ietf.org/html/draft-martinsen-t= ram-discuss-02 is in the same context viable only for UDP. Panos -----Original Message----- From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Friday, May 08, 2015 12:01 PM To: Smith, Kevin, (R&D) Vodafone Group; saag@ietf.org Subject: Re: [saag] draft-smith-encrypted-traffic-management Hi Kevin, Thanks for writing that up. I think Kathleen's maybe travelling now (or jus= t about to) so it might be a day or so but I'm sure she'll get back about p= ossibly merging bits of this text with [4]. Cheers, S. On 08/05/15 16:35, Smith, Kevin, (R&D) Vodafone Group wrote: > Dear all, >=20 > I've posted a draft on 'Network management of encrypted traffic' [1]. Thi= s follows up from the acknowledgement in both the 'Pervasive Monitoring is = an attack' BCP [2] and the IAB statement on Internet confidentiality [3] t= o strike a balance that allows non-intrusive network management to continue= to operate. The aim of the draft is to list ways to enable this, including= new work (such as SPUD) looking into the problem. As such it intends to pr= ovide privacy-aware solutions to the effects of encryption raised in [2]. >=20 > All comments and feedback very welcome. Thanks for your time! >=20 > Kevin >=20 > Kevin Smith, Vodafone R&D >=20 > [1]=20 > https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-managem > ent/ [2] https://tools.ietf.org/html/rfc7258 > [3]=20 > https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiali > ty/ [4] https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 >=20 _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Tue May 12 08:25:19 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73BE1A8A42 for ; Tue, 12 May 2015 08:25:17 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xtGa-zAYFf_0 for ; Tue, 12 May 2015 08:25:16 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37421A8A3A for ; Tue, 12 May 2015 08:25:15 -0700 (PDT) Received: from [85.158.136.83] by server-3.bemta-5.messagelabs.com id F1/4C-03026-A5B12555; Tue, 12 May 2015 15:25:14 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-8.tower-36.messagelabs.com!1431444313!6825007!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6053 invoked from network); 12 May 2015 15:25:14 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-8.tower-36.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 May 2015 15:25:14 -0000 Received: from mailint03.vodafone.com (mailint03.vodafone.com [195.232.244.200]) by mailout04.vodafone.com (Postfix) with ESMTP id 3lmNHF5GpjznTbD for ; Tue, 12 May 2015 17:25:13 +0200 (CEST) Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailint03.vodafone.com (Postfix) with ESMTP id 3lmNHF3jwjz16JC5 for ; Tue, 12 May 2015 17:25:13 +0200 (CEST) Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id 3lmNHF3d9fz16J0g for ; Tue, 12 May 2015 17:25:13 +0200 (CEST) Received: from VOEXC16W.internal.vodafone.com (145.230.101.18) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 12 May 2015 17:25:13 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.66]) by voexc16w.internal.vodafone.com ([145.230.101.18]) with mapi id 14.03.0224.002; Tue, 12 May 2015 17:25:12 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: "saag@ietf.org" Thread-Topic: [saag] draft-smith-encrypted-traffic-management Thread-Index: AQHQidFavQk8tPwQzkuWKI+Go6xoZZ14JXWQgABWeOA= Date: Tue, 12 May 2015 15:25:11 +0000 Message-ID: References: <554CDDD8.8010101@cs.tcd.ie> <1C9F17D1873AFA47A969C4DD98F98A752658DEB8@xmb-rcd-x10.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] draft-smith-encrypted-traffic-management X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 15:25:18 -0000 Hi Panos, Thanks for the feedback. I have added these as issues to the git repo at: https://github.com/Kevsy/encrypted-traffic-management/ ...and I will be releasing a revised version of the I-D with these suggesti= ons (and others) incorporated in a couple of weeks. All best Kevin=20 -----Original Message----- From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]=20 Sent: 08 May 2015 21:55 To: Smith, Kevin, (R&D) Vodafone Group; saag@ietf.org Subject: RE: [saag] draft-smith-encrypted-traffic-management Hi Kevin, I just wanted to point out a couple of similar to SPUD options. The PCP Flo= wdata option that was proposed in https://tools.ietf.org/html/draft-wing-pc= p-flowdata-00 is another option that operates in the same context of the en= dpoint communicating with the network to give context about the flows witho= ut compromising privacy. Also https://tools.ietf.org/html/draft-martinsen-t= ram-discuss-02 is in the same context viable only for UDP. Panos -----Original Message----- From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Friday, May 08, 2015 12:01 PM To: Smith, Kevin, (R&D) Vodafone Group; saag@ietf.org Subject: Re: [saag] draft-smith-encrypted-traffic-management Hi Kevin, Thanks for writing that up. I think Kathleen's maybe travelling now (or jus= t about to) so it might be a day or so but I'm sure she'll get back about p= ossibly merging bits of this text with [4]. Cheers, S. On 08/05/15 16:35, Smith, Kevin, (R&D) Vodafone Group wrote: > Dear all, >=20 > I've posted a draft on 'Network management of encrypted traffic' [1]. Thi= s follows up from the acknowledgement in both the 'Pervasive Monitoring is = an attack' BCP [2] and the IAB statement on Internet confidentiality [3] t= o strike a balance that allows non-intrusive network management to continue= to operate. The aim of the draft is to list ways to enable this, including= new work (such as SPUD) looking into the problem. As such it intends to pr= ovide privacy-aware solutions to the effects of encryption raised in [2]. >=20 > All comments and feedback very welcome. Thanks for your time! >=20 > Kevin >=20 > Kevin Smith, Vodafone R&D >=20 > [1]=20 > https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-managem > ent/ [2] https://tools.ietf.org/html/rfc7258 > [3]=20 > https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiali > ty/ [4] https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 >=20 _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Sat May 16 09:47:42 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9071B2C61 for ; Wed, 6 May 2015 09:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_LOW=-0.7, 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 0LJU8-S9qLpX for ; Wed, 6 May 2015 09:44:24 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF3C1A1BE7 for ; Wed, 6 May 2015 09:44:24 -0700 (PDT) Received: from pps.filterd (m0004347 [127.0.0.1]) by m0004347.ppops.net (8.14.5/8.14.5) with SMTP id t46GfZAx007091 for ; Wed, 6 May 2015 09:44:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=facebook; bh=2p6U3EJrGuPeGXCmz5pcWiMrqu/1yc46atQExwZbxy8=; b=dOeOjgvtr3G3MSVYUoR+gpeO10C9rJCxCPiZHs9s0d6hQNi8FIi1+A5/i80bEW67foEN tf/5YNLyXj9n0+sL2StEf/1zFCYui8XXup4cweKwD7joI2pysEE3hRvdzZT+ZZtGkfjf xe7EhStinUgyjBQwsrCAS/9+KjVCigbH2b8= Received: from mail.thefacebook.com ([199.201.64.23]) by m0004347.ppops.net with ESMTP id 1u7cpgh51u-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 06 May 2015 09:44:23 -0700 Received: from PRN-MBX02-3.TheFacebook.com ([169.254.5.145]) by PRN-CHUB16.TheFacebook.com ([fe80::7948:a494:45d7:3dd9%12]) with mapi id 14.03.0195.001; Wed, 6 May 2015 09:44:22 -0700 From: Brad Hill To: "saag@ietf.org" Thread-Topic: Call for review: Subresource Integrity Thread-Index: AdCIG9vt7EGxw2kfT7CqJJuBedYBVw== Date: Wed, 6 May 2015 16:44:21 +0000 Message-ID: <71512C0F85CD764C8AB1CCDCA2FA4FE807CC70E3@PRN-MBX02-3.TheFacebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-06_04:2015-05-05,2015-05-06,1970-01-01 signatures=0 Archived-At: X-Mailman-Approved-At: Sat, 16 May 2015 09:47:36 -0700 Subject: [saag] Call for review: Subresource Integrity X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 16:44:25 -0000 SAAG members and interested parties, The WebAppSec WG at the W3C plans to advance Subresource Integrity to Candi= date Recommendation soon and is asking for wide review of the specification= . This specification defines a mechanism by which user agents may verify that= a fetched resource has been delivered without unexpected manipulation. http://w3c.github.io/webappsec/specs/subresourceintegrity/ If you wish to make comments regarding this document, please send them to p= ublic-webappsec@w3.org with [SRI] at the start of your email's subject. All= comments are welcome. Further sharing of this call for wide review among other interested communi= ties is encouraged. Thank you, Brad Hill From nobody Sat May 16 09:47:44 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF63B1A0107; Thu, 30 Apr 2015 13:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfeqrDys53cM; Thu, 30 Apr 2015 13:57:49 -0700 (PDT) Received: from extmail1.yaanatech.com (extmail1.yaanatech.com [63.128.177.51]) by ietfa.amsl.com (Postfix) with ESMTP id B42651A00D4; Thu, 30 Apr 2015 13:57:49 -0700 (PDT) Received: from [192.168.1.51] (pool-70-106-196-128.clppva.fios.verizon.net [70.106.196.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id A909958093; Thu, 30 Apr 2015 21:02:46 +0000 (UTC) Message-ID: <5542974B.9080208@yaanatech.com> From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "B.-C. Boesch" , saag@ietf.org, sacm@ietf.org, ietf@ietf.org, OPSAWG@ietf.org, Kathleen Moriarty References: <5540ED82.5060905@gmx.net> In-Reply-To: <5540ED82.5060905@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Sat, 16 May 2015 09:47:38 -0700 Subject: Re: [saag] [sacm] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tony@yaanatech.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 30 Apr 2015 20:57:51 -0000 X-Original-Date: Thu, 30 Apr 2015 16:57:47 -0400 X-List-Received-Date: Thu, 30 Apr 2015 20:57:51 -0000 How is this not like STIX? -t On 2015-04-29 10:41 AM, B.-C. Boesch wrote: > Abstract > > The Intrusion Detection Parametrization Exchange Format (IDPEF)=20 > defines data formats and exchange procedures to standardize=20 > parametrization information exchange into intrusion detection and=20 > response systems from an independent central Manager to any Analyzer.=20 > The IDPEF enables a combination of different (vendor and analyzing=20 > technique) IDS Analyzers under one independent central Manager. A=20 > separate operations of IDS is not longer needed. Base is a new=20 > parametrization methodology where IDS operating parameters=20 > (configurations) are separated in an environmental parametrization=20 > part and a vendor-specific analyzing part. > > This Internet-Draft describes a data model to represent=20 > parametrization information of intrusion detection system entities,=20 > and explains the rationale for using this model. An implementation of=20 > the data model in the Extensible Markup Language (XML) is presented, a = > XML Document Type Definition is developed, and parametrization=20 > examples are provided. From nobody Thu May 21 12:45:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99391A898C for ; Thu, 21 May 2015 12:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etES66dOYJfM for ; Thu, 21 May 2015 12:45:18 -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 E1D481A8966 for ; Thu, 21 May 2015 12:45:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWJ18235; Thu, 21 May 2015 19:45:06 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 20:45:04 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Thu, 21 May 2015 12:45:01 -0700 From: Lucy yong To: "saag@ietf.org" Thread-Topic: New Version Notification for draft-hy-gue-4-secure-transport-02.txt Thread-Index: AQHQk/j8kieQQTAAUkyr2C6kOEtYL52G0VtQ Date: Thu, 21 May 2015 19:45:00 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5717F8EE@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.191] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [saag] FW: New Version Notification for draft-hy-gue-4-secure-transport-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 19:45:19 -0000 SGVsbG8sDQoNCkZZSS4gR2VuZXJpYyBVRFAgRW5jYXBzdWxhdGlvbiAoR1VFKSBwcm90b2NvbCBp cyBub3cgdW5kZXIgZGV2ZWxvcG1lbnQgaW4gTlZPMyBXRyBpbiBSb3V0aW5nIEFyZWEuIEdVRSBj YW4gYmUgdXNlZCBmb3IgbmV0d29yayB0dW5uZWwgZW5jYXBzdWxhdGlvbiBvciB0cmFuc3BvcnQg bGF5ZXIgZW5jYXBzdWxhdGlvbi4gR1VFIGNvbnRhaW5zIGJhc2ljIGVuY2Fwc3VsYXRpb24gc2No ZW1hIHdpdGggc29tZSBvcHRpb25hbCBjYXBhYmlsaXRpZXMuDQoNCkdVRSBkZXNpZ25hdGVzIHR3 byBvcHRpb25zIGZvciBzZWN1cmUgdHJhbnNwb3J0IHB1cnBvc2UuIE9uZSBvcHRpb24gaXMgZm9y IEdVRSBoZWFkZXIgaW50ZWdyaXR5IHByb3RlY3Rpb24gYW5kIGF1dGhlbnRpY2F0aW9uOyBhbm90 aGVyIG9wdGlvbiBpcyBmb3IgR1VFIHBheWxvYWQgZW5jcnlwdGlvbi4NCg0KVGhpcyBkcmFmdCBz cGVjaWZpZXMgdGhlc2UgdHdvIG9wdGlvbnMuIFdlIGxpa2UgdG8gYWRhcHQgZXhpc3Rpbmcgc2Vj dXJpdHkgbWVjaGFuaXNtcyBhbmQgc2VlayBzb21lIGNvbW1lbnQvc3VnZ2VzdGlvbiBvbiB0aGlz IHByb3Bvc2FsLiBXZWxjb21lIHNvbWUgc2VjdXJpdHkgZXhwZXJ0IHRvIGpvaW50IHdvcmsgb24g dGhlIHNvbHV0aW9uLiANCg0KVGhhbmtzLA0KTHVjeSAgDQo+ICAgDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIE1heSAyMSwgMjAxNSAyOjA0 IFBNDQpUbzogVG9tIEhlcmJlcnQ7IFRvbSBIZXJiZXJ0OyBMdWN5IHlvbmc7IEx1Y3kgeW9uZw0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oeS1ndWUtNC1zZWN1 cmUtdHJhbnNwb3J0LTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oeS1n dWUtNC1zZWN1cmUtdHJhbnNwb3J0LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBMdWN5IFlvbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpO YW1lOgkJZHJhZnQtaHktZ3VlLTQtc2VjdXJlLXRyYW5zcG9ydA0KUmV2aXNpb246CTAyDQpUaXRs ZToJCUdlbmVyaWMgVURQIEVuY2Fwc3VsYXRpb24gKEdVRSkgZm9yIFNlY3VyZSBUcmFuc3BvcnQN CkRvY3VtZW50IGRhdGU6CTIwMTUtMDUtMjANCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczoJCTExDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWh5LWd1ZS00LXNlY3VyZS10cmFuc3BvcnQtMDIudHh0DQpTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHktZ3VlLTQt c2VjdXJlLXRyYW5zcG9ydC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaHktZ3VlLTQtc2VjdXJlLXRyYW5zcG9ydC0wMg0KRGlmZjogICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1oeS1ndWUtNC1zZWN1cmUt dHJhbnNwb3J0LTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhl IGFiaWxpdHkgb2YgR2VuZXJpYyBVRFAgRW5jYXBzdWxhdGlvbg0KICAgKEdVRSkgW0dVRV0gdG8g cHJvdmlkZSBzZWN1cmUgdHJhbnNwb3J0IG92ZXIgSVAgbmV0d29ya3MgYW5kIHRoZQ0KICAgSW50 ZXJuZXQsIGluY2x1ZGluZyBHVUUgaGVhZGVyIGludGVncml0eSBwcm90ZWN0aW9uIGFuZCBvcmln aW4NCiAgIGF1dGhlbnRpY2F0aW9uIGFuZCBHVUUgcGF5bG9hZCBlbmNyeXB0aW9uLiBUaGVzZSBh cmUgb3B0aW9uYWwNCiAgIGZlYXR1cmVzIG9mIEdVRS4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K From nobody Thu May 21 12:50:15 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7476B1A89A9 for ; Thu, 21 May 2015 12:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-aAoCvniBvD for ; Thu, 21 May 2015 12:50:11 -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 20D601A89A8 for ; Thu, 21 May 2015 12:50:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWJ18488; Thu, 21 May 2015 19:50:09 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 20:50:09 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Thu, 21 May 2015 12:50:04 -0700 From: Lucy yong To: "saag@ietf.org" Thread-Topic: New Version Notification for draft-hy-gue-4-secure-transport-02.txt Thread-Index: AQHQk/j8kieQQTAAUkyr2C6kOEtYL52G0VtQgAAFITA= Date: Thu, 21 May 2015 19:50:03 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5717F900@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.191] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [saag] New Version Notification for draft-hy-gue-4-secure-transport-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 19:50:13 -0000 SGVyZSBpcyB0aGUgaW5mb3JtYXRpb24gYWJvdXQgR1VFOiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1udm8zLWd1ZS0wMA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBMdWN5IHlvbmcgDQpTZW50OiBUaHVyc2RheSwgTWF5IDIxLCAyMDE1IDI6NDYg UE0NClRvOiAnc2FhZ0BpZXRmLm9yZycNClN1YmplY3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWh5LWd1ZS00LXNlY3VyZS10cmFuc3BvcnQtMDIudHh0DQoNCkhlbGxv LA0KDQpGWUkuIEdlbmVyaWMgVURQIEVuY2Fwc3VsYXRpb24gKEdVRSkgcHJvdG9jb2wgaXMgbm93 IHVuZGVyIGRldmVsb3BtZW50IGluIE5WTzMgV0cgaW4gUm91dGluZyBBcmVhLiBHVUUgY2FuIGJl IHVzZWQgZm9yIG5ldHdvcmsgdHVubmVsIGVuY2Fwc3VsYXRpb24gb3IgdHJhbnNwb3J0IGxheWVy IGVuY2Fwc3VsYXRpb24uIEdVRSBjb250YWlucyBiYXNpYyBlbmNhcHN1bGF0aW9uIHNjaGVtYSB3 aXRoIHNvbWUgb3B0aW9uYWwgY2FwYWJpbGl0aWVzLg0KDQpHVUUgZGVzaWduYXRlcyB0d28gb3B0 aW9ucyBmb3Igc2VjdXJlIHRyYW5zcG9ydCBwdXJwb3NlLiBPbmUgb3B0aW9uIGlzIGZvciBHVUUg aGVhZGVyIGludGVncml0eSBwcm90ZWN0aW9uIGFuZCBhdXRoZW50aWNhdGlvbjsgYW5vdGhlciBv cHRpb24gaXMgZm9yIEdVRSBwYXlsb2FkIGVuY3J5cHRpb24uDQoNClRoaXMgZHJhZnQgc3BlY2lm aWVzIHRoZXNlIHR3byBvcHRpb25zLiBXZSBsaWtlIHRvIGFkYXB0IGV4aXN0aW5nIHNlY3VyaXR5 IG1lY2hhbmlzbXMgYW5kIHNlZWsgc29tZSBjb21tZW50L3N1Z2dlc3Rpb24gb24gdGhpcyBwcm9w b3NhbC4gV2VsY29tZSBzb21lIHNlY3VyaXR5IGV4cGVydCB0byBqb2ludCB3b3JrIG9uIHRoZSBz b2x1dGlvbi4gDQoNClRoYW5rcywNCkx1Y3kgIA0KPiAgIA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBNYXkgMjEsIDIwMTUgMjowNCBQTQ0K VG86IFRvbSBIZXJiZXJ0OyBUb20gSGVyYmVydDsgTHVjeSB5b25nOyBMdWN5IHlvbmcNClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHktZ3VlLTQtc2VjdXJlLXRy YW5zcG9ydC0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHktZ3VlLTQt c2VjdXJlLXRyYW5zcG9ydC0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgTHVjeSBZb25nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJ CWRyYWZ0LWh5LWd1ZS00LXNlY3VyZS10cmFuc3BvcnQNClJldmlzaW9uOgkwMg0KVGl0bGU6CQlH ZW5lcmljIFVEUCBFbmNhcHN1bGF0aW9uIChHVUUpIGZvciBTZWN1cmUgVHJhbnNwb3J0DQpEb2N1 bWVudCBkYXRlOgkyMDE1LTA1LTIwDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFn ZXM6CQkxMQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1oeS1ndWUtNC1zZWN1cmUtdHJhbnNwb3J0LTAyLnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh5LWd1ZS00LXNlY3Vy ZS10cmFuc3BvcnQvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWh5LWd1ZS00LXNlY3VyZS10cmFuc3BvcnQtMDINCkRpZmY6ICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaHktZ3VlLTQtc2VjdXJlLXRyYW5z cG9ydC0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBhYmls aXR5IG9mIEdlbmVyaWMgVURQIEVuY2Fwc3VsYXRpb24NCiAgIChHVUUpIFtHVUVdIHRvIHByb3Zp ZGUgc2VjdXJlIHRyYW5zcG9ydCBvdmVyIElQIG5ldHdvcmtzIGFuZCB0aGUNCiAgIEludGVybmV0 LCBpbmNsdWRpbmcgR1VFIGhlYWRlciBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBhbmQgb3JpZ2luDQog ICBhdXRoZW50aWNhdGlvbiBhbmQgR1VFIHBheWxvYWQgZW5jcnlwdGlvbi4gVGhlc2UgYXJlIG9w dGlvbmFsDQogICBmZWF0dXJlcyBvZiBHVUUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg== From nobody Fri May 22 14:59:40 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B71D1A8956 for ; Fri, 22 May 2015 14:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYlRictQhUM4 for ; Fri, 22 May 2015 14:59:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07B51A894F for ; Fri, 22 May 2015 14:59:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7B578BF07 for ; Fri, 22 May 2015 22:59:35 +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 fGmOCH5fczMG for ; Fri, 22 May 2015 22:59:34 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.24.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2AD9BBF04 for ; Fri, 22 May 2015 22:59:34 +0100 (IST) Message-ID: <555FA6C5.5000004@cs.tcd.ie> Date: Fri, 22 May 2015 22:59:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "saag@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 21:59:38 -0000 Hiya, Russ has been working this draft [1] for a while now, has gotten good feedback along the road and has now asked me if I'd AD sponsor it as a BCP that documents some of what we want protocols to do in terms of cryptographic algorithm agility and picking MTI algorithms. I think it'd be good to have such a BCP if we get IETF consensus on the content, so all going well, I do plan to start an IETF LC on this around the end of June (after I do some vacating:-). That would mean we could take some f2f time in Prague to discuss it if needed. In the meantime, I'd appreciate it if folks on this list could give some feedback on the draft. Of course a detailed review is most welcome, but it'd also be good to see expressions of support for it becoming a BCP, or expressions of opposition to that, as the case may be. (As always, saying why is much better than a simple +1 or -1) So please try to take the time to give this a read in the next month and say what you think about it. (Treat this as a kinda-sorta-WGLC-like thing I guess.) Thanks, Stephen. [1] https://tools.ietf.org/html/draft-iab-crypto-alg-agility From nobody Fri May 22 16:02:59 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4B41A898A for ; Fri, 22 May 2015 16:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK-risWqzD_V for ; Fri, 22 May 2015 16:02:55 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C774D1A8989 for ; Fri, 22 May 2015 16:02:55 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so1501843igb.0 for ; Fri, 22 May 2015 16:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8RfwWOZfOZM0ljevD7z5XEqoeeV6BM/8QI3F/Z7ZBv4=; b=APPE1NbGj5RPeMpWv3iGYfG4uheSNIUrwo4Y22T2TC2QPldKgfaEX8iR4eXx/UOcFH ecwP1GfcfpVNp0ooqsRjc0kvZ1BJ1/WTd2RPaHi4e6De77Vqg3+eFvxeFLjD+/mszui1 zUc0vI9ghOTlL46RpbvskJ1tl6tw0+l94HAnXjYunztA63MXj8MZIRAt3b9WFwqreMXt /ynjQzSMCCOE/bX1dGF4h9ZfcSg1fzmQZ61AA3IDmn8KgLqvKXlFoYmFHAFqdu5bAR8M zKsRGw8vEKT8UEdxt5+x1x4xbI+0niBwb3bndA45r0zg2TuY9AEzOblKsN3X8TmVykub P4dQ== MIME-Version: 1.0 X-Received: by 10.107.6.30 with SMTP id 30mr9731439iog.35.1432335775344; Fri, 22 May 2015 16:02:55 -0700 (PDT) Received: by 10.64.76.106 with HTTP; Fri, 22 May 2015 16:02:55 -0700 (PDT) In-Reply-To: <555FA6C5.5000004@cs.tcd.ie> References: <555FA6C5.5000004@cs.tcd.ie> Date: Fri, 22 May 2015 16:02:55 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:02:57 -0000 On 22 May 2015 at 14:59, Stephen Farrell wrote: > So please try to take the time to give this a read > in the next month and say what you think about it. > (Treat this as a kinda-sorta-WGLC-like thing I guess.) A few comments. I think that this needs a little more work. Cipher suites include Diffie-Hellman or RSA without specifying a particular public key length. This is unnecessarily specific. While we often choose primitives that are coupled to a particular strength (e.g. AES-GCM with 128-bit keys and authentication tags is common, but those aren't the only options), some algorithms permit flexibility in their strength, including the number of rounds, key sizes, authentication tags, prime group size, etc... The section (2.4) that this appears in addresses matching relative strengths of primitives in a suite: not using 16384-bit DH to protect a triple-DES symmetric key, for instance. That suggests that this is two sections: 1. pick sizes, or provide a way to negotiate sizes (and in negotiating, be sure to avoid the downgrades of S2.3) 2. pick sizes that are roughly comparable strength And here we come to the "unless" part. Protocols have very different things riding on the different keys. Authentication primitives (signing, authentication tags, MAC) could require real-time attacks to be exploited in some contexts, like the authentication tag in TLS. Or at least attackers are constrained in time (breaking a certificate key after the certificate expired is of significantly less value to an attacker). On the other hand, breaks in symmetric crypto or key exchange for something like TLS have significant value to an attacker in recovering plaintext on recorded sessions. I think that this level of nuance isn't necessary to capture, but acknowledging that this is at least a little bit more complicated would be good. In S2.5, this is a bit of a non-sequitur without context: "While RSA with a 2048-bit public key is quite a bit stronger than SHA-1". The point is that these are widely deployed and available, even if one is not considered adequately strong. The point that the RSA is "strong enough" might not be so obvious to a future audience. The note in Section 3.2 on Performance belongs elsewhere. Likely in the section on strength (or two sections if you take my suggestion). Section 3.3 could be expanded to emphasize the social aspects of this. This is largely a social problem, and a difficult one: for browsers, we don't want to break sites because we lose users by doing so, that creates incentives to stay busted, but interoperable. We've found in browser-land that coordinating response can be highly effective at reducing defection. Section 4.1 neglects to mention the obvious benefit in selecting something that lots of other people are using too. That's a non-trivial advantage over and above the reasons cited (though many of them might be considered different ways of saying the same thing). I find Section 4.6 baffling. We have words that we can use for these things. They are MUST NOT, MUST and SHOULD. None of these attempt to presage the future. But generating new conventions for what might or might not happen in the future is much harder than waiting and just making the change when the time comes. For instance, if TLS 1.3 doesn't mandate use of 25519, we could use SHOULD+. OR, we can say SHOULD and then write a new document that upgrades 25519 to MUST when we decide that's a good time. It stands as much chance of being ignored as a SHOULD+, of course, but it doesn't have the problems with predicting the future that SHOULD+ invokes. From nobody Sat May 23 07:35:48 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A1A1A1B48; Sat, 23 May 2015 07:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuhBST7vzYxt; Sat, 23 May 2015 07:35:43 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FD51A1B6B; Sat, 23 May 2015 07:35:42 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4NEZROp030315 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 23 May 2015 16:35:29 +0200 Date: Sat, 23 May 2015 16:35:26 +0200 From: Simon Josefsson To: Karthikeyan Bhargavan Message-ID: <20150523163526.7e7d5e14@latte.josefsson.org> In-Reply-To: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <20150216115457.3c16fdbf@latte.josefsson.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/.hvmA=uvI9hcR2USMr=tHVP"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 14:35:44 -0000 --Sig_/.hvmA=uvI9hcR2USMr=tHVP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > I have a separate question: would there be value in defining a new > session-level channel binding (updating rfc5929) based on > tls-session-hash? I offered https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 as an alternative to tls-unique back in the days. The issue with using only the client/server-random (a'la TLS Finished) was discussed back then and for -01 in 2008 I fixed the construct to be more secure (credit to Eric Rescorla and Sam Hartman who made me aware of the concern). My draft derives the channel binding in a way similar to tls-session-hash. I would appreciate if you could take a look and tell me if you believe that it would solve the triple-handshake concern. /Simon --Sig_/.hvmA=uvI9hcR2USMr=tHVP Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVYJAuAAoJEIYLf7sy+BGdyvoH/jop/Fr3jQP6ceR15F/S6Ac/ bwuPbeNAu8CuRcmTeidjlWKneysggtJQwfun0aNeBgkzYbUXzxZ5PQyKWaLfu+Q5 yrXI9+ZvOeGf3K56E6ztHkr5qsRy1DK+V7ZwwBWbpDQFYeWGtST+vSOQcQ3/bybS 1uDTFBMGW51WL+elo06ype8NOZxKx9rZmPMWICzo19cB0ZvKz0O9twQ3k0IcwDQe cfpxqHhJSPQehu+xCN28iEN+dnTD7YlQgq0K/938zisZY/rtAVh11LuVv9ezfjnb TiYUpcIhEO43gtHcOszeVCTArAbUXIWK7+O+6XmQmvcVd/UwRQAvAQUGdrPIy4c= =PNiz -----END PGP SIGNATURE----- --Sig_/.hvmA=uvI9hcR2USMr=tHVP-- From nobody Sat May 23 10:34:55 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01B51A1B5D for ; Sat, 23 May 2015 10:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 Xw29ETM4RcWs for ; Sat, 23 May 2015 10:34:49 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3B31A1B0B for ; Sat, 23 May 2015 10:34:49 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 2722B6D756; Sat, 23 May 2015 13:34:45 -0400 (EDT) Message-ID: <5560BA33.7000300@iang.org> Date: Sat, 23 May 2015 18:34:43 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <555FA6C5.5000004@cs.tcd.ie> In-Reply-To: <555FA6C5.5000004@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 17:34:54 -0000 On 22/05/2015 22:59 pm, Stephen Farrell wrote: > > Hiya, > > Russ has been working this draft [1] for a while now, > has gotten good feedback along the road and has now > asked me if I'd AD sponsor it as a BCP that documents > some of what we want protocols to do in terms of > cryptographic algorithm agility and picking MTI > algorithms. > > I think it'd be good to have such a BCP if we get IETF > consensus on the content, so all going well, I do plan > to start an IETF LC on this around the end of June (after > I do some vacating:-). That would mean we could take > some f2f time in Prague to discuss it if needed. > > In the meantime, I'd appreciate it if folks on this > list could give some feedback on the draft. Of course > a detailed review is most welcome, but it'd also be > good to see expressions of support for it becoming a > BCP, or expressions of opposition to that, as the case > may be. (As always, saying why is much better than a > simple +1 or -1) > > So please try to take the time to give this a read > in the next month and say what you think about it. > (Treat this as a kinda-sorta-WGLC-like thing I guess.) > > Thanks, > Stephen. > > [1] https://tools.ietf.org/html/draft-iab-crypto-alg-agility My thoughts on 4.3. 1. The content is not easy to endorse. Clearly it is written from a stalwart position of "bad idea" without actually getting into the logic and accepting that there is a place and time for this approach. Indeed if the entire document were written to accept that in some circumstances there is merit in 1TCS then consensus might be easier. I for one don't approve of the document. Perversely, I'm fine with the title :) although I'd prefer the more canonical version of *One True Cipher Suite considered harmful* . It is of course an irony and an honour! 2. 4.3/1 First para "It is much better..." just assumes that the only mistakes that occur are in the algorithm choice. Statistically it is the other way around, most mistakes are in the protocol, in which case the protocol itself must be transitioned. In which case we have only a nominal or occasional stress on needing to transition just an algorithm. Section 2.3 / para 3 agrees, by saying "Sadly, this has happened..." 3. second para, same criticism. It would be very nice for someone to actually surface a list of when algorithms have been catastrophically broken, versus a list of similar breaks with protocols. I know I say it doesn't happen very much, but it's not as if anyone has sat down and worked it out. This might be a good masters thesis for someone? 4. 3th para. WEP. So, this is an example, as grumbled above. But was RC4 broken? Or was the protocol broken? In practice it was due to the small key, small IV. Would a choice of algorithms have saved anyone? I reckon not, for two reasons. Firstly, the product was designed to be weak, and the weakness would have just carried across. Like, DES with 40 bit keys instead of RC4, etc. Secondly, the market for these devices was never really set up for any sort of widescale upgrade of the parameters, so regardless of any claim that "RC4 broken, must switch" few would likely have done it. In practice, the OODA loop for switching an algorithm would likely be the same as upgrading all the hardware by buying new kit. So don't bother? Indeed if we were to add algorithm agility to WiFi, imagine the chaos in user-land. WiFi is already a big tricky because nobody out there knows what the choices mean, so they rely on defaults to get it right. What I'm saying here is that the case for switching the algorithm in WiFi is particularly murky, and is no sense related to the science of protocols. 5. 4th para -- SHA-1 to SHA-256 over 5 years. Probably true. And in the interim it was far more important to upgrade through the TLS versions, so why later generations were still using SHA-1 remains a mystery. The first failure remediation in TLS that I measured took about 3.5 years, and that's when they were trying real hard. It was a protocol breach of course, not an algorithm break. Discussion also applies to algorithmic agility as well. The whale that is missing from the whole document is how to implement a switch. Without this, advice for algorithmic agility is negligent - IETF is encouraging people to use a protocol design pattern without any clear or plausible manual in how to enjoy the fruits of that method. Section 2.3 hints at this but provides no meat. this: "Protocols MUST facilitate the selection to the best algorithm or suite..." is not as helpful because (a) the selection protocol itself is hard coded with this algorithm, so can't be switched without upgrade, and (b) it assumes a definition of "best" which either requires external instructions (a cipher negotiation list) or it just puts the point on the fact that the only experts of any credibility here are the original protocol designers. A point which is made in sections 2.4, 4.1! Section 3.2 ditto. Section 4.2 agrees with "the manner by which system administrators are advised to switch algorithms or suites is at best ad hoc, and at worst entirely absent." There is begrudging acceptance that upgrading the entire protocol version number is one way to upgrade the cipher suite. 4.6 might be the only new contribution as to how to move forward on algorithms. iang From nobody Sun May 24 00:05:30 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405C91A875D for ; Sun, 24 May 2015 00:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGs3SbGqkwWT for ; Sun, 24 May 2015 00:05:24 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992471A8783 for ; Sun, 24 May 2015 00:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1432450866; x=1463986866; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DXxAoh6Euquuk0JTNGWVlI7k15fAPGPXxt5TkLH4ljs=; b=a0fnlV4uhGTmVJfU4zvUBrlGcAJjqx/FPHg0tUdaYYAcAFS8JVKBQEs8 uB5GyfzXjDdvw55/eItWBwD08MCTLoaFmc7pWX3HFpyBTD7Vpe5/CrWpP /iAIAdsqKxKtYu+GmVvNc2krIPygjC3oxC+YaeuLw5hIqpjQqJ2RTNVod Za+/PSRhuLApUiHIB3MQs0lVdcnrNH6VvOMcOyb+RsFrtIipIPaLYfe5D pDwBhFYoe4fIWcIoqPqSFqyIzgiR2rzoruRMRU0Vu0xqrrKZeXpd0q5XB ibVwVh4kSp8Z+dpUNYhxGkeUtAukmDF4Gx3WeMfkXL1RkAlRoOBQz41eb Q==; X-IronPort-AV: E=Sophos;i="5.13,485,1427713200"; d="scan'208";a="17933813" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 24 May 2015 19:01:03 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Sun, 24 May 2015 19:01:03 +1200 From: Peter Gutmann To: ianG , "saag@ietf.org" Thread-Topic: [saag] AD sponsoring draft-iab-crypto-alg-agility Thread-Index: AQHQlNqfgo19hZCMhE6oLTR7m3xfZp2JCqKAgAGqHuA= Date: Sun, 24 May 2015 07:01:02 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie>,<5560BA33.7000300@iang.org> In-Reply-To: <5560BA33.7000300@iang.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 07:05:28 -0000 ianG writes:=0A= =0A= >4. 3th para. WEP. So, this is an example, as grumbled above. But was R= C4=0A= >broken? Or was the protocol broken? In practice it was due to the small = key,=0A= >small IV.=0A= =0A= Apart from an initial comment on the draft I've tried to avoid getting=0A= involved in a debate over this since I think the issue is at least as much = (if=0A= not more) religious than technical. For example I can use Russ' WEP exampl= e=0A= to argue exactly the opposite of the point he's trying to make: The problem= =0A= with WEP wasn't a 1TCS one, it was that it was designed by non-cryptographe= rs,=0A= and was badly broken. If they'd gone with four cipher suites instead of one= ,=0A= we'd just have four badly broken ones instead of one, or, worse, three badl= y=0A= broken ones and one not-quite-as-broken one so they could tell everyone to = use=0A= the not-quite-as-bad one.=0A= =0A= >The whale that is missing from the whole document is how to implement a=0A= >switch.=0A= =0A= Yup. Or, better, the option "choose a good 1TCS and go with it". Nearly 2= 0=0A= years ago when I did my SSL implementation, I chose as default RSA + 3DES += =0A= SHA1 (RSA dictated by the fact that at that time servers were relatively=0A= powerful and clients weren't, and RSA's asymmetry helped). If I'd implemen= ted=0A= nothing else, I'd still be about as secure today as I would with any more= =0A= modern suite (various side-channel attacks, the EtM issue, and others are= =0A= separate issues since they affect all cipher suites, not just that one, so= =0A= you're in trouble no matter what suite you select).=0A= =0A= As PHB has pointed out in a thread on the OpenPGP list, the problems we're= =0A= seeing, over and over again, last week's toy-crypto DH being only the most= =0A= recent example, is caused by too many cipher suites, not too few. If there= 'd=0A= been 1TCS from 20 years ago, and nothing else (and excluding as I've alread= y=0A= said general protocol attacks that affect any suite), a lot of the stuff=0A= that's hit us in the last decade or so wouldn't have happened. Again quoti= ng=0A= PHB, the problem isn't the strongest suite/algorithm that's available, it's= =0A= the weakest, and we've got plenty of those all over the place. =0A= =0A= So choose a strong 1TCS as a MUST and as a backup an equally strong one as = a=0A= SHOULD, not because the 1TCS will ever fail suddenly but because it's going= to=0A= be politically almost impossible to get just 1TCS through. The whale can b= e=0A= safely ignored because there'll never be any need to switch from the 1TCS,= =0A= it'll be there mostly to deal with strongly-held religious beliefs.=0A= =0A= Peter.=0A= From nobody Sun May 24 05:12:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AD01A8AB4 for ; Sun, 24 May 2015 05:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCnMvN_VthEv for ; Sun, 24 May 2015 05:12:42 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC611A8AB3 for ; Sun, 24 May 2015 05:12:42 -0700 (PDT) Received: by wichy4 with SMTP id hy4so26448415wic.1 for ; Sun, 24 May 2015 05:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vUW1z0re23lNibNzjivBHAZ3jQE/BesUCjxHbHIbXkQ=; b=B7HeLMXS0yH0Cq6+WpfnWx32QjJ7DwubYjZpfkwymtyoHzYLDnB/HuBVaZQt6ikFku zlW9pCzY03Ovh3Y7yTSvZ8g9R+7Ypai4+jxi9kDU/HWbKVUzNygID2u4AohNlmZAD2nQ e+c7bz3EPd3qagu8oeRBkhwlIpa85bKDBdD8wLPV0xmzKDHRGzEPMjr7WKMyz1sXk8pf VV29xn+TxrJWF1J1GchW3wbaQIrAw4XZwfWl6D+mwSStzCeNJG1Gst4ti46OXF1Rh+p2 IAL6Koem3VKvhxaJ74JIew+o5j9LsTvpgK0x76Ae/NK8dYnsdJi2VO0hjim5p0loksxK d+0A== MIME-Version: 1.0 X-Received: by 10.194.123.4 with SMTP id lw4mr30495854wjb.94.1432469561230; Sun, 24 May 2015 05:12:41 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Sun, 24 May 2015 05:12:41 -0700 (PDT) In-Reply-To: <555FA6C5.5000004@cs.tcd.ie> References: <555FA6C5.5000004@cs.tcd.ie> Date: Sun, 24 May 2015 08:12:41 -0400 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 12:12:44 -0000 On Fri, May 22, 2015 at 5:59 PM, Stephen Farrell wrote: > > Hiya, > > Russ has been working this draft [1] for a while now, > has gotten good feedback along the road and has now > asked me if I'd AD sponsor it as a BCP that documents > some of what we want protocols to do in terms of > cryptographic algorithm agility and picking MTI > algorithms. But this is not what we actually want to do. It's not a question of getting good algorithms deployed, but removing bad ones, and not a question of algorithm failures, but protocol failures. Protocol failures are made worse by adding negotiation mechanisms. As Peter notes downthread, 1TCS is a perfectly fine approach if you anticipate potentially having to fix the protocol. I'd go further: versioning is the best approach. > > I think it'd be good to have such a BCP if we get IETF > consensus on the content, so all going well, I do plan > to start an IETF LC on this around the end of June (after > I do some vacating:-). That would mean we could take > some f2f time in Prague to discuss it if needed. > > In the meantime, I'd appreciate it if folks on this > list could give some feedback on the draft. Of course > a detailed review is most welcome, but it'd also be > good to see expressions of support for it becoming a > BCP, or expressions of opposition to that, as the case > may be. (As always, saying why is much better than a > simple +1 or -1) > > So please try to take the time to give this a read > in the next month and say what you think about it. > (Treat this as a kinda-sorta-WGLC-like thing I guess.) > > Thanks, > Stephen. > > [1] https://tools.ietf.org/html/draft-iab-crypto-alg-agility > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon May 25 08:05:11 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186F81A90E2; Fri, 22 May 2015 23:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmAdDZGomZ4W; Fri, 22 May 2015 23:07:22 -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 0A08A1A90D7; Fri, 22 May 2015 23:07:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,480,1427752800"; d="asc'?scan'208";a="126053707" Received: from 178.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.178]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 May 2015 08:07:19 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Karthikeyan Bhargavan In-Reply-To: <20150216115457.3c16fdbf@latte.josefsson.org> Date: Sat, 23 May 2015 08:07:17 +0200 Message-Id: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <20150216115457.3c16fdbf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Mon, 25 May 2015 08:05:10 -0700 Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 06:07:27 -0000 --Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> We have a solution for that: >> https://tools.ietf.org/html/draft-ietf-tls-session-hash If a TLS connection uses the tls-session-hash, the tls-unique channel = binding becomes a good channel identifier for use in SCRAM (avoiding Triple = Handshake-style attacks). So either SCRAM could require tls-session-hash, or we could update = RFC5929 to require it (in the same way that it already requires RFC5746). I have a separate question: would there be value in defining a new = session-level channel binding (updating rfc5929) based on tls-session-hash? The advantage would be to obtain authenticated session resumption. That is, once a client has used SCRAM to authenticate on one connection, = it can reuse that credential on all resumed connections, until a new full handshake is performed. I = don=92t know how commonly we use session resumption in non-web scenarios, but the vast majority of = connections initiated by web browsers use abbreviated handshakes. Best, Karthik >=20 > Then SCRAM-SHA256 should normatively references that and require that > it is implemented for secure use of SCRAM with channel bindings. = There > are drawbacks with that approach: it is not widely implemented, not > published as an RFC that updates earlier TLS versions, and difficult > for SCRAM implementers to validate (usually the TLS stack is opaque to > the SCRAM implementer). I could live with that though, as a way of > pushing the current security problem down from the IETF protocol layer > into the implementation layer. >=20 > Alternatively, use a new channel binding type that use the extended > master secret derivation as described by the document above. I could > update draft-josefsson-sasl-tls-cb to describe this approach. >=20 > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVYBkWAAoJEB/WSo9veuUKybYH+QGJuJL8kTJBHTobgxiPBN2B DNUq+rNQa1ocNHvFUtVsJ/xiPfBOmCtXYlkk09PO2i03vPhJJCAea4hC1PVB51iB W7KPUELMp0o6EYvNnStGKWlOLQ7oUQcsXUNXZxvlpaVsd0WUg8GcfzgL2wEZQiWM LEQ5Ajcwx4rQYnaK/uFxsg8E1Hb+2xlLema2Vu/IKcR9FrxsP+FkYf5GPzOC9O3v lZi3czoWfEWPqiE9MENpddhPpU3eNkLxV6/C1wHPdqOlGLStYqfclpyBSTR7sepP nNTP2jz1mlAfIQUPiHdt2VU9SVVSwPAvzipheM3p8kF2r8qdbS9kQBRVKi5B6Vo= =xpYT -----END PGP SIGNATURE----- --Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6-- From nobody Mon May 25 09:54:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1CF1A00F5 for ; Mon, 25 May 2015 09:54:11 -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, 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 KLJxoFNDRUNA for ; Mon, 25 May 2015 09:54:07 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 43B3B1B2CBA for ; Mon, 25 May 2015 09:51:17 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 98BCC9A4029; Mon, 25 May 2015 12:51:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id p0MGTXqKWJ8h; Mon, 25 May 2015 12:50:07 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 901989A4017; Mon, 25 May 2015 12:50:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Mon, 25 May 2015 12:50:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie>, <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann , ianG X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 16:54:12 -0000 Ian and Peter: >> 4. 3th para. WEP. So, this is an example, as grumbled above. But = was RC4 >> broken? Or was the protocol broken? In practice it was due to the = small key, >> small IV. >=20 > Apart from an initial comment on the draft I've tried to avoid getting > involved in a debate over this since I think the issue is at least as = much (if > not more) religious than technical. For example I can use Russ' WEP = example > to argue exactly the opposite of the point he's trying to make: The = problem > with WEP wasn't a 1TCS one, it was that it was designed by = non-cryptographers, > and was badly broken. If they'd gone with four cipher suites instead = of one, > we'd just have four badly broken ones instead of one, or, worse, three = badly > broken ones and one not-quite-as-broken one so they could tell = everyone to use > the not-quite-as-bad one. I see the history a bit differently. The original WEP had a 40-bit key, = and no one looked at the protocol because the security was obviously = weak. When the key size was increased to 128-bits, then people looked = at the protocol and saw all of the major mistakes. It is hard to = believe that so many mistakes can be made in one protocol. The fact that the protocol was so tightly integrated with the 1TCS made = it very difficult to insert a secure algorithm. The vendors wanted a = backward compatible solution, and that made it even harder. >> The whale that is missing from the whole document is how to implement = a >> switch. >=20 > Yup. Or, better, the option "choose a good 1TCS and go with it". = Nearly 20 > years ago when I did my SSL implementation, I chose as default RSA + = 3DES + > SHA1 (RSA dictated by the fact that at that time servers were = relatively > powerful and clients weren't, and RSA's asymmetry helped). If I'd = implemented > nothing else, I'd still be about as secure today as I would with any = more > modern suite (various side-channel attacks, the EtM issue, and others = are > separate issues since they affect all cipher suites, not just that = one, so > you're in trouble no matter what suite you select). >=20 > As PHB has pointed out in a thread on the OpenPGP list, the problems = we're > seeing, over and over again, last week's toy-crypto DH being only the = most > recent example, is caused by too many cipher suites, not too few. If = there'd > been 1TCS from 20 years ago, and nothing else (and excluding as I've = already > said general protocol attacks that affect any suite), a lot of the = stuff > that's hit us in the last decade or so wouldn't have happened. Again = quoting > PHB, the problem isn't the strongest suite/algorithm that's available, = it's > the weakest, and we've got plenty of those all over the place. =20 >=20 > So choose a strong 1TCS as a MUST and as a backup an equally strong = one as a > SHOULD, not because the 1TCS will ever fail suddenly but because it's = going to > be politically almost impossible to get just 1TCS through. The whale = can be > safely ignored because there'll never be any need to switch from the = 1TCS, > it'll be there mostly to deal with strongly-held religious beliefs. I am not sure that there is a need in all situations. In PGP and S/MIME, for example, small parts of the user based can = migrate at different times. There are many small groups with little = overlap, so they can almost transition independently. In DNSSEC and RPKI, algorithms are used globally. RFC 6916 offers an = approach to algorithm migration in the RPKI. Russ From nobody Tue May 26 08:05:52 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C307B1A8939 for ; Tue, 26 May 2015 08:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, 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 XFQLUQOEAQuA for ; Tue, 26 May 2015 08:05:46 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBDC1A895D for ; Tue, 26 May 2015 08:05:26 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id B65069A403B; Tue, 26 May 2015 11:05:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 4bJ03oTkRVhm; Tue, 26 May 2015 11:04:11 -0400 (EDT) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A88169A4017; Tue, 26 May 2015 11:04:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-43--923717522 From: Russ Housley In-Reply-To: <5544E1D0.8010307@cisco.com> Date: Tue, 26 May 2015 10:20:15 -0400 Message-Id: References: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> <5544E1D0.8010307@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 15:05:50 -0000 --Apple-Mail-43--923717522 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eliot: I missed these comments when I produced -04. Sorry. I'm tackling them = now. See below. Russ On May 2, 2015, at 10:40 AM, Eliot Lear wrote: > Hi Russ, >=20 > Some comments: >=20 > Bottom of the introduction: >=20 >> Experience shows that many people are >> unwilling to disable older weaker algorithms; it seems that these >> people prefer to live with weaker algorithms, sometimes seriously >> flawed ones, to maintain interoperability with older software well >> after experts recommend migration. >=20 > There are a myriad of reasons, and this is just one important one. It = may be that they are unable to make the changes because there is = hardware involved that cannot support the new algorithm (footprint = issues, accelerator problems, or what-have-you). I will hazard a guess = that a more common scenario is that they have no idea how to make the = changes or even that the changes are needed. My suggestion is either = don't get into the "it seems..." business or to cover all the ground. I suggest: In a perfect world, this takes place before the older algorithm or suite = of algorithms is catastrophically weakened. However, experience has = shown that many people are unwilling to disable older weaker algorithms; = people live with weaker algorithms, sometimes seriously flawed ones, = well after experts recommend migration. There may be many reasons for = this situation, but maintaining interoperability with older = implementations is clearly an important one. Difficulty supporting the = new algorithm on deployed hardware is clearly another. >=20 > Section 2/Section 3: >=20 > There is a minor organizational issue here, and perhaps Housley's Law = applies (the one about the document not being finished until all excess = verbiage has been removed). It looks like part of Section 3 could be = merged with Section 2 (I got initially confused by some ambiguous advice = in 2.1 that was cleared up in 3.1). Some of Section 3 belongs with the = text in Section 4. Specifically, 3.3 is really tied quite closely to = 4.2, 4.3, and 4.4. I will take a look at this after this round of comments. Stephen just = asked for review on SAAG and CRFG. I do not want to do too much = restructuring while so many people are looking. It will make comment = resolution too hard. > Section 2.2: >> For this reason, the >> protocol MUST specify one or more mandatory-to-implement algorithm = or >> suite. >=20 > It may be worth reminding people that "mandatory to implement !=3D = mandatory to deploy" and holding some discussion on this point. For = instance, some environments may find the MTI insufficient for their = purposes. I suggest: For this reason, the protocol MUST specify one or more = mandatory-to-implement algorithm or suite. This does not require all = implementations to use this algorithm or suite, but it does require that = users are able to configure them. Note that mandatory-to-implement = algorithms or suites are not specified for protocols that are embedded = in other protocols; in these cases the system-level protocol = specification identifies the mandatory-to-implement algorithm or suite. > Section 2.4: >=20 >> When selecting a suite of cryptographic algorithms, the strength = of >> each algorithm SHOULD be considered. It needs to be considered at >> the time a protocol is designed. It also needs to be considered = at >> the time a protocol implementation is deployed and configured. >> Advice from from experts is useful, but in reality, it is not = often >> available to system administrators that are deploying and = configuring >> a protocol implementation. For this reason, protocol designers >> SHOULD provide clear guidance to implementors, leading to = balanced >> options being available at the time of deployment and = configuration. >=20 > I'll note that most of us applications people need current advice = (like some that's in this draft) just like using what's out there and = available in tools like OpenSSL, but these libraries generally do not = provide that advice. Perhaps it would be useful to even have an = appendix that includes translation of the advice in the draft to choices = in the various libraries. No, I'm not offering to write it, and I'd = understand if it gets missed because nobody else does either. The recent BCP out of the UTA WG provides some of this advice, but it = does so using TLS-specific terms. I'd rather not try to do that kind of = thing using library-specific terms. For one thing, how would we decide = which libraries to include. It could be a very large task. > Section 4.3: >=20 > I was surprised to find that you did not follow up your earlier = philosophical statement in Section 4.2 ("The idea is to have an = implemented and deployed algorithm as a fallback") with some sort of = SHOULD or MUST around that, either in 4.2 or 4.3. Maybe it belongs in = 2.2 next to the MUST at the top. Maybe I missed it? I could add a sentence that says protocol designers SHOULD NOT pick just = one, but I really think we need to leave room for judgement. > Section 4.4: >=20 > This advice is largely around what happens when there is some user = interface to configure systems. That is unlikely to be the case with = the Internet of Many Tiny Little Things (IoMTLT). Do you want to give = some more specific advice to top off what is being said wrt smart = objects (following up from the tech plenary)? Note that the plenary did not offer BCP-level advice on this topic. I = suggest: Some nations specify cryptographic algorithms, and then require their = use through legislation or regulations. These algorithms may not have = wide public review, and they can have limited reach of deployments. = Yet, the legislative or regulatory mandate creates a captive market. As = a result, the use of such algorithms get specified, implemented, and = deployed. The default server-side configuration SHOULD disable such = algorithms; in this way, explicit action by the system administrator is = needed to enable them where they are actually required. For tiny = devices, such administrator action may only be possible at the time the = device is deployed. > Nittiest nit: >=20 >> Algorithm agility is achieved when a protocol can easily migrate = from >> one algorithm suite to another, more desirable one, over time. >=20 > I think the "," after "another" is unneeded. Fixed.= --Apple-Mail-43--923717522 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Eliot:

I missed these comments when I produced -04.  Sorry.  I'm tackling them now.

See below.

Russ


On May 2, 2015, at 10:40 AM, Eliot Lear wrote:

Hi Russ,

Some comments:

Bottom of the introduction:

   Experience shows that many people are
   unwilling to disable older weaker algorithms; it seems that these
   people prefer to live with weaker algorithms, sometimes seriously
   flawed ones, to maintain interoperability with older software well
   after experts recommend migration.

There are a myriad of reasons, and this is just one important one.  It may be that they are unable to make the changes because there is hardware involved that cannot support the new algorithm (footprint issues, accelerator problems, or what-have-you).  I will hazard a guess that a more common scenario is that they have no idea how to make the changes or even that the changes are needed.  My suggestion is either don't get into the "it seems..." business or to cover all the ground.

I suggest:

In a perfect world, this takes place before the older algorithm or suite of algorithms is catastrophically weakened.  However, experience has shown that many people are unwilling to disable older weaker algorithms;  people live with weaker algorithms, sometimes seriously flawed ones, well after experts recommend migration.  There may be many reasons for this situation, but maintaining interoperability with older implementations is clearly an important one.  Difficulty supporting the new algorithm on deployed hardware is clearly another.


Section 2/Section 3:

There is a minor organizational issue here, and perhaps Housley's Law applies (the one about the document not being finished until all excess verbiage has been removed).  It looks like part of Section 3 could be merged with Section 2 (I got initially confused by some ambiguous advice in 2.1 that was cleared up in 3.1).  Some of Section 3 belongs with the text in Section 4.  Specifically, 3.3 is really tied quite closely to 4.2, 4.3, and 4.4.

I will take a look at this after this round of comments.  Stephen just asked for review on SAAG and CRFG.  I do not want to do too much restructuring while so many people are looking.  It will make comment resolution too hard.

Section 2.2:
   For this reason, the
   protocol MUST specify one or more mandatory-to-implement algorithm or
   suite.

It may be worth reminding people that "mandatory to implement != mandatory to deploy" and holding some discussion on this point.  For instance, some environments may find the MTI insufficient for their purposes.

I suggest:

For this reason, the protocol MUST specify one or more mandatory-to-implement algorithm or suite.  This does not require all implementations to use this algorithm or suite, but it does require that users are able to configure them.  Note that mandatory-to-implement algorithms or suites are not specified for protocols that are embedded in other protocols; in these cases the system-level protocol specification identifies the mandatory-to-implement algorithm or suite.

Section 2.4:

   When selecting a suite of cryptographic algorithms, the strength of
   each algorithm SHOULD be considered.  It needs to be considered at
   the time a protocol is designed.  It also needs to be considered at
   the time a protocol implementation is deployed and configured.
   Advice from from experts is useful, but in reality, it is not often
   available to system administrators that are deploying and configuring
   a protocol implementation.  For this reason, protocol designers
   SHOULD provide clear guidance to implementors, leading to  balanced
   options being available at the time of deployment and configuration.

I'll note that most of us applications people need current advice (like some that's in this draft) just like using what's out there and available in tools like OpenSSL, but these libraries generally do not provide that advice.  Perhaps it would be useful to even have an appendix that includes translation of the advice in the draft to choices in the various libraries.  No, I'm not offering to write it, and I'd understand if it gets missed because nobody else does either.

The recent BCP out of the UTA WG provides some of this advice, but it does so using TLS-specific terms.  I'd rather not try to do that kind of thing using library-specific terms.  For one thing, how would we decide which libraries to include.  It could be a very large task.

Section 4.3:

I was surprised to find that you did not follow up your earlier philosophical statement in Section 4.2 ("The idea is to have an implemented and deployed algorithm as a fallback") with some sort of SHOULD or MUST around that, either in 4.2 or 4.3.  Maybe it belongs in 2.2 next to the MUST at the top.  Maybe I missed it?

I could add a sentence that says protocol designers SHOULD NOT pick just one, but I really think we need to leave room for judgement.

Section 4.4:

This advice is largely around what happens when there is some user interface to configure systems.  That is unlikely to be the case with the Internet of Many Tiny Little Things (IoMTLT).  Do you want to give some more specific advice to top off what is being said wrt smart objects (following up from the tech plenary)?

Note that the plenary did not offer BCP-level advice on this topic.  I suggest:

Some nations specify cryptographic algorithms, and then require their use through legislation or regulations.  These algorithms may not have wide public review, and they can have limited reach of deployments.  Yet, the legislative or regulatory mandate creates a captive market.  As a result, the use of such algorithms get specified, implemented, and deployed.  The default server-side configuration SHOULD disable such algorithms; in this way, explicit action by the system administrator is needed to enable them where they are actually required.  For tiny devices, such administrator action may only be possible at the time the device is deployed.

Nittiest nit:

   Algorithm agility is achieved when a protocol can easily migrate from
   one algorithm suite to another, more desirable one, over time.

I think the "," after "another" is unneeded.

Fixed.
--Apple-Mail-43--923717522-- From nobody Tue May 26 09:07:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038DD1B2BCD for ; Tue, 26 May 2015 09:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 qSlKLpQ7udaM for ; Tue, 26 May 2015 09:07:22 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 483C81B2ACD for ; Tue, 26 May 2015 09:07:07 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id BFF559A4029; Tue, 26 May 2015 12:06:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id SmWcTQ6MQiBv; Tue, 26 May 2015 12:06:13 -0400 (EDT) Received: from new-host-3.home (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 0281D9A4050; Tue, 26 May 2015 12:06:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 26 May 2015 12:06:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <555FA6C5.5000004@cs.tcd.ie> To: Martin Thomson X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 16:07:27 -0000 On May 22, 2015, at 7:02 PM, Martin Thomson wrote: > On 22 May 2015 at 14:59, Stephen Farrell = wrote: >> So please try to take the time to give this a read >> in the next month and say what you think about it. >> (Treat this as a kinda-sorta-WGLC-like thing I guess.) >=20 > A few comments. I think that this needs a little more work. >=20 > Cipher suites include Diffie-Hellman or RSA without specifying a > particular public key length. >=20 > This is unnecessarily specific. While we often choose primitives that > are coupled to a particular strength (e.g. AES-GCM with 128-bit keys > and authentication tags is common, but those aren't the only options), > some algorithms permit flexibility in their strength, including the > number of rounds, key sizes, authentication tags, prime group size, > etc... The point of this paragraph is about the pro and con of including key = size in the identifier. However, you are right that it could apply to = other attributes as well. I suggest: Some algorithms offer flexibility in their strength by adjusting the key = size, number of rounds, authentication tag size, prime group size, and = so on. For example, cipher suites include Diffie-Hellman or RSA without = specifying a particular public key length. =20 >=20 > The section (2.4) that this appears in addresses matching relative > strengths of primitives in a suite: not using 16384-bit DH to protect > a triple-DES symmetric key, for instance. >=20 > That suggests that this is two sections: > 1. pick sizes, or provide a way to negotiate sizes (and in > negotiating, be sure to avoid the downgrades of S2.3) > 2. pick sizes that are roughly comparable strength >=20 > And here we come to the "unless" part. Protocols have very different > things riding on the different keys. Authentication primitives > (signing, authentication tags, MAC) could require real-time attacks to > be exploited in some contexts, like the authentication tag in TLS. Or > at least attackers are constrained in time (breaking a certificate key > after the certificate expired is of significantly less value to an > attacker). On the other hand, breaks in symmetric crypto or key > exchange for something like TLS have significant value to an attacker > in recovering plaintext on recorded sessions. >=20 > I think that this level of nuance isn't necessary to capture, but > acknowledging that this is at least a little bit more complicated > would be good. Good observation. I suggest: When selecting or negotiating a suite of cryptographic algorithms, the = strength of each algorithm SHOULD be considered. The algorithms in a = suite SHOULD be roughly equal; however, the security service provided by = each algorithm in a particular context needs to be considered in making = the selection. Algorithm strength needs to be considered at the time a = protocol is designed. It also needs to be considered at the time a = protocol implementation is deployed and configured. Advice from from = experts is useful, but in reality, it is not often available to system = administrators that are deploying and configuring a protocol = implementation. For this reason, protocol designers SHOULD provide = clear guidance to implementors, leading to balanced options being = available at the time of deployment and configuration. >=20 > In S2.5, this is a bit of a non-sequitur without context: "While RSA > with a 2048-bit public key is quite a bit stronger than SHA-1". The > point is that these are widely deployed and available, even if one is > not considered adequately strong. The point that the RSA is "strong > enough" might not be so obvious to a future audience. You are right. I suggest: Despite the guidance in Section 2.4, opportunistic security [RFC7435] = SHOULD also be considered, especially at the time a protocol = implementation is deployed and configured. Using algorithms that are = weak against advanced attackers but sufficient against others is a way = to make pervasive surveillance significantly more difficult. As a = result, algorithms that would not be acceptable in many negotiated = situations are acceptable for opportunistic security. Similarly, = shorter key sizes are also acceptable for opportunistic security. That = said, the use of strong algorithms is always preferable. >=20 > The note in Section 3.2 on Performance belongs elsewhere. Likely in > the section on strength (or two sections if you take my suggestion). I'm not sure how to handle this one yet. Eliot suggested some other = reorganization, and I'll consider this as well. >=20 > Section 3.3 could be expanded to emphasize the social aspects of this. > This is largely a social problem, and a difficult one: for browsers, > we don't want to break sites because we lose users by doing so, that > creates incentives to stay busted, but interoperable. We've found in > browser-land that coordinating response can be highly effective at > reducing defection. Thanks for this. I suggest adding another paragraph: In many ways preserving interoperability is a difficult social problem. = For example, consider web browsers. Dropping support for an algorithm = suite can break connectivity to some web sites because, and the browser = will lose users by doing so. This situation creates incentives to = support algorithm suites that would otherwise be deprecated, but = preserving interoperability. Coordinating the demise of an algorithm = suite is an important aspect of the answer to this social problem. >=20 > Section 4.1 neglects to mention the obvious benefit in selecting > something that lots of other people are using too. That's a > non-trivial advantage over and above the reasons cited (though many of > them might be considered different ways of saying the same thing). Yes, I think this point comes through in many ways in the document, but = you are right, it should be explicit. I suggest adding this sentence to the middle of the first paragraph: There are significant benefits in selecting algorithms and suites that = are widely deployed. >=20 > I find Section 4.6 baffling. We have words that we can use for these > things. They are MUST NOT, MUST and SHOULD. None of these attempt to > presage the future. But generating new conventions for what might or > might not happen in the future is much harder than waiting and just > making the change when the time comes. This idea is not new. It was first used with IKEv1 when Jeff Schiller = was SEC AD. The idea is to give product planners a heads up. >=20 > For instance, if TLS 1.3 doesn't mandate use of 25519, we could use > SHOULD+. OR, we can say SHOULD and then write a new document that > upgrades 25519 to MUST when we decide that's a good time. It stands > as much chance of being ignored as a SHOULD+, of course, but it > doesn't have the problems with predicting the future that SHOULD+ > invokes. I think you grasp the idea. Russ= From nobody Tue May 26 09:14:42 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D461AC3FD for ; Tue, 26 May 2015 09:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42z8SOfVi3dI for ; Tue, 26 May 2015 09:14:35 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410A51A9121 for ; Tue, 26 May 2015 09:14:35 -0700 (PDT) Received: by yhda23 with SMTP id a23so32082270yhd.2 for ; Tue, 26 May 2015 09:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wIJq1bWCl3OyRIHjE53Zz/QvnqmAvZreYEFZQTyhnjA=; b=II9Y2UwG5Hp5JA3h4us0dd4z4MyFeTdbgXyLUxD+oFshfj1YjCJfakUOq/Vd9a9QRo Vsmg4LJiolYRD9Kio8wlSlW7j08DPhF9yklM/ayAvfmpc4po7jsZffqqoW6STs2WzxzK lKA3F3ZJRbOYtJHNqQkfpUZsh9PaiZp5bEssuAFw4hDxktRWSTkPIKdMOrWn7YN9gWz9 LVhvbbDGHJswCX7ZpLEpBBPsCSogeFkijWP5AhNHvkr9DnPSaiGXrFApbW5bcDmNe7Jz LoGasbCl6FZzG7jaIHM/Qg4sxKvt3menngs9IsKAyWUCCyfPcrShluodDJdVjSifU6c4 FAhg== MIME-Version: 1.0 X-Received: by 10.170.204.15 with SMTP id v15mr17987231yke.57.1432656874485; Tue, 26 May 2015 09:14:34 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 26 May 2015 09:14:34 -0700 (PDT) In-Reply-To: References: <555FA6C5.5000004@cs.tcd.ie> Date: Tue, 26 May 2015 09:14:34 -0700 Message-ID: From: Martin Thomson To: Russ Housley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 16:14:40 -0000 On 26 May 2015 at 09:06, Russ Housley wrote: > I think you grasp the idea. Likewise. Thanks. Your proposed changes look good. From nobody Tue May 26 10:48:53 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A491A0687 for ; Tue, 26 May 2015 10:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAw-j03c9kGa for ; Tue, 26 May 2015 10:48:47 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68E91A005F for ; Tue, 26 May 2015 10:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23906; q=dns/txt; s=iport; t=1432662527; x=1433872127; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=xFX69ESFokrxdy510eo5eGhMN3N+zzGxpOEIVtFMee4=; b=D7NeNrG+iJGmRP5bWOO9drWypr+i5JCN0fJQopdgWu8pR++KPk8VEgQt mFOst6vry4Qp66NN0T5YaJG38ihJGlDK2ouFReTfRzh2E/t2MUHsXM149 q3eMJjArnMtf/LjkNZdnMifhd4x8t/+AfBUsT5Vl8ihjg/anHZMNNxzD1 o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnBADosGRV/xbLJq1ch2HHZAKCAhEBAQEBAQEBgQqEIgEBAQMBI0IGDQEFCwsYCRYLAgIJAwIBAgFFBg0BBwEBiCAIsC2jeQEBAQEBBQEBAQEBAQEBAQEBF4o4gQKELA5LB4JogUUBBJBMhE6BQ4c6gSmDcYJei16DWSOBZh8FHFMBgQA8gTSBRAEBAQ X-IronPort-AV: E=Sophos;i="5.13,500,1427760000"; d="asc'?scan'208,217";a="491245974" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 26 May 2015 17:48:44 +0000 Received: from [10.61.106.15] (dhcp-10-61-106-15.cisco.com [10.61.106.15]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4QHmiF8002604; Tue, 26 May 2015 17:48:44 GMT Message-ID: <5564B1FB.2010204@cisco.com> Date: Tue, 26 May 2015 19:48:43 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Russ Housley References: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> <5544E1D0.8010307@cisco.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AjTFBLTk2CGrDiVUgcn7sQ8WC0kD0oVq6" Archived-At: Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 17:48:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AjTFBLTk2CGrDiVUgcn7sQ8WC0kD0oVq6 Content-Type: multipart/alternative; boundary="------------040805010108030805050309" This is a multi-part message in MIME format. --------------040805010108030805050309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, Thanks for the response. Please see below. On 5/26/15 4:20 PM, Russ Housley wrote: > > On May 2, 2015, at 10:40 AM, Eliot Lear wrote: > >> Hi Russ, >> >> Some comments: >> >> Bottom of the introduction: >> >>> Experience shows that many people are >>> unwilling to disable older weaker algorithms; it seems that these >>> people prefer to live with weaker algorithms, sometimes seriously >>> flawed ones, to maintain interoperability with older software well= >>> after experts recommend migration. >> >> There are a myriad of reasons, and this is just one important one.=20 >> It may be that they are *unable* to make the changes because there is >> hardware involved that cannot support the new algorithm (footprint >> issues, accelerator problems, or what-have-you). I will hazard a >> guess that a more common scenario is that they have no idea *how* to >> make the changes or even that the changes are needed. My suggestion >> is either don't get into the "it seems..." business or to cover all >> the ground. > > I suggest: > > In a perfect world, this takes place before the older algorithm or > suite of algorithms is catastrophically weakened. However, experience > has shown that many people are unwilling to disable older weaker > algorithms; people live with weaker algorithms, sometimes seriously > flawed ones, well after experts recommend migration. There may be > many reasons for this situation, but maintaining interoperability with > older implementations is clearly an important one. Difficulty > supporting the new algorithm on deployed hardware is clearly another. I think we are arriving at the meat of the matter: if what we are talking about is *removing* or *turning off* some suite or algorithm, from a constrained device perspective, that is a strong and defensible argument because the footprint impact is either zero or negative. And so I like your phrasing above. However, I suggest that it could be a bit more succinct. E.g., For various reasons, most notably interoperability concerns, experience has shown that it has proven difficult for administrators and implementors to turn off weak algorithms. In addition, inability of legacy systems and resource-constrained devices to support new algorithms has added to those concerns. > >> >> Section 2/Section 3: >> >> There is a minor organizational issue here, and perhaps Housley's Law >> applies (the one about the document not being finished until all >> excess verbiage has been removed). It looks like part of Section 3 >> could be merged with Section 2 (I got initially confused by some >> ambiguous advice in 2.1 that was cleared up in 3.1). Some of Section >> 3 belongs with the text in Section 4. Specifically, 3.3 is really >> tied quite closely to 4.2, 4.3, and 4.4. > > I will take a look at this after this round of comments. Stephen just > asked for review on SAAG and CRFG. I do not want to do too much > restructuring while so many people are looking. It will make comment > resolution too hard. Sure. > >> Section 2.2: >>> For this reason, the >>> protocol MUST specify one or more mandatory-to-implement algorithm= or >>> suite. >> >> It may be worth reminding people that "mandatory to implement !=3D >> mandatory to deploy" and holding some discussion on this point. For >> instance, some environments may find the MTI insufficient for their >> purposes. > > I suggest: > > For this reason, the protocol MUST specify one or more > mandatory-to-implement algorithm or suite. This does not require all > implementations to use this algorithm or suite, but it does require > that users are able to configure them. Note that mandatory- Perhaps the following: s/implementations/deployments/ and s/,but.*\./but rather that they be available for all deployments./ > to-implement algorithms or suites are not specified for protocols that > are embedded in other protocols; in these cases the system-level > protocol specification identifies the mandatory-to-implement algorithm > or suite. I have no objection to this text, but it is not necessary for what I mentioned above. > >> Section 2.4: >> >>> When selecting a suite of cryptographic algorithms, the strength o= f >>> each algorithm SHOULD be considered. It needs to be considered at= >>> the time a protocol is designed. It also needs to be considered a= t >>> the time a protocol implementation is deployed and configured. >>> Advice from from experts is useful, but in reality, it is not ofte= n >>> available to system administrators that are deploying and configur= ing >>> a protocol implementation. For this reason, protocol designers >>> SHOULD provide clear guidance to implementors, leading to balance= d >>> options being available at the time of deployment and configuratio= n. >> >> I'll note that most of us applications people need current advice >> (like some that's in this draft) just like using what's out there and >> available in tools like OpenSSL, but these libraries generally do >> *not* provide that advice. Perhaps it would be useful to even have >> an appendix that includes translation of the advice in the draft to >> choices in the various libraries. No, I'm not offering to write it, >> and I'd understand if it gets missed because nobody else does either. > > The recent BCP out of the UTA WG provides some of this advice, but it > does so using TLS-specific terms. I'd rather not try to do that kind > of thing using library-specific terms. For one thing, how would we > decide which libraries to include. It could be a very large task. Sounds like a reference could do for now. > >> Section 4.3: >> >> I was surprised to find that you did not follow up your earlier >> philosophical statement in Section 4.2 ("The idea is to have an >> implemented and deployed algorithm as a fallback") with some sort of >> SHOULD or MUST around that, either in 4.2 or 4.3. Maybe it belongs >> in 2.2 next to the MUST at the top. Maybe I missed it? > > I could add a sentence that says protocol designers SHOULD NOT pick > just one, but I really think we need to leave room for judgement. > I may have misunderstood the sentence or the document, but if it is intended as a best current practice, a normative SHOULD seems like a good thing. But I see that I am sounding like the normative word police, up with which one SHOULD NOT put, and so I'll leave it at that ;-= ) >> Section 4.4: >> >> This advice is largely around what happens when there is some user >> interface to configure systems. That is unlikely to be the case with >> the Internet of Many Tiny Little Things (IoMTLT). Do you want to >> give some more specific advice to top off what is being said wrt >> smart objects (following up from the tech plenary)? > > Note that the plenary did not offer BCP-level advice on this topic. I > suggest: > > Some nations specify cryptographic algorithms, and then require their > use through legislation or regulations. These algorithms may not have > wide public review, and they can have limited reach of deployments. > Yet, the legislative or regulatory mandate creates a captive market. > As a result, the use of such algorithms get specified, implemented, > and deployed. The default server-side configuration SHOULD disable > such algorithms; in this way, explicit action by the system > administrator is needed to enable them where they are actually > required. For tiny devices, such administrator action may only be > possible at the time the device is deployed. > The main point I was making above is that constrained devices may not have administrative capabilities to enable or disable specific suites through their UIs. I shutter to think of my dad trying to sort this on his refrigerator. Or me, for that matter. And so what I was thinking of was something like the following: National standards pose great challenges to implementers of constrained devices. Some do not have user interfaces. In addition, an implementer may have to choose between market-specific product releases that may be incompatible elsewhere or an increased development and production costs to support multiple algorithms that likely will undergo less testing than a small number of well proven global algorithms or suites. Eliot --------------040805010108030805050309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ,

Thanks for the response.=C2=A0 Please see below.

On 5/26/15 4:20 PM, Russ Housley wrote= :

On May 2, 2015, at 10:40 AM, Eliot Lear wrote:

Hi Russ,

Some comments:

Bottom of the introduction:

=C2=A0=C2=A0 Experience shows tha= t many people are
=C2=A0=C2=A0 unwilling to disable older weaker algorithms= ; it seems that these
=C2=A0=C2=A0 people prefer to live with weaker algorithms= , sometimes seriously
=C2=A0=C2=A0 flawed ones, to maintain interoperability wi= th older software well
=C2=A0=C2=A0 after experts recommend migration.

There are a myriad of reasons, and this is just one important one.=C2=A0 It may be that they are unable = to make the changes because there is hardware involved that cannot support the new algorithm (footprint issues, accelerator problems, or what-have-you).=C2=A0 I will hazar= d a guess that a more common scenario is that they have no idea how to make the changes or even that the changes are needed.=C2=A0 My suggestion is either don't get= into the "it seems..." business or to cover all the ground.

I suggest:

In a perfect world, this takes place before the older algorithm or suite of algorithms is catastrophically weakened. =C2=A0However, experience has shown that many peopl= e are unwilling to disable older weaker algorithms; =C2=A0peopl= e live with weaker algorithms, sometimes seriously flawed ones, well after experts recommend migration. =C2=A0There may= be many reasons for this situation, but maintaining interoperability with older implementations is clearly an important one. =C2=A0Difficulty supporting the new algorithm = on deployed hardware is clearly another.

I think we are arriving at the meat of the matter: if what we are talking about is removing or turning off some suite or algorithm, from a constrained device perspective, that is a strong and defensible argument because the footprint impact is either zero or negative.=C2=A0 And so I like your phrasing above.=C2=A0= However, I suggest that it could be a bit more succinct.=C2=A0 E.g.,<= br>
For various reasons, most notably interoperability concerns, experience has shown that it has proven difficult for administrators and implementors to turn off weak algorithms.=C2=A0 In addition, inability of legacy systems and resource-constrained devices to support new algorithms has added to those concerns.


Section 2/Section 3:

There is a minor organizational issue here, and perhaps Housley's Law applies (the one about the document not being finished until all excess verbiage has been removed).=C2=A0 It looks like part of Section 3 could be me= rged with Section 2 (I got initially confused by some ambiguous advice in 2.1 that was cleared up in 3.1).=C2=A0 Some of Section 3 belongs with the text in Section 4.=C2=A0 Specifically, 3.3 is really tied quite closely to 4.2, 4.3, and 4.4.

I will take a look at this after this round of comments. =C2=A0Stephen just asked for review on SAAG and CRFG. =C2=A0I d= o not want to do too much restructuring while so many people are looking. =C2=A0It will make comment resolution too hard.

Sure.


Section 2.2:
=C2=A0=C2=A0 For this reason, the=
=C2=A0=C2=A0 protocol MUST specify one or more mandatory-to-implement algorithm or
=C2=A0=C2=A0 suite.

It may be worth reminding people that "mandatory to implement !=3D mandatory to deploy" and holding some discussion on this point.=C2=A0 For instance, some environm= ents may find the MTI insufficient for their purposes.

I suggest:

For this reason, the protocol MUST specify one or more mandatory-to-implement algorithm or suite. =C2=A0This does not require all implementations to use this algorithm or suite, but it does require that users are able to configure them. =C2=A0Note that mandatory-
Perhaps the following:

s/implementations/deployments/
and
s/,but.*\./but rather that they be available for all deployments./

to-implement algorithms or suites are not specified for protocols that are embedded in other protocols; in these cases the system-level protocol specification identifies the mandatory-to-implement algorithm or suite.

I have no objection to this text, but it is not necessary for what I mentioned above.

Section 2.4:

=C2=A0 =C2=A0When selecting a sui= te of cryptographic algorithms, the strength of
=C2=A0=C2=A0 each algorithm SHOULD be considered.=C2=A0 I= t needs to be considered at
=C2=A0=C2=A0 the time a protocol is designed.=C2=A0 It al= so needs to be considered at
=C2=A0=C2=A0 the time a protocol implementation is deploy= ed and configured.
=C2=A0=C2=A0 Advice from from experts is useful, but in r= eality, it is not often
=C2=A0=C2=A0 available to system administrators that are = deploying and configuring
=C2=A0=C2=A0 a protocol implementation.=C2=A0 For this re= ason, protocol designers
=C2=A0=C2=A0 SHOULD provide clear guidance to implementor= s, leading to=C2=A0 balanced
=C2=A0=C2=A0 options being available at the time of deplo= yment and configuration.

I'll note that most of us applications people need current advice (like some that's in this draft) just like using what's out there and available in tools like OpenSSL, but these libraries generally do not provide that advice.=C2=A0 Perhaps it would be useful to even have an appendix that includes translation of the advice in the draft to choices in the various libraries.=C2=A0 No, I'm no= t offering to write it, and I'd understand if it gets missed because nobody else does either.

The recent BCP out of the UTA WG provides some of this advice, but it does so using TLS-specific terms. =C2=A0I'd rather not t= ry to do that kind of thing using library-specific terms. =C2=A0Fo= r one thing, how would we decide which libraries to include. =C2=A0= It could be a very large task.

Sounds like a reference could do for now.


Section 4.3:

I was surprised to find that you did not follow up your earlier philosophical statement in Section 4.2 ("The idea is to have an implemented and deployed algorithm as a fallback") with some sort of SHOULD or MUST around that, either in 4.2 or 4.3.=C2=A0 Maybe it belongs in 2.2 next to= the MUST at the top.=C2=A0 Maybe I missed it?

I could add a sentence that says protocol designers SHOULD NOT pick just one, but I really think we need to leave room for judgement.


I may have misunderstood the sentence or the document, but if it is intended as a best current practice, a normative SHOULD seems like a good thing.=C2=A0 But I see that I am sounding like the normative wor= d police, up with which one SHOULD NOT put, and so I'll leave it at that ;-)



Section 4.4:

This advice is largely around what happens when there is some user interface to configure systems.=C2=A0 That is unlikely to be the case with the Internet of Many Tiny Little Things (IoMTLT).=C2=A0 Do you want to give some more= specific advice to top off what is being said wrt smart objects (following up from the tech plenary)?

Note that the plenary did not offer BCP-level advice on this topic. =C2=A0I suggest:

Some nations specify cryptographic algorithms, and then require their use through legislation or regulations. =C2=A0The= se algorithms may not have wide public review, and they can have limited reach of deployments. =C2=A0Yet, the legislative or regulatory mandate creates a captive market. =C2=A0As a result,= the use of such algorithms get specified, implemented, and deployed. =C2=A0The default server-side configuration SHOULD disable such algorithms; in this way, explicit action by the system administrator is needed to enable them where they are actually required. =C2=A0For tiny devices, such administrator action may only be possible at the time the device is deployed.


The main point I was making above is that constrained devices may not have administrative capabilities to enable or disable specific suites through their UIs.=C2=A0 I shutter to think of my dad trying t= o sort this on his refrigerator.=C2=A0 Or me, for that matter.=C2=A0 An= d so what I was thinking of was something like the following:

National standards pose great challenges to implementers of constrained devices.=C2=A0 Some do not have user interfaces.=C2=A0 In= addition, an implementer may have to choose between market-specific product releases that may be incompatible elsewhere or an increased development and production costs to support multiple algorithms that likely will undergo less testing than a small number of well proven global algorithms or suites.

Eliot

--------------040805010108030805050309-- --AjTFBLTk2CGrDiVUgcn7sQ8WC0kD0oVq6 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 iQEcBAEBCAAGBQJVZLH8AAoJEIe2a0bZ0nozqzEIAJkc1JrVBdftb6yIW6O8u+5z MqPWLxJeU7GvtfFp9d+VZTEnyyYmN2ThcBAfj0tMhD0wlnH9f2yZpMgZ8l5WrRS2 4fKVTl7SVR3sszNFEF648A9hYOHwh4XBG6HEbF4I9cfETJjlr25UruA/5Y60SobY 3y0ZJCEtLeNU+xbczMQXW1XmRtlvZ5w4W6diurKxhERMKke9o4qu6e71su8Sy25N VFXCqIQtDNLfdHtXzXfWd58SGKHnl2G+zqc2oVa4Qr/O1933wG0gqlRJIfA8/52Q 8sS9xPtjemL7RonpuIOPM7SyinF8MNx8I4eIRWJDO0wtsfO5uqXQgj06eQ6ghUA= =HL3x -----END PGP SIGNATURE----- --AjTFBLTk2CGrDiVUgcn7sQ8WC0kD0oVq6-- From nobody Tue May 26 11:15:40 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2991B2C7B for ; Tue, 26 May 2015 11:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 t0J4kpCzu3vy for ; Tue, 26 May 2015 11:15:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA161B2C8C for ; Tue, 26 May 2015 11:15:31 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 18:15:15 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0172.012; Tue, 26 May 2015 18:15:15 +0000 From: Christian Huitema To: Russ Housley , Peter Gutmann , ianG Thread-Topic: [saag] AD sponsoring draft-iab-crypto-alg-agility Thread-Index: AQHQlNqebmvnhnsVY0yHyiFYasZvwZ2J08yAgADhSQCAAjcLAIABosmw Date: Tue, 26 May 2015 18:15:14 +0000 Message-ID: References: <555FA6C5.5000004@cs.tcd.ie>, <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> In-Reply-To: <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.159.254] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 3:JhJx5W65aYIkilMqB5zZXGwCZVAl+f6W/yeWRWLFML3CJuiZAgfsy+FSCmTgbeNHIT00rVBQBD97af38NjT53wJtmBOYLg7yXGcMVM+fGHsmnx3xcy7ErmQ6kAWv6Tsgh7wFL3trBofJVR26by+WCA==; 10:gqPWSAChDqmigdoXvn4/VAjyKYwxORBgAeAm7tsIyllPeQyoqz+o19/Rz71S+g0btM2KAjAdET/pM5z92VUu/yWrnRF1rPLwOPO1nzKqChY=; 6:KDrimOE/GGA3YCZFYUsZeFn0ILw7Pa/zQVEsBbkuuFlN9LxFtYVZyP19M9MqXRB3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51704005)(33656002)(5001830100001)(86362001)(66066001)(81156007)(189998001)(97736004)(4001540100001)(64706001)(2656002)(5001770100001)(87936001)(5001860100001)(92566002)(101416001)(5001960100002)(105586002)(106356001)(106116001)(99286002)(230783001)(46102003)(93886004)(76576001)(54356999)(102836002)(50986999)(68736005)(2950100001)(62966003)(77096005)(77156002)(74316001)(76176999)(86612001)(2900100001)(122556002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 18:15:14.2164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 Archived-At: Cc: IETF SAAG Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 18:15:40 -0000 > > Apart from an initial comment on the draft I've tried to avoid getting > > involved in a debate over this since I think the issue is at least as > > much (if not more) religious than technical. For example I can use > > Russ' WEP example to argue exactly the opposite of the point he's > > trying to make: The problem with WEP wasn't a 1TCS one, it was that it > > was designed by non-cryptographers, and was badly broken. If they'd > > gone with four cipher suites instead of one, we'd just have four badly > > broken ones instead of one, or, worse, three badly broken ones and one > > not-quite-as-broken one so they could tell everyone to use the not-quit= e-as- > bad one. >=20 > I see the history a bit differently. The original WEP had a 40-bit key, = and no one > looked at the protocol because the security was obviously weak. When the= key > size was increased to 128-bits, then people looked at the protocol and sa= w all of > the major mistakes. It is hard to believe that so many mistakes can be m= ade in > one protocol. WEP is certainly one of the worse examples out there. The initial key lengt= h was ridiculous, the initialization vector was used incorrectly, the linea= r CRC did not protect the data integrity, etc. It seems like a textbook exa= mple against having just one cipher. But at the same time, WEP issues could= not be fixed by just changing the underlying encryption algorithm. The fix= es required changing the whole protocol, which is actually an example of ve= rsioning. The other "bad example" of security design is of course the use of A5 in GS= M. This one provides an interesting view on key and algorithm negotiation. = The standard was deliberately compromised to enable mass surveillance. That= was probably also the reason for choosing a 40 bit key in WEP. Which bring= s an interesting question. Consider the process used to set IETF standards.= In that context, is the "single suite" design easier to sabotage than a "m= ultiple choice" design?=20 -- Christian Huitema From nobody Tue May 26 12:19:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8152A1ACE61 for ; Tue, 26 May 2015 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 GzjiApp-WqEq for ; Tue, 26 May 2015 12:19:44 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 069291ACDF3 for ; Tue, 26 May 2015 12:19:44 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 4F5949A4040; Tue, 26 May 2015 15:19:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 0-U7+FWtycUw; Tue, 26 May 2015 15:18:28 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2E9179A403B; Tue, 26 May 2015 15:19:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-51--905792961 From: Russ Housley In-Reply-To: <5564B1FB.2010204@cisco.com> Date: Tue, 26 May 2015 15:19:00 -0400 Message-Id: <0D2CA0CA-7EA9-4D2E-A6B4-E7A3055FD68F@vigilsec.com> References: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> <5544E1D0.8010307@cisco.com> <5564B1FB.2010204@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 19:19:48 -0000 --Apple-Mail-51--905792961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eliot: I dropped the parts where we have reached agreement. >>> Bottom of the introduction: >>>=20 >>>> Experience shows that many people are >>>> unwilling to disable older weaker algorithms; it seems that = these >>>> people prefer to live with weaker algorithms, sometimes = seriously >>>> flawed ones, to maintain interoperability with older software = well >>>> after experts recommend migration. >>>=20 >>> There are a myriad of reasons, and this is just one important one. = It may be that they are unable to make the changes because there is = hardware involved that cannot support the new algorithm (footprint = issues, accelerator problems, or what-have-you). I will hazard a guess = that a more common scenario is that they have no idea how to make the = changes or even that the changes are needed. My suggestion is either = don't get into the "it seems..." business or to cover all the ground. >>=20 >> I suggest: >>=20 >> In a perfect world, this takes place before the older algorithm or = suite of algorithms is catastrophically weakened. However, experience = has shown that many people are unwilling to disable older weaker = algorithms; people live with weaker algorithms, sometimes seriously = flawed ones, well after experts recommend migration. There may be many = reasons for this situation, but maintaining interoperability with older = implementations is clearly an important one. Difficulty supporting the = new algorithm on deployed hardware is clearly another. >=20 > I think we are arriving at the meat of the matter: if what we are = talking about is removing or turning off some suite or algorithm, from a = constrained device perspective, that is a strong and defensible argument = because the footprint impact is either zero or negative. And so I like = your phrasing above. However, I suggest that it could be a bit more = succinct. E.g., >=20 > For various reasons, most notably interoperability concerns, = experience has shown that it has proven difficult for administrators and = implementors to turn off weak algorithms. In addition, inability of = legacy systems and resource-constrained devices to support new = algorithms has added to those concerns. I think that the part that talks about living with weak algorithms = should be retained: ... For various reasons, most notably interoperability concerns, = experience has shown that it has proven difficult for implementors and = administrators to remove or disable weak algorithms. Further, the = inability of legacy systems and resource-constrained devices to support = new algorithms adds to those concerns. As a result, people live with = weaker algorithms, sometimes seriously flawed ones, well after experts = recommend migration. >>> Section 2.2: >>>> For this reason, the >>>> protocol MUST specify one or more mandatory-to-implement = algorithm or >>>> suite. >>>=20 >>> It may be worth reminding people that "mandatory to implement !=3D = mandatory to deploy" and holding some discussion on this point. For = instance, some environments may find the MTI insufficient for their = purposes. >>=20 >> I suggest: >>=20 >> For this reason, the protocol MUST specify one or more = mandatory-to-implement algorithm or suite. This does not require all = implementations to use this algorithm or suite, but it does require that = users are able to configure them. Note that mandatory- > Perhaps the following: >=20 > s/implementations/deployments/ > and > s/,but.*\./but rather that they be available for all deployments./ That work for me. >> to-implement algorithms or suites are not specified for protocols = that are embedded in other protocols; in these cases the system-level = protocol specification identifies the mandatory-to-implement algorithm = or suite. >=20 > I have no objection to this text, but it is not necessary for what I = mentioned above. Right. I had to make a change to that part to make it flow. >>> Section 2.4: >>>=20 >>>> When selecting a suite of cryptographic algorithms, the strength = of >>>> each algorithm SHOULD be considered. It needs to be considered = at >>>> the time a protocol is designed. It also needs to be considered = at >>>> the time a protocol implementation is deployed and configured. >>>> Advice from from experts is useful, but in reality, it is not = often >>>> available to system administrators that are deploying and = configuring >>>> a protocol implementation. For this reason, protocol designers >>>> SHOULD provide clear guidance to implementors, leading to = balanced >>>> options being available at the time of deployment and = configuration. >>>=20 >>> I'll note that most of us applications people need current advice = (like some that's in this draft) just like using what's out there and = available in tools like OpenSSL, but these libraries generally do not = provide that advice. Perhaps it would be useful to even have an = appendix that includes translation of the advice in the draft to choices = in the various libraries. No, I'm not offering to write it, and I'd = understand if it gets missed because nobody else does either. >>=20 >> The recent BCP out of the UTA WG provides some of this advice, but it = does so using TLS-specific terms. I'd rather not try to do that kind of = thing using library-specific terms. For one thing, how would we decide = which libraries to include. It could be a very large task. >=20 > Sounds like a reference could do for now. Section 2.2 points to it already. I'm not sure another reference in = Section 2.4 is really helpful. >>> Section 4.3: >>>=20 >>> I was surprised to find that you did not follow up your earlier = philosophical statement in Section 4.2 ("The idea is to have an = implemented and deployed algorithm as a fallback") with some sort of = SHOULD or MUST around that, either in 4.2 or 4.3. Maybe it belongs in = 2.2 next to the MUST at the top. Maybe I missed it? >>=20 >> I could add a sentence that says protocol designers SHOULD NOT pick = just one, but I really think we need to leave room for judgement. >=20 > I may have misunderstood the sentence or the document, but if it is = intended as a best current practice, a normative SHOULD seems like a = good thing. But I see that I am sounding like the normative word = police, up with which one SHOULD NOT put, and so I'll leave it at that = ;-) I understand and agree with your comment about some document = restructuring. Let's see if we can get all of the guidance agreed, and = then work on that. Section 4 already makes this clear, I think. It = does not use SHOULD or SHOULD NOT in light of the discussion in Section = 4.3. It already says: Ideally, two independent sets of mandatory-to-implement algorithms will = be specified, allowing for a primary suite and a secondary suite. This = approach ensures that the secondary suite is widely deployed if a flaw = is found in the primary one. >=20 >=20 >=20 >>> Section 4.4: >>>=20 >>> This advice is largely around what happens when there is some user = interface to configure systems. That is unlikely to be the case with = the Internet of Many Tiny Little Things (IoMTLT). Do you want to give = some more specific advice to top off what is being said wrt smart = objects (following up from the tech plenary)? >>=20 >> Note that the plenary did not offer BCP-level advice on this topic. = I suggest: >>=20 >> Some nations specify cryptographic algorithms, and then require their = use through legislation or regulations. These algorithms may not have = wide public review, and they can have limited reach of deployments. = Yet, the legislative or regulatory mandate creates a captive market. As = a result, the use of such algorithms get specified, implemented, and = deployed. The default server-side configuration SHOULD disable such = algorithms; in this way, explicit action by the system administrator is = needed to enable them where they are actually required. For tiny = devices, such administrator action may only be possible at the time the = device is deployed. >>=20 >=20 > The main point I was making above is that constrained devices may not = have administrative capabilities to enable or disable specific suites = through their UIs. I shutter to think of my dad trying to sort this on = his refrigerator. Or me, for that matter. And so what I was thinking = of was something like the following: >=20 > National standards pose great challenges to implementers of = constrained devices. Some do not have user interfaces. In addition, an = implementer may have to choose between market-specific product releases = that may be incompatible elsewhere or an increased development and = production costs to support multiple algorithms that likely will undergo = less testing than a small number of well proven global algorithms or = suites. I'd prefer to separate these to things. I suggest two paragraphs: Some nations specify cryptographic algorithms, and then require their = use through legislation or regulations. These algorithms may not have = wide public review, and they can have limited reach of deployments. = Yet, the legislative or regulatory mandate creates a captive market. As = a result, the use of such algorithms get specified, implemented, and = deployed. The default server or responder configuration SHOULD disable = such algorithms; in this way, explicit action by the system = administrator is needed to enable them where they are actually required. = For tiny devices with no user interface, an administrator action may = only be possible at the time the device is purchased. National algorithms can force an implementer to produce several = incompatible product releases for a different countries or regions, = which has significantly greater cost over development of a product using = a globally-acceptable algorithm. Russ --Apple-Mail-51--905792961 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
=20 =20
Bottom of the introduction:

   Experience shows = that many people are
   unwilling to disable older weaker = algorithms; it seems that these
   people prefer to live with weaker = algorithms, sometimes seriously
   flawed ones, to maintain interoperability = with older software well
   after experts recommend migration.

There are a myriad of reasons, and this is just one important one.  It may be that they are unable = to make the changes because there is hardware involved that cannot support the new algorithm (footprint issues, accelerator problems, or what-have-you).  I will = hazard a guess that a more common scenario is that they have no idea how to make the changes or even that the changes are needed.  My suggestion is either don't = get into the "it seems..." business or to cover all the ground.

I suggest:

In a perfect world, this takes place before the older algorithm or suite of algorithms is catastrophically weakened.  However, experience has shown that many = people are unwilling to disable older weaker algorithms; =  people live with weaker algorithms, sometimes seriously flawed ones, well after experts recommend migration.  There = may be many reasons for this situation, but maintaining interoperability with older implementations is clearly an important one.  Difficulty supporting the new algorithm = on deployed hardware is clearly another.

I think we are arriving at the meat of the matter: if what we are talking about is removing or turning off some suite or algorithm, from a constrained device perspective, that is a strong and defensible argument because the footprint impact is either zero or negative.  And so I like your phrasing = above.  However, I suggest that it could be a bit more succinct.  = E.g.,

For various reasons, most notably interoperability concerns, experience has shown that it has proven difficult for administrators and implementors to turn off weak algorithms.  In addition, inability of legacy systems and resource-constrained devices to support new algorithms has added to those = concerns.

I think that the part = that talks about living with weak algorithms should be = retained:

...  For various reasons, most = notably interoperability concerns, experience has shown that it has = proven difficult for implementors and administrators to remove or = disable weak algorithms.  Further, the inability of legacy systems = and resource-constrained devices to support new algorithms adds to those = concerns.  As a result, people live with weaker algorithms, = sometimes seriously flawed ones, well after experts recommend = migration.


Section 2.2:
   For this reason, = the
   protocol MUST specify one or more mandatory-to-implement algorithm or
   suite.

It may be worth reminding people that "mandatory to implement !=3D mandatory to deploy" and holding some discussion on this point.  For instance, some = environments may find the MTI insufficient for their purposes.

I suggest:

For this reason, the protocol MUST specify one or more mandatory-to-implement algorithm or suite.  This does not require all implementations to use this algorithm or suite, but it does require that users are able to configure them.  Note that mandatory-
Perhaps the following:

s/implementations/deployments/
and
s/,but.*\./but rather that they be available for all = deployments./

That work for = me.

to-implement algorithms or suites are not = specified for protocols that are embedded in other protocols; in these cases the system-level protocol specification identifies the mandatory-to-implement algorithm or suite.

I have no objection to this text, but it is not necessary for what I mentioned above.

Right.  I = had to make a change to that part to make it = flow.

=20
Section 2.4:

   When selecting a = suite of cryptographic algorithms, the strength of
   each algorithm SHOULD be considered.  = It needs to be considered at
   the time a protocol is designed.  It = also needs to be considered at
   the time a protocol implementation is = deployed and configured.
   Advice from from experts is useful, but in = reality, it is not often
   available to system administrators that are = deploying and configuring
   a protocol implementation.  For this = reason, protocol designers
   SHOULD provide clear guidance to = implementors, leading to  balanced
   options being available at the time of = deployment and configuration.

I'll note that most of us applications people need current advice (like some that's in this draft) just like using what's out there and available in tools like OpenSSL, but these libraries generally do not provide that advice.  Perhaps it would be useful to even have an appendix that includes translation of the advice in the draft to choices in the various libraries.  No, I'm = not offering to write it, and I'd understand if it gets missed because nobody else does either.

The recent BCP out of the UTA WG provides some of this advice, but it does so using TLS-specific terms.  I'd rather not = try to do that kind of thing using library-specific terms. =  For one thing, how would we decide which libraries to include. =  It could be a very large task.

Sounds like a reference could do for = now.

Section 2.2 points to it = already.  I'm not sure another reference in Section 2.4 is really = helpful.

Section 4.3:

I was surprised to find that you did not follow up your earlier philosophical statement in Section 4.2 ("The idea is to have an implemented and deployed algorithm as a fallback") with some sort of SHOULD or MUST around that, either in 4.2 or 4.3.  Maybe it belongs in 2.2 next = to the MUST at the top.  Maybe I missed it?

I could add a sentence that says protocol designers SHOULD NOT pick just one, but I really think we need to leave room for judgement.

I may have misunderstood the sentence or the document, but if it is intended as a best current practice, a normative SHOULD seems like a good thing.  But I see that I am sounding like the normative = word police, up with which one SHOULD NOT put, and so I'll leave it at that ;-)

I understand and agree = with your comment about some document restructuring.  Let's see if = we can get all of the guidance agreed, and then work on that. =  Section 4 already makes this clear, I think.  It does not use = SHOULD or SHOULD NOT in light of the discussion in Section 4.3.   = It already says:

Ideally, two independent sets = of mandatory-to-implement algorithms will be specified, allowing for a = primary suite and a secondary suite.  This approach ensures that = the secondary suite is widely deployed if a flaw is found in the primary = one.





Section 4.4:

This advice is largely around what happens when there is some user interface to configure systems.  That is unlikely to be the case with the Internet of Many Tiny Little Things (IoMTLT).  Do you want to give some = more specific advice to top off what is being said wrt smart objects (following up from the tech plenary)?

Note that the plenary did not offer BCP-level advice on this topic.  I suggest:

Some nations specify cryptographic algorithms, and then require their use through legislation or regulations. =  These algorithms may not have wide public review, and they can have limited reach of deployments.  Yet, the legislative or regulatory mandate creates a captive market.  As a = result, the use of such algorithms get specified, implemented, and deployed.  The default server-side configuration SHOULD disable such algorithms; in this way, explicit action by the system administrator is needed to enable them where they are actually required.  For tiny devices, such administrator action may only be possible at the time the device is deployed.


The main point I was making above is that constrained devices may not have administrative capabilities to enable or disable specific suites through their UIs.  I shutter to think of my dad trying = to sort this on his refrigerator.  Or me, for that matter.  = And so what I was thinking of was something like the following:

National standards pose great challenges to implementers of constrained devices.  Some do not have user interfaces.  = In addition, an implementer may have to choose between market-specific product releases that may be incompatible elsewhere or an increased development and production costs to support multiple algorithms that likely will undergo less testing than a small number of well proven global algorithms or = suites.

I'd prefer to separate = these to things.  I suggest two = paragraphs:

Some nations specify = cryptographic algorithms, and then require their use through legislation = or regulations.  These algorithms may not have wide public review, = and they can have limited reach of deployments.  Yet, the = legislative or regulatory mandate creates a captive market.  As a = result, the use of such algorithms get specified, implemented, and = deployed.  The default server or responder configuration SHOULD = disable such algorithms; in this way, explicit action by the system = administrator is needed to enable them where they are actually required. =  For tiny devices with no user interface, an administrator action = may only be possible at the time the device is = purchased.

National algorithms can force an = implementer to produce several incompatible product releases for a = different countries or regions, which has significantly greater cost = over development of a product using a globally-acceptable = algorithm.

Russ

= = --Apple-Mail-51--905792961-- From nobody Tue May 26 13:03:17 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38B81A1A30 for ; Tue, 26 May 2015 13:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F20CbcaYoaKr for ; Tue, 26 May 2015 13:03:13 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B591A1AB5 for ; Tue, 26 May 2015 13:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7586; q=dns/txt; s=iport; t=1432670592; x=1433880192; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=mOjOiCVPg9vQWzkfv0n/VQHj4l3jzphwJ2YcfaSTU6A=; b=Vom2Yormg5YhSUIhP7H+rrdYfgHrJPMPv8Cc+3vYE8Sh/KplQU7Xkbwh vjHOKt+Iv1fLw5qwb+0JpwECGQicYq2/Y6R0L8RDMtW/Ut7rK8etidwGH M0E/xvjlpH4TD8EnTyChuT2p2yE/EAtchcFAqptfblJ/vSEfN/QSFPZIp c=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmBAC90GRV/xbLJq1ch2HAGodQAoICEwEBAQEBAQGBCoQiAQEBAwEjSA0BBQsLGAkWCwICCQMCAQIBRQYNAQcBAYggCKxRo2wBAQEBAQEBAQIBAQEBAQEBAQEBAReLOoQsDksHgmiBRQEEkEyEToFDhzqBKYZPi16DWSOCBXQBgQA8gTSBRAEBAQ X-IronPort-AV: E=Sophos;i="5.13,501,1427760000"; d="asc'?scan'208,217";a="491400703" 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; 26 May 2015 20:03:10 +0000 Received: from [10.61.106.15] (dhcp-10-61-106-15.cisco.com [10.61.106.15]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4QK3A1K015967; Tue, 26 May 2015 20:03:10 GMT Message-ID: <5564D17C.7090804@cisco.com> Date: Tue, 26 May 2015 22:03:08 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Russ Housley References: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> <5544E1D0.8010307@cisco.com> <5564B1FB.2010204@cisco.com> <0D2CA0CA-7EA9-4D2E-A6B4-E7A3055FD68F@vigilsec.com> In-Reply-To: <0D2CA0CA-7EA9-4D2E-A6B4-E7A3055FD68F@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MebQWI6jGVE2irbANmSKUeT8lGksmSdWq" Archived-At: Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:03:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MebQWI6jGVE2irbANmSKUeT8lGksmSdWq Content-Type: multipart/alternative; boundary="------------040606070702040006000102" This is a multi-part message in MIME format. --------------040606070702040006000102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, On 5/26/15 9:19 PM, Russ Housley wrote: > ... For various reasons, most notably interoperability concerns, > experience has shown that it has proven difficult for implementors and > administrators to remove or disable weak algorithms. Further, the > inability of legacy systems and resource-constrained devices to > support new algorithms adds to those concerns. As a result, people > live with weaker algorithms, sometimes seriously flawed ones, well > after experts recommend migration. > > That works for me. > I understand and agree with your comment about some document > restructuring. Let's see if we can get all of the guidance agreed, > and then work on that. Section 4 already makes this clear, I think. > It does not use SHOULD or SHOULD NOT in light of the discussion in > Section 4.3. It already says: > > Ideally, two independent sets of mandatory-to-implement algorithms > will be specified, allowing for a primary suite and a secondary suite. > This approach ensures that the secondary suite is widely deployed if > a flaw is found in the primary one. > > Sounds good. >> > > I'd prefer to separate these to things. I suggest two paragraphs: > > Some nations specify cryptographic algorithms, and then require their > use through legislation or regulations. These algorithms may not have > wide public review, and they can have limited reach of deployments. > Yet, the legislative or regulatory mandate creates a captive market. > As a result, the use of such algorithms get specified, implemented, > and deployed. The default server or responder configuration SHOULD > disable such algorithms; in this way, explicit action by the system > administrator is needed to enable them where they are actually > required. For tiny devices with no user interface, an administrator > action may only be possible at the time the device is purchased. > National algorithms can force an implementer to produce several > incompatible product releases for a different countries or regions, > which has significantly greater cost over development of a product > using a globally-acceptable algorithm. > We discussed this offline. I think Russ will be posting something about this... Eliot --------------040606070702040006000102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ,


On 5/26/15 9:19 PM, Russ Housley wrote= :
... =C2=A0For various reasons, most notably interoperability concerns, experience has shown that it has proven difficult for implementors and administrators to remove or disable weak algorithms. =C2=A0Further, the inability of legacy systems and resource-constrained devices to support new algorithms adds to those concerns. =C2=A0As a result, people live with weaker algorithms, sometimes seriously flawed ones, well after experts recommend migration.



That works for me.

I understand and agree with your comment about some document restructuring. =C2=A0Let's see if we can get all of the guidance agreed, and then work on that. =C2=A0Section 4 already mak= es this clear, I think. =C2=A0It does not use SHOULD or SHOULD NOT in light of the discussion in Section 4.3. =C2=A0 It already says:

Ideally, two independent sets of mandatory-to-implement algorithms will be specified, allowing for a primary suite and a secondary suite. =C2=A0This approach ensures that the secondary s= uite is widely deployed if a flaw is found in the primary one.



Sounds good.



I'd prefer to separate these to things. =C2=A0I suggest two paragraphs:

Some nations specify cryptographic algorithms, and then require their use through legislation or regulations. =C2=A0The= se algorithms may not have wide public review, and they can have limited reach of deployments. =C2=A0Yet, the legislative or regulatory mandate creates a captive market. =C2=A0As a result,= the use of such algorithms get specified, implemented, and deployed. =C2=A0The default server or responder configuration SHOULD disable such algorithms; in this way, explicit action by the system administrator is needed to enable them where they are actually required. =C2=A0For tiny devices with no user= interface, an administrator action may only be possible at the time the device is purchased.

National algorithms can force an implementer to produce several incompatible product releases for a different countries or regions, which has significantly greater cost over development of a product using a globally-acceptable algorithm.



We discussed this offline.=C2=A0 I think Russ will be posting somethi= ng about this...

Eliot
--------------040606070702040006000102-- --MebQWI6jGVE2irbANmSKUeT8lGksmSdWq 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 iQEcBAEBCAAGBQJVZNF9AAoJEIe2a0bZ0noziyQH/2AaDn2xDKTbxJCX+on0aeAW yVVxjZOPUylKKwlVF55uSAJwubvt8707JCf89PUSQx+H/Ak5CO9jofNigd70hWYN ZVblkY375Sp9ZNSJCbcctfyFVbtLrA5W93vqkUdK/gKSvDPACBf200zrTbCC/50e 6nRSo5eAG+/aOXz6AG/PwmUavUrFecbG81QralquzzLXoRKLMzxEC21TusADYUI9 wccgZcacL7ygpLNvLtJUj4n0oPuGD0od4hse7GlnswNIqY2z+A7Y2piBSwqQMFVR xgRwpedvUK0UJ/LwflMHBVPWMJZqE1joL/nd5/mTokULVkaMm1Y6vL/NuE8qhyU= =nEab -----END PGP SIGNATURE----- --MebQWI6jGVE2irbANmSKUeT8lGksmSdWq-- From nobody Tue May 26 13:06:38 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7674F1ACE34 for ; Tue, 26 May 2015 13:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 tX4mKMLAbBrd for ; Tue, 26 May 2015 13:06:34 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id AB5621A873B for ; Tue, 26 May 2015 13:06:34 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 693049A4040; Tue, 26 May 2015 16:06:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id XnoxHfvBf3Mp; Tue, 26 May 2015 16:05:20 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 695EF9A403B; Tue, 26 May 2015 16:06:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-53--902980453 From: Russ Housley In-Reply-To: <5564D17C.7090804@cisco.com> Date: Tue, 26 May 2015 16:05:52 -0400 Message-Id: References: <6C3AC8E6-A93D-451F-9E0E-3F9ABE7EC83F@vigilsec.com> <5544E1D0.8010307@cisco.com> <5564B1FB.2010204@cisco.com> <0D2CA0CA-7EA9-4D2E-A6B4-E7A3055FD68F@vigilsec.com> <5564D17C.7090804@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-03 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:06:36 -0000 --Apple-Mail-53--902980453 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> 'd prefer to separate these to things. I suggest two paragraphs: >>=20 >> Some nations specify cryptographic algorithms, and then require their = use through legislation or regulations. These algorithms may not have = wide public review, and they can have limited reach of deployments. = Yet, the legislative or regulatory mandate creates a captive market. As = a result, the use of such algorithms get specified, implemented, and = deployed. The default server or responder configuration SHOULD disable = such algorithms; in this way, explicit action by the system = administrator is needed to enable them where they are actually required. = For tiny devices with no user interface, an administrator action may = only be possible at the time the device is purchased. >=20 >> National algorithms can force an implementer to produce several = incompatible product releases for a different countries or regions, = which has significantly greater cost over development of a product using = a globally-acceptable algorithm. >=20 > We discussed this offline. I think Russ will be posting something = about this... National Cipher Suites Some nations specify cryptographic algorithms, and then require their = use through legislation or regulations. These algorithms may not have = wide public review, and they can have limited reach of deployments. = Yet, the legislative or regulatory mandate creates a captive market. As = a result, the use of such algorithms get specified, implemented, and = deployed. The default server or responder configuration SHOULD disable = such algorithms; in this way, explicit action by the system = administrator is needed to enable them where they are actually required. = For tiny devices with no user interface, an administrator action may = only be possible at the time the device is purchased. National algorithms can force an implementer to produce several = incompatible product releases for a different countries or regions, = which has significantly greater cost over development of a product using = a globally-acceptable algorithm. This situation could be even worse if = the various national algorithms impose different requirements on the = protocol, its key management, or its use of random values. Russ --Apple-Mail-53--902980453 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
'd prefer to separate these to things.  I = suggest two paragraphs:

Some nations = specify cryptographic algorithms, and then require their use through = legislation or regulations.  These algorithms may not have wide = public review, and they can have limited reach of deployments. =  Yet, the legislative or regulatory mandate creates a captive = market.  As a result, the use of such algorithms get specified, = implemented, and deployed.  The default server or responder = configuration SHOULD disable such algorithms; in this way, explicit = action by the system administrator is needed to enable them where they = are actually required.  For tiny devices with no user interface, an = administrator action may only be possible at the time the device is = purchased.

National algorithms can force an implementer to = produce several incompatible product releases for a different countries = or regions, which has significantly greater cost over development of a = product using a globally-acceptable = algorithm.

We discussed this offline.  = I think Russ will be posting something about = this...

Nation= al Cipher Suites

Some nations specify = cryptographic algorithms, and then require their use through legislation = or regulations.  These algorithms may not have wide public review, = and they can have limited reach of deployments.  Yet, the = legislative or regulatory mandate creates a captive market.  As a = result, the use of such algorithms get specified, implemented, and = deployed.  The default server or responder configuration SHOULD = disable such algorithms; in this way, explicit action by the system = administrator is needed to enable them where they are actually required. =  For tiny devices with no user interface, an administrator action = may only be possible at the time the device is = purchased.

National algorithms can force an = implementer to produce several incompatible product releases for a = different countries or regions, which has significantly greater cost = over development of a product using a globally-acceptable algorithm. =  This situation could be even worse if the various national = algorithms impose different requirements on the protocol, its key = management, or its use of random = values.

Russ

= --Apple-Mail-53--902980453-- From nobody Tue May 26 13:07:11 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD0F1ACF04 for ; Tue, 26 May 2015 13:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 Ib4_sMbnMU5J for ; Tue, 26 May 2015 13:07:08 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2AC11ACEC4 for ; Tue, 26 May 2015 13:07:03 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 0EB666D734; Tue, 26 May 2015 16:07:01 -0400 (EDT) Message-ID: <5564D265.4030504@iang.org> Date: Tue, 26 May 2015 21:07:01 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christian Huitema , Russ Housley , Peter Gutmann References: <555FA6C5.5000004@cs.tcd.ie>, <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF SAAG Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:07:10 -0000 On 26/05/2015 19:15 pm, Christian Huitema wrote: >>> Apart from an initial comment on the draft I've tried to avoid getting >>> involved in a debate over this since I think the issue is at least as >>> much (if not more) religious than technical. For example I can use >>> Russ' WEP example to argue exactly the opposite of the point he's >>> trying to make: The problem with WEP wasn't a 1TCS one, it was that it >>> was designed by non-cryptographers, and was badly broken. If they'd >>> gone with four cipher suites instead of one, we'd just have four badly >>> broken ones instead of one, or, worse, three badly broken ones and one >>> not-quite-as-broken one so they could tell everyone to use the not-quite-as- >> bad one. >> >> I see the history a bit differently. The original WEP had a 40-bit key, and no one >> looked at the protocol because the security was obviously weak. When the key >> size was increased to 128-bits, then people looked at the protocol and saw all of >> the major mistakes. It is hard to believe that so many mistakes can be made in >> one protocol. > > WEP is certainly one of the worse examples out there. The initial key length was ridiculous, the initialization vector was used incorrectly, the linear CRC did not protect the data integrity, etc. It seems like a textbook example against having just one cipher. But at the same time, WEP issues could not be fixed by just changing the underlying encryption algorithm. The fixes required changing the whole protocol, which is actually an example of versioning. "But at the same time..." :) > The other "bad example" of security design is of course the use of A5 in GSM. This one provides an interesting view on key and algorithm negotiation. The standard was deliberately compromised to enable mass surveillance. It was deliberately compromised, yes. The MiB were in the design room. However, it is important to remember our security modelling. GSM crypto was designed to protect against two things: paparazzi and billing fraud. It did those very well. It was never designed to protect against national security agencies, and didn't need to, given that the GSM protocol was only secure on air. Both the European agencies and every other agency could easily hack in and listen in the clear. > That was probably also the reason for choosing a 40 bit key in WEP. Which brings an interesting question. Consider the process used to set IETF standards. In that context, is the "single suite" design easier to sabotage than a "multiple choice" design? (This is what I call the "special interests" attack.) iang From nobody Tue May 26 13:25:09 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB10C1B3128 for ; Tue, 26 May 2015 13:25:07 -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, 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 Hfvpa-0QQBTm for ; Tue, 26 May 2015 13:25:01 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id B35E01B3127 for ; Tue, 26 May 2015 13:25:01 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E1B879A4040; Tue, 26 May 2015 16:24:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id mkhUQvD9a4dJ; Tue, 26 May 2015 16:23:46 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id AD0A29A4029; Tue, 26 May 2015 16:24:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <5560BA33.7000300@iang.org> Date: Tue, 26 May 2015 16:24:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4F157EFC-CAD9-40B3-B1AE-AF05F0EAEAB3@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> To: ianG X-Mailer: Apple Mail (2.1085) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:25:07 -0000 Ian: > My thoughts on 4.3. >=20 > 1. The content is not easy to endorse. Clearly it is written from a = stalwart position of "bad idea" without actually getting into the logic = and accepting that there is a place and time for this approach. >=20 > Indeed if the entire document were written to accept that in some = circumstances there is merit in 1TCS then consensus might be easier. I = for one don't approve of the document. >=20 > Perversely, I'm fine with the title :) although I'd prefer the more = canonical version of *One True Cipher Suite considered harmful* . It is = of course an irony and an honour! Even when 1TCS is chosen, the protocol design needs to accommodate a = change. As I said in my response to Peter, the designer needs to think = about transition, and protocol details should not be too tightly bound = to the details of the first selection of the iTCS. To make this more = clear, I have update the WEP discussion: The first IEEE 802.11 [WiFi] specification included the Wired Equivalent = Privacy (WEP) as the only encryption technique. Many of the protocol = details were driven by the selected algorithm. WEP was found to be = quite weak [WEP], and a very large effort was needed to specify, = implement, and deploy the alternative encryption techniques. This = effort was made even harder by the protocol design choices that were = tied to the initial algorithm selection and the desire for backward = compatibility. > 2. 4.3/1 First para "It is much better..." just assumes that the only = mistakes that occur are in the algorithm choice. Statistically it is = the other way around, most mistakes are in the protocol, in which case = the protocol itself must be transitioned. In which case we have only a = nominal or occasional stress on needing to transition just an algorithm. >=20 > Section 2.3 / para 3 agrees, by saying "Sadly, this has happened..." You are right that many problems come from the protocol itself. That is = not the point of this section. I think that comes out in Section 2.3 = and in the mac-then-encrypt discussion elsewhere in the document. > 3. second para, same criticism. It would be very nice for someone to = actually surface a list of when algorithms have been catastrophically = broken, versus a list of similar breaks with protocols. I know I say it = doesn't happen very much, but it's not as if anyone has sat down and = worked it out. This might be a good masters thesis for someone? I agree, but I'm nor sure how that helps me improve the document. > 4. 3th para. WEP. So, this is an example, as grumbled above. But = was RC4 broken? Or was the protocol broken? In practice it was due to = the small key, small IV. It was a whole bunch of things, I already sent a message in response to = Peter on this topic. >=20 > Would a choice of algorithms have saved anyone? I reckon not, for two = reasons. Firstly, the product was designed to be weak, and the weakness = would have just carried across. Like, DES with 40 bit keys instead of = RC4, etc. Secondly, the market for these devices was never really set = up for any sort of widescale upgrade of the parameters, so regardless of = any claim that "RC4 broken, must switch" few would likely have done it. >=20 > In practice, the OODA loop for switching an algorithm would likely be = the same as upgrading all the hardware by buying new kit. So don't = bother? >=20 > Indeed if we were to add algorithm agility to WiFi, imagine the chaos = in user-land. WiFi is already a big tricky because nobody out there = knows what the choices mean, so they rely on defaults to get it right. >=20 > What I'm saying here is that the case for switching the algorithm in = WiFi is particularly murky, and is no sense related to the science of = protocols. I hope you agree that the text suggested above is an improvement. Can = it be made even better? > 5. 4th para -- SHA-1 to SHA-256 over 5 years. Probably true. And in = the interim it was far more important to upgrade through the TLS = versions, so why later generations were still using SHA-1 remains a = mystery. >=20 > The first failure remediation in TLS that I measured took about 3.5 = years, and that's when they were trying real hard. It was a protocol = breach of course, not an algorithm break. >=20 > Discussion also applies to algorithmic agility as well. The platform needed to add support for SHA-256 before the applications = could use it. That made it even harder, and I think that situation will = be repeated in the future. > The whale that is missing from the whole document is how to implement = a switch. Without this, advice for algorithmic agility is negligent - = IETF is encouraging people to use a protocol design pattern without any = clear or plausible manual in how to enjoy the fruits of that method. As I said in my reply to Peter: In PGP and S/MIME, for example, small parts of the user based can = migrate at different times. There are many small groups with little = overlap, so they can almost transition independently. In DNSSEC and RPKI, algorithms are used globally. RFC 6916 offers an = approach to algorithm migration in the RPKI. > Section 2.3 hints at this but provides no meat. this: >=20 > "Protocols MUST facilitate the selection to > the best algorithm or suite..." >=20 > is not as helpful because (a) the selection protocol itself is hard = coded with this algorithm, so can't be switched without upgrade, and (b) = it assumes a definition of "best" which either requires external = instructions (a cipher negotiation list) or it just puts the point on = the fact that the only experts of any credibility here are the original = protocol designers. A point which is made in sections 2.4, 4.1! Do you think this works better? Algorithm transition is naturally facilitated as part of an algorithm = selection or negotiation mechanism. Protocols traditionally select the = best algorithm or suite that is supported by all communicating peers and = acceptable by their policies. In addition, a mechanism is needed to = determine whether the new algorithm has been deployed. For example, = SMIMECapabilities [RFC5751] allows S/MIME mail user agents to share the = list of algorithms that they are willing to use in preference order. = For another example, the DNSSEC EDNS0 option [RFC6975] measures the = acceptance and use of new digital signing algorithms. > Section 3.2 ditto. Section 4.2 agrees with >=20 > "the manner by which system administrators > are advised to switch algorithms or suites is > at best ad hoc, and at worst entirely absent." >=20 > There is begrudging acceptance that upgrading the entire protocol = version number is one way to upgrade the cipher suite. I certainly do not agree with your conclusion. We have seen a = transition from DES to Triple-DES to AES in S/MIME without a need for = version changes. > 4.6 might be the only new contribution as to how to move forward on = algorithms. It is not new. See RFC 4307. Russ= From nobody Tue May 26 14:29:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2110A1B31FD for ; Tue, 26 May 2015 14:29:19 -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 jErewBLwkJOr for ; Tue, 26 May 2015 14:29:17 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524F61B31FC for ; Tue, 26 May 2015 14:29:17 -0700 (PDT) Received: by igcau1 with SMTP id au1so63910746igc.1 for ; Tue, 26 May 2015 14:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vKtZPAMl56gtQ7Vtm6CCefHYVKtDXcXfLm9Ip2/xArM=; b=uh0BKoH4V4nAxegyf6kQcC3YmfyHZV4KF4w+0VqPUtvx4eRV7MuHA/C8FYC1v6e3u2 qy1HHaVVIVRsGr5Lfl+Ot2V/AYYWw354MhCjgKkY0HsMiThwxlsq2+ubr5KZu3Lq9NZw X9eakUiQZu7RgpUmx31Ip8jAJFeUQ16dSfwc1VXMhPahEpH6YfhuQSreIZ9DzQjcsNrY fTbZOPNroXebc8frG4Hb8C5LHVbeJLmQu5+O4Kpz31tshO1fqtotHG8+S3MhjP23gPOs u1BSskf2eoG+ayokF0lxgv3MpnBoX54pITfPwuj/9i3PHnk9JXfB+81RSiDkDlJ2WUxa RABA== MIME-Version: 1.0 X-Received: by 10.107.150.14 with SMTP id y14mr37893513iod.55.1432675756819; Tue, 26 May 2015 14:29:16 -0700 (PDT) Received: by 10.36.32.5 with HTTP; Tue, 26 May 2015 14:29:16 -0700 (PDT) Date: Tue, 26 May 2015 14:29:16 -0700 Message-ID: From: Ted Hardie To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a1140289c904b95051702d186 Archived-At: Subject: [saag] Review request for draft-iab-privsec-confidentiality-mitigations X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:29:19 -0000 --001a1140289c904b95051702d186 Content-Type: text/plain; charset=UTF-8 Howdy, The draft below is a very drafty -00 that attempts to tackle the question of what mitigations are available to pervasive surveillance and the related question of what interactions those mitigations have with each other. The IAB privsec would appreciate review of the draft; public discussion is on the perpass@ietf.org list, as some of the source material come from there. regards, Ted Hardie A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Architecture Board Working Group of the IETF. Title : Confidentiality in the Face of Pervasive Surveillance Author : Ted Hardie Filename : draft-iab-privsec-confidentiality-mitigations-00.txt Pages : 9 Date : 2015-05-19 Abstract: The IAB has published [I-D.iab-privsec-confidentiality-threat] in response to several revelations of pervasive attack on Internet communications. In this document we survey the mitigations to those threats which are currently available or which might plausibly be deployed. We discuss these primarily in the context of Internet protocol design, focusing on robustness to pervasive monitoring and avoidance of unwanted cross-mitigation impacts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-iab-privsec-confidentiality-mitigations/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-iab-privsec-confidentiality-mitigations-00 --001a1140289c904b95051702d186 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

The draft below is= a very drafty -00 that attempts to tackle the question of what mitigations= are available to pervasive surveillance and the related question of what i= nteractions those mitigations have with each other.=C2=A0 The IAB privsec w= ould appreciate review of the draft; public discussion is on the perpass@ietf.org list, as some of the source = material come from there.

regards,

Ted Hardie

A New Internet-Draft is available= from the on-line Internet-Drafts directories.
=C2=A0This draft is a work item of the Internet Architecture Board Working = Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Confidentiality in the Face of Pervasive Surveillance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Ted = Hardie
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iab= -privsec-confidentiality-mitigations-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-05-19

Abstract:
=C2=A0 =C2=A0The IAB has published [I-D.iab-privsec-confidentiality-threat]= in
=C2=A0 =C2=A0response to several revelations of pervasive attack on Interne= t
=C2=A0 =C2=A0communications.=C2=A0 In this document we survey the mitigatio= ns to those
=C2=A0 =C2=A0threats which are currently available or which might plausibly= be
=C2=A0 =C2=A0deployed.=C2=A0 We discuss these primarily in the context of I= nternet
=C2=A0 =C2=A0protocol design, focusing on robustness to pervasive monitorin= g and
=C2=A0 =C2=A0avoidance of unwanted cross-mitigation impacts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= ab-privsec-confidentiality-mitigations/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-iab-privs= ec-confidentiality-mitigations-00
--001a1140289c904b95051702d186-- From nobody Fri May 29 11:02:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7898F1A7000 for ; Fri, 29 May 2015 11:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] 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 gEHHcUJEX5AD for ; Fri, 29 May 2015 11:02:25 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616DC1B29DC for ; Fri, 29 May 2015 11:02:17 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id C47286D78F; Fri, 29 May 2015 14:02:15 -0400 (EDT) Message-ID: <5568A9A6.6060407@iang.org> Date: Fri, 29 May 2015 19:02:14 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <555FA6C5.5000004@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] draft-iab-crypto-alg-agility - 3.3, 4.1, 4.6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 18:02:27 -0000 Section 3.3 said this: 3.3. Preserving Interoperability Cryptographic algorithm deprecation is very hard. People do not like to introduce interoperability problems, even to preserve security. As a result, flawed algorithms are supported for far too long. The impacts of legacy software an long support tails on security can be reduced by making it easy to develop, deploy, and configure new algorithms. Suggest changing last two lines to this: ... reduced by making it easy to rollover old suites to new suites. Elsewise, the text would be to suggest that "adding new algorithms" is the solution when actually it's part of the problem. On 26/05/2015 17:06 pm, Russ Housley wrote: > > On May 22, 2015, at 7:02 PM, Martin Thomson wrote: >> Section 3.3 could be expanded to emphasize the social aspects of this. >> This is largely a social problem, and a difficult one: for browsers, >> we don't want to break sites because we lose users by doing so, that >> creates incentives to stay busted, but interoperable. We've found in >> browser-land that coordinating response can be highly effective at >> reducing defection. > > Thanks for this. +1 reduction of the consequences of over-agility is what we are trying to achieve, and what this document can primarily help with. > I suggest adding another paragraph: > > In many ways preserving interoperability is a difficult social problem. For example, consider web browsers. Dropping support for an algorithm suite can break connectivity to some web sites because, and the browser will lose users by doing so. This situation creates incentives to support algorithm suites that would otherwise be deprecated, but preserving interoperability. Coordinating the demise of an algorithm suite is an important aspect of the answer to this social problem. Yep, that's good. I don't like the "social problem" part. While this may sound good to our ears, it gives the impression that the users are the problem, when in fact they are simply responding to the hand we dealt them. I.e., we created the protocol, and we created it in a way that it isn't easy to deprecate old stuff. Now we're blaming them for acting precisely how the protocol channels them. How about this: Without clear mechanisms for rollover, preserving interoperability becomes a difficult social problem. For example, consider web browsers....but preserving interoperability. Institutions, being large or dominating users within a large user base, may find that coordinating the demise of an algorithm suite is an important method to minimise the trauma of rollover to the users. Notes. 1. I'm using the term "institution" in its economic sense, which is natural for me, but may be weird to others. I'm not sure what term would be comfortable here, but recall NIST is another institution (other than the browsers) that has coordinated demise in this fashion. 2. Then, it would be grand if we could also expand on ways in which the designer / WG / IANA / IETF could help by coordinating. But that's beyond my ken to write. >> Section 4.1 neglects to mention the obvious benefit in selecting >> something that lots of other people are using too. That's a >> non-trivial advantage over and above the reasons cited (though many of >> them might be considered different ways of saying the same thing). > > Yes, I think this point comes through in many ways in the document, but you are right, it should be explicit. > > I suggest adding this sentence to the middle of the first paragraph: > > There are significant benefits in selecting algorithms and suites that are widely deployed. OK. But I think the document would gain utility if it where to have a section like "x. Strategies to assist migration" with that comment, and above "social problem" solution in it. Also this: >> I find Section 4.6 baffling. The para is disjoint. It starts out with a discussion of what might happen, without clear point (to me). Then switches dramatically to how to transition. I suspect the 'bits' discussion belongs elsewhere. Then, the meat: Where possible, authors SHOULD provide notice to implementers about expected algorithm transitions. One approach is to use SHOULD+, SHOULD-, and MUST- in the specification of algorithms. ... seems happy stand-alone, following on from the title. >> We have words that we can use for these >> things. They are MUST NOT, MUST and SHOULD. None of these attempt to >> presage the future. But generating new conventions for what might or >> might not happen in the future is much harder than waiting and just >> making the change when the time comes. > > This idea is not new. It was first used with IKEv1 when Jeff Schiller was SEC AD. The idea is to give product planners a heads up. So, could this be introduced with that explanation? Something like: Where possible, authors SHOULD provide notice to implementers about expected algorithm transitions. IKEv1 introduced a mechanism to provide notice which this ID adopts [REF]. This approach uses additional hints SHOULD+, SHOULD-, and MUST- in the specification of algorithms. SHOULD+... SHOULD-... MUST-... iang From nobody Sat May 30 06:45:01 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBFF1A1B85 for ; Sat, 30 May 2015 06:45:00 -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 JNDv502NS8cH for ; Sat, 30 May 2015 06:44:58 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CACB61A1B83 for ; Sat, 30 May 2015 06:44:58 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id B064A6D75D; Sat, 30 May 2015 09:44:53 -0400 (EDT) Message-ID: <5569BED4.2070102@iang.org> Date: Sat, 30 May 2015 14:44:52 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Russ Housley References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <4F157EFC-CAD9-40B3-B1AE-AF05F0EAEAB3@vigilsec.com> In-Reply-To: <4F157EFC-CAD9-40B3-B1AE-AF05F0EAEAB3@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: saag@ietf.org Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 13:45:00 -0000 On 26/05/2015 21:24 pm, Russ Housley wrote: > In DNSSEC and RPKI, algorithms are used globally. RFC 6916 offers an approach to algorithm migration in the RPKI. If such is the case, then could this present draft borrow that approach and repeat it? Just to repeat, this draft delivers better value to the extent that the full life cycle is made apparent to the engineer. >> Section 2.3 hints at this but provides no meat. this: >> >> "Protocols MUST facilitate the selection to >> the best algorithm or suite..." >> >> is not as helpful because (a) the selection protocol itself is hard coded with this algorithm, so can't be switched without upgrade, and (b) it assumes a definition of "best" which either requires external instructions (a cipher negotiation list) or it just puts the point on the fact that the only experts of any credibility here are the original protocol designers. A point which is made in sections 2.4, 4.1! > > Do you think this works better? > > Algorithm transition is naturally facilitated as part of an algorithm selection or negotiation mechanism. Protocols traditionally select the best algorithm or suite that is supported by all communicating peers and acceptable by their policies. Yes, that works better (within the context). >> 4.6 might be the only new contribution as to how to move forward on algorithms. > > It is not new. See RFC 4307. I'd suggest referencing it then, see other post. iang From nobody Sun May 31 07:22:22 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7391A1B00 for ; Sun, 31 May 2015 07:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwptI5-ekGba for ; Sun, 31 May 2015 07:22:19 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E511A1AFC for ; Sun, 31 May 2015 07:22:19 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so71146981lbb.2 for ; Sun, 31 May 2015 07:22:17 -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=LQTswi8wuDxIOi+UtPhiRSfMk3GiHVuGFKJpzrLUYJk=; b=lt93WT+liUQ0uJQnNdYgem07VX0pGbK+OZuW3XMNuKieCQVFoYuS2FyLsE9N/ccufV o2n0RVv42GaU7dlN93QTZa1vAOE7kbFACp8tKREiiBx5Ps91TnuyvWwa9sJvCYxo8dQp OTKNf/ZPmXMHrj8kh2yXuGCeR7QSAZBr9JiNOcKbe4auHCh1W9BkFqwK46r4anZLnhDH zC1/7CIDAu3opopg7T2Cu31Q5yyhnA0dDZY1dIEHyLSInxdNFZipotF06rbHR3rZKzNX vv6cHQN1sorpr5vObGc4b11hc70mEtFpzBMJgg3G+PqOxqqDAorLc9rb3A5sN2UxCq48 35Mw== MIME-Version: 1.0 X-Received: by 10.112.40.9 with SMTP id t9mr17148791lbk.55.1433082137517; Sun, 31 May 2015 07:22:17 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Sun, 31 May 2015 07:22:17 -0700 (PDT) In-Reply-To: <555FA6C5.5000004@cs.tcd.ie> References: <555FA6C5.5000004@cs.tcd.ie> Date: Sun, 31 May 2015 10:22:17 -0400 X-Google-Sender-Auth: ZBmjWPBeC9nWVMM5T9c9vjBANXk Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11336578bda5a50517616f41 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 14:22:20 -0000 --001a11336578bda5a50517616f41 Content-Type: text/plain; charset=UTF-8 Comments Section 2.2 " Note that this is not done for protocols that are embedded in other protocols, where the system-level protocol specification identifies the mandatory-to-implement algorithm or suite." I would rather this is called out as a named exception, 'Specifications that provide a platform' or some such. The reason for this is that I have sat through many unproductive hours of argument over what should be MTI in what is obviously a platform spec. Having RSA-SHA1 be MTI in XML Signature only hurts. As written, the language uses 'protocol' which is too narrow. Only some IETF specs are protocols. "To achieve this goal, the base protocol specification includes a reference to a companion algorithms document, allowing the update of one document without necessarily requiring an update to the other. " I would prefer it if the 'companion document' can be shared across specs. As a practical matter, a mail client has to use TLS these days. Ergo the intersection of the cipher suites supported by TLS, OpenPGP and S/MIME should be non-zero and be MTI for the 'email' domain. --001a11336578bda5a50517616f41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Comments

Section 2.2

" Note that this= is not done for protocols that are embedded in
=C2=A0 =C2=A0other protocols, where the system-level protocol specific= ation
=C2=A0 =C2=A0identifies the mandatory= -to-implement algorithm or suite."
I would rather this is called out as a na= med exception, 'Specifications that provide a platform' or some suc= h.

The= reason for this is that I have sat through many unproductive hours of argu= ment over what should be MTI in what is obviously a platform spec. Having R= SA-SHA1 be MTI in XML Signature only hurts.

As written, the language uses 'pr= otocol' which is too narrow. Only some IETF specs are protocols.
<= div class=3D"gmail_extra">
"To ach= ieve this
=C2=A0 =C2=A0goal, the base proto= col specification includes a reference to a
=C2=A0 =C2=A0companion algorithms document, allowing the update of one doc= ument
=C2=A0 =C2=A0without necessarily requ= iring an update to the other. =C2=A0"
=
I would prefer it if the 'companio= n document' can be shared across specs. As a practical matter, a mail c= lient has to use TLS these days. Ergo the intersection of the cipher suites= supported by TLS, OpenPGP and S/MIME should be non-zero and be MTI for the= 'email' domain.



--001a11336578bda5a50517616f41--