From nobody Sat Aug 1 00:29:05 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 8E4B71B2B22 for ; Sat, 1 Aug 2015 00:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 qDEIaANzZunb for ; Sat, 1 Aug 2015 00:29:02 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6261B2B1F for ; Sat, 1 Aug 2015 00:29:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2D8C2224083E; Sat, 1 Aug 2015 09:28:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f6bIdpiqh7w; Sat, 1 Aug 2015 09:28:30 +0200 (CEST) Received: from [10.192.1.135] (LStLambert-656-1-53-31.w80-13.abo.wanadoo.fr [80.13.34.31]) by power.freeradius.org (Postfix) with ESMTPSA id 1787F2240126; Sat, 1 Aug 2015 09:28:29 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Sat, 1 Aug 2015 09:28:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com> <55B8A692.8080409@cs.tcd.ie> <55B8D49A.1010402@cs.tcd.ie> To: Randy Bush X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] New Version Notification for draft-cui-dhc-dhcpv6-encryption-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: Sat, 01 Aug 2015 07:29:04 -0000 On Jul 29, 2015, at 9:47 PM, Randy Bush wrote: > within an enterprise, one is tempted to suggest enterprise-controlled > credential distribution; i get a cert (or whatever) oob to let my = laptop > authenticate the dhcp service and vice versa. but enterprises are > seeing a lot of byod, and i am not sure how they are dealing with = that. > do they really want to authenticate all mobiles? Yes. Enterprises are moving to ubiquitous 802.1X, both for wired and = wireless. All end-user devices will be authenticated. In those situations, it should be trivial to sign the DHCP packets = with a key derived from the 802.1X session. That signals the end device = that the DHCP server is run under the same organization as the 802.1X = authenticator. The main reason this doesn't happen (so far as I can = tell) is that the DHCP and 802.1X groups don't talk much. Either at the = IETF, or inside of corporations developing operating systems. > in the coffee shop, one would like the mobile device to be given the > dhcp server's credentials out of band; i suggested a QR code on the = wall > as one (i.e. there could be others) example. and, unlike the > enterprise, i think the mobile device should reveal as little as > possible about itself. Or, just move to 802.1X, and then sign the DHCP packets as above. The = Hotspot 2.0 standard from the WiFi alliance uses 802.1X for all = hotspots. > bottom line: i do not think there are easy solutions in the = introduction > space. but it is our responsibility. and i am trying to think about > it and others should too. The main barrier to adoption is deploying the solutions. The = technologies described above are ubiquitous in isolation... the only new = thing required is for them to communicate. Alan DeKok. From nobody Sat Aug 1 00:32: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 A0D841B2B25 for ; Sat, 1 Aug 2015 00:32:05 -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 m7Qgavn_wNAz for ; Sat, 1 Aug 2015 00:32:04 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82EAE1B2B22 for ; Sat, 1 Aug 2015 00:32:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E7E86224083E; Sat, 1 Aug 2015 09:31:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzJ-e6oswVKP; Sat, 1 Aug 2015 09:31:33 +0200 (CEST) Received: from [10.192.1.135] (LStLambert-656-1-53-31.w80-13.abo.wanadoo.fr [80.13.34.31]) by power.freeradius.org (Postfix) with ESMTPSA id 40E582240126; Sat, 1 Aug 2015 09:31:33 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Sat, 1 Aug 2015 09:31:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E607681-7B1F-4128-9F24-D98FE23AA958@deployingradius.com> References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com> <55B8A692.8080409@cs.tcd.ie> <55B8D49A.1010402@cs.tcd.ie> To: Christian Huitema X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] New Version Notification for draft-cui-dhc-dhcpv6-encryption-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: Sat, 01 Aug 2015 07:32:05 -0000 On Jul 30, 2015, at 2:17 AM, Christian Huitema = wrote: > Even in the "trusted network" scenario, the gain is only apparent in = the absence of link-layer protection. For example, enterprise Wi-Fi = networks typically use 802.1x and EAP to negotiate a link-layer = encryption key specific to the client. This goes a long way towards = protecting all the link traffic, including DHCP. That protects the traffic from third party observers, at least at the = radio layer. It doesn't authenticate the DHCP traffic as coming from a = trusted source. The rest of the wired network may still be penetrated = and broken. > Clearly there is a residual risk of on-line attackers, such as a local = computer owned by a virus. That risk is generally mitigated by filters = in the switches, restricting the sending of DHCP and RA packets. DHCP = encryption would be useful if it was easier to deploy than those = filters, and more secure. Or just sign the DHCP packets with a key derived from the 802.1X keys. = That requires no interaction with the switches. Only the DHCP client = and server need to be updated. Alan DeKok. From nobody Sat Aug 1 18:27: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 41C571A88E4 for ; Sat, 1 Aug 2015 18:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 khaoPHamkBF4 for ; Sat, 1 Aug 2015 18:27:25 -0700 (PDT) Received: from BLU004-OMC2S28.hotmail.com (blu004-omc2s28.hotmail.com [65.55.111.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFBD1A88E2 for ; Sat, 1 Aug 2015 18:27:25 -0700 (PDT) Received: from BLU181-W40 ([65.55.111.72]) by BLU004-OMC2S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 1 Aug 2015 18:27:24 -0700 X-TMN: [JqBmDgHymDH7fRmS1S6tbNpluaS7jgnH] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_8c619a94-2876-48cd-a475-6c65f88a7ac3_" From: Bernard Aboba To: Alan DeKok Date: Sat, 1 Aug 2015 18:27:24 -0700 Importance: Normal In-Reply-To: <4E607681-7B1F-4128-9F24-D98FE23AA958@deployingradius.com> References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com>, <55B8A692.8080409@cs.tcd.ie>, <55B8D49A.1010402@cs.tcd.ie>, , , <4E607681-7B1F-4128-9F24-D98FE23AA958@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 02 Aug 2015 01:27:24.0388 (UTC) FILETIME=[629C5A40:01D0CCC2] Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] New Version Notification for draft-cui-dhc-dhcpv6-encryption-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: Sun, 02 Aug 2015 01:27:27 -0000 --_8c619a94-2876-48cd-a475-6c65f88a7ac3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alan said:=20 "Or just sign the DHCP packets with a key derived from the 802.1X keys. Th= at requires no interaction with the switches. Only the DHCP client and ser= ver need to be updated." [BA] Authenticating a DHCP packet with a unicast key derived between the st= ation and the AP would not prove authorization to act as a DHCP server=2C s= o IMHO it would not add any value beyond what is already provided by 802.11= security. Similarly=2C authenticating a multicast DHCP packet with a key = derived from the 802.11 group key would also not demonstrate authorization = to act as a DHCP server so that also adds no value. = --_8c619a94-2876-48cd-a475-6c65f88a7ac3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Alan said: =3B

"Or just sign the DHCP packets with a key derived from the= 802.1X keys. That requires no interaction with the switches. Only the DH= CP client and server need to be updated."


= [BA] Authenticating a DHCP packet with a unicast key derived between the st= ation and the AP would not prove authorization to act as a DHCP server=2C s= o IMHO it would not add any value beyond what is already provided by 802.11= security.  =3BSimilarly=2C authenticating a multicast DHCP packet with= a key derived from the 802.11 group key would also not demonstrate authori= zation to act as a DHCP server so that also adds no value. =3B
= = --_8c619a94-2876-48cd-a475-6c65f88a7ac3_-- From nobody Sun Aug 2 01:17: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 BE4381A1EF1 for ; Sun, 2 Aug 2015 01:17:32 -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 DSMNyHM2saW4 for ; Sun, 2 Aug 2015 01:17:30 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92C4C1A1EEA for ; Sun, 2 Aug 2015 01:17:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 3766A2240720; Sun, 2 Aug 2015 10:17:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnXm77W6IFxx; Sun, 2 Aug 2015 10:17:28 +0200 (CEST) Received: from [10.192.1.135] (LPoitiers-656-1-89-54.w193-251.abo.wanadoo.fr [193.251.88.54]) by power.freeradius.org (Postfix) with ESMTPSA id 815D022401C5; Sun, 2 Aug 2015 10:17:28 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Sun, 2 Aug 2015 10:17:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85F31297-B08F-4A86-B9A0-8004FB78DD01@deployingradius.com> References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com>, <55B8A692.8080409@cs.tcd.ie>, <55B8D49A.1010402@cs.tcd.ie>, , , <4E607681-7B1F-4128-9F24-D98FE23AA958@deployingradius.com> To: Aboba Bernard X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] New Version Notification for draft-cui-dhc-dhcpv6-encryption-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: Sun, 02 Aug 2015 08:17:32 -0000 On Aug 2, 2015, at 3:27 AM, Bernard Aboba = wrote: > [BA] Authenticating a DHCP packet with a unicast key derived between = the station and the AP would not prove authorization to act as a DHCP = server, so IMHO it would not add any value beyond what is already = provided by 802.11 security. That's true. All it would do was signal that the DHCP packet came = from the AP. Which we already know. > Similarly, authenticating a multicast DHCP packet with a key derived = from the 802.11 group key would also not demonstrate authorization to = act as a DHCP server so that also adds no value.=20 Sure, but that's not what I meant. I was thinking of the MSK / EMSK, which are derived from the EAP = session, and typically the TLS session. The EAPOL Key is in turn = derived from that. It should be possible to derive a DHCP session key from the MSK. The = authentication server can send the DHCP session key to the DHCP server, = which can then use it to sign DHCP packets. The supplicant can do the = same thing, and validate the incoming DHCP packet. The key would be = unique to each session. It would also be possible to use the MSK to = derive a unique MAC address for the device, which would signal to the = DHCP server that the device had previously been authenticated via = 802.1X. And that identity derivation would solve most of the issues = around privacy of identifiers. This is imperfect, of course. It presumes that 802.1X is used, which = isn't always the case. Other methods will be needed in other = circumstances. Alan DeKok. From nobody Sun Aug 2 01:32: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 D0EDD1A6FEC for ; Sun, 2 Aug 2015 01:32:28 -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, 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 n6zBtKktfCcJ for ; Sun, 2 Aug 2015 01:32:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05AC41A6FE9 for ; Sun, 2 Aug 2015 01:32:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZLogy-0006PO-J8; Sun, 02 Aug 2015 08:32:24 +0000 Date: Sun, 02 Aug 2015 17:32:23 +0900 Message-ID: From: Randy Bush To: DeKok Alan In-Reply-To: <85F31297-B08F-4A86-B9A0-8004FB78DD01@deployingradius.com> References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] New Version Notification for draft-cui-dhc-dhcpv6-encryption-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: Sun, 02 Aug 2015 08:32:29 -0000 > This is imperfect, of course. It presumes that 802.1X is used, > which isn't always the case. Other methods will be needed in > other circumstances. is there any chance we can enumerate the significant scenarios so that we can start to understand how they might be handled? randy From nobody Mon Aug 3 05:05: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 8E4B21B2D08 for ; Mon, 3 Aug 2015 05:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7lF77OHhSQh for ; Mon, 3 Aug 2015 05:05:43 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6555E1B2D09 for ; Mon, 3 Aug 2015 05:05:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id D7DCB2075B; Mon, 3 Aug 2015 08:04:47 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6c-kxGNZ0-xe; Mon, 3 Aug 2015 08:04:47 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 3 Aug 2015 08:04:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C8528804F7; Mon, 3 Aug 2015 08:05:34 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com> <55B8A692.8080409@cs.tcd.ie> <55B8D49A.1010402@cs.tcd.ie> <4E607681-7B1F-4128-9F24-D98FE23AA958@deployingradius.com> <85F31297-B08F-4A86-B9A0-8004FB78DD01@deployingradius.com> Date: Mon, 03 Aug 2015 08:05:34 -0400 In-Reply-To: <85F31297-B08F-4A86-B9A0-8004FB78DD01@deployingradius.com> (Alan DeKok's message of "Sun, 2 Aug 2015 10:17:27 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] New Version Notification for draft-cui-dhc-dhcpv6-encryption-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: Mon, 03 Aug 2015 12:05:44 -0000 Bernard claims that using the EAP key hierarchy doesn't prove authorization to act as a DHCP server. There's a sense in which this is true. However, there's another sense in which being involved in the EAP keying proves that the proposed DHCP server is part of the infrastructure. I think that provides better assurance by far than we have today. My hope is that we do not let the perfect solution here become the enemy of incremental improvement. From nobody Mon Aug 3 09:07: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 95A0D1ACD35 for ; Mon, 3 Aug 2015 09:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOryhToNCAse for ; Mon, 3 Aug 2015 09:07:46 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 223BB1ACD37 for ; Mon, 3 Aug 2015 09:07:38 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 8992F3600D1; Mon, 3 Aug 2015 09:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=R8qMk/LRO/zpOD Q59J3aSHff0M4=; b=WZh6V9mcMz0jN9/F+EcUeQ+pTOYl15MI7npk/jXmx9W5Z6 d3FPLqUbYY/XgR7vf9xSrbsmenK44cnWzLuDa3f6JUPxNhY2TW571y8Y5jB9uY1n h3c+2scSY7vBZL2WJd7S1a+L51KGB7n+Qb1W9+uBPS1qmPNuFP+fea8602iUc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 6BEEC360087; Mon, 3 Aug 2015 09:07:36 -0700 (PDT) Date: Mon, 3 Aug 2015 11:07:34 -0500 From: Nico Williams To: Stephen Farrell Message-ID: <20150803160733.GM2957@localhost> References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com> <55B8A692.8080409@cs.tcd.ie> <55B8D49A.1010402@cs.tcd.ie> <165fe8ce.ef05.14eda273b12.Coremail.lilishan48@126.com> <55B8E0F2.3000403@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B8E0F2.3000403@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Fw:Fw:New Version Notification for draft-cui-dhc-dhcpv6-encryption-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: Mon, 03 Aug 2015 16:07:47 -0000 On Wed, Jul 29, 2015 at 03:19:30PM +0100, Stephen Farrell wrote: > We do I think have proof that symmetric keying for everything > fails, thanks to RFC3118, but for all the rest, as far as I know > we'd just be guessing right now. Ignoring weak passwords and applying a Kerberos-ish (but EAP-ified, meaning using IAKERB to authenticate to the infrastructure and then user-to-user Kebreros to authenticate the NAS to the client) I think symmetric keying for everything ought to work just fine. (Also ignoring the lack of PKCROSS.) Not that that's something I care to push. Just sayin'. Weak passwords obviously are a good argument for a PAKE or for at least having DH + server authentication, so PK does seem necessary, yes, but mostly for that reason, and for the bootstrapping of cross-domain trusts that a purely-symmetric Needham-Schroeder protocol has trouble with. Nico -- From nobody Mon Aug 3 09:17: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 234ED1ACE39 for ; Mon, 3 Aug 2015 09:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSnkCzY7dQtT for ; Mon, 3 Aug 2015 09:17:53 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 03EFD1ACE3A for ; Mon, 3 Aug 2015 09:17:53 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 8E70D3180A7; Mon, 3 Aug 2015 09:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=U3dfkNZZeGsq/k fK7wW2loMHt5g=; b=agbzoW6Uw6OZRO7NT6aW0EZBBKhwxlqs7MWoRDTHswSc1h cvEZ//Z6XTaZ/b1vGgaJVrEeWmZRGHejrX5izC2IKOJhlI7WTinqW2+jr6eypoNy jWvlC835S8Xk1G0HCtyjNZll0Fr3DJvgO/iKKhGF3LJmD5N3OK6wPUTkxT9MQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 1DE7631809D; Mon, 3 Aug 2015 09:17:52 -0700 (PDT) Date: Mon, 3 Aug 2015 11:17:50 -0500 From: Nico Williams To: Randy Bush Message-ID: <20150803161750.GN2957@localhost> References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com> <55B8A692.8080409@cs.tcd.ie> <55B8D49A.1010402@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Fw:Fw:New Version Notification for draft-cui-dhc-dhcpv6-encryption-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: Mon, 03 Aug 2015 16:17:54 -0000 On Thu, Jul 30, 2015 at 04:47:53AM +0900, Randy Bush wrote: > within an enterprise, one is tempted to suggest enterprise-controlled > credential distribution; i get a cert (or whatever) oob to let my laptop > authenticate the dhcp service and vice versa. but enterprises are > seeing a lot of byod, and i am not sure how they are dealing with that. > do they really want to authenticate all mobiles? Authenticating the enterprise and DHCP servers to the mobiles is one thing. Authenticating the latter to the former is another. I've no idea if enterprises want to do this, but my experience is that many enterprises that offer wifi want to force users to then VPN and/or else to accept MITM trust anchors ("you want to use our network, you pay a privacy price" is de rigeur). > in the coffee shop, one would like the mobile device to be given the > dhcp server's credentials out of band; i suggested a QR code on the wall > as one (i.e. there could be others) example. and, unlike the > enterprise, i think the mobile device should reveal as little as > possible about itself. The QR code thing works for enterprises that allows BYOD. There's also "install this app from the store using 3G/4G then you can get on our wifi". There are plenty of options; none perfect. > bottom line: i do not think there are easy solutions in the introduction > space. but it is our responsibility. and i am trying to think about > it and others should too. Yes. > [0] - i am remonded of the plethora of documents with insecure > transports where the sec cons says "use ipsec" with no hint about > keying, how the upper layer can even tell if ipsec is being used, > ... Yes, that approach is a disaster [because of a lack of standard, useful set of IPsec APIs]. But I'm like a broken record as to this. From nobody Mon Aug 3 23:41: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 CDC951B365E for ; Mon, 3 Aug 2015 23:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 9_1Z_LLDP9Lk for ; Mon, 3 Aug 2015 23:41:39 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 D906E1B365C for ; Mon, 3 Aug 2015 23:41:38 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so9523287wib.1 for ; Mon, 03 Aug 2015 23:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=Wzs3aDiWASN/TgXfXUMgKMkJLCDFH3lNHg5RhPOxtS8=; b=YBgm1QPtvLhKWVYKQgQYpOK1RuvaZnZaMTla6AMJD2ZzrTYnM4m5i3oP4H7y4j3D5v 5lMhF2BYxB8U1NIs/6S0e7+K6h08Tfy49qHcHOIezwtZbKhcaTzG6zodwOReFSXszrp1 drmy/V3IVzmeeDVFsP+jJd436P7zTkGnaZDL8G4rZbCI2vBtinTNd8V8fjlSvShjS+If ezbLdPsVPT+W5FzyMxi2W5Oj42Y7dtLczRoL+HFL7GDz6MOPs8Vm97Iu/9SOmBAt6/S8 H0Ay8nzHpNXXDq2n+ybS3aAz3t9wpTeSDBGpvZJ3EHwCCUIFA2QyRKTae7wSAMDYhnoV YREA== X-Received: by 10.180.77.200 with SMTP id u8mr4803790wiw.70.1438670497649; Mon, 03 Aug 2015 23:41:37 -0700 (PDT) Received: from [192.168.1.15] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id ez4sm634616wid.14.2015.08.03.23.41.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Aug 2015 23:41:36 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_9628D1BF-5177-4B2B-B6DC-4E4C74011566" Message-Id: <29B747CA-4723-47B4-9588-A81A89DCEB07@gmail.com> Date: Tue, 4 Aug 2015 09:41:33 +0300 To: Security Area Advisory Group Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [saag] CNN Says: Encryption a growing threat to security 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, 04 Aug 2015 06:41:41 -0000 --Apple-Mail=_9628D1BF-5177-4B2B-B6DC-4E4C74011566 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 h= ttp://edition.cnn.com/2015/08/01/opinions/rogers-encryption-security-risk/= index.html = If encryption is so dangerous to security, why does the US government = use it so much? Both the article and the video contain a bunch of nonsense, but I worry = a lot about this kind of message being sent to the public by a trusted = source such as CNN. I think the worst of this is presenting the issue as if this =E2=80=9Cmast= er key=E2=80=9D scheme is in the interest of the public, whereas the = only downside is the bottom-line of corporations. So all those tech = companies resisting such mandates are just heartlessly putting profits = before the safety of the people. It=E2=80=99s a powerful message, and = I=E2=80=99m afraid a lot of people, even well-educated ones, are buying = it. IMO key escrow with a private corporation is marginally worse than key = escrow with the government, but both mean that we can=E2=80=99t trust = the encryption. In the old Perry Mason novels, private detective Paul = Drake would go to his friend at the phone company, slip him some money = and get the phone records for whoever Perry Mason suspected. I guess in = this brave new world that Mike Rogers is advocating the new Paul Drake = would go to his friend at Google and get their TLS keys. In such a = world, I don=E2=80=99t know if it=E2=80=99s prudent for my doctor to = send me the result of my blood test over HTTPS, or for companies to move = personnel records from one data center to another over the Internet. = Back to a guy with a briefcase handcuffed to his wrist? Yoav --Apple-Mail=_9628D1BF-5177-4B2B-B6DC-4E4C74011566 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 http://edition.cnn.com/2015/08/01/opinions/rogers-encryption-se= curity-risk/index.html

If encryption is so dangerous to security, why does the US = government use it so much?

Both the article and the video contain a bunch of nonsense, = but I worry a lot about this kind of message being sent to the public by = a trusted source such as CNN.

I think the worst of this is presenting = the issue as if this =E2=80=9Cmaster key=E2=80=9D scheme is in the = interest of the public, whereas the only downside is the bottom-line of = corporations. So all those tech companies resisting such mandates are = just heartlessly putting profits before the safety of the people. It=E2=80= =99s a powerful message, and I=E2=80=99m afraid a lot of people, even = well-educated ones, are buying it.

IMO key escrow with a private = corporation is marginally worse than key escrow with the government, but = both mean that we can=E2=80=99t trust the encryption. In the old Perry = Mason novels, private detective Paul Drake would go to his friend at the = phone company, slip him some money and get the phone records for whoever = Perry Mason suspected. I guess in this brave new world that Mike Rogers = is advocating the new Paul Drake would go to his friend at Google and = get their TLS keys. In such a world, I don=E2=80=99t know if it=E2=80=99s = prudent for my doctor to send me the result of my blood test over HTTPS, = or for companies to move personnel records from one data center to = another over the Internet. Back to a guy with a briefcase handcuffed to = his wrist?

Yoav



= --Apple-Mail=_9628D1BF-5177-4B2B-B6DC-4E4C74011566-- From nobody Tue Aug 4 00:56: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 06ADB1B36E8 for ; Tue, 4 Aug 2015 00:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xc6XQS2-lhWI for ; Tue, 4 Aug 2015 00:56:57 -0700 (PDT) Received: from BLU004-OMC4S29.hotmail.com (blu004-omc4s29.hotmail.com [65.55.111.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5956B1B36FA for ; Tue, 4 Aug 2015 00:56:56 -0700 (PDT) Received: from BLU406-EAS350 ([65.55.111.135]) by BLU004-OMC4S29.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 4 Aug 2015 00:56:55 -0700 X-TMN: [wJWPenAdQT17bH7NkuSpCUpgrZeK+46Zil5g8Co7LG8=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_6220d5bc-2a1e-4f75-a806-c4b454bb295e_" References: <29B747CA-4723-47B4-9588-A81A89DCEB07@gmail.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <29B747CA-4723-47B4-9588-A81A89DCEB07@gmail.com> Date: Tue, 4 Aug 2015 00:56:50 -0700 To: Yoav Nir X-OriginalArrivalTime: 04 Aug 2015 07:56:55.0684 (UTC) FILETIME=[21D09C40:01D0CE8B] Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] CNN Says: Encryption a growing threat to security 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, 04 Aug 2015 07:56:59 -0000 --_6220d5bc-2a1e-4f75-a806-c4b454bb295e_ Content-Type: multipart/alternative; boundary="Apple-Mail-E0106BEB-0990-4AF0-AAB2-A3B6BB479356" Content-Transfer-Encoding: 7bit --Apple-Mail-E0106BEB-0990-4AF0-AAB2-A3B6BB479356 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaXMgaW1wb3J0YW50IHRvIHJlYWQgYmV0d2VlbiB0aGUgbGluZXMgb2YgdGhlc2Ugc3RhdGVt ZW50cywgd2hpY2ggY29uY2VybiBkYXRhIGF0IHJlc3QsIG5vdCBpbiB0cmFuc2l0LiBFbmNyeXB0 aW9uIG9mIGRhdGEgYXQgcmVzdCBpcyBzaW11bHRhbmVvdXNseSBub3Qgd2lkZWx5IGRlcGxveWVk IGVub3VnaCBhbmQgYXQgdGhlIHNhbWUgdGltZSwgZGlmZmljdWx0IHRvIG92ZXJjb21lIGZvciBs YXcgZW5mb3JjZW1lbnQgYWdlbmNpZXMgbGFja2luZyB0aGUgZnVuZGluZyBhbmQgc29waGlzdGlj YXRpb24gb2YgbWlsaXRhcnkgYW5kIHN1cnZlaWxsYW5jZSBhZ2VuY2llcy4NCg0KVGhvc2UgYWdl bmNpZXMsIHdobyB1bmRlcnN0YW5kIHRoZSB0ZWNobm9sb2d5IGFuZCB0cmFkZSBvZmZzIG11Y2gg YmV0dGVyLCBoYXZlIGVpdGhlciBiZWVuIHNpbGVudCBvbiB0aGUgc3ViamVjdCwgb3IgaGF2ZSBh bHVtbmkgd2hvIG5vdyBvcGVubHkgb3Bwb3NlIHRoZSBwcm9wb3NhbHMgZnJvbQ0KTGF3IGVuZm9y Y2VtZW50LiANCg0KV2UgaGF2ZSBzZWVuIHRoaXMgbW92aWUgYmVmb3JlLiBJdCBtYXR0ZXJzIGxp dHRsZSBpZiBDTk4gcHJldGVuZHMgaXQgaXMgYSBuZXcgcmVsZWFzZSByYXRoZXIgdGhhbiBhIHJl bWFrZS4NCg0KDQoNCk9uIEF1ZyAzLCAyMDE1LCBhdCAxMTo0MSBQTSwgWW9hdiBOaXIgPHluaXIu aWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gaHR0cDovL2VkaXRpb24uY25uLmNvbS8yMDE1 LzA4LzAxL29waW5pb25zL3JvZ2Vycy1lbmNyeXB0aW9uLXNlY3VyaXR5LXJpc2svaW5kZXguaHRt bA0KPiANCj4gSWYgZW5jcnlwdGlvbiBpcyBzbyBkYW5nZXJvdXMgdG8gc2VjdXJpdHksIHdoeSBk b2VzIHRoZSBVUyBnb3Zlcm5tZW50IHVzZSBpdCBzbyBtdWNoPw0KPiANCj4gQm90aCB0aGUgYXJ0 aWNsZSBhbmQgdGhlIHZpZGVvIGNvbnRhaW4gYSBidW5jaCBvZiBub25zZW5zZSwgYnV0IEkgd29y cnkgYSBsb3QgYWJvdXQgdGhpcyBraW5kIG9mIG1lc3NhZ2UgYmVpbmcgc2VudCB0byB0aGUgcHVi bGljIGJ5IGEgdHJ1c3RlZCBzb3VyY2Ugc3VjaCBhcyBDTk4uDQo+IA0KPiBJIHRoaW5rIHRoZSB3 b3JzdCBvZiB0aGlzIGlzIHByZXNlbnRpbmcgdGhlIGlzc3VlIGFzIGlmIHRoaXMg4oCcbWFzdGVy IGtleeKAnSBzY2hlbWUgaXMgaW4gdGhlIGludGVyZXN0IG9mIHRoZSBwdWJsaWMsIHdoZXJlYXMg dGhlIG9ubHkgZG93bnNpZGUgaXMgdGhlIGJvdHRvbS1saW5lIG9mIGNvcnBvcmF0aW9ucy4gU28g YWxsIHRob3NlIHRlY2ggY29tcGFuaWVzIHJlc2lzdGluZyBzdWNoIG1hbmRhdGVzIGFyZSBqdXN0 IGhlYXJ0bGVzc2x5IHB1dHRpbmcgcHJvZml0cyBiZWZvcmUgdGhlIHNhZmV0eSBvZiB0aGUgcGVv cGxlLiBJdOKAmXMgYSBwb3dlcmZ1bCBtZXNzYWdlLCBhbmQgSeKAmW0gYWZyYWlkIGEgbG90IG9m IHBlb3BsZSwgZXZlbiB3ZWxsLWVkdWNhdGVkIG9uZXMsIGFyZSBidXlpbmcgaXQuDQo+IA0KPiBJ TU8ga2V5IGVzY3JvdyB3aXRoIGEgcHJpdmF0ZSBjb3Jwb3JhdGlvbiBpcyBtYXJnaW5hbGx5IHdv cnNlIHRoYW4ga2V5IGVzY3JvdyB3aXRoIHRoZSBnb3Zlcm5tZW50LCBidXQgYm90aCBtZWFuIHRo YXQgd2UgY2Fu4oCZdCB0cnVzdCB0aGUgZW5jcnlwdGlvbi4gSW4gdGhlIG9sZCBQZXJyeSBNYXNv biBub3ZlbHMsIHByaXZhdGUgZGV0ZWN0aXZlIFBhdWwgRHJha2Ugd291bGQgZ28gdG8gaGlzIGZy aWVuZCBhdCB0aGUgcGhvbmUgY29tcGFueSwgc2xpcCBoaW0gc29tZSBtb25leSBhbmQgZ2V0IHRo ZSBwaG9uZSByZWNvcmRzIGZvciB3aG9ldmVyIFBlcnJ5IE1hc29uIHN1c3BlY3RlZC4gSSBndWVz cyBpbiB0aGlzIGJyYXZlIG5ldyB3b3JsZCB0aGF0IE1pa2UgUm9nZXJzIGlzIGFkdm9jYXRpbmcg dGhlIG5ldyBQYXVsIERyYWtlIHdvdWxkIGdvIHRvIGhpcyBmcmllbmQgYXQgR29vZ2xlIGFuZCBn ZXQgdGhlaXIgVExTIGtleXMuIEluIHN1Y2ggYSB3b3JsZCwgSSBkb27igJl0IGtub3cgaWYgaXTi gJlzIHBydWRlbnQgZm9yIG15IGRvY3RvciB0byBzZW5kIG1lIHRoZSByZXN1bHQgb2YgbXkgYmxv b2QgdGVzdCBvdmVyIEhUVFBTLCBvciBmb3IgY29tcGFuaWVzIHRvIG1vdmUgcGVyc29ubmVsIHJl Y29yZHMgZnJvbSBvbmUgZGF0YSBjZW50ZXIgdG8gYW5vdGhlciBvdmVyIHRoZSBJbnRlcm5ldC4g QmFjayB0byBhIGd1eSB3aXRoIGEgYnJpZWZjYXNlIGhhbmRjdWZmZWQgdG8gaGlzIHdyaXN0Pw0K PiANCj4gWW9hdg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBzYWFnIG1haWxpbmcgbGlzdA0KPiBzYWFnQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0K --Apple-Mail-E0106BEB-0990-4AF0-AAB2-A3B6BB479356 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SXQgaXMg aW1wb3J0YW50IHRvIHJlYWQgYmV0d2VlbiB0aGUgbGluZXMgb2YgdGhlc2Ugc3RhdGVtZW50cywg d2hpY2ggY29uY2VybiBkYXRhIGF0IHJlc3QsIG5vdCBpbiB0cmFuc2l0LiBFbmNyeXB0aW9uIG9m IGRhdGEgYXQgcmVzdCBpcyBzaW11bHRhbmVvdXNseSBub3Qgd2lkZWx5IGRlcGxveWVkIGVub3Vn aCBhbmQgYXQgdGhlIHNhbWUgdGltZSwgZGlmZmljdWx0IHRvIG92ZXJjb21lIGZvciBsYXcgZW5m b3JjZW1lbnQgYWdlbmNpZXMgbGFja2luZyB0aGUgZnVuZGluZyBhbmQgc29waGlzdGljYXRpb24g b2YgbWlsaXRhcnkgYW5kIHN1cnZlaWxsYW5jZSBhZ2VuY2llcy48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2PlRob3NlIGFnZW5jaWVzLCB3aG8gdW5kZXJzdGFuZCB0aGUgdGVjaG5vbG9neSBhbmQg dHJhZGUgb2ZmcyBtdWNoIGJldHRlciwgaGF2ZSBlaXRoZXIgYmVlbiBzaWxlbnQgb24gdGhlIHN1 YmplY3QsIG9yIGhhdmUgYWx1bW5pIHdobyBub3cgb3Blbmx5IG9wcG9zZSB0aGUgcHJvcG9zYWxz IGZyb208L2Rpdj48ZGl2PkxhdyBlbmZvcmNlbWVudC4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2PldlIGhhdmUgc2VlbiB0aGlzIG1vdmllIGJlZm9yZS4gSXQgbWF0dGVycyBsaXR0bGUg aWYgQ05OIHByZXRlbmRzIGl0IGlzIGEgbmV3IHJlbGVhc2UgcmF0aGVyIHRoYW4gYSByZW1ha2Uu PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5P biBBdWcgMywgMjAxNSwgYXQgMTE6NDEgUE0sIFlvYXYgTmlyICZsdDs8YSBocmVmPSJtYWlsdG86 eW5pci5pZXRmQGdtYWlsLmNvbSI+eW5pci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PG1ldGEgaHR0 cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWwgY2hhcnNldD11dGYtOCI+ PGEgaHJlZj0iaHR0cDovL2VkaXRpb24uY25uLmNvbS8yMDE1LzA4LzAxL29waW5pb25zL3JvZ2Vy cy1lbmNyeXB0aW9uLXNlY3VyaXR5LXJpc2svaW5kZXguaHRtbCIgY2xhc3M9IiI+aHR0cDovL2Vk aXRpb24uY25uLmNvbS8yMDE1LzA4LzAxL29waW5pb25zL3JvZ2Vycy1lbmNyeXB0aW9uLXNlY3Vy aXR5LXJpc2svaW5kZXguaHRtbDwvYT48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48 ZGl2IGNsYXNzPSIiPklmIGVuY3J5cHRpb24gaXMgc28gZGFuZ2Vyb3VzIHRvIHNlY3VyaXR5LCB3 aHkgZG9lcyB0aGUgVVMgZ292ZXJubWVudCB1c2UgaXQgc28gbXVjaD88L2Rpdj48ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPkJvdGggdGhlIGFydGljbGUgYW5k IHRoZSB2aWRlbyBjb250YWluIGEgYnVuY2ggb2Ygbm9uc2Vuc2UsIGJ1dCBJIHdvcnJ5IGEgbG90 IGFib3V0IHRoaXMga2luZCBvZiBtZXNzYWdlIGJlaW5nIHNlbnQgdG8gdGhlIHB1YmxpYyBieSBh IHRydXN0ZWQgc291cmNlIHN1Y2ggYXMgQ05OLjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+SSB0aGluayB0aGUgd29yc3Qgb2YgdGhpcyBpcyBwcmVz ZW50aW5nIHRoZSBpc3N1ZSBhcyBpZiB0aGlzIOKAnG1hc3RlciBrZXnigJ0gc2NoZW1lIGlzIGlu IHRoZSBpbnRlcmVzdCBvZiB0aGUgcHVibGljLCB3aGVyZWFzIHRoZSBvbmx5IGRvd25zaWRlIGlz IHRoZSBib3R0b20tbGluZSBvZiBjb3Jwb3JhdGlvbnMuIFNvIGFsbCB0aG9zZSB0ZWNoIGNvbXBh bmllcyByZXNpc3Rpbmcgc3VjaCBtYW5kYXRlcyBhcmUganVzdCBoZWFydGxlc3NseSBwdXR0aW5n IHByb2ZpdHMgYmVmb3JlIHRoZSBzYWZldHkgb2YgdGhlIHBlb3BsZS4gSXTigJlzIGEgcG93ZXJm dWwgbWVzc2FnZSwgYW5kIEnigJltIGFmcmFpZCBhIGxvdCBvZiBwZW9wbGUsIGV2ZW4gd2VsbC1l ZHVjYXRlZCBvbmVzLCBhcmUgYnV5aW5nIGl0LjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+SU1PIGtleSBlc2Nyb3cgd2l0aCBhIHByaXZhdGUgY29y cG9yYXRpb24gaXMgbWFyZ2luYWxseSB3b3JzZSB0aGFuIGtleSBlc2Nyb3cgd2l0aCB0aGUgZ292 ZXJubWVudCwgYnV0IGJvdGggbWVhbiB0aGF0IHdlIGNhbuKAmXQgdHJ1c3QgdGhlIGVuY3J5cHRp b24uIEluIHRoZSBvbGQgUGVycnkgTWFzb24gbm92ZWxzLCBwcml2YXRlIGRldGVjdGl2ZSBQYXVs IERyYWtlIHdvdWxkIGdvIHRvIGhpcyBmcmllbmQgYXQgdGhlIHBob25lIGNvbXBhbnksIHNsaXAg aGltIHNvbWUgbW9uZXkgYW5kIGdldCB0aGUgcGhvbmUgcmVjb3JkcyBmb3Igd2hvZXZlciBQZXJy eSBNYXNvbiBzdXNwZWN0ZWQuIEkgZ3Vlc3MgaW4gdGhpcyBicmF2ZSBuZXcgd29ybGQgdGhhdCBN aWtlIFJvZ2VycyBpcyBhZHZvY2F0aW5nIHRoZSBuZXcgUGF1bCBEcmFrZSB3b3VsZCBnbyB0byBo aXMgZnJpZW5kIGF0IEdvb2dsZSBhbmQgZ2V0IHRoZWlyIFRMUyBrZXlzLiBJbiBzdWNoIGEgd29y bGQsIEkgZG9u4oCZdCBrbm93IGlmIGl04oCZcyBwcnVkZW50IGZvciBteSBkb2N0b3IgdG8gc2Vu ZCBtZSB0aGUgcmVzdWx0IG9mIG15IGJsb29kIHRlc3Qgb3ZlciBIVFRQUywgb3IgZm9yIGNvbXBh bmllcyB0byBtb3ZlIHBlcnNvbm5lbCByZWNvcmRzIGZyb20gb25lIGRhdGEgY2VudGVyIHRvIGFu b3RoZXIgb3ZlciB0aGUgSW50ZXJuZXQuIEJhY2sgdG8gYSBndXkgd2l0aCBhIGJyaWVmY2FzZSBo YW5kY3VmZmVkIHRvIGhpcyB3cmlzdD88L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48 L2Rpdj48ZGl2IGNsYXNzPSIiPllvYXY8L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48 L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzwvc3Bhbj48YnI+PHNwYW4+c2FhZyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhy ZWY9Im1haWx0bzpzYWFnQGlldGYub3JnIj5zYWFnQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNw YW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWc8L2E+PC9zcGFuPjxicj48 L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-E0106BEB-0990-4AF0-AAB2-A3B6BB479356-- --_6220d5bc-2a1e-4f75-a806-c4b454bb295e_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_6220d5bc-2a1e-4f75-a806-c4b454bb295e_-- From nobody Tue Aug 4 01:54:24 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 6396F1B3735 for ; Tue, 4 Aug 2015 01:54:23 -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 J8zKpwY-Qtcn for ; Tue, 4 Aug 2015 01:54:22 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36BC1A0248 for ; Tue, 4 Aug 2015 01:54:21 -0700 (PDT) Received: by wibud3 with SMTP id ud3so167322633wib.1 for ; Tue, 04 Aug 2015 01:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yoa014W7Zxnj5mdbw6A5dj45ODP+3cQ+48v7tq9WEMI=; b=iDp/LBKOXD0iKrxJME1nx0wYmdkeE/4IfYHCNf7glcFWmkUkzAvV7aeIeY7mlYgJrP 1ltzOfr82J++QZDf5f/VPnM99nDmK6saKSaIJXmJeVL0fA318eZ6xZv9Lus3yqnUhInT PPTiJ/Pr6Nfe5meV4sjRTPADLEQc/pbG+71dK0KLgtrxZ0zQ5/Gok1KVm6K82jLtVYCF GYAbIRxJRBRAodC6D5jH/8FCa7fIGbQhJ17WN/vFuqrJtcO6EnpPSeENu+n5Gm1qRKTu fXjirAXr6acRfxA9TKSIKszIbiJ+qji1QLIjweNTsfBhAsw08WIWXQI6SHQP/Q4xthmM ljUw== X-Received: by 10.180.12.148 with SMTP id y20mr40450345wib.80.1438678460616; Tue, 04 Aug 2015 01:54:20 -0700 (PDT) Received: from [192.168.1.15] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id mc4sm1200984wic.6.2015.08.04.01.54.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Aug 2015 01:54:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: Date: Tue, 4 Aug 2015 11:54:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29B747CA-4723-47B4-9588-A81A89DCEB07@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] CNN Says: Encryption a growing threat to security 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, 04 Aug 2015 08:54:23 -0000 > On Aug 4, 2015, at 10:56 AM, Bernard Aboba = wrote: >=20 > It is important to read between the lines of these statements, which = concern data at rest, not in transit. Encryption of data at rest is = simultaneously not widely deployed enough and at the same time, = difficult to overcome for law enforcement agencies lacking the funding = and sophistication of military and surveillance agencies. >=20 > Those agencies, who understand the technology and trade offs much = better, have either been silent on the subject, or have alumni who now = openly oppose the proposals from > Law enforcement.=20 >=20 > We have seen this movie before. It matters little if CNN pretends it = is a new release rather than a remake. The movie is not new but the text is. It specifically talks about = communications, giving email and messaging apps as examples. While the = encryption of messages in transit is not widely deployed on the = Internet, setting up even S/MIME or PGP among a small group is fairly = easy and overcoming it is hard. Who are the agencies who are silent or opposed? I haven=E2=80=99t heard = many in either the US or the UK. Yoav From nobody Tue Aug 4 06:19: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 718F71A90ED for ; Tue, 4 Aug 2015 06:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kM8vkotCRda for ; Tue, 4 Aug 2015 06:19: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 4E2811A9145 for ; Tue, 4 Aug 2015 06:19:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2CEC5BE7B for ; Tue, 4 Aug 2015 14:19:03 +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 cHLPBsB2ki3M for ; Tue, 4 Aug 2015 14:19:01 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.103]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A3F0ABE77 for ; Tue, 4 Aug 2015 14:19:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438694341; bh=rmHCYLslmGmEaUkZ2LjOD3Ch2HqKBSq3ugeAvAxOL/U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=JOJ8asSoJXD+gvvQXzxlSRsmUavBgCdLVCfZUXtT8aCanlm8/68uw8d2pzj3G7dhJ lR1a31LCmLp5kjU4qyTvTePwfHhdMrAtliwVxh3IP/neycz4yTXnUJI2Eb0hs/k3Uo fGXw/gIQ/x1MqxiSm5k5gsHfOxWh7kjAbs8Bxsw0= Message-ID: <55C0BBC5.4030605@cs.tcd.ie> Date: Tue, 04 Aug 2015 14:19:01 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <55A26484.7050807@cs.tcd.ie> <87fv4ts9l2.fsf@latte.josefsson.org> <55A2AD94.3040604@tzi.org> <55B38D16.7050707@cs.tcd.ie> In-Reply-To: <55B38D16.7050707@cs.tcd.ie> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] keys under doormats: is our doormat ok? 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, 04 Aug 2015 13:19:39 -0000 On 25/07/15 14:20, Stephen Farrell wrote: > > Hiya, > > On 12/07/15 19:10, Carsten Bormann wrote: >> >> Just as we elevated RFC 20 to STD, we could still elevate it to BCP -- a >> status that, IIRC, was just becoming available at the time RFC 1984 was >> published. > > During the saag session in Prague we asked about this (more when I get > a chance to merge the good meeting notes we got). My conclusion from > that was that there seems to be a reasonable consensus among those who > were there and claimed to understand the issues to do as Carsten > suggests and there was almost no support for revising the text and > issuing a substantive update. > > That means we try to upgrade RFC 1984 to BCP status in-place without > changes to the text or the RFC number. > > I'm checking with the IESG and IAB to see if this plan causes them > angst and will report back in a week(ish) and take it from there. (So > get ready for, but please don't yet start, the potentially "fun" > process debate about the "C" in BCP - we'll undoubtedly do that in > an IETF last call;-) IAB and IESG seem sanguine about this, so I've written up the status change thing in the tracker. [1] I'll start IETF last call on that in a day or two. Comments are welcome in the meantime of course. Cheers, S. [1] https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/ > > Cheers, > S. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Tue Aug 4 07:17:33 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 73DC21A1B21 for ; Tue, 4 Aug 2015 07:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Jb7hBaZlvOVv for ; Tue, 4 Aug 2015 07:17:30 -0700 (PDT) Received: from BLU004-OMC4S28.hotmail.com (blu004-omc4s28.hotmail.com [65.55.111.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3A11A1B05 for ; Tue, 4 Aug 2015 07:17:29 -0700 (PDT) Received: from BLU406-EAS34 ([65.55.111.137]) by BLU004-OMC4S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 4 Aug 2015 07:17:28 -0700 X-TMN: [SAL7vetritBvEpDtcZyKXxLZYFnv8DKv] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <29B747CA-4723-47B4-9588-A81A89DCEB07@gmail.com> From: Bernard Aboba To: Yoav Nir In-Reply-To: Date: Tue, 4 Aug 2015 07:17:24 -0700 MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 04 Aug 2015 14:17:28.0484 (UTC) FILETIME=[4B396640:01D0CEC0] Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] CNN Says: Encryption a growing threat to security 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, 04 Aug 2015 14:17:31 -0000 Here is an article on alumni who are opposed: http://www.itnews.com.au/News/407105,top-former-us-security-officials-oppose= -encryption-backdoors.aspx Here is the article on the new mandates: http://www.itnews.com.au/News/405036,white-house-mandates-https-only-govt-we= bsites.aspx From nobody Tue Aug 4 08:06: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 AA1BA1A0162 for ; Tue, 4 Aug 2015 08:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-1Aqn5rSRVH for ; Tue, 4 Aug 2015 08:06:21 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 401631A00FF for ; Tue, 4 Aug 2015 08:06:17 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id C37742005E61F; Tue, 4 Aug 2015 08:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Nw/w6V2tQHaJNq 0WRzhMtYzFSEk=; b=JMxyHR7Zw+KBEHRngyPxq3VaX1Kv2vy6EhNBvePj3S4cTy UC5yZnHA/bodAIpG5Me3bpSkaWvFj9Ae6RAlytqgKyBMVN+nX4kBaAhsn4avk5oz c+zM2kyBYhTluvEf6uaeIsddlrPVLGxJijjdR0fYmqc2IaebqXU3kXZS4UXLc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 4FD352005E605; Tue, 4 Aug 2015 08:06:16 -0700 (PDT) Date: Tue, 4 Aug 2015 10:06:15 -0500 From: Nico Williams To: Yoav Nir Message-ID: <20150804150614.GR2957@localhost> References: <29B747CA-4723-47B4-9588-A81A89DCEB07@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] CNN Says: Encryption a growing threat to security 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, 04 Aug 2015 15:06:23 -0000 On Tue, Aug 04, 2015 at 11:54:17AM +0300, Yoav Nir wrote: > The movie is not new but the text is. It specifically talks about > communications, giving email and messaging apps as examples. While the > encryption of messages in transit is not widely deployed on the > Internet, setting up even S/MIME or PGP among a small group is fairly > easy and overcoming it is hard. Small groups of people using S/MIME or PGP (encryption) is just a source of even more interesting metadata. 80% of e-mail traffic using S/MIME or PGP (encryption) would notionally reduce the ability of intel agencies to collect message plaintexts, but the metadata would still be plenty, and anyways, any e-mail infrastruction and MUA enhancements that could get us to such pervasive encryption would likely provide many MITM opportunities and other means of gathering data (think of CALEA, at least for sites like gmail and hosted domains -- no crypto backdoors, just forced access for LEAs). To me it seems like the impact of civilian crypto on intel agencies is mostly this: curtailing the amount of plaintext and metadata that can be massively gathered on web browsing. The web is perhaps the use case with the most pervasive civilian end-to-end crypto. Metadata is really where the game is at, and TLS + CDNs -> some opacity as to that, especially if we did something strong enough as to DNS privacy (though I suspect we won't). E-mail is store-and-forward, high-latency as a social medium, but the web is real-time. Applying CALEA-style legislation to web sites seems difficult. The encrypted web's higher opacity and technical difficulty of legal surveilance compared to e-mail's strikes me as the probable motivation for intel and LEA opposition to civilian crypto. Besides, CALEA doesn't help intel agencies much. This is all just speculation, mind you. Nico -- From nobody Tue Aug 4 12:54:29 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 B633F1A8953 for ; Tue, 4 Aug 2015 12:54:28 -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 qn_yceVCKR_l for ; Tue, 4 Aug 2015 12:54:27 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id D90171A895E for ; Tue, 4 Aug 2015 12:54:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 05FDD22405AC; Tue, 4 Aug 2015 21:54:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV4-sg95Sy_k; Tue, 4 Aug 2015 21:54:24 +0200 (CEST) Received: from [192.168.30.17] (LStLambert-656-1-273-101.w90-63.abo.wanadoo.fr [90.63.181.101]) by power.freeradius.org (Postfix) with ESMTPSA id 7956922402D3; Tue, 4 Aug 2015 21:54:24 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Tue, 4 Aug 2015 21:54:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com> <55B8A692.8080409@cs.tcd.ie> <55B8D49A.1010402@cs.tcd.ie> <4E607681-7B1F-4128-9F24-D98FE23AA958@deployingradius.com> <85F31297-B08F-4A86-B9A0-8004FB78DD01@deployingradius.com> To: Sam Hartman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] New Version Notification for draft-cui-dhc-dhcpv6-encryption-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: Tue, 04 Aug 2015 19:54:28 -0000 On Aug 3, 2015, at 2:05 PM, Sam Hartman wrote: > Bernard claims that using the EAP key hierarchy doesn't prove > authorization to act as a DHCP server. >=20 > There's a sense in which this is true. It's all very true. But not overly helpful. AAA servers have certificates with an OID that says "TLS Web Server = Authentication". Yet despite that lie (or perhaps because of it), = clients use those certs for EAP / 802.1X authentication. > However, there's another sense in which being involved in the EAP = keying > proves that the proposed DHCP server is part of the infrastructure. > I think that provides better assurance by far than we have today. > My hope is that we do not let the perfect solution here become the = enemy > of incremental improvement. I agree. If you trust the AAA server to authenticate you, then it's beneficial = to have a trusted introduction to a DHCP server. You might ignore that = trust statement, but that's your decision. *Not* having that trust = statement means you're accepting DHCP packets from random systems on the = local network. Which seems worse to me. Alan DeKok. From nobody Mon Aug 10 11:21: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 5AA641B3B0A for ; Mon, 10 Aug 2015 11:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZS9ggWWuZdB3 for ; Mon, 10 Aug 2015 11:21:41 -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 AFF511B3B03 for ; Mon, 10 Aug 2015 11:21:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24513BE9C for ; Mon, 10 Aug 2015 19:21:36 +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 WVWI5ixH9Rml for ; Mon, 10 Aug 2015 19:21:34 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.218]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C29AFBE9A for ; Mon, 10 Aug 2015 19:21:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439230894; bh=G3Xf5hSozCsC2s8lxidD4B2szIHOxo+XpGaTwtnynVI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=x4MSsQocez0gVDrAaIo+qaymYaFPwbtFtmx2Zye45XMINrZpwEeorZrlQBEcrQMrI e+LKXGlJOoq4w5Br9Ml3eYgFLP/SRj0ByfpfVbw54gUpOLd6FXDizvzCPFQqV0ldnw v0zaFV0giUbYEk/fqyv9oysSVdFSZ0r4oHNnVgmU= Message-ID: <55C8EBAE.4070704@cs.tcd.ie> Date: Mon, 10 Aug 2015 19:21:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <20150810171306.11047.24159.idtracker@ietfa.amsl.com> In-Reply-To: <20150810171306.11047.24159.idtracker@ietfa.amsl.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <20150810171306.11047.24159.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP 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, 10 Aug 2015 18:21:43 -0000 As promised... As it says below, please send comments if any to ietf@ietf.org (or exceptionally to iesg@ietf.org). Thanks, S -------- Forwarded Message -------- Subject: Last Call: Recognising RFC1984 as a BCP Date: Mon, 10 Aug 2015 10:13:06 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual participant to make the following status changes: - RFC1984 from Informational to Best Current Practice (IAB and IESG Statement on Cryptographic Technology and the Internet) The supporting document for this request can be found here: https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/ The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-09-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The affected document can be obtained via https://datatracker.ietf.org/doc/rfc1984/ IESG discussion of this request can be tracked via https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/ballot/ From nobody Mon Aug 10 13:36:00 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 043881B2E1A for ; Mon, 10 Aug 2015 13:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zn2yiosrCoDt for ; Mon, 10 Aug 2015 13:35:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327951B3E0B for ; Mon, 10 Aug 2015 13:35:57 -0700 (PDT) Received: from [10.20.8.26] (ip-64-134-99-5.public.wayport.net [64.134.99.5]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t7AKYdAe029065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Aug 2015 13:34:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (12H143) In-Reply-To: <55C8EBAE.4070704@cs.tcd.ie> Date: Mon, 10 Aug 2015 16:34:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <370F0905-3815-4DA4-B21A-B321D92E12C9@isi.edu> References: <20150810171306.11047.24159.idtracker@ietfa.amsl.com> <55C8EBAE.4070704@cs.tcd.ie> To: Stephen Farrell X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP 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, 10 Aug 2015 20:35:59 -0000 I disagree with this change of status. Documents that refer to this RFC info= rmationally would all need to be considered for potential impact.=20 This does not seem to be an appropriate change. If a BCP were appropriate, a= bis revision should be the mechanism for upgrading the impact of the conten= t.=20 Joe > On Aug 10, 2015, at 2:21 PM, Stephen Farrell w= rote: >=20 >=20 > As promised... As it says below, please send comments if any > to ietf@ietf.org (or exceptionally to iesg@ietf.org). >=20 > Thanks, > S >=20 >=20 > -------- Forwarded Message -------- > Subject: Last Call: Recognising RFC1984 as a BCP > Date: Mon, 10 Aug 2015 10:13:06 -0700 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce >=20 >=20 > The IESG has received a request from an individual participant to make > the following status changes: >=20 > - RFC1984 from Informational to Best Current Practice > (IAB and IESG Statement on Cryptographic Technology and the Internet) >=20 > The supporting document for this request can be found here: >=20 > https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-pra= ctice/ >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-09-07. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > The affected document can be obtained via > https://datatracker.ietf.org/doc/rfc1984/ >=20 > IESG discussion of this request can be tracked via > https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-pra= ctice/ballot/ >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Aug 10 16:25:51 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 C86CC1A1A68 for ; Mon, 10 Aug 2015 16:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXw1Y4w8TSlA for ; Mon, 10 Aug 2015 16:25:46 -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 A12F51A1A8B for ; Mon, 10 Aug 2015 16:25:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6CF71BE8B for ; Tue, 11 Aug 2015 00:25:44 +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 XPqH_na4B8ta for ; Tue, 11 Aug 2015 00:25:42 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.218]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 592BABE87 for ; Tue, 11 Aug 2015 00:25:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439249142; bh=DR5LUPgGDVbgUYij3pPx6WdOJD41jj79alkbobNBpT4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=cgWI2ldx8KwYRCYKvTiEAk3PdqYIP7NL7lcUVK5miWOFQsfOlpAY8wFLHQH/Wp7i8 lb2WA9vts8iWg36CJOh9WNaqdX0cT479SSIZvNQIk8k4f8XYXznCkr7qtuBvlssmoE tGdkRy5CtxGNXYaK+Vz1Aj4gkEeLZFOF9MC0JO18= Message-ID: <55C932F6.7080203@cs.tcd.ie> Date: Tue, 11 Aug 2015 00:25:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <559153E0.5050102@cs.tcd.ie> In-Reply-To: <559153E0.5050102@cs.tcd.ie> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 10 Aug 2015 23:25:50 -0000 With apologies to the author/shepherd, I forgot about this one;-( I'm going to start IETF last call now. My own comments below can be handled with any other last call comments. Cheers, S. - intro: Maybe take a look at the intro to RFC7539. I think it does a good job of presenting the background (for a similar DJB production:-) so it might be worth seeing if there's anything you want to copy from that. - intro, para 1: some more references (or one ref to a survey paper) would be good - intro, para 2: "as Bernstein pointed out" requires a reference - section 13: whassup with that? why isn't the usual IETF boilerplate ok? - section 16: saying the reader "must" follow crypto research is silly as you cannot ensure readers will do that (and you know they won't:-). I think you mean that if you don't keep up to date then you might miss out when issues are found with this algorithm. If so, saying so would be better. - 17: I'm not sure the RFC editor will like references that only point to http://cr.yp.to/ or tarsnap.com. If you have better citations in addition that'd be good. From nobody Mon Aug 10 18:14: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 9AE871A87DE for ; Mon, 10 Aug 2015 18:14:58 -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 rit3SqedPPfo for ; Mon, 10 Aug 2015 18:14:56 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 84E351A87DB for ; Mon, 10 Aug 2015 18:14:56 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 50EC6F984; Mon, 10 Aug 2015 21:14:54 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id F2021200EB; Tue, 11 Aug 2015 03:14:44 +0200 (CEST) From: Daniel Kahn Gillmor To: Joe Touch , Stephen Farrell In-Reply-To: <370F0905-3815-4DA4-B21A-B321D92E12C9@isi.edu> References: <20150810171306.11047.24159.idtracker@ietfa.amsl.com> <55C8EBAE.4070704@cs.tcd.ie> <370F0905-3815-4DA4-B21A-B321D92E12C9@isi.edu> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 10 Aug 2015 21:14:42 -0400 Message-ID: <87d1yur5h9.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP 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, 11 Aug 2015 01:14:58 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon 2015-08-10 16:34:38 -0400, Joe Touch wrote: > I disagree with this change of status. Is your disagreement on process grounds or because you disagree with the analysis or sentiments expressed in RFC 1984? > Documents that refer to this RFC informationally would all need to be > considered for potential impact. I just did a review of all RFCs that refer to RFC 1984 explicitly [0] =2D------------ The RFCs are: * RFC 2804 ("IETF Policy on Wiretapping") [ reference is aggregated in "References" section, no distinction between normative/informative ] =20=20=20=20 https://tools.ietf.org/html/rfc2804#page-2 >> - The IETF restates its strongly held belief, stated at greater >> length in [RFC 1984], that both commercial development of the >> Internet and adequate privacy for its users against illegal >> intrusion requires the wide availability of strong cryptographic >> technology. * RFC 4322 ("Opportunistic Encryption using the Internet Key Exchange (IKE)") [ reference is in the "Informative References" section ] https://tools.ietf.org/html/rfc4322#section-1.1 >> The Internet Architecture Board (IAB) and Internet Engineering >> Steering Group (IESG) have taken a strong stand that the Internet >> should use powerful encryption to provide security and privacy >> [RFC1984]. The Linux FreeS/WAN project attempts to provide a >> practical means to implement this policy. * RFC 7258 ("Pervasive Monitoring Is an Attack") [ reference is in "Informative References" section; there is no normative section ] https://tools.ietf.org/html/rfc7258#section-3 >> In the past, architectural statements of this sort, e.g., [RFC1984] >> and [RFC2804], have been published as joint products of the Internet >> Engineering Steering Group (IESG) and the Internet Architecture Board >> (IAB). However, since those documents were published, the IETF and >> IAB have separated their publication "streams" as described in >> [RFC4844] and [RFC5741]. This document was initiated after >> discussions in both the IESG and IAB, but is published as an IETF- >> stream consensus document, in order to ensure that it properly >> reflects the consensus of the IETF community as a whole. =2D------------ None of these references (and none of these documents) seems to disagree in any way with RFC 1984, or to be harmed or modified by its confirmation after 19 years as a BCP. Given that 2670 of the 7460 published RFCs have some mention of cryptgraphy [1], and that at every month since the start of 2000 (i haven't looked earlier) we've published RFCs mentioning cryptography, it seems clear that encrypted communications is still something that we believe in as a community, and are continuing to rely on. I see no reason to revise our recommendation that we "would like to encourage policies that allow ready access to uniform strong cryptographic technology for all Internet users in all countries." --dkg [0] $ egrep -il 'rfc.?1984' rfc*.html=20 rfc1984.html rfc2804.html rfc4322.html rfc7258.html $=20 [1]=20 $ egrep -il '(en|de)crypt|crypt(o|ed|-hash|-pw|analy(sis|ze))' rfc*.html | = wc -l 2670 $ ls rfc*.html | wc -l 7460 $=20 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJVyUyCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcXjMQAL2gKhp4l4fvh8vjXldNpeq8 Yh0hSAO14pBPNtrzlrDMh/JbXeiumxP8AOhoMr4rOOu/lV93a0IgM4fAiWQqjKaI 9JYNYEMe4tLKIz05qmI1FTqZkK47nqQ1SXB6DDwIuzRZeeVc4qrz7whxULbcDNPq CoQSFQeUdHaYvV/t72//lbfURl3wvB/uq7Mof1cRwO2Y/+A+Plz+qJBXppx8sjZD LFoSZl8zW3+yPtbW6z5jVXcf+Kmi4QadAGMF1p1qaFnLVXlqaszMissfp9omR8rg wnzITVdDsaH1Y7zqbY+ufvhQ1XNlFZV4/V8Q5L9vxEcl5QJfhJu200QMMgNSZrHl 9YymR1g2NOYSrW4DkQtfrDa6HCJMdFdn7qj6/nfBb6rJUpxWvj4w8JfXfqSLzsNk bIDirTDkhPBn9baaWY/YBiwrHVZlYzsUfSX7vPovNz/sdU76NAA2kWmpjbbVJ5Fx e4p3qSd19iZHjL6IC1Isy+XTTwhVSc00kUb1da/tMHvqPKsDBYVmp5P0wkBxtbNj W0xuRCrIoQ7dyUgFZHg8xxXOuK7mmkQrq7gCPCcLYJg9m9tA1C42wblBYKZIeRsj LL4fK74MPUrK++Z0FazF08DUOW/VzT0OXhcmZA+jbYpiQg9q6I2RZDdgPMxtfjyB Sv4aN2CJT3i+cz8C4t06 =k53+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 11 09:15:51 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 C07111AC437 for ; Tue, 11 Aug 2015 09:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Y0QXmjpU_B0T for ; Tue, 11 Aug 2015 09:15:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173091AC430 for ; Tue, 11 Aug 2015 09:15:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1815C2079E; Tue, 11 Aug 2015 10:25:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EDDEE63B10; Tue, 11 Aug 2015 10:08:02 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D6A9F63AE8; Tue, 11 Aug 2015 10:08:02 -0400 (EDT) From: Michael Richardson To: Daniel Kahn Gillmor In-Reply-To: <87d1yur5h9.fsf@alice.fifthhorseman.net> References: <20150810171306.11047.24159.idtracker@ietfa.amsl.com> <55C8EBAE.4070704@cs.tcd.ie> <370F0905-3815-4DA4-B21A-B321D92E12C9@isi.edu> <87d1yur5h9.fsf@alice.fifthhorseman.net> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP 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, 11 Aug 2015 16:15:49 -0000 --=-=-= Content-Type: text/plain Daniel Kahn Gillmor wrote: >> I disagree with this change of status. > Is your disagreement on process grounds or because you disagree with > the analysis or sentiments expressed in RFC 1984? >> Documents that refer to this RFC informationally would all need to be >> considered for potential impact. > I just did a review of all RFCs that refer to RFC 1984 explicitly [0] > ------------- > The RFCs are: > * RFC 2804 ("IETF Policy on Wiretapping") It might make sense to turn this into a BCP. I agree with your analysis (in particular as the author of 4322, I agree) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVcoBwoCLcPvd0N1lAQLz6gf/YSryuP1xXb8z9WbaISDU4u201igN4a2o 88pMuyTx0SsoVbedcV+Y+16WZ/44PvcRJmoFioG7h4MFz7qySUUc6Qv+CyxLwPin PBCpFFTjNL0HYiipz1MEPIWs4PcLnYdeHh1fKrpmzG7ISTVxT/R4OmoFGjbx8msM K8wtMIE/0flfRt6ZPtyYDCHuXwNCHWOcx/OhL6i93egWwRaK7f6glJUAhWWVDG56 ODvOal3crY6cxvsE1oprAkgVEvlGvEnD/Pt6HlC1ihMZK2aFqDC7RT2xsVTHcyKW VxWpkyg9OODSnoTo3u9RI9Z/9QXQxPOGjjyKqNAK4Ci7sUA8+m4B/g== =b7zY -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 11 10:30: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 B6C7A1ACDFF for ; Tue, 11 Aug 2015 10:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0Hi-67pxMBbx for ; Tue, 11 Aug 2015 10:30:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D71C1ACD8E for ; Tue, 11 Aug 2015 10:30:46 -0700 (PDT) Received: from [128.9.184.100] ([128.9.184.100]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t7BHTvUx020188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Aug 2015 10:30:03 -0700 (PDT) To: Daniel Kahn Gillmor , Stephen Farrell References: <20150810171306.11047.24159.idtracker@ietfa.amsl.com> <55C8EBAE.4070704@cs.tcd.ie> <370F0905-3815-4DA4-B21A-B321D92E12C9@isi.edu> <87d1yur5h9.fsf@alice.fifthhorseman.net> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55CA3113.7000909@isi.edu> Date: Tue, 11 Aug 2015 10:29:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <87d1yur5h9.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP 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, 11 Aug 2015 17:30:47 -0000 On 8/10/2015 6:14 PM, Daniel Kahn Gillmor wrote: > On Mon 2015-08-10 16:34:38 -0400, Joe Touch wrote: >> I disagree with this change of status. > > Is your disagreement on process grounds or because you disagree with the > analysis or sentiments expressed in RFC 1984? Both. As a process issue: - The analogy to ASCII (RFC20) is not helpful. That is a factual document; this is an op-ed piece. - It makes sense to move existing RFCs to "Historic", but in all other cases (ASCII included) it is much more common and in keeping with the IETF process to issue a new RFC As a content issue: - we cannot issue a "last call" on a BCP unless the doc is open for edits - BCPs should make recommendations to protocol designers, users, implementers, and operators this document speaks more to governments, which is a policy role I feel ought to stay closer to the ISOC and out of the IETF/IRTF While I appreciate the kitsch of desperately clinging to the originally issued RFC number, the document further lacks the clear and technical advice to EVERYONE I expect for the topic covered. Some missing issues are noted below. IMO, a BCP on this topic should stick to the facts, avoid wandering into policy and governmental issues, and make clear recommendations to the IETF community. The current RFC fails in all these regards. Joe ---- - the fact that lazy programming is the cause of a large amount of security issues (buffer overrun) - the concept that "crypto everywhere" is as vacuously useful as "crypto nowhere" - it makes no direct key size recommendation (as a BCP should) - it makes no algorithmic diversity recommendation (as, IMO, a crypto BCP should) - it makes no statement on the computational complexity of crypto algs and their relationship to adoption and deployment (as, IMO, a crypto BCP should) - it makes a claim about certification authorities being both legitimate and necessary, when they are the antithesis of some valid and useful crypto systems - it fails to address the slipshod way in which public keys are often signed by others, e.g., using a "government issued ID" as proof (who of us would know an invalid ID if we saw one?) (i.e., "key signing parties are a hazard to public key crypto" IMO) - it makes no statement about the relationship of the keys to the data, i.e., it does not warn against bare reuse of keys (vs., e.g., using the keys with session info to derive a session key) - it does not address how salts or seeds are generated safely, and why using header fields you "don't know" isn't the same as using random info. - it fails to address ways in which actions, rather than content, expose information (e.g., the packet patterns) - it fails to address the potential benefit of out-of-band verification or salts The list goes on. ---- From nobody Wed Aug 12 04:22: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 79B8F1A8AED for ; Wed, 12 Aug 2015 04:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 WDzNsY0oKq6l for ; Wed, 12 Aug 2015 04:21:59 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 DD2A71A8AD4 for ; Wed, 12 Aug 2015 04:21:58 -0700 (PDT) Received: by lalv9 with SMTP id v9so7254582lal.0 for ; Wed, 12 Aug 2015 04:21:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=jucmOIeES3KfwY/PRMyJIE6xdJOirTMNKVwkIuAyXRU=; b=b6XQddPLqOrlAQx/ghQm8oRysL9wsJ3choPEDtI5xA49w1holPv4C2wei+mLGZESg5 kh2NZPP2GKXml8aOO4c6XAxOqFygoQPZ1lnzbmLCculE4d3qpfZUDD7D5edDmgcr8zCT S8hbOkyado7hdtYyvF88cGZX7K75FG3QZCw9n4b6tS9uBw5vlD1RyCgZDPAjg761vytg e9taoSrxorQIbh3QHwL6amDxtWksMeyv0IJo8+hyexrOeG0nxpSAAtA/6mwD3CDoO3w9 OMpi5HH4ZWrsWXJ9t/WVhrufyKGwnKIrqasLnnX76iX2YvS5ohwnPyjaUujzyy/yXWz4 15bA== X-Gm-Message-State: ALoCoQncDAnba74pCN3t7M4/wfPZAMRmMSVm+rXZtD+PuhYkBfv2EmXuGTfmwo5NxmARLRJryqlg MIME-Version: 1.0 X-Received: by 10.152.4.163 with SMTP id l3mr31891411lal.35.1439378517303; Wed, 12 Aug 2015 04:21:57 -0700 (PDT) Received: by 10.25.144.193 with HTTP; Wed, 12 Aug 2015 04:21:57 -0700 (PDT) Date: Wed, 12 Aug 2015 12:21:57 +0100 Message-ID: From: Phil Lello To: saag@ietf.org Content-Type: multipart/alternative; boundary=089e013d100c38c8ca051d1b6d2a Archived-At: Subject: [saag] SSH Protocol Extensions 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, 12 Aug 2015 11:22:00 -0000 --089e013d100c38c8ca051d1b6d2a Content-Type: text/plain; charset=UTF-8 Hi, I'm currently working on extensions to the SSH protocol; as I believe the SecSH WG is effectively dormant, is this list the best place to discuss the proposals? Briefly, I am seeking to add support for federated/asserted identities to SSH, for scenarios where the protocol is used as an application transport (e.g. git, svn). This involves the client sending a desired username for authentication, along with a authentication token from a trusted 3rd party. In the initial implementation, this would be a SAML assertion, although I intend to make the implementation generic enough to support other mechanisms. Trust relationships for valid IdPs would be handled according to local policy. A related extension will be a formal websocket binding for SSH, and I expect the reference implementation of this to be a patch to Gerrit (a git-based code review tool that contains an embedded Java SSH server). Phil Lello --089e013d100c38c8ca051d1b6d2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I'm currently wor= king on extensions to the SSH protocol; as I believe the SecSH WG is effect= ively dormant, is this list the best place to discuss the proposals?
Briefly, I am seeking to add support for federated/asserted identiti= es to SSH, for scenarios where the protocol is used as an application trans= port (e.g. git, svn). This involves the client sending a desired username f= or authentication, along with a authentication token from a trusted 3rd par= ty.

In the initial implementation, this would be a SAML assertion, a= lthough I intend to make the implementation generic enough to support other= mechanisms. Trust relationships for valid IdPs would be handled according = to local policy.

A related extension will be a formal websocke= t binding for SSH, and I expect the reference implementation of this to be = a patch to Gerrit (a git-based code review tool that contains an embedded J= ava SSH server).

Phil Lello
--089e013d100c38c8ca051d1b6d2a-- From nobody Wed Aug 12 04:25: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 751CF1A8BB2 for ; Wed, 12 Aug 2015 04:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 eWxh94fBGKOV for ; Wed, 12 Aug 2015 04:25:11 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 1C5B31A87C2 for ; Wed, 12 Aug 2015 04:25:11 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9DBA6402D7; Wed, 12 Aug 2015 13:25:09 +0200 (CEST) To: Phil Lello , saag@ietf.org References: From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <55CB2D0F.8000606@restena.lu> Date: Wed, 12 Aug 2015 13:25:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NLVCXNH3gDfGRAvNqjF3gqqESfsDRXUwb" Archived-At: Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 11:25:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NLVCXNH3gDfGRAvNqjF3gqqESfsDRXUwb Content-Type: multipart/mixed; boundary="------------080801050006080404040008" This is a multi-part message in MIME format. --------------080801050006080404040008 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > Briefly, I am seeking to add support for federated/asserted identities > to SSH, for scenarios where the protocol is used as an application > transport (e.g. git, svn). This involves the client sending a desired > username for authentication, along with a authentication token from a > trusted 3rd party. >=20 > In the initial implementation, this would be a SAML assertion The above is pretty much exactly what the ABFAB working group has been working on for the last couple of years. Federated SSH access is their number one real-life case AFAICT. Did you review their specs yet? Greetings, Stefan Winter , although > I intend to make the implementation generic enough to support other > mechanisms. Trust relationships for valid IdPs would be handled > according to local policy. >=20 > A related extension will be a formal websocket binding for SSH, and I > expect the reference implementation of this to be a patch to Gerrit (a > git-based code review tool that contains an embedded Java SSH server). >=20 > Phil Lello >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------080801050006080404040008 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------080801050006080404040008-- --NLVCXNH3gDfGRAvNqjF3gqqESfsDRXUwb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVyy0UAAoJEMDeajWKOdxmjPIP+gNzqOZVY89rLgAcjKFEkvyL VpgKBi7ovpOsTw1c6qW2ZClVYuTqkKFTOuSZ9PPhtzLBMNurnq3Mn/c/Yzs/xd/g FJRm9czwYlDlY+X2e+ScEF/Ens6AdkvRsuL3GXUlzSwTiYqpwb38VZj+mfZrIJrx O1xIXlC8aAqqj+AqTPa4Qi5O5CLjTnNHfATSgxT5ydA177mHnLKnHxAkq8kAyPum bw+uSYtgHPdOJBr7h2lh+nE0hLKz6hAB0TQw400K7z9GKdenwenzS4TthrCNeHlm weJ9zjn1z8pDM8JEecFbNI+DDGLXoCeK0kAg/3L3vKlGILZm7CHZacJrwmmnImfV SuYWc96YonByjp596HGIqlZl7ZwxM3Wzp7536J9bCDeRNTb+2pLC4cbu0kegHLq0 UnMSy8tXeAb1aSAommtB8XCJe1LQVky3QvDEL/idCy4La/KuU4GhiUz32x6V4R4I 5vMBq5g5fcQWrCr/vEBBHaxWEHCfyLBzeVfo9XbQvZWzEGZGPG2XnhwA1n+K3r48 yLJEaOHgxWhwM/kZSW0y6EtVAczIkWZaqnJSWRyu12jazJaQkF3AZBRpA6GtDcb0 UUrfrDBlD5saXo/R/+M/ucCuUM/Tc+wFvZ1nETNpW7Wjkh0BWqFl4qYDUAKTBUoS yhcBZ3E0fheflMMJlua3 =ZpWX -----END PGP SIGNATURE----- --NLVCXNH3gDfGRAvNqjF3gqqESfsDRXUwb-- From nobody Wed Aug 12 04:30: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 994801A8EA9 for ; Wed, 12 Aug 2015 04:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, WEIRD_PORT=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 kV-68Xwa1yh6 for ; Wed, 12 Aug 2015 04:30:22 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 9E13D1A8AF9 for ; Wed, 12 Aug 2015 04:30:21 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so7616269lbc.2 for ; Wed, 12 Aug 2015 04:30:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QgjhNFbeBXxkk7sFKBCuUuTLAzDpbq8204Ono5A3CXQ=; b=TL2UasAObVZUYiTT1NH0yqv12mBcKKMYrf7QlVLwRzs9uvYnyvpsfoFsBsEzgdlAPx lR49Qouui/Oy3ZNYOCH2Ax3vtQjeay9NW145SGdKcWkQqQ3DcH/8ggN2hA9NzjEdPp8F yJtiWjsQfiR0+gwN8IrWjj2NSwpvOyqcAZnkb/RXte5pCj8P69N9aDD9uKlQZwkEUXZM 9IgIWiBwOjkyCPxo5C1Ax9cSlO2x90f786bHQCL79esaDNJUq4bW1A5PpyUc45fDreIz JpRIBsUJ4qT0nlDBS0c+q0GnExSCeEY4IrY5HvDGvV6J/x6zGgtVvh9+lRoXm0/j919m OBkQ== X-Gm-Message-State: ALoCoQlGsw1AigK3xwRtJAAYkoRmCflv1uUIRIP/VUfJV9jdZbMQfhjjcPYaK01ObIgBYaUwEz3u MIME-Version: 1.0 X-Received: by 10.152.20.4 with SMTP id j4mr8932587lae.7.1439379020063; Wed, 12 Aug 2015 04:30:20 -0700 (PDT) Received: by 10.25.144.193 with HTTP; Wed, 12 Aug 2015 04:30:20 -0700 (PDT) In-Reply-To: <55CB2D0F.8000606@restena.lu> References: <55CB2D0F.8000606@restena.lu> Date: Wed, 12 Aug 2015 12:30:20 +0100 Message-ID: From: Phil Lello To: Stefan Winter Content-Type: multipart/alternative; boundary=089e01493308304779051d1b8b63 Archived-At: Cc: saag@ietf.org Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 11:30:23 -0000 --089e01493308304779051d1b8b63 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Many thanks Stefan, I wasn't aware of the ABFAB WG, I will review their specs. Phil On Wed, Aug 12, 2015 at 12:25 PM, Stefan Winter wrote: > Hi, > > > Briefly, I am seeking to add support for federated/asserted identities > > to SSH, for scenarios where the protocol is used as an application > > transport (e.g. git, svn). This involves the client sending a desired > > username for authentication, along with a authentication token from a > > trusted 3rd party. > > > > In the initial implementation, this would be a SAML assertion > > The above is pretty much exactly what the ABFAB working group has been > working on for the last couple of years. Federated SSH access is their > number one real-life case AFAICT. > > Did you review their specs yet? > > Greetings, > > Stefan Winter > > , although > > I intend to make the implementation generic enough to support other > > mechanisms. Trust relationships for valid IdPs would be handled > > according to local policy. > > > > A related extension will be a formal websocket binding for SSH, and I > > expect the reference implementation of this to be a patch to Gerrit (a > > git-based code review tool that contains an embedded Java SSH server). > > > > Phil Lello > > > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > recipient's key is known to me > > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 > --089e01493308304779051d1b8b63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Many thanks Stefan, I wasn't aware of the ABFAB W= G, I will review their specs.

Phil

On Wed, Aug 12, 2015 at 12:25 PM, S= tefan Winter <stefan.winter@restena.lu> wrote:
Hi,

> Briefly, I am seeking to add support for federated/asserted identities=
> to SSH, for scenarios where the protocol is used as an application
> transport (e.g. git, svn). This involves the client sending a desired<= br> > username for authentication, along with a authentication token from a<= br> > trusted 3rd party.
>
> In the initial implementation, this would be a SAML assertion

The above is pretty much exactly what the ABFAB working group has be= en
working on for the last couple of years. Federated SSH access is their
number one real-life case AFAICT.

Did you review their specs yet?

Greetings,

Stefan Winter

, although
> I intend to make the implementation generic enough to support other > mechanisms. Trust relationships for valid IdPs would be handled
> according to local policy.
>
> A related extension will be a formal websocket binding for SSH, and I<= br> > expect the reference implementation of this to be a patch to Gerrit (a=
> git-based code review tool that contains an embedded Java SSH server).=
>
> Phil Lello
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>


--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Educati= on Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 = 1
Fax: +352 422473
PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371= /pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66

--089e01493308304779051d1b8b63-- From nobody Wed Aug 12 07:57: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 0AFC01A8A0B for ; Wed, 12 Aug 2015 07:57:19 -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 ZiGY9w1kl5Zc for ; Wed, 12 Aug 2015 07:57:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FFD81A8A06 for ; Wed, 12 Aug 2015 07:57:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 09ADF2009E; Wed, 12 Aug 2015 11:15:14 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5A54B63B10; Wed, 12 Aug 2015 10:57:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3E68163AE8; Wed, 12 Aug 2015 10:57:16 -0400 (EDT) From: Michael Richardson To: Phil Lello In-Reply-To: References: <55CB2D0F.8000606@restena.lu> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: saag@ietf.org Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 14:57:19 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Phil Lello wrote: > Many thanks Stefan, I wasn't aware of the ABFAB WG, I will review the= ir > specs. Is ABFAB actually writing SSH extensions? My (three-minute review) impression they are writing GSSAPI extensions, and SSH can use GSSAPI. If they don't suit, where would Phil go? I think it would have to be an Independant Stream or AD sponsored, but I'm sure that using saag to review would be great. It would be very nice to be able to get a list of names of the server that are "also" names... and it would be nice to be able to get a 302-type redirect... =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVctey4CLcPvd0N1lAQKqawf/dvQbsTYeQGGLtUaw6iSTN/JeuXYnmefo 5bfeU7go3EnTgZ+QkhY6Nu+JON1obD1ZY9Rf37UU1W9/vraxNf4pY1UCQBvmLd0j eUewpcWhiXPUo8yYPPjJPq7btj22nXNCznkItiHgUSpCacGAlp02K8aqmUzehqrx tjNr+CW1xVUOuDhRkDnjhGjkj/c3LLO8drLVeXPGYKkJj3qPGsdL7dOTRy+ckH/Q BMCP6pEh4mg5y1j9uIaFBMP0D5z5NUttX5wL4Wk0Oy6uyerZ+nggBTNPQdzEWNS3 3ERa5Rz2UzqFy2kCXDYgELoyGV2jgpdEoNjJDCZFxWQ9l8dw+QoTvg== =m7Tk -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 12 08:50: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 A14F01A0045 for ; Wed, 12 Aug 2015 08:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSCYEDsTpsBK for ; Wed, 12 Aug 2015 08:50:19 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D226C1A0087 for ; Wed, 12 Aug 2015 08:50:19 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 8A5B320047B85; Wed, 12 Aug 2015 08:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=y9QP+rIhi3Fvql rUZ4ljvfWKv94=; b=jHOdRaVPqFpIDesg3T4XESTXaC5sAJTxpTcKaFag3spbDE qXuCG8ZZq3KOfdY4EJnwofakBIvaBGQHWMvybdQEhHL8uUHuzq0jgyWl5pH8Hi2H /iHS6p4IsXV1pKNCFozSQ6qpjUik9Zp8zUANGihtK3ngVGM7oZF9w2neQZpmA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id 826AE20047B86; Wed, 12 Aug 2015 08:50:18 -0700 (PDT) Date: Wed, 12 Aug 2015 10:50:17 -0500 From: Nico Williams To: Michael Richardson Message-ID: <20150812155016.GA24354@localhost> References: <55CB2D0F.8000606@restena.lu> <12386.1439391436@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12386.1439391436@sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 15:50:23 -0000 On Wed, Aug 12, 2015 at 10:57:16AM -0400, Michael Richardson wrote: > > Phil Lello wrote: > > Many thanks Stefan, I wasn't aware of the ABFAB WG, I will review their > > specs. > > Is ABFAB actually writing SSH extensions? No, they aren't. > My (three-minute review) impression they are writing GSSAPI extensions, and > SSH can use GSSAPI. Yes, that's it. > If they don't suit, where would Phil go? In principle the old SECSH WG mailing list is to be used for discussing SSHv2 extensions. We might want to create an @ietf.org list though, though if the volume is low enough SAAG works for me. As for SSHv2 and federation, I'd like to understand what functionality is needed that using GSS/ABFAB can't provide. > I think it would have to be an Independant Stream or AD sponsored, but I'm > sure that using saag to review would be great. Yes. > It would be very nice to be able to get a list of names of the server > that are "also" names... and it would be nice to be able to get a 302-type > redirect... Hmm? You mean ask an SSHv2 server to list its aliases? And to give you temporary redirects? Nico -- From nobody Wed Aug 12 09:04:16 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 D41D11A21C3; Wed, 12 Aug 2015 09:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVoh3OP5Ezqb; Wed, 12 Aug 2015 09:04:12 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E83D1A1A67; Wed, 12 Aug 2015 09:04:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8AF6D20798; Wed, 12 Aug 2015 12:02:54 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDJxhxPNc_VK; Wed, 12 Aug 2015 12:02:53 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 12 Aug 2015 12:02:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8943481BA5; Wed, 12 Aug 2015 12:04:10 -0400 (EDT) From: Sam Hartman To: Phil Lello References: Date: Wed, 12 Aug 2015 12:04:10 -0400 In-Reply-To: (Phil Lello's message of "Wed, 12 Aug 2015 12:21:57 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: kitten@ietf.org, saag@ietf.org, draft-ietf-kitten-sasl-saml-ec@tools.ietf.org Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 16:04:14 -0000 I think that RFC 4462 plus the SAML ECP mechanism (draft-ietf-kitten-sasl-saml-ec) can do what you're talking about and is probably a fairly good secure way of using a SAML assertion to authenticate to SSH. >>>>> "Phil" == Phil Lello writes: Phil> Hi, I'm currently working on extensions to the SSH Phil> protocol; as I believe the SecSH WG is effectively dormant, is Phil> this list the best place to discuss the proposals? Briefly, I Phil> am seeking to add support for federated/asserted identities to Phil> SSH, for scenarios where the protocol is used as an Phil> application transport (e.g. git, svn). This involves the Phil> client sending a desired username for authentication, along Phil> with a authentication token from a trusted 3rd party. In the Phil> initial implementation, this would be a SAML assertion, Phil> although I intend to make the implementation generic enough to Phil> support other mechanisms. Trust relationships for valid IdPs Phil> would be handled according to local policy. A related Phil> extension will be a formal websocket binding for SSH, and I Phil> expect the reference implementation of this to be a patch to Phil> Gerrit (a git-based code review tool that contains an embedded Phil> Java SSH server). Phil Lello Phil> _______________________________________________ saag mailing Phil> list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Wed Aug 12 09:13: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 BF2021A8A9E for ; Wed, 12 Aug 2015 09:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 TIcDJXY5mmQZ for ; Wed, 12 Aug 2015 09:13:05 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7341A8AB6 for ; Wed, 12 Aug 2015 09:13:04 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so12447152lbb.1 for ; Wed, 12 Aug 2015 09:13:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hDFwqQ28DSQiOc16GqFwy3WB/U8erN59ho1LI1B+pBc=; b=PXVm0ZUdBUU2vThl+7SptR//Nrxq6Pn2xToas81mJlqHLQSRLcuCg87tuQrlokCtt5 EbrEM1NjLSiT4chkBiWRB8Fjgan09nExV/RFDfGRSXlZET0LqeTLqVQQbUOGXGgu2bGk LsFATee1eerFu3/UUV/OuuFBYJuSROciQugZTwqtoSR0jOvUFVopwoPGDso3IumFbnrv JtmGaZsd+5901BMk3T1t+eZ8cUcRDtsJSjoJGaSZeQUDLc047rxQ/FBnyKrbUHi/x/i/ izVyM0HtA0eZoc0Byc+pUaV70vuF1aoPSwps5nIfhp6CXAH+SD0IFseGymaP91utXzNk 2z+A== X-Gm-Message-State: ALoCoQk7wrldKAgOasoAsyCmB/5vxxju6Dyk+7aRAcyKwIAR3ipbIR+fFduDkuuF87UR7hMtPPI5 MIME-Version: 1.0 X-Received: by 10.112.164.4 with SMTP id ym4mr33343475lbb.7.1439395983081; Wed, 12 Aug 2015 09:13:03 -0700 (PDT) Received: by 10.25.144.193 with HTTP; Wed, 12 Aug 2015 09:13:02 -0700 (PDT) In-Reply-To: <20150812155016.GA24354@localhost> References: <55CB2D0F.8000606@restena.lu> <12386.1439391436@sandelman.ca> <20150812155016.GA24354@localhost> Date: Wed, 12 Aug 2015 17:13:02 +0100 Message-ID: From: Phil Lello To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c25cea43657f051d1f7e2b Archived-At: Cc: Michael Richardson , saag@ietf.org Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 16:13:06 -0000 --001a11c25cea43657f051d1f7e2b Content-Type: text/plain; charset=UTF-8 On Wed, Aug 12, 2015 at 4:50 PM, Nico Williams wrote: > On Wed, Aug 12, 2015 at 10:57:16AM -0400, Michael Richardson wrote: > > > > Phil Lello wrote: > > > Many thanks Stefan, I wasn't aware of the ABFAB WG, I will review > their > > > specs. > > > > Is ABFAB actually writing SSH extensions? > > No, they aren't. > > > My (three-minute review) impression they are writing GSSAPI extensions, > and > > SSH can use GSSAPI. > > Yes, that's it. > > > If they don't suit, where would Phil go? > > In principle the old SECSH WG mailing list is to be used for discussing > SSHv2 extensions. We might want to create an @ietf.org list though, > though if the volume is low enough SAAG works for me. > As for SSHv2 and federation, I'd like to understand what functionality > is needed that using GSS/ABFAB can't provide. > I'm still getting up to speed on GSS/ABFAB, so reserve the right to reverse my position, however it seems to me that GSS/ABFAB is reasonably complex to implement, compared to defining a new authentication method. Whilst GSS/ABFAB seems well suited to large enterprise environments, I'm not convinced it is suitable for allowing federated identities to be used with light-weight stand-alone ssh servers. Admittedly, I'm currently put off by what appears to be a steep learning curve once GSS, RADIUS, et al. come into the mix, but with my 'lazy coder' hat on, it doesn't seem unreasonable that other potential implementers will feel the same. > I think it would have to be an Independant Stream or AD sponsored, but I'm > > sure that using saag to review would be great. > > Yes. > > > It would be very nice to be able to get a list of names of the server > > that are "also" names... and it would be nice to be able to get a > 302-type > > redirect... > > Hmm? You mean ask an SSHv2 server to list its aliases? And to give you > temporary redirects? > > I'm not sure I understand the reason for this, but wouldn't reverse DNS on the target hostname achieve this? > Nico > -- > Phil --001a11c25cea43657f051d1f7e2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 12, 2015 at 4:50 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Wed, Aug 12, 2015 at 10:57:16AM -0400, Michael Richardson wrote:
>
> Phil Lello <phil@dunlop-lel= lo.uk> wrote:
>=C2=A0 =C2=A0 =C2=A0> Many thanks Stefan, I wasn't aware of the = ABFAB WG, I will review their
>=C2=A0 =C2=A0 =C2=A0> specs.
>
> Is ABFAB actually writing SSH extensions?

No, they aren't.

> My (three-minute review) impression they are writing GSSAPI extensions= , and
> SSH can use GSSAPI.

Yes, that's it.

> If they don't suit, where would Phil go?

In principle the old SECSH WG mailing list is to be used for discuss= ing
SSHv2 extensions.=C2=A0 We might want to create an @ietf.org list though,
though if the volume is low enough SAAG works for me.
=C2=A0
As for SSHv2 and federation, I'd like to understand what functionality<= br> is needed that using GSS/ABFAB can't provide.
=C2= =A0
I'm still getting up to speed on GSS/ABFAB, so reserve th= e right to reverse my position, however it seems to me that GSS/ABFAB is re= asonably complex to implement, compared to defining a new authentication me= thod. Whilst GSS/ABFAB seems well suited to large enterprise environments, = I'm not convinced it is suitable for allowing federated identities to b= e used with light-weight stand-alone ssh servers. Admittedly, I'm curre= ntly put off by what appears to be a steep learning curve once GSS, RADIUS,= et al. come into the mix, but with my 'lazy coder' hat on, it does= n't seem unreasonable that other potential implementers will feel the s= ame.

> I think it would have to be an Independant Stream or AD sponsored, but= I'm
> sure that using saag to review would be great.

Yes.

> It would be very nice to be able to get a list of names of the server<= br> > that are "also" names... and it would be nice to be able to = get a 302-type
> redirect...

Hmm?=C2=A0 You mean ask an SSHv2 server to list its aliases?=C2=A0 A= nd to give you
temporary redirects?

I'm not sure I understand the reason for this, but wouldn't= reverse DNS on the target hostname achieve this?
=C2=A0
Nico
--

Phil<= br>
--001a11c25cea43657f051d1f7e2b-- From nobody Wed Aug 12 09:22: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 8DC361A8ADB for ; Wed, 12 Aug 2015 09:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjqgptNKhD_5 for ; Wed, 12 Aug 2015 09:22:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558721A8A9D for ; Wed, 12 Aug 2015 09:22:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6C423284B55; Wed, 12 Aug 2015 16:22:14 +0000 (UTC) Date: Wed, 12 Aug 2015 16:22:14 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150812162214.GS9139@mournblade.imrryr.org> References: <55CB2D0F.8000606@restena.lu> <12386.1439391436@sandelman.ca> <20150812155016.GA24354@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] SSH Protocol Extensions X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 16:22:16 -0000 On Wed, Aug 12, 2015 at 05:13:02PM +0100, Phil Lello wrote: > Admittedly, I'm currently put off by > what appears to be a steep learning curve once GSS, RADIUS, et al. come > into the mix, but with my 'lazy coder' hat on, it doesn't seem unreasonable > that other potential implementers will feel the same. Is this confusing implementation with deployment? Once the platform's GSSAPI library supports ABFAB, it becomes a question of deployment, not implementation. -- Viktor. From nobody Wed Aug 12 09:43: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 268991A89FA for ; Wed, 12 Aug 2015 09:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiiQuJ7qF5rR for ; Wed, 12 Aug 2015 09:43:53 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E71021A8765 for ; Wed, 12 Aug 2015 09:43:52 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 3C00F26C090; Wed, 12 Aug 2015 09:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=h//nwoLUrTy71s cX09KEOWRpAos=; b=YUVFENec/6eOtnhjO5BK8DbT7PXL6HMHMqevaA0qWbLmA6 jLVsl3RfqOf+rrjWJEEn9M4CiRO1ICvWbrWsBIomSCmg29nMjkQB1FkxFj67pJjJ 5Q4OCZ0DAAhIF31WCXAPTcJNvFuMAbGu1/gM0Id9s7xDSdK5fFAM+8lWlU1dk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPA id 806EA26C095; Wed, 12 Aug 2015 09:43:45 -0700 (PDT) Date: Wed, 12 Aug 2015 11:43:43 -0500 From: Nico Williams To: Phil Lello Message-ID: <20150812164339.GC3654@localhost> References: <55CB2D0F.8000606@restena.lu> <12386.1439391436@sandelman.ca> <20150812155016.GA24354@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Michael Richardson , saag@ietf.org Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 16:43:54 -0000 On Wed, Aug 12, 2015 at 05:13:02PM +0100, Phil Lello wrote: > On Wed, Aug 12, 2015 at 4:50 PM, Nico Williams > wrote: > > As for SSHv2 and federation, I'd like to understand what functionality > > is needed that using GSS/ABFAB can't provide. > > > > I'm still getting up to speed on GSS/ABFAB, so reserve the right to reverse > my position, however it seems to me that GSS/ABFAB is reasonably complex to > implement, compared to defining a new authentication method. Whilst > GSS/ABFAB seems well suited to large enterprise environments, I'm not > convinced it is suitable for allowing federated identities to be used with > light-weight stand-alone ssh servers. Admittedly, I'm currently put off by > what appears to be a steep learning curve once GSS, RADIUS, et al. come > into the mix, but with my 'lazy coder' hat on, it doesn't seem unreasonable > that other potential implementers will feel the same. If you ignore all of the details of the GSS-API for the moment and focus just on the protocol, there's nothing complex. It's a synchronous exchange of opaque messages ("security context tokens") for some mechanism. You get to define these messages (unless ABFAB fits the bill, then you can use ABFAB's). You don't have to implement RFC2744 nor do you have to use existing implementations. There's only one set of bits-on-the-wire added by GSS, and that's on the first security context token. There are details of how to generate the mechanism name, but you don't have to write code to do that. You do it once, confirm that others get the same result, and write down the results in your code. There's also a "MIC token" to bind the authentication to the SSHv2 key exchange. That's it. No need for GSS functions. No need for a pluggable GSS library. "defining a new authentication method" seems unnecessary when there already is one that can do what you want. The complete specs are complex, of course, but that's only because they deal with things that you don't have to. Nico -- From nobody Wed Aug 12 09:45: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 C97CA1A8F4D for ; Wed, 12 Aug 2015 09:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX-uUW4fw1Fm for ; Wed, 12 Aug 2015 09:45:41 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DAC671A8F45 for ; Wed, 12 Aug 2015 09:45:41 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 8CB8254085; Wed, 12 Aug 2015 09:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=69cmrWJBDjyY0E MKqcsx/1cNyDE=; b=JADtve4ZxfuG9pCkSxbAaT3e0/uMIQ9R8PVDbtj0UxVwud zuSpU5ByFIYDsUve6uciawpz0x2faLt51xf+Bl8Fs7DpcCCivXx3mCgNApUYt5j+ 1AwdjvgUIZC2O/WJE3orUn3j7UyGSBuMgAocxz9nmviE/jg5wN1SWZIu7M1Q8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id 174F35409F; Wed, 12 Aug 2015 09:45:40 -0700 (PDT) Date: Wed, 12 Aug 2015 11:45:40 -0500 From: Nico Williams To: Phil Lello Message-ID: <20150812164536.GD3654@localhost> References: <55CB2D0F.8000606@restena.lu> <12386.1439391436@sandelman.ca> <20150812155016.GA24354@localhost> <20150812164339.GC3654@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150812164339.GC3654@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Michael Richardson , saag@ietf.org Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 16:45:42 -0000 I should add that we have a great example of how the complexity of the GSS-API is really just about the API, and how it can be sidestepped: RFC5802. RFC5802 specifies a mechanism for GSS and SASL that can be implemented without reference to GSS. Nico -- From nobody Wed Aug 12 09:50: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 00BE21A9031 for ; Wed, 12 Aug 2015 09:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN5fxlHX2HCo for ; Wed, 12 Aug 2015 09:50:16 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 61B141A8F4D for ; Wed, 12 Aug 2015 09:50:16 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id C07D7200D30C2; Wed, 12 Aug 2015 09:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=PYPsnHRbAtwxccM/DnU+RCrVda8 =; b=vE+0ltLQIza66Ip0Gr3H2dHCO/ftBAch0g3GXq2Je4G2/3cridSeEM/YNoA Au5C485/eNw5tiqbj0uEwSNiGlP1B3gluIrg7WZ2BLsPC0ibLP3RAQgmVL+FAciV r6z8cndsuuxkqFI+dhy3zqrh2CszVkCfzVj3mbRVqtV/vI1c= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPA id C947D200D30C0; Wed, 12 Aug 2015 09:50:14 -0700 (PDT) Date: Wed, 12 Aug 2015 11:50:11 -0500 From: Nico Williams To: saag@ietf.org Message-ID: <20150812165007.GE3654@localhost> References: <55CB2D0F.8000606@restena.lu> <12386.1439391436@sandelman.ca> <20150812155016.GA24354@localhost> <20150812162214.GS9139@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150812162214.GS9139@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 16:50:21 -0000 On Wed, Aug 12, 2015 at 04:22:14PM +0000, Viktor Dukhovni wrote: > On Wed, Aug 12, 2015 at 05:13:02PM +0100, Phil Lello wrote: > > > Admittedly, I'm currently put off by > > what appears to be a steep learning curve once GSS, RADIUS, et al. come > > into the mix, but with my 'lazy coder' hat on, it doesn't seem unreasonable > > that other potential implementers will feel the same. > > Is this confusing implementation with deployment? I don't see a mention of deployment. I suspect that Phil wants to implement from scratch, not use an off-the-shelf implementation. > Once the platform's GSSAPI library supports ABFAB, it becomes a > question of deployment, not implementation. I should note that one should be able to implement and deploy an SSH client and server that use a system GSS library for some GSS mechanisms, and a non-system GSS mechanism used directly without reference to any GSS libraries. Some SASL and SMB implementations do this sort of thing. Nico -- From nobody Wed Aug 12 10:37:05 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 305BC1A92DC for ; Wed, 12 Aug 2015 10:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6b_jjSyv62J for ; Wed, 12 Aug 2015 10:37:02 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1120E1A9177 for ; Wed, 12 Aug 2015 10:37:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 247FC20796 for ; Wed, 12 Aug 2015 13:35:44 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmqsV1Je4_ZV for ; Wed, 12 Aug 2015 13:35:42 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Wed, 12 Aug 2015 13:35:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7F5DC81B5F; Wed, 12 Aug 2015 13:36:58 -0400 (EDT) From: Sam Hartman To: saag@ietf.org References: <55CB2D0F.8000606@restena.lu> <12386.1439391436@sandelman.ca> <20150812155016.GA24354@localhost> <20150812162214.GS9139@mournblade.imrryr.org> Date: Wed, 12 Aug 2015 13:36:58 -0400 In-Reply-To: <20150812162214.GS9139@mournblade.imrryr.org> (Viktor Dukhovni's message of "Wed, 12 Aug 2015 16:22:14 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 17:37:03 -0000 >>>>> "Viktor" == Viktor Dukhovni writes: Viktor> On Wed, Aug 12, 2015 at 05:13:02PM +0100, Phil Lello wrote: >> Admittedly, I'm currently put off by what appears to be a steep >> learning curve once GSS, RADIUS, et al. come into the mix, but >> with my 'lazy coder' hat on, it doesn't seem unreasonable that >> other potential implementers will feel the same. Viktor> Is this confusing implementation with deployment? Viktor> Once the platform's GSSAPI library supports ABFAB, it Viktor> becomes a question of deployment, not implementation. Viktor> -- Viktor. to be clear, ABFAB is kind of heavy-weight if you really want to use a SAML assertion to authenticate for ssh. It does support doing that at a theoretical level, and we do actually have running code with people using SAML assertions to carry attribute statements for ssh in ABFAB. However, the SAML EC folks have running code for using SAML assertions for ssh authentication and that removes a couple of layers from the system, so I think it's a better fit for what I understand of this use case. From nobody Wed Aug 12 10:54: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 A22A71ABD3A; Wed, 12 Aug 2015 10:54:57 -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 apimQqncOrX6; Wed, 12 Aug 2015 10:54:54 -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 426A91ABD38; Wed, 12 Aug 2015 10:54:54 -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 t7CHsdt4030467 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 12 Aug 2015 19:54:40 +0200 Date: Wed, 12 Aug 2015 19:54:37 +0200 From: Simon Josefsson To: Sam Hartman Message-ID: <20150812195437.2e03c0c8@latte.josefsson.org> In-Reply-To: References: 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_/1XeZTu2_X=gY31QPyqKsrNv"; 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, saag@ietf.org, draft-ietf-kitten-sasl-saml-ec@tools.ietf.org Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 17:54:57 -0000 --Sig_/1XeZTu2_X=gY31QPyqKsrNv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Or look into already published RFC 6616 for OpenID in SASL or RFC 6595 on SAML in SASL. SAML-EC avoids the web loop, and may indeed be more relevant depending on use-case. I believe the problem with these mechanisms has been: 1) They are stateless -- if you need to open many connections, or open them often, you need one OpenID/SAML authentication per connection which results in poor user experience. 2) They are tied to a particular federation system. Sometimes this is not a problem, but I imagine sometimes the client/server does not know what system is the most appriate to use until a web loop has been invoked. The OAuth SASL mechanism (long delayed, still being worked on) may also be relevant to look into, but it does not support GSS-API so SSH support is not a given. I believe there is room for improvement in this area, so Phil, please let us know about your progress. If you send me an email I may assist offlist with some advice too. /Simon > I think that RFC 4462 plus the SAML ECP mechanism > (draft-ietf-kitten-sasl-saml-ec) can do what you're talking about and > is probably a fairly good secure way of using a SAML assertion to > authenticate to SSH. > >>>>> "Phil" =3D=3D Phil Lello writes: >=20 > Phil> Hi, I'm currently working on extensions to the SSH > Phil> protocol; as I believe the SecSH WG is effectively dormant, > Phil> is this list the best place to discuss the proposals? > Phil> Briefly, I am seeking to add support for federated/asserted > Phil> identities to SSH, for scenarios where the protocol is used > Phil> as an application transport (e.g. git, svn). This involves > Phil> the client sending a desired username for authentication, > Phil> along with a authentication token from a trusted 3rd > Phil> party. In the initial implementation, this would be a SAML > Phil> assertion, although I intend to make the implementation > Phil> generic enough to support other mechanisms. Trust > Phil> relationships for valid IdPs would be handled according to > Phil> local policy. A related extension will be a formal > Phil> websocket binding for SSH, and I expect the reference > Phil> implementation of this to be a patch to Gerrit (a git-based > Phil> code review tool that contains an embedded Java SSH > Phil> server). Phil Lello > Phil> _______________________________________________ saag > Phil> mailing list saag@ietf.org > Phil> https://www.ietf.org/mailman/listinfo/saag --Sig_/1XeZTu2_X=gY31QPyqKsrNv Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVy4hdAAoJEIYLf7sy+BGd6GIH/iVrthe2ag3LzZ1SSiC3alql h+Z2p5HNQKFNJmxmvtcpjEuT6H5R+6LQThr3bAaPM099Gl3kk/fNiiSGqAjJWkt6 zd1M1zz88GnQQd0A9EDEXvrR2imNsi83/rNIF4QZPNokyq/kFMc5gWsmGy53B/UQ yF7CoY/MdObJk+wEGaNGNxX9iFBJuDGy0GMnyvbIQfzmbZ1PQWxNNeE9uEc9aDTo 6jMjIQ+I3typlMfLjzN+C9gdu86MbYf4w0kCo8UIzgKXu54U7uJ57e2Zfo21n8/i S2pReepYuphNN3u8t7LICw55e/gxel3eG+77kUGlpprxLwtiqsfdp9kIaTVlgkk= =nNob -----END PGP SIGNATURE----- --Sig_/1XeZTu2_X=gY31QPyqKsrNv-- From nobody Wed Aug 12 11:37: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 15FED1A8F35; Wed, 12 Aug 2015 11:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0dCDOq66Zfm; Wed, 12 Aug 2015 11:37:03 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1828C1A8AB1; Wed, 12 Aug 2015 11:37:03 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id C3CC22005693E; Wed, 12 Aug 2015 11:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nf4QvohK5VYur1 CVhFGnYhfoPdM=; b=LaZozSNWam4HyfXAv/a9iV1gSVLi/EXnBbx3TUazdOEst3 /TqhHtceeV4AZTR2eCwC3QgGOVHdThly8FL3k52KqXppn5255s+mT4R60+ZGlMER 8EM6XXk6vpegCoxi6xB4p3O7MggIbQuWiKYKxh/Dkp5mfAFua5E+douwyZ06E= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 25E7720058D13; Wed, 12 Aug 2015 11:37:02 -0700 (PDT) Date: Wed, 12 Aug 2015 13:37:01 -0500 From: Nico Williams To: Simon Josefsson Message-ID: <20150812183657.GG3654@localhost> References: <20150812195437.2e03c0c8@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150812195437.2e03c0c8@latte.josefsson.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org, Sam Hartman , saag@ietf.org, draft-ietf-kitten-sasl-saml-ec@tools.ietf.org Subject: Re: [saag] SSH Protocol Extensions 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, 12 Aug 2015 18:37:04 -0000 On Wed, Aug 12, 2015 at 07:54:37PM +0200, Simon Josefsson wrote: > Or look into already published RFC 6616 for OpenID in SASL or RFC 6595 > on SAML in SASL. SAML-EC avoids the web loop, and may indeed be more > relevant depending on use-case. If Phil needs a SAML, one-message authentiation method with no proof of possession, then a new SSHv2 userauth method is probably best (since the GSS userauth method uses MIC tokens for channel binding). Would the SAML token be possible to bind to an SSHv2 session? I would hope so. > I believe the problem with these mechanisms has been: > > 1) They are stateless -- if you need to open many connections, or open > them often, you need one OpenID/SAML authentication per connection which > results in poor user experience. Probably not an issue for SSHv2. > 2) They are tied to a particular federation system. Sometimes this is > not a problem, but I imagine sometimes the client/server does not know > what system is the most appriate to use until a web loop has been > invoked. > > The OAuth SASL mechanism (long delayed, still being worked on) may also > be relevant to look into, but it does not support GSS-API so SSH support > is not a given. See above comment about MIC tokens and channel binding. Also, without a server-side proof of possession the channel binding can only protect against token reuse, and the user will still depend on the use of server host public keys for server authentication (which may not be a problem). Nico -- From nobody Wed Aug 12 15:39:43 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 813B21A8798 for ; Wed, 12 Aug 2015 15:39:42 -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 TkfJibT3qu0F for ; Wed, 12 Aug 2015 15:39:37 -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 7A1DB1ACEDF for ; Wed, 12 Aug 2015 15:39:37 -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 t7CMdJgh002760 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 13 Aug 2015 00:39:20 +0200 From: Simon Josefsson To: Stephen Farrell References: <559153E0.5050102@cs.tcd.ie> <55C932F6.7080203@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150812:saag@ietf.org::8Aa8Ny4CS+RFwjNu:Bian X-Hashcash: 1:22:150812:stephen.farrell@cs.tcd.ie::BAWe745aS4Eq2TR8:8HGm Date: Thu, 13 Aug 2015 00:39:18 +0200 In-Reply-To: <55C932F6.7080203@cs.tcd.ie> (Stephen Farrell's message of "Tue, 11 Aug 2015 00:25:42 +0100") Message-ID: <87y4hg9lnt.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 12 Aug 2015 22:39:42 -0000 --=-=-= Content-Type: text/plain Stephen Farrell writes: > With apologies to the author/shepherd, I forgot about this one;-( > > I'm going to start IETF last call now. My own comments below can > be handled with any other last call comments. Thank you! The changes mentioned below are in this commit: https://gitlab.com/jas/ietf-scrypt/commit/6f4f3335552528994ae326a4641b179d10a31e83#diff-1 > - intro: Maybe take a look at the intro to RFC7539. I think > it does a good job of presenting the background (for a > similar DJB production:-) so it might be worth seeing if > there's anything you want to copy from that. I have added some text inspired by this. > - intro, para 1: some more references (or one ref to a > survey paper) would be good I suppose you mean references for the following? DES-based UNIX Crypt-function, FreeBSD MD5 crypt, GNU SHA-256/512 crypt Windows NT LAN Manager (NTLM) hash Blowfish-based bcrypt I can try to find some references. Help appreciated on what a good reference for these would be, the FreeBSD/GNU/NTLM are proprietary and may lack a good specification. I did not make any change yet. > - intro, para 2: "as Bernstein pointed out" requires a > reference I dropped this. His NFS circuit integer factorization paper was folklore 10 years ago but less so today. > - section 13: whassup with that? why isn't the usual IETF > boilerplate ok? You can't copy text from RFCs into FOSS code. Section 13 gives reader additional rights. Similar boiler plate have been used in a couple of RFCs already, and from what I understand is not in conflict with any IETF procedures. > - section 16: saying the reader "must" follow crypto > research is silly as you cannot ensure readers will do that > (and you know they won't:-). I think you mean that if you > don't keep up to date then you might miss out when issues > are found with this algorithm. If so, saying so would be > better. I tried to rephrase it -- improvements welcome. > - 17: I'm not sure the RFC editor will like references that > only point to http://cr.yp.to/ or tarsnap.com. If you have > better citations in addition that'd be good. As far as I know, Salsa20 was not published at any conference or journal, so there may not be any better references. For the scrypt paper, maybe the conference homepage is better? Instead of tarsnap.com the scrypt paper would then be linked to this page: https://www.bsdcan.org/2009/schedule/track/Hacking/147.en.html I did not make this change yet. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVy8sWAAoJEIYLf7sy+BGdWhIIAKzWn7TrNRJ9IXhGtmYjvEWM OV9S511TOjMslJElJzumKuGlaBSPfi9YTl8JiGtIOJd6Namsk3hxaZ+vsqE2q92R IGYagmn2OUIsJgVjoTUHhMee9G/cZSnych3e0NK6xTm8FTG4BGJpXq6gpg8EM3Oc Zl0OCiJ7OKpt+kj4ZkL4WyhS2DLSicxZ7Tsh+kXp90dwvEj5oOWvZ2w+uBftQsCt JYWkvCNs09Nb9cpCGE5zGkmaBOx9B7dayov+pmipLg4BD+cvNFpPIQakygRsiPOI 6IlFbF4TA0LMFnUVcMSS9mQizGJ330jAlOItz5ie+uhpHp5RwKNSKgNh+S398lQ= =qPJP -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 12 18:44: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 9EB2C1B2F01; Wed, 12 Aug 2015 18:44:03 -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 PuoG_FBD7A0H; Wed, 12 Aug 2015 18:44:01 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4011B2EE9; Wed, 12 Aug 2015 18:44:01 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-b5-55cbf660ef23 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id AC.FF.09777.066FBC55; Wed, 12 Aug 2015 21:44:00 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t7D1hxYr028987; Wed, 12 Aug 2015 21:43:59 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7D1htj6004541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Aug 2015 21:43:58 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t7D1ht35022933; Wed, 12 Aug 2015 21:43:55 -0400 (EDT) Date: Wed, 12 Aug 2015 21:43:53 -0400 (EDT) From: Benjamin Kaduk To: Simon Josefsson In-Reply-To: <20150812195437.2e03c0c8@latte.josefsson.org> Message-ID: References: <20150812195437.2e03c0c8@latte.josefsson.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixCmqrJvw7XSoweUbghZHN69isZjS38lk cW/LJXYHZo8lS34yecw8c5E9gCmKyyYlNSezLLVI3y6BK6Pr6Wf2gqtMFf+/HGJrYOxm6mLk 5JAQMJH4vuA0M4QtJnHh3nq2LkYuDiGBxUwSn7q2soIkhAQ2Mkpcvm8MkTjEJLHl/juoqgZG ieMH5rGBVLEIaEtc/HcCrINNQEVi5puNQHEODhEBTYm57RkgYWYBJYldizvByoWByie+Xwa2 mVPASmJZUzcLiM0r4Cix+eUZRoj5MxglTrz6xgiSEBXQkVi9fwpUkaDEyZlPWCCGakksn76N ZQKj4CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGuvlZpbopaaUbmIEB60k3w7G rweVDjEKcDAq8fBueHQ6VIg1say4MvcQoyQHk5Ior9odoBBfUn5KZUZicUZ8UWlOavEhRgkO ZiUR3qRnQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQnezV+AGgWL UtNTK9Iyc0oQ0kwcnCDDeYCG7wWp4S0uSMwtzkyHyJ9i1OVY8OP2WiYhlrz8vFQpoDUgRQIg RRmleXBzYMnmFaM40FvCvB9AqniAiQpu0iugJUxAS9LlToEsKUlESEk1MPqteb1iX1CeqWrC 4ZSy1ce+rkxm3mswd/6juo9Zhue9d307bsqU+faG+W0V9wneURfn2q2//zXitcHmfX+9Mp27 PdbpmYXzHD0e8uuiTLFIL2v/8uI555/KrbqXU/08kuuruQrvwvdvV4Q4XpPlEeZ/Z9XtfFTm 0qcWhWOcO/ddSd1isqMkS0eJpTgj0VCLuag4EQBH39WIEQMAAA== Archived-At: Cc: kitten@ietf.org, saag@ietf.org Subject: Re: [saag] SSH Protocol Extensions 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, 13 Aug 2015 01:44:03 -0000 On Wed, 12 Aug 2015, Simon Josefsson wrote: > The OAuth SASL mechanism (long delayed, still being worked on) may also > be relevant to look into, but it does not support GSS-API so SSH support > is not a given. The spec just hit AUTH48 today; I am given to understand there are a couple of implementations floating around. -Ben From nobody Thu Aug 13 04:48: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 4EB7D1A1A79 for ; Thu, 13 Aug 2015 04:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etj8UzCyscPr for ; Thu, 13 Aug 2015 04:48:41 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::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 3C06F1A0470 for ; Thu, 13 Aug 2015 04:48:41 -0700 (PDT) Received: by labd1 with SMTP id d1so24731791lab.1 for ; Thu, 13 Aug 2015 04:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=42hrCIRBrw115grYmbP1eToV48RDnumWZr1VWSQouGA=; b=WF0yayzoHZiiuP5wXkXl6t1y1ZP16Bi/xHMTn8MALBfzhNVrIAI6vvwXISv40HJjJY I8RHP04alukwRSOW3vD7KhMh4tb/k8dKYh6bWvLwfMKmlwz5ujG0Z7LExaTm0nPPg/N6 kPmoMrfY0cITfrrj9IY+WS5MlasHg0nn5IRb0yu3VNWqDFbmFTkis+ifK72aL1sqIfok aMfbGeaj6kQTrb+TNO63QxJ37/ohRFrrWIJmcb/WCsOdiYFi5ow4sBzdrb3IU5FFuSAd KBxJz1K2Jo0MISgZhSDwE3X72vo7U3Kt3OcLQo7KLrjhipJCKyXVXD3gAqW88CDy3Hdv 6YVw== MIME-Version: 1.0 X-Received: by 10.112.219.70 with SMTP id pm6mr35430264lbc.41.1439466519588; Thu, 13 Aug 2015 04:48:39 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.112.28.76 with HTTP; Thu, 13 Aug 2015 04:48:39 -0700 (PDT) In-Reply-To: <87y4hg9lnt.fsf@latte.josefsson.org> References: <559153E0.5050102@cs.tcd.ie> <55C932F6.7080203@cs.tcd.ie> <87y4hg9lnt.fsf@latte.josefsson.org> Date: Thu, 13 Aug 2015 13:48:39 +0200 X-Google-Sender-Auth: J54SLbWg1w_syHVrmAXEZPpbfKo Message-ID: From: Nikos Mavrogiannopoulos To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 13 Aug 2015 11:48:43 -0000 On Thu, Aug 13, 2015 at 12:39 AM, Simon Josefsson wrote: > DES-based UNIX Crypt-function, > FreeBSD MD5 crypt, > GNU SHA-256/512 crypt > Windows NT LAN Manager (NTLM) hash > Blowfish-based bcrypt The latter was published in USENIX 1999: https://www.usenix.org/legacy/event/usenix99/provos/provos.pdf > As far as I know, Salsa20 was not published at any conference or > journal, so there may not be any better references. Salsa20 was an official submission to estream competition, so the authoritative reference is the design articles at: http://www.ecrypt.eu.org/stream/salsa20pf.html (the "Salsa20 specification" and "Salsa20 design"). regards, Nikos From nobody Thu Aug 13 06:10: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 D1DC61A1BD2 for ; Thu, 13 Aug 2015 06:10:28 -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 8vvWF_WDxyvm for ; Thu, 13 Aug 2015 06:10:26 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 780A81A1BCB for ; Thu, 13 Aug 2015 06:10:26 -0700 (PDT) Received: by wicne3 with SMTP id ne3so258725395wic.1 for ; Thu, 13 Aug 2015 06:10:25 -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=Pu9QVycZ9YeJmAKsR1TGnW2FGguBNhBbNqlEbg1i21k=; b=wCPvwTNN64atTxJ3AP4a25vXMtTKGVCDC5WJI5xGaXAh8d9Qx2Gvz7Vha3kM4q7wYv Akvv6xyvGvHCJ0ldM5WAdahlWNbNA7zOgOAyd5389MvpRZMQDmOKW509YG2E//HUx4pl 0TKF6Y+t6wJxcC/oSvpR46gHW5TVp8tPnxCKHS5r0scSLrs3qJJkRZVEVWVJZ9Aub50u eJ1gyLhpSAJPejhatgBoztnYB3OlAGGOrNP1eKrMHMbn3Y5tCb/WpW7VUmG9PPj9f6om bLvMMiG2m2wbcynUD1z9jgR4hxKdhkvknqQd/Qo85P9zF29kYGwkuDhH/U32T7kFzhvW RKDg== MIME-Version: 1.0 X-Received: by 10.180.189.17 with SMTP id ge17mr55094454wic.90.1439471425233; Thu, 13 Aug 2015 06:10:25 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Thu, 13 Aug 2015 06:10:25 -0700 (PDT) In-Reply-To: References: <559153E0.5050102@cs.tcd.ie> <55C932F6.7080203@cs.tcd.ie> <87y4hg9lnt.fsf@latte.josefsson.org> Date: Thu, 13 Aug 2015 09:10:25 -0400 Message-ID: From: Kathleen Moriarty To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Josefsson , "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 13 Aug 2015 13:10:29 -0000 On Thu, Aug 13, 2015 at 7:48 AM, Nikos Mavrogiannopoulos wrote: > On Thu, Aug 13, 2015 at 12:39 AM, Simon Josefsson wrote: >> DES-based UNIX Crypt-function, >> FreeBSD MD5 crypt, >> GNU SHA-256/512 crypt >> Windows NT LAN Manager (NTLM) hash >> Blowfish-based bcrypt > > The latter was published in USENIX 1999: > https://www.usenix.org/legacy/event/usenix99/provos/provos.pdf > >> As far as I know, Salsa20 was not published at any conference or >> journal, so there may not be any better references. > > Salsa20 was an official submission to estream competition, so the > authoritative reference is the design articles at: > http://www.ecrypt.eu.org/stream/salsa20pf.html (the "Salsa20 > specification" and "Salsa20 design"). I'd jut like to take a step back from the reference question to ask, why is salsa used as a hash when it was designed as a stream cipher? Is there a reason Blake2 (derived from chacha) was not used instead? Maybe there is a good reason and I'd be interested to have that background. Thanks, Kathleen > > regards, > Nikos > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Best regards, Kathleen From nobody Thu Aug 13 07:24: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 1B92E1B2DCC for ; Thu, 13 Aug 2015 07:24:43 -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 27EKWfxMEBlN for ; Thu, 13 Aug 2015 07:24:40 -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 EA9CD1A00BE for ; Thu, 13 Aug 2015 07:24:39 -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 t7DEO9ab010142 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 13 Aug 2015 16:24:10 +0200 From: Simon Josefsson To: Kathleen Moriarty References: <559153E0.5050102@cs.tcd.ie> <55C932F6.7080203@cs.tcd.ie> <87y4hg9lnt.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150813:nmav@gnutls.org::uaUOiNID1N8iKK+s:2o3K X-Hashcash: 1:22:150813:saag@ietf.org::wEBK3hnwF7VOoGhY:2u/5 X-Hashcash: 1:22:150813:kathleen.moriarty.ietf@gmail.com::BvMZM3/8/1MmKml/:VYeG Date: Thu, 13 Aug 2015 16:24:08 +0200 In-Reply-To: (Kathleen Moriarty's message of "Thu, 13 Aug 2015 09:10:25 -0400") Message-ID: <87a8tv8dx3.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 13 Aug 2015 14:24:43 -0000 --=-=-= Content-Type: text/plain Kathleen Moriarty writes: > On Thu, Aug 13, 2015 at 7:48 AM, Nikos Mavrogiannopoulos > wrote: >> On Thu, Aug 13, 2015 at 12:39 AM, Simon Josefsson wrote: >>> DES-based UNIX Crypt-function, >>> FreeBSD MD5 crypt, >>> GNU SHA-256/512 crypt >>> Windows NT LAN Manager (NTLM) hash >>> Blowfish-based bcrypt >> >> The latter was published in USENIX 1999: >> https://www.usenix.org/legacy/event/usenix99/provos/provos.pdf >> >>> As far as I know, Salsa20 was not published at any conference or >>> journal, so there may not be any better references. >> >> Salsa20 was an official submission to estream competition, so the >> authoritative reference is the design articles at: >> http://www.ecrypt.eu.org/stream/salsa20pf.html (the "Salsa20 >> specification" and "Salsa20 design"). > > I'd jut like to take a step back from the reference question to ask, > why is salsa used as a hash when it was designed as a stream cipher? This is a terminology issue. 'Salsa20 core' or 'Salsa20 hash' is explained here: http://cr.yp.to/salsa20.html Salsa20 core is a hash function, in its general sense, see: https://en.wikipedia.org/wiki/Hash_function In particular, Salsa20 core is NOT a cryptographic hash function. Compare Salsa20 core to FNV or CRC or something similar, not to SHA-1. Salsa20 the stream cipher is based on the Salsa20 core hash function. Scrypt does not use Salsa20 the stream cipher. Think of the Salsa20 hash function as similar to FNV hash. This said, I'm not convinced the estream Salsa20 specification is the most suitable reference to explain the Salsa20 core hash function. The eSTREAM site linked above only appear to publish a ZIP file with the algorithm specification. Is that a good reference? However, perhaps we can add it as an additional reference? Then there is always the worry about which is the "right" one in case of differences, but since the draft includes test vectors I doubt there will be any confusion. > Is there a reason Blake2 (derived from chacha) was not used instead? 1) Scrypt needs a (fast) mathematic hash function, not a cryptographic hash. 2) Age; ChaCha and Scrypt were designed at the same time. > Maybe there is a good reason and I'd be interested to have that > background. I hope this helps. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVzKiIAAoJEIYLf7sy+BGdKsUH/iimOQs6LdlZWny7KeOv0bAX fVgi64aGzozoC/oE42or4Mqhwi208ETZ5V5DQaVoosJoskyAQpRtKD3LxPiTrlyy c2AhyYvWKr91POTjSaeutuEIyvCSE/GvCOx4302X1hlVZkv+UnMvaq1iG65B/1mO JF4fmkPjTfUnJXQWAuWAjFQEo8Th7Jj0U+RtKau4hteYAnT1i5NNc+w8YouWkvsg zeUPPerxNHGyHr/TyyKdny4kPXxX68PS6OrhSWqvC72LZIyUiUay3oSDzw1CHYF9 GA7gicOIi5s/cCWwk7M5hKXlkP2UwPUZwnM2iHQjwt+bkodjww1u9xd185K6x4U= =rFmW -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 13 07:35:57 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 9DF4A1A21C2 for ; Thu, 13 Aug 2015 07:35:56 -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 Fg3hKLvgJbLK for ; Thu, 13 Aug 2015 07:35:54 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3B41A21B4 for ; Thu, 13 Aug 2015 07:35:54 -0700 (PDT) Received: by wijp15 with SMTP id p15so261476463wij.0 for ; Thu, 13 Aug 2015 07:35:53 -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=vFq4vDwM9641odoz6O0NYmR0YMpt3F7NoFOEvsSX49A=; b=PaZu6XjEb30zIkK10+4EHwjtACiMgCoKYbV/UYoq4/DinWUTph0NeOo79ktNmEEc4T TOjwvb4pGj7YnRET9VWkxkxSsyGvwGn7Bz8xb67xBaX7Ec9E2bc+z7vD96zuk1ukQrZo DG7QHd7rmv5Oay4xeectYTfi2fn/kBdakvuUPs8RYeTtWNeev3PyEf+Va6A0B+iAXzL0 KGdCn3A7GUnFcJTXaVbCCQbjBogpJxiAQk69/TRkvcNbWU7bOJgJsv3+agz4FJjWJ93o 9F4T7PB4+SAwk0+WtKqjaqDJlsdLdfES5CV4x7OsjDw1kyDs+xQrZvxnDT4az+6XKRQ+ MAMw== MIME-Version: 1.0 X-Received: by 10.194.2.9 with SMTP id 9mr76644739wjq.95.1439476553155; Thu, 13 Aug 2015 07:35:53 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Thu, 13 Aug 2015 07:35:53 -0700 (PDT) In-Reply-To: <87a8tv8dx3.fsf@latte.josefsson.org> References: <559153E0.5050102@cs.tcd.ie> <55C932F6.7080203@cs.tcd.ie> <87y4hg9lnt.fsf@latte.josefsson.org> <87a8tv8dx3.fsf@latte.josefsson.org> Date: Thu, 13 Aug 2015 10:35:53 -0400 Message-ID: From: Kathleen Moriarty To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 13 Aug 2015 14:35:56 -0000 On Thu, Aug 13, 2015 at 10:24 AM, Simon Josefsson wrote: > Kathleen Moriarty writes: > >> On Thu, Aug 13, 2015 at 7:48 AM, Nikos Mavrogiannopoulos >> wrote: >>> On Thu, Aug 13, 2015 at 12:39 AM, Simon Josefsson wrote: >>>> DES-based UNIX Crypt-function, >>>> FreeBSD MD5 crypt, >>>> GNU SHA-256/512 crypt >>>> Windows NT LAN Manager (NTLM) hash >>>> Blowfish-based bcrypt >>> >>> The latter was published in USENIX 1999: >>> https://www.usenix.org/legacy/event/usenix99/provos/provos.pdf >>> >>>> As far as I know, Salsa20 was not published at any conference or >>>> journal, so there may not be any better references. >>> >>> Salsa20 was an official submission to estream competition, so the >>> authoritative reference is the design articles at: >>> http://www.ecrypt.eu.org/stream/salsa20pf.html (the "Salsa20 >>> specification" and "Salsa20 design"). >> >> I'd jut like to take a step back from the reference question to ask, >> why is salsa used as a hash when it was designed as a stream cipher? > > This is a terminology issue. 'Salsa20 core' or 'Salsa20 hash' is > explained here: > > http://cr.yp.to/salsa20.html > > Salsa20 core is a hash function, in its general sense, see: > > https://en.wikipedia.org/wiki/Hash_function > > In particular, Salsa20 core is NOT a cryptographic hash function. > Compare Salsa20 core to FNV or CRC or something similar, not to SHA-1. > > Salsa20 the stream cipher is based on the Salsa20 core hash function. > > Scrypt does not use Salsa20 the stream cipher. > > Think of the Salsa20 hash function as similar to FNV hash. > > This said, I'm not convinced the estream Salsa20 specification is the > most suitable reference to explain the Salsa20 core hash function. The > eSTREAM site linked above only appear to publish a ZIP file with the > algorithm specification. Is that a good reference? However, perhaps we > can add it as an additional reference? Then there is always the worry > about which is the "right" one in case of differences, but since the > draft includes test vectors I doubt there will be any confusion. > >> Is there a reason Blake2 (derived from chacha) was not used instead? > > 1) Scrypt needs a (fast) mathematic hash function, not a cryptographic > hash. > > 2) Age; ChaCha and Scrypt were designed at the same time. > >> Maybe there is a good reason and I'd be interested to have that >> background. > > I hope this helps. Thanks, I was just taking a quick look at this because of the reference problem. > > /Simon -- Best regards, Kathleen From nobody Thu Aug 13 07:40:43 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 39EF01A21B7 for ; Thu, 13 Aug 2015 07:40:42 -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 r5nB-NmmRCpU for ; Thu, 13 Aug 2015 07:40:41 -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 012961A21B5 for ; Thu, 13 Aug 2015 07:40:40 -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 t7DEeKlw012024 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 13 Aug 2015 16:40:22 +0200 From: Simon Josefsson To: Nikos Mavrogiannopoulos References: <559153E0.5050102@cs.tcd.ie> <55C932F6.7080203@cs.tcd.ie> <87y4hg9lnt.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150813:nmav@gnutls.org::QTgmLmZardSdIG6L:Q2ks X-Hashcash: 1:22:150813:saag@ietf.org::OiqFvJHo6mEtWzqF:YDNx Date: Thu, 13 Aug 2015 16:40:19 +0200 In-Reply-To: (Nikos Mavrogiannopoulos's message of "Thu, 13 Aug 2015 13:48:39 +0200") Message-ID: <871tf79rqk.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 13 Aug 2015 14:40:42 -0000 --=-=-= Content-Type: text/plain Nikos Mavrogiannopoulos writes: > On Thu, Aug 13, 2015 at 12:39 AM, Simon Josefsson wrote: >> DES-based UNIX Crypt-function, >> FreeBSD MD5 crypt, >> GNU SHA-256/512 crypt >> Windows NT LAN Manager (NTLM) hash >> Blowfish-based bcrypt > > The latter was published in USENIX 1999: > https://www.usenix.org/legacy/event/usenix99/provos/provos.pdf Thanks, I have added this reference: https://gitlab.com/jas/ietf-scrypt/commit/3ec64578caeae390a2135eccd482e0e1659163c9 I recall a blog post from Ulrich Drepper describing the GNU libc SHA-256/512 crypt function but cannot locate it now. NTLM was discussed on this list recently, and it is a proprietary algorithm and I'm not aware of any suitable reference for it. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVzKxTAAoJEIYLf7sy+BGdX5kH/2HeyJ5WAMBgIzlDgELpFdMc xIOGabX/qXUJU7BeveunfCbYAo2r4mNWammjdinYA3XV/tnCQL1YYBQ/L1itQ7cZ pBDYJeN8jK7EoZlK21NyiBoMlIKLTCnITXnhNeFfIeuSzTcSc3/0s7XxkqjoKtHl n++S3bNt8ZbznxjZVJqsMjyR20Um6BUVSfhW3ihL6rFqfmXKTwS8rvnQvzNd8Wqq 5PEECziWxRaZZ6MY257rANPP4YbpEwhlW0YmN6Hq+SSnZLgp6yrxBZDJrqKyIAm7 9uVH7+ENwX0RmF/f3RIhmHoE2PpQNC+vDovji1G8KIsG6YjXRb5Rz1pg2XArTNo= =A7XU -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 13 10:48:00 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 A29471A8F37 for ; Thu, 13 Aug 2015 10:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4yW18qrzcfE for ; Thu, 13 Aug 2015 10:47:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF7B1A8BC4 for ; Thu, 13 Aug 2015 10:47:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3msb302blJz3R6 for ; Thu, 13 Aug 2015 19:47:56 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=uP0Exs/o X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BfXODRbliP-c for ; Thu, 13 Aug 2015 19:47:54 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 13 Aug 2015 19:47:54 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B25E1800A0 for ; Thu, 13 Aug 2015 13:47:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1439488073; bh=VfLR2JsXD8PD0JYGi29kboirHI4R9zHMxFyv1AUXY4Y=; h=Date:From:To:Subject; b=uP0Exs/o3x0zNBm/3nzLBRxx3GR2nbdSO2RkLjDFyTC/VAZNRLsNxRJqdjrn95Rt8 tlCMtzzHduD/3Vm1tmg3iPX4kmkY6HsWCR5Jtru4DemC9inT8XSwpw3QtBI1Grz8eO r4cOVV3vFEy13mx806jKLU9Y613Y0ASEI43FITQk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7DHlrKR015174 for ; Thu, 13 Aug 2015 13:47:53 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 13 Aug 2015 13:47:53 -0400 (EDT) From: Paul Wouters To: saag@ietf.org Message-ID: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [saag] IETF-93 Trans summary 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, 13 Aug 2015 17:47:59 -0000 Trans met after saag. Work on the RFC-6962bis document is nearing completion. The open tickets left seem non-controversial. The gossip document progressed and people thought it was ready for working group adoption. The threat model document was presented and people also thought it was ready for working group adoption. There was some talk about whether to start an architecture document A new concept of selective logging was presented which generated some discussion to take to the list. Full minutes at https://www.ietf.org/proceedings/93/minutes/minutes-93-trans From nobody Thu Aug 13 14:35: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 986BD1B3B39; Thu, 13 Aug 2015 14:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, 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 iFJBpzL3pHiU; Thu, 13 Aug 2015 14:35:55 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 856DA1B39D3; Thu, 13 Aug 2015 14:35:55 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1FE881022400A; Thu, 13 Aug 2015 14:35:55 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 13 Aug 2015 14:35:55 -0700 (PDT) Message-ID: <449964e467e0347db185eb787db71efd.squirrel@www.trepanning.net> In-Reply-To: References: Date: Thu, 13 Aug 2015 14:35:55 -0700 (PDT) From: "Dan Harkins" To: "Christian Huitema" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Sam Hartman , "saag@ietf.org" , "emu@ietf.org" Subject: Re: [saag] Feedback on Salted EAP draft 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, 13 Aug 2015 21:35:56 -0000 Hi Christian, On Tue, July 14, 2015 10:50 am, Christian Huitema wrote: [snip] > The draft is short and clear enough, but it acknowledges a pretty big > security issue: "the salted > password from a compromised database can be used directly to impersonate > the client-- there > is no dictionary attack needed to recover the plaintext password." > > That's a pretty big caveat, but there are still some advantages over > operating with unsalted passwords. The draft aligns server side password > management for EAP-pwd with standard industry practices, which is good. > In case of server compromise, the immediate effect of the compromise is an > attack on the already compromised server, and the per-user salt make > password discovery harder. The security section should be expanded to > explain this tradeoff. Yes, it's a big caveat and, as I mentioned, I'm trying to be as blunt as possible about it. I have updated the Security Considerations to include the point you are making about server compromise and the per-user salt still making password recovery harder. > Nits: > > - in the abstract, missing "not" in " but did (not?) include support for > salted passwords." Nice catch. An -02 version has been posted. Would you please take a look and let me know whether it satisfactorily addresses your comments? regards, Dan. From nobody Thu Aug 13 17:30: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 6261B1AD0A1 for ; Thu, 13 Aug 2015 17:30:12 -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 FtPOuTe911aT for ; Thu, 13 Aug 2015 17:30:10 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C841AD0A0 for ; Thu, 13 Aug 2015 17:30:10 -0700 (PDT) X-AuditID: 12074423-f79496d000001e58-66-55cd3691140c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 74.2B.07768.1963DC55; Thu, 13 Aug 2015 20:30:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t7E0U81G025145; Thu, 13 Aug 2015 20:30:08 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7E0U4eA013422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Aug 2015 20:30:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t7E0U4n0016670; Thu, 13 Aug 2015 20:30:04 -0400 (EDT) Date: Thu, 13 Aug 2015 20:30:04 -0400 (EDT) From: Benjamin Kaduk To: Simon Josefsson In-Reply-To: <871tf79rqk.fsf@latte.josefsson.org> Message-ID: References: <559153E0.5050102@cs.tcd.ie> <55C932F6.7080203@cs.tcd.ie> <87y4hg9lnt.fsf@latte.josefsson.org> <871tf79rqk.fsf@latte.josefsson.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0Z1odjbU4GWDgsXSnbtZLab0dzJZ 3Ntyid2B2WPytkZGjyVLfjJ5zDxzkT2AOYrLJiU1J7MstUjfLoErY3LPBMaCV0wV0+ecZG5g XMzUxcjJISFgInH181UWCFtM4sK99WxdjFwcQgKLmSTuXgYpAnE2MkrsXXOdDaRKSOAQk8SK 5gCIRAOjxLazi8BGsQhoS2x5N5cVxGYTUJGY+WYjUAMHh4iApsTc9gyQMLOAn8Tmoz/ASoQF bCSmT78PZnMKGEo8WdrNDGLzCjhKnLrXC3XFFUaJPQ0QRaICOhKr909hgSgSlDg58wkLxFAt ieXTt7FMYBSchSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0zvdzMEr3UlNJNjODw dVHewfjnoNIhRgEORiUe3g2PTocKsSaWFVfmHmKU5GBSEuXlNzkbKsSXlJ9SmZFYnBFfVJqT WnyIUYKDWUmEd4oUUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYL3 qzFQo2BRanpqRVpmTglCmomDE2Q4D9BwI5DFvMUFibnFmekQ+VOMuhwLftxeyyTEkpeflyol zjsBpEgApCijNA9uDiztvGIUB3pLmPcmyDoeYMqCm/QKaAkT0JJ0uVMgS0oSEVJSDYzbvcqz FC+HRuY05fXx54lZdy5+m1qjpRXW9CrdePmWNbZHkl5tsMz9fF7Xadn0+Oy9kd9OC/T/+eEn GXDa8ePnPCmX9zmn/eW+qf2afJN9Vnjgy5aJZxKrfkzzTnvEYvqUM2dD8frsv6EKjtF2YuzL 7D5m3rB+ebuV7QjzZm73p7fnyezq+KPEUpyRaKjFXFScCAD9DPiKFgMAAA== Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 14 Aug 2015 00:30:12 -0000 On Thu, 13 Aug 2015, Simon Josefsson wrote: > NTLM was discussed on this list recently, and it is a proprietary > algorithm and I'm not aware of any suitable reference for it. It has been a while since I was needing to refer to it from a document, but I thought that https://msdn.microsoft.com/en-us/library/cc236621.aspx was pretty canonical. -Ben From nobody Thu Aug 13 17:55:56 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 A30FA1AD0C9 for ; Thu, 13 Aug 2015 17:55:55 -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 CLDeI2PSXO1K for ; Thu, 13 Aug 2015 17:55:54 -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 F024F1AD0C5 for ; Thu, 13 Aug 2015 17:55:53 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 30EF36D722; Thu, 13 Aug 2015 20:55:52 -0400 (EDT) Message-ID: <55CD3C9C.5080109@iang.org> Date: Fri, 14 Aug 2015 01:55:56 +0100 From: ianG 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: saag@ietf.org References: <559153E0.5050102@cs.tcd.ie> <55C932F6.7080203@cs.tcd.ie> <87y4hg9lnt.fsf@latte.josefsson.org> <87a8tv8dx3.fsf@latte.josefsson.org> In-Reply-To: <87a8tv8dx3.fsf@latte.josefsson.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 14 Aug 2015 00:55:55 -0000 On 13/08/2015 15:24 pm, Simon Josefsson wrote: > Kathleen Moriarty writes: > >> On Thu, Aug 13, 2015 at 7:48 AM, Nikos Mavrogiannopoulos >> wrote: >>> On Thu, Aug 13, 2015 at 12:39 AM, Simon Josefsson wrote: >>>> As far as I know, Salsa20 was not published at any conference or >>>> journal, so there may not be any better references. >>> >>> Salsa20 was an official submission to estream competition, so the >>> authoritative reference is the design articles at: >>> http://www.ecrypt.eu.org/stream/salsa20pf.html (the "Salsa20 >>> specification" and "Salsa20 design"). > http://cr.yp.to/salsa20.html > This said, I'm not convinced the estream Salsa20 specification is the > most suitable reference to explain the Salsa20 core hash function. Concur - the world has changed. Review-by-web-page is now fairly well understood. As it happens the most influential paper in the space was simply bandied around on a mail list for a while. You could say, it was reviewed by running code and rough consensus! He'll probably end up with the first pseudonymous Turing prize. Or she. Or they. iang From nobody Thu Aug 13 22:08:16 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 DAA311AC41C for ; Thu, 13 Aug 2015 22:08:14 -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 UT8EROpjQCmf for ; Thu, 13 Aug 2015 22:08:12 -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 86E531AC422 for ; Thu, 13 Aug 2015 22:08:12 -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 t7E57xBb015468 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 14 Aug 2015 07:08:01 +0200 From: Simon Josefsson To: Benjamin Kaduk References: <559153E0.5050102@cs.tcd.ie> <55C932F6.7080203@cs.tcd.ie> <87y4hg9lnt.fsf@latte.josefsson.org> <871tf79rqk.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150814:kaduk@mit.edu::wAb8vnEx7JN8daIw:7yNC X-Hashcash: 1:22:150814:saag@ietf.org::Mw1aK9deP2WRRqzC:8WbU Date: Fri, 14 Aug 2015 07:07:58 +0200 In-Reply-To: (Benjamin Kaduk's message of "Thu, 13 Aug 2015 20:30:04 -0400 (EDT)") Message-ID: <87oaia8nkh.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 14 Aug 2015 05:08:15 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk writes: > On Thu, 13 Aug 2015, Simon Josefsson wrote: > >> NTLM was discussed on this list recently, and it is a proprietary >> algorithm and I'm not aware of any suitable reference for it. > > It has been a while since I was needing to refer to it from a document, > but I thought that https://msdn.microsoft.com/en-us/library/cc236621.aspx > was pretty canonical. Thanks -- that appears similar to a cr.yp.to link, maybe somewhat worse since it doesn't mention an author and the content appears to change frequently and I can't find links to a stable version of the document. I'll use it and let Stephen and/or the RFC editor figure out how to handle this. I agree with ianG that the world has changed here, and it should be fine to use URLs like this when there isn't any better alternative available. https://gitlab.com/jas/ietf-scrypt/commit/306d3e8a6d67d9118c6907a5544baa79ccf76f1d#diff-1 /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVzXeuAAoJEIYLf7sy+BGd5ZYH/2K3YJazNgP1MRqf3OAXVFsy /1o1wFqf2T9Nb52F68c4Uut1kT1n1j2hLPJOPup9brVjz4S7GAplJYzCidLnHptY AB0X/FN3NQ64tx5UK+8nFnoqqtvZspJeh6W3kOQvhPBrweKaa6k3ANbNPSpDNfL6 WeojTgI/KKHgGYutvSOlqv3dBt8jb3b8ooUOMHZ+iePyVw2SwaXQ1/2BwJupTTmE C6tqQ8XGt6TWcF8txBfJGWFWc/9xPVf3/7aNAyjIvouJbl0sApzbr8gSYoueYLsa Luh0XYget7/QLzZy5okbXsl5OeHlQPfQSHwmdu5xcsLMf8dyQwzPIed2FjSaHmA= =Yizx -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 14 04:32: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 53BE11ACD5B for ; Fri, 14 Aug 2015 04:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_tka4CLaITy for ; Fri, 14 Aug 2015 04:32:28 -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 3F0D71ACD74 for ; Fri, 14 Aug 2015 04:32:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 103B8BECA; Fri, 14 Aug 2015 12:32:26 +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 DI5bXgJBDyBw; Fri, 14 Aug 2015 12:32:25 +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 D4B53BEC0; Fri, 14 Aug 2015 12:32:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439551945; bh=E5XWCy+gnmNnUsWmgnZoju9mzZ/qLtL1UH9FF0nLRr4=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=rKdJ5i+O4yOnUdrPPza2OtYKMWD6wWZ9Spdbhx0F248xibPIrgd50o9EUIf+VN6se ChzlaEJBe6hcb8sY6q7pJ3uxVIHSrLg0hi7Gn9IgcLjJyorosMJ6DHdEaCe482q4VE z2+qVZbJEvR3lqjlr5/Brtpon1i3ANJBKbSLSFe4= Message-ID: <55CDD1BA.6030100@cs.tcd.ie> Date: Fri, 14 Aug 2015 12:32:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Simon Josefsson , Benjamin Kaduk References: <559153E0.5050102@cs.tcd.ie> <55C932F6.7080203@cs.tcd.ie> <87y4hg9lnt.fsf@latte.josefsson.org> <871tf79rqk.fsf@latte.josefsson.org> <87oaia8nkh.fsf@latte.josefsson.org> In-Reply-To: <87oaia8nkh.fsf@latte.josefsson.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XRun6Nksn5mD4xEkW6nfDa9iKIt8JpJ4R" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf 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, 14 Aug 2015 11:32:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XRun6Nksn5mD4xEkW6nfDa9iKIt8JpJ4R Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/08/15 06:07, Simon Josefsson wrote: > I agree with ianG that the world has changed here, and it > should be fine to use URLs like this when there isn't any better > alternative available. Using URLs is fine, and sometimes the best that can be done. I think the RFC editor are reasonably enough concerned that bitrot does kick in and they, and we, do like that decades old RFC references can still be de-referenced. So in general I think it's reasonable to question any case where the only reference is via a URL hosted on a domain that one considers might not be there in 20 years. And having asked the question, it can also be reasonable to just use such a URL if that's the best there is. S. --XRun6Nksn5mD4xEkW6nfDa9iKIt8JpJ4R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVzdG7AAoJEC88hzaAX42iYIsH/iXaZHMRaOdRNkpH4uTU/t5y jvb37LArWGZXhEuFCzmzuV9c4RLtl7bT4F3cfejd3OsKxapmLXk2XA9koVTT7VPU qlTxSgypXF1Bus/itdjvVnlQGUkF3vEp2oRg3nmJ7it4XvlMcE56LLCQdnu0jRwy bCoDCSEYqDZR2ocSurDnG/TiIwuI8siIMEMUe4vbYVWbqo/etQWEiyXokwTMRLZ+ Ey/4PuC4b+73NM8swwisLm2H8BY3hXokQ8sazXQ1mSYpbx3Cshl1ya7qMobY6QVj LCLmFtcGhgLbcvYmx9reUUDK+eVGTKqtAYcmjsQGQ+omNsyWcUS3JKri94YocKI= =R5Uy -----END PGP SIGNATURE----- --XRun6Nksn5mD4xEkW6nfDa9iKIt8JpJ4R-- From nobody Fri Aug 14 08:02: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 368F61AC3CB; Thu, 13 Aug 2015 06:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 ZpwEO5Bjwf1z; Thu, 13 Aug 2015 06:49:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2ED1A906F; Thu, 13 Aug 2015 06:49:12 -0700 (PDT) Received: from BN1AFFO11FD005.protection.gbl (10.58.52.30) by BN1AFFO11HUB026.protection.gbl (10.58.52.136) with Microsoft SMTP Server (TLS) id 15.1.243.9; Thu, 13 Aug 2015 13:48:48 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.222) smtp.mailfrom=osu.edu; cryptonector.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.222 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.222; helo=cio-tnc-pf08.osuad.osu.edu; Received: from cio-tnc-pf08.osuad.osu.edu (164.107.81.222) by BN1AFFO11FD005.mail.protection.outlook.com (10.58.52.65) with Microsoft SMTP Server (TLS) id 15.1.243.9 via Frontend Transport; Thu, 13 Aug 2015 13:48:47 +0000 Received: from CIO-KRC-HT04.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by cio-tnc-pf08.osuad.osu.edu (Postfix) with ESMTPS id 149672E007E; Thu, 13 Aug 2015 09:48:47 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-KRC-HT04.osuad.osu.edu ([fe80::2d93:5c00:ad4e:861d%10]) with mapi id 14.03.0224.002; Thu, 13 Aug 2015 09:48:45 -0400 From: "Cantor, Scott" To: Nico Williams , Simon Josefsson Thread-Topic: [kitten] [saag] SSH Protocol Extensions Thread-Index: AQHQ1RiM4EkCc0B71keQikYW9uIlvp4I6MWAgAAL2ICAAP68AA== Date: Thu, 13 Aug 2015 13:48:45 +0000 Message-ID: <6B7C7317-467A-4809-ABA3-FF599332F18D@osu.edu> References: <20150812195437.2e03c0c8@latte.josefsson.org> <20150812183657.GG3654@localhost> In-Reply-To: <20150812183657.GG3654@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [140.254.59.150] Content-Type: text/plain; charset="utf-8" Content-ID: <7DA4AB04CCA61841BA0289A1113B4504@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD005; 1:29duy2tHuAbbNOLx9IL3pDgFXjy9imqJyEJ8Dr4SUoBF+x3b4PX4aMSLEeSfYXINAPqREaVOASmTZTEf3R3as26dIwMLZAjsBCQuA9OEXKwKe5YJngyhrquSEqIWTucPU4TAfF43x6UZUaP4uLMRzdbCNbnOPpYd13h6IPedGcyfnr3Qy2H/9n3QQIda1kZVyuNhhwhpF5E5EpclJPWE5bdcBj90QKAzPn52exkFh44jgxOULe2f7c83icXqYKDqzdQecoj2Xc9RNHmgsEh9JNCNKsapBqSwmydoT810q8iNK5aXrwer5R9AaC7qrtrA04UZp63YhFtlvLwY19JvyUqtCqfWpe274C3BCOFrkvo= X-Forefront-Antispam-Report: CIP:164.107.81.222; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(3050300001)(377454003)(189002)(479174004)(199003)(24454002)(2656002)(50986999)(87936001)(36756003)(89122001)(90282001)(109096001)(76176999)(106466001)(50466002)(46102003)(75432002)(5250100002)(23676002)(2950100001)(5001770100001)(88552001)(2900100001)(5001860100001)(19580405001)(6806004)(93886004)(5001830100001)(5001920100001)(33656002)(4001540100001)(5003600100002)(19580395003)(66066001)(82746002)(83716003)(102836002)(54356999)(189998001)(64706001)(77156002)(62966003)(93346002)(106116001)(86362001)(47776003)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB026; H:cio-tnc-pf08.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-tnc-pf08.osuad.osu.edu; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB026; 2:U8F3ox6W9nBVWzUpHoMoUYVsqz1dfTSWjslya6ZP2x42+jxftxilJ9UDoWLOyzV3XtEw6n+i2Rb2t8Oy/JkGpugWdyUteKlkqqAzznOPWfnkPCNsPNS6sO6rixPVkpp8YUWa3XKHpSc4nf9aCcW3bO5uu/P2J8r6Nc5BPL5ybnA=; 3:z60m4yTVmHUs+5v0VKHZs+R4DILaY/1h1SWiox2s+Cd9V9Ss5YSZ4c1aeJokje+UkElquxn0RpiBr3vKLdqEBbNBgfZaHhNKSFObZznBMIV5Vs+/YLlb5SOHeRfSOch7eJSZwKx2bUpjorB4tlpcnQhUmTGRhT9V91FmZc0UyxxCugSh/i7WcBec2WN6B8/F7++p4OYz36Fvzs+9pLZ7nH8/MlxzhIy2+KEb1fTZd+MXH7Nz39oEuBhT4csd4AqP; 25:YWn++M45vvdUwuASC77DZRvQXb3IHKGCdEkQXLxGzw3iFcOrsrJez+vz1ZsFSGO0ir8ypasUzVQSwZMosIKNBmWA3TnXTJ97zbH3xZsIrAUOQ8luGrVYDIz/ExJSZ/PRgCsa89l97OpioxHPLjBq9W8PGQW5dKSBHI5Zba4f/Kzxj9UYVL7r8ZJb8QJScfhGREYpyDxU7vl5t1W8zLj59mO2hhP0wsnEa69QqUnxbh9AwaPmhmLHjmwT1CumiTW08zF9TVOJSdbJ9UOePFVXLw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB026; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB026; 20:JFpVlxrPYlF2NrDoLwqDq9UxIf2omy61WUr88Zq+aLaAnpDt88CRKu33FMucV/miXQuSz0woaAyiNDGQNoOtenLBTD9p02VaDDghdjLCal2RmY+WGMH7u9gIjFDn0QF3zoCSyveyBWBc3bZECmDjKLGA1ENPJ+HQEcyJSoWqk1ZgHpd+FqblWz5EQ27Se2hBAFUaBaEuWBsEpcsefODvX/O3weHQM0aMoVF20CSZ+VbiLT1Fa4VxWEr/Qlb5U9ljQPzY5r0/e8EvBXZ7u6unTQbriNVi7ysEhHuGJsgB39D3xDRValhZPBnw5d10sTr5aBAXzzs0mHU2G11MBCUhUJKoN40oN8bqh5wLyCldpGJG0H9ZZifSqJCAGfWTM7r4P2Tfs1RpbFU70rF10m/oQnlZYahfu+i7xaMnCsheo2Rwj+8XmVQJsBpGMwe5uGzet82CMwb6eyae6KYSE7pBULNoNAPrM54Z6kFo1CPs6Qu9j7tt1jfBhuy/A8ejnHCt; 4:N+Yy5cJU6Sn96/heE0OlKJYa6Ymgz9Kg55vJBnEg1ptNjQ82Cc6yzdy/ce3exxeViOQeZu5bH96Z1esGWkwv1xHAeegw0Nn2BT8bboMEUY/iyzt/lSFZrZSDIMEvhkTOt3ZrYz4F+uV5fuk/jBnkyx6o142AmuwhUbjQU3VwYLzMZrtZzWhT52PRGJts/qbda6BBdNROCQfDPavDSSMl/JbI5GvBPTpjuCjTDukkD5nt6QXPEhiVIs7jkp8OvcT1N7BNgFOU7iuozslz9qfcDWDysJrKNaib1uEi9NmiquY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1AFFO11HUB026; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB026; X-Forefront-PRVS: 0667289FF8 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFBRkZPMTFIVUIwMjY7MjM6SEVJNzgvcGJhTSt5YlNab0lqc0FhMXhw?= =?utf-8?B?Wm9jZXNGRURab1AzbDVkekVaM1FRSWJHRmhaN1FXRFVGa3hBRWpGSTluL1lV?= =?utf-8?B?Nlc2TDFvVERYN0kzOEllN1dSeHFKTndUVGVkQXNxNStVbWVIWTR6cXIzaVpC?= =?utf-8?B?NlE1dUM3WGR0clVhSUhSanN4NHF0L1J6MDFWNno1Mk5zaUJ1anlodEZLRktr?= =?utf-8?B?VnJ1MXpFL1hBVmdjY3pvNDBkQnNFbmNybFFVdFhGMXhiZVJzSVFQSFVnVEN3?= =?utf-8?B?V2UrMnhObHQ5MzV6NDJtU0lISFgrWnhtbGtLcmE0NWNrcW9zQnExMklBYWhx?= =?utf-8?B?S0o1WXBRWWUyU2JVL0RtT0c0QWNXSTNISFJON2Vya1RJeGdWRVJldEQ0QnZj?= =?utf-8?B?SmM4Ykx5NnRmOEdac1BJL1hXYUJWbk00WU1MMTVTOS9YVWQ5UkYwUXIyMVlq?= =?utf-8?B?d2RnWUVyRDdzYmJoVTYxRDFUbDViTUdIS1JZdzFjRi9PQVpGOFk1UUhRbXlN?= =?utf-8?B?QUlFVktOQWE5cGhnU2ZFUDZJTzI3elNUTzA1dWRGdjRKZEhLRnN0aDNyQldM?= =?utf-8?B?VUcwVU1UNGs4Ym03dC80ekNHYUl5TXJOM3NEdkRnYS9XMFBZTzZXQkpMRVhE?= =?utf-8?B?UkpLVFFxVERUeGZrUjR4bWFQRFB4WjBsdFJjeURIN3Q5WWJ1Zld3dDNabWUw?= =?utf-8?B?Q1ZsdTloU3lDdWtGL1RIVUlLWEhuQmlsbGhBeVNwRXVJeUlJWmNmRjhXOGp2?= =?utf-8?B?dFRaWU5JVFRIZWZQOU5SUm15MEV0ZFVoUm9zM056VWtsL0NXSXNQUXhFb1Jz?= =?utf-8?B?UVR5RDc3VkF4aWZoa1JtbHBDRTdOVFgyQU90WnduK3hrM2lTS2FzdVNMTTlC?= =?utf-8?B?L1g4dW5EK3ZVMlhKd1R3akxlVnBhN1pGVS9Rc2pMdTM5dFlWSVNBc242NVdl?= =?utf-8?B?N3BQcFZpT3ZvcncwNlJsK05yN0VKQWlFUG94ekhzazhzKzNVa3RBck5ucjJR?= =?utf-8?B?SW1RVEVWamQvS0draDhEQk5INW43VUZjb2tCcjZlRnJjRE1zd0VKOVU4VHBP?= =?utf-8?B?cEYweWhlbVRNR3dxMUE3eG5iajE2eFZ3M2UzSkFCV3Q0V0Q1MkxLVU1OSVZF?= =?utf-8?B?dG5WemZaa3dCekFZTzNFQWRaUGxPQlhQbzhCMzF6TEhxcmp0bWYvZkR4WXBx?= =?utf-8?B?cFFMdERVeUpLRXU3cFNJSElEMU5uTVlNczI5Tk1hWURzNGU1Ri9GY0t3alps?= =?utf-8?B?UFNTMytSZlhCc3RscU5EMitHdm9rSk9rSmhKb1VZaHR5U1FWNTRHaHVhL1Mz?= =?utf-8?B?MHB6cnpMa3MwT3hzQy9mOFhoUVJrbjNqSTNuUU9WSkplZStkZzAvUFhBMml0?= =?utf-8?B?dFptZDBSQm0rNkdCQWgyNFV1eXJRRk0zWkJiL1dYMmJpb0wvOU5rbHJ3dzZT?= =?utf-8?B?WGxPT3BMdWhkZEN4UStBbDljN2tzeE03QXh3ckJFRHQwUWVHRHFOS0NIMGFW?= =?utf-8?B?eGhqTDNPb0FLR3JFY1RVRm9FaUkzVzhIbkoySkNGVXJWSisvS0gxMVZpMHMx?= =?utf-8?B?RlprdkJ1WXNZUXJHNXZvemNKTFgvZkJQYTVtV2NBcUE0QVhtRzJYSGVSbGZr?= =?utf-8?B?RTJPckFzTDRsbitneTdWSXVtcHVhZkRhbXlaa3dsTFMrODc4ckU2S05oem9u?= =?utf-8?B?c3ZldzVsODd0MkhwREJ2WnZoREJSQ3VGNzBGWlRBNzFyYU1rNXhrRHZ6ZTky?= =?utf-8?B?MkNWRjM4S3AwSGl0b2tPK29KcXI4aG5GcngvUFEvV292K2duWTFkWnpNemk2?= =?utf-8?B?ekhudThuN3VZZ3lvWU8yYTNIQm05MHhMSjZGRnFyRkFXelJ6K1k1bGtYcnJj?= =?utf-8?Q?SZBxxd1M6uQdU=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB026; 5:aatwZOdSzvfV2Ygeg4ez768RAmE/I0i+70ijOg7ofwC9/eeJE7WoLg5Cr+V6KBD1S6KibIu0rLCdkPoPsF93F95GX5eJwe1vqv1QTEWeOk2UqlDWaQsE+iBBOKNmbkGXNBm361/za1/84BE1WqCvVw==; 24:l6bmfuV3ZU7/PPuOaa8qBqSAnYW7xDyJx1cRiOlbgnpSgSV2A7uMSNNfBNtq4tQXRn72gZnxj5YUjy224ravsWH3ba4aoJfCBWwtuUWC2ZI= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2015 13:48:47.7872 (UTC) X-MS-Exchange-CrossTenant-Id: b4d138ca-1815-4a9b-a3a7-130a33b1e692 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=b4d138ca-1815-4a9b-a3a7-130a33b1e692; Ip=[164.107.81.222]; Helo=[cio-tnc-pf08.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB026 Archived-At: X-Mailman-Approved-At: Fri, 14 Aug 2015 08:02:51 -0700 Cc: "kitten@ietf.org" , Sam Hartman , "saag@ietf.org" , "draft-ietf-kitten-sasl-saml-ec@tools.ietf.org" Subject: Re: [saag] [kitten] SSH Protocol Extensions 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, 13 Aug 2015 13:49:52 -0000 T24gOC8xMi8xNSwgMjozNyBQTSwgIktpdHRlbiBvbiBiZWhhbGYgb2YgTmljbyBXaWxsaWFtcyIg PGtpdHRlbi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBuaWNvQGNyeXB0b25lY3Rvci5j b20+IHdyb3RlOg0KDQo+T24gV2VkLCBBdWcgMTIsIDIwMTUgYXQgMDc6NTQ6MzdQTSArMDIwMCwg U2ltb24gSm9zZWZzc29uIHdyb3RlOg0KPj4gT3IgbG9vayBpbnRvIGFscmVhZHkgcHVibGlzaGVk IFJGQyA2NjE2IGZvciBPcGVuSUQgaW4gU0FTTCBvciBSRkMgNjU5NQ0KPj4gb24gU0FNTCBpbiBT QVNMLiAgU0FNTC1FQyBhdm9pZHMgdGhlIHdlYiBsb29wLCBhbmQgbWF5IGluZGVlZCBiZSBtb3Jl DQo+PiByZWxldmFudCBkZXBlbmRpbmcgb24gdXNlLWNhc2UuDQo+DQo+SWYgUGhpbCBuZWVkcyBh IFNBTUwsIG9uZS1tZXNzYWdlIGF1dGhlbnRpYXRpb24gbWV0aG9kIHdpdGggbm8gcHJvb2Ygb2YN Cj5wb3NzZXNzaW9uLCB0aGVuIGEgbmV3IFNTSHYyIHVzZXJhdXRoIG1ldGhvZCBpcyBwcm9iYWJs eSBiZXN0IChzaW5jZSB0aGUNCj5HU1MgdXNlcmF1dGggbWV0aG9kIHVzZXMgTUlDIHRva2VucyBm b3IgY2hhbm5lbCBiaW5kaW5nKS4gIFdvdWxkIHRoZQ0KPlNBTUwgdG9rZW4gYmUgcG9zc2libGUg dG8gYmluZCB0byBhbiBTU0h2MiBzZXNzaW9uPyAgSSB3b3VsZCBob3BlIHNvLg0KDQpFeGNlcHQg aXQncyBub3QgZGVmaW5lZCBob3cgb25lIHdvdWxkIGFjcXVpcmUgdGhlIHRva2VuLCBhbmQgdGhh dCdzIG5vdCB0cml2aWFsIHRvIGRvIHByb3Blcmx5LiBJZiBTQU1MIElkUHMgZG9uJ3Qgc3VwcG9y dCB0aGUgcHJvZmlsZSwgdGhlbiB5b3UncmUgbm93aGVyZS4gVGhhdCdzIHRoZSBwcm9ibGVtIHRo ZSBzYW1sLWVjIG1lY2hhbmlzbSB3YXMgYXR0YWNraW5nIGZ1bmRhbWVudGFsbHksIHJldXNlIG9m IGFuIGFwcHJvcHJpYXRlIFNBTUwgcHJvZmlsZSB0byBkbyB0aGUgam9iLg0KDQotLSBTY290dA0K DQo= From nobody Fri Aug 14 14:14: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 54E881A8A1C for ; Fri, 14 Aug 2015 14:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wMeCk2ZU6l5 for ; Fri, 14 Aug 2015 14:14:44 -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 C13AF1A8A12 for ; Fri, 14 Aug 2015 14:14:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4951EBE47 for ; Fri, 14 Aug 2015 22:14:42 +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 7rAVcln2P9d6 for ; Fri, 14 Aug 2015 22:14:40 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.22.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C7C03BDCF for ; Fri, 14 Aug 2015 22:14:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439586880; bh=TgPrk9Q82/wo+RRWRtBAjE7U6EdvlNth1OMLM9+OEtQ=; h=Date:From:To:Subject:From; b=iC+9SF2QwPZ8HnhNUpnEk8mcnofzVw0G86nBWPDRGjzoD2CkGReoeyg+hEu6b6/cR LYsnqdGQwyus3R/kdbieCuou1cHsMIIDlGABtuMvQPr8g9n4B3FNEejFmDAdwQg7cJ Y4tbVOdkC7eYJ53UWl4ROfkqYW7a7UnsA8SGfiR4= Message-ID: <55CE5A40.3090804@cs.tcd.ie> Date: Fri, 14 Aug 2015 22:14:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "saag@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 14 Aug 2015 21:14:46 -0000 Hiya, As an FYI, those of you who are interested in cryptographic module APIs would probably be interested in this. [1] (partly copied below.) I'm told the ISO spec is behind a paywall, but haven't gone to look and see if there's a version freely available, so it's hard to know what kind of change this might represent. If someone has more info on that it might be useful to share that here. Cheers, S. []1 http://csrc.nist.gov/news_events/#aug12 ----------- NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules NIST is seeking public comments on using International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) standards for cryptographic algorithm and cryptographic module testing, conformance, and validation activities, currently specified by Federal Information Processing Standard (FIPS) 140-2. The National Technology Transfer and Advancement Act (NTTAA), Public Law 104-113, directs federal agencies to adopt voluntary consensus standards wherever possible. The responses to this request for information (RFI) will be used to plan possible changes to the FIPS or in a decision to use all or part of ISO/IEC 19790:2012, Security Requirements for Cryptographic Modules, for testing, conformance and validation of cryptographic algorithms and modules. The **RFI posted in today’s Federal Register provides additional background information, including seven questions that NIST is especially interested in having addressed, as well as NIST’s intentions. Send public comments to: UseOfISO@nist.gov (also see the address for sending written comments) Comment period closes: September 28, 2015 From nobody Fri Aug 14 15:43:54 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 0FEB31A9026 for ; Fri, 14 Aug 2015 15:43:53 -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 vZI1KcTEfmg5 for ; Fri, 14 Aug 2015 15:43:51 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 7C06E1A9037 for ; Fri, 14 Aug 2015 15:43:51 -0700 (PDT) Received: by wicne3 with SMTP id ne3so32180275wic.1 for ; Fri, 14 Aug 2015 15:43:50 -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=zA7EsOC1ixaIn57y555IpEWhao0hvHwZTz/uQukaOGo=; b=x+216vg3L5GLyQ3OJTxyuXCbn8TcC0b/dNadEsd4LAmH+RG7pMqfIU/DeAY9L3TPZ1 ucD7Mbnou+QYsGtuBj2BnXuQl4gJRS7URQ4gGWst6G79yhuQU4o7fBbXi7nMwBLKc05x e3q+Z0x7LmYHYBgCGa9DovGs2AehsdY47EnCL+OUoFo1HNuNXSyQmC/sL4uWAxYSQQ7G /caUnX6RiBvGqX5pvglgNAFe8/84BccFFKY5Fw+Uhl7UbiAYewbFj7KsHIibacRdYJuW Zh0X3/XxUZWrBh9sxufr+HOkfHvlecwvyoWUUW0+Ky9O9fAn8LaO+Vr9Gobg/N8g8V8h jrQg== MIME-Version: 1.0 X-Received: by 10.180.106.68 with SMTP id gs4mr10419211wib.61.1439592230252; Fri, 14 Aug 2015 15:43:50 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Fri, 14 Aug 2015 15:43:50 -0700 (PDT) Date: Fri, 14 Aug 2015 18:43:50 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Review request - draft-saarinen-blake2 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, 14 Aug 2015 22:43:53 -0000 Hello, draft-saarinen-blake2 is going through the ISE stream and might benefit from a broader review. It would be good to find any nits/issues now as opposed to errata later with the description, algorithm, or code. It describes the cryptographic hash function Blake2, contains algorithms and C code for implementing Blake2, and could be a nice reference to anyone that uses Blake2b or Blake2s in a draft later. It's a well-written draft if that help to entice you into reading it :-) Here is the direct link: https://datatracker.ietf.org/doc/draft-saarinen-blake2/ Thank you! -- Best regards, Kathleen From nobody Sat Aug 15 00:52:54 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 F39D51ACDA9 for ; Sat, 15 Aug 2015 00:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 mN0ECWJHDPXR for ; Sat, 15 Aug 2015 00:52:51 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 E157A1ACDA8 for ; Sat, 15 Aug 2015 00:52:50 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so56857731lbb.0 for ; Sat, 15 Aug 2015 00:52:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/NZajXdNxebbiv7+EGaxDrfsm3CALP842d7A1jY6EL0=; b=froz9toRfjdqZDBNPvuv4I8jpOfy+g3Jx+G1E0r03k7pkNAqVAgD/tKnLKb6tIUwx1 50/7gZPAMssM9xd5VKaaGH1gzHnkWMP9VRGzIoJKr2aaTe4ik6dAGGfZRY9bjuEWrLtL fWirzGj9X9nNz0g9CldytcTj/c9ClI7nJcVGXG3IQBJSa0Lh3+yg+dxVmRzPY+WiJ9nO fQkLD4ywwHwcNJQOWyevjdJQ/A567dLVQiV3f8MNm+pb4vYP9FmvH0fgdTespyQHCw6M CRuD6PC/cFUKUJI94vywn4j+YMxK11Jqv5goXD/+Mg0dHEJaSQiQ7CI9VAmBhI/g02H7 U07A== X-Gm-Message-State: ALoCoQkHIPm0UigQh2xLS3QdwJeZq+VaFrRxvMZ6yPnzZ9lqmVyEqxXXA/OKrtLMU3ZR4WlAYtME MIME-Version: 1.0 X-Received: by 10.112.105.104 with SMTP id gl8mr47269852lbb.81.1439625169250; Sat, 15 Aug 2015 00:52:49 -0700 (PDT) Received: by 10.25.144.193 with HTTP; Sat, 15 Aug 2015 00:52:49 -0700 (PDT) In-Reply-To: <6B7C7317-467A-4809-ABA3-FF599332F18D@osu.edu> References: <20150812195437.2e03c0c8@latte.josefsson.org> <20150812183657.GG3654@localhost> <6B7C7317-467A-4809-ABA3-FF599332F18D@osu.edu> Date: Sat, 15 Aug 2015 08:52:49 +0100 Message-ID: From: Phil Lello To: "Cantor, Scott" Content-Type: multipart/alternative; boundary=001a11347b18d2cd98051d54da5f Archived-At: Cc: Simon Josefsson , "kitten@ietf.org" , "saag@ietf.org" , "draft-ietf-kitten-sasl-saml-ec@tools.ietf.org" , Sam Hartman Subject: Re: [saag] [kitten] SSH Protocol Extensions 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, 15 Aug 2015 07:52:54 -0000 --001a11347b18d2cd98051d54da5f Content-Type: text/plain; charset=UTF-8 Thanks to everyone for their input. I think my efforts would be better directed at extending the SSH protocol to support SASL; although SASL/GSS binding (RFC5801) is possible in some cases, it isn't always. Is there an industry standard for SASL in C? I'm aware of https://tools.ietf.org/html/draft-newman-sasl-c-api-03 from April 2004 and the GSASL http://www.gnu.org/software/gsasl/ library, but am looking for a standard mechanism where adding new SASL mechanisms is a case of adding a run-time plugin (.so / .dll). Phil Lello On Thu, Aug 13, 2015 at 2:48 PM, Cantor, Scott wrote: > On 8/12/15, 2:37 PM, "Kitten on behalf of Nico Williams" < > kitten-bounces@ietf.org on behalf of nico@cryptonector.com> wrote: > > >On Wed, Aug 12, 2015 at 07:54:37PM +0200, Simon Josefsson wrote: > >> Or look into already published RFC 6616 for OpenID in SASL or RFC 6595 > >> on SAML in SASL. SAML-EC avoids the web loop, and may indeed be more > >> relevant depending on use-case. > > > >If Phil needs a SAML, one-message authentiation method with no proof of > >possession, then a new SSHv2 userauth method is probably best (since the > >GSS userauth method uses MIC tokens for channel binding). Would the > >SAML token be possible to bind to an SSHv2 session? I would hope so. > > Except it's not defined how one would acquire the token, and that's not > trivial to do properly. If SAML IdPs don't support the profile, then you're > nowhere. That's the problem the saml-ec mechanism was attacking > fundamentally, reuse of an appropriate SAML profile to do the job. > > -- Scott > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a11347b18d2cd98051d54da5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks to everyone for their input. I think my e= fforts would be better directed at extending the SSH protocol to support SA= SL; although SASL/GSS binding (RFC5801) is possible in some cases, it isn&#= 39;t always.

Is there an industry standard for SASL in C? I= 9;m aware of https://tools.ietf.org/html/draft-newman-sasl-c-api-03 from April = 2004 and the GSASL http://ww= w.gnu.org/software/gsasl/ library, but am looking for a standard mechan= ism where adding new SASL mechanisms is a case of adding a run-time plugin = (.so / .dll).

Phil Lello

On Thu, Aug 13, 2015 at 2:48 PM, C= antor, Scott <cantor.2@osu.edu> wrote:
On 8/12/15, 2:37 PM, "Kitten on behalf = of Nico Williams" <kitte= n-bounces@ietf.org on behalf of nico@cryptonector.com> wrote:

>On Wed, Aug 12, 2015 at 07:54:37PM +0200, Simon Josefsson wrote:
>> Or look into already published RFC 6616 for OpenID in SASL or RFC = 6595
>> on SAML in SASL.=C2=A0 SAML-EC avoids the web loop, and may indeed= be more
>> relevant depending on use-case.
>
>If Phil needs a SAML, one-message authentiation method with no proof of=
>possession, then a new SSHv2 userauth method is probably best (since th= e
>GSS userauth method uses MIC tokens for channel binding).=C2=A0 Would t= he
>SAML token be possible to bind to an SSHv2 session?=C2=A0 I would hope = so.

Except it's not defined how one would acquire the token, and tha= t's not trivial to do properly. If SAML IdPs don't support the prof= ile, then you're nowhere. That's the problem the saml-ec mechanism = was attacking fundamentally, reuse of an appropriate SAML profile to do the= job.

-- Scott

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--001a11347b18d2cd98051d54da5f-- From nobody Sat Aug 15 01:23: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 DFF781ACDD4 for ; Sat, 15 Aug 2015 01:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 6UBS_COdad5v for ; Sat, 15 Aug 2015 01:23:09 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 B3DE81ACDD3 for ; Sat, 15 Aug 2015 01:23:08 -0700 (PDT) Received: by lagz9 with SMTP id z9so55055517lag.3 for ; Sat, 15 Aug 2015 01:23:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Dn20vNsEFBjq6sgtGCFslsFOd1GozIR/PiS+qX2FQbU=; b=ZjnLNS4/PZZKklBB+rkX45ixD0pougHPo+HQ34dYOC6RpLXFseA5ckTQsr0FxEakZy E/R/w1Cf8hDLej/iDvoUq9mQ3Td3bx0ZmWVXKIlEFjkLCnZU9PUv14o86AoCRta5osnF v5khE2BGch1ST7CqldXJPNHN2UB+8CXgxZqXmeE2BgIYvTHp0nXKm3o98vyXONmfFPda KXG4ozre8nwmRMnU1AZlqZK4H5c+Wi7YeOXuPyXeGD1mIbN8ZQBqqCqGC+PfWcFeLqeF BKd13ColOp7rOl7qvNp3YDZrc0LtYk4noGCB89Og+zBG4AdcO5RXJKHGTcHIgzdy8p9d go0g== X-Gm-Message-State: ALoCoQnBdHuPN5SYZ1KnG1xhwlfA3EpzhkBpqPPKLC0K9yfLn8dUEuI6mxoZ0WhMYWW0uRsiCZpD MIME-Version: 1.0 X-Received: by 10.152.2.41 with SMTP id 9mr47865010lar.65.1439626986969; Sat, 15 Aug 2015 01:23:06 -0700 (PDT) Received: by 10.25.144.193 with HTTP; Sat, 15 Aug 2015 01:23:06 -0700 (PDT) In-Reply-To: <55CE5A40.3090804@cs.tcd.ie> References: <55CE5A40.3090804@cs.tcd.ie> Date: Sat, 15 Aug 2015 09:23:06 +0100 Message-ID: From: Phil Lello To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e013c62582b0036051d554710 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 15 Aug 2015 08:23:11 -0000 --089e013c62582b0036051d554710 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not in the US or trading with US companies, so presumably not affected, but the paywall alone sounds like a reasonable grounds to object to me - it prevents reasonable review by people with no reason to buy the standard, and presumably also creates a smaller pool of suppliers (since it will eliminate those who don't buy the spec). On Fri, Aug 14, 2015 at 10:14 PM, Stephen Farrell wrote: > > Hiya, > > As an FYI, those of you who are interested in cryptographic > module APIs would probably be interested in this. [1] (partly > copied below.) > > I'm told the ISO spec is behind a paywall, but haven't gone > to look and see if there's a version freely available, so > it's hard to know what kind of change this might represent. > If someone has more info on that it might be useful to > share that here. > > Cheers, > S. > > []1 http://csrc.nist.gov/news_events/#aug12 > > > ----------- > > NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal > Standard for cryptographic modules > > NIST is seeking public comments on using International Organization for > Standardization/International Electrotechnical Commission (ISO/IEC) > standards for cryptographic algorithm and cryptographic module testing, > conformance, and validation activities, currently specified by Federal > Information Processing Standard (FIPS) 140-2. The National Technology > Transfer and Advancement Act (NTTAA), Public Law 104-113, directs > federal agencies to adopt voluntary consensus standards wherever > possible. The responses to this request for information (RFI) will be > used to plan possible changes to the FIPS or in a decision to use all or > part of ISO/IEC 19790:2012, Security Requirements for Cryptographic > Modules, for testing, conformance and validation of cryptographic > algorithms and modules. > > The **RFI posted in today=E2=80=99s Federal Register provides additional > background information, including seven questions that NIST is > especially interested in having addressed, as well as NIST=E2=80=99s inte= ntions. > > Send public comments to: UseOfISO@nist.gov (also see the address for > sending written comments) > > Comment period closes: September 28, 2015 > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --089e013c62582b0036051d554710 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not in the US or trading with US companies, so pre= sumably not affected, but the paywall alone sounds like a reasonable ground= s to object to me - it prevents reasonable review by people with no reason = to buy the standard, and presumably also creates a smaller pool of supplier= s (since it will eliminate those who don't buy the spec).

On Fri, Aug 14, 2015 = at 10:14 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

As an FYI, those of you who are interested in cryptographic
module APIs would probably be interested in this. [1] (partly
copied below.)

I'm told the ISO spec is behind a paywall, but haven't gone
to look and see if there's a version freely available, so
it's hard to know what kind of change this might represent.
If someone has more info on that it might be useful to
share that here.

Cheers,
S.

[]1 http://csrc.nist.gov/news_events/#aug12


-----------

NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal
Standard for cryptographic modules

NIST is seeking public comments on using International Organization for
Standardization/International Electrotechnical Commission (ISO/IEC)
standards for cryptographic algorithm and cryptographic module testing,
conformance, and validation activities, currently specified by Federal
Information Processing Standard (FIPS) 140-2. The National Technology
Transfer and Advancement Act (NTTAA), Public Law 104-113, directs
federal agencies to adopt voluntary consensus standards wherever
possible. The responses to this request for information (RFI) will be
used to plan possible changes to the FIPS or in a decision to use all or part of ISO/IEC 19790:2012, Security Requirements for Cryptographic
Modules, for testing, conformance and validation of cryptographic
algorithms and modules.

The **RFI posted in today=E2=80=99s Federal Register provides additional background information, including seven questions that NIST is
especially interested in having addressed, as well as NIST=E2=80=99s intent= ions.

=C2=A0Send public comments to: UseOfIS= O@nist.gov (also see the address for
sending written comments)

Comment period closes: September 28, 2015

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--089e013c62582b0036051d554710-- From nobody Sat Aug 15 04:24: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 BDC0A1B2E49 for ; Sat, 15 Aug 2015 04:24:17 -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 hYM7WtqRb2km for ; Sat, 15 Aug 2015 04:24:16 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 D91F11B2E48 for ; Sat, 15 Aug 2015 04:24:15 -0700 (PDT) Received: by iodv127 with SMTP id v127so92577342iod.3 for ; Sat, 15 Aug 2015 04:24:15 -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=5RIIqT75A9Lb/lIm9JhOcAUSrJkdUrhckbe1poa++bY=; b=hOH51NPmXRfX0Cq9Y52KRDsAdBBZ5IjOdP4fxJZfZdoXLxnt/JmagwhzKdzw75Fmr9 JWgXTImmWHdZvGECfBZZiXHRMIVYnHA3orM3J3Jm62r3wCKTmcrA8xpiyzwnxb+9EMnJ JB8jA9bX1J7CFi9UePLhpqopRMkDAHkO4NH19UshNxYw7ZyS8uN0xGQ7dwRUyvfaQCZ2 e6zQrjxc7o2AdxZT4R1AGpLkYS9qF8TPg4BCIR7jp9Jisx1JrqM1FYKcrEhHmaqUxfJe xXHvCaCnFVY2ihAmREr6ATg82yOlGwb69jdC29FJz8Dndji7MKKzVNYP42cCYpQGM7Cg h4lQ== MIME-Version: 1.0 X-Received: by 10.107.155.12 with SMTP id d12mr55711036ioe.131.1439637855360; Sat, 15 Aug 2015 04:24:15 -0700 (PDT) Received: by 10.107.175.141 with HTTP; Sat, 15 Aug 2015 04:24:15 -0700 (PDT) In-Reply-To: References: <55CE5A40.3090804@cs.tcd.ie> Date: Sat, 15 Aug 2015 07:24:15 -0400 Message-ID: From: David Lloyd-Jones To: Stephen Farrell , phil@dunlop-lello.uk Content-Type: multipart/alternative; boundary=001a1141b9d6f95c42051d57cee0 Archived-At: Cc: saag@ietf.org Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 15 Aug 2015 11:24:17 -0000 --001a1141b9d6f95c42051d57cee0 Content-Type: text/plain; charset=UTF-8 Stephen, None of http://csrc.nist.gov/news_events/#aug12 http://csrc.nist.gov/publications/PubsFIPS.html#140-2 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=52906 http://www.iso.org/iso/catalogue_detail.htm?csnumber=52906 is behind a paywall. What is it you have "heard," Stephen, that has given Phil this avalanche of "reason to object"? I wouldn't be surprised if some of the documentation within those catalogues costs money. There was a time in the early days of Oracle when the docs for their basic database software cost US$6,000. I paid US$92 for my IBM equivalent a few years ago, but these are not paywalls. They are costs of operating docs. (I suspect that that $6,000 was because Larry knew he was working the American taxpayer over just one time, and in 1983 that was still real money to him: gas for the motorbike, not the jet.) Is it a question of that sort of thing? Parenthetically, I notice that the correspondence thread "Information Security" over on Google+ has recently fractured in two, I would guess because the main feed is full of juvenile ranting. -dlj. On 15 August 2015 at 04:23, Phil Lello wrote: > I'm not in the US or trading with US companies, so presumably not > affected, but the paywall alone sounds like a reasonable grounds to object > to me - it prevents reasonable review by people with no reason to buy the > standard, and presumably also creates a smaller pool of suppliers (since it > will eliminate those who don't buy the spec). {snipped} > --001a1141b9d6f95c42051d57cee0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephen,
=C2=A0
None of=C2=A0htt= p://csrc.nist.gov/news_events/#aug12

is behind a paywall.

What is it you have &= quot;heard," Stephen, that has given Phil this avalanche of "reas= on to object"?
=C2=A0
I wouldn't be surprised = if some of the documentation within those catalogues costs money.=C2=A0 The= re was a time in the early days of Oracle when the docs for their basic dat= abase software cost US$6,000.=C2=A0 I paid US$92 for my IBM equivalent a fe= w years ago, but these are not paywalls.=C2=A0 They are costs of operating = docs. =C2=A0

(I suspect that that $6,000 was becau= se Larry knew he was working the American taxpayer over just one time, and = in 1983 that was still real money to him: gas for the motorbike, not the je= t.)

Is it a question of that sort of thing?
<= div>
Parenthetically, I notice that the correspondence thread= "Information Security" over on Google+ has recently fractured in= two, I would guess because the main feed is full of juvenile ranting.
=C2=A0
-dlj.
=C2=A0
=C2=A0

On 15 August 2015 at 04:= 23, Phil Lello <phil@dunlop-lello.uk> wrote:
I'm not in the US or trading wit= h US companies, so presumably not affected, but the paywall alone sounds li= ke a reasonable grounds to object to me - it prevents reasonable review by = people with no reason to buy the standard, and presumably also creates a sm= aller pool of suppliers (since it will eliminate those who don't buy th= e spec). {snipped}
--001a1141b9d6f95c42051d57cee0-- From nobody Sat Aug 15 04:31:16 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 F3C391B2E55 for ; Sat, 15 Aug 2015 04:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hht8gi49C7Cs for ; Sat, 15 Aug 2015 04:31:12 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0649.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::649]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC741B2E53 for ; Sat, 15 Aug 2015 04:31:11 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.1.231.21; Sat, 15 Aug 2015 11:31:08 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0231.021; Sat, 15 Aug 2015 11:31:08 +0000 From: "Paterson, Kenny" To: David Lloyd-Jones Thread-Topic: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules Thread-Index: AQHQ1tZGPR3gW81L/E+kkoHmSC1pRJ4MuYwAgAAynICAAAHtwg== Date: Sat, 15 Aug 2015 11:31:08 +0000 Message-ID: <912ED439-7FE4-469C-AB32-AC7B2E32BE9F@rhul.ac.uk> References: <55CE5A40.3090804@cs.tcd.ie> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [85.255.232.198] x-microsoft-exchange-diagnostics: 1; DBXPR03MB383; 5:WSELZAJ0qDEdYRigTMSkHVhqb0wLcxcGBklc9WQVP7/6abAwsBl8VwSdLQj/MlNyOHyg8prHcI/eIKUa1d2fB5ykRgstK5qPVIRw8XqIAYisRsRodPzfJh+6PYLhEd0hugnG2OzgSdhBeNmRsjbuiQ==; 24:JO18FRArd4SLrdbkV23iRmtNXqF7VXdavyVdu/jrjDDvipIgs7dQrcBOAn7hBJ+Fkp52yo6mt+vov+c0LPmeVjc+WqQhp2s+XMrrBnS0koo=; 20:uNXk1VJUd8qatEY0VgKZxow4sVUr+r9tK6xbtFJbdKXXSxL3Shmougqik9Sk60KHihDBAVVCanKdRgDEaNWxeQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB383; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501041)(5005006)(3002001); SRVR:DBXPR03MB383; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB383; x-forefront-prvs: 06691A4183 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(124975003)(189002)(199003)(24454002)(97736004)(62966003)(106356001)(106116001)(105586002)(68736005)(189998001)(66066001)(64706001)(5002640100001)(122556002)(36756003)(19617315012)(10400500002)(110136002)(5001960100002)(2656002)(92566002)(33656002)(101416001)(82746002)(77096005)(86362001)(102836002)(15975445007)(46102003)(2950100001)(83716003)(87936001)(2900100001)(74482002)(54356999)(76176999)(5001860100001)(50986999)(5001920100001)(19580395003)(40100003)(19580405001)(77156002)(4001540100001)(5001830100001)(81156007)(16236675004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_912ED4397FE4469CAB32AC7B2E32BE9Frhulacuk_" MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2015 11:31:08.1743 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB383 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 15 Aug 2015 11:31:15 -0000 --_000_912ED4397FE4469CAB32AC7B2E32BE9Frhulacuk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Err, no. ISO documents are notorious for not being free. In this case, the = asking price is 178 Swiss Francs. Not exorbitant but not free either. (Yeah= , it's free to read the abstract.) Kenny On 15 Aug 2015, at 12:24, David Lloyd-Jones > wrote: Stephen, None of http://csrc.nist.gov/news_events/#aug12 http://csrc.nist.gov/publications/PubsFIPS.html#140-2 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumbe= r=3D52906 http://www.iso.org/iso/catalogue_detail.htm?csnumber=3D52906 is behind a paywall. What is it you have "heard," Stephen, that has given Phil this avalanche of= "reason to object"? I wouldn't be surprised if some of the documentation within those catalogue= s costs money. There was a time in the early days of Oracle when the docs = for their basic database software cost US$6,000. I paid US$92 for my IBM e= quivalent a few years ago, but these are not paywalls. They are costs of o= perating docs. (I suspect that that $6,000 was because Larry knew he was working the Ameri= can taxpayer over just one time, and in 1983 that was still real money to h= im: gas for the motorbike, not the jet.) Is it a question of that sort of thing? Parenthetically, I notice that the correspondence thread "Information Secur= ity" over on Google+ has recently fractured in two, I would guess because t= he main feed is full of juvenile ranting. -dlj. On 15 August 2015 at 04:23, Phil Lello > wrote: I'm not in the US or trading with US companies, so presumably not affected,= but the paywall alone sounds like a reasonable grounds to object to me - i= t prevents reasonable review by people with no reason to buy the standard, = and presumably also creates a smaller pool of suppliers (since it will elim= inate those who don't buy the spec). {snipped} _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_000_912ED4397FE4469CAB32AC7B2E32BE9Frhulacuk_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Err, no. ISO documents are notorious for not being free. In this case,= the asking price is 178 Swiss Francs. Not exorbitant but not free either. = (Yeah, it's free to read the abstract.)

Kenny

On 15 Aug 2015, at 12:24, David Lloyd-Jones <david.lloydjones@gmail.com> wrote:

Stephen,
 
None of 
http:= //csrc.nist.gov/news_events/#aug12

is behind a paywall.

What is it you have "heard," Stephen, that has given Phil th= is avalanche of "reason to object"?
 
I wouldn't be surprised if some of the documentation within those cata= logues costs money.  There was a time in the early days of Oracle when= the docs for their basic database software cost US$6,000.  I paid US$= 92 for my IBM equivalent a few years ago, but these are not paywalls.  They are costs of operating docs.  =

(I suspect that that $6,000 was because Larry knew he was working the = American taxpayer over just one time, and in 1983 that was still real money= to him: gas for the motorbike, not the jet.)

Is it a question of that sort of thing?

Parenthetically, I notice that the correspondence thread "Informa= tion Security" over on Google+ has recently fractured in two, I wo= uld guess because the main feed is full of juvenile ranting.
 
-dlj.
 
 

On 15 August 2015 at 04:23, Phil Lello <phil= @dunlop-lello.uk> wrote:
I'm not in the US or trading with US companies, so presuma= bly not affected, but the paywall alone sounds like a reasonable grounds to= object to me - it prevents reasonable review by people with no reason to b= uy the standard, and presumably also creates a smaller pool of suppliers (since it will eliminate those who don= 't buy the spec). {snipped}
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ie= tf.org/mailman/listinfo/saag
--_000_912ED4397FE4469CAB32AC7B2E32BE9Frhulacuk_-- From nobody Sat Aug 15 05:51:03 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 5DF881A88C5 for ; Sat, 15 Aug 2015 05:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqPscsZFsrGe for ; Sat, 15 Aug 2015 05:51:01 -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 4E0F71A88D0 for ; Sat, 15 Aug 2015 05:51:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1B0F8BE79; Sat, 15 Aug 2015 13:51: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 QxDjsozYoVm7; Sat, 15 Aug 2015 13:50:59 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.22.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EBFCBBE73; Sat, 15 Aug 2015 13:50:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439643059; bh=u8DmMut8ceb1lz5suJMgN2vahfSXqTiUyqz4zyTT8a4=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=ErPbwO9/C51Q9/Odoxnw9+y7CjGDRvUcgqgO9O7mAn9SoD5ldfCjAh5+dAKSTNEd6 nnNHBEJ+vIaECqUIrUrq3W7GE2AgEGgoG2gjSDNVONOfG/me/3Q6i6VOfElO/hKX9A eTz+dgthKXxQTeZHfL7oGSbJa7NgPt3gFomT9R5k= Message-ID: <55CF35B2.9020302@cs.tcd.ie> Date: Sat, 15 Aug 2015 13:50:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: David Lloyd-Jones , phil@dunlop-lello.uk References: <55CE5A40.3090804@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: saag@ietf.org Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 15 Aug 2015 12:51:02 -0000 On 15/08/15 12:24, David Lloyd-Jones wrote: > What is it you have "heard," Stephen, that has given Phil this avalanche of > "reason to object"? I already said that I have been told that the ISO spec is behind a paywall, that is all. And now I've said it twice:-) Whether or not that's a deal for folks who've previously been willing to subject themselves to FIPS140 fun is a reasonable question. But it's also reasonable to point out that that is a barrier to broad, open review. And of course, if you care about any of this, then telling NIST what you think is the correct action. S. From nobody Sun Aug 16 21:33: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 C42331A0397 for ; Sun, 16 Aug 2015 21:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSD5Uq6u_DxL for ; Sun, 16 Aug 2015 21:33:18 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 C77DF1A038E for ; Sun, 16 Aug 2015 21:33:17 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so74567189lbb.3 for ; Sun, 16 Aug 2015 21:33:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WdOi5+tEa6h/Je+EHrTpwErIniwYnhMBMR2mVfMD300=; b=ZMRN5Z6At1ZarZlwO5OYlxD/WeZ3m227yNU6yx8ZZ9UoS5OJCQUo/kF9LoKBJJMfaj Ozs5mw88ispl3qTPPkp0d9DPOBcloX9J+t/OBIMvHr5yl+3mIqX7zUayTFkMBtS0k7s7 O9ui462tCZn43Yq7AEQjiEhzDvV2Yw6YIsnuKboxtgAgCtEoL0iVQglsR87e+3+EOjex ezLpTmqF8z6SkW+e2pMaDWJWPI4z9JBp+/TCkDnnbHYTawyVNbNM8V7rPvrtWfp/6EEf t8a3SzXF9sbWFb/JT16nlY/ATjTpbh0qbCBqR/1ljPK/O7KVzSUskzvQkWqxFu/umanT GkUQ== X-Gm-Message-State: ALoCoQkEyiDdWJiSHGd1MzSHdSC4ATBMkYdmf2WFq/MeC55m8OjIr824ViMiI8gKZzButE0kjBum MIME-Version: 1.0 X-Received: by 10.112.142.196 with SMTP id ry4mr54085692lbb.68.1439785996265; Sun, 16 Aug 2015 21:33:16 -0700 (PDT) Received: by 10.112.122.17 with HTTP; Sun, 16 Aug 2015 21:33:16 -0700 (PDT) In-Reply-To: <449964e467e0347db185eb787db71efd.squirrel@www.trepanning.net> References: <449964e467e0347db185eb787db71efd.squirrel@www.trepanning.net> Date: Sun, 16 Aug 2015 21:33:16 -0700 Message-ID: From: Joseph Salowey To: Dan Harkins Content-Type: multipart/alternative; boundary=089e0112bf7edc4370051d7a4ce2 Archived-At: Cc: Sam Hartman , "saag@ietf.org" , "emu@ietf.org" Subject: Re: [saag] Feedback on Salted EAP draft 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, 17 Aug 2015 04:33:19 -0000 --089e0112bf7edc4370051d7a4ce2 Content-Type: text/plain; charset=UTF-8 Hi Dan, I read the latest version of the draft (-02) and it looks mostly good to me. some comments: I think you want to change the RFC references in the abstract from RFC 2751 to RFC 2759. One question I have is there any reason why you specify the input of the hash function as password | salt instead of the other way around? Is this the way it is done in practice? Thanks, Joe On Thu, Aug 13, 2015 at 2:35 PM, Dan Harkins wrote: > > Hi Christian, > > On Tue, July 14, 2015 10:50 am, Christian Huitema wrote: > [snip] > > The draft is short and clear enough, but it acknowledges a pretty big > > security issue: "the salted > > password from a compromised database can be used directly to impersonate > > the client-- there > > is no dictionary attack needed to recover the plaintext password." > > > > That's a pretty big caveat, but there are still some advantages over > > operating with unsalted passwords. The draft aligns server side password > > management for EAP-pwd with standard industry practices, which is good. > > In case of server compromise, the immediate effect of the compromise is > an > > attack on the already compromised server, and the per-user salt make > > password discovery harder. The security section should be expanded to > > explain this tradeoff. > > Yes, it's a big caveat and, as I mentioned, I'm trying to > be as blunt as possible about it. I have updated the Security > Considerations to include the point you are making about server > compromise and the per-user salt still making password recovery > harder. > > > Nits: > > > > - in the abstract, missing "not" in " but did (not?) include support for > > salted passwords." > > Nice catch. > > An -02 version has been posted. Would you please take a look > and let me know whether it satisfactorily addresses your comments? > > regards, > > Dan. > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --089e0112bf7edc4370051d7a4ce2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dan,

I read the latest version of th= e draft (-02) and it looks mostly good to me. =C2=A0 some comments:

I think you want to change the RFC references in the abst= ract from RFC 2751 to RFC 2759. =C2=A0

One questio= n I have is there any reason why you specify the input of the hash function= as password | salt instead of the other way around?=C2=A0 Is this the way = it is done in practice? =C2=A0

Thanks,
<= br>
Joe

On Thu, Aug 13, 2015 at 2:35 PM, Dan Harkins = <dharkins@loung= e.org> wrote:

=C2=A0 Hi Christian,

On Tue, July 14, 2015 10:50 am, Christian Huitema wrote:
[snip]
> The draft is short and clear enough, but it acknowled= ges a pretty big
> security issue: "the salted
> password from a compromised database can be used directly to impersona= te
> the client-- there
> is no dictionary attack needed to recover the plaintext password."= ;
>
> That's a pretty big caveat, but there are still some advantages ov= er
> operating with unsalted passwords. The draft aligns server side passwo= rd
> management for EAP-pwd=C2=A0 with standard industry practices, which i= s good.
> In case of server compromise, the immediate effect of the compromise i= s an
> attack on the already compromised server, and the per-user salt make > password discovery harder. The security section should be expanded to<= br> > explain this tradeoff.

=C2=A0 Yes, it's a big caveat and, as I mentioned, I'm tryin= g to
be as blunt as possible about it. I have updated the Security
Considerations to include the point you are making about server
compromise and the per-user salt still making password recovery
harder.

> Nits:
>
> - in the abstract, missing "not" in " but did (not?) in= clude support for
> salted passwords."

=C2=A0 Nice catch.

=C2=A0 An -02 version has been posted. Would you please take a look
and let me know whether it satisfactorily addresses your comments?

=C2=A0 regards,

=C2=A0 Dan.


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--089e0112bf7edc4370051d7a4ce2-- From nobody Mon Aug 17 08:18: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 B32F91A88E4 for ; Fri, 14 Aug 2015 09:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf40Jp1G93-v for ; Fri, 14 Aug 2015 09:47:34 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289931A88DE for ; Fri, 14 Aug 2015 09:47:34 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.199.108; From: "Susan Hares" To: References: In-Reply-To: Date: Fri, 14 Aug 2015 12:47:28 -0400 Message-ID: <010901d0d6b0$e82fcfa0$b88f6ee0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010A_01D0D68F.6121B210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMJDnzX0R9xXAXNq+IUI0T2muLIlZubQX4g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Mon, 17 Aug 2015 08:18:07 -0700 Cc: 'Jeffrey Haas' , 'Alia Atlas' Subject: [saag] FW: Urgent need for a person from the security directorate to review key pionts in I2RS security 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, 14 Aug 2015 16:47:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010A_01D0D68F.6121B210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Security directorate: I need help rather urgently. The I2RS and the NETCONF WGs are collaborating to create the I2RS protocol. The design team will begin its work next week (8/17) so I need someone who can help for the next 2 weeks. We really need a security person to help us for the next few weeks to determine what are necessary security requirements for this protocol. I am willing to provide tutorial and information for the security person. NETCONF reviewers have suggested that some of the I2RS security requirements are unclear or "not security" requirements. The NETCONF reviewers have also suggested that the optional insecure transport for non-configuration data) will not be approved by the security ADs or reviewers. Rather that both groups arguing over what they think a security reviewer will say - we'd like a person from the security directorate to speak for the security area. The security directorate has really help us in forming our work. We had a great security review on the I2RS architecture in December 2014/January 2015 from Tero Kivinen (kivinen@iki.fi) Also our GEN-ART review from Russ Housley also suggested issues. After these issues we split our security work into wire-protocol security and environment security. We need help to determine that we have split the work correctly. We are heading into WG adoption call on these drafts next week. The details are in the message below I sent to Kathleen and Stephen. However, I recalled that last time I also need to send email to saag group that helped me get a reviewer. Sue Hares I2RS co-chair. From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, August 14, 2015 11:59 AM To: 'Kathleen Moriarty'; 'Stephen Farrell' Cc: 'Alia Atlas' Subject: Urgent need for a person from the security directorate to review key pionts in I2RS security Kathleen and Stephen: I sent you a request at IETF that we need a security person from the security directorate to review the following I2RS security drafts. http://datatracker.ietf.org/doc/draft-hares-i2rs-auth-trans/ http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requirements/ and a revision of http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requirements/ Perhaps you will recall I mentioned this to you on Friday of IETF. My need has turned from urgent (in July) to "very urgent" as we start I2RS-netconf design team to work on the I2RS protocol design next week. Would you please find some who can advise me from the security directorate? The details are below. Sue Hares ------------------ Document 1) http://datatracker.ietf.org/doc/draft-hares-i2rs-auth-trans/ We had editorial feedback on requirements 3 and 4 that these requirement need clarification, and requirement 10 is ambiguous. We would like feedback on what the security person on this need for editorial review, and review of the alternate text. In this document, we have feedback from Netconf that Requirement 8 and 12 are not security requirements. . SEC-REQ-08: Each Identity is associated with one secondary identity during a particular read/write sequence, but the secondary identity may vary during the time a connection between the I2RS client and I2RS agent is active. The variance of the secondary identity allows the I2rs client to be associated with multiple applications and pass along an identifier for these applications in the secondary identifier. . SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement mechanisms that mitigate DoS attacks Our input from the Ericsson network security is the mitigation of DDos was important. Also, the I2RS protocol will have a multiple message sequence in which the local system can: 1. Perform all or none: All operations succeed or none of them will be applied. This useful when there are mutual dependencies. 2. Perform until error: Operations are applied in order, and when error occurs the processing stops. This is useful when dependencies exist between multiple-message operations, and order is important. 3. Perform all storing errors: Perform all actions storing error indications for errors. This method can be used when there are no dependencies between operations, and the client wants to sort it out. Is the ability to do impact security? If so, we need to craft this work. If not, we will pull this from the security section. Lastly, the I2RS group early in its architecture decided that it was important to provide some information via an insecure connection. Publishing information via an insecure connection must consider the information and the context. This insecure data was going to be used to provide global information that ISPs would want to publish to public from a router. The architecture document: http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ I will be calling for the I2RS WG to reconsider the insecure connection, but I suspect the I2RS WG will want the secure connection. I need a person from the security directorate to discuss the issues with during the WG call regarding the insecure connection. Unless there is overwhelming agreement to get rid of the insecure connection, the I2RS chairs and AD are likely to keep it in. Document 2) http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requirements/ This draft considers the security environment that the I2RS operates within. The security review in December 2014 indicated several comments that led us to work on a security environment draft. ------=_NextPart_000_010A_01D0D68F.6121B210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Security directorate:

 

I need help rather = urgently.  The I2RS and the NETCONF WGs are collaborating to create = the I2RS protocol.  The design team will begin its work next week = (8/17) so I need someone who can help for the next 2 weeks.  We = really need a security person to help us for the next few weeks to = determine what are necessary security requirements for this = protocol.   I am willing to provide tutorial and information = for the security person.

 

NETCONF reviewers have = suggested that some of the I2RS security requirements are unclear or = “not security” requirements.  The NETCONF reviewers = have also suggested that the optional insecure transport for = non-configuration data) will not be approved by the security ADs or = reviewers.  Rather that both groups arguing over what they think a = security reviewer will say – we’d like a person from the = security directorate to speak for the security area. =

 

The security directorate = has really help us in forming our work.  We had a great security = review on the I2RS architecture in December 2014/January 2015 from Tero = Kivinen (kivinen@iki.fi) Also our = GEN-ART review from Russ Housley also suggested issues.  After = these issues we split our security work into wire-protocol security and = environment security.  We need help to determine that we have split = the work correctly.  We are heading into WG adoption call on these = drafts next week.

 

The details are in the = message below I sent to Kathleen and Stephen.  However, I recalled = that last time I also need to send email to saag group that helped me = get a reviewer.

 

Sue = Hares

I2RS co-chair.

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Friday, August 14, = 2015 11:59 AM
To: 'Kathleen Moriarty'; 'Stephen = Farrell'
Cc: 'Alia Atlas'
Subject: Urgent need for a = person from the security directorate to review key pionts in I2RS = security

 

Kathleen and = Stephen:

 

I sent you a request at IETF that we need a security = person from the security directorate to review the following I2RS = security drafts.

 

htt= p://datatracker.ietf.org/doc/draft-hares-i2rs-auth-trans/<= /p>

http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requireme= nts/

and a revision of =

http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requireme= nts/

 

Perhaps you will recall I mentioned this to you on = Friday of IETF.  My need has turned from urgent (in July) to = “very urgent” as we start I2RS-netconf design team to work = on the  I2RS protocol design next week.   Would you = please find some who can advise me from the security directorate? =  The details are below.

 

Sue Hares =

------------------

 

Document = 1)  htt= p://datatracker.ietf.org/doc/draft-hares-i2rs-auth-trans/<= /p>

 

We had = editorial feedback on requirements 3 and 4 that these requirement need = clarification, and requirement 10 is ambiguous.  We would like = feedback on what the security person on this need for editorial review, = and

review of the alternate text. =

 

In this document, we have feedback from Netconf that = Requirement 8 and 12 are not security requirements.

 

·         = SEC-REQ-08: Each Identity is associated with one = secondary

identity = during a particular read/write sequence, but the

    secondary identity may vary during = the time a connection between

    the I2RS client and I2RS agent is = active.  The variance of the

    secondary identity allows the I2rs = client to be associated with

    multiple applications and pass = along an identifier for these

    applications in the secondary = identifier.

 

·         =
SEC-REQ-12: The I2RS Client and =
I2RS Agent protocol SHOULD implement
   mechanisms that =
mitigate DoS attacks

 

Our input = from the Ericsson network security is the mitigation of DDos was = important.

 

Also, the I2RS protocol will have a multiple message = sequence in which the local system can: 

   1.  Perform all or none: All =
operations succeed or none of them will
      =
; be applied.  This useful when there are mutual =
dependencies.
 
   2.  Perform =
until error: Operations are applied in order, and =
when
      =
; error occurs the processing stops.  This is useful =
when
      =
; dependencies exist between multiple-message operations, and =
order
      =
; is important.
 
   3.  Perform all =
storing errors: Perform all actions storing =
error
      =
; indications for errors.  This method can be used when there =
are
      =
; no dependencies between operations, and the client wants to =
sort
      =
; it out.

 

Is the = ability to do impact security?  If so, we need to craft this work. =

If not, we will pull this from the = security section.

 

Lastly, the = I2RS group early in its architecture decided that it was important to = provide some information via an insecure connection.  Publishing = information via an insecure connection must consider the information and = the context.  This insecure data was going to be used to provide = global information that ISPs would want to publish to public from a = router.

 

The architecture document:

ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/

 

I = will be calling for the I2RS WG to reconsider the insecure connection, = but I suspect the I2RS WG will want the secure connection.   I = need a person from the security directorate to discuss the issues with = during the WG call regarding the insecure connection.   Unless = there is overwhelming agreement to get rid of the insecure connection, = the I2RS chairs and AD are likely to keep it in.

 

Document 2) = http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requireme= nts/

 

This draft considers the security environment that the = I2RS operates within.  The security review in December 2014 = indicated several comments that led us to work on a security environment = draft.

 

 

 

 

 

 

------=_NextPart_000_010A_01D0D68F.6121B210-- From nobody Mon Aug 17 09:21: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 0EAE41ACE17 for ; Mon, 17 Aug 2015 09:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 3fZqWjShhpAk for ; Mon, 17 Aug 2015 09:21:40 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 D6D571A8925 for ; Mon, 17 Aug 2015 09:21:39 -0700 (PDT) Received: by qkcs67 with SMTP id s67so48374405qkc.1 for ; Mon, 17 Aug 2015 09:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pjB/jZR1VdBJ0xD1iQ/CYm9Y22aPJXzWl64uMeTRCSo=; b=Vagi7wXBJRi9x018RHGUCrk5mqZoUjfgwEQOutMWvMMFhwFhSzgOq4uoQ/0kDQnRoq GimhTHncr8kOtuwlGtnBDLA6rJRrfUwCNbU/Gq3y9JY+agmO04QHL/x5WJ/+J0Iq8vTP OYGJyKw/zf30O9Txse2p/6F8SgH/k9py/gw2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pjB/jZR1VdBJ0xD1iQ/CYm9Y22aPJXzWl64uMeTRCSo=; b=RL39gr/nCZEM1RiEg296aKIw4jTULz7IbnIKNcpBjcoPBRSppF9tI1YoEwC29ayMFf gio2lZfDVqyRtr2JXbCgbvdoEIWzLw/Y3TIGfHjM3vqeD1opQxuvVypF03c2ym8guszR uaNGKsbnBFq58/VjZ/PVgTNuFETxA2V5h1looVzZTg6MFaBs9jYr1fh1EbhbM82ZhEKP Tx2FjrNRwv3axCfOR/bYVau4NARjMLYHyz1RxChc4nL8Crjxpb68IdTdUIREz43TOilw mQc8BA91jz67DS0xVqj/h/V7kdO2whSNHWmCMdJInfVLSn2VgD8mch623h6b6SAEClHC 3XOA== X-Gm-Message-State: ALoCoQng2jKH1l5O9qbsqchzXcTF2Kb6OIZnGD71SVEED1T80Gc23g6fo0R3SnknjZqo42uwtgzb MIME-Version: 1.0 X-Received: by 10.55.209.157 with SMTP id o29mr3947926qkl.34.1439828499136; Mon, 17 Aug 2015 09:21:39 -0700 (PDT) Received: by 10.96.238.1 with HTTP; Mon, 17 Aug 2015 09:21:39 -0700 (PDT) In-Reply-To: <55CF35B2.9020302@cs.tcd.ie> References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> Date: Mon, 17 Aug 2015 12:21:39 -0400 Message-ID: From: William Whyte To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11479fe63aa35f051d8432ae Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 17 Aug 2015 16:21:45 -0000 --001a11479fe63aa35f051d8432ae Content-Type: text/plain; charset=UTF-8 In fairness, NIST explicitly call this out themselves at https://www.federalregister.gov/articles/2015/08/12/2015-19743/government-use-of-standards-for-security-and-conformance-requirements-for-cryptographic-algorithm : NIST is also interested in feedback on the impacts of a potential U.S. Government requirement for use and conformance using a standard with a fee-based model where organizations must purchase copies of the ISO/IEC 19790:2014. William On Sat, Aug 15, 2015 at 8:50 AM, Stephen Farrell wrote: > > > On 15/08/15 12:24, David Lloyd-Jones wrote: > > What is it you have "heard," Stephen, that has given Phil this avalanche > of > > "reason to object"? > > I already said that I have been told that the ISO spec is behind > a paywall, that is all. And now I've said it twice:-) > > Whether or not that's a deal for folks who've previously been > willing to subject themselves to FIPS140 fun is a reasonable > question. But it's also reasonable to point out that that is > a barrier to broad, open review. > > And of course, if you care about any of this, then telling > NIST what you think is the correct action. > > S. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a11479fe63aa35f051d8432ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In fairness, NIST explicitly call this out themselves at= =C2=A0https://www.federalregister.gov/articles/2015/= 08/12/2015-19743/government-use-of-standards-for-security-and-conformance-r= equirements-for-cryptographic-algorithm:=C2=A0

=C2=A0NIST= is also interested in feedback on the impacts of a potential U.S. Governme= nt requirement for use and conformance using a standard with a fee-based mo= del where organizations must purchase copies of the ISO/IEC 19790:2014.
William

On Sat, Aug 15, 2015 at 8:50 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 15/08/15 12:24, David Lloyd-Jones wrote:
> What is it you have "heard," Stephen, that has given Phil th= is avalanche of
> "reason to object"?

I already said that I have been told that the ISO spec is behind
a paywall, that is all. And now I've said it twice:-)

Whether or not that's a deal for folks who've previously been
willing to subject themselves to FIPS140 fun is a reasonable
question. But it's also reasonable to point out that that is
a barrier to broad, open review.

And of course, if you care about any of this, then telling
NIST what you think is the correct action.

S.

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--001a11479fe63aa35f051d8432ae-- From nobody Mon Aug 17 11:39:16 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 58D1D1B2EF4 for ; Mon, 17 Aug 2015 11:39:15 -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 m1oWvojogTJv for ; Mon, 17 Aug 2015 11:39:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE291B2EF1 for ; Mon, 17 Aug 2015 11:39:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 74116200A3; Mon, 17 Aug 2015 14:57:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4FDDB63B10; Mon, 17 Aug 2015 14:39:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 34F4263AEC; Mon, 17 Aug 2015 14:39:12 -0400 (EDT) From: Michael Richardson To: William Whyte In-Reply-To: References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 17 Aug 2015 18:39:15 -0000 --=-=-= Content-Type: text/plain William Whyte wrote: > NIST is also interested in feedback on the impacts of a potential U.S. > Government requirement for use and conformance using a standard with a > fee-based model where organizations must purchase copies of the > ISO/IEC 19790:2014. I won't read/review a document behind a paywall for free. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVdIqTYCLcPvd0N1lAQKFAwgAhIPY1Z4HciJjoYwi23cq0j+dpIX+NwcC 2k1S6jf+Fa/dZImIcEieFYTL0R2ZlWtleqTaRhbGP6ZOd0Fd1m8qhwWvnPIRZH29 TNPylQNDVsUokBRox2BauvRnvq1SGV3qc85mSvFuai1Op86DgzUXqIDNfsVSrp82 33hy8oixgRYbwKdBcY1q6vUl38blmWjC1dalB8+JGyTYVjPUfBHUpdDNAYrrlpz1 SoZL7YHSne/6XX5/7VnQKUUSCOooprUajdMrTxmHllnJpGpRkb6ij3MIhLJQUsi/ iqgVmi0rgMNwAamyBz++QWsCRRBoCGSgX2xzCYb9dPzIFdz8CdwI4g== =DOlm -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 17 11:48:54 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 B76281B2ED1 for ; Mon, 17 Aug 2015 11:48:52 -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 3Q0SFeu5KQAt for ; Mon, 17 Aug 2015 11:48:50 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 722331ACDDC for ; Mon, 17 Aug 2015 11:48:50 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id D42B9F24135; Mon, 17 Aug 2015 14:48:39 -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 6U6COt8Gn--i; Mon, 17 Aug 2015 14:47:21 -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 A5E9EF24145; Mon, 17 Aug 2015 14:48:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-339--178896087 From: Russ Housley In-Reply-To: Date: Mon, 17 Aug 2015 14:48:08 -0400 Message-Id: References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> To: William Whyte X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 17 Aug 2015 18:48:52 -0000 --Apple-Mail-339--178896087 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It is not clear to me that the use of ISO/IEC 19790 offers any = improvement for the people that make crypto modules or the people that = purchase crypto modules. The specification being behind a paywall means = that fewer people will know what it says. Since the existing FIPS = documents are freely available online, this seems to me to be a move in = the wrong direction. Russ On Aug 17, 2015, at 12:21 PM, William Whyte wrote: > In fairness, NIST explicitly call this out themselves at = https://www.federalregister.gov/articles/2015/08/12/2015-19743/government-= use-of-standards-for-security-and-conformance-requirements-for-cryptograph= ic-algorithm:=20 >=20 > NIST is also interested in feedback on the impacts of a potential = U.S. Government requirement for use and conformance using a standard = with a fee-based model where organizations must purchase copies of the = ISO/IEC 19790:2014. >=20 > William >=20 > On Sat, Aug 15, 2015 at 8:50 AM, Stephen Farrell = wrote: >=20 >=20 > On 15/08/15 12:24, David Lloyd-Jones wrote: > > What is it you have "heard," Stephen, that has given Phil this = avalanche of > > "reason to object"? >=20 > I already said that I have been told that the ISO spec is behind > a paywall, that is all. And now I've said it twice:-) >=20 > Whether or not that's a deal for folks who've previously been > willing to subject themselves to FIPS140 fun is a reasonable > question. But it's also reasonable to point out that that is > a barrier to broad, open review. >=20 > And of course, if you care about any of this, then telling > NIST what you think is the correct action. >=20 > S. --Apple-Mail-339--178896087 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It is = not clear to me that the use of ISO/IEC 19790 offers any improvement for = the people that make crypto modules or the people that purchase crypto = modules.  The specification being behind a paywall means that fewer = people will know what it says.  Since the existing FIPS documents = are freely available online, this seems to me to be a move in the wrong = direction.

Russ


On = Aug 17, 2015, at 12:21 PM, William Whyte wrote:

In fairness, NIST explicitly call this out themselves = at https://www.federalregister.gov/articles/2015/08/12/= 2015-19743/government-use-of-standards-for-security-and-conformance-requir= ements-for-cryptographic-algorithm: 

 NIST = is also interested in feedback on the impacts of a potential U.S. = Government requirement for use and conformance using a standard with a = fee-based model where organizations must purchase copies of the ISO/IEC = 19790:2014.

William

On Sat, Aug 15, = 2015 at 8:50 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> = wrote:


On 15/08/15 12:24, David Lloyd-Jones wrote:
> What is it you have "heard," Stephen, that has given Phil this = avalanche of
> "reason to object"?

I already said that I have been told that the ISO spec is = behind
a paywall, that is all. And now I've said it twice:-)

Whether or not that's a deal for folks who've previously been
willing to subject themselves to FIPS140 fun is a reasonable
question. But it's also reasonable to point out that that is
a barrier to broad, open review.

And of course, if you care about any of this, then telling
NIST what you think is the correct action.

S.
=

= = --Apple-Mail-339--178896087-- From nobody Mon Aug 17 13:33:29 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 2F84C1A1ACC for ; Mon, 17 Aug 2015 13:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 RIypscesY1rj for ; Mon, 17 Aug 2015 13:33:27 -0700 (PDT) Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) (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 801D21A1AB3 for ; Mon, 17 Aug 2015 13:33:27 -0700 (PDT) Received: by vkbf67 with SMTP id f67so59637209vkb.3 for ; Mon, 17 Aug 2015 13:33:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iC2KKxF8r8reS/6FMB6cgag4P1RtPWCtNy/i335B+3A=; b=mkSJr7XuEslFAKm73LChNFCgbV3mnGHHqvRhERzrnWZDBgOenzVwrTiLrHlYnHlJh8 9OJdg1HdxnuMi6Z8pVZ9srvZ9od0LT3OFZyeV8rcFwp4vlbFxDKyTjZk5NwotuwId5yR DZsPchpHb8IK9ge644sJ6DDXXO5kLGhZdyokobLvOJkvs4EYi9Ps4NS5Q52nw2xXxjmZ TW8Fs5gUhuh+whVyBF3LMetQhWDAI/9VU7rBH0dUGRJQlqs3dGR60O7kaHXXn/iQbFXb BeecL2IV3gV268n5sCpwucfyCoT+M+w0Q8D7A9DgL+hvRutu8C77+nvCkhhjc0tou6bQ 8gsg== X-Gm-Message-State: ALoCoQmYO2SN+OroooieB8sKzoREz1pWBggKNsmy03QRgJRXenFLV2NlrN/rcyYJna2dKEMnxzYP MIME-Version: 1.0 X-Received: by 10.52.237.161 with SMTP id vd1mr3841694vdc.65.1439843606639; Mon, 17 Aug 2015 13:33:26 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Mon, 17 Aug 2015 13:33:26 -0700 (PDT) In-Reply-To: References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> Date: Mon, 17 Aug 2015 16:33:26 -0400 Message-ID: From: Richard Barnes To: Russ Housley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 17 Aug 2015 20:33:29 -0000 On Mon, Aug 17, 2015 at 2:48 PM, Russ Housley wrote: > It is not clear to me that the use of ISO/IEC 19790 offers any improvement > for the people that make crypto modules or the people that purchase crypto > modules. The specification being behind a paywall means that fewer people > will know what it says. Since the existing FIPS documents are freely > available online, this seems to me to be a move in the wrong direction. +1, but presumably these comments should be going to some NIST channel? > > Russ > > > On Aug 17, 2015, at 12:21 PM, William Whyte wrote: > > In fairness, NIST explicitly call this out themselves at > https://www.federalregister.gov/articles/2015/08/12/2015-19743/government-use-of-standards-for-security-and-conformance-requirements-for-cryptographic-algorithm: > > NIST is also interested in feedback on the impacts of a potential U.S. > Government requirement for use and conformance using a standard with a > fee-based model where organizations must purchase copies of the ISO/IEC > 19790:2014. > > William > > On Sat, Aug 15, 2015 at 8:50 AM, Stephen Farrell > wrote: >> >> >> >> On 15/08/15 12:24, David Lloyd-Jones wrote: >> > What is it you have "heard," Stephen, that has given Phil this avalanche >> > of >> > "reason to object"? >> >> I already said that I have been told that the ISO spec is behind >> a paywall, that is all. And now I've said it twice:-) >> >> Whether or not that's a deal for folks who've previously been >> willing to subject themselves to FIPS140 fun is a reasonable >> question. But it's also reasonable to point out that that is >> a barrier to broad, open review. >> >> And of course, if you care about any of this, then telling >> NIST what you think is the correct action. >> >> S. > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Mon Aug 17 15:32: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 36C981ACECF for ; Mon, 17 Aug 2015 15:32:11 -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 EARTLKhH4uH0 for ; Mon, 17 Aug 2015 15:32:09 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 950351ACECE for ; Mon, 17 Aug 2015 15:32:09 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 30047F24136; Mon, 17 Aug 2015 18:31:59 -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 7QOtcRYIgqJt; Mon, 17 Aug 2015 18:30:41 -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 5B906F24134; Mon, 17 Aug 2015 18:31:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Mon, 17 Aug 2015 18:31:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <75EDF4F6-A8E9-4423-ACD2-31671413EFBD@vigilsec.com> References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> To: Richard Barnes X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 17 Aug 2015 22:32:11 -0000 I think it would be stronger if these comments went to NIST from the = IETF Security Area Directors or the IESG. Russ On Aug 17, 2015, at 4:33 PM, Richard Barnes wrote: > On Mon, Aug 17, 2015 at 2:48 PM, Russ Housley = wrote: >> It is not clear to me that the use of ISO/IEC 19790 offers any = improvement >> for the people that make crypto modules or the people that purchase = crypto >> modules. The specification being behind a paywall means that fewer = people >> will know what it says. Since the existing FIPS documents are freely >> available online, this seems to me to be a move in the wrong = direction. >=20 > +1, but presumably these comments should be going to some NIST = channel? >=20 >>=20 >> Russ >>=20 >>=20 >> On Aug 17, 2015, at 12:21 PM, William Whyte wrote: >>=20 >> In fairness, NIST explicitly call this out themselves at >> = https://www.federalregister.gov/articles/2015/08/12/2015-19743/government-= use-of-standards-for-security-and-conformance-requirements-for-cryptograph= ic-algorithm: >>=20 >> NIST is also interested in feedback on the impacts of a potential = U.S. >> Government requirement for use and conformance using a standard with = a >> fee-based model where organizations must purchase copies of the = ISO/IEC >> 19790:2014. >>=20 >> William >>=20 >> On Sat, Aug 15, 2015 at 8:50 AM, Stephen Farrell = >> wrote: >>>=20 >>>=20 >>>=20 >>> On 15/08/15 12:24, David Lloyd-Jones wrote: >>>> What is it you have "heard," Stephen, that has given Phil this = avalanche >>>> of >>>> "reason to object"? >>>=20 >>> I already said that I have been told that the ISO spec is behind >>> a paywall, that is all. And now I've said it twice:-) >>>=20 >>> Whether or not that's a deal for folks who've previously been >>> willing to subject themselves to FIPS140 fun is a reasonable >>> question. But it's also reasonable to point out that that is >>> a barrier to broad, open review. >>>=20 >>> And of course, if you care about any of this, then telling >>> NIST what you think is the correct action. >>>=20 >>> S. >>=20 >>=20 >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 From nobody Mon Aug 17 15:43:26 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 048B01ACED9 for ; Mon, 17 Aug 2015 15:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b7Pb_u5IWH9 for ; Mon, 17 Aug 2015 15:43:22 -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 34F1C1ACEDA for ; Mon, 17 Aug 2015 15:43:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 75D1CBEB5; Mon, 17 Aug 2015 23:43:20 +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 BBcgGXkDRbNf; Mon, 17 Aug 2015 23:43:17 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.22.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A3471BEA1; Mon, 17 Aug 2015 23:43:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439851397; bh=vQR9WKNeH84wd0k0CxL5HKFJICATblAbccce9fwh57A=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=Se9ZmMcmD4gpuaJk4pQtoKJrWNXt5iC+ame+5B+xXsiy+NwYB0rf2vjKb8Kv1QkEE gmexc3XCy/Fy8dwBq5nPBZfDoFgG6DsQR2ftqCvy4ZRY7OXvoCLGcqD/k2CV0FPkIg gHw9yfTXfABT1fSRc1UP4UvhtThYMM/ADhBjfcrM= Message-ID: <55D26385.8050203@cs.tcd.ie> Date: Mon, 17 Aug 2015 23:43:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Russ Housley , Richard Barnes References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> <75EDF4F6-A8E9-4423-ACD2-31671413EFBD@vigilsec.com> In-Reply-To: <75EDF4F6-A8E9-4423-ACD2-31671413EFBD@vigilsec.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF SAAG Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 17 Aug 2015 22:43:25 -0000 Hiya, On 17/08/15 23:31, Russ Housley wrote: > I think it would be stronger if these comments went to NIST from the > IETF Security Area Directors or the IESG. Fair enough, I'm happy to chat with Kathleen and see how best to process a statement if you or someone has time to draft a bit of text. Or if nobody does I'll try get to it next week if Kathleen doesn't beat me to it. (I at least may need reminding - so please bug me if nothing appears to happen a lot;-) I don't think it'd be right for the IESG to send but I'm happy to chat with the IESG and IAB to find a way to get the message sent. (*) Regardless of whose name is on the "From" line of the message, I'd be happy if the text had been seen and not found objectionable on this list. (If objections are raised here we can figure out what to do about 'em.) And of course, after some text has been crafted here it might get tweaked by e.g. the IAB or someone but I'd make sure they know that this list was involved in the generation of the text and ask that they check any such edits. S. (*) For the sensible amongst you who don't get involved in IETF process stuff, the IAB are (amongst other things) the foreign-office and might rightly be a bit irked if the IESG (amongst other things, the home-office) started stepping on that toe. Apologies for the .gov.uk terminology but I figure the Irish analogues wouldn't be as well known:-) > > Russ > > > On Aug 17, 2015, at 4:33 PM, Richard Barnes wrote: > >> On Mon, Aug 17, 2015 at 2:48 PM, Russ Housley >> wrote: >>> It is not clear to me that the use of ISO/IEC 19790 offers any >>> improvement for the people that make crypto modules or the people >>> that purchase crypto modules. The specification being behind a >>> paywall means that fewer people will know what it says. Since >>> the existing FIPS documents are freely available online, this >>> seems to me to be a move in the wrong direction. >> >> +1, but presumably these comments should be going to some NIST >> channel? >> >>> >>> Russ >>> >>> >>> On Aug 17, 2015, at 12:21 PM, William Whyte wrote: >>> >>> In fairness, NIST explicitly call this out themselves at >>> https://www.federalregister.gov/articles/2015/08/12/2015-19743/government-use-of-standards-for-security-and-conformance-requirements-for-cryptographic-algorithm: >>> >>> >>> NIST is also interested in feedback on the impacts of a potential U.S. >>> Government requirement for use and conformance using a standard >>> with a fee-based model where organizations must purchase copies >>> of the ISO/IEC 19790:2014. >>> >>> William >>> >>> On Sat, Aug 15, 2015 at 8:50 AM, Stephen Farrell >>> wrote: >>>> >>>> >>>> >>>> On 15/08/15 12:24, David Lloyd-Jones wrote: >>>>> What is it you have "heard," Stephen, that has given Phil >>>>> this avalanche of "reason to object"? >>>> >>>> I already said that I have been told that the ISO spec is >>>> behind a paywall, that is all. And now I've said it twice:-) >>>> >>>> Whether or not that's a deal for folks who've previously been >>>> willing to subject themselves to FIPS140 fun is a reasonable >>>> question. But it's also reasonable to point out that that is a >>>> barrier to broad, open review. >>>> >>>> And of course, if you care about any of this, then telling NIST >>>> what you think is the correct action. >>>> >>>> S. >>> >>> >>> >>> _______________________________________________ saag mailing >>> list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag >>> > > _______________________________________________ saag mailing list > saag@ietf.org https://www.ietf.org/mailman/listinfo/saag > > From nobody Mon Aug 17 17:37:29 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 862611B3020 for ; Mon, 17 Aug 2015 17:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 AvOdnpTsDjoP for ; Mon, 17 Aug 2015 17:37:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58821B2FE6 for ; Mon, 17 Aug 2015 17:37:24 -0700 (PDT) Received: from BLUPR05MB705.namprd05.prod.outlook.com (10.141.207.11) by BLUPR05MB484.namprd05.prod.outlook.com (10.141.29.28) with Microsoft SMTP Server (TLS) id 15.1.231.21; Tue, 18 Aug 2015 00:37:09 +0000 Received: from CO2PR05CA044.namprd05.prod.outlook.com (10.141.241.172) by BLUPR05MB705.namprd05.prod.outlook.com (10.141.207.11) with Microsoft SMTP Server (TLS) id 15.1.231.21; Tue, 18 Aug 2015 00:37:08 +0000 Received: from BL2FFO11FD007.protection.gbl (2a01:111:f400:7c09::121) by CO2PR05CA044.outlook.office365.com (2a01:111:e400:1429::44) with Microsoft SMTP Server (TLS) id 15.1.231.21 via Frontend Transport; Tue, 18 Aug 2015 00:37:08 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.1.243.9 via Frontend Transport; Tue, 18 Aug 2015 00:37:07 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 17 Aug 2015 17:37:05 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t7I0b3D00359; Mon, 17 Aug 2015 17:37:03 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 96E5C1148B; Mon, 17 Aug 2015 17:37:02 -0700 (PDT) To: William Whyte In-Reply-To: References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> Comments: In-reply-to: William Whyte message dated "Mon, 17 Aug 2015 12:21:39 -0400." From: "Mark D. Baushke" X-Mailer: MH-E 8.5; nmh 1.2; GNU Emacs 24.3.1 Date: Mon, 17 Aug 2015 17:37:02 -0700 Message-ID: <97152.1439858222@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD007; 1:69+Mz4rWo+H2J9aSKuyk5ulrF3r0pIGxmxZz+OZqQhwT5Oo3GoeG4NCEJbkKEsPRjBiccOyuIrHWhksqCEUORJVVqGpEVeKZlbJfQ+OfLA1nIzd0muIEIS6HdhMOnvlTl0Pe53il8PmgC7GKLT6rGTaEyOOzjEJeXgqBKGByWDsbecabczYC+3dyUg6a5iH58l5RfJ4W59dfwKtPcONT6xzxG1jBsYv7UyhNYTOBrchfUoPV8MTIZ8obsSKSuby89j5u6ou20MkK1CKXTLUUhs+8+sa0clZZ4WY9DCcdk3jyIEDmmLrUTTbm2e3eDwnrW0QEHAoyQpoLxC/pef5TxbEp+EfhBlXylWjuySB8dDgVxLwj5V6C9AhmT4TBKI1n2ATFob0dApwVc44dkBdJuQ== X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(3050300001)(199003)(189002)(5003940100001)(5001960100002)(110136002)(5001830100001)(5001860100001)(81156007)(93886004)(5003600100002)(19580395003)(117636001)(189998001)(50466002)(48376002)(50226001)(6806004)(97736004)(558084003)(105596002)(15975445007)(2950100001)(77096005)(5001920100001)(4001540100001)(46102003)(106466001)(50986999)(62966003)(92566002)(77156002)(76176999)(64706001)(68736005)(87936001)(86362001)(47776003)(69596002)(76506005)(53416004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB705; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB705; 2:YAAcMwTkFXJNk9dNWvWmDIlYH0+SfWpTj5z7dQ51GG6+6HQc1HgkoQXjwkdsjXQkM8iA/l0sHyzNqB2eh6tBGHQc/ritn/jiIip3EYKF2FP91a3OT2aAjDUJP6prFDIeJ6qPDtjCT7rnoNL8xVoDhrrw5B30GrjJGKONVnxSThM=; 3:oZgwjq1hO/LQDRYo4luweOncMWRWVTs0GmITO/BRk/hpi7YXS/MdydW5crnqP2HUrxTHT0Bj1p6oG+nxHJcbrzeCZW8v2Jua4dFhMKxbHdvQbWoVBMsAuHUHUQ6uPFIGMs00YbJwuMHX3HLW+nstrUzE6Ow5salJuqTC6af2ZkdmZ1T3UN1RSf9NLuUXzzDKpXbZAMCRaXW9UP6NWW5MdGNN087vnZpg+h6aBMPYpPc=; 25:v+uJEnEUcv5g7apA21OGbWKVlqZFowvZKuZoNyMM5W2SElr1tSAmvIDPy92TmuNJd63xEX8BItdet7HgQQ3IptnK3ptcXydrbvKYia7LFFTh7TzIEzkfvS/KqIH8bvcm1BN6WswNj9oo4PGdgt7fVHYl4WNMLSTOnX3wVbt/mtg8waqJB4/No19Uxnko1YZAwgT6O6QXJxjsURfiZCSRYLr0TEXJAHIJwNcgsUQVVTQ1mK1YwgWTvQsL3UD7Thhf2IZdSH40TXfQtxXQ6I1W1A== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB705; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB484; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB705; 20:gstA3R/hA9CJp+nvbBYotYFeGxsPxcJ5YFLek6ZQpisvrBLaIZaVxacQltUjV1p4tIzG+rew4KCkBclfuXI7+f2oLaqkQaxEOE8nGlC8QdbbjXSC8lzY8GeGFlV2bmdIMYloZEmJ3zA3NOylFIdFYVxs8uD9RqvS+GsuhxmjsGFqvWxhSHGs4Xs0Ti9lBnG+G8qc1+F4pg+YGbzBj+1ohYoh0EAt54jw/h4faVCnMZd3wsu1RZ+lGBwX24+/1XbB0iPNtzW7YFmUFleD3KMzPDsSR6+bK0xRZtX+Q+a4e8b4owBgdg80myvBgIR3Jo8dK2AViRteh+s/ikcrMEvOf4gSrsEZVGuszv8sb+iQcEtxPk5wcWm1u9Y2ngEoPM6En/h8gl7bafAacHYY2Mdx5tza/hCa6n34dxCDjD19HS47FAam0YJBCNdE/dEa4SICeIaMCplzkIHBxhgsgOvnfO2Qafygz/EaePhGT67hh6m/6VNyw8lAhpwbmqHDr8FO; 4:PVR+bcOFsGIaJIKcZ0M5Cws+LAplhn921REsJICWOF8HWAc3p6qPdsqygwOI9vMGHX0DK2oDTByP2V/rZ3hKUChm/C7G2MBK16MSuhRJpoefq+OuRA4kVtVxsJW1L7RevC1YBg/ZLpQc55a5a88OTA9WW9IvXWKTG/AjHOCQBF+4YIz4yCc9G/znc43fRBO+2y1AuSmk18eZjmmn9RAAhD7y3ukBzMubwj4zpnraEzaqXvPLhD9p4We5kglO9jUCubqjVifALGJInysh7d3WdmUrD5EMJ8Aas25Kqz2I1EvZknSR3WnPJf6qPdVAZpJv X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BLUPR05MB705; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB705; X-Forefront-PRVS: 067270ECAF X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB705; 23:R+I4K6ltROEYroQaY7nOEotxqx/JV6Bw6Ho3F8KBnu?= =?us-ascii?Q?wopBfCD6qx8BqXCimZRjDtgaCNbpqVV8+4byFPubngW6CqWZNeJAjnhMNjwD?= =?us-ascii?Q?PfIP6YU42n8gxd8WtIiBFE3+yyB5WyjPPMTknWT755RpdODRrSw7/KVox65d?= =?us-ascii?Q?8AhrLxh8sstt6EpxjAdk/duu0tTpMLCF8PSCTzJ+4cpzE+D6g9B1kfMTJ8M0?= =?us-ascii?Q?9jbTIgQYcHpSs7NZakLsFDYiH/MjvoatwnafeKXjo05wM+HJlS8a7Z76l2la?= =?us-ascii?Q?wwzdN3/9r1i2jdoTLK7NYBnEiKHLqN0+ZWAPlJvYT1MREJM7aoVhDbJD+Myt?= =?us-ascii?Q?QSMlE68yJqyq+QEfKj7rxOvAVGqXgBKMOi1tjQGSNKc4m60s5SDPQPrWJoKq?= =?us-ascii?Q?WFwMUxDqr8gk4FNI06SSd+Orm8SInotR8DrK2hP9dgZQOLX9y+scbFrDSC19?= =?us-ascii?Q?5UHBGL6YigSUusU2kv8l/E9ItbJJBh9I6PRvNG8jXFg0pb1fWf4aT8M2lLGk?= =?us-ascii?Q?UVdUKyTeJskH80GqcRQKR4u3E0nTcsUr3TP9sls+jCaBG47ytrZHgUWxaHuW?= =?us-ascii?Q?yZJun6swOrQpplqPvAkrOnTX1t+Xk3REi+yIg8Pic3MkbdpOK7FWrojTIS0h?= =?us-ascii?Q?AQax2GWygeypVgVWbm9l/LqTx1oWAYWa60LJ/SHITjUnJ218w8G9LIrcVuPh?= =?us-ascii?Q?ry14Q6NwgC/CMSVWawHSRsyfl0Ps0jX+M2XoCm9aizyNy1BYPaPNzCmn1/4E?= =?us-ascii?Q?bm0Sc8nLGSTYRs3nuMeBkcUeljVQdDgpcdzjRFBjPAygKML6o1qd50t7Z5sX?= =?us-ascii?Q?6Gh/H4pGf8JG9Er9aFtr8m6i/pQQHiIyRrAlCocdtf94ErWNT8UaouDsR0ri?= =?us-ascii?Q?nnKnvEywzWTBCUYwHpZutcYCP7LJxWWLWs7Qz0TkwQkG3sQIRI7cciWduWSD?= =?us-ascii?Q?niPBTuOF014cQcsCoSV8GjXKkVQd8OSWzql/mDd1BFlfTzjRQy6AnIytjtmY?= =?us-ascii?Q?YMqZR3+1QEbRr7xRhSkhUVOVMx7uA5EpWwNWV1Mz9x2nfneRRGZNzt6bTnON?= =?us-ascii?Q?4apRm5y6a2CBDb3egq5irZHqSHnl87OP8efFbl8i5LMrDysBKoLC2vQvdDKI?= =?us-ascii?Q?6v4y9wW3rMtQG3VfFR6M9cRCWRORWPPg5X5MG4SG9ZoRQWdduyfXF7vKawrN?= =?us-ascii?Q?2BZEx9mtJrqKTY1o1WLaJ2h8Vt7GQZJ6x2?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB705; 5:EoT8B2S2dqfBgsDzUnxpQVOG6igurUb9T86KAZHyq+LDcB5caNIaX7xGdJBHWIQfayN5CyxKuFeLEELgt5/4gcdi/6iBNyMwfMLSXz4AOKp4Hap1snriCE2PKnJBVWAhcX+kz60X5mJYvTTFtFNrzw==; 24:w2FSbX/fe+c38eobajWsiiPidyIxUHAQZFGcOnrPc+JAxwOpdUZL5K9d4f/UoWHUDzEANZq5RohGG2Y6MEbtTpuNShyx1DrFXqjomygwZgM=; 20:kYAPMjLMoIL4cMrcuPtmhOwLeQfzG3CKvYxiDaKdRf9LtvuNE5qogarpKqvNIwBteA/GhdeXjdLlHdi6uMwWTw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2015 00:37:07.0309 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB705 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB484; 2:6hV/DmbhbaRRcWjXjdKd9DcmxffLAs/vOqF2/XBbI2/aiLnm9fM+eRAhdtZ1iLqIUB3HRD+xm012gREOwggieEYVV+9viOrQUBS4JjDCczVGwUa7vOK6LDZ83N1vTUWBv1DIKG46YojxqndebPXjEUBqa/mXgWJm6RBS97AFfNo=; 3:0Pd25k2joHeTEdzYFFJx/IC64PoLphD63ytb/cQ5lXn2Tod1WFicM2P6Oi6ccYUjbTwiVd8X1kJH4kxFjwPluheeC/3W1j02qAfQ6+vB+1klouBe6AMnu5PJ2CdoGD3Nz/Q0IJv9cY7ifiw6CKuZFg2g4X21wZFo0ymTvo+QFjFsHbh8zXZoU6Ne+YnBWwxD4gjHVVWxFTLegwa2CRppBhNsImt9ASiQjPBYOsY2l/I=; 25:D5G4hvY+HQ1bA7zDwGwswDSr8go5TZ7p5obVxiaC/eEroZHT+JOzR7rTYe0nCKtvbowpIfkvheTqsbTOX5+qpr8nLgy7Qp+JAIUP6nibKrB5eVYcONVJAWAKD9AMeZUIARj/w8/8LQDzoksOVkh9VaEQhi7ogs5CGVZu9CdMuftI6tayy5YfY3inF8jKCE9VrI3Q2YQtgH/0qATH1oG2tDz4QUBLLXl0KNUKDYhwx7+vsyIgnUR9AeI34vk5OmvS3TlsRE18cCbYRYol18o7hQ==; 23:c+oJBT9jtTSa+5PhoE4YGeXQRR1ULDX6QQTZys/k9yX2swB2NFwX5VBMlNUZ13OVFxhOxVzabyAO9+9ssdv2KvOlUaDqKEFZ6mc2V8QNAtxGJpP3lyoaYw92cafmmQbNmjYQW4v7Iyg4Fwod6WKXsKRxqiMY6tuXkc1vd07FKLikaE2+D+kLHoh0wcorDvay X-OriginatorOrg: juniper.net Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 18 Aug 2015 00:37:27 -0000 It may be worth noting that NIST actually put the wrong edition of the ISO/IEC standard in the Federal Register article... They intended to put 19790:2012 instead. See also http://csrc.nist.gov/groups/STM/cmvp/notices.html -- Mark From nobody Tue Aug 18 02:33: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 A1C011B32D5 for ; Tue, 18 Aug 2015 02:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 RlNrV28vFsXk for ; Tue, 18 Aug 2015 02:33:50 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 9DD561A0018 for ; Tue, 18 Aug 2015 02:33:49 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so99190042lbb.3 for ; Tue, 18 Aug 2015 02:33:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xiRG48YmwTJ5GiuSdSWdCXDNugejQL2WTNm+FuGiuaE=; b=f+/mrObF2fh95UIeDtmfea/k8SHgQ6vjdFiNRP00XItrIy0EDWjc2aadgRU5kkahOk SlbyWXzMOMRMKZ2yBnvlJObU5g7GnFRaVXm3t3jk8sTASMqRRdXswxPcVm595rNxTlyb nd/YwoNsYBLIfwrPDpmX3VvfMUlTUu1KbHhGuptUBhNKcLbt+Q/frP5KIHO69xHn0Aqy SiU7g1ukcWsKxIbWJjG6ceJlS4++ZvVuNQn4hSjyfHk1A+Gtj+gtp0FWPZZaKO87eFyT OpCj5LamhV7Vzip/ujEAXx4Jf/J5im0TVAg4VNndRgefzoIn62nYroMtBzbKO2JnQavd nb3g== X-Gm-Message-State: ALoCoQnZ24b6IQ3WuAu0NGJ9xXGqzvM7m7QmOaR+mcDF4KovZKSD0ceb6/sW1TZ773+Ahw9XoeYZ MIME-Version: 1.0 X-Received: by 10.152.2.41 with SMTP id 9mr5469302lar.65.1439890427906; Tue, 18 Aug 2015 02:33:47 -0700 (PDT) Received: by 10.25.144.193 with HTTP; Tue, 18 Aug 2015 02:33:47 -0700 (PDT) In-Reply-To: <97152.1439858222@eng-mail01.juniper.net> References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> <97152.1439858222@eng-mail01.juniper.net> Date: Tue, 18 Aug 2015 10:33:47 +0100 Message-ID: From: Phil Lello To: "Mark D. Baushke" Content-Type: multipart/alternative; boundary=089e013c625878aa26051d929df6 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 18 Aug 2015 09:33:51 -0000 --089e013c625878aa26051d929df6 Content-Type: text/plain; charset=UTF-8 I'd just like to clarify that my objection to the paywall isn't about paying for the standard per-se, as it would be reasonable to pay a fee as an implementor (much like paying to access C++ standards to write a compiler). The objection is specifically about needing to pay to access the standard as part of a review process, as the fee is a barrier to broad evaluation. Phil On Tue, Aug 18, 2015 at 1:37 AM, Mark D. Baushke wrote: > It may be worth noting that NIST actually put the wrong edition of the > ISO/IEC standard in the Federal Register article... They intended to put > 19790:2012 instead. > > See also > > http://csrc.nist.gov/groups/STM/cmvp/notices.html > > -- Mark > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --089e013c625878aa26051d929df6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd just like to clarify that my objection to the= paywall isn't about paying for the standard per-se, as it would be rea= sonable to pay a fee as an implementor (much like paying to access C++ stan= dards to write a compiler). The objection is specifically about needing to = pay to access the standard as part of a review process, as the fee is a bar= rier to broad evaluation.

Phil

On Tue, Aug 18, 2015 at 1:37 AM, Mark D= . Baushke <mdb@juniper.net> wrote:
It may be worth noting that NIST actually put the wrong edition of= the
ISO/IEC standard in the Federal Register article... They intended to put 19790:2012 instead.

See also

=C2=A0 http://csrc.nist.gov/groups/STM/cmvp/notices= .html

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mark

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--089e013c625878aa26051d929df6-- From nobody Tue Aug 18 06:47: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 96EB91A8748 for ; Tue, 18 Aug 2015 06:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 9Ax_s1fbzCir for ; Tue, 18 Aug 2015 06:47:33 -0700 (PDT) Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) (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 02D5F1A873A for ; Tue, 18 Aug 2015 06:47:32 -0700 (PDT) Received: by vkm66 with SMTP id 66so8823167vkm.1 for ; Tue, 18 Aug 2015 06:47:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IZiy8rV7o/rGtYAd7hrHYnkBeNJyNUxeUQp70lcJT4w=; b=iUmumwgrUYzoWpz/KyxCLu42e7Pgtic4zNFSaIN548TrPACWO2ok5aiN8w/fvUeAeB 8B70er4GwpJNQpZc4Iwn1QY0KtfFvr9w/9D0avZXShJoMsOEyNPX7wkd2zXjcF7cwQjk sA+Yn5gIZnkOIScfNiIwp8KzSOEsIu4ImXoeEfErdxC560wIv3BNPK9uiFaUKv2ctza+ xIteHaoG3iG8TcnQpBzTpAL7DSPRFsdmbnONa1K1eIuUGI2po6qIJ81mJRv7t43ldifI ScBkTLNU6CygIQiGD+q8hhuV28lzjmZbuYJ9VDnL+nHLrc1bl4jtMITjVGwVyUdZJyCQ Juhw== X-Gm-Message-State: ALoCoQkMgpneCnBy8KgHkeYzBHqt1HspforNCg6WhpWtP+hJ+98aB68cLQUZZJUafCO/08XhXnAo MIME-Version: 1.0 X-Received: by 10.52.69.241 with SMTP id h17mr8898942vdu.68.1439905652250; Tue, 18 Aug 2015 06:47:32 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Tue, 18 Aug 2015 06:47:32 -0700 (PDT) In-Reply-To: References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> <97152.1439858222@eng-mail01.juniper.net> Date: Tue, 18 Aug 2015 09:47:32 -0400 Message-ID: From: Richard Barnes To: Phil Lello Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 18 Aug 2015 13:47:34 -0000 On Tue, Aug 18, 2015 at 5:33 AM, Phil Lello wrote: > I'd just like to clarify that my objection to the paywall isn't about paying > for the standard per-se, as it would be reasonable to pay a fee as an > implementor (much like paying to access C++ standards to write a compiler). > The objection is specifically about needing to pay to access the standard as > part of a review process, as the fee is a barrier to broad evaluation. Well, then let me explicitly disagree with this position. The standards that run the Internet need to be widely implemented, and that means the specs need to be widely available. As Russ observed, the current FIPS standards are freely available, so moving to a paywalled standard would be a major step backwards. And a step backwards for, AFAICT, no benefit. I would also observe that "free for review, pay for implementation" is not really a realistic position. If anyone can download the spec for review, then it will be out there on the Internet after it's finalized. Much like the C++ spec, in fact (see the links in https://en.wikipedia.org/wiki/C%2B%2B). And in practice that just means that everyone will use the free "almost final" version, not the paywalled "final" version. --Richard > > Phil > > On Tue, Aug 18, 2015 at 1:37 AM, Mark D. Baushke wrote: >> >> It may be worth noting that NIST actually put the wrong edition of the >> ISO/IEC standard in the Federal Register article... They intended to put >> 19790:2012 instead. >> >> See also >> >> http://csrc.nist.gov/groups/STM/cmvp/notices.html >> >> -- Mark >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Tue Aug 18 07: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 BDE191A876C for ; Tue, 18 Aug 2015 07:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFDFAcONAFi2 for ; Tue, 18 Aug 2015 07:02:20 -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 90FF41A8773 for ; Tue, 18 Aug 2015 07:02:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 63D4DBE80 for ; Tue, 18 Aug 2015 15:02:18 +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 QeiMYjhT-Dxp for ; Tue, 18 Aug 2015 15:02:18 +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 2E3AABE32 for ; Tue, 18 Aug 2015 15:02:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439906538; bh=QdMemwI1iRe5wCqiwC8UtkeXWAQ3bnS2qeB+F43t1t4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=CbYzSxWqeARrWvQuCczjIkh2WpwhkfX72hZE7S9zInQf4XTYd/nJUtS7Y0Jx1qP0C vD2qrS1L8f778pAKVBxzmFpDUkW5Wd/havQt34m+snTT1kq9SjXi/jnOwNjR9VmxHl AnCz8zShyu0Br68cmzZThaIfVT3JlTzo0yJq9Moo= Message-ID: <55D33AEA.20508@cs.tcd.ie> Date: Tue, 18 Aug 2015 15:02:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <55D339E6.10803@cs.tcd.ie> In-Reply-To: <55D339E6.10803@cs.tcd.ie> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <55D339E6.10803@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ne2kmeGNeqtUkKeGBnXm0H0A50dACbud1" Archived-At: Subject: [saag] Fwd: who's interested? (was: Re: [Anima] Conclusion: adopt draft-pritikin-anima-bootstrapping-keyinfra as ANIMA WG document) 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, 18 Aug 2015 14:02:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ne2kmeGNeqtUkKeGBnXm0H0A50dACbud1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, There's been a bunch of discussion on the anima wg list (with the interesting bit of the thread starting about [1]) on the "introducing" or bootstrapping topic that came up at saag in Prague. See [1] and the text below if that's of interest. Cheers, S. PS: a reply-all is a fail, I'll assume you're not really interested enough to read the instructions properly:-) [1] https://www.ietf.org/mail-archive/web/anima/current/msg01337.html -------- Forwarded Message -------- Subject: who's interested? (was: Re: [Anima] Conclusion: adopt draft-pritikin-anima-bootstrapping-keyinfra as ANIMA WG document) Date: Tue, 18 Aug 2015 14:57:58 +0100 From: Stephen Farrell To: joel jaeggli , Michael Richardson , Hannes Tschofenig CC: Toerless Eckert (eckert) , anima-chairs@tools.ietf.org , Max Pritikin (pritikin) , Kathleen Moriarty , anima , Sheng Jiang Apologies for the oversized distribution list. Kathleen and I chatted about this, and indeed we had some discussion of related topics at the saag meeting in Prague. I'd like to see if there are a bunch of folks who are interested in doing work in this space and if there's a useful topic or set of topics on which work could be done and that needs a bit more co-ordination between working groups. I think that might well justify either a slot at the saag session at IETF94 or even perhaps a non-WG-forming BoF session if more time for discussion was needed. Minimally, Max Pritkin has already offered to do a presentation for saag at IETF94 presenting his view of the problem and solution spaces. (Which I guess will generate discussion:-) But first, I'd like to see who's interested in working on this between now and IETF94. If you are interested, please send me an offlist mail, preserving the subject line. Depending on how many of those I get I may start a new list or send around a few mails, but in any case I'll get back to this list in a week or two and what, if anything, is the plan. Cheers, S. --Ne2kmeGNeqtUkKeGBnXm0H0A50dACbud1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV0zrqAAoJEC88hzaAX42iYO8H/i5MYMpiJcanrZJSjgV5tluY 7NLQwwwjlCYt2BltFYFXkVtAvqBovRhN5VjiEvEsHsVM3HKHPl8j4UEol9T6eiE2 NyLV6dwNi2lEkWiCYP/E9tAR25yXp3nPQ+I4esiXA6PuStYdbgmjeWBFOLBVN/+h CFBUHECJlbXcvA0kYAN6s7YOr3MLPnYhGdXDT9y5m4fcRXIGpmf9h9P3JTtaeI+x p1ium8MyxxWcsJYImYfqPmFKHxKLwIzrnjzoLQNnCjwdYZVrURQMAA0x77ETUKqO +JHBEG1p3x7iQ21MgRQvR6ONLWmkeyfm8U5HzD/+Pz9tKUhuUmUBpx/LtDCTips= =NVry -----END PGP SIGNATURE----- --Ne2kmeGNeqtUkKeGBnXm0H0A50dACbud1-- From nobody Tue Aug 18 07:12:29 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 5E9C21A87AC for ; Tue, 18 Aug 2015 07:12:28 -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 GGUaeQ6WB7Wd for ; Tue, 18 Aug 2015 07:12:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A951A87B0 for ; Tue, 18 Aug 2015 07:12:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 446262009E; Tue, 18 Aug 2015 10:30:43 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 56F0663B10; Tue, 18 Aug 2015 10:12:25 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3B7C963AEC; Tue, 18 Aug 2015 10:12:25 -0400 (EDT) From: Michael Richardson To: Russ Housley In-Reply-To: <75EDF4F6-A8E9-4423-ACD2-31671413EFBD@vigilsec.com> References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> <75EDF4F6-A8E9-4423-ACD2-31671413EFBD@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: IETF SAAG Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 18 Aug 2015 14:12:28 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: > I think it would be stronger if these comments went to NIST from the > IETF Security Area Directors or the IESG. +1 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVdM9SICLcPvd0N1lAQLDSQf/XsUxNqZV82ME7fkIQ2hrbvUH6XaTiVYS hHbAT3F+JfcwqP0JiAauwvLRItwqxeJxWz87xwzP2iapOW4Jk+DPThERSCgqj0SB Jv2NT5vfjd/mooDLqHc6P24RNCIi9s+dapPnWCmfF+G5IRGIDY4vLPxj2RmyDvU0 6B4r0Vsp4gYT16/Bi8LaZRdVsj94i9w1a7aMihZ8/N2TZ6Ui2CxXhgzo6o38b1+T nnvYvTuqXZMoNQmBlHoGPdlhFhpEtUZVp60QGl7EIo0YoklqhFOJSCUNbHZAbMhD 9BZQK6/2vqDFwaaqcoHMKc9UOQZYkBHir8Yrddjs+bt7afY7dif6Tw== =gY1Q -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 18 07:13:18 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 359A81A87C0 for ; Tue, 18 Aug 2015 07:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 FXnXUajOEOua for ; Tue, 18 Aug 2015 07:13:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF3E1A87AC for ; Tue, 18 Aug 2015 07:13:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 713172009E; Tue, 18 Aug 2015 10:31:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9541563B10; Tue, 18 Aug 2015 10:13:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 79B8663AEC; Tue, 18 Aug 2015 10:13:08 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <55D26385.8050203@cs.tcd.ie> References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> <75EDF4F6-A8E9-4423-ACD2-31671413EFBD@vigilsec.com> <55D26385.8050203@cs.tcd.ie> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: IETF SAAG Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 18 Aug 2015 14:13:17 -0000 --=-=-= Content-Type: text/plain Stephen Farrell wrote: > On 17/08/15 23:31, Russ Housley wrote: >> I think it would be stronger if these comments went to NIST from the >> IETF Security Area Directors or the IESG. > Fair enough, I'm happy to chat with Kathleen and see how > best to process a statement if you or someone has time to > draft a bit of text. Or if nobody does I'll try get to it > next week if Kathleen doesn't beat me to it. (I at least > may need reminding - so please bug me if nothing appears > to happen a lot;-) > I don't think it'd be right for the IESG to send but I'm > happy to chat with the IESG and IAB to find a way to get > the message sent. (*) I think it's directly related to OpenStand. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVdM9dICLcPvd0N1lAQKDUwf+PNiSVhxXMIt6k9DwOt1gZmRwsKDJk8d5 PPrA+RNGhxaqA07Rz+7Dlb3GJDW1miKRQ6bTHu5nJmtnaa2KooRuxSCslBePUqpv Sg3/R3cZ4iWS2d5zhZkwO0xgAB9Glke/EfEPfxRGLq7LTk38cpdqd+nFpfE90Sku XzNOaYBKV17J+ipEVCFRHvKeaeNGbs2Yw26ipvVL47XO9I37mwP6CKGLCTIUyATK IsabmQA8tgN5SYc3Irfca3wl2cr3OM9F1kwMmf34zSV+QhFlIMX4wSWLdt3i2RsW T40mHf5IO7J1CKU2UwgglD0mvDJHbHacgBTN5Ua84qvSNEme+X2yBw== =qyt/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 18 07:28: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 A63691A8839 for ; Tue, 18 Aug 2015 07:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjcneQ0xWpO3 for ; Tue, 18 Aug 2015 07:28:22 -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 280DF1A882F for ; Tue, 18 Aug 2015 07:28:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C04D6BE75; Tue, 18 Aug 2015 15:28:19 +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 YEYg_CJHKcvx; Tue, 18 Aug 2015 15:28:19 +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 72A1ABE5D; Tue, 18 Aug 2015 15:28:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439908099; bh=ahDv3KN0U7hZ8kGu5l1u4XK693WMvB+jh3fHIpZGnio=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=19QpAMqUIL9T0c68uMLeWu1Ygs0pSFlZvFZC74PPT71kE+Vb1I3+y25qk+sQrGbqQ VJFoOIBqWXzHfJrX1T6CkYnDKj5l/b4hNMYcxH9TWDIn4J5JRugJcSxG6arI9txBGW WRYlmy2CnZgeexyaxMAysDTcrD31OxLIGJKhTzbE= Message-ID: <55D34103.9010607@cs.tcd.ie> Date: Tue, 18 Aug 2015 15:28:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Michael Richardson References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> <75EDF4F6-A8E9-4423-ACD2-31671413EFBD@vigilsec.com> <55D26385.8050203@cs.tcd.ie> <11010.1439907188@sandelman.ca> In-Reply-To: <11010.1439907188@sandelman.ca> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6a3W9IsGgor3MdLaUxkgICf1qeGqDLBam" Archived-At: Cc: IETF SAAG Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 18 Aug 2015 14:28:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6a3W9IsGgor3MdLaUxkgICf1qeGqDLBam Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18/08/15 15:13, Michael Richardson wrote: >=20 > Stephen Farrell wrote: > > On 17/08/15 23:31, Russ Housley wrote: > >> I think it would be stronger if these comments went to NIST from= the > >> IETF Security Area Directors or the IESG. >=20 > > Fair enough, I'm happy to chat with Kathleen and see how > > best to process a statement if you or someone has time to > > draft a bit of text. Or if nobody does I'll try get to it > > next week if Kathleen doesn't beat me to it. (I at least > > may need reminding - so please bug me if nothing appears > > to happen a lot;-) >=20 > > I don't think it'd be right for the IESG to send but I'm > > happy to chat with the IESG and IAB to find a way to get > > the message sent. (*) >=20 > I think it's directly related to OpenStand. Fair point. S. >=20 >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 --6a3W9IsGgor3MdLaUxkgICf1qeGqDLBam Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV00EDAAoJEC88hzaAX42iWS0IAK1IUuKP/Fhj/E33yY2UmsMZ BUtQ9BH6sv+vkhQygV7AGPDpyBvM3ti1VsYpHEjAfTXzZzBw3ycd/ubhk1CWLK4i K5kYyu0g2UcR5KwsBw36uPHAh7648Q6z7dh7VssublJgkSdbbTbzOq420oK2PX1d Myimd86mXebTzwarw9/9sJV0yhlPwh8XpwnoPF5N7qbUqJSb/t3tQKupTjoTyEme +WUNQyYrZrC7afSlJu+TJwdKURBNs4Bw9pcdIztjmih0ifl8AuwVoFIHR+/o1zw+ E4Nmr0UfX3wheWVR1P4gn3g4Ox6BnNsU6oSNH5SC4EbJNGkEcW7ey86WoCiTGh8= =Cb2M -----END PGP SIGNATURE----- --6a3W9IsGgor3MdLaUxkgICf1qeGqDLBam-- From nobody Tue Aug 18 07:31: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 5856E1A8866 for ; Tue, 18 Aug 2015 07:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBV8yc5XYB2L for ; Tue, 18 Aug 2015 07:31:16 -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 5BFBB1A885B for ; Tue, 18 Aug 2015 07:31:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2D919BE58; Tue, 18 Aug 2015 15:31:15 +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 fkt81PBZQX4e; Tue, 18 Aug 2015 15:31:15 +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 00E11BE5D; Tue, 18 Aug 2015 15:31:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439908275; bh=n2tMueiDRCiDs5NYk4fAh4eVLxoFjEIjSzQahTpjpE8=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=Mfa8S6cUghISzrYsM4+MDoQykq/CvBr5ic5ViqTvICX1e/9GKJNnMlcYtGfkd7erc bbxoVzhQyDPECx+YRdZhvv2RTIMGDQlFFej1Y5xhscqLAfngyVBXfUMEwMJFdOrGf4 SwihMU87YVXSwmOb6Q2jIojFdUoyM4mTLoTiItf0= Message-ID: <55D341B2.6010109@cs.tcd.ie> Date: Tue, 18 Aug 2015 15:31:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Richard Barnes , Phil Lello References: <55CE5A40.3090804@cs.tcd.ie> <55CF35B2.9020302@cs.tcd.ie> <97152.1439858222@eng-mail01.juniper.net> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] NIST requests comments on using ISO/IEC 19790:2012 as the U.S. Federal Standard for cryptographic modules 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, 18 Aug 2015 14:31:18 -0000 On 18/08/15 14:47, Richard Barnes wrote: > On Tue, Aug 18, 2015 at 5:33 AM, Phil Lello wrote: >> I'd just like to clarify that my objection to the paywall isn't about paying >> for the standard per-se, as it would be reasonable to pay a fee as an >> implementor (much like paying to access C++ standards to write a compiler). >> The objection is specifically about needing to pay to access the standard as >> part of a review process, as the fee is a barrier to broad evaluation. > > Well, then let me explicitly disagree with this position. The > standards that run the Internet need to be widely implemented, and > that means the specs need to be widely available. As Russ observed, > the current FIPS standards are freely available, so moving to a > paywalled standard would be a major step backwards. And a step > backwards for, AFAICT, no benefit. One of the reasons I asked if someone was willing to take a 1st cut at drafting some text is that, since I am not going to be reading the document behind the paywall, I have no clue if Richard is correct when he says "for, AFAICT, no benefit." (Since I've not read the thing;-) If an IETF/IAB/IESG/whatever response really ought also say something about the technical content, as well as the open-ness aspect of the process, then I at least will be depending on folks who have peeked behind that particular curtain to see what the wizard looks like. Or if none of us do, then I guess we could say that:-) Cheers, S. > > I would also observe that "free for review, pay for implementation" is > not really a realistic position. If anyone can download the spec for > review, then it will be out there on the Internet after it's > finalized. Much like the C++ spec, in fact (see the links in > https://en.wikipedia.org/wiki/C%2B%2B). And in practice that just > means that everyone will use the free "almost final" version, not the > paywalled "final" version. > > --Richard > > >> >> Phil >> >> On Tue, Aug 18, 2015 at 1:37 AM, Mark D. Baushke wrote: >>> >>> It may be worth noting that NIST actually put the wrong edition of the >>> ISO/IEC standard in the Federal Register article... They intended to put >>> 19790:2012 instead. >>> >>> See also >>> >>> http://csrc.nist.gov/groups/STM/cmvp/notices.html >>> >>> -- Mark >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Tue Aug 18 18:03: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 8C7BF1A2130 for ; Tue, 18 Aug 2015 18:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xus-8rohj21O for ; Tue, 18 Aug 2015 18:03:21 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27731A21A0 for ; Tue, 18 Aug 2015 18:03:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.218.207; From: "Susan Hares" To: References: In-Reply-To: Date: Tue, 18 Aug 2015 21:03:18 -0400 Message-ID: <01cb01d0da1a$d652f470$82f8dd50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CC_01D0D9F9.4F45E850" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGdftgYrTxMM4fgXu6G1IsGfy/Iip55KD4Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jon Hudson' Subject: Re: [saag] SEC-DIR QA review of draft-ietf-trill-channel-tunnel-07.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: Wed, 19 Aug 2015 01:03:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01CC_01D0D9F9.4F45E850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Saag: Would you review following four drafts from TRILL which create a new directory service mechanism for IP/MAC address mappings? In you QA review, would determine if the security mechanisms in this IP address/MAC Address have: good security mechanisms and meet the privacy concerns? These 4 drafts are in the process of Routing QA reviews and IANA Reviews (where appropriate). 1) TRILL: Edge Directory Assist Mechanisms: This draft provides the overview of the TRILL directory mechanisms. These mechanisms aim at reducing multi-destination traffic, particularly ARP/ND and unknown unicast flooding. It can also be used to detect traffic with forged source addresses. Routing QA review on draft-trill-directory-assist-mechanisms-03.txt https://mailarchive.ietf.org/arch/msg/trill/9QMAY54iiheEzFOKPLdv59QdA7M Note: Draft has not been revised to handle these comments. 2) draft-ietf-trill-arp-optimization - This draft describes how reduce ARP/ND traffic within a TRILL Campus by the following mechanisms: a) learning MAC/IP addresses maping via ISIS application sub-TLVor b) getting IP/MAC addresses from directory services (push/pull). This draft gives step by step instructions on the mechanisms. Routing QA review: http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html Note: Draft has not been revised to handle these comments. 3) draft-ietf-trill-channel-tunnel-07.txt on your QA review: The TRILL directory mechanisms have push/pull mechanisms. The draft-ietf-trill-channel-tunnel draft is needed to provide a mechanism to secure pull directory messages. Push directory messages are IS-IS PDUs so these drafts can use IS-IS authentication. 4) draft-ietf-trill-ia-appsubtlv-05: This draft reports of addresses for TRILL interfaces in ISIS application sub-TLV (reduces/replaces need for ARP/ND ) Note: No Routing QA Review yet (awaiting review) Thank you, Sue Hares TRILL-co-chair and document shepherd for this group. ------=_NextPart_000_01CC_01D0D9F9.4F45E850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Saag: =

 

Would you review following four drafts from TRILL which = create a new directory service mechanism for IP/MAC address = mappings?   In you QA review, would  determine if the = security mechanisms in this IP address/MAC Address have: good security = mechanisms and meet the privacy concerns? =

 

These 4 = drafts are in the process of Routing QA reviews and IANA Reviews (where = appropriate).   

 

1)       = TRILL: Edge Directory Assist Mechanisms: This draft = provides the overview of the TRILL directory mechanisms.  These = mechanisms aim at reducing multi-destination traffic, particularly = ARP/ND and unknown unicast flooding. It can also be used to detect = traffic with forged source addresses.

 

Routing QA review on draft-trill-directory-assist-mechanisms-03.txt =   https://mailarchive.ietf.org/arch/msg/trill/9QMAY54iiheEzFOKPLdv5= 9QdA7M

 

Note: =  Draft has not been revised to handle these comments. =

 

2)       = draft-ietf-trill-arp-optimization - This draft describes how = reduce ARP/ND traffic within a TRILL Campus by the following mechanisms: = a) learning MAC/IP addresses maping via ISIS application sub-TLVor b) getting IP/MAC addresses from directory = services (push/pull).  This draft gives step by step instructions = on the mechanisms.

 

Routing QA review: http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html=

 

=

Note: Draft has not been = revised to handle these comments.

 

=

3)       =  draft-ietf-trill-chann= el-tunnel-07.txt on your QA review: = The TRILL directory mechanisms have push/pull mechanisms. =  The draft-ietf-trill-channel-tunnel = draft is needed to provide a mechanism to secure pull directory = messages.  Push directory messages are IS-IS PDUs so these drafts = can use IS-IS authentication.

 

4)      = draft-ietf-trill-ia-appsubtlv-05:  This draft reports of = addresses for TRILL interfaces in ISIS application sub-TLV = (reduces/replaces need for ARP/ND )

 

Note: No Routing QA Review yet (awaiting review) =

 

 

=

Thank you, =

 

=

Sue Hares =

TRILL-co-chair and document shepherd for this group. =

 

------=_NextPart_000_01CC_01D0D9F9.4F45E850-- From nobody Tue Aug 18 18:17:41 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 5B3351A6F2F for ; Tue, 18 Aug 2015 18:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g6vKzHNHon7 for ; Tue, 18 Aug 2015 18:17:38 -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 C5B641A6F28 for ; Tue, 18 Aug 2015 18:17:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3DBCCBE7B; Wed, 19 Aug 2015 02:17:36 +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 4w3NOtPeBBQR; Wed, 19 Aug 2015 02:17:34 +0100 (IST) Received: from [127.0.0.1] (unknown [86.42.22.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8E6A5BE75; Wed, 19 Aug 2015 02:17:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439947054; bh=U/kNNFk9Ec/BrcyofrJvfXsStVpbN8KjzAfOazvtyIk=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=BKfJw9tXpZXShlR/j581k5xM5UIriC3w//ayngQxh2BdcgkkMC3BBwyqEMIFeTVE1 yfVVi9zURAWkKcy7m44mGAKk/94hQW1500wMYiWPwHM1VKIcWDB6XcIQF/wv6etV9r FpnRLIB82wnpHCZ83J7kKqTg1dpTIxq9tl5CqByQ= X-Priority: 3 To: shares@ndzh.com From: stephen.farrell@cs.tcd.ie In-Reply-To: <01cb01d0da1a$d652f470$82f8dd50$@ndzh.com> References: <01cb01d0da1a$d652f470$82f8dd50$@ndzh.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Wed, 19 Aug 2015 01:17:30 +0000 Message-ID: MIME-Version: 1.0 Archived-At: Cc: saag@ietf.org, jon.hudson@gmail.com Subject: Re: [saag] SEC-DIR QA review of draft-ietf-trill-channel-tunnel-07.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: Wed, 19 Aug 2015 01:17:40 -0000 U3VlLA0KDQpIb3cgbWFueSBtb3JlIGFyZSBvbiB0aGUgd2F5PyBJIGZlYXIgdG9vIG1hbnkgYXNr cyBtaWdodCBjYXVzZSBmZXdlciByZXNwb25zZXMuDQoNClRhLA0KUy4NCg0KT24gV2VkIEF1ZyAx OSAwMjowMzoxOCAyMDE1IEdNVCswMTAwLCBTdXNhbiBIYXJlcyB3cm90ZToNCj4gU2FhZzogDQo+ IA0KPiAgDQo+IA0KPiBXb3VsZCB5b3UgcmV2aWV3IGZvbGxvd2luZyBmb3VyIGRyYWZ0cyBmcm9t IFRSSUxMIHdoaWNoIGNyZWF0ZSBhIG5ldw0KPiBkaXJlY3Rvcnkgc2VydmljZSBtZWNoYW5pc20g Zm9yIElQL01BQyBhZGRyZXNzIG1hcHBpbmdzPyAgIEluIHlvdSBRQSByZXZpZXcsDQo+IHdvdWxk ICBkZXRlcm1pbmUgaWYgdGhlIHNlY3VyaXR5IG1lY2hhbmlzbXMgaW4gdGhpcyBJUCBhZGRyZXNz L01BQyBBZGRyZXNzDQo+IGhhdmU6IGdvb2Qgc2VjdXJpdHkgbWVjaGFuaXNtcyBhbmQgbWVldCB0 aGUgcHJpdmFjeSBjb25jZXJucz8gDQo+IA0KPiAgDQo+IA0KPiBUaGVzZSA0IGRyYWZ0cyBhcmUg aW4gdGhlIHByb2Nlc3Mgb2YgUm91dGluZyBRQSByZXZpZXdzIGFuZCBJQU5BIFJldmlld3MNCj4g KHdoZXJlIGFwcHJvcHJpYXRlKS4gICANCj4gDQo+ICANCj4gDQo+IDEpICAgICAgIFRSSUxMOiBF ZGdlIERpcmVjdG9yeSBBc3Npc3QgTWVjaGFuaXNtczogVGhpcyBkcmFmdCBwcm92aWRlcyB0aGUN Cj4gb3ZlcnZpZXcgb2YgdGhlIFRSSUxMIGRpcmVjdG9yeSBtZWNoYW5pc21zLiAgVGhlc2UgbWVj aGFuaXNtcyBhaW0gYXQNCj4gcmVkdWNpbmcgbXVsdGktZGVzdGluYXRpb24gdHJhZmZpYywgcGFy dGljdWxhcmx5IEFSUC9ORCBhbmQgdW5rbm93biB1bmljYXN0DQo+IGZsb29kaW5nLiBJdCBjYW4g YWxzbyBiZSB1c2VkIHRvIGRldGVjdCB0cmFmZmljIHdpdGggZm9yZ2VkIHNvdXJjZQ0KPiBhZGRy ZXNzZXMuDQo+IA0KPiAgDQo+IA0KPiBSb3V0aW5nIFFBIHJldmlldyBvbiBkcmFmdC10cmlsbC1k aXJlY3RvcnktYXNzaXN0LW1lY2hhbmlzbXMtMDMudHh0DQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvdHJpbGwvOVFNQVk1NGlpaGVFekZPS1BMZHY1OVFkQTdNDQo+IA0K PiAgDQo+IA0KPiBOb3RlOiAgRHJhZnQgaGFzIG5vdCBiZWVuIHJldmlzZWQgdG8gaGFuZGxlIHRo ZXNlIGNvbW1lbnRzLiANCj4gDQo+ICANCj4gDQo+IDIpICAgICAgIGRyYWZ0LWlldGYtdHJpbGwt YXJwLW9wdGltaXphdGlvbiAtIFRoaXMgZHJhZnQgZGVzY3JpYmVzIGhvdyByZWR1Y2UNCj4gQVJQ L05EIHRyYWZmaWMgd2l0aGluIGEgVFJJTEwgQ2FtcHVzIGJ5IHRoZSBmb2xsb3dpbmcgbWVjaGFu aXNtczogYSkNCj4gbGVhcm5pbmcgTUFDL0lQIGFkZHJlc3NlcyBtYXBpbmcgdmlhIElTSVMgYXBw bGljYXRpb24gc3ViLVRMVm9yIGIpIGdldHRpbmcNCj4gSVAvTUFDIGFkZHJlc3NlcyBmcm9tIGRp cmVjdG9yeSBzZXJ2aWNlcyAocHVzaC9wdWxsKS4gIFRoaXMgZHJhZnQgZ2l2ZXMgc3RlcA0KPiBi eSBzdGVwIGluc3RydWN0aW9ucyBvbiB0aGUgbWVjaGFuaXNtcy4gDQo+IA0KPiAgDQo+IA0KPiBS b3V0aW5nIFFBIHJldmlldzoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3J0Zy1kaXIvY3VycmVudC9tc2cwMjYwNi5odG1sDQo+IA0KPiAgDQo+IA0KPiBOb3RlOiBEcmFm dCBoYXMgbm90IGJlZW4gcmV2aXNlZCB0byBoYW5kbGUgdGhlc2UgY29tbWVudHMuIA0KPiANCj4g IA0KPiANCj4gMykgICAgICAgIGRyYWZ0LWlldGYtdHJpbGwtY2hhbm5lbC10dW5uZWwtMDcudHh0 IG9uIHlvdXIgUUEgcmV2aWV3OiBUaGUNCj4gVFJJTEwgZGlyZWN0b3J5IG1lY2hhbmlzbXMgaGF2 ZSBwdXNoL3B1bGwgbWVjaGFuaXNtcy4gIFRoZQ0KPiBkcmFmdC1pZXRmLXRyaWxsLWNoYW5uZWwt dHVubmVsIGRyYWZ0IGlzIG5lZWRlZCB0byBwcm92aWRlIGEgbWVjaGFuaXNtIHRvDQo+IHNlY3Vy ZSBwdWxsIGRpcmVjdG9yeSBtZXNzYWdlcy4gIFB1c2ggZGlyZWN0b3J5IG1lc3NhZ2VzIGFyZSBJ Uy1JUyBQRFVzIHNvDQo+IHRoZXNlIGRyYWZ0cyBjYW4gdXNlIElTLUlTIGF1dGhlbnRpY2F0aW9u Lg0KPiANCj4gIA0KPiANCj4gNCkgICAgICBkcmFmdC1pZXRmLXRyaWxsLWlhLWFwcHN1YnRsdi0w NTogIFRoaXMgZHJhZnQgcmVwb3J0cyBvZiBhZGRyZXNzZXMNCj4gZm9yIFRSSUxMIGludGVyZmFj ZXMgaW4gSVNJUyBhcHBsaWNhdGlvbiBzdWItVExWIChyZWR1Y2VzL3JlcGxhY2VzIG5lZWQgZm9y DQo+IEFSUC9ORCApDQo+IA0KPiAgDQo+IA0KPiBOb3RlOiBObyBSb3V0aW5nIFFBIFJldmlldyB5 ZXQgKGF3YWl0aW5nIHJldmlldykgDQo+IA0KPiAgDQo+IA0KPiAgDQo+IA0KPiBUaGFuayB5b3Us IA0KPiANCj4gIA0KPiANCj4gU3VlIEhhcmVzIA0KPiANCj4gVFJJTEwtY28tY2hhaXIgYW5kIGRv Y3VtZW50IHNoZXBoZXJkIGZvciB0aGlzIGdyb3VwLiANCj4gDQo+ICANCj4gDQo+ From nobody Tue Aug 18 18:34:41 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 99CE11A854D for ; Tue, 18 Aug 2015 18:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQqOaQSG5eBr for ; Tue, 18 Aug 2015 18:34:38 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2391A7035 for ; Tue, 18 Aug 2015 18:34:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.218.207; From: "Susan Hares" To: References: <01cb01d0da1a$d652f470$82f8dd50$@ndzh.com> In-Reply-To: Date: Tue, 18 Aug 2015 21:34:34 -0400 Message-ID: <01f701d0da1f$34ec09f0$9ec41dd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHAaYa2fX3u8KyFgrQWwvqpKyk8FgGLFGUKnicPPrA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: saag@ietf.org, jon.hudson@gmail.com Subject: Re: [saag] SEC-DIR QA review of draft-ietf-trill-channel-tunnel-07.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: Wed, 19 Aug 2015 01:34:39 -0000 Stephen:=20 I'm a WG chair for 3 WGs, and I'm pushing WG groups of WG drafts toward = the IESG publishing so it may seem like a large group:=20 Let me prioritize the drafts by WG:=20 1) I2RS - is a must have:=20 I2RS is in the midst of a disagreement over the security requirements. = Without Russ Housley's help to review it, we are stuck for this work. = Top priority=20 2) TRILL - is a "Nice to have" as we are using Crypto-suites in = tunneling protocol.=20 This is a QA review for the next group of TRILL - which is providing a = whole group of directory service. If you do not do this now, then it = will progress to IESG submission in September. Donald Eastlake worked = on these drafts so it is ok 3) BGP - "Nothing more/less than usual" status - for all drafts. =20 Sue=20 -----Original Message----- From: stephen.farrell@cs.tcd.ie [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Tuesday, August 18, 2015 9:18 PM To: shares@ndzh.com Cc: kathleen.moriarty.ietf@gmail.com; jon.hudson@gmail.com; = d3e3e3@gmail.com; saag@ietf.org Subject: Re: RE: SEC-DIR QA review of = draft-ietf-trill-channel-tunnel-07.txt Sue, How many more are on the way? I fear too many asks might cause fewer = responses. Ta, S. On Wed Aug 19 02:03:18 2015 GMT+0100, Susan Hares wrote: > Saag:=20 >=20 > =20 >=20 > Would you review following four drafts from TRILL which create a new > directory service mechanism for IP/MAC address mappings? In you QA = review, > would determine if the security mechanisms in this IP address/MAC=20 > Address > have: good security mechanisms and meet the privacy concerns?=20 >=20 > =20 >=20 > These 4 drafts are in the process of Routing QA reviews and IANA = Reviews > (where appropriate). =20 >=20 > =20 >=20 > 1) TRILL: Edge Directory Assist Mechanisms: This draft provides = the > overview of the TRILL directory mechanisms. These mechanisms aim at=20 > reducing multi-destination traffic, particularly ARP/ND and unknown=20 > unicast flooding. It can also be used to detect traffic with forged=20 > source addresses. >=20 > =20 >=20 > Routing QA review on draft-trill-directory-assist-mechanisms-03.txt > https://mailarchive.ietf.org/arch/msg/trill/9QMAY54iiheEzFOKPLdv59QdA7 > M >=20 > =20 >=20 > Note: Draft has not been revised to handle these comments.=20 >=20 > =20 >=20 > 2) draft-ietf-trill-arp-optimization - This draft describes how = reduce > ARP/ND traffic within a TRILL Campus by the following mechanisms: a)=20 > learning MAC/IP addresses maping via ISIS application sub-TLVor b)=20 > getting IP/MAC addresses from directory services (push/pull). This=20 > draft gives step by step instructions on the mechanisms. >=20 > =20 >=20 > Routing QA review: > http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html >=20 > =20 >=20 > Note: Draft has not been revised to handle these comments.=20 >=20 > =20 >=20 > 3) draft-ietf-trill-channel-tunnel-07.txt on your QA review: = The > TRILL directory mechanisms have push/pull mechanisms. The=20 > draft-ietf-trill-channel-tunnel draft is needed to provide a mechanism = > to secure pull directory messages. Push directory messages are IS-IS=20 > PDUs so these drafts can use IS-IS authentication. >=20 > =20 >=20 > 4) draft-ietf-trill-ia-appsubtlv-05: This draft reports of = addresses > for TRILL interfaces in ISIS application sub-TLV (reduces/replaces=20 > need for ARP/ND ) >=20 > =20 >=20 > Note: No Routing QA Review yet (awaiting review) >=20 > =20 >=20 > =20 >=20 > Thank you, >=20 > =20 >=20 > Sue Hares >=20 > TRILL-co-chair and document shepherd for this group.=20 >=20 > =20 >=20 > From nobody Tue Aug 18 19:01:56 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 A36791A8A0F for ; Tue, 18 Aug 2015 19:01:54 -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 kXCCIS6A-w1K for ; Tue, 18 Aug 2015 19:01:52 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 8F4CE1A8A08 for ; Tue, 18 Aug 2015 19:01:52 -0700 (PDT) Received: by qkcs67 with SMTP id s67so65566230qkc.1 for ; Tue, 18 Aug 2015 19:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G4rjHf/oYrHNDT4QfrY9lVx3nWpYWayATwcgWBYvjFA=; b=FXDOUI2tBwLUAezg+L/6UzxETDkvUoh5gryo3RjYQRuehVG0FuWWpa9dvWm9+hCGUI kGOzmmhDknVs8V1F9ZKFMR4N/fQMRO5cIA2T1RrXRRaGewlqExEWXmdZKDKzy6kVyZy8 myVHupvNYnvJoV7xoJM50WQJizp5W2H9ZagnnXVACUyUibt/2vT6FEmEynxwrcfP3bzi 2HA6xARKl6EZwK3TWNwuzM2NKF/Kfe3CpXunrQDGKQSzc86iaPo5IfT87n4kg9djiCn9 /DYBiZgUEQxpm06Sk/cEPefIfr8eMOtDcrRbUT/cQPRdlGJ6Xw65s4lGHZTiP/eoKxYy Rfxg== X-Received: by 10.55.40.162 with SMTP id o34mr18645340qko.106.1439949711757; Tue, 18 Aug 2015 19:01:51 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id 79sm3274550qkz.25.2015.08.18.19.01.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Aug 2015 19:01:51 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <01f701d0da1f$34ec09f0$9ec41dd0$@ndzh.com> Date: Tue, 18 Aug 2015 22:01:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01cb01d0da1a$d652f470$82f8dd50$@ndzh.com> <01f701d0da1f$34ec09f0$9ec41dd0$@ndzh.com> To: Susan Hares Archived-At: Cc: "" , "" Subject: Re: [saag] SEC-DIR QA review of draft-ietf-trill-channel-tunnel-07.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: Wed, 19 Aug 2015 02:01:54 -0000 As I understand it, Russ has agreed to cover #1, so we just need help in the= other 2 with #2 having priority. We could just request early reviews and have them put into the rotation if n= o one volunteers. Thanks, Kathleen=20 Sent from my iPhone > On Aug 18, 2015, at 9:34 PM, Susan Hares wrote: >=20 > Stephen:=20 >=20 > I'm a WG chair for 3 WGs, and I'm pushing WG groups of WG drafts toward th= e IESG publishing so it may seem like a large group:=20 >=20 > Let me prioritize the drafts by WG:=20 >=20 > 1) I2RS - is a must have:=20 >=20 > I2RS is in the midst of a disagreement over the security requirements. Wi= thout Russ Housley's help to review it, we are stuck for this work. Top prio= rity=20 >=20 > 2) TRILL - is a "Nice to have" as we are using Crypto-suites in tunneling= protocol.=20 >=20 > This is a QA review for the next group of TRILL - which is providing a who= le group of directory service. If you do not do this now, then it will pro= gress to IESG submission in September. Donald Eastlake worked on these dra= fts so it is ok >=20 > 3) BGP - "Nothing more/less than usual" status - for all drafts. =20 >=20 > Sue=20 >=20 >=20 > -----Original Message----- > From: stephen.farrell@cs.tcd.ie [mailto:stephen.farrell@cs.tcd.ie]=20 > Sent: Tuesday, August 18, 2015 9:18 PM > To: shares@ndzh.com > Cc: kathleen.moriarty.ietf@gmail.com; jon.hudson@gmail.com; d3e3e3@gmail.c= om; saag@ietf.org > Subject: Re: RE: SEC-DIR QA review of draft-ietf-trill-channel-tunnel-07.t= xt >=20 > Sue, >=20 > How many more are on the way? I fear too many asks might cause fewer respo= nses. >=20 > Ta, > S. >=20 >> On Wed Aug 19 02:03:18 2015 GMT+0100, Susan Hares wrote: >> Saag:=20 >>=20 >>=20 >>=20 >> Would you review following four drafts from TRILL which create a new >> directory service mechanism for IP/MAC address mappings? In you QA revi= ew, >> would determine if the security mechanisms in this IP address/MAC=20 >> Address >> have: good security mechanisms and meet the privacy concerns?=20 >>=20 >>=20 >>=20 >> These 4 drafts are in the process of Routing QA reviews and IANA Reviews >> (where appropriate). =20 >>=20 >>=20 >>=20 >> 1) TRILL: Edge Directory Assist Mechanisms: This draft provides the= >> overview of the TRILL directory mechanisms. These mechanisms aim at=20 >> reducing multi-destination traffic, particularly ARP/ND and unknown=20 >> unicast flooding. It can also be used to detect traffic with forged=20 >> source addresses. >>=20 >>=20 >>=20 >> Routing QA review on draft-trill-directory-assist-mechanisms-03.txt >> https://mailarchive.ietf.org/arch/msg/trill/9QMAY54iiheEzFOKPLdv59QdA7 >> M >>=20 >>=20 >>=20 >> Note: Draft has not been revised to handle these comments.=20 >>=20 >>=20 >>=20 >> 2) draft-ietf-trill-arp-optimization - This draft describes how red= uce >> ARP/ND traffic within a TRILL Campus by the following mechanisms: a)=20 >> learning MAC/IP addresses maping via ISIS application sub-TLVor b)=20 >> getting IP/MAC addresses from directory services (push/pull). This=20 >> draft gives step by step instructions on the mechanisms. >>=20 >>=20 >>=20 >> Routing QA review: >> http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html >>=20 >>=20 >>=20 >> Note: Draft has not been revised to handle these comments.=20 >>=20 >>=20 >>=20 >> 3) draft-ietf-trill-channel-tunnel-07.txt on your QA review: The >> TRILL directory mechanisms have push/pull mechanisms. The=20 >> draft-ietf-trill-channel-tunnel draft is needed to provide a mechanism=20= >> to secure pull directory messages. Push directory messages are IS-IS=20 >> PDUs so these drafts can use IS-IS authentication. >>=20 >>=20 >>=20 >> 4) draft-ietf-trill-ia-appsubtlv-05: This draft reports of addresse= s >> for TRILL interfaces in ISIS application sub-TLV (reduces/replaces=20 >> need for ARP/ND ) >>=20 >>=20 >>=20 >> Note: No Routing QA Review yet (awaiting review) >>=20 >>=20 >>=20 >>=20 >>=20 >> Thank you, >>=20 >>=20 >>=20 >> Sue Hares >>=20 >> TRILL-co-chair and document shepherd for this group. >=20 From nobody Mon Aug 24 09:58:23 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 4BA9D1A8A09; Mon, 24 Aug 2015 09:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, 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 j4D9zsrvft2P; Mon, 24 Aug 2015 09:58:20 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id ED1B71A8968; Mon, 24 Aug 2015 09:58:18 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A232A10224008; Mon, 24 Aug 2015 09:58:18 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 24 Aug 2015 09:58:18 -0700 (PDT) Message-ID: In-Reply-To: References: <449964e467e0347db185eb787db71efd.squirrel@www.trepanning.net> Date: Mon, 24 Aug 2015 09:58:18 -0700 (PDT) From: "Dan Harkins" To: "Joseph Salowey" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "saag@ietf.org" , "emu@ietf.org" Subject: Re: [saag] Feedback on Salted EAP draft 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, 24 Aug 2015 16:58:22 -0000 Hi Joe, On Sun, August 16, 2015 9:33 pm, Joseph Salowey wrote: > Hi Dan, > > I read the latest version of the draft (-02) and it looks mostly good to > me. some comments: > > I think you want to change the RFC references in the abstract from RFC > 2751 > to RFC 2759. Yes, good catch! I am not referring to the "Signaled Preemption Priority Policy Element." :-) > One question I have is there any reason why you specify the input of the > hash function as password | salt instead of the other way around? Is this > the way it is done in practice? I actually asked whether this was how it was done in eduroam and did not get definitive answer back. When I poked around in the results of a "how to hash passwords" query there were a few examples that had code and they did it that way. If you know of a counter example, please speak up while the cement has yet to dry. regards, Dan. > Thanks, > > Joe > > On Thu, Aug 13, 2015 at 2:35 PM, Dan Harkins wrote: > >> >> Hi Christian, >> >> On Tue, July 14, 2015 10:50 am, Christian Huitema wrote: >> [snip] >> > The draft is short and clear enough, but it acknowledges a pretty big >> > security issue: "the salted >> > password from a compromised database can be used directly to >> impersonate >> > the client-- there >> > is no dictionary attack needed to recover the plaintext password." >> > >> > That's a pretty big caveat, but there are still some advantages over >> > operating with unsalted passwords. The draft aligns server side >> password >> > management for EAP-pwd with standard industry practices, which is >> good. >> > In case of server compromise, the immediate effect of the compromise >> is >> an >> > attack on the already compromised server, and the per-user salt make >> > password discovery harder. The security section should be expanded to >> > explain this tradeoff. >> >> Yes, it's a big caveat and, as I mentioned, I'm trying to >> be as blunt as possible about it. I have updated the Security >> Considerations to include the point you are making about server >> compromise and the per-user salt still making password recovery >> harder. >> >> > Nits: >> > >> > - in the abstract, missing "not" in " but did (not?) include support >> for >> > salted passwords." >> >> Nice catch. >> >> An -02 version has been posted. Would you please take a look >> and let me know whether it satisfactorily addresses your comments? >> >> regards, >> >> Dan. >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > From nobody Mon Aug 24 13:31:21 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 145BA1B3282 for ; Mon, 24 Aug 2015 13:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 hboupLdAIB8Y for ; Mon, 24 Aug 2015 13:31:18 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 D4A6A1B3280 for ; Mon, 24 Aug 2015 13:31:17 -0700 (PDT) Received: by widdq5 with SMTP id dq5so61194875wid.1 for ; Mon, 24 Aug 2015 13:31:16 -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 :content-type; bh=N4jz8E2mQl0UazD1N/GqFMJqcHwxWUNuwl4N0Yzfkv0=; b=wmxNS0TDwjA2UvmKxx9HrtpL4FaJCFTifN2c4RMCWTzlSSTgk6u7mOhZKXj+x3VDQD tE9PPxNDT1KgQKV4j30sS1DWzXgyDENml4cZia2oeyRTgtn+pG9j+9Uv/yJzL+M/LQuL 9d+tB2sCLWlrr6QfilC+2nLzvMry/FwOKCuFXVRLLZXlnmeybhhSaOTmCBVzyZ2az8aR HhU63+j1N0BrfN8zUaHapiHHz1lO+y0lVnq/wmnymAKHKQkN6wGXIi0nTNYjZEvzJcZB VgdYa1OwrMGhok+dBDgQoyrjsF1ZAe9IgkzqPanrf8IViFu3NvVWtk4c4QmxJCBEMHnJ TKbg== MIME-Version: 1.0 X-Received: by 10.180.73.229 with SMTP id o5mr31982706wiv.36.1440448276617; Mon, 24 Aug 2015 13:31:16 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Mon, 24 Aug 2015 13:31:16 -0700 (PDT) In-Reply-To: <20150728053035.GR4347@mournblade.imrryr.org> References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> Date: Mon, 24 Aug 2015 16:31:16 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 24 Aug 2015 20:31:20 -0000 After reading through this thread again, I don't think we have clear consensus to match statements being made in this draft in section 2.9: 2.9. Opportunistic Security 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, weaker algorithms and shorter key sizes are also acceptable for opportunistic security. That said, the use of strong algorithms is always preferable. Maybe I'm in the rough, but I read through many varying opinions in this thread, with contributors each having their own caveat to the general statement, yet we have general statements in the OS RFC and this draft. The first sentence in this section counters what Viktor is saying was intended in the OS RFC (per this thread), that this provision should only apply to legacy systems. When protocols are designed, appropriate crypto should be specified. Then it is better to use outdated rather than nothing later on in deployment cycles. Others added in additional caveats to the general statement, so I don't think we really have consensus on this set of points. I'm personally okay with the concept that using deprecated algorithms is better than nothing, but I'd rather it be clear that this choice is not in compliance with current recommendations otherwise we will never be able to complete transitions. As such, I'd rather it not be part of how we discuss OS since it only appears as a couple sentences in the overall RFC. As with S/MIME, this would just be a hold out due to upgrade complications with older implementations - it's ok, but not okay as part of OS giving it an excuse to stick around longer. If others think I'm in the rough, it would be good to know. Thanks, Kathleen On Tue, Jul 28, 2015 at 1:30 AM, Viktor Dukhovni wrote: > On Tue, Jul 28, 2015 at 04:54:58AM +0000, Christian Huitema wrote: > >> OS is by definition prone to MITM attacks, including downgrade attacks. > > [ Yes, when not authenticated. There's also downgrade-resistant OS, via > e.g. DANE, but not widely deployed at present. ] > >> Just negotiating any which algorithm key that comes out of the channel is >> too dangerous for my taste. If we do OS we should also enable a form of >> MITM detection, maybe channel binding. It will not be used in all OS >> connections, but using it in some connections in an unpredictable should >> be enough to detect and deter mass deployment of MITM. > > I agree this is desirable, but it is rather difficult to make MiTM > detection practical in many cases, e.g. email. Sure one could log > channel-unique tags on both sides, but who's going to ever compare > them? > > One might propagate the tags along the forward-path in new trace > headers, but those would need to be signed by the previous-hop MTA, > at which point, we're no longer talking about unauthenticated > opportunistic TLS. > > The trick is finding a way to make it possible and worthwhile for > a sufficient fraction of participants to add the requsiite checks. > This can work for interactive protocols (humans on phone verbally > verify matching channel-ids), but is rather difficult for > store-and-forward. > > For SMTP transport at least, DANE looks like a more promising > counter-measure to active attacks. > > -- > VIktor. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Best regards, Kathleen From nobody Mon Aug 24 13:47:23 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 D8EDE1ACD1D for ; Mon, 24 Aug 2015 13:47:21 -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 n9-cAiBpiyT5 for ; Mon, 24 Aug 2015 13:47:20 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 A1C031A1A80 for ; Mon, 24 Aug 2015 13:47:20 -0700 (PDT) Received: by qkfh127 with SMTP id h127so87799491qkf.1 for ; Mon, 24 Aug 2015 13:47:19 -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=x+KPjxs2NSbxosK6+1anUbVcWX0soRS9I7yZKkiDhL4=; b=qdpatlKjFhMyEPfhSHC2f2K2ij4mWzL3cnUVUqeDMQfO83Q0JdoCGxu150sQsa5xfN PkLZvvWaUT5Ovtc8PMJ3QzmXCG5yiausSiXmCyzBsYjEpjm/9sqP3qtrfhDLFzLUjnby dO3wOlMlknopgQ9x81CKZ7/Ef3wdEIJ+7g3jQ+GAoWtcAQ+rRZYMkYHvUSdOqP/uBkeE D4dDUvR4PQoZ7O5NoR1xoHhW//7/2LyQ0tNVVv/+4BBT9z/Aw2aD+gzO7l2ZgZcvb9Ha FNejxXkzu7AOoh4ghivoa9hceWt7mePr33dz/+XFbvsAPqBFb+FHQwsK/EM0ElMJ7Zkv LGpw== MIME-Version: 1.0 X-Received: by 10.170.199.7 with SMTP id q7mr3099501yke.57.1440449239875; Mon, 24 Aug 2015 13:47:19 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Mon, 24 Aug 2015 13:47:19 -0700 (PDT) In-Reply-To: References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> Date: Mon, 24 Aug 2015 13:47:19 -0700 Message-ID: From: Martin Thomson To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 24 Aug 2015 20:47:22 -0000 On 24 August 2015 at 13:31, Kathleen Moriarty wrote: > If others think I'm in the rough, it would be good to know. I think that you have it right. New protocol work has different deployment constraints with respect to security. New stuff can (and should) be encrypted always. From nobody Mon Aug 24 14:29: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 896551AD0C6 for ; Mon, 24 Aug 2015 14:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptArh9vs4wMJ for ; Mon, 24 Aug 2015 14:29:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39EC21ACDFA for ; Mon, 24 Aug 2015 14:29:08 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 60ED4284D64; Mon, 24 Aug 2015 21:29:07 +0000 (UTC) Date: Mon, 24 Aug 2015 21:29:07 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150824212907.GN9021@mournblade.imrryr.org> References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 21:29:10 -0000 On Mon, Aug 24, 2015 at 04:31:16PM -0400, Kathleen Moriarty wrote: > The first sentence in this section counters what Viktor is saying was > intended in the OS RFC (per this thread), that this provision should > only apply to legacy systems. When protocols are designed, > appropriate crypto should be specified. Then it is better to use > outdated rather than nothing later on in deployment cycles. Others > added in additional caveats to the general statement, so I don't think > we really have consensus on this set of points. Yes. OS is supposed to enable a transparent "upgrade" from cleartext to encryption (possibly with peer authentication). With *legacy* protocols, when negotiating unauthenticated opportunistic encryption, it is important to not exclude recently obsoleted algorithms that are still needed for interoperability lest failing to offer them cause communications failure or needless use of cleartext. When designing new protocols, it makes sense to set a realistic floor that excludes already deprecated crypto, and then not supporting the obsolete algorithms does not risk failure to communicate or needless use of cleartext. -- Viktor. From nobody Mon Aug 24 14:32:43 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 D59F81AD366 for ; Mon, 24 Aug 2015 14:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, 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 xSYTh-i8lgzT for ; Mon, 24 Aug 2015 14:32:40 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 632F31AD364 for ; Mon, 24 Aug 2015 14:32:40 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C5D2074000F for ; Mon, 24 Aug 2015 21:32:39 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id AC0E1740001 for ; Mon, 24 Aug 2015 21:32:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1440451959; bh=Oft9TsnZ8awl0UvOlgeDwjDnRqVJs9cyrulRKREDG0c=; l=519; h=From:To:Date:References:In-Reply-To:From; b=z9If2wLcR0GMEHq3Nc6vaUd/dr2YtfvOC7LCj0Fm+Uz8Wq020Pf8lwmBnnf4Hd+sG QaGV10mQaMJlg3F+lMNOP46quXG78PD+RXAbcr5+sH+X2X97Hw1H4VAfMoJUK92ze7 751ioS8jJZO68zJg1xTbyu/Ubt4QTKiOxWKauqk4= Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id A8C6D98084 for ; Mon, 24 Aug 2015 21:32:39 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 24 Aug 2015 16:32:39 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Mon, 24 Aug 2015 16:32:39 -0500 From: "Salz, Rich" To: "saag@ietf.org" Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQ3qvj021A7RxjOEahYRWcAOaGUp4b/kqA//+syqA= Date: Mon, 24 Aug 2015 21:32:38 +0000 Message-ID: <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> In-Reply-To: <20150824212907.GN9021@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 24 Aug 2015 21:32:42 -0000 > With *legacy* protocols, when negotiating unauthenticated opportunistic > encryption, it is important to not exclude recently obsoleted algorithms = that > are still needed for interoperability lest failing to offer them cause > communications failure or needless use of cleartext. And here, I think, is the rub. SMTP is a legacy protocol. Is opportunistically-encrypted SMTP a legacy pr= otocol? How long has it been in common use? How old is the crypto that th= ese deployed systems have access to? From nobody Mon Aug 24 14:38: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 2A3601A8A0E for ; Mon, 24 Aug 2015 14:38:50 -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 PRCVOANprwpi for ; Mon, 24 Aug 2015 14:38:48 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 B80621A897B for ; Mon, 24 Aug 2015 14:38:48 -0700 (PDT) Received: by qgeg42 with SMTP id g42so95780614qge.1 for ; Mon, 24 Aug 2015 14:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u1MrGZ/j5cIg7dV2e2kkWPDLov4IB/nL8eFam5NJopY=; b=Eem357mWzU4YPtLX6CjWbBQ+0Ey6dCHNN17pfCNh8qGWSQO/hqqFkCF/hrwQOlI3KM VDwLpp8OKtT4dQiYUx5QA7784ICcheDjPk6Tgf/uKqpODQ+pvktagE7l1Lw9GhEmubk1 J1NiJErrfuaHx14V1bCHhlutRh9Uj6X1jwMC77c13MCAyi+LxS3vf1sr5thhUGvIT9R9 6h17KpTAKAj8y/c+jRXWNqc6ajm4UMjRYcx50bzZ+lwOQyIkNOl/D5iEMV5lXYutzu6S Y8+E3I6CAkmvdjs3TvBicQazYOQnaZTDO0YLQhaYGX4XFCE5F4F4A+70VRHeWxgFsuyJ DtTw== X-Received: by 10.140.231.208 with SMTP id b199mr62405664qhc.87.1440452327815; Mon, 24 Aug 2015 14:38:47 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id s64sm10386794qgs.33.2015.08.24.14.38.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Aug 2015 14:38:47 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Mon, 24 Aug 2015 17:38:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <846AD897-C38F-4528-849D-B98B2D87798B@gmail.com> References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> To: "Salz, Rich" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 24 Aug 2015 21:38:50 -0000 Sent from my iPhone On Aug 24, 2015, at 5:32 PM, Salz, Rich wrote: >> With *legacy* protocols, when negotiating unauthenticated opportunistic >> encryption, it is important to not exclude recently obsoleted algorithms t= hat >> are still needed for interoperability lest failing to offer them cause >> communications failure or needless use of cleartext. >=20 > And here, I think, is the rub. >=20 > SMTP is a legacy protocol. Is opportunistically-encrypted SMTP a legacy p= rotocol? How long has it been in common use? How old is the crypto that th= ese deployed systems have access to? >=20 I agree this is the problem/poster child for this discussion. I'd rather ph= rase it that in some cases, deprecated crypto will be used when libraries/so= ftware can't be updated rather than saying it's okay because it falls into O= S. But this may just be me. Thanks, Kathleen=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Aug 24 14:40: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 BB7AB1B2B66 for ; Mon, 24 Aug 2015 14:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, 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 hqBbXw8Qx0C5 for ; Mon, 24 Aug 2015 14:40:26 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6241B2B40 for ; Mon, 24 Aug 2015 14:40:26 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B68364803B; Mon, 24 Aug 2015 21:40:25 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id A08DB48036; Mon, 24 Aug 2015 21:40:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1440452425; bh=fScFsV5TAG+ZZePTB+k6F3lCuyGotUD54xGTSKeGyBI=; l=303; h=From:To:CC:Date:References:In-Reply-To:From; b=mbTXz+9xZgrk1rYZmUJ3EFVvRz3Of2y+3yEDVU7v51kpOI1rYjEdpLlPyJClzbOPM oyh6xtXKhOW0jzg59C3KbsQktTCvS3aIHsuh8dO7cyT93A4jGgsfF9Ldd2Xhs8c7Dg hXR+mzJ8aEykSg6lao1kc61BDC1wC4GtI84StMbU= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 9D57198082; Mon, 24 Aug 2015 21:40:25 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 24 Aug 2015 16:40:22 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Mon, 24 Aug 2015 16:40:22 -0500 From: "Salz, Rich" To: Kathleen Moriarty Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQ3qvj021A7RxjOEahYRWcAOaGUp4b/kqA//+syqCAAFXoAP//rITw Date: Mon, 24 Aug 2015 21:40:22 +0000 Message-ID: References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <846AD897-C38F-4528-849D-B98B2D87798B@gmail.com> In-Reply-To: <846AD897-C38F-4528-849D-B98B2D87798B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 24 Aug 2015 21:40:30 -0000 > I agree this is the problem/poster child for this discussion. I'd rather= phrase it > that in some cases, deprecated crypto will be used when libraries/softwar= e > can't be updated rather than saying it's okay because it falls into OS. = But this > may just be me. It's not just you. :) From nobody Mon Aug 24 14:45: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 9C3A81B2B89 for ; Mon, 24 Aug 2015 14:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTmc5PQ2v5Uh for ; Mon, 24 Aug 2015 14:45:45 -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 936391B2B77 for ; Mon, 24 Aug 2015 14:45:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E3A85BF13; Mon, 24 Aug 2015 22:45:43 +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 cctLIgNse5fN; Mon, 24 Aug 2015 22:45:42 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.21.200]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CE629BF10; Mon, 24 Aug 2015 22:45:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440452741; bh=58U4BSsOtcNID152+T+7ikpzuVzYJRYOd50QBrL658o=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=ur1m5HeRmaoRtlnHF8Pzzys2gHzU7NWscziKYNjuZe3yS/MEs1+iSuKVd4XvUNTvG VXPt7zHnm1frty6VYaKD1cr425e4a3yXv9n8kZ05GubvOp8S8tyOQDeCasdUykliWX OTfngjH7dmrxWoQgjvEc22TSXgEbDHIqIMH/QAUM= Message-ID: <55DB9085.2080504@cs.tcd.ie> Date: Mon, 24 Aug 2015 22:45:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "Salz, Rich" , Kathleen Moriarty References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <846AD897-C38F-4528-849D-B98B2D87798B@gmail.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 24 Aug 2015 21:45:47 -0000 On 24/08/15 22:40, Salz, Rich wrote: >> I agree this is the problem/poster child for this discussion. I'd rather phrase it >> that in some cases, deprecated crypto will be used when libraries/software >> can't be updated rather than saying it's okay because it falls into OS. But this >> may just be me. > > It's not just you. :) And me too. However, there was strong push back to that from apps folks when we debated this before. So even though I think all 3 of us are correct, I think we're in the rough. But no harm validating that again. S. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Mon Aug 24 14:50: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 F42071B2AD8 for ; Mon, 24 Aug 2015 14:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRqSO027TM9E for ; Mon, 24 Aug 2015 14:50:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840F31B2B3F for ; Mon, 24 Aug 2015 14:50:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B0B36284D64; Mon, 24 Aug 2015 21:50:37 +0000 (UTC) Date: Mon, 24 Aug 2015 21:50:37 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150824215037.GO9021@mournblade.imrryr.org> References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 21:50:41 -0000 On Mon, Aug 24, 2015 at 09:32:38PM +0000, Salz, Rich wrote: > > With *legacy* protocols, when negotiating unauthenticated opportunistic > > encryption, it is important to not exclude recently obsoleted algorithms that > > are still needed for interoperability lest failing to offer them cause > > communications failure or needless use of cleartext. > > And here, I think, is the rub. > > SMTP is a legacy protocol. Is opportunistically-encrypted SMTP a legacy > protocol? Yes. http://tools.ietf.org/html/rfc2487 (January 1999) TLS support for Postfix (patch-set from Lutz Jaenicke): https://github.com/vdukhovni/postfix/blob/master/postfix/TLS_CHANGES (initial version 1999/03/29) > How long has it been in common use? Somewhere between 12 and 15 years. I call that "legacy". Opportunistic TLS was added to Microsoft Exchange 2003, and further extended in 2007. Wietse adopted the unofficial patch-set into mainstream Postfix in 2005. It had been merged into Postfix by various Linux distributions prior to that. > How old is the crypto that these deployed systems have access to? The Windows 2003-based systems, which are still in use, only do TLS 1.0 with RC4-{SHA,MD5}. Many older Linux systems still only have OpenSSL 0.9.8 and also support only TLS 1.0, SSL 2.0 and SSL 3.0. With no ECDHE. -- Viktor. From nobody Mon Aug 24 14:56:32 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 0A1B61B32BE for ; Mon, 24 Aug 2015 14:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jca3KXwyjs7 for ; Mon, 24 Aug 2015 14:56:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B336C1B32BB for ; Mon, 24 Aug 2015 14:56:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9BFF8284D64; Mon, 24 Aug 2015 21:56:28 +0000 (UTC) Date: Mon, 24 Aug 2015 21:56:28 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150824215628.GP9021@mournblade.imrryr.org> References: <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <846AD897-C38F-4528-849D-B98B2D87798B@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 21:56:31 -0000 On Mon, Aug 24, 2015 at 09:40:22PM +0000, Salz, Rich wrote: > > I agree this is the problem/poster child for this discussion. I'd rather phrase it > > that in some cases, deprecated crypto will be used when libraries/software > > can't be updated rather than saying it's okay because it falls into OS. But this > > may just be me. > > It's not just you. :) Actually, both OS and legacy are necessary conditions. If it is not OS, and is supposed to deliver strong rather than best-effort security, then legacy or not, deprecated algorithms need to be phased out rapidly. If it is OS, and not legacy, then again no deprecated algorithms. However OS + legacy (which implies impracticality of fast Internet-wide upgrade) then obsolete algorithms linger-on for a while, but eventually disappear from OS too, once hardware refresh cycles take care of the laggards. We've eliminated EXPORT crypto, DES, SSL 2.0 and SSL 3.0 for OS for SMTP. We've not yet eliminated RC4-SHA, but will I think in a couple of years. -- Viktor. From nobody Mon Aug 24 15:01:56 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 04EAF1B337C for ; Mon, 24 Aug 2015 15:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 SiKSbRPY3ecD for ; Mon, 24 Aug 2015 15:01:55 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (unknown [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id E6D851B337B for ; Mon, 24 Aug 2015 15:01:54 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C46B347D13 for ; Mon, 24 Aug 2015 22:01:53 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 6AF95477E5 for ; Mon, 24 Aug 2015 22:01:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1440453713; bh=TFF3AaqL92dqelCUbBe1Z2FupFLgPWxK8yZYGq7uAX4=; h=From:To:Subject:Date:References:In-Reply-To:From; b=WruwBVNNCEKkTUYQzgfgaC+yhU6VSw9kkzXGE8DlDFfiqUARRt7HVhfXod8wV5b/e DY0/wlAO5KAmOmDg4CSosM2jEjVsQjVjlz2QRBjM+NdxDucUywflRAqEmeFbST3ywg nN7VrzUfMtcy5AQL4LBi9YKkHOTDrZj9GNW6x3bk= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 533AF2026 for ; Mon, 24 Aug 2015 22:01:53 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 24 Aug 2015 17:01:52 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Mon, 24 Aug 2015 17:01:52 -0500 From: "Salz, Rich" To: "saag@ietf.org" Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQ3qvj021A7RxjOEahYRWcAOaGUp4b/kqA//+syqCAAFk4gP//rndg Date: Mon, 24 Aug 2015 22:01:51 +0000 Message-ID: References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> In-Reply-To: <20150824215037.GO9021@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 24 Aug 2015 22:01:56 -0000 > Somewhere between 12 and 15 years. I call that "legacy". I'd put the dates at 12 (Windows 2003) and 10 (Wietse's adoption in 2005), = but that's still legacy. Thanks for the timeline! I think 10 years is long enough -- too long, actually -- but that's a separ= ate discussion that I believe I've already lost. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Mon Aug 24 15:17: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 B746D1AD2D9 for ; Mon, 24 Aug 2015 15:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3jp8m1yGnCk for ; Mon, 24 Aug 2015 15:17:25 -0700 (PDT) Received: from nk11p14im-asmtp002.me.com (nk11p14im-asmtp002.me.com [17.158.72.161]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A161ACEF9 for ; Mon, 24 Aug 2015 15:17:25 -0700 (PDT) Received: from [192.168.1.89] (host86-183-15-3.range86-183.btcentralplus.com [86.183.15.3]) by nk11p14im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NTL00APCXWIQM30@nk11p14im-asmtp002.me.com> for saag@ietf.org; Mon, 24 Aug 2015 22:17:09 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-08-24_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1412110000 definitions=main-1508240338 From: David Misell Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (1.0) Message-id: Date: Mon, 24 Aug 2015 23:17:06 +0100 References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> In-reply-to: To: saag@ietf.org X-Mailer: iPad Mail (12H321) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 24 Aug 2015 22:17:26 -0000 It's only been 40 years since whit diffie and Martin Hellman wrote new direc= tions in cryptography! Best Regards, Dave david.misell@bcs.org 07710380044 misell.dave on skype On 24 Aug 2015, at 23:01, Salz, Rich wrote: >> Somewhere between 12 and 15 years. I call that "legacy". >=20 > I'd put the dates at 12 (Windows 2003) and 10 (Wietse's adoption in 2005),= but that's still legacy. Thanks for the timeline! >=20 > I think 10 years is long enough -- too long, actually -- but that's a sepa= rate discussion that I believe I've already lost. >=20 > -- =20 > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Aug 25 00:27: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 519C31A8A7D for ; Tue, 25 Aug 2015 00:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 6qRGmc_IYR8t for ; Tue, 25 Aug 2015 00:27:22 -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 1900F1A6F5D for ; Tue, 25 Aug 2015 00:27:21 -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=1440487642; x=1472023642; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=C67HI0Z+MH+MWdwySeQMX/ufpww3Abuw6Z7g/+5LgVc=; b=MeONCbsmj7oj1m3/VSyITFCLhOy1yoCqDRQPvN/MMgMJbqvE3fTagrXQ qXivcLCYKYsNn1c653NVvy+N3GRCiAyLZl6u6KGBH61mLbJTU/Nvq2Kvb a+vd0t2fd+XAfnhcp8dptwBSjPl8V0iUmLYENaysXY5rcdyTPMTXoEVTr 5Ip4XCUND0fYFNo/3sUhCk1fBmRnxumEPqxZltW+9ORLBtkQR6eK9PBhw u4yr5eC9Il+mc+7oaZJSTCrkUr8DNXADHtW5PGs5cRKITAQKgnqC1sZN/ mdfIFgRQLZiQ3G5L1wY2IqWNMUpqY4fGLCAtXO2e9bzsia3EhCrBOi6LL Q==; X-IronPort-AV: E=Sophos;i="5.15,744,1432555200"; d="scan'208";a="37572430" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Aug 2015 19:26:54 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 25 Aug 2015 19:26:53 +1200 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQ3qvbT9ZhMqG4SESDb9hHYel1Rp4a4U6AgAAA+wCAAAUHgIABabjA Date: Tue, 25 Aug 2015 07:26:53 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> References: <55A938F1.9090404@cs.tcd.ie> <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com>, <20150824215037.GO9021@mournblade.imrryr.org> In-Reply-To: <20150824215037.GO9021@mournblade.imrryr.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 review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 07:27:26 -0000 Viktor Dukhovni writes:=0A= =0A= >Opportunistic TLS was added to Microsoft Exchange 2003, and further extend= ed=0A= >in 2007.=0A= =0A= It's not true opportunistic TLS (unless they've fixed it recently), it's "p= ay=0A= a commercial CA to be allowed to do TLS", unlike pretty much every other MT= A=0A= I'm aware of which allows you to just set up and go without having to buy a= =0A= cert for each server.=0A= =0A= (I'm not saying this as part of some anti-CA crusade, but to point out that= =0A= Exchange puts a considerable hurdle in the way of universal opportunstic TL= S=0A= for email. To do opportunistic TLS with Postfix or most (all?) other MTAs,= =0A= you need just the MTA. To do it with Exchange, you need the MTA plus=0A= permission from a commercial CA to use TLS. In the interests of getting ha= rd=0A= data for this, I wrote to Aaron Zauner, who did the TLS-with-SMTP survey, a= =0A= few days ago to ask if he has distinct stats for Exchange vs. everything el= se).=0A= =0A= Peter.= From nobody Tue Aug 25 06:43:37 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 C26D91ACD79 for ; Tue, 25 Aug 2015 06:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXumpZOfQq9J for ; Tue, 25 Aug 2015 06:43:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296C31A907A for ; Tue, 25 Aug 2015 06:43:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A8ED0284B69; Tue, 25 Aug 2015 13:43:33 +0000 (UTC) Date: Tue, 25 Aug 2015 13:43:33 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150825134333.GX9021@mournblade.imrryr.org> References: <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 13:43:36 -0000 On Tue, Aug 25, 2015 at 07:26:53AM +0000, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >Opportunistic TLS was added to Microsoft Exchange 2003, and further extended > >in 2007. > > It's not true opportunistic TLS (unless they've fixed it recently), it's "pay > a commercial CA to be allowed to do TLS", unlike pretty much every other MTA > I'm aware of which allows you to just set up and go without having to buy a > cert for each server. Server side STARTTLS support, which is agnostic as to whether the client is opportunistic or not, is available with Exchange 2003 and later. Opportunistic TLS is supported in at least Exchange 2007 and later. I don't recall what Exchange 2003 did outbound, I only recall helping Microsoft to design fixes for various issues prior to the release of Exchange 2007. Some flaws remain, but it is largely workable without a CA tax. > (I'm not saying this as part of some anti-CA crusade, but to point out that > Exchange puts a considerable hurdle in the way of universal opportunstic TLS > for email. To do opportunistic TLS with Postfix or most (all?) other MTAs, > you need just the MTA. To do it with Exchange, you need the MTA plus > permission from a commercial CA to use TLS. In the interests of getting hard > data for this, I wrote to Aaron Zauner, who did the TLS-with-SMTP survey, a > few days ago to ask if he has distinct stats for Exchange vs. everything else). Inbound, Exchange does not and cannot know whether the client is authenticating the server certificate or ignoring it. Outbound, there are still a few known defects, that I've communicated to Microsoft, and will I hope be fixed at some point. The most significant known issues are TLS handshake failure and fallback to cleartext when: * The peer's certificate is expired. Even though authentication is not required and it would be accepted from an untrusted issuer. * The peer's certificate chain has certificates signed with MD5. Even if the only use of MD5 is in the self-signature of a root CA, and even for client cerficates which are solicited though the server does not use them. * The server's certificate uses SHA2-256, but the peer only supports TLS 1.0, or in any case fails to include SHA2-256 in the supported signature algorithms extension. The last of these is a result of implementing RFC 5246 (TLS 1.2), rather than what makes sense. It looks like TLS 1.3 is on track to be sensible in this regard (server-side handling of certificate signature algorithms). The majority of clients and servers don't run into the above problems, but they do thwart STARTTLS for a non-negligible minority of systems. -- Viktor. From nobody Tue Aug 25 07:57: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 D828E1B2E61 for ; Tue, 25 Aug 2015 07:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_35=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCLfUcLVE_eK for ; Tue, 25 Aug 2015 07:56:56 -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 3B72C1B34BB for ; Tue, 25 Aug 2015 07:56:54 -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=1440514617; x=1472050617; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yZorjdPmQV/hHHO6l3z/5gyFDzYA3OwIfTQlqPB4PLU=; b=Qxo0l6IYeja8ssSuLNdQ1MmYDn1b86INWZKv79ov6svdjBkZlXWXKhqm F+Ub/tOfWW6H3G5vih7koWwHRXzQfN7F8KTAymQqRsKC+x2YmAhmaCpSo NPrw09cgFPYDB+FqYAXwbPJI89V6O5ynqMuzwdB7lUsQLXQIb7Uoz6D3V bEoFWadPEjsF1syrVozkCgiczojnige++KXjGbqLNqtmXr6HcxCS9dZyM HP1Uk8R3Smw8C7tAMzUUMSZ/AXkDQSf0K7D6hO0YbKf8Xt8/No1cK9GEW 5hD3AkZOeJVgPm3mXUG8vZFE/U6RXLF6ydAlx0CQmHLyUyUbuDLJRD7WT Q==; X-IronPort-AV: E=Sophos;i="5.15,746,1432555200"; d="scan'208";a="37610262" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Aug 2015 02:56:55 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 26 Aug 2015 02:56:52 +1200 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQ3qvbT9ZhMqG4SESDb9hHYel1Rp4a4U6AgAAA+wCAAAUHgIABabjA//+gh4CAAN1rEA== Date: Tue, 25 Aug 2015 14:56:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AE6693@uxcn10-5.UoA.auckland.ac.nz> References: <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz>, <20150825134333.GX9021@mournblade.imrryr.org> In-Reply-To: <20150825134333.GX9021@mournblade.imrryr.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 review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 14:57:05 -0000 Viktor Dukhovni writes:=0A= =0A= >Inbound, Exchange does not and cannot know whether the client is=0A= >authenticating the server certificate or ignoring it.=0A= =0A= Argh, yeah, sorry, messed that one up, the issue was more with Outlook (i.e= .=0A= client-side) than Exchange (server-side), specifically the amount of pain= =0A= involved in configuring things to trust non-commercial-CA-issued certs.=0A= Here's the 25-step process (which each step comprising several sub-steps, i= t's=0A= pages and pages and pages of instructions) for Exchange 2010:=0A= =0A= http://social.technet.microsoft.com/wiki/contents/articles/13916.how-to-use= -a-self-signed-certificate-in-exchange-2010.aspx=0A= =0A= Compare this to a cut&paste of:=0A= =0A= openssl req -x509 -newkey rsa:2048 -nodes -keyout /etc/ssl/private/key.pem = -out /etc/ssl/certs/cert.pem -days 3650 -subj '/CN=3Dmail.example.com' =0A= =0A= (E&OE :-) for non-Exchange mail servers.=0A= =0A= (I've long been an advocate of software auto-generating a key on install an= d=0A= allowing the user to override it if they want further customisation, which= =0A= would probably make about, oh, 99% of things like this:=0A= =0A= https://code.google.com/p/littleblackbox/=0A= =0A= go away).=0A= =0A= Peter.= From nobody Tue Aug 25 08:16:43 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 E81AE1B3536 for ; Tue, 25 Aug 2015 08:16:39 -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, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-68I7M2J64k for ; Tue, 25 Aug 2015 08:16:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC331B350C for ; Tue, 25 Aug 2015 08:16:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EAB5D284B69; Tue, 25 Aug 2015 15:16:32 +0000 (UTC) Date: Tue, 25 Aug 2015 15:16:32 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150825151632.GF9021@mournblade.imrryr.org> References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE6693@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AE6693@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 15:16:40 -0000 On Tue, Aug 25, 2015 at 02:56:52PM +0000, Peter Gutmann wrote: > Compare this to a cut&paste of: > > openssl req -x509 -newkey rsa:2048 -nodes -keyout /etc/ssl/private/key.pem -out /etc/ssl/certs/cert.pem -days 3650 -subj '/CN=mail.example.com' > For Postfix, http://www.postfix.org/TLS_README.html#quick-start it takes a one more 'postconf' command to actually turn on TLS after the key and cert are generated: # dir="$(postconf -h config_directory)" # fqdn=$(postconf -h myhostname) # case $fqdn in /*) fqdn=$(cat "$fqdn");; esac # ymd=$(date +%Y-%m-%d) # key="${dir}/key-${ymd}.pem"; rm -f "${key}" # cert="${dir}/cert-${ymd}.pem"; rm -f "${cert}" # (umask 077; openssl genrsa -out "${key}" 2048) && openssl req -new -key "${key}" \ -x509 -subj "/CN=${fqdn}" -days 3650 -out "${cert}" && postconf -e \ "smtpd_tls_cert_file = ${cert}" \ "smtpd_tls_key_file = ${key}" \ 'smtpd_tls_security_level = may' \ 'smtpd_tls_received_header = yes' \ 'smtpd_tls_loglevel = 1' \ 'smtp_tls_security_level = may' \ 'smtp_tls_loglevel = 1' \ 'smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache' \ 'tls_random_source = dev:/dev/urandom' And the key/cert generation is done with a bit more finesse to set a sensible umask, avoid clobbering previous key/cert files that might be in live use, deal with Debian's "myhostname" in a file, etc. > (I've long been an advocate of software auto-generating a key on install and > allowing the user to override it if they want further customisation. I concur, but am a bit worried about low entropy at system build time. -- Viktor. From nobody Tue Aug 25 08:26: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 80C351B3507 for ; Tue, 25 Aug 2015 08:26:40 -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, 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 z7PDzbAfwN1U for ; Tue, 25 Aug 2015 08:26:38 -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 41E661B34F4 for ; Tue, 25 Aug 2015 08:26:38 -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=1440516398; x=1472052398; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CXViOqMvxj+29zj/PXxnkgjdBA7PQum2SX4EKcAUh4E=; b=PYP0ezEgrZ8EDhzeFp3wiMA2bQ6nHP8u/Qj48W2PcngzyjMhk+aWqzCo mupNAN3xdoTsqjZpvOV96oN5p4I9DnGvMLrc0ihLVcS2PYUUho8WU+ZvS FzQaNHp45QTRnUtVwEJvLV7DNPj/rT0Njqln0P7WZlk+momUUdvsi0eY+ isenOw0wg9WCHuIyMiQqiswQ69N/T5HAM3lJdyTJ5sGayzmspvqHN6dmR qbsd7f6V78gAu4nF0gq4+FrLtpX2ZEr78IeuNad9id/t4GaqsWypg+bjc Hjh7knqGyeTAin+W+v/iYP7R+6y4kDDpgh7yfKK4A6dly0RpIqWZwlESi g==; X-IronPort-AV: E=Sophos;i="5.15,746,1432555200"; d="scan'208";a="37612108" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Aug 2015 03:26:36 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 26 Aug 2015 03:26:36 +1200 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQ3qvbT9ZhMqG4SESDb9hHYel1Rp4a4U6AgAAA+wCAAAUHgIABabjA//+gh4CAAN1rEP//PI8AgADLuuI= Date: Tue, 25 Aug 2015 15:26:35 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AE66D2@uxcn10-5.UoA.auckland.ac.nz> References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE6693@uxcn10-5.UoA.auckland.ac.nz>, <20150825151632.GF9021@mournblade.imrryr.org> In-Reply-To: <20150825151632.GF9021@mournblade.imrryr.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 review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 15:26:40 -0000 Viktor Dukhovni writes:=0A= =0A= >I concur, but am a bit worried about low entropy at system build time.=0A= =0A= Better to have at least low-entropy keys than no-entropy keys, which is the= =0A= alternative when users don't (or can't) generate keys themselves post-=0A= install...=0A= =0A= (The low-entropy issue is also largely a hypothetical one, in that people= =0A= worry about it without doing much measuring. When I evaluated it, admitted= ly=0A= many years ago, I found there was actually more entropy available after=0A= something like a system restart because of all the nondeterminism introduce= d=0A= by the boot process. Same with provisioning embedded devices, if you gener= ate=0A= the keys externally on a high-entropy system when you're loading the firmwa= re=0A= onto a limited device you're getting better entropy than if you generated t= hem=0A= on-device. In any case though, anything is better than fixed private keys,= =0A= which far too many systems use).=0A= =0A= Peter.= From nobody Tue Aug 25 08:44:16 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 A43811B2F65 for ; Tue, 25 Aug 2015 08:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, 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 1r30mwn1YLfq for ; Tue, 25 Aug 2015 08:44:14 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 46B901B2F49 for ; Tue, 25 Aug 2015 08:44:14 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 560FD74001B for ; Tue, 25 Aug 2015 15:44:13 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 3B533740018 for ; Tue, 25 Aug 2015 15:44:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1440517453; bh=HsVkRQiJUz3UM9MiDo5fsD+DijG7cnNOwXdc0ptWTl8=; l=693; h=From:To:Date:References:In-Reply-To:From; b=VEEgFx+GssBLAHjBxpvprIwDa5wqOBXSODktZxeZvyxkZ79yP/lgUF/erAUawhaee ybh0JyL4L5nGsJkgxtTAkKG4AhT/hM5nJNxlhcFckZWTSCWkrd98e4dv89tQA4Poew EkNxwtja8tSAawJcJPbDyBqzG4L5jrpdpNbXUCrQ= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 395E998082 for ; Tue, 25 Aug 2015 15:44:13 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 25 Aug 2015 10:44:12 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Tue, 25 Aug 2015 10:44:12 -0500 From: "Salz, Rich" To: "saag@ietf.org" Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQ3qvj021A7RxjOEahYRWcAOaGUp4b/kqA//+syqCAAFk4gIAAoQGAgABpPoD//8v60A== Date: Tue, 25 Aug 2015 15:44:12 +0000 Message-ID: <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150727194020.GD15860@localhost> <55B6D36C.70105@iang.org> <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> In-Reply-To: <20150825134333.GX9021@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 15:44:15 -0000 > Opportunistic TLS is supported in at least Exchange 2007 and later. > I don't recall what Exchange 2003 did outbound, I only recall helping > Microsoft to design fixes for various issues prior to the release of Exch= ange > 2007. Some flaws remain, but it is largely workable without a CA tax. This is important. It means that for SMTP, OS really started in 2005 with = Postfix and 2007 for Exchange? If so, then there is really no need to sup= port RC4. STARTTLS, as Peter was saying, can imply more than just OS, as M= S really wants a CA to be involved. Since a principle tenet of OS is *unau= thenticated* privacy, it appears that the discussion has conflated the two. From nobody Tue Aug 25 09:06:32 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 17F031B34E8 for ; Tue, 25 Aug 2015 09:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA0yFfrpWY2X for ; Tue, 25 Aug 2015 09:06:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7E81B34DF for ; Tue, 25 Aug 2015 09:06:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0F674284B69; Tue, 25 Aug 2015 16:06:28 +0000 (UTC) Date: Tue, 25 Aug 2015 16:06:28 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150825160627.GH9021@mournblade.imrryr.org> References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 16:06:31 -0000 On Tue, Aug 25, 2015 at 03:44:12PM +0000, Salz, Rich wrote: > > Opportunistic TLS is supported in at least Exchange 2007 and later. > > I don't recall what Exchange 2003 did outbound, I only recall helping > > Microsoft to design fixes for various issues prior to the release of Exchange > > 2007. Some flaws remain, but it is largely workable without a CA tax. > > This is important. It means that for SMTP, OS really started in 2005 with > Postfix and 2007 for Exchange? If so, then there is really no need to > support RC4. STARTTLS, as Peter was saying, can imply more than just OS, > as MS really wants a CA to be involved. Since a principal tenet of OS is > *unauthenticated* privacy, it appears that the discussion has conflated > the two. You're reading too much into the tea leaves. Exchange as a server supported inbound STARTTLS since 2003 and a non-trivial number of deployed systems are of that vintage. There was STARTTLS support in Postfix as shipped in some Linux distributions, well before the feature was officially adopted and improved by Wietse for Postfix 2.2 in 2005. Yes, Exchange support for STARTTLS was improved (for outbound TLS) in 2007. However, exchange was not and is not a dominant edge MTA. It is used inside networks a lot more than at the edge. There is longstanding STARTTLS support in Sendmail, Qmail, Exim, Ironport appliances, Kerio appliances, ... STARTTLS for SMTP has a large deployed base, with many of the systems running less-capable "vintage" software. How long ago they got there is not especially relevant. Your conclusions about RC4 with SMTP are I'm afraid wishful thinking. Users are having real issues delivering email to RC4-only systems. Downgrading those to cleartext (and sometimes failing delivery entirely) is not a win. I'll deprecate RC4 in Postfix as soon as possible, but not sooner. In any case, whether it is RC4 now, or some other deprecated ciphersuite in the futre, with opportunistic security one needs to pay more attention to what interoperates than what is unequivocally strong. The goal is as much security as can be realistically had, not "all or nothing". I like to make an analogy with vaccination, we're protecting the infrastructure as a whole, rather guaranteed security for a particular flow. -- Viktor. From nobody Tue Aug 25 09:21:51 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 EDCEB1A00A8 for ; Tue, 25 Aug 2015 09:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SraJdKM5g1FE for ; Tue, 25 Aug 2015 09:21:48 -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 A4EC21A00A0 for ; Tue, 25 Aug 2015 09:21:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7AC8ABE64 for ; Tue, 25 Aug 2015 17:21:47 +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 jHET-BWXqAaU for ; Tue, 25 Aug 2015 17:21:47 +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 4CA3ABE4D for ; Tue, 25 Aug 2015 17:21:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440519707; bh=AAjIDi5Vvil286zIwqEaaz4dEpYxToDEMchegiOG0ik=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ILyUATf5xWOE68oDhxZkhRqr5R0NfvKc+FWPJW5xYZ5pVIJK98bBWsZVIQuRdwMkg ZafPEG4xLRew785tiYUpAKuDgY5Y4lWDkLOFuzr16aep78YaCKZoqZzf/fzpPeJ3rY r4c5x1tmH4DYNWNU8psvvI8cF6H2uWKvvzPIfiS4= Message-ID: <55DC961A.903@cs.tcd.ie> Date: Tue, 25 Aug 2015 17:21:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: saag@ietf.org References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> In-Reply-To: <20150825160627.GH9021@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 16:21:50 -0000 Viktor, (Here we are back at this argument again:-) On 25/08/15 17:06, Viktor Dukhovni wrote: > In any case, whether it is RC4 now, or some other deprecated > ciphersuite in the futre, with opportunistic security one needs to > pay more attention to what interoperates than what is unequivocally > strong. The goal is as much security as can be realistically had, > not "all or nothing". I like to make an analogy with vaccination, > we're protecting the infrastructure as a whole, rather guaranteed > security for a particular flow. Do you agree though that there are at least two points in time involved when considering weakened or suspect ciphers? There is the time you're discussing of when the bad algorithm can be turned off without damaging interop of ciphertext form packets. But there is also the time after which one considers that all such ciphertext will in a short while be almost the same as plaintext for a capable attacker. And the latter can happen before the former. My argument (for which I still think I'm in the rough) is that when we get to that 2nd point in time, one ought no longer use a cipher even in OS mode. Yes, that's a trade off, as are all OS arguments. For me the continued use of a cipher that is that weakened is worse overall, as that cipher is liable to be used in more environments that just one. And yes, that does mean that some packets will be sent in clear that would otherwise not be, but it also means that some software will be updated sooner and hence other packets will be sent as better ciphertext. (And btw: In the specific case of RC4 the IETF does have consensus to deprecate that already [1], even if the mail community let that go by while pretending it wasn't happening:-) Cheers, S. [1] https://tools.ietf.org/html/rfc7465 From nobody Tue Aug 25 09:24:32 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 05FBC1A016A for ; Tue, 25 Aug 2015 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, 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 BsEawhUMBJTd for ; Tue, 25 Aug 2015 09:24:29 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id ADF471A0162 for ; Tue, 25 Aug 2015 09:24:29 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 23066740064; Tue, 25 Aug 2015 16:24:29 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 0C626740032; Tue, 25 Aug 2015 16:24:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1440519869; bh=61gTRCEdaOUyit9l+BTlaOJZGIq1UP83xe5hFlSS3rg=; l=337; h=From:To:Date:References:In-Reply-To:From; b=XiC8GJ9NtIeTH4tx2iHOPsBixWbxnObSrJg3im18ikCPM/ti3HUhTFA6O1RqxEY+g mJtdttfQyeONwn+evu1Z+jdlAwEI1QbWeYf3N0GwjFPWN7zo4YJ7vx0y8MdRSFwtYb 8uYc/oCvnA4bUEZTu4TNMD79B/09fo6sV3PDNIfs= Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 093E41E080; Tue, 25 Aug 2015 16:24:29 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 25 Aug 2015 11:24:28 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Tue, 25 Aug 2015 11:24:28 -0500 From: "Salz, Rich" To: Stephen Farrell , "saag@ietf.org" Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQ3qvj021A7RxjOEahYRWcAOaGUp4b/kqA//+syqCAAFk4gIAAoQGAgABpPoD//8v60IAAW/QAgAAERgD//6yxwA== Date: Tue, 25 Aug 2015 16:24:28 +0000 Message-ID: References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> In-Reply-To: <55DC961A.903@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 16:24:31 -0000 > My argument (for which I still think I'm in the rough) is that when we ge= t to > that 2nd point in time, one ought no longer use a cipher even in OS mode. I am not sure that you are in the rough. I don't recall much support for t= he opposite viewpoint, other than my charming, voluble, and persistent Open= SSL colleague :) From nobody Tue Aug 25 09:26: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 7CE6F1A0334 for ; Tue, 25 Aug 2015 09:26:35 -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 fmtuZ3luafx6 for ; Tue, 25 Aug 2015 09:26:30 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 783561A0252 for ; Tue, 25 Aug 2015 09:26:29 -0700 (PDT) Received: by widdq5 with SMTP id dq5so20022253wid.0 for ; Tue, 25 Aug 2015 09:26:28 -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 :content-type; bh=5A5w7VEduh0jBOf4TVOM3rRgYm6+h1Ll68ABRjJ+0TU=; b=DBqwS2x1/GovpKxIxXMAQa6fcBnOpydz7rJIaXI/qAPV/1VAqKR2O6knrVnsNjvc8H J5IXjR4fCVcEEzEBrLNguoeLaGMORk5AF37f90a+RgoMtZVOJWapxnlLWygzT5mnY53s +3ZJ/tob7gzLU72zsZgQgyLikj7DcTprKeU8m+O4ChNFQHrJRmRG7nv2d9OY918qO+zr QHlUQk6xfmMWMDuZuKvKGAjgeNT4SRPo/0nHxau3mOdF1M3zXiNP4RqH4ehHMQwSlYqa qV0ASlrPk9h3wI+q+afea/mrNjyWYRZO1kFwYGeEdR9gCjhFE8OieXzBUFscZy9iYdSd skrA== MIME-Version: 1.0 X-Received: by 10.194.205.37 with SMTP id ld5mr54443528wjc.14.1440519988220; Tue, 25 Aug 2015 09:26:28 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Tue, 25 Aug 2015 09:26:27 -0700 (PDT) In-Reply-To: <20150825160627.GH9021@mournblade.imrryr.org> References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> Date: Tue, 25 Aug 2015 12:26:27 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 16:26:35 -0000 On Tue, Aug 25, 2015 at 12:06 PM, Viktor Dukhovni wrote: > On Tue, Aug 25, 2015 at 03:44:12PM +0000, Salz, Rich wrote: > >> > Opportunistic TLS is supported in at least Exchange 2007 and later. >> > I don't recall what Exchange 2003 did outbound, I only recall helping >> > Microsoft to design fixes for various issues prior to the release of Exchange >> > 2007. Some flaws remain, but it is largely workable without a CA tax. >> >> This is important. It means that for SMTP, OS really started in 2005 with >> Postfix and 2007 for Exchange? If so, then there is really no need to >> support RC4. STARTTLS, as Peter was saying, can imply more than just OS, >> as MS really wants a CA to be involved. Since a principal tenet of OS is >> *unauthenticated* privacy, it appears that the discussion has conflated >> the two. > > You're reading too much into the tea leaves. Exchange as a server > supported inbound STARTTLS since 2003 and a non-trivial number of > deployed systems are of that vintage. There was STARTTLS support > in Postfix as shipped in some Linux distributions, well before the > feature was officially adopted and improved by Wietse for Postfix > 2.2 in 2005. > > Yes, Exchange support for STARTTLS was improved (for outbound TLS) > in 2007. However, exchange was not and is not a dominant edge MTA. > It is used inside networks a lot more than at the edge. > > There is longstanding STARTTLS support in Sendmail, Qmail, Exim, > Ironport appliances, Kerio appliances, ... > > STARTTLS for SMTP has a large deployed base, with many of the > systems running less-capable "vintage" software. How long ago they > got there is not especially relevant. Your conclusions about RC4 > with SMTP are I'm afraid wishful thinking. > > Users are having real issues delivering email to RC4-only systems. > Downgrading those to cleartext (and sometimes failing delivery > entirely) is not a win. I'll deprecate RC4 in Postfix as soon as > possible, but not sooner. > > In any case, whether it is RC4 now, or some other deprecated > ciphersuite in the futre, with opportunistic security one needs to > pay more attention to what interoperates than what is unequivocally > strong. The goal is as much security as can be realistically had, > not "all or nothing". I like to make an analogy with vaccination, > we're protecting the infrastructure as a whole, rather guaranteed > security for a particular flow. > I'm not sure we have consensus and would like to see more opinions as to what we collectively think the statements on OS should include. I don't think anyone is saying that bad crypto isn't better than no crypto, but how we define OS and continue to use the definition may matter for algorithm and cipher suite deprecation efforts. It's long been a practice for legacy systems to continue to use deprecated protocols, algorithms and cipher suites, but we've said they are not in compliance with RFCXXXX. Do we really want to start down a path of saying it's okay because it falls under OS? I'd rather not. We would get to about the same result, but perhaps we could have more success with deprecation transitions if these older options are not 'blessed'. If others would like to offer their thoughts, it would be appreciated. I know the specific argument around this was for RC4 and SMTP, but let's think about the generalized statement and what we want that to be going forward. Thank you, Kathleen > -- > Viktor. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Best regards, Kathleen From nobody Tue Aug 25 09:55:43 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 EEC3B1A9071 for ; Tue, 25 Aug 2015 09:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l14KtNvwreJT for ; Tue, 25 Aug 2015 09:55:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5172E1A9064 for ; Tue, 25 Aug 2015 09:55:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3422F284B69; Tue, 25 Aug 2015 16:55:40 +0000 (UTC) Date: Tue, 25 Aug 2015 16:55:40 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150825165539.GL9021@mournblade.imrryr.org> References: <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55DC961A.903@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 16:55:43 -0000 On Tue, Aug 25, 2015 at 05:21:46PM +0100, Stephen Farrell wrote: > > In any case, whether it is RC4 now, or some other deprecated > > ciphersuite in the futre, with opportunistic security one needs to > > pay more attention to what interoperates than what is unequivocally > > strong. The goal is as much security as can be realistically had, > > not "all or nothing". I like to make an analogy with vaccination, > > we're protecting the infrastructure as a whole, rather guaranteed > > security for a particular flow. > > Do you agree though that there are at least two points in time > involved when considering weakened or suspect ciphers? > > There is the time you're discussing of when the bad algorithm > can be turned off without damaging interop of ciphertext form > packets. Yes. > But there is also the time after which one considers that all > such ciphertext will in a short while be almost the same as > plaintext for a capable attacker. That could happen. > And the latter can happen before the former. Possibly. More realistically I see multiple milestones (in some order): 1. Cipher becomes known weak. 2. Cipher known not much stronger than cleartext. 3. Cipher no longer required for interop. 4. Cipher is not MTI and is rarely used. With OS in Postfix, I'm willing to deprecate some ciphers once we have 3 and 4, in some cases even before 1 and 2. For example, I'm considering by default not enabling DSS, fixed DH and fixed ECDH. And have already posted a best-practice guide to the users list advising users to do that. > My argument (for which I still think I'm in the rough) is that > when we get to that 2nd point in time, one ought no longer use > a cipher even in OS mode. Introducing negotiation failures in OS, and requirement to support cleartext fallback in is problematic. Even if some ciphersuite is effective a NULL cipher, it is better to negotiate that without introducing a fallback dance. > And yes, that does mean that some packets will be sent in > clear that would otherwise not be, but it also means that some > software will be updated sooner and hence other packets will be > sent as better ciphertext. The nasty part is that cleartext fallback is not always desirable or available. Sendmail IIRC does not fall back after STARTTLS handshake failure. > (And btw: In the specific case of RC4 the IETF does have consensus > to deprecate that already [1], even if the mail community let that > go by while pretending it wasn't happening:-) We're aware of the RC4 deprecation, and use of RC4 is declining, we're just going to take a couple of years longer to get there. -- Viktor. From nobody Tue Aug 25 10:39: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 330311AC3B1 for ; Tue, 25 Aug 2015 10:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro_73aC1thiE for ; Tue, 25 Aug 2015 10:39:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1751AC39E for ; Tue, 25 Aug 2015 10:39:41 -0700 (PDT) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 7BD9A284B56; Tue, 25 Aug 2015 17:39:40 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Viktor Dukhovni In-Reply-To: Date: Tue, 25 Aug 2015 13:39:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org> References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 17:39:43 -0000 > On Aug 25, 2015, at 12:26 PM, Kathleen Moriarty = wrote: >=20 >> In any case, whether it is RC4 now, or some other deprecated >> ciphersuite in the futre, with opportunistic security one needs to >> pay more attention to what interoperates than what is unequivocally >> strong. The goal is as much security as can be realistically had, >> not "all or nothing". I like to make an analogy with vaccination, >> we're protecting the infrastructure as a whole, rather guaranteed >> security for a particular flow. >=20 > I'm not sure we have consensus and would like to see more opinions as > to what we collectively think the statements on OS should include. I thought we reached "rough" consensus on this point during the rather intensive/extensive last-call discussions of the OS draft. = Specifically, that even weaker ciphers are better than cleartext, and may need to continue to be used if that's what it takes. > I don't think anyone is saying that bad crypto isn't better than no > crypto, but how we define OS and continue to use the definition may > matter for algorithm and cipher suite deprecation efforts. It's long > been a practice for legacy systems to continue to use deprecated > protocols, algorithms and cipher suites, but we've said they are not > in compliance with RFCXXXX. Do we really want to start down a path of > saying it's okay because it falls under OS? I'd rather not. We would > get to about the same result, but perhaps we could have more success > with deprecation transitions if these older options are not 'blessed'. How to position deprecation is more of a marketing than a technical question. I agree that we don't want to dilute the message that deprecated ciphers should be phased out as quickly as possible. OS is not a license to indefinitely ignore deprecation. The key issue is what "as quickly as possible" means. For OS, it is = likely to mean that the process takes longer, because the relative priorities = of interoperability and security are different than with non-OS designs. So by all means, publish unequivocal deprecation of RC4, ... but expect that OS applications will take some time to act on such publications and rightly so. --=20 Viktor. From nobody Tue Aug 25 10:55:33 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 B6B311ACF08 for ; Tue, 25 Aug 2015 10:55:31 -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 n6XEkGbCyAxi for ; Tue, 25 Aug 2015 10:55:30 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (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 1F7BB1ACEE6 for ; Tue, 25 Aug 2015 10:55:30 -0700 (PDT) Received: by qgeb6 with SMTP id b6so111048993qge.3 for ; Tue, 25 Aug 2015 10:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=50xGzGIYKTOkqOwxFy6nBG7R0msGX6Pw2e4sy5zF6QQ=; b=VmL5TtcMRhBMtctlXEMGuIEUqOCqQg5JX1woeb4F0qrH9V8JWGCbAf/EAk3z3KadgL cTeWDrhXz+s83p/f//XfYZfjU5t/He9eqwt9lGoSbczf/y+CVgE8YtUBaXXVRC/1PLhc AbulJQsMpDo4SvP7qCUb9TxoW6DJhwdrm4cfAgyNRj7PzqgdM7Xbt2qOgVrShrZipz+z IyEK155r5jQGGo+Md+fdyFQu8l8ffnhpLI3mDnpUnl4jW0wM8AYDAg+gkRypIPDkNcrq EzNKJiVJqhSucykLi0wUPJJRShW93FoOIdBPr/MbowRnLLViVOQMGr02cSjDAot5M6ss xVlA== X-Received: by 10.140.234.130 with SMTP id f124mr71572414qhc.103.1440525329352; Tue, 25 Aug 2015 10:55:29 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id j30sm14271042qgj.20.2015.08.25.10.55.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Aug 2015 10:55:28 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <7CEEF500-4530-4245-A3DC-C7D1ACB754B6@gmail.com> Date: Tue, 25 Aug 2015 13:55:27 -0400 References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org> In-Reply-To: <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org> To: "saag@ietf.org" X-Mailer: iPhone Mail (12H143) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 17:55:31 -0000 Sent from my iPhone > On Aug 25, 2015, at 1:39 PM, Viktor Dukhovni wrot= e: >=20 >=20 >>> On Aug 25, 2015, at 12:26 PM, Kathleen Moriarty wrote: >>>=20 >>> In any case, whether it is RC4 now, or some other deprecated >>> ciphersuite in the futre, with opportunistic security one needs to >>> pay more attention to what interoperates than what is unequivocally >>> strong. The goal is as much security as can be realistically had, >>> not "all or nothing". I like to make an analogy with vaccination, >>> we're protecting the infrastructure as a whole, rather guaranteed >>> security for a particular flow. >>=20 >> I'm not sure we have consensus and would like to see more opinions as >> to what we collectively think the statements on OS should include. >=20 > I thought we reached "rough" consensus on this point during the rather > intensive/extensive last-call discussions of the OS draft. Specifically, > that even weaker ciphers are better than cleartext, and may need to > continue to be used if that's what it takes. I don't this point was as clearly discussed in those threads, so I'd like to= hear thoughts from the community. Thank you for sharing your opinion. If you think it was and have a pointer to the appropriate thread with adequa= te input to show support, please post it. Otherwise, allowing others to chi= me in will be helpful. I may be in the rough, but I'm not convinced of that= with this thread so far. Thanks, Kathleen=20 >=20 >> I don't think anyone is saying that bad crypto isn't better than no >> crypto, but how we define OS and continue to use the definition may >> matter for algorithm and cipher suite deprecation efforts. It's long >> been a practice for legacy systems to continue to use deprecated >> protocols, algorithms and cipher suites, but we've said they are not >> in compliance with RFCXXXX. Do we really want to start down a path of >> saying it's okay because it falls under OS? I'd rather not. We would >> get to about the same result, but perhaps we could have more success >> with deprecation transitions if these older options are not 'blessed'. >=20 > How to position deprecation is more of a marketing than a technical > question. I agree that we don't want to dilute the message that > deprecated ciphers should be phased out as quickly as possible. > OS is not a license to indefinitely ignore deprecation. >=20 > The key issue is what "as quickly as possible" means. For OS, it is likel= y > to mean that the process takes longer, because the relative priorities of > interoperability and security are different than with non-OS designs. >=20 > So by all means, publish unequivocal deprecation of RC4, ... but expect > that OS applications will take some time to act on such publications and > rightly so. >=20 > --=20 > Viktor. From nobody Tue Aug 25 11:13:49 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 EF5F31A8799 for ; Tue, 25 Aug 2015 11:13:46 -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 hVvB8owjpheL for ; Tue, 25 Aug 2015 11:13:45 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 7E5201A871A for ; Tue, 25 Aug 2015 11:13:45 -0700 (PDT) Received: by ykbi184 with SMTP id i184so164227289ykb.2 for ; Tue, 25 Aug 2015 11:13:45 -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=8SBCx3qH5TvWzS0jw7MUZkP7Cc4Eu1c5709TQ68Qtvc=; b=TagpTReJ2tAPhOrHnoWSDutRJibf8IB7Oy1iVPOtRX4Ter/2ZY9rlTVX1uh+RF6WKU oDKBkW5b9KlLC6hIMzEnsM/C/PNA+Jfj9Fx+2dsHbwmsZDhi1/e8YLSMZdG/1duoPPYx zLwtmFFQkE7jpexgzQ/GT3OwEb5gNTqOPPTdNyrDs7pz0khHyLh/yOb639bDb4BXNk2M oZxqS8rV4962eGL57Y+bJJ442UgWWtkQpcPz0l+ji/ysibxOTx8HHhAGWuTPymPbpb/I UaZwOuwTBKJISOufb/4KY8hML7jB24zs0LJNzIXoVS1P3XhR5kA97LQxjqV9TkRhH7kQ rcxg== MIME-Version: 1.0 X-Received: by 10.13.225.66 with SMTP id k63mr40270558ywe.148.1440526424843; Tue, 25 Aug 2015 11:13:44 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Tue, 25 Aug 2015 11:13:44 -0700 (PDT) In-Reply-To: <7CEEF500-4530-4245-A3DC-C7D1ACB754B6@gmail.com> References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org> <7CEEF500-4530-4245-A3DC-C7D1ACB754B6@gmail.com> Date: Tue, 25 Aug 2015 11:13:44 -0700 Message-ID: From: Martin Thomson To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 18:13:47 -0000 On 25 August 2015 at 10:55, Kathleen Moriarty wrote: >> I thought we reached "rough" consensus on this point during the rather >> intensive/extensive last-call discussions of the OS draft. Specifically, >> that even weaker ciphers are better than cleartext, and may need to >> continue to be used if that's what it takes. > > I don't this point was as clearly discussed in those threads, so I'd like to hear thoughts from the community. Thank you for sharing your opinion. > > If you think it was and have a pointer to the appropriate thread with adequate input to show support, please post it. Otherwise, allowing others to chime in will be helpful. I may be in the rough, but I'm not convinced of that with this thread so far. Since Kathleen asks so nicely, I'd like to register my disagreement with Victor on this point. There are compatibility reasons *today* that exist as a result of having to interoperate with old software that was built or deployed without due regard to security updates or continuous maintenance. However, if we expect software to be updated in order to get opportunistic security, then I don't think it unreasonable to also expect it to be maintained on an ongoing basis. A sudden once-off isn't going to cut it if we want to prepare for the eventuality where one of the current ciphers turns out to be irredeemably busted. If you accept that software that is updated once can be continuously maintained thereafter, then it's not a stretch to conclude that deploying good ciphers is equally feasible. From nobody Tue Aug 25 12:07: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 F18011A1BAC for ; Tue, 25 Aug 2015 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm7SXhs82pJF for ; Tue, 25 Aug 2015 12:07:04 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393D51A910E for ; Tue, 25 Aug 2015 12:07:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5F41F284B56; Tue, 25 Aug 2015 19:07:03 +0000 (UTC) Date: Tue, 25 Aug 2015 19:07:03 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150825190703.GO9021@mournblade.imrryr.org> References: <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org> <7CEEF500-4530-4245-A3DC-C7D1ACB754B6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 19:07:06 -0000 On Tue, Aug 25, 2015 at 11:13:44AM -0700, Martin Thomson wrote: > However, if we expect software to be updated in order to get > opportunistic security, then I don't think it unreasonable to also > expect it to be maintained on an ongoing basis. And SMTP servers are updated from time to time, but the refresh cycles are fairly long and the incentives to care about encryption are not great. If we want people to encrypt for the common good, despite lack of apparent benefit to them, we must not erect barriers to adoption in the form of interoperability problems. Obsoleting mainstream ciphers has a major interoperability impact and takes time, (especially RC4 which was rumoured better than CBC after CRIME and BEAST, was the best cipher in Windows 2003, and outperformed the alternatives in the absense of hardware support). What RFC 7435 says is that OS systems can be more tolerant of deprecated algorithms when interoperability considerations trump the security analysis. Such tolerance is not forever. > If you accept that software that is updated once can be continuously > maintained thereafter, then it's not a stretch to conclude that > deploying good ciphers is equally feasible. Deployment of good ciphers is taking place, slowly. In the mean-time, there's email to be delivered, and users who rightly expect OS to not get in the way. Encryption is a nice-to-have. * Deliver the email * Encrypt if possible (RFC 3207, 7435) * Authenticate when requested by the peer (RFC 7435, SMTP DANE draft). In practice, OS is working quite well, Google's outbound mail (which is much less dominated by bulk mail ads than their inbound mail) is now ~81+% encrypted, up from ~77% a year ago: https://www.google.com/transparencyreport/saferemail/ -- Viktor. From nobody Tue Aug 25 14:44: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 6170E1A8789 for ; Tue, 25 Aug 2015 14:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-nsC1BOCQbV for ; Tue, 25 Aug 2015 14:44:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2231A8AC4 for ; Tue, 25 Aug 2015 14:44:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6EDFB284B56; Tue, 25 Aug 2015 21:44:11 +0000 (UTC) Date: Tue, 25 Aug 2015 21:44:11 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150825214411.GS9021@mournblade.imrryr.org> References: <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 21:44:14 -0000 On Tue, Aug 25, 2015 at 01:39:39PM -0400, Viktor Dukhovni wrote: > > I don't think anyone is saying that bad crypto isn't better than no > > crypto, but how we define OS and continue to use the definition may > > matter for algorithm and cipher suite deprecation efforts. It's long > > been a practice for legacy systems to continue to use deprecated > > protocols, algorithms and cipher suites, but we've said they are not > > in compliance with RFCXXXX. Do we really want to start down a path of > > saying it's okay because it falls under OS? I'd rather not. We would > > get to about the same result, but perhaps we could have more success > > with deprecation transitions if these older options are not 'blessed'. > > How to position deprecation is more of a marketing than a technical > question. I agree that we don't want to dilute the message that > deprecated ciphers should be phased out as quickly as possible. > OS is not a license to indefinitely ignore deprecation. > > The key issue is what "as quickly as possible" means. For OS, it is likely > to mean that the process takes longer, because the relative priorities of > interoperability and security are different than with non-OS designs. > > So by all means, publish unequivocal deprecation of RC4, ... but expect > that OS applications will take some time to act on such publications and > rightly so. I should note, that premature deprecation of algorithms and/or protocol features by library maintainers who are not attuned to the needs of OS applications is already having detrimental effects. For example, LibreSSL 2.2.2 has not only removed support for SSL 2.0 and SSL 3.0, but has also removed TLS server support for SSL-2.0-compatible HELLO. This means that servers linked with LibresSSL are unable to complete a TLS handshake with clients that have not yet disabled SSL 2.0 and are still sending SSLv2-compatible HELLO. Such clients are not uncommon. The Postfix user who ran into this problem reverted to linking Postfix with OpenSSL. In the OpenSSL "master" branch (future 1.1.0), SSL 2.0 and SSL 3.0 are disabled just like in LibreSSL 2.2.2, but support for SSLv2-compatible HELLO is retained (on servers, but the client code will never send such a HELLO). It takes care and sound judgement to preserve interoperability, and not all applications have the same needs. So while the "marketing" message needs to be clear and unequivocal (stop using obsolete crypto), in libraries the underlying technical changes to support that need to be constructed more carefully, and final removal may be the last step of a process that happens across multiple releases that gradually reduce support. * Remove from use by default. * Reduce relative preference. * Require non-default compile-time options to enable. * Remove the code. Applications can move more aggressively, and use appropriate APIs to disable obsolete crypto faster because they are better positioned to know where to draw the line between security and interoperability with legacy systems. -- Viktor. From nobody Tue Aug 25 15:04: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 42D821A923E for ; Tue, 25 Aug 2015 15:04:39 -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 cavNsf8vTSJ6 for ; Tue, 25 Aug 2015 15:04:37 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 8891E1A9234 for ; Tue, 25 Aug 2015 15:04:37 -0700 (PDT) Received: by widdq5 with SMTP id dq5so27293778wid.0 for ; Tue, 25 Aug 2015 15:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Enzoleizd9oTYYMtDeHfNMuX66wKLMx79+g4CjjsK78=; b=dn9yBy2z7KKSPTJPM4gjnyfDF/RR/QUMk1FWzogK6d0ihkc2AUS7k8Q/ZQrFrrHAl9 8jG1G2kaVe9Ekb2aqu+hMwCFN8wv0zY5Cx30E4KPFX6Yq3OezN/OyMk9jRqasIZ2P1EY 6gPCpng4ub9peSjJnq68SjAI4eVa1S8giX3mZu4DP3sSl2Kj2fWVIClK8g/C7BOLwqrd KMfMDXH2deFTCmpDjPsTJ25iLzCPvbaDSa/HuSlyMlR5WDEwmN2qHp1fWbHuJcVSfLl4 Qquns8S5sJodWcleT/6+zF0zqQ7HiQrk0bwfmqB71hPsEuwd3i6v1spQ0moApUa5tfPf ByJw== X-Received: by 10.194.2.51 with SMTP id 19mr56252383wjr.40.1440540276272; Tue, 25 Aug 2015 15:04:36 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id q8sm4539028wik.24.2015.08.25.15.04.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Aug 2015 15:04:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <55DC961A.903@cs.tcd.ie> Date: Wed, 26 Aug 2015 01:04:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 22:04:39 -0000 > On Aug 25, 2015, at 7:21 PM, Stephen Farrell = wrote: >=20 >=20 > Viktor, >=20 > (Here we are back at this argument again:-) >=20 > On 25/08/15 17:06, Viktor Dukhovni wrote: >> In any case, whether it is RC4 now, or some other deprecated >> ciphersuite in the futre, with opportunistic security one needs to >> pay more attention to what interoperates than what is unequivocally >> strong. The goal is as much security as can be realistically had, >> not "all or nothing". I like to make an analogy with vaccination, >> we're protecting the infrastructure as a whole, rather guaranteed >> security for a particular flow. >=20 > Do you agree though that there are at least two points in time > involved when considering weakened or suspect ciphers? >=20 > There is the time you're discussing of when the bad algorithm > can be turned off without damaging interop of ciphertext form > packets. >=20 > But there is also the time after which one considers that all > such ciphertext will in a short while be almost the same as > plaintext for a capable attacker. It depends on what that capable attacker is trying to do. If this = adversary is attacking *your* communications, you=E2=80=99re right. If = the adversary is attempting pervasive monitoring, this stage almost = never comes. If every TCP connection today was encrypted with DES a = capable attacker could decrypt any connection but not every connection. = They couldn=E2=80=99t even decrypt 1% of all connections. So against an = adversary engaging in pervasive monitoring, even single DES is = significantly better than cleartext. Yoav From nobody Tue Aug 25 15:17: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 3B0551A0049 for ; Tue, 25 Aug 2015 15:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W76ww8xYhiHy for ; Tue, 25 Aug 2015 15:17:10 -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 BBB771A1B5D for ; Tue, 25 Aug 2015 15:17:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4E130BE64; Tue, 25 Aug 2015 23:17:06 +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 RtXb5VqKVEJt; Tue, 25 Aug 2015 23:17:05 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.21.200]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D39C6BE5D; Tue, 25 Aug 2015 23:17:04 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440541024; bh=tRapxTdZxm5LQYpEvfzG7go5t5rvvmDS7bfNV06FTmo=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=GPD74Mb6XWzNDnlpx+hm1CB0E5IdeFGQpXpCvEMBT88TJA4WVmdKRuLeO6VFLVfy7 +y/v6Ia7/jeYEsNZmDvCkP4LlhAbeb0nS+F2fcD96jm6NpN446BytSOspK8jLVHJmd RGzAPgsE3YAmfiWqa7P0Fiw9Zp9hbT2/tyEBsfRk= Message-ID: <55DCE960.4090801@cs.tcd.ie> Date: Tue, 25 Aug 2015 23:17:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Yoav Nir References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 22:17:11 -0000 On 25/08/15 23:04, Yoav Nir wrote: > It depends on what that capable attacker is trying to do. If this > adversary is attacking *your* communications, you’re right. If the > adversary is attempting pervasive monitoring, this stage almost never > comes. If every TCP connection today was encrypted with DES a capable > attacker could decrypt any connection but not every connection. They > couldn’t even decrypt 1% of all connections. So against an adversary > engaging in pervasive monitoring, even single DES is significantly > better than cleartext. Mostly fair point, though one might speculate as to whether RC4 may end up easier than single DES. (Actually, do we have any good information about that? I guess there aren't many publications on the relative weaknesses of weak ciphers.) But it's also the case that OS aims to protect against passive attacks and to force the adversary to be active. That property of OS should still apply even if we're only talking about 1% or 0.0001% of all traffic and is lost if we have a somewhat patient adversary who has enough meta-data to decide how to spider through a large trove of weak ciphertext, which seems likely to me. So yes, very weak ciphers are still better than plaintext when we consider easily searching the entire cache of recorded data, but that is not the only property we want when applying the OS design pattern. Being secure against a passive targeted attack for as long as the application traffic remains sensitive is also a goal of OS, I think. (Note: I'm not saying we can be sure of that, but it is a goal.) S. PS: Even if we don't reach a snappy new statement of how OS and weaker crypto play together, I think this discussion is useful, for me at least. From nobody Tue Aug 25 15:54:18 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 06BF11B2F17 for ; Tue, 25 Aug 2015 15:54:17 -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 HbjxXL10GsO6 for ; Tue, 25 Aug 2015 15:54:14 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0684.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::684]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236AC1B2F14 for ; Tue, 25 Aug 2015 15:54:14 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.1.243.23; Tue, 25 Aug 2015 22:53:54 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0243.020; Tue, 25 Aug 2015 22:53:54 +0000 From: "Paterson, Kenny" To: Stephen Farrell , Yoav Nir Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQwLSs3KuaLDlrpEWFnhMCe0p1yp3g5oyAgA7gMICAAFiLAIAACT4AgAA5LACAAAn0gIArapgAgAAQKoCAAAD7AIAABQaAgAChAoCAAGk9gIAAIbYAgAAGOQCAAARGAIAAX8UAgAADgACAABsHAA== Date: Tue, 25 Aug 2015 22:53:54 +0000 Message-ID: References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <55DCE960.4090801@cs.tcd.ie> In-Reply-To: <55DCE960.4090801@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [92.3.212.0] x-microsoft-exchange-diagnostics: 1; DBXPR03MB384; 5:fVOV6fQxjCjRWBX/Hjn5ZId4Ku3crYIWpJUFwLIxwfY9YwdDG5/c4rkhpgEZiPfCqAz+FNI4+nVLmpQ2L2xR+Ganl+SnpAwViIJ9Ev3B5+10w+sfAT1CUDvxdXcFTYzlr82X1Ffkj3cs0cMeGuUlYg==; 24:4gW6voXBifHPB1Y4NgFu+40gcegODxTUvXLlocIyJpDvy39vRBy//gL0G/OjyzhnA3uT4ZpejRZ9tAoOwXHbwUleedpLfSWeeWRwI3w/hKc=; 20:zzY1j8iTTSDGb+hPerFNjm7hrBDokpLWEj4NO5wq0m17fVpTbpZmW70TYrQjyph2574IwOl6kY7cw80UHB32bA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB384; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:DBXPR03MB384; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB384; x-forefront-prvs: 06793E740F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(189002)(199003)(24454002)(62966003)(54356999)(77156002)(5007970100001)(105586002)(2900100001)(106356001)(106116001)(74482002)(230783001)(5004730100002)(122556002)(19580395003)(92566002)(93886004)(40100003)(19580405001)(5001770100001)(77096005)(76176999)(97736004)(50986999)(46102003)(87936001)(15975445007)(64706001)(81156007)(4001540100001)(36756003)(83506001)(4001350100001)(5001960100002)(86362001)(2656002)(2950100001)(189998001)(5001860100001)(5002640100001)(101416001)(102836002)(68736005)(66066001)(5001830100001)(10400500002)(7756004); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2015 22:53:54.3764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB384 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 25 Aug 2015 22:54:17 -0000 Hi On 25/08/2015 23:17, "saag on behalf of Stephen Farrell" wrote: >Mostly fair point, though one might speculate as to whether RC4 >may end up easier than single DES. (Actually, do we have any good >information about that? I guess there aren't many publications on >the relative weaknesses of weak ciphers.) This is something I can say a bit about. Let's take TLS with DES and RC4. To break a DES-protected connection aqap, you'd use an exhaustive key search, needing a couple of known plaintext/ciphertext blocks (not a problem for most application protocols running over TLS). Cost: a few thousand dollars for the FPGAs; time: depends on budget of course, but embarrassingly parallelisable. You've then got the key and can decrypt the whole TLS connection. To break RC4 in TLS, with the current public state of the art [1,2], you'd somehow need to gather 2^26 - 2^30 encryptions of the same plaintext. That can be done in some circumstances, e.g. malicious javascript running the browser, with the target being HTTP cookie, but it's a bit of a stretch. What you get back is that (short) plaintext, rather than the key. So with the *current* state of the art, the attack requirements and attack results are quite different. Despite the strict incomparability, I think it's reasonable to say that DES is currently *much* less secure than RC4 in the TLS context. What we don't know is how the attacks will evolve in future. My guess is that the DES attack will not get any better in an interesting way (that is, save for falling costs of hardware). DES is a good block cipher with too small a key (and too small a block). And it feels to me that, for RC4, the currently known public techniques are starting to run out of steam. Maybe someone will come up with some fresh ideas. Meanwhile, we don't really know the capabilities of government agencies against RC4. Cheers, Kenny =20 [1] http://www.isg.rhul.ac.uk/tls/RC4mustdie.html [2] https://www.rc4nomore.com/ From nobody Tue Aug 25 22:52: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 230231A01FA for ; Tue, 25 Aug 2015 22:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsIedn9cQFu1 for ; Tue, 25 Aug 2015 22:52:46 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 52F481A001D for ; Tue, 25 Aug 2015 22:52:43 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id D662BB8094; Tue, 25 Aug 2015 22:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=g1i6ocmp+cXdgp mzT/tkujmWdJM=; b=BldvqHvQ6pT1frIfWPIj1G3Tc9z0UOq0otcVyBXihZya8Z 0ahTC01rBvY68RAtwa4ZW6dD2NYId4fn8EWg0k0vyEP3VnbIkLISAfg1NpDstHnR OaZDulB8gXr0lllA3jiD/bBTsvquWoEvo//yBmiDqJJ/oMDiwIS4T4Q4SVBu0= Received: from localhost (unknown [38.125.52.165]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 72065B8086; Tue, 25 Aug 2015 22:52:42 -0700 (PDT) Date: Wed, 26 Aug 2015 00:52:41 -0500 From: Nico Williams To: Stephen Farrell Message-ID: <20150826055240.GD13302@localhost> References: <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55DC961A.903@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 26 Aug 2015 05:52:53 -0000 On Tue, Aug 25, 2015 at 05:21:46PM +0100, Stephen Farrell wrote: > On 25/08/15 17:06, Viktor Dukhovni wrote: > > In any case, whether it is RC4 now, or some other deprecated > > ciphersuite in the futre, with opportunistic security one needs to > > pay more attention to what interoperates than what is unequivocally > > strong. The goal is as much security as can be realistically had, > > not "all or nothing". I like to make an analogy with vaccination, > > we're protecting the infrastructure as a whole, rather guaranteed > > security for a particular flow. > > Do you agree though that there are at least two points in time > involved when considering weakened or suspect ciphers? > > There is the time you're discussing of when the bad algorithm > can be turned off without damaging interop of ciphertext form > packets. > > But there is also the time after which one considers that all > such ciphertext will in a short while be almost the same as > plaintext for a capable attacker. > > And the latter can happen before the former. We've been pwned, so we want that to stop, and the way we're choosing to make it stop is to shoot ourselves in the feet. Less rhetorically: We know RC4 is weak and we want to use something else that's better instead. Clearly, we can ban RC4, but that isn't a magic wand that makes everyone start using AES or what have you. Still, we plow on because hey, some TLS implementors will understand the SMTP OS situation and won't break that application. But! if we merrily write text telling TLS implementors to remove RC4, many of them will, and in the process they will make security/interop for SMTP demonstrably worse (as Viktor has shown). It seems we can't be moderate in how we approach cipher obsolescence, perhaps because... we're embarrassed to have obsolete ciphers around so long after they became obsolete? That's not a good excuse for throwing a big switch. A good excuse for throwing the switch is any case where merely offering weak crypto introduces a downgrade attack, but that's not the case here. "Look ma'!, we banned the bad thing" is clever marketing. For a short while. "Look ma'!, we're getting off the old thing and onto the new, and we're giving people time so we don't make things worst in the short-term" is a mouthful and ma' will have to think about it before deciding that we're doing the right thing, but it is the right thing. We totally can live with an outright ban on RC4. That not all TLS implementors will adhere to. Or accept the loss of security/interop for SMTP. If implementors willfully diverge from the spec, then the spec is probably wrong. If implementors faithfully implement a spec, and as a result applications break, the spec is probably wrong. The only hope for an outright ban is that breakage causes people to go fix it. But with SMTP OS it's not always clear to users that there's breakage, and when it is clear (mail won't flow) it isn't always easy to go fix it. Nico -- From nobody Wed Aug 26 02:42:23 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 61FCB1A00BC for ; Wed, 26 Aug 2015 02:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-6P5MN_gfhL for ; Wed, 26 Aug 2015 02:42:19 -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 EF1AD1A1A07 for ; Wed, 26 Aug 2015 02:42:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0BD35BE5D; Wed, 26 Aug 2015 10:42:17 +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 6AqZctC82tDD; Wed, 26 Aug 2015 10:42:16 +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 1B53ABDF9; Wed, 26 Aug 2015 10:42:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440582130; bh=cQcfQHE1o2f5s2xYjaDANYGmag1b3kNAVwuX2zIETQ0=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=RGPxaQzijxWIj7RjdT62dhUCCIN/x3c1mgtVcRc5ZvCX2kHHUnIWsd81WK0IWVjKs +PP1DTL6MUJTjFss0Vi5f/T4ZK/b7xju4+UzqGSFZa+3yspFGpSKEouLqY2W9TIcbg wmO1k83NIGTFG1QlMGtYThLRnapbGENZmYddSqgo= Message-ID: <55DD89F2.8050801@cs.tcd.ie> Date: Wed, 26 Aug 2015 10:42:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Nico Williams References: <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <20150826055240.GD13302@localhost> In-Reply-To: <20150826055240.GD13302@localhost> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: saag@ietf.org Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 26 Aug 2015 09:42:21 -0000 Hi Nico, On 26/08/15 06:52, Nico Williams wrote: > We know RC4 is weak and we want to use something else that's better > instead. Clearly, we can ban RC4, but that isn't a magic wand that > makes everyone start using AES or what have you. Still, we plow on > because hey, some TLS implementors will understand the SMTP OS situation > and won't break that application. But! if we merrily write text telling > TLS implementors to remove RC4, many of them will, and in the process > they will make security/interop for SMTP demonstrably worse (as Viktor > has shown). > > It seems we can't be moderate in how we approach cipher obsolescence, > perhaps because... we're embarrassed to have obsolete ciphers around so > long after they became obsolete? That's not a good excuse for throwing > a big switch. A good excuse for throwing the switch is any case where > merely offering weak crypto introduces a downgrade attack, but that's > not the case here. > > "Look ma'!, we banned the bad thing" is clever marketing. For a short > while. "Look ma'!, we're getting off the old thing and onto the new, > and we're giving people time so we don't make things worst in the > short-term" is a mouthful and ma' will have to think about it before > deciding that we're doing the right thing, but it is the right thing. > > We totally can live with an outright ban on RC4. That not all TLS > implementors will adhere to. Or accept the loss of security/interop for > SMTP. If implementors willfully diverge from the spec, then the spec is > probably wrong. If implementors faithfully implement a spec, and as a > result applications break, the spec is probably wrong. The only hope > for an outright ban is that breakage causes people to go fix it. But > with SMTP OS it's not always clear to users that there's breakage, and > when it is clear (mail won't flow) it isn't always easy to go fix it. I'm sorry but you're entirely ignoring the use of RC4 in the web which was a very important part of this. While there may be a rump of smtp servers that are broken and that won't upgrade soon, there was a very large proportion of the web using RC4 before we deprecated it, and now there is far less, with no breakage. (See Richard's presentation at saag in Prague.) That change wasn't caused by us, but we did the right thing to help it along with RFC7465. Another of the lessons of OS (or rather, of more seriously considering deployment realities) is that we sometimes need to think outside our own silos. That goes for mail folks and web folks and others too. (I'm not saying you're one or other of those, but your mail was very silo-specific.) S. > > Nico > From nobody Wed Aug 26 02:54: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 8A2131B2A04 for ; Wed, 26 Aug 2015 02:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKCLXIHwzAM7 for ; Wed, 26 Aug 2015 02:54:47 -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 93B361B29F9 for ; Wed, 26 Aug 2015 02:54:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6BD45BDF9; Wed, 26 Aug 2015 10:54:46 +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 viGWPXxr0O_M; Wed, 26 Aug 2015 10:54:46 +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 3CA8FBDCA; Wed, 26 Aug 2015 10:54:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440582886; bh=zbuefdUZeS/9jY2UOkM/I8OUqVVl9Du69VGC4+CgSyk=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=0plTGq5HdbaH0w+FBbkAGM72oyKNk+wP45XrRdgRdFAzSbaSToCGAB4GJJ7jSQHTD umyK4A1AUjNd2/Lhbh5EJY+YVSQMNJ5+rLQgzvGHHoHQn5BRYGdqLw5TUJ+wzsS/o6 6ODWrJ6sHtJEvEI/582QtyFO/bHkkpguAvBcW6Pw= Message-ID: <55DD8CE6.9030508@cs.tcd.ie> Date: Wed, 26 Aug 2015 10:54:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "Paterson, Kenny" , Yoav Nir References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <55DCE960.4090801@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 26 Aug 2015 09:54:48 -0000 On 25/08/15 23:53, Paterson, Kenny wrote: > And it feels to me that, for RC4, the currently known public techniques > are starting to run out of steam. Thanks. I wasn't aware of that. The only thing I'd add to your mail is that when you say that we don't know how attacks will evolve, that's not quite true. We do know that the attacks always get better, but we don't know by how much or when. S. From nobody Wed Aug 26 03:28:12 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 2B37E1A700A for ; Wed, 26 Aug 2015 03:28:11 -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 01VBjmBdD5S1 for ; Wed, 26 Aug 2015 03:28:09 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0640.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::640]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450DD1A1EF9 for ; Wed, 26 Aug 2015 03:28:09 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.1.243.23; Wed, 26 Aug 2015 10:27:52 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0243.020; Wed, 26 Aug 2015 10:27:52 +0000 From: "Paterson, Kenny" To: Stephen Farrell , Yoav Nir Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQwLSs3KuaLDlrpEWFnhMCe0p1yp3g5oyAgA7gMICAAFiLAIAACT4AgAA5LACAAAn0gIArapgAgAAQKoCAAAD7AIAABQaAgAChAoCAAGk9gIAAIbYAgAAGOQCAAARGAIAAX8UAgAADgACAABsHAIAAp+gAgAAZ9oA= Date: Wed, 26 Aug 2015 10:27:51 +0000 Message-ID: References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <55DCE960.4090801@cs.tcd.ie> <55DD8CE6.9030508@cs.tcd.ie> In-Reply-To: <55DD8CE6.9030508@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [78.146.79.170] x-microsoft-exchange-diagnostics: 1; DBXPR03MB384; 5:hFgTJtuiCob7IzweVinxnM4Sf+vsT+gXSwrokh5zgg6MwiA0sM4U2qmJVe5iAPGGLt2NMSik2icWj6l+lp5CNuSlMCQD168Edaym08iZK+43GTEVNjI0/HBDP7tcCDPc55fN7ggmQAkTH6F5Lg9H8w==; 24:LHVvPrPUTr2mzqg+9T+jHh4VCqaHB3GK+fGOL1UvArPtHMd6wH4gJV6OME1YAFfT2foROQhMN2NCobSD62u49zjaI6j0IC5m7YB6qeePoRg=; 20:quaqoXNL5yR9APfq5TtwmwIyoglF1Q0xwE9SxTBJgYRvXI+Tp9pe6/5D7QfTmhU7yf19/gIVRyt6fLHi3wHBRw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB384; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:DBXPR03MB384; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB384; x-forefront-prvs: 0680FADD48 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(189002)(199003)(24454002)(77156002)(54356999)(62966003)(5004730100002)(5007970100001)(105586002)(106116001)(74482002)(106356001)(2900100001)(122556002)(19580395003)(92566002)(93886004)(40100003)(19580405001)(97736004)(76176999)(46102003)(4001350100001)(64706001)(77096005)(5001770100001)(50986999)(81156007)(189998001)(230783001)(4001540100001)(36756003)(83506001)(5001960100002)(2656002)(86362001)(68196006)(2950100001)(101416001)(5002640100001)(102836002)(5001860100001)(68736005)(66066001)(5001830100001)(87936001)(10400500002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <0931C1C605C1E941AF2E1E87DD763318@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2015 10:27:51.9305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB384 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 26 Aug 2015 10:28:11 -0000 Hi On 26/08/2015 10:54, "Stephen Farrell" wrote: > > >On 25/08/15 23:53, Paterson, Kenny wrote: >> And it feels to me that, for RC4, the currently known public techniques >> are starting to run out of steam. > >Thanks. I wasn't aware of that. To be clear: it's just my personal opinion, based on working on this specific area for a while. We shouldn't ignore the possibility of smarter people being attracted to the problem now and making progress with new ideas. > >The only thing I'd add to your mail is that when you say that we don't >know how attacks will evolve, that's not quite true. We do know that >the attacks always get better, but we don't know by how much or when. Agreed, and I'm now surprised I didn't write that myself ;-) Cheers Kenny=20 > >S. From nobody Wed Aug 26 03:48:14 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 F0A901ACDE1 for ; Wed, 26 Aug 2015 03:48:12 -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, 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 jmne7EY27agA for ; Wed, 26 Aug 2015 03:48:09 -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 23A4B1ACD6B for ; Wed, 26 Aug 2015 03:48:09 -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=1440586089; x=1472122089; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=pjeITi40Q1V9Ih+VSzyrMKWeI9TdfarqI5bbOmsI9vU=; b=OYmScKsaB1qtauaDBELrPMiRp+olcYGuef9HOEy9VRPD9MdQB34qOJyw jH7plzYgYJmHzUyhlj6TlWJCQxpqIWHu8x9RsLjCd/GknTi2v7SPRTpbK iGzYE2L8svfoYC8edY54U+ht4ZuOlrgOJ9eOVgRN0bE1aFi5TkB5dY7wg Epi0wtn2COvF06CJGjdYRPS0BV2BqeeWGJdNQ3sMfr+LuCqkEDqn4REQG 8NLdfD3iNC0z8Z5NxDFlYJgyn20Z3FjjtoPo+LhBZw02mheZbyoRIfNiK 65sWwnxR67YBJ8ZNmDw2QYsZl9NYT0mqvn75vTLaE9QeEp9IQcbv7vA1G w==; X-IronPort-AV: E=Sophos;i="5.17,415,1437393600"; d="scan'208";a="37803690" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Aug 2015 22:48:07 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 26 Aug 2015 22:48:07 +1200 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQ3qvbT9ZhMqG4SESDb9hHYel1Rp4a4U6AgAAA+wCAAAUHgIABabjA//+gh4CAACG1AIAABjkAgAAFlYCAABR0gIAARFKAgAGj6uI= Date: Wed, 26 Aug 2015 10:48:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AE7336@uxcn10-5.UoA.auckland.ac.nz> References: <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org>, <20150825214411.GS9021@mournblade.imrryr.org> In-Reply-To: <20150825214411.GS9021@mournblade.imrryr.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 review of draft-iab-crypto-alg-agility-06 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, 26 Aug 2015 10:48:13 -0000 Viktor Dukhovni writes:=0A= =0A= > * Remove from use by default.=0A= > * Reduce relative preference.=0A= > * Require non-default compile-time options to enable.=0A= > * Remove the code.=0A= =0A= That's more or less what I use, specifially, "make the option least-=0A= preferred", then "require a custom compile", then "remove the code", with a= n=0A= occasional "reinsert the &*)(($)@ code because some widely-used app is stil= l=0A= living 15 years in the past".=0A= =0A= The problem with trying to handle backwards-compatibility is that the long= =0A= tail never actually reaches zero but instead tends toward some (non-zero)= =0A= constant of users who will never upgrade if they're not forced to. This is= =0A= why you can't maintain backwards-compatibility for ever, some users have to= be=0A= forced to upgrade. What I typically do is make something a compile-time=0A= option that's not enabled in any standard build, so they have the option to= =0A= enable the deprecated behaviour at the expense of building and distributing= =0A= custom binaries to do so. Suddenly the absolutely-impossible-can-never-be-= =0A= done upgrade magically becomes possible, because the cost of not upgrading = has=0A= become nonzero. The trick is figuring out how nonzero to make it, and on= =0A= which time schedule.=0A= =0A= Peter.=0A= From nobody Wed Aug 26 04:50: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 CD35D1ACD55 for ; Wed, 26 Aug 2015 04:50:00 -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 pY4gzpKh29Qa for ; Wed, 26 Aug 2015 04:49:59 -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 62AED1AC41D for ; Wed, 26 Aug 2015 04:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1362; q=dns/txt; s=iport; t=1440589799; x=1441799399; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=4C7kJ7v/Yxz0Kz1oSrzvR6EiXihM3Kq4oMjkdMri/7o=; b=ZY7l4ITyeY92KFy5KAO4Q0DIjjPPLy/xxoY2RptE7ClHeeJw2+PV1CDz NbvHgQNJTNucRQPOBDN3PMAiOMDlH0I2rVhKtaTiuKsMZWnvtHYiLDTne ixb5idfUMTpSHaMZD/Rnrz4m45iKJChWWQ3x2yBi52+LSNhbR56687GAf o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CgBADHpt1V/xbLJq1dh3vCPQKCBAEBAQEBAYELhCQBAQMBI1UGCwshFgsCAgkDAgECAUUTCAEBiCIIs0iUfwEBAQcCIItbhREXglKBQwEEhyaGcYcggkCBXIhWiHeRZCaEADyCfwEBAQ X-IronPort-AV: E=Sophos;i="5.17,415,1437436800"; d="asc'?scan'208";a="604712460" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Aug 2015 11:49:57 +0000 Received: from [10.61.210.101] ([10.61.210.101]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7QBnvdZ008744 for ; Wed, 26 Aug 2015 11:49:57 GMT To: saag@ietf.org References: <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <20150825165539.GL9021@mournblade.imrryr.org> From: Eliot Lear Message-ID: <55DDA7E4.1090807@cisco.com> Date: Wed, 26 Aug 2015 13:49:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150825165539.GL9021@mournblade.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OiQ2lauL7QoRW5h94jTUvbfpeKllAu6C1" Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 26 Aug 2015 11:50:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OiQ2lauL7QoRW5h94jTUvbfpeKllAu6C1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 8/25/15 6:55 PM, Viktor Dukhovni wrote: > The nasty part is that cleartext fallback is not always desirable > or available. Sendmail IIRC does not fall back after STARTTLS > handshake failure. Yes that's right. Instead you get a 403 4.7.0 TLS handshake failed.=20 This is now happening all over the place, as it turns out, due to the recent changes to the OpenSSL library involving dh processing. Eliot --OiQ2lauL7QoRW5h94jTUvbfpeKllAu6C1 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 iQEcBAEBCAAGBQJV3aflAAoJEIe2a0bZ0nozO1wH/2WVdpmyVRIhyngKFiV6RpK7 XkXtfztWeEFEcG7R+RQOxPaN3Qta+OESMEgz5SaMYCYs3euIEWJK2lVFNPSwVnmh +vxt2lU6mnpZPKxDq7LxTlFFsR7LOQlmm4W3k99CIguIcMpWS+YnIA/B9qakJ0bs xdZdWq8dsI4SVbSF/PmiFhkP4XhS8y4piNhf8VECXVsovS5O+dKAwO/zCyjVu10+ aKZ1/1NGXdq9AootaFU7wH423d8fVpkCsN+1mjolKORFvl2YBBkoSLfhk9BK4O6N CBs/JQSgqA8DbQcw1ayJgMvA+b/5FgByQECaIEko7B8pocQ0oXiGbBMd5VtT4/M= =NGLi -----END PGP SIGNATURE----- --OiQ2lauL7QoRW5h94jTUvbfpeKllAu6C1-- From nobody Wed Aug 26 06:50: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 0089B1B2B73 for ; Wed, 26 Aug 2015 06:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0ER4aXkeCkg for ; Wed, 26 Aug 2015 06:50:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FF91B2B30 for ; Wed, 26 Aug 2015 06:50:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EFBAC284D24; Wed, 26 Aug 2015 13:50:43 +0000 (UTC) Date: Wed, 26 Aug 2015 13:50:43 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150826135043.GU9021@mournblade.imrryr.org> References: <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <20150825165539.GL9021@mournblade.imrryr.org> <55DDA7E4.1090807@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55DDA7E4.1090807@cisco.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 13:50:47 -0000 On Wed, Aug 26, 2015 at 01:49:56PM +0200, Eliot Lear wrote: > On 8/25/15 6:55 PM, Viktor Dukhovni wrote: > > > The nasty part is that cleartext fallback is not always desirable > > or available. Sendmail IIRC does not fall back after STARTTLS > > handshake failure. > > Yes that's right. Instead you get a 403 4.7.0 TLS handshake failed. > This is now happening all over the place, as it turns out, due to the > recent changes to the OpenSSL library involving dh processing. With Logjam we don't have much choice but to break compatibility with 512-bit DH, because we're mitigating a downgrade attack. Are there many servers out there with 512-bit DH keys not only for export ciphers but across the board? Sendmail uses a single set of DH parameters, rather than one set for export and another for non-export ciphers, and perhaps it was not entirely uncommon to configure it to use 512-bit DH parameters across the board. The Sendmail DH code has incorrect assumptions and corresponding internal documentation. It assumes wrongly that TLS clients need to configure DH parameters. (Sendmail could avoid loading or generating DH parameters when running as a client). Sendmail should have been using the OpenSSL DH parameter callback API, rather than setting fixed parameters for both export and non-export ciphers. Needless to say the TLS functionality in Sendmail does not appear to be very actively maintained. :-( -- Viktor. From nobody Wed Aug 26 07:53: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 A1A391A0266 for ; Wed, 26 Aug 2015 07:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 7ONhQka9j6i4 for ; Wed, 26 Aug 2015 07:53:08 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (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 36A0C1A0074 for ; Wed, 26 Aug 2015 07:53:08 -0700 (PDT) Received: by obkg7 with SMTP id g7so173189749obk.3 for ; Wed, 26 Aug 2015 07:53:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=m6GuLL9LfpjZMLrlVrZ8JNe+ivNm4YgUvaIB6Mk7oD0=; b=eQsgZPN7XqyjPNo0LnG60vHVE6ro3ux8bcdJmfiAudjorOq9SIMSsIhOr4SW4MrfF5 zdz+ESeXCgjbidrfqPvNZYrT8ginLCi9dvRV/ctvigvF+9dWIO57FUh3a844h7EAHfTx GuaX2tRj4XWXjXYYZsAFrKw0iUP+cxL91AGWN6Lij35303KTtFruM17WzYbRHwatlVq7 o7QNJEvZoY8N6lZtxL7JMeDOSCYeU8/8P2hahNnZFD3VQifK17bwc/B3OPQv4zu07wN0 zP7ALKiOV4NzJRPoKM4rDKj9NyKz2d9M6Kuh6Birt3aB7XYSbVhzjE3yhfhjB7Uj9aOZ +WkA== X-Gm-Message-State: ALoCoQmRDH+sYwbuMjzfEEHs4wUAs6oToyKVpJGItbc3USjeVUW8whwWboiVa73mjxjnFujPm7Wn MIME-Version: 1.0 X-Received: by 10.182.68.68 with SMTP id u4mr27734144obt.86.1440600787513; Wed, 26 Aug 2015 07:53:07 -0700 (PDT) Received: by 10.202.174.144 with HTTP; Wed, 26 Aug 2015 07:53:07 -0700 (PDT) Date: Wed, 26 Aug 2015 10:53:07 -0400 Message-ID: From: Warren Kumari To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 26 Aug 2015 14:53:09 -0000 Hi there all, I'd appreciate it if folk could have a look at this draft and provide any feedback. I'm not sure that SAAG is the right place for it, but I couldn't think of anywhere better. https://tools.ietf.org/html/draft-wkumari-owe-01 Note that this is NOT intended to be the be all and end all of secure wireless, it is simply intended to make open wifi suck somewhat less. We are not claiming great security (the WPA2 4-way handshake significantly limits what can be achieved), and so much of the draft / idea is making sure that users do not get a false (or any) sense of security - this should be transparent to them. We also want it to be *really* simple, so that commodity CPE vendors will include "support" (basically a flag in the beacon) - this removes other solutions like .1X, etc. Appreciate your time, W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Aug 26 10:01:43 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 1C0BA1B2E08 for ; Wed, 26 Aug 2015 10:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl3xMspxEQrk for ; Wed, 26 Aug 2015 10:01:39 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883191B2DE6 for ; Wed, 26 Aug 2015 10:01:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A4643284D26; Wed, 26 Aug 2015 17:01:38 +0000 (UTC) Date: Wed, 26 Aug 2015 17:01:38 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150826170138.GB9021@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 17:01:41 -0000 On Wed, Aug 26, 2015 at 10:53:07AM -0400, Warren Kumari wrote: > I'm not sure that SAAG is the right place for it, but I couldn't think > of anywhere better. > > https://tools.ietf.org/html/draft-wkumari-owe-01 I'm concerned that the proposal still leaves even purely passive adversaries able to decrypt all traffic that begin during the passive traffic collection interval. This is considerably weaker than many other opportunistic security protocols. With no protection against a passive adversary who started monitoring before the victim joins the network, is this still worth doing? -- Viktor. From nobody Wed Aug 26 10:36:24 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 409BA1B2D26 for ; Wed, 26 Aug 2015 10:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 QwDsAPoNqK27 for ; Wed, 26 Aug 2015 10:36:22 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5F61B2C98 for ; Wed, 26 Aug 2015 10:36:22 -0700 (PDT) Received: by obbfr1 with SMTP id fr1so177589085obb.1 for ; Wed, 26 Aug 2015 10:36:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=YF0gaMj37Q/0A7VpEGQf5DqxHWsyybwvcYh17npWjNU=; b=iFkOtHD3RFdyjYvSviqTCqkUa/uStrsWlp8b0hhIhN7OXoRhFHggEpYoskJAuV5k6y rlwK3CvkRLc2DC/5YNcjkX7D0LJ8Vi7bJ5g84g8Jhj8wETjiy9t01RAPTwEJxPlii6iX 9Qo2jBZtd0q1tjgoqaQ5fFkggTimLB+k+SdshjlB942IZtnWPjmFsv5XokO1x8RLA+z5 k4P4XNcuX+0zOU8ldJTRkOuaJPyak5SP1FRa4j1AMUe9WFQ94Zox88Ok8eXXNSV/lrAo GwqJDorJxNA1T086nIb79puCNeqdafUFr4zcBEbrbYMvXbXda0GtzX3qPjhW8K/ma/4c DhYQ== X-Gm-Message-State: ALoCoQl/jaZqHzuXrWP1ruRLP4Zqji6U2Kno2oAgwgnduJ3qrwAlA+WJpKCgIM+NmDjb5gR7tDi8 MIME-Version: 1.0 X-Received: by 10.182.20.15 with SMTP id j15mr34525726obe.52.1440610581772; Wed, 26 Aug 2015 10:36:21 -0700 (PDT) Received: by 10.202.174.144 with HTTP; Wed, 26 Aug 2015 10:36:21 -0700 (PDT) In-Reply-To: <20150826170138.GB9021@mournblade.imrryr.org> References: <20150826170138.GB9021@mournblade.imrryr.org> Date: Wed, 26 Aug 2015 13:36:21 -0400 Message-ID: From: Warren Kumari To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a11330536fc96a6051e3a4967 Archived-At: Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 26 Aug 2015 17:36:24 -0000 --001a11330536fc96a6051e3a4967 Content-Type: text/plain; charset=UTF-8 On Wednesday, August 26, 2015, Viktor Dukhovni wrote: > On Wed, Aug 26, 2015 at 10:53:07AM -0400, Warren Kumari wrote: > > > I'm not sure that SAAG is the right place for it, but I couldn't think > > of anywhere better. > > > > https://tools.ietf.org/html/draft-wkumari-owe-01 > > I'm concerned that the proposal still leaves even purely passive > adversaries able to decrypt all traffic that begin during the > passive traffic collection interval. This is considerably weaker > than many other opportunistic security protocols. With no protection > against a passive adversary who started monitoring before the victim > joins the network, is this still worth doing? I believe that it is -- I think that the cost to implement this is really really low (I added PoC "support" to OpenWRT in less than an hour, and almost all of that was finding a suitable access point in my basement :-)). I fully acknowledge that this doesn't solve all issues, and doesn't claim to - but I think that for the negligible cost, the incremental security win is worth it. W > > -- > Viktor. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --001a11330536fc96a6051e3a4967 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, August 26, 2015, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Wed, Aug 26, 2015 at 10:53:07AM -0400, Warren Kum= ari wrote:

> I'm not sure that SAAG is the right place for it, but I couldn'= ;t think
> of anywhere better.
>
> https://tools.ietf.org/html/draft-wkumari-owe-01

I'm concerned that the proposal still leaves even purely passive
adversaries able to decrypt all traffic that begin during the
passive traffic collection interval.=C2=A0 This is considerably weaker
than many other opportunistic security protocols.=C2=A0 With no protection<= br> against a passive adversary who started monitoring before the victim
joins the network, is this still worth doing?

I believe that it is -- I think that the cost to implement this is reall= y really low (I added PoC=C2=A0"support" to OpenWRT=C2=A0in less = than an hour, and almost all of that was finding a suitable access point in= my basement :-)).=C2=A0

I fully acknowledge that this = doesn't solve all issues, and doesn't claim to - but I think that f= or the negligible cost, the incremental security win is worth it.

<= /div>
W
=C2=A0

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag


--
I don't think the execution is releva= nt when it was obviously a bad idea in the first place.
This is like put= ting rabid weasels in your pants, and later expressing regret at having cho= sen those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0= ---maf
--001a11330536fc96a6051e3a4967-- From nobody Wed Aug 26 11:30: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 E48751B303D for ; Wed, 26 Aug 2015 11:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDb0lo7MdX-7 for ; Wed, 26 Aug 2015 11:30:26 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF77C1B2FDF for ; Wed, 26 Aug 2015 11:30:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 184CDE180; Wed, 26 Aug 2015 14:30:25 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vav4F20RNWHU; Wed, 26 Aug 2015 14:30:24 -0400 (EDT) Received: from [192.168.1.192] (wsip-174-76-19-71.oc.oc.cox.net [174.76.19.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 9BFEAE1A4; Wed, 26 Aug 2015 14:30:24 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: Date: Wed, 26 Aug 2015 11:30:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 26 Aug 2015 18:30:29 -0000 > On Aug 26, 2015, at 7:53 AM, Warren Kumari wrote: >=20 > I'd appreciate it if folk could have a look at this draft and provide > any feedback. I agree with the argument that the minimal effort makes it worth doing. OTOH, I also agree that something you can=E2=80=99t break passively = would be better. How about a connection that=E2=80=99s negotiated with = D-H key exchange, but you never verify identities? (Hmmm, is there an = EAP mech that would effectively do that?) How hard will it be to get AP makers to adopt whatever is proposed? Is = the additional difficulty of DH really a dealbreaker? Personal: hbhotz@oxy.edu Business: hhotz@securechannels.com From nobody Wed Aug 26 11:52:03 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 A70841A1B69 for ; Wed, 26 Aug 2015 11:52:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNdR_3L3Oc3a for ; Wed, 26 Aug 2015 11:52:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC79C1B2C8A for ; Wed, 26 Aug 2015 11:51:59 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.231.21; Wed, 26 Aug 2015 18:51:57 +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.0231.024; Wed, 26 Aug 2015 18:51:57 +0000 From: Christian Huitema To: Warren Kumari , "saag@ietf.org" Thread-Topic: [saag] Would love some feedback on Opportunistic Wireless Encryption Thread-Index: AQHQ4CW/AZzR8B6HAU2jyV7mVrhQ2J4emrQg Date: Wed, 26 Aug 2015 18:51:57 +0000 Message-ID: References: <20150826170138.GB9021@mournblade.imrryr.org> In-Reply-To: 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.174.23] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:8aU6ZiFIFhnZsQfzNWaErkIDRYNfYvVMRx+zCu8HQ2cL3I1s+NuCSFGIyntVxxuZPQ5d02wfx3U03IoeQwlsA0Mz7ZPfmoyIdsXtZC2HML/r4UwZqy9YgC1iB4IosLnWpx4ZALhkmrB4kMlfhCCodg==; 24:/kpwX0fVBfkzUF2xyjh22VnFfC90MzpHJk34qXaR9ieTUN5jOlouKz+Uw+WMpvFUHOOIQ6sIBtkNUpaiuLrKh+5y7b8blzH2/8fO3rHEfP0=; 20:Tg9yK7zI83Bvs21ZHZYTygGJLKXDoeQhawcjQDxS3vMxEICIVU7KUsVc9ftvsaGk9dNEjPyca7Uaovpwd6w97g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655; 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)(8121501046)(5005006)(3002001); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 0680FADD48 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(51444003)(24454002)(19580395003)(97736004)(86612001)(2950100001)(122556002)(10090500001)(102836002)(8990500004)(5004730100002)(2900100001)(101416001)(92566002)(54356999)(74316001)(68736005)(5005710100001)(106356001)(50986999)(40100003)(10400500002)(33656002)(77096005)(106116001)(10290500002)(5002640100001)(2656002)(76176999)(105586002)(99286002)(5007970100001)(5001920100001)(87936001)(2501003)(107886002)(19580405001)(86362001)(77156002)(5003600100002)(81156007)(5001960100002)(66066001)(62966003)(5001860100001)(4001540100001)(76576001)(5001770100001)(64706001)(189998001)(5001830100001)(551544002)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; 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) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2015 18:51:57.3595 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 Archived-At: Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 26 Aug 2015 18:52:01 -0000 T24gV2VkbmVzZGF5LCBBdWd1c3QgMjYsIDIwMTUgMTA6MzYgQU0sIFdhcnJlbiBLdW1hcmkgd3Jv dGU6DQo+DQo+IE9uIFdlZG5lc2RheSwgQXVndXN0IDI2LCAyMDE1LCBWaWt0b3IgRHVraG92bmkg PGlldGYtZGFuZUBkdWtob3ZuaS5vcmc+IHdyb3RlOg0KPj4gLi4uwqAgVGhpcyBpcyBjb25zaWRl cmFibHkgd2Vha2VyDQo+PiB0aGFuIG1hbnkgb3RoZXIgb3Bwb3J0dW5pc3RpYyBzZWN1cml0eSBw cm90b2NvbHMuwqAgV2l0aCBubyBwcm90ZWN0aW9uDQo+PiBhZ2FpbnN0IGEgcGFzc2l2ZSBhZHZl cnNhcnkgd2hvIHN0YXJ0ZWQgbW9uaXRvcmluZyBiZWZvcmUgdGhlIHZpY3RpbQ0KPj4gam9pbnMg dGhlIG5ldHdvcmssIGlzIHRoaXMgc3RpbGwgd29ydGggZG9pbmc/DQo+IA0KPiBJIGJlbGlldmUg dGhhdCBpdCBpcyAtLSBJIHRoaW5rIHRoYXQgdGhlIGNvc3QgdG8gaW1wbGVtZW50IHRoaXMgaXMg cmVhbGx5IHJlYWxseSBsb3cgKEkgYWRkZWQgUG9DwqANCj4gInN1cHBvcnQiIHRvIE9wZW5XUlTC oGluIGxlc3MgdGhhbiBhbiBob3VyLCBhbmQgYWxtb3N0IGFsbCBvZiB0aGF0IHdhcyBmaW5kaW5n IGEgDQo+IHN1aXRhYmxlIGFjY2VzcyBwb2ludCBpbiBteSBiYXNlbWVudCA6LSkpLg0KPg0KPiBJ IGZ1bGx5IGFja25vd2xlZGdlIHRoYXQgdGhpcyBkb2Vzbid0IHNvbHZlIGFsbCBpc3N1ZXMsIGFu ZCBkb2Vzbid0IGNsYWltIHRvIC0gYnV0IEkgdGhpbmsgdGhhdCBmb3IgDQo+IHRoZSBuZWdsaWdp YmxlIGNvc3QsIHRoZSBpbmNyZW1lbnRhbCBzZWN1cml0eSB3aW4gaXMgd29ydGggaXQuDQoNCllv dSBoYXZlIHRvIGRlY2lkZSB3aG8geW91IGFyZSBvcHRpbWl6aW5nIGZvci4gVGhlIGFkbWluaXN0 cmF0b3JzIHdvdWxkIGNhbm5vdCBiZSBib3RoZXJlZCB0byBzZXQgYSBwYXNzd29yZCBmb3IgdGhl IFdpLUZpPyBJZiB0aGUgcm91dGVyIHN0YXJ0cyBkb2luZyBPV0Ugd2l0aG91dCB0aGVpciBrbm93 bGVkZ2UsIHRoZXJlIHdpbGwgYmUgYSBncmVhdCBkZWFsIG9mIGNvbmZ1c2lvbiB3aGVuIGxlZ2Fj eSBVSSBzaG93cyB0aGUgbmV0d29yayBhcyBlbmNyeXB0ZWQgYW5kIHVzZXJzIGFza3MgdGhlIGJh cnRlbmRlciBmb3IgdGhlIHBhc3N3b3JkLg0KDQpTbyBsZXQncyBhc3N1bWUgdGhhdCBPV0UgaXMg ZXhwbGljaXRseSB0dXJuZWQgb24gYnkgdGhlIGFkbWluaXN0cmF0b3JzLiBUaGV5IHRha2UgdGhl IHBhaW4gdG8gYWN0aXZhdGUgdGhlIG9wdGlvbiBpbiB0aGUgVUkuIFdoeSBpcyBpdCBzaW1wbGVy IHRoYW4ganVzdCBzZXR0aW5nIGEgcGFzc3dvcmQ/IFRoZSBiYXJ0ZW5kZXIgd2lsbCBzdGlsbCBn ZXQgYXNrZWQgZm9yIHRoZSBwYXNzd29yZCBieSBhbGwgdGhlIGxlZ2FjeSBjdXN0b21lcnMsIGFu ZCBhdCB0aGF0IHBvaW50IGl0IGRvZXMgbm90IG1ha2UgYW55IGRpZmZlcmVuY2Ugd2hldGhlciBo ZSBoYXMgdG8gYW5zd2VyICJ1c2UgdGhlIG5hbWUgb2YgdGhlIG5ldHdvcmsiIG9yICJPcGVuIFNl c2FtZS4iDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0K From nobody Wed Aug 26 12:17: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 8A7C71A1BB4 for ; Wed, 26 Aug 2015 12:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 f0iMKyuLlsQc for ; Wed, 26 Aug 2015 12:17:42 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B3D011A1B18 for ; Wed, 26 Aug 2015 12:17:42 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 1D0901B406F for ; Wed, 26 Aug 2015 12:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=HJoy9jon2NZJPlJgCa9u 5mzc06s=; b=iyz5Ar7H3HYm2RU4C95NIqOFxVxmynTFqwcjTV/ZoStaUcjeqz6U XDguWy0sRKO1Eb/dWDl8rNX59JqnPDq+QDmkWALkD2VFze56rbrWG8yl/+otYz7o bEWfsTxDxTKp3Kg1cYnsdl38CcgUCcJ2eQRAwOgX4Brd+wgqpF0xkWc= Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com [209.85.160.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id EBA871B406B for ; Wed, 26 Aug 2015 12:17:41 -0700 (PDT) Received: by ykbi184 with SMTP id i184so197334080ykb.2 for ; Wed, 26 Aug 2015 12:17:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.44.23 with SMTP id 23mr58420ykm.52.1440616659893; Wed, 26 Aug 2015 12:17:39 -0700 (PDT) Received: by 10.129.109.88 with HTTP; Wed, 26 Aug 2015 12:17:39 -0700 (PDT) In-Reply-To: <55DD89F2.8050801@cs.tcd.ie> References: <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <20150826055240.GD13302@localhost> <55DD89F2.8050801@cs.tcd.ie> Date: Wed, 26 Aug 2015 14:17:39 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11378e8e45466d051e3bb4d0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 26 Aug 2015 19:17:43 -0000 --001a11378e8e45466d051e3bb4d0 Content-Type: text/plain; charset=UTF-8 On Wednesday, August 26, 2015, Stephen Farrell wrote: > > Hi Nico, > > On 26/08/15 06:52, Nico Williams wrote: > > > > I'm sorry but you're entirely ignoring the use of RC4 in the web Not at all. I'm arguing that rather than outright ban RC4 at the TLS layer for all apps we should make it a SHOULD NOT use with guidance for various applications. > Another of the lessons of OS (or rather, of more seriously considering > deployment realities) is that we sometimes need to think outside our > own silos. That goes for mail folks and web folks and others too. > (I'm not saying you're one or other of those, but your mail was very > silo-specific.) > Exactly. --001a11378e8e45466d051e3bb4d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, August 26, 2015, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Nico,

On 26/08/15 06:52, Nico Williams wrote:



I'm sorry but you're entirely ignoring the use of RC4 in the web

Not at all.=C2=A0 I'm arguing that rather= than outright ban RC4 at=C2=A0the TLS layer for all apps we should make it= a SHOULD NOT use with guidance for various applications.
=C2=A0<= /div>
Another of the lessons of OS (or rather, of more seriously considering
deployment realities) is that we sometimes need to think outside our
own silos. That goes for mail folks and web folks and others too.
(I'm not saying you're one or other of those, but your mail was ver= y
silo-specific.)

Exactly.=C2=A0
--001a11378e8e45466d051e3bb4d0-- From nobody Wed Aug 26 15:11:21 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 4F69F1B346B for ; Wed, 26 Aug 2015 15:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 nIlnxbcs6SEu for ; Wed, 26 Aug 2015 15:11:17 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B81B3469 for ; Wed, 26 Aug 2015 15:11:17 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3921C1022404A; Wed, 26 Aug 2015 15:11:17 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 26 Aug 2015 15:11:17 -0700 (PDT) Message-ID: <511ec4fef968dcf87bb42912360e37f1.squirrel@www.trepanning.net> In-Reply-To: References: Date: Wed, 26 Aug 2015 15:11:17 -0700 (PDT) From: "Dan Harkins" To: "Warren Kumari" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 26 Aug 2015 22:11:19 -0000 Hi Warren, On Wed, August 26, 2015 7:53 am, Warren Kumari wrote: > Hi there all, > > I'd appreciate it if folk could have a look at this draft and provide > any feedback. > I'm not sure that SAAG is the right place for it, but I couldn't think > of anywhere better. > > https://tools.ietf.org/html/draft-wkumari-owe-01 > > > Note that this is NOT intended to be the be all and end all of secure > wireless, it is simply intended to make open wifi suck somewhat less. > We are not claiming great security (the WPA2 4-way handshake > significantly limits what can be achieved), and so much of the draft / > idea is making sure that users do not get a false (or any) sense of > security - this should be transparent to them. It might suck less but it still kind of sucks. You could make it suck even less by using SAE (an 802.11 authentication protocol that uses a PAKE to establish pairwise keys). This would address the limitations you mention in your draft that have to do with WPA2-PSK. > We also want it to be *really* simple, so that commodity CPE vendors > will include "support" (basically a flag in the beacon) - this removes > other solutions like .1X, etc. Another option might be to define another vendor-specific Element to carry DH exponentials. Just tag one on the end of the first two messages of the 4-way handshake and have each side derive a "pairwise master key" (PMK, the thing used with the nonces in the 4-way handshake to derive the data encryption keys) from the DH shared secret. Instead of having everyone use the SSID as the password, just get rid of the password! regards, Dan. > Appreciate your time, > W > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Wed Aug 26 22:44: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 DC8B51A892E for ; Wed, 26 Aug 2015 22:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 CmQJ_1P1JZct for ; Wed, 26 Aug 2015 22:44:27 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCF51A00AC for ; Wed, 26 Aug 2015 22:44:27 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0D70C1022404A; Wed, 26 Aug 2015 22:44:27 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 26 Aug 2015 22:44:27 -0700 (PDT) Message-ID: <134476325d78817c83a7d94804c1faf0.squirrel@www.trepanning.net> In-Reply-To: References: Date: Wed, 26 Aug 2015 22:44:27 -0700 (PDT) From: "Dan Harkins" To: "Warren Kumari" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 27 Aug 2015 05:44:29 -0000 Hi Warren, One more thing... On Wed, August 26, 2015 7:53 am, Warren Kumari wrote: > Hi there all, > > I'd appreciate it if folk could have a look at this draft and provide > any feedback. > I'm not sure that SAAG is the right place for it, but I couldn't think > of anywhere better. > > https://tools.ietf.org/html/draft-wkumari-owe-01 > > > Note that this is NOT intended to be the be all and end all of secure > wireless, it is simply intended to make open wifi suck somewhat less. > We are not claiming great security (the WPA2 4-way handshake > significantly limits what can be achieved), and so much of the draft / > idea is making sure that users do not get a false (or any) sense of > security - this should be transparent to them. > > We also want it to be *really* simple, so that commodity CPE vendors > will include "support" (basically a flag in the beacon) - this removes > other solutions like .1X, etc. Typically, the AP advertises its security policy with an "RSN element" in its beacons and probe responses. This lists the unicast and broadcast ciphers it supports, the capabilities (current broadcast replay counter, whether an extended key ID is used, etc) and some other stuff. The client selects a complete subset and adds the "RSN element" when associating to indicate it is agreeing to do that particular set of policy and the AP acks it back in the associate response. The policy offer and selection are confirmed in the 4-way handshake to prevent downgrade attacks. If you're gonna make this look like an open network you're gonna have to somehow plumb this information into other components of the frames since the presence of an "RSN element" would mean the SSID is not open. You could include an "RSN element" in the OWE Vendor-Specific OWE Support Advertisement element you define but you're gonna need to somehow get the client to select a proper subset and the AP to ack it prior to beginning the 4-way handshake. You may want to add the OWE Support Advertisement (with the "RSN element" embedded in it) to associate requests and associate responses too. This is getting a bit ungainly. You might want to reconsider making it an open network. You could specify an encrypted network but use a Vendor-specific "AKM Suite" in the "RSN element" to indicate OWE. That way it won't show up on legacy clients as a network that needs a password. Legacy clients just won't know what the hell it is. This would allow you to keep the existing "RSN element" in the beacons, probe responses, associate request/responses, and 4-way handshake. Add on the Vendor-specific element to pass DH exponentials (what I suggested in my previous email) and do a DH in the 4-way handshake and I think you've got something workable. No password needed, resistant to passive attack, still susceptible to an active MiTH (which is problematic because it requires the MiTM to impersonate the AP while in range of it), better than WPA2-PSK, genuinely sucks less. regards, Dan. From nobody Thu Aug 27 06:35: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 34D971B3A8F for ; Thu, 27 Aug 2015 06:35:10 -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] 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 LhZxgbknzoSo for ; Thu, 27 Aug 2015 06:35:08 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CDE1B3A88 for ; Thu, 27 Aug 2015 06:35:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0F38FE2035; Thu, 27 Aug 2015 09:35:07 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 23151-10; Thu, 27 Aug 2015 09:35:05 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id D8141E2034; Thu, 27 Aug 2015 09:35:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1440682504; bh=C2wqTD0inMtchyX5oceB0SEz1haxEwPjxOKv5tVVJqc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=aQMdaihngEwlImcI/LdsVDclD/MvZF1+YuR+ws8o6zeZi/H3Lmgs4SLVLEX3VKhCs +dEnzsabiGHCmS2DPjkbWzf9Ll9r6+oR76STDr2K2ZN37MHkZwjW5IKRq7fuJEsAXe gfbcvVWnOips9oQ/xnUZzFJMfvkb6gyMr1TAMfjg= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t7RDZ4Vk019622; Thu, 27 Aug 2015 09:35:04 -0400 From: Derek Atkins To: Martin Thomson References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org> <7CEEF500-4530-4245-A3DC-C7D1ACB754B6@gmail.com> Date: Thu, 27 Aug 2015 09:35:04 -0400 In-Reply-To: (Martin Thomson's message of "Tue, 25 Aug 2015 11:13:44 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 27 Aug 2015 13:35:10 -0000 Martin Thomson writes: > Since Kathleen asks so nicely, I'd like to register my disagreement > with Victor on this point. > > There are compatibility reasons *today* that exist as a result of > having to interoperate with old software that was built or deployed > without due regard to security updates or continuous maintenance. > > However, if we expect software to be updated in order to get > opportunistic security, then I don't think it unreasonable to also > expect it to be maintained on an ongoing basis. A sudden once-off > isn't going to cut it if we want to prepare for the eventuality where > one of the current ciphers turns out to be irredeemably busted. > > If you accept that software that is updated once can be continuously > maintained thereafter, then it's not a stretch to conclude that > deploying good ciphers is equally feasible. I disagree. Most IT players I know set something up and basically don't touch it unless something breaks. They don't regularly update stuff unless they have to (and I'll hand-wave at what indicates they "have to" -- some people are definitely more proactive and a CVE might be enough to trigger the update). The fact that we're still seeing 12-year-old software in deployment (Exchange 2003) seems to back up my point that once stuff is deployed and "worked" it tends to be left alone. My personal feeling that "some" crypto is better than "no" crypto.... MOST of the time. I think all of us would argue that "rot13" is probably *not* better than no crypto. So where do we draw the line as to what's a step forward and what's a false sense of security? Do we draw the line at rot13? RC4-40? RC4-128? DES? 3DES? And once we agree that we need to have that line, does that line need to move over time? And how do we move that line? Is there some way we can pop errors up the stack in a way that the end users can be notified that something is wrong? Just returning a "45x Cipher Too Weak" SMTP error code isn't going to help, because I know of nobody that actively monitors those logs sufficiently to even NOTICE that they get that message. Often you'll only start to check the logs once you notice mail isn't flowing at all, and even then you'll only really know for outbound email, not inbound email! -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Aug 27 11:53:03 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 0B9261B2F82 for ; Thu, 27 Aug 2015 11:53:03 -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 1EAcoLp6S_Ar for ; Thu, 27 Aug 2015 11:53:02 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 20E951B2F7F for ; Thu, 27 Aug 2015 11:53:02 -0700 (PDT) Received: by ykfw73 with SMTP id w73so30164034ykf.3 for ; Thu, 27 Aug 2015 11:53:01 -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=rE65aNCF8lxWEkF5AafJKieYqzEhUC3mfUBO29k0RC8=; b=MIc0+np1i7zfDqxYx9lRN7xOayFvBdovOViLR8QVuZD/ZdgcxwlKrHaQ4mzLCx2QHQ Yhy+jjnA5A0uBYNQvfG5lEawnxgIvwlPULZ1WbkmpoiZBqa0nHqjPo8ccKnDm/WzzI9H lGXeIDAkqwnsUX6QvM7HqMGTXH+PPfJqBb/c6V1uXEGpVHzof0tgsdNAVAOHG4LATyGX h3G5pWIS3AJ1Cyw+yOTbAFLvyWZNe1UIeyPPuuElT5CIhVYsrobImZXQAuZR2/0zOnu2 Rr0PcHD2CS1n3XqIcW4u9D0k8QtOoM7SaXyrr2LVxBk8REFiBjwNLQtD/z0B2LpgtJpJ rHeg== MIME-Version: 1.0 X-Received: by 10.170.165.193 with SMTP id h184mr4850396ykd.1.1440701581585; Thu, 27 Aug 2015 11:53:01 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Thu, 27 Aug 2015 11:53:01 -0700 (PDT) In-Reply-To: References: <20150728013020.GO4347@mournblade.imrryr.org> <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org> <7CEEF500-4530-4245-A3DC-C7D1ACB754B6@gmail.com> Date: Thu, 27 Aug 2015 11:53:01 -0700 Message-ID: From: Martin Thomson To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 27 Aug 2015 18:53:03 -0000 On 27 August 2015 at 06:35, Derek Atkins wrote: > Most IT players I know set something up and basically don't > touch it unless something breaks. That is what needs to change. I'm seeing evidence that it is changing. From nobody Thu Aug 27 13:37: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 170F51A6EFB for ; Thu, 27 Aug 2015 13:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfrQ9NzuZsXY for ; Thu, 27 Aug 2015 13:37:20 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FBC1A1BEC for ; Thu, 27 Aug 2015 13:37:19 -0700 (PDT) Received: by wicne3 with SMTP id ne3so3219442wic.0 for ; Thu, 27 Aug 2015 13:37:18 -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=7Bh2D71d8AjdQZatoe+8HEbGe3KJAh9OB7hblbkK5ms=; b=t4PhkEex6cGMOA9tgF5iCdZZdiX6guvTamvNR0/qZ/g/Vtf3UYz85e9R9Cdq+c3N4P nJs7uf1KSC6T4nXAD5Q2cSLOdU78/jJTy9O6lG2g4e4XLAjPXjCA0HIrhPpblidJGUWh P1cTp5xy7Zg3LqvN1pt0yFLg8R8Jko98A5DafX7o8cLDsyFEo8zGL4YTWqFUBJiN/t5a Xu4AOAmYDp723hHyGD7TA4Gwl+c7N0twu8r0UZTUjmqKeyYS9MwbiOGDO3EcSOc0EZfo tV9cu4iLtvwegR1yBgva2YuyvbUQaOVNI+ffF5AspTUYLpKnah07jNkqrSiLUKl19YiK lpUw== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr497549wij.30.1440707838497; Thu, 27 Aug 2015 13:37:18 -0700 (PDT) Received: by 10.28.132.11 with HTTP; Thu, 27 Aug 2015 13:37:18 -0700 (PDT) In-Reply-To: <55DD89F2.8050801@cs.tcd.ie> References: <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <20150826055240.GD13302@localhost> <55DD89F2.8050801@cs.tcd.ie> Date: Thu, 27 Aug 2015 16:37:18 -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 review of draft-iab-crypto-alg-agility-06 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, 27 Aug 2015 20:37:22 -0000 On Wed, Aug 26, 2015 at 2:42 AM, Stephen Farrell wrote: > > Hi Nico, > > On 26/08/15 06:52, Nico Williams wrote: > >> We know RC4 is weak and we want to use something else that's better >> instead. Clearly, we can ban RC4, but that isn't a magic wand that >> makes everyone start using AES or what have you. Still, we plow on >> because hey, some TLS implementors will understand the SMTP OS situation >> and won't break that application. But! if we merrily write text telling >> TLS implementors to remove RC4, many of them will, and in the process >> they will make security/interop for SMTP demonstrably worse (as Viktor >> has shown). >> >> It seems we can't be moderate in how we approach cipher obsolescence, >> perhaps because... we're embarrassed to have obsolete ciphers around so >> long after they became obsolete? That's not a good excuse for throwing >> a big switch. A good excuse for throwing the switch is any case where >> merely offering weak crypto introduces a downgrade attack, but that's >> not the case here. >> >> "Look ma'!, we banned the bad thing" is clever marketing. For a short >> while. "Look ma'!, we're getting off the old thing and onto the new, >> and we're giving people time so we don't make things worst in the >> short-term" is a mouthful and ma' will have to think about it before >> deciding that we're doing the right thing, but it is the right thing. >> >> We totally can live with an outright ban on RC4. That not all TLS >> implementors will adhere to. Or accept the loss of security/interop for >> SMTP. If implementors willfully diverge from the spec, then the spec is >> probably wrong. If implementors faithfully implement a spec, and as a >> result applications break, the spec is probably wrong. The only hope >> for an outright ban is that breakage causes people to go fix it. But >> with SMTP OS it's not always clear to users that there's breakage, and >> when it is clear (mail won't flow) it isn't always easy to go fix it. > > I'm sorry but you're entirely ignoring the use of RC4 in the web > which was a very important part of this. While there may be a rump > of smtp servers that are broken and that won't upgrade soon, there > was a very large proportion of the web using RC4 before we deprecated > it, and now there is far less, with no breakage. (See Richard's > presentation at saag in Prague.) That change wasn't caused by us, but > we did the right thing to help it along with RFC7465. Did we actually disable RC4 across the web? A closer investigation reveals all the attacks will still work after the latest round of browser changes: one just needs to forge a single packet to break the first connection, until the browser incorrectly learns RC4 intolerance. Claims that only a small fraction of connections are using RC4 miss the mark: the question is how many connections can be fooled into using RC4. At what point can we remove the code from OpenSSL? That's the endpoint we should be aiming for. > > Another of the lessons of OS (or rather, of more seriously considering > deployment realities) is that we sometimes need to think outside our > own silos. That goes for mail folks and web folks and others too. > (I'm not saying you're one or other of those, but your mail was very > silo-specific.) > > S. > > >> >> Nico >> > > _______________________________________________ > 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 Thu Aug 27 13:50:03 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 1B8071ACCF4 for ; Thu, 27 Aug 2015 13:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbM_2bxxUkK8 for ; Thu, 27 Aug 2015 13:50:00 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571361ACCE3 for ; Thu, 27 Aug 2015 13:50:00 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 78563284D2B; Thu, 27 Aug 2015 20:49:59 +0000 (UTC) Date: Thu, 27 Aug 2015 20:49:59 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20150827204959.GZ9021@mournblade.imrryr.org> References: <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <20150826055240.GD13302@localhost> <55DD89F2.8050801@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:50:02 -0000 On Thu, Aug 27, 2015 at 04:37:18PM -0400, Watson Ladd wrote: > At what point can we remove the code from OpenSSL? That's the endpoint > we should be aiming for. Code removal is I think at more than 2 years away. Removal from the DEFAULT cipherlist is already staged in the "master" branch (upcoming 1.1.0 release in 2016). Between that and removal of the code, is making it a non-default compile-time option (along with single-DES). -- Viktor. From nobody Thu Aug 27 13:50:51 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 9C71A1ACCE3 for ; Thu, 27 Aug 2015 13:50:50 -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 4T2ujxE0rZRv for ; Thu, 27 Aug 2015 13:50:49 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 4EB7C1A039A for ; Thu, 27 Aug 2015 13:50:49 -0700 (PDT) Received: by ykdt205 with SMTP id t205so33951947ykd.1 for ; Thu, 27 Aug 2015 13:50:48 -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=5LuTf+yLQBGXQwNdixf8No0RsytGCYDqK7VBUoaX8Dc=; b=W08ZK7Zu6ZM2fifXLOVtKGIb2B7V69/QBLLfSMVIV/15o+IXliKEvrXTr+OQRB5R44 qzRn5AAC8kmFG78TVRFoZ7yWioH1hznZ44ZCzzcD4B1Y1RXhXTadL+gfChOx1+xeyZzD j+RzEE/CRhPA3cMPG8IJimkgTl95ovpJ+4L1m5XWNNy4EzzFSPntD8BttlSlYg/p4Lgd ZwgWQzPbIMQlYh/0Wn5tqYhxLfdPJvjOjB2nZlxUy6vMoRMmIR0aYkBYAPH+fJQCmELz wBlC8VENzoj41SvyJ78SNLNBsaFVJJlUAGWRllURamOV5WS5ypM/fHBXBqeGq5kgAXCD hsHA== MIME-Version: 1.0 X-Received: by 10.13.234.138 with SMTP id t132mr5488801ywe.89.1440708648736; Thu, 27 Aug 2015 13:50:48 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Thu, 27 Aug 2015 13:50:48 -0700 (PDT) In-Reply-To: References: <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <20150826055240.GD13302@localhost> <55DD89F2.8050801@cs.tcd.ie> Date: Thu, 27 Aug 2015 13:50:48 -0700 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 27 Aug 2015 20:50:50 -0000 On 27 August 2015 at 13:37, Watson Ladd wrote: > At what point can we remove the code from OpenSSL? That's the endpoint > we should be aiming for. I expect this to progress roughly as follows (for Firefox, and in general): 1. announcement 2. disable, maybe with a way to manually override 3. disable with no override 4. disable this on the last of the servers 5. remove from the library You are asking about step 5, which is important, but some of the intermediate steps have a non-trivial benefit too. The reason for step 4 is a little ugly. We run openssl on our download servers. We want to offer Firefox downloads to users who have old and busted browsers. That means we need to be a little more promiscuous on those servers than we might otherwise want to be. That means that we also don't do anything much of importance on those same servers. We want security updates too, so we want new versions of openssl that will support us. That means that openssl will likely support old and crufty stuff for longer than you might think. We still haven't disabled SSLv2 in NSS, but that's laziness. The reason will still have SSLv3 in NSS is in part due to step 4. From nobody Thu Aug 27 14:01: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 25DB41B29F6 for ; Thu, 27 Aug 2015 14:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 gRExYdbLIrs6 for ; Thu, 27 Aug 2015 14:01:55 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (unknown [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id CB4601B29F4 for ; Thu, 27 Aug 2015 14:01:55 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BDB4D4BBEA; Thu, 27 Aug 2015 21:01:54 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id A7AA149EE7; Thu, 27 Aug 2015 21:01:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1440709314; bh=x93OllqbK1eUhHC+RhG3T01LIi0YMgGkJCs31dWA7Kc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=X1CBxPEUw60mb6Gj8SmxA5BrwZfnbEXSBPYU23bsNM5W+d4HaABf1B+eN+SS1dPiU zmMiKki+cicoOKNaQ+eV+Biz/v9PLpEcH0qkVQLYDwiO9KaLaqUbIx3cB9B+wsQWqP xMf9x9qptTDYo3mNJk5RX740tIY6zcfRVcpsxwuM= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 8E9BA2036; Thu, 27 Aug 2015 21:01:54 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 27 Aug 2015 16:01:52 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Thu, 27 Aug 2015 16:01:52 -0500 From: "Salz, Rich" To: Martin Thomson , Watson Ladd Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06 Thread-Index: AQHQ3qvj021A7RxjOEahYRWcAOaGUp4b/kqA//+syqCAAFk4gIAAoQGAgABpPoD//8v60IAAW/QAgAAERgCAAOKSgIAAQB0AgAJJYACAAAPGAP//rovA Date: Thu, 27 Aug 2015 21:01:51 +0000 Message-ID: References: <20150728053035.GR4347@mournblade.imrryr.org> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <55DC961A.903@cs.tcd.ie> <20150826055240.GD13302@localhost> <55DD89F2.8050801@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06 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, 27 Aug 2015 21:01:57 -0000 > The reason for step 4 is a little ugly. We run openssl on our download > servers. We want to offer Firefox downloads to users who have old and > busted browsers. We have a similar issue at www.openssl.org. I recently locked things down = to get an A+ from SSLLabs. This meant some folks had a harder time getting= updates. I pointed them to the FTP server. And old, LTS python, doesn't = do TLS very well. I don't recall what they're going to do. From nobody Thu Aug 27 16:49:26 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 661BB1B3160 for ; Thu, 27 Aug 2015 16:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 strAclKD1tuo for ; Thu, 27 Aug 2015 16:49:22 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809391B3148 for ; Thu, 27 Aug 2015 16:49:22 -0700 (PDT) Received: by obkg7 with SMTP id g7so29761705obk.3 for ; Thu, 27 Aug 2015 16:49:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Sxm7AS3x7293wzGFX5GGGA8ppa87p/7QVhaNU3c2uaE=; b=kUh5ZrPXDPZ4d3WW9eKmeX9U+mb4RZ7+SS0NXCf4jf6HB1UqJTJo29v8yMFJrr6/E8 wcaEFMGvoHPp3CPF+26FEaeL9EsigC1pe8Au7gg0eVwd4fEtKTZCDazaFIzNx4ux5Qjo FTIWzMdxHZV4vmn1MhbMEl7aaReOPDiFLgx2OMYVKfrs5AiXTvsHzHmsKYGqHXKcsT8D mKccJ48Nb/2+hJEAZSM64i2y0hU6ssIZM469ZaGVctAr2wTP+8ZNE6kOSKoukP86FQIp ITJAUqnVC2MseHQB+uB0AoJAbdp4WIVBV2ZzLiCuAgH/dwJd8jOEuUdD4oqoyIq4Flvw YbrQ== X-Gm-Message-State: ALoCoQlBeGAkcdCkD80MPLGlYmyMLcZShkkb30CBaCFA1strFRxdtOx/AhdzhJHuLabwj2+OQBIP MIME-Version: 1.0 X-Received: by 10.182.158.72 with SMTP id ws8mr4033410obb.54.1440719361767; Thu, 27 Aug 2015 16:49:21 -0700 (PDT) Received: by 10.202.174.144 with HTTP; Thu, 27 Aug 2015 16:49:21 -0700 (PDT) In-Reply-To: References: <20150826170138.GB9021@mournblade.imrryr.org> Date: Thu, 27 Aug 2015 19:49:21 -0400 Message-ID: From: Warren Kumari To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 27 Aug 2015 23:49:24 -0000 On Wed, Aug 26, 2015 at 2:51 PM, Christian Huitema wrote: > On Wednesday, August 26, 2015 10:36 AM, Warren Kumari wrote: >> >> On Wednesday, August 26, 2015, Viktor Dukhovni = wrote: >>> ... This is considerably weaker >>> than many other opportunistic security protocols. With no protection >>> against a passive adversary who started monitoring before the victim >>> joins the network, is this still worth doing? >> >> I believe that it is -- I think that the cost to implement this is reall= y really low (I added PoC >> "support" to OpenWRT in less than an hour, and almost all of that was fi= nding a >> suitable access point in my basement :-)). >> >> I fully acknowledge that this doesn't solve all issues, and doesn't clai= m to - but I think that for >> the negligible cost, the incremental security win is worth it. > > You have to decide who you are optimizing for. The administrators would c= annot be bothered to set a password for the Wi-Fi? If the router starts doi= ng OWE without their knowledge, there will be a great deal of confusion whe= n legacy UI shows the network as encrypted and users asks the bartender for= the password. > > So let's assume that OWE is explicitly turned on by the administrators. T= hey take the pain to activate the option in the UI. Yup -- the expectation is that my e.g Netgear 42Foo will have 3 radio butto= ns: [ ] WPA2-PSK (Enter password here ________) [X] OWE: A slightly less insecure, but still open network. [ ] Open: No encryption. > Why is it simpler than just setting a password? The bartender will still = get asked for the password by all the legacy customers, and at that point i= t does not make any difference whether he has to answer "use the name of th= e network" or "Open Sesame." This issue for many places is that they specifically do not *want* a password, not that they simply cannot be bothered to set a password -- for example, in the Prague Hilton lobby there was a network ("Hilton-guest" or "Hilton-lobby" or something like that). It was intentionally unsecured, so that people didn't have to go along, stand in the long line for registration and then be told "Oh, yeah, the password is Password"". You are right that there will be some initial legacy issues -- but if we can convince Windows 10 Mobile, Apple iOS, and Android willing to include support (which seems likely, "support" is trivial - basically 1: try the SSID as the passphrase and 2: don't bother showing a lock icon) we could get the *huge* majority of devices doing this before the document is published, and way before CPE starts including the button. Even for devices that don't get support added -- after I've asked at 3 coffeeshops what the password is, and they all say "It's the same as the network name..." I'm likely to start trying the network name if the SSID name sounds like it may be open (e.g is the name of the establishment, contains -guest, -public, or better yet, -owe). > > -- Christian Huitema > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Aug 27 17:12: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 30DBB1B2BFC for ; Thu, 27 Aug 2015 17:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 dtkDkwnH5MWu for ; Thu, 27 Aug 2015 17:12:28 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (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 58C9B1B3272 for ; Thu, 27 Aug 2015 17:09:52 -0700 (PDT) Received: by obkg7 with SMTP id g7so30059596obk.3 for ; Thu, 27 Aug 2015 17:09:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dsktGlcg4AgP2MzHP4+Rn7TIKGNVGaiHvoOyd+R590Q=; b=J0E7dShHF4bWkN+FVsFZibxGMlds97233J/iXONt+CMLRRLKBvm8dsQDFbuUQjHCFx vrOoSCi9MknlFkRDphQInd+YZZt5rC29RujMIvf69wzVbEcTZHljr2rz0MzzzIjWuhye M+ky+yHmq/cY4cKKSm7lXXTKhrxwx2WOUyUfwmVXUBgg62xbX7MKG0AI7h6+0tK3Qvtf OkNhLlX4y9atMsmE6GiYLJJeEWqblUiOIXd6e7GQgSWBAeTFB1BAOpAunRSZj/1FcJt+ WbmBn2aSn0ZRsz7G4QQDlg+u38VKG5tPd5XqJ8aF0IYfbkKiGlB75m5+ApINy4BPD0Q7 lsvQ== X-Gm-Message-State: ALoCoQlQszAg1gyAtpaWFU55Wa+X9QGGPl6euMu34TX4Wm36PkOPk9T2HQ9olBEvH1/OdRZi7+0R MIME-Version: 1.0 X-Received: by 10.182.68.68 with SMTP id u4mr4472110obt.86.1440720591852; Thu, 27 Aug 2015 17:09:51 -0700 (PDT) Received: by 10.202.174.144 with HTTP; Thu, 27 Aug 2015 17:09:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Aug 2015 20:09:51 -0400 Message-ID: From: Warren Kumari To: "Henry B (Hank) Hotz, CISSP" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 28 Aug 2015 00:12:30 -0000 On Wed, Aug 26, 2015 at 2:30 PM, Henry B (Hank) Hotz, CISSP wrote: > >> On Aug 26, 2015, at 7:53 AM, Warren Kumari wrote: >> >> I'd appreciate it if folk could have a look at this draft and provide >> any feedback. > > I agree with the argument that the minimal effort makes it worth doing. > > OTOH, I also agree that something you can=E2=80=99t break passively would= be better. How about a connection that=E2=80=99s negotiated with D-H key e= xchange, but you never verify identities? (Hmmm, is there an EAP mech that = would effectively do that?) > > How hard will it be to get AP makers to adopt whatever is proposed? Is th= e additional difficulty of DH really a dealbreaker? Unfortunately I believe that it probably is a deal breaker, or, at least, would take so much time that it wouldn't be worth doing. I believe that the right place to do this sort of work (adding public key agreement) is in the IEEE, probably in the 802.11 group. I am not participating in the IEEE at the moment, but am beginning to wonder if I should participate and see if a public key agreement can be added to WPA. Adhoc / mesh networks already have a solution to this ("Simultaneous Authentication of Equals" (SAE - 802.1s)). I'm guessing that there is a good reason that is isn't also in normal wifi; I believe that Dan Harkins was deeply involved in the development of SAE - perhaps he can shed some light on this? W > > Personal: hbhotz@oxy.edu > Business: hhotz@securechannels.com > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Aug 27 17:35: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 BDC341B3052 for ; Thu, 27 Aug 2015 17:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 ro0FF4dZhGLD for ; Thu, 27 Aug 2015 17:35:21 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (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 D3B281B304F for ; Thu, 27 Aug 2015 17:35:21 -0700 (PDT) Received: by obbfr1 with SMTP id fr1so32949511obb.1 for ; Thu, 27 Aug 2015 17:35:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AWrXxUWZch+UjxL8aYoMz4dpGtkwA1oMLfEwnUYl4nU=; b=AvnwCLpnU/fVxn6qtQ51fbNMIy5vPONCHXln6p6ovZl1MoB9kP92a2gexXZbMrLMGz 8Zu+FjIsw9FOgqpa7rpcanjBVM4TMMQhw5jVmw2JPlCDewDBWjblWWIufQuzTyxRzhNk zgPKCMM9nLvzB2cmJzIuHA2oXhcAw1Yo8Sw7GqQE/IR95tUsB5mIFdISqd8Da0Rb9cjG f7Sh/Wcpl6rc9Sy6k+JLlMTRO08yHG7/gZVa6doX950QdreJ5iKFboABYAdzob14B9bt I75QO2/rRuI61lEkksNURW77R+8C5DhRaJSPu/J/gBW4cDkU80yLNrQK3c0Y8NR56Am4 s0oQ== X-Gm-Message-State: ALoCoQk70fXplcQBZ8vTYv/ssxtAGF+TPaljnIgv23xnOmT1bENDycuOySODLez0+/qa9cgWFlP6 MIME-Version: 1.0 X-Received: by 10.182.120.100 with SMTP id lb4mr4176696obb.71.1440722121150; Thu, 27 Aug 2015 17:35:21 -0700 (PDT) Received: by 10.202.174.144 with HTTP; Thu, 27 Aug 2015 17:35:21 -0700 (PDT) In-Reply-To: <511ec4fef968dcf87bb42912360e37f1.squirrel@www.trepanning.net> References: <511ec4fef968dcf87bb42912360e37f1.squirrel@www.trepanning.net> Date: Thu, 27 Aug 2015 20:35:21 -0400 Message-ID: From: Warren Kumari To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 28 Aug 2015 00:35:23 -0000 On Wed, Aug 26, 2015 at 6:11 PM, Dan Harkins wrote: > > Hi Warren, > > On Wed, August 26, 2015 7:53 am, Warren Kumari wrote: >> Hi there all, >> >> I'd appreciate it if folk could have a look at this draft and provide >> any feedback. >> I'm not sure that SAAG is the right place for it, but I couldn't think >> of anywhere better. >> >> https://tools.ietf.org/html/draft-wkumari-owe-01 >> >> >> Note that this is NOT intended to be the be all and end all of secure >> wireless, it is simply intended to make open wifi suck somewhat less. >> We are not claiming great security (the WPA2 4-way handshake >> significantly limits what can be achieved), and so much of the draft / >> idea is making sure that users do not get a false (or any) sense of >> security - this should be transparent to them. > > It might suck less but it still kind of sucks. You could make it > suck even less by using SAE (an 802.11 authentication protocol that > uses a PAKE to establish pairwise keys). Hah, this will teach me to read all the mail in a thread before replying -- I just posted something mentioning you and SAE. :-) Does SAE work with access points or is it only defined for ad hoc / mech networks? And if it is defined for APs, does current consumer CPE (dlink, linksys, netgear, etc) support it? I'd really like this to be a trivial thing for both APs and clients to include support for, and would much rather have a crappy but better than plaintext solution now instead of a great solution many years in the future. I'd like to see *something* deployed, and then we can work on improving it as time goes by... The current document has a Sub-type field ("Sub-type identifies the version of the OWE protocol. Currently only 0 is defined." ) - my cunning plan was to use that (if needed) to eventually signal that the underlying network supports something better than the current 4WHS -- although I'm guessing clients would be able to figure that out from other information advertised by the AP. > This would address the > limitations you mention in your draft that have to do with WPA2-PSK. > >> We also want it to be *really* simple, so that commodity CPE vendors >> will include "support" (basically a flag in the beacon) - this removes >> other solutions like .1X, etc. > > Another option might be to define another vendor-specific Element > to carry DH exponentials. Just tag one on the end of the first two > messages of the 4-way handshake and have each side derive a "pairwise > master key" (PMK, the thing used with the nonces in the 4-way handshake > to derive the data encryption keys) from the DH shared secret. Instead > of having everyone use the SSID as the password, just get rid of the > password! This is probably worth discussing more, but this also feels more like a larger scale change, and, while worth doing, I think it would be better done in parallel... Thank you, W > > regards, > > Dan. > >> Appreciate your time, >> W >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Aug 28 02:24: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 5549C1B386E for ; Fri, 28 Aug 2015 02:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 mOo-VHZr4ff7 for ; Fri, 28 Aug 2015 02:24:50 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 9C81D1B3855 for ; Fri, 28 Aug 2015 02:24:49 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2DBA843A65 for ; Fri, 28 Aug 2015 11:24:48 +0200 (CEST) To: saag@ietf.org References: <20150826170138.GB9021@mournblade.imrryr.org> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <55E028E0.6080803@restena.lu> Date: Fri, 28 Aug 2015 11:24:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5VMnuHXNJ4qcChpRJo0PqrkBiBWg31PPK" Archived-At: Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 28 Aug 2015 09:24:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5VMnuHXNJ4qcChpRJo0PqrkBiBWg31PPK Content-Type: multipart/mixed; boundary="------------080503050702060402010006" This is a multi-part message in MIME format. --------------080503050702060402010006 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > You are right that there will be some initial legacy issues -- but if > we can convince Windows 10 Mobile, Apple iOS, and Android willing to > include support (which seems likely, "support" is trivial - basically > 1: try the SSID as the passphrase and 2: don't bother showing a lock > icon) Or, for wireless sniffing kit of your choice: 1) try to decrypt with the SSID as the password 2) win! Seriously, this way of encrypting traffic stops only one attacker group: people with a Wi-Fi card in promiscuous mode who use Wireshark to look at packets ("us" :-) ). Everyone with only a /slightly/ serious attitude just continues to do what they do with their upgraded sniffing gear. I don't see how this improves security in a significant enough way. And the cost for it *is* high - convince all OS manufacturers to do something && convince AP admins to do something. > we could get the *huge* majority of devices doing this before > the document is published, and way before CPE starts including the > button. > Even for devices that don't get support added -- after I've asked at 3 > coffeeshops what the password is, and they all say "It's the same as > the network name..." I'm likely to start trying the network name if > the SSID name sounds like it may be open (e.g is the name of the > establishment, contains -guest, -public, or better yet, -owe). Funny: right now, an attacker would need to go to the shop to get that same information. In your future deployment, the binding of SSID to passphrase comes automatically. (Besides, my guess is that sniffing gear today probably tries the SSID as a passphrase anyway - simply because it is rather common). So, what exactly are we winning with this approach? Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------080503050702060402010006 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------080503050702060402010006-- --5VMnuHXNJ4qcChpRJo0PqrkBiBWg31PPK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJV4CjgAAoJEMDeajWKOdxmQGEP/3qNpFr/O5CtCdMTHSxpTsdy 4G8oTPIRFHLIzH43iYlzkoxyowcBB48E5BSi+coX7zL3xR1v2KTFFPQchpoR06wD pUMVQUEYsrpbfGpFds/AQK4/s+osIu56Kch4AyoXBtdXix6bB6IY3zYkMasWkdGE kHYR5k6gDLuSxhVrD52KSb7RsHGbw1J0SZ+uBfJMG/1l+sc4VbHuusub+TbeqseZ 6RfFyBjLKgmu3/yYp4o6NIm80BT7irZqEs8J8Dm9/OXwE2UVopSCqhTvhOL4g4lo 0lbUGVABdHj/7Jj7NuyyTuMg8uXN5GPHkAt1lpHggl9b0hb2aWvnSdU9NDVBnegR SEgMaLPEKiOXuf2Svz7ElfaxhGs+pl9NgIqSjMnICw3tNjuViLx+GPXpOt6yJcaL PSJCr3/SCQwAKBetvwFdbgziArvv5HnIdD3BDAs4ES+dOtwbFxNa+ZKtbNXUlL/O DBlUra9/Pnps0i3/xzJQR9csbzAR13KZD44zLXDNt155nm7jCzTMCLswsj4dYVk0 66SKip3FeZCQRE3ctxid0D34occHfZtNmYoKvUs+lZ7OY7txCCovPiNqnTckIsKU CIpb8shVQgLFfQEngYwV0USIYqf7TTo64jAZWnStUIqXFHSb13rBTojLXtfNrhy1 gUK0ulKm5Cvv9t+9Xtif =nQtZ -----END PGP SIGNATURE----- --5VMnuHXNJ4qcChpRJo0PqrkBiBWg31PPK-- From nobody Fri Aug 28 12:13:54 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 517A71A8928 for ; Fri, 28 Aug 2015 12:13:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvZosAxf8jBv for ; Fri, 28 Aug 2015 12:13:51 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CFB1A8863 for ; Fri, 28 Aug 2015 12:13:51 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.256.15; Fri, 28 Aug 2015 19:13:49 +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.0256.013; Fri, 28 Aug 2015 19:13:49 +0000 From: Christian Huitema To: Stefan Winter , "saag@ietf.org" Thread-Topic: [saag] Would love some feedback on Opportunistic Wireless Encryption Thread-Index: AQHQ4SMAZFCDPTU0j0ar6+bHp05ul54hJH4AgACfYCA= Date: Fri, 28 Aug 2015 19:13:49 +0000 Message-ID: References: <20150826170138.GB9021@mournblade.imrryr.org> <55E028E0.6080803@restena.lu> In-Reply-To: <55E028E0.6080803@restena.lu> 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.174.23] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:J7R/SF2kSpxGFdAA4YM8N+g83zrezoMdmYN24qWqAU27kWM4aWZQF8xpP7Mfqr7ZuPjyFuGncJm3iVmxkO7Mg1JG544CR2IaMXfWvx9Gb1hJEjjihZhNmb8MmHO5EPz5PNpL+ZVvJmFljWJpGwBTGg==; 24:En5zqBwu9jP+1IYQtzf/M2ITRVHN7G0apYwYuCtxMGUL7COh72mTE61Q6iwX70zS7SqwEUn9DOH0rOhHaXeWby5AHDwA1j4+XfBCfSRDz7o=; 20:4KtKfQws096zlrW7UDomC3IIKk03oi3VxzDyhvoiFZrJhKDXpA5ULSBQWO2Y6CxoK8tH1krtI1u1X6kXi4qLjw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; 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)(8121501046)(5005006)(3002001); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0682FC00E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(15594002)(377454003)(189002)(24454002)(5001830100001)(74316001)(77156002)(50986999)(189998001)(77096005)(5001860100001)(107886002)(64706001)(2501003)(19580395003)(19580405001)(5001770100001)(87936001)(62966003)(2900100001)(2950100001)(54356999)(8990500004)(101416001)(81156007)(97736004)(4001540100001)(76176999)(92566002)(66066001)(86612001)(76576001)(10290500002)(5001960100002)(2656002)(86362001)(10400500002)(5003600100002)(10090500001)(105586002)(5005710100001)(5007970100001)(5002640100001)(5004730100002)(40100003)(122556002)(106356001)(99286002)(102836002)(33656002)(93886004)(106116001)(68736005)(551544002)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM 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: 28 Aug 2015 19:13:49.5544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 28 Aug 2015 19:13:53 -0000 On Friday, August 28, 2015 2:25 AM, Stefan Winter wrote: > To: saag@ietf.org > Subject: Re: [saag] Would love some feedback on Opportunistic Wireless > Encryption >=20 > Hi, >=20 > > You are right that there will be some initial legacy issues -- but if > > we can convince Windows 10 Mobile, Apple iOS, and Android willing to > > include support (which seems likely, "support" is trivial - basically > > 1: try the SSID as the passphrase and 2: don't bother showing a lock > > icon) >=20 > Or, for wireless sniffing kit of your choice: >=20 > 1) try to decrypt with the SSID as the password > 2) win! It is a bit more complicated than that, but not much. With WPA2, the traffi= c is not directly encrypted with the password, but instead with a key deriv= ed from the password, the SSID, an Access Point nonce, and a Station nonce.= Even if the password is shared, each client uses a different set of nonce,= and thus a different key. However, the nonce are transmitted in clear-text= during the initial exchange. That means the attack goes as: 1) Capture the initial exchange between Station and Access point, and remem= ber the nonce. 2) Assume that the SSID is the password and try to derive the per station k= ey using the nonce. 3) Win! This is in fact the main limitation to Warren's approach. The proposed OWE = system will still be vulnerable to passive listener attacks, and is thus no= t much of an improvement over open networks.=20 Note that this is also a limitation of the "public password" approach, as i= n "ask the password to the bartender." We can hypothesize that mass surveil= lance systems will quickly build a database linking networks, SSID and publ= ic passwords. After all, the initial WPA2 exchange carries authentication c= odes that are the hash of the nonce and the password, which trivially enabl= es dictionary attacks. That means the procedure will be: 1) Capture the initial exchange between Station and Access point, and remem= ber the nonce. 2) Retrieve the password associated to the SSID from the database. 3) Derive the per station key using the nonce. 4) Win! Thinks would be different if instead of just sending the nonce in clear tex= t the WPA2 exchange used some variation of Diffie-Hellman or EKE. Attackers= would need to move from "passive listening" to "actively implement MITM at= tack," and we believe that might curtail mass surveillance efforts. But tha= t's not the case. -- Christian Huitema From nobody Fri Aug 28 15:11:24 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 D62351B34AE for ; Fri, 28 Aug 2015 15:11:22 -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 0N0sANvngEXN for ; Fri, 28 Aug 2015 15:11:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D199E1B3496 for ; Fri, 28 Aug 2015 15:11:20 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.256.15; Fri, 28 Aug 2015 22:11:18 +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.0256.013; Fri, 28 Aug 2015 22:11:17 +0000 From: Christian Huitema To: Warren Kumari , "saag@ietf.org" Thread-Topic: [saag] Would love some feedback on Opportunistic Wireless Encryption Thread-Index: AQHQ4SMAZFCDPTU0j0ar6+bHp05ul54hJH4AgACfYCCAADKTQA== Date: Fri, 28 Aug 2015 22:11:17 +0000 Message-ID: References: <20150826170138.GB9021@mournblade.imrryr.org> <55E028E0.6080803@restena.lu> In-Reply-To: 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.174.23] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:X1HuHQD1RVeMAFpiFQh9TpntabyAiKbsswTu82yZt2B3/gWolejBoBDuVDe58nOvUoKAJ39rhbL+8eLTwck48LyAcVnAzkVTefCZpOLuyxorA/+OQitSGwyRLbFasa9wNjhRgCCQzFgyCdoSGCyzyg==; 24:13xmMc+dAI6n6ZotAPpF25WOjG/GsBXBi6T8w973XQWkkEByiuC/WCRWx1R/+A1azPEQhoZhdMm+kkeFIdE6CBjKwA+YxIiRyoEK4naEv00=; 20:EMBH0fb0Sunk2QaXSvO4HrAzUE7EVuuDnSxY9wnfIZy5s/WcMWIYTel+jUVL7DxrY3YN+HDJE6pJdE/vICTqqw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; 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)(8121501046)(3002001); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0682FC00E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(15594002)(377454003)(189002)(24454002)(74316001)(5001830100001)(50986999)(77156002)(77096005)(189998001)(5001860100001)(62966003)(64706001)(107886002)(2501003)(5001770100001)(87936001)(2900100001)(8990500004)(54356999)(2950100001)(97736004)(81156007)(76176999)(4001540100001)(101416001)(92566002)(66066001)(86612001)(10290500002)(76576001)(5001960100002)(2656002)(86362001)(10400500002)(5003600100002)(10090500001)(5005710100001)(105586002)(5007970100001)(5002640100001)(40100003)(5004730100002)(122556002)(99286002)(106356001)(102836002)(33656002)(93886004)(106116001)(68736005)(46102003)(551544002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM 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: 28 Aug 2015 22:11:17.8251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 28 Aug 2015 22:11:23 -0000 On Friday, August 28, 2015 12:14 PM, Christian Huitema wrote: > ... > This is in fact the main limitation to Warren's approach. The proposed OW= E > system will still be vulnerable to passive listener attacks, and is thus = not much of > an improvement over open networks. >=20 > Note that this is also a limitation of the "public password" approach, as= in "ask > the password to the bartender." We can hypothesize that mass surveillance > systems will quickly build a database linking networks, SSID and public > passwords. After all, the initial WPA2 exchange carries authentication co= des that > are the hash of the nonce and the password, which trivially enables dicti= onary > attacks. That means the procedure will be: >=20 > 1) Capture the initial exchange between Station and Access point, and > remember the nonce. > 2) Retrieve the password associated to the SSID from the database. > 3) Derive the per station key using the nonce. > 4) Win! >=20 > Thinks would be different if instead of just sending the nonce in clear t= ext the > WPA2 exchange used some variation of Diffie-Hellman or EKE. Attackers wou= ld > need to move from "passive listening" to "actively implement MITM attack,= " and > we believe that might curtail mass surveillance efforts. But that's not t= he case. In fact, there is a way out, but it requires a bit more coding than Warren'= s simple hack. Suppose that instead of using WPA2-PSK, the access point would be using 802= .1x and EAP-Password (RFC 5931).=20 Suppose that in addition, the AP will send an information element explainin= g that it uses the OWE convention, which means that the user name is "anony= mous" and the password is the name of the SSID. The updated station automatically proceeds with the authentication. This re= sults in the derivation of a one-time session key, which is not vulnerable = to dictionary attacks and the like. It is still vulnerable to MITM attacks,= but that's kind of the definition of opportunistic security. A variation of the implementation would define that the user name is "anony= mous" and that the user needs to enter a password. That variation would be = as easy to use as WPA2-PSK, but would be protected against dictionary attac= ks. Now of course that requires a fair amount of coding: implement this EAP Pas= sword variation in the AP, and make sure it is available in the clients. Bu= t we would have actually improved Wi-Fi security, without compromising the = user experience. -- Christian Huitema From nobody Fri Aug 28 18:24:29 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 273D81B3659 for ; Fri, 28 Aug 2015 18:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, 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 V4aJjcIdX4CR for ; Fri, 28 Aug 2015 18:24:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016861B379C for ; Fri, 28 Aug 2015 18:24:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F5262015D for ; Fri, 28 Aug 2015 21:43:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3686863B10; Fri, 28 Aug 2015 21:24:26 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1B09E63AD9 for ; Fri, 28 Aug 2015 21:24:26 -0400 (EDT) From: Michael Richardson To: "saag@ietf.org" In-Reply-To: References: <20150826170138.GB9021@mournblade.imrryr.org> <55E028E0.6080803@restena.lu> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 29 Aug 2015 01:24:28 -0000 Christian Huitema wrote: > This is in fact the main limitation to Warren's approach. The proposed > OWE system will still be vulnerable to passive listener attacks, and is > thus not much of an improvement over open networks. I wish we'd stop trying to solve layer-5 problems at layer-2. Due to the proliferation of the belief that access to the network is "controlled", we have endless devices that lack proper authorization interfaces. I'd much rather we bought every starbucks as project and a sniffer, so that everyone could see what information they are disclosing. That's why I don't care about making wifi more "secure". -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sat Aug 29 08:02: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 C95371ACE23 for ; Fri, 28 Aug 2015 02:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLZ-8n8UswAG for ; Fri, 28 Aug 2015 02:47:27 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5A1A1B4B for ; Fri, 28 Aug 2015 02:47:26 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0019.outbound.protection.outlook.com [213.199.154.19]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-15-FVxbHy3FRreBVlZhgHKs2A-1; Fri, 28 Aug 2015 10:47:23 +0100 Received: from DB3PR07MB138.eurprd07.prod.outlook.com (10.242.132.20) by DB3PR07MB138.eurprd07.prod.outlook.com (10.242.132.20) with Microsoft SMTP Server (TLS) id 15.1.256.15; Fri, 28 Aug 2015 09:47:22 +0000 Received: from DB3PR07MB138.eurprd07.prod.outlook.com ([169.254.8.199]) by DB3PR07MB138.eurprd07.prod.outlook.com ([169.254.8.199]) with mapi id 15.01.0256.013; Fri, 28 Aug 2015 09:47:22 +0000 From: Josh Howlett To: Stefan Winter , "saag@ietf.org" Date: Fri, 28 Aug 2015 10:47:22 +0100 Thread-Topic: [saag] Would love some feedback on Opportunistic Wireless Encryption Thread-Index: AQHQ4DBZ69cTh+zZrkypIC+mXoL8Mp4ghZyAgACgxwCAAAH34A== Message-ID: References: <20150826170138.GB9021@mournblade.imrryr.org> <55E028E0.6080803@restena.lu> In-Reply-To: <55E028E0.6080803@restena.lu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-GB, en-US authentication-results: spf=none (sender IP is ) smtp.mailfrom=Josh.Howlett@jisc.ac.uk; x-originating-ip: [86.129.140.32] x-microsoft-exchange-diagnostics: 1; DB3PR07MB138; 5:sF6YuR8RPHYkvQu9XNtuuwxicDCKyrifxX92V3KBylMiLbzINaV4fzdY0BOQ2LAKxV8YIslD9ZWYpNWb55XizOt7VbZ62ee1I2XIO9q7Rl1BDGWhCVz1V9z24i4Fu6tX3KSRQJ2FpYDv1ht2czg5dg==; 24:4nYwuJBWYEDr0ig9D+dL1hTYE3qUE0V+Q3gJ7PRwkU7XC1f8jhGags5hN0UpFVPL8XpFPJ9dmSYuugU96fD7tW7y32vFNFZuVqiQka5ySLE=; 20:iE9YOfHdthHZLls0r4wVK3MHvhgnVfgeUR6+sLaTm6B5lijv4qEz0gQHYJtKpEJfl/d1cODw+wDsxr7IYFyEzomY5qTe73CIo9abMZUfDgkFNVuGLHQR/KCm+8JLTUDQMuG66L6J+0hrS1PS+erBh7A6vZaJJ0VxgpuJP3ADc/c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB138; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:DB3PR07MB138; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB138; x-forefront-prvs: 0682FC00E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(10400500002)(74316001)(33656002)(86362001)(40100003)(2501003)(2950100001)(2900100001)(68736005)(5003600100002)(4001540100001)(97736004)(5001770100001)(81156007)(106116001)(62966003)(77156002)(5002640100001)(106356001)(102836002)(5007970100001)(5001960100002)(76576001)(107886002)(189998001)(5004730100002)(5001860100001)(93886004)(105586002)(5001830100001)(2656002)(76176999)(66066001)(54356999)(101416001)(50986999)(46102003)(87936001)(74482002)(122556002)(92566002)(64706001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB138; H:DB3PR07MB138.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: jisc.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM x-originatororg: jisc.ac.uk x-ms-exchange-crosstenant-originalarrivaltime: 28 Aug 2015 09:47:22.6083 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 x-ms-exchange-transport-crosstenantheadersstamped: DB3PR07MB138 x-mc-unique: FVxbHy3FRreBVlZhgHKs2A-1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Sat, 29 Aug 2015 08:02:38 -0700 Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption 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, 28 Aug 2015 09:47:29 -0000 > So, what exactly are we winning with this approach? +1 I would also be concerned around with unintended consequences arising from = users drawing incorrect expectations of the security yielded by this approa= ch. It does confer some additional protection but in a very qualified way; = and in ways that are impossible for a layman to understand. It could encour= age users to attribute too much trust in the network, in ways that they wou= ldn't with an "open" network. This is a general issue with OE, of course. FWIW, at least in the UK most public WiFi access is captive portal, provide= d by a relatively small number of operators. In practice therefore I doubt = there would be a market for this. Josh. Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc=E2=80=99s registered office is: One Castlepark, Tower Hil= l, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800. =20 From nobody Mon Aug 31 00:57:24 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 CCB0A1B3463; Mon, 31 Aug 2015 00:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 N6YBQKiGjsy4; Mon, 31 Aug 2015 00:57:21 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (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 1BD5D1B3413; Mon, 31 Aug 2015 00:57:21 -0700 (PDT) Received: by laboe4 with SMTP id oe4so39691114lab.0; Mon, 31 Aug 2015 00:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=31n2ux1vXRwe8z8p89C+haE8B2AZLek1XoLviR0/Hgs=; b=skCbMXXHrj9ROBWtgY7/nKAMmNFp3GAI7KNKXoSkKTbHjs2Ho6rxOtKyZTHjjkB4NS qB0XA4uhiYyO8xUu87uXzBGj9QMmbFP6mOYu1FCgUN2mJMKF0hNWGiPCUhzC0O/L/Mv5 c3bZuU+23Nn5QjWwZtNvHFwdh84iAo8xXPXI7VjnGGw8Lh/WfoDL1MB2Gjm67rB+xCRt wo833TvekyW389P2zum0vYEyJng0wPrdeW5rvnf5KECjPQwz1wis/kZUVKRP0n5bYoiN PDIpO4ssR8wJfWsNjz1cW7SbBUMIJ0gnwA+0qqLTR8/V4cOsJsrZudcI0ECHYF5f2odN fjEQ== MIME-Version: 1.0 X-Received: by 10.112.62.133 with SMTP id y5mr7584110lbr.120.1441007839493; Mon, 31 Aug 2015 00:57:19 -0700 (PDT) Received: by 10.114.49.202 with HTTP; Mon, 31 Aug 2015 00:57:19 -0700 (PDT) Date: Mon, 31 Aug 2015 15:57:19 +0800 Message-ID: From: =?UTF-8?B?5p2O5Li95aeX?= To: ek@google.com Content-Type: multipart/alternative; boundary=001a11c3b4e8644450051e96c896 Archived-At: Cc: saag@ietf.org, dhcwg@ietf.org Subject: Re: [saag] [dhcwg] Fw:Fw:New Version Notification for draft-cui-dhc-dhcpv6-encryption-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: Mon, 31 Aug 2015 07:57:22 -0000 --001a11c3b4e8644450051e96c896 Content-Type: text/plain; charset=UTF-8 Dear Erik, Thanks very much for your corrections and guidance. IMHO, 802.1x is typically used to authenticate a device. we presume that 802.1x is used, then the various critical identifiers are faced with surveillance risk. According to privacy considerations for DHCPv6 [1], the various identifiers need to be protected from pervasive monitoring. To protect the DHCP privacy information from monitoring, I think the encryption between the DHCP client and server is necessary. Best Regards, Lishan [1] https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-01 At 2015-07-30 17:41:56, "Erik Kline" wrote: >>>Even in the "trusted network" scenario, the gain is only apparent in the >>> absence of link-layer protection. For example, enterprise Wi-Fi networks >>> typically use 802.1x and EAP to negotiate a link-layer encryption key >>> specific to the client. This goes a long way towards protecting all the link >>> traffic, including DHCP. Clearly there is a residual risk of on-line >>> attackers, such as a local computer owned by a virus. That risk is generally >>> mitigated by filters in the switches, restricting the sending of DHCP and RA >>> packets. DHCP encryption would be useful if it was easier to deploy than >>> those filters, and more secure. >>> >> [Lishan]: The link-layer encryption 802.1x and EAP you mentioned is only >> designed for the Wi-Fi network. For the general scenario, such as wired >> environment, the DHCP encryption is needed. > >802.1x works on wired ethernet. --001a11c3b4e8644450051e96c896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Erik,

Thanks very = much for your corrections and guidance.
IMHO, 802.1x is typically= used to authenticate a device. we presume that 802.1x is used, then the va= rious critical identifiers are faced with surveillance risk. According to p= rivacy considerations for DHCPv6 [1], the various identifiers need to be pr= otected from pervasive monitoring. To protect the DHCP privacy information = from monitoring, I think the encryption between the DHCP client and server = is necessary.=C2=A0

Best Regards,
Lishan=


At 2015-07-30 17:41:56, &q= uot;Erik Kline" <ek@google.com= > wrote:
>>>Even in the "trusted network" s= cenario, the gain is only apparent in the
>>> absence of= link-layer protection. For example, enterprise Wi-Fi networks
&g= t;>> typically use 802.1x and EAP to negotiate a link-layer encryptio= n key
>>> specific to the client. This goes a long way t= owards protecting all the link
>>> traffic, including DH= CP. Clearly there is a residual risk of on-line
>>> atta= ckers, such as a local computer owned by a virus. That risk is generally
>>> mitigated by filters in the switches, restricting the = sending of DHCP and RA
>>> packets. DHCP encryption woul= d be useful if it was easier to deploy than
>>> those fi= lters, and more secure.
>>>
>> [Lishan]:= The link-layer encryption 802.1x and EAP you mentioned is only
&= gt;> designed for the Wi-Fi network. For the general scenario, such as w= ired
>> environment, the DHCP encryption is needed.
>
>802.1x works on wired ethernet.
--001a11c3b4e8644450051e96c896--