From nobody Tue May 5 13:26:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602CB1A8833 for ; Tue, 5 May 2015 13:26:49 -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 FX1qxmlp_wed for ; Tue, 5 May 2015 13:26:44 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.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 409471B308C for ; Tue, 5 May 2015 13:26:44 -0700 (PDT) Received: by widdi4 with SMTP id di4so161328246wid.0 for ; Tue, 05 May 2015 13:26:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=IuBxc4QlpGCJHUSWEbWMkLoEzrrglWRtACimv4MGOmQ=; b=McGhPpN4cFNQjhkm0m+Pp1V9i/nKILJt0nRJrI672IyfPoKP4wXra07zNfApzKBmPh aIuvyQ/s5LMoqk8pSYzAudX60j9kA3kSgmO5/Fap/CD1uwq4incZh1Vw+JmiKDzcIXUA wm75DJ/Tt8FRwvngB6Xl7IOkamcS6piPuz/TXV5TyPxu+1rONXNNedPiJRDyXdtYe0Zy DNYCI6u8K1Z15vW443ld7NGBW7yh31rZ/r+bZY+BbhSuHtVuOOr7tp+HZcaY35H+iFAq CtB+EGabjnUM/jto3jx4bO9yKRooDiXfZB6dCGPdBZOArvRv3owY+4kUKISSaZs42eNW CMBg== X-Gm-Message-State: ALoCoQm1JbWfL5aMaHbT2SajM9b6mBBInb5otKf7vUMTZsee9nQGwi78LODNTv/Ik1yrxaXX7795 X-Received: by 10.194.60.67 with SMTP id f3mr55250933wjr.28.1430857602941; Tue, 05 May 2015 13:26:42 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id l3sm534161wiv.18.2015.05.05.13.26.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 May 2015 13:26:41 -0700 (PDT) Message-ID: <5549277D.7060404@azet.org> Date: Tue, 05 May 2015 22:26:37 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Bingzheng Wu References: 20150429023006.30489.70916.idtracker@ietfa.amsl.com In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig175698EC2FC71CBF1BBD4008" Archived-At: Cc: tls Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-client-keyshare-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 20:26:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig175698EC2FC71CBF1BBD4008 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I talked to Bingzheng off-list and suggested a couple of changes. I've made these editorial changes to enhance the readability of the draft as well as some grammatical and style changes. The effective content remains identical. Diff in-line. I also opened a Pull Request on GitHub for these changes: https://github.com/alibaba/client-keyshare/pull/1 Couple of comments: - the introduction is quite verbose and explicit, usually this is just a couple of paragraphs that give an overview - The draft references ephemeral DH a couple of times, maybe it should state somewhere explicitly that it only supports ephemeral DH due to TLS 1.3 and the current BCP for TLS? - I find the bullet-point explainations in the "message flow" section rather confusing Thanks, Aaron diff --git a/rfc-draft/draft-bzwu-tls-client-keyshare-00.xml b/rfc-draft/draft-bzwu-tls-client-keyshare-00.xml index d4662e0..3e88fcf 100644 --- a/rfc-draft/draft-bzwu-tls-client-keyshare-00.xml +++ b/rfc-draft/draft-bzwu-tls-client-keyshare-00.xml @@ -34,36 +34,35 @@ This document defines an extension that allows a TLS client - to carry Diffie-Hellman (DH) keyshare in ClientHello message, - replacing ClientKeyExchange message in the 2nd round-trip, - so as to reduce the full handshake latency of one network round-trip time (RTT). + to carry a Diffie-Hellman (DH) keyshare in ClientHello message, + replacing the ClientKeyExchange message in the 2nd round-trip, + to reduce the full handshake latency to one network round-trip time (RTT).
A full TLS handshake as specified in TLS requires 2-RTT, - mostly because of the ClientKeyExchange message in the 2nd round-trip, which is - used for key exchange. - The new version, TLS version 1.3 which works in progress, - provides 1-RTT mode, by sending DH keyshare immediately - after ClientHello in the 1st round-trip, called ClientKeyShare message. - However it will takes long time to finalize the draft and deploy. - - This document defines a TLS extension that allows the client using current TLS - version to carry DH keyshares in ClientHello message in the 1st round-trip. - This leads to a latency reduction of 1-RTT. Elliptic Curve (EC) and Finite Field (FF) - keyshare types are supported. - - The full handshake looks as follows with this extension. - A client takes this extension with DH keyshare in ClientHello message. - A server receiving this extension echos in ServerHello message to indicate enable - it in this session, and sends ServerKeyExchange to complete key exchange + mostly because of the ClientKeyExchange message in the second round-trip, which is + used for the key exchange. + TLS 1.3 will offer a 1-RTT mode by sending DH keyshare immediately= + after the ClientHello in the first round-trip, called ClientKeyShare message. + However, it will take a long time to finalize the draft and deploy TLS 1.3. + + This document defines a TLS extension that allows a client using TLS 1.2 + to carry DH keyshares in the ClientHello message with the 1st round-trip. + This leads to a latency reduction of of one round-trip. Elliptic Curve (EC) + and Finite Field (FF) keyshare types are supported. + + The full handshake works as follows with the keyshare extension= =2E + A client takes this extension with the DH keyshare in the ClientHello message. + A server receiving this extension echos it in the ServerHello message to indicate support + within this session and sends a ServerKeyExchange to complete the key exchange (with the DH keyshare in client's extension). - Since there is no ClientKeyExchange to wait for, server sends no ServerHelloDone, - but ChangeCipherSpec and Finished immediately, which is like the abbreviated handshake flow. + Since there is no ClientKeyExchange to wait for, the server sends no ServerHelloDone, + but ChangeCipherSpec and Finished message immediately, similar to an abbreviated handshake flow. - The message flow of normal full handshake is illustrated in Figure 1; and the message + The message flow of a normal full handshake is illustrated in Figure 1; and the message flow of handshake using this extension is illustrated in Figure 2.
- For TLS extension mechanism, this extension works only if client and server - both support it. For example, if a server who does not support this extension - receives a ClientHello message with this extension, the server just ignores it. + This works only if client and server + both support the extension. For example, if a server which does not support this extension + receives a ClientHello message with this extension, the server MUST ignore it. - This extension only works if the negotiated key exchange algorithm is DH-like, - FFDH(Ephemeral) or ECDH(Ephemeral). - Obviously client has to send ClientKeyExchange after getting serve= r's - certificate if using RSA as key exchange, so it can not benefit from this - extension normally. Although the client may get server's certificate before - handshake by Cached Infomation extension which works in progress, = we - does not support RSA key exchange for simplicity, and that DH-like is better - than RSA (TLS version 1.3, which works in progress, is going to - remove support for RSA key exchange). + This extension only works if the negotiated key exchange algorithm is + Ephemeral Diffie-Hellman (FFDH or ECDH). + Obviously, the client has to send a ClientKeyExchange message after getting the server's + certificate if it is using RSA as key exchange. Thus it can not benefit from this + extension. Although the client may get server's certificate before the + handshake by the Cached Infomation extension (work in progress), w= e + do not support RSA key exchange for simplicity. TLS 1.3 will remove support for RSA + key-exchange entirely and RSA as key-exchange is discouraged Since the client does not know which DH types and parameters the server supports, - it MAY takes more than one DH keyshares in this extension. + it MAY takes more than one DH keyshare in this extension. The server picks one DH keyshare of the same type with the key exchange - algorithm (FF or ECC) and acceptable parameters, used for key exchange. - If there is no suitable keyshare, the server just ignores this extension. + algorithm (FF or ECC) and acceptable parameters, used for the key exchange. + If there is no suitable keyshare, the server MUST ignore this extension. - Besides, this extension does not work if server requests client's certificate, - which also need 1 RTT. + This extension does not work if server requests a client's certificate, + which also needs 1-RTT. - Finally, this extension only works in full handshake, while not in abbreviated - handshake which does not need key exchange. + Finally, this extension only works in when full handshake are used, abbreviated + handshake are not supported.
@@ -144,7 +142,7 @@
This document defines a new extension type (client_keyshare(TBD)), which - is used in ClientHello and ServerHello messages. + is used in the ClientHello and ServerHello messages. The extension type is specified as follows.
, to indicate client's preferences. + The shares SHOULD keep the same order as with elliptic_curves + extension , to indicate client's preference. Only NamedCurves (for EC type) and NegotiatedParameters - (which works in progress) (for FF type) are supported. + (work in progress) (for FF type) are supported. While generic parameters are not supported for safety and simplicity.
Specifies the DH parameters associated with the public key. NamedGroup is extended from NamedCurve - by Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS, - which works in progress, for supporting finite-field-based DH.<= /t> + by Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS + (work in progress) for supporting finite-field-based DH. @@ -197,9 +195,9 @@ or in ECPoint format for EC type.= - Because the key exchange is made by ClientKeyshare extension and ServerKeyExchange message, - it's not need to take value in extension_data when included in ServerHello. - The server just echo the extension with empty extension_data to indicate enable it in + Because the key exchange is made by the ClientKeyshare extension and ServerKeyExchange message, + it's not necessary to parse values in extension_data if included in the ServerHello message. + The server just echoes the extension with an empty extension_data to indicate support in the current this session.
@@ -207,36 +205,36 @@
- In TLS handshake, client adds this extension in ClientHello, with one or more DH keyshares. + In the TLS handshake, the client adds this extension in the ClientHello message, with one or more DH keyshares. - When receiving handshake, server enables this extension if (also described in Introduction session): + When receiving a handshake, a server enables this extension if: - this extension is present in ClientHello; + the extension is present in ClientHello; the negotiated key-exchange algorithm is DH-like; - at least one acceptable ClientKeyShareOffer; - client's certificate is not required; - and it's full handshake but not abbreviated. + it has at least one acceptable ClientKeyShareOffer; + the client's certificate is not required; + and it's not an abbreviated handshake. If enabled, the server then: - adds this extension in ServerHello with empty extension_data, to indicate enable this extension; - picks one acceptable ClientKeyShareOffer for key exchange, - generates an DH keyshare with the same parameters as the picked ClientKeyShareOffer, - sends it in ServerKeyExchange, and completes the key exchange with them; - and does not wait for ClientKeyExchange, or sends ServerHelloDone; but sends ChangeCipherSpec - and Finished immediately. It's like the abbreviated handshake flow. + adds this extension in the ServerHello message with an empty extension_data, to indicate support for this extension; + picks one acceptable ClientKeyShareOffer for the key exchange,= + generates an DH keyshare with the same parameters as the chosen ClientKeyShareOffer, + sends it in the ServerKeyExchange, and completes the key exchange with these values; + it does not wait for ClientKeyExchange, and does not send a ServerHelloDone message; instead the server + sends ChangeCipherSpec and Finished messages immediately, like with an abbreviated handshake. - The client enables this extension if the server echos this extension in ServerHello. + The client enables this extension if the server echoes this extension in the ServerHello message. If enabled, the client then: - picks the ClientKeyShareOffer containing the same parameters with ServerKeyExchange, to complete key exchange. - If there is no such ClientKeyShareOffer, client MUST abort the handshake with an illegal_parameter fatal alert; + picks the ClientKeyShareOffer containing the same parameters as with ServerKeyExchange. + If there is no ClientKeyShareOffer, the client MUST abort the handshake with an illegal_parameter fatal alert; does not send ClientKeyExchange; - and expects not ServerHelloDone but ChangeCipherSpec and Finished after ServerKeyExchange. - It's like the abbreviated handshake flow. + and expects no ServerHelloDone message but ChangeCipherSpec and Finished messages after the ServerKeyExchange, + like with an abbreviated handshake.
@@ -245,29 +243,27 @@
- Server sends ChangeCipherSpec and Finished after ServerKeyExchange, if this - extension is enabled, in Figure 2. However there may be any messages between - ServerKeyExchange and ChangeCipherSpec, like NewSessionTicket message if Session - Ticket extension works . + Server sends ChangeCipherSpec and Finished messages after the ServerKeyExchange, if this + extension is enabled (Figure 2). However there may be messages between the + ServerKeyExchange and ChangeCipherSpec, e.g. NewSessionTicket, if the Session + Ticket extension is used . - In Session Hash extension, which works in progress, "handshake_messages" - refers to all handshake messages up to and including the ClientKeyExchange message. + With the Session Hash extension (work in progess) "handshake_messages" + refer to all handshake messages up to and including the ClientKeyExchange message. There is no ClientKeyExchange if this client_keyshare extension is enabled. - So the "handshake_messages" should be changed to refer to all handshake messages - up to and including the ServerKeyExchange message, without break Session Hash extension. + The "handshake_messages" should be changed to refer to all handshake messages + up to and including the ServerKeyExchange message, without breaking the Session Hash extension. Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for T= LS - where the FF NegotiatedParameters are defined, which works in progress, only supports - FFDH-ephemeral but not FFDH-static. This extension dose too. - + where the FF NegotiatedParameters are defined (works in progress) only supports + FFDH-ephemeral but not FFDH-static. This extension does as well too.
- This extension brings client's DH keyshare forward, from ClientKeyExchange + This extension brings client's DH keyshare forward, from the ClientKeyExchange message in the 2nd round-trip, to ClientHello message in the 1st round-trip. - The TLS version 1.3, which works in progress, also works like this. - So I have not find any security problem about this extension yet. + The TLS version 1.3 (works in progress) also works like this.
@@ -333,6 +329,18 @@ + + + + Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) + + + + + + + + --------------enig175698EC2FC71CBF1BBD4008 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVSSd+AAoJEOTbZJL9ubXVu7oQAIs7tt2Qr7A5Km+XcHu5bBgr N5Ehcpx9c9BzTQMia4Gky7KLxkpV+o67u3Kah5EP2hrsFKo64N6vXM2PSdKSD+PR 1lftsAvoO5Io+yWflFd7VZHqnZnyX+yccjaSM6v1215G4AujP+GOepNxP6pI0cW+ /IiwGppWX7zqefuipj9pcwhXaNtqNTLr5hBpSt9oTm9CvtMqFT78ggAgnJBeFTdG X73M7XB9krQsmoeQDAGbtmwC5Qqg85Tm1ddi6hKhTZ+SnotnICJDw6oTv3wQSZyd CUIjI1plCdIzQBMe6+X9tl6JnMLE6YrR6YVzJ3zWEzusXLtQQgzPBJSO6cj6JTV8 5KulnWzlZx3HgjR/dUIBkHW1DUUMwEtvMr8nEVcc0mokvdjEkfjmZo2KGmU1R/Sj 9iOq9h0MGMlNlA9Anbqx+h0GM191C0XBhYs154bFl9UhDQclozNyu+1nUWfYbSz1 oUnI9ij6fPekgcYg6gps7uVKfkJPEkUQ4A/RWrU36Zx++kOFDHTrePYurFtdjAO+ t6jRU+q/27Wnq2vdw3FvgExxDQ3II7FsNnZETmKCAc4fxBko+vsjyqPhspoAxae/ KhYfGH2r2UqvgiUd0b7VuWVtxeAJFkkGwC5XZjbWULl6yUMcSzp6S7z8r7CRFhdT BJbwsn1/lGORfh5Z6McL =x1Ub -----END PGP SIGNATURE----- --------------enig175698EC2FC71CBF1BBD4008-- From nobody Tue May 5 14:02:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A623F1AD373 for ; Tue, 5 May 2015 14:01:58 -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 nWTZYxwNkhG6 for ; Tue, 5 May 2015 14:01:57 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 BB0EB1AD358 for ; Tue, 5 May 2015 14:01:56 -0700 (PDT) Received: by wiun10 with SMTP id n10so161940974wiu.1 for ; Tue, 05 May 2015 14:01:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Q6XhTAukLXa0XeOkxrsFgclX15fzQvANmbSjS7yKBBw=; b=Vc6axhe3qYd663oeAy88HZkjZdsej1spW23LaX6G8yCMa9COs+jv0yaJ23yHvvYVio 0mKbIzoTr134S3e3FfohDnFUWpQ8so64JIR8slGnrdfxghYxTeRymLnfa6FXoJFVfLa2 aJza+pXjVFSSPDLIuHC5+pXAJvi0VLv9g9mj6TrCVoEuHw0TlDzuBgTNKNG4hex73937 p+bPqbsPMdULSnmFTQWN9D1svHIO95CY3YKh4AHuYKl+bVNEtpA9lcxH9O6gtakq9m6J ASqY/7R5WU3XY4zN/m41M0wASdHQfVig+DSBNrjZ2nn/l4WlGy9J7lpBQmJemg2VkTID JPkA== X-Gm-Message-State: ALoCoQk2uezbLOc4DxnLeAv5RLd8sJ/U/SYLDhBYQZ5oAIX80B36j40LIZiuTaaTsiN9DdDHqvoP X-Received: by 10.180.14.193 with SMTP id r1mr7539701wic.47.1430859715463; Tue, 05 May 2015 14:01:55 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id 9sm17194188wjr.11.2015.05.05.14.01.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 May 2015 14:01:54 -0700 (PDT) Message-ID: <55492FBD.6060104@azet.org> Date: Tue, 05 May 2015 23:01:49 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Bingzheng Wu References: 20150429023006.30489.70916.idtracker@ietfa.amsl.com <5549277D.7060404@azet.org> In-Reply-To: <5549277D.7060404@azet.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigDF6A60A8551DC53190B274F7" Archived-At: Cc: tls Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-client-keyshare-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:01:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF6A60A8551DC53190B274F7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A few more comments: * Maybe the document should state that it's intended for TLS 1.2 only (as there's no reason for this extension in 1.1). * Why have the original as well as the new flow as figures? Would just detail the new message flow with the proposed extension. * The security considerations section has barely any useful info. * it might suffice to note RSA as key exchange in the security considerations section, since it's deprecated * it might be reasonable to state in the beginning that handshakes involving client certificates are entirely unsupported, thus not noting it as often in the message flow section of the draft. Aaron --------------enigDF6A60A8551DC53190B274F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVSS++AAoJEOTbZJL9ubXV/TwP/AqAqR8u692Epaj8tQQjqhdo 1d3uGvtfKvBR6MQVgWSJFawtvtREk11+F6k3ZdFek6hlQo1BKWtdUIkVmExPP+WM M0dnMBUKYrCVuX+csC1MHlRVdXq7lmLrp0Qss4AjRhDWPYRuhzkCd2D6SBINcB+k b83Pi3HeebvM84uJgwT/2dffeBpAsJyhfLu2G3I0KMtdqVcG+Qv4tJsGlkEn9zUa SQu2y6WYT3XJvhfm3DhGeTI50dTsfwj1dkCDjjEeLUw+OA2H48laqeZREPwJ1XBl pHDw+IbGnjqoBlD4wW4Yda7AOwlOMhW33LWkAH3YqgR4pqAPkNuSSutCJUNhNll7 aNW0BMP38EED3jyU2vSDGDFb0ZTsiWBB7XusoDTi+YisXy4C2O9OisUCQJQd13Yd XoqJo0utQja8oCrX7Abaq3p3gWGsjtJu3UNtduh2q56ultwpHzA8KcFXigiBJ/ex 32g/HDyfUCqNrZzFFgBOIsL450zxtWHAstXerXRLRuZjs20RU15WKNyL1TxP/ADJ vI+m6SiHQ4dcLV1375mK+JOyKFZglbLimLa+mZTCA7Cap+Jh+Ah846PYnZgC868n RIPmHxYZQLs1NLoaOpyOdaFeWulgtK9LXBdrkFh7+IvK3wD+mlr6RvtXkVzdl9qf aVbvqm0LsX/fDVwQ3kRA =AjSD -----END PGP SIGNATURE----- --------------enigDF6A60A8551DC53190B274F7-- From nobody Wed May 6 19:00:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4D41A00CD for ; Wed, 6 May 2015 19:00:49 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQCxgQhFLEDY for ; Wed, 6 May 2015 19:00:47 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id 802341A009E for ; Wed, 6 May 2015 19:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430964046; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=zRqLCN/6l9aYKrcvg/G/zCvawLFAyULhVdaceYUKnU8=; b=O4FB1OLzFlqVVgKpO609PpG7uwPey75jgHPqotLRGWyLeTft/yx3esfNQD602mJaGHQQHqcvXBGsISFlNChDV150OFOJKErsetoHMiJVqYFAFXWeKAar21syTmL/if2zVl8SeEI63VIzVRW6xVlJoW9SRVkffk8T+/GaPtHEKnk= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R481e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05043; MF=bingzheng.wbz@alibaba-inc.com; PH=DS; RN=1; RT=1; SR=0; Received: from ali074145n(mailfrom:bingzheng.wbz@alibaba-inc.com ip:42.120.74.156) by smtp.aliyun-inc.com(127.0.0.1); Thu, 07 May 2015 10:00:42 +0800 From: "Bingzheng Wu" To: References: <20150507015038.3959.37354.idtracker@ietfa.amsl.com> In-Reply-To: <20150507015038.3959.37354.idtracker@ietfa.amsl.com> Date: Thu, 07 May 2015 10:00:42 +0800 Message-ID: <002701d08869$9fe17180$dfa45480$@alibaba-inc.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: AQJp/WMJ3UsxXbJ9vWNGJqI16VismZw81dtw Content-Language: zh-cn Archived-At: Subject: [TLS] New Version Notification for draft-bzwu-tls-client-keyshare-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 02:00:49 -0000 Hi All, I have updated draft-bzwu-tls-client-keyshare document to version-01. Aaron Zauner's editorial comments pull request was merged, and the = article's structure was changed following Aaron Zauner's advices. https://datatracker.ietf.org/doc/draft-bzwu-tls-client-keyshare/ Please kindly review it. Any comments are welcomed to the github: https://github.com/alibaba/client-keyshare I will put the client-keyshare's patch based on OpenSSL-1.0.2 to the = github, if helpful. Thanks and best regards, Bingzheng Wu > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, May 07, 2015 9:51 AM > To: Bingzheng Wu; Bingzheng Wu > Subject: New Version Notification for = draft-bzwu-tls-client-keyshare-01.txt >=20 >=20 > A new version of I-D, draft-bzwu-tls-client-keyshare-01.txt > has been successfully submitted by Bingzheng Wu and posted to the IETF > repository. >=20 > Name: draft-bzwu-tls-client-keyshare > Revision: 01 > Title: Transport Layer Security (TLS) Client Keyshare Extension > Document date: 2015-05-05 > Group: Individual Submission > Pages: 6 > URL: > = https://www.ietf.org/internet-drafts/draft-bzwu-tls-client-keyshare-01.tx= t > Status: > https://datatracker.ietf.org/doc/draft-bzwu-tls-client-keyshare/ > Htmlized: = https://tools.ietf.org/html/draft-bzwu-tls-client-keyshare-01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-bzwu-tls-client-keyshare-01 >=20 > Abstract: > This document defines an extension that allows a TLS client to = carry > Diffie-Hellman (DH) keyshares in ClientHello message, replacing the > ClientKeyExchange message in the second round-trip, to reduce the > full handshake latency to one network round-trip time (RTT). >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Wed May 6 20:13:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A5E1A8709 for ; Wed, 6 May 2015 20:13: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, 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 Edy3KoG3HAqi for ; Wed, 6 May 2015 20:13:08 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 4F0081A8701 for ; Wed, 6 May 2015 20:13:08 -0700 (PDT) Received: by qgej70 with SMTP id j70so14958231qge.2 for ; Wed, 06 May 2015 20:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=BTObeeWXc2UUTXSd0WiubLlYsnWnIKYTEa5SUtUc7jo=; b=WbHRF9397XBWDmUKjYdxBqTppgxJSvj7MWLcxmBe4VHebwCxLYzVXPUxt3ozXwUzVv Ut+/6v51Kfg3Bpj0DMJiJ6qAjY4FZh+9eW9iKzFmc8oCfV5+CY7JycWV7i9nifeWFsVX IfD5RUEJRiSduNlSZ7e6hCfY/XbweLGYz/k4b50HeBGc7PHw622S4P/xzUcl4v/Lc4kd nvJ645CbvzMBZ3re1FBM9hNZ8HkdIcVWAfO707zJjDbUXB3nbsL+ee1b3uXeENe09T/7 KK5zFfEeLh+FiOnUhHJoorwyEw7Q9boeto3foncM1uYsOdHg0/arPJ3HJm29LqTS/cjQ thrw== X-Received: by 10.55.42.148 with SMTP id q20mr4066848qkq.68.1430968387691; Wed, 06 May 2015 20:13:07 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id q105sm592215qgq.11.2015.05.06.20.13.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 May 2015 20:13:07 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 6 May 2015 23:13:05 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201505062313.06092.davemgarrett@gmail.com> Archived-At: Subject: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 03:13:10 -0000 https://tools.ietf.org/html/rfc5246#section-7.4.2 ---------------------------------------------------------------------- certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. ---------------------------------------------------------------------- It seems that in practice, nobody cares about that second "MUST". https://bugzilla.mozilla.org/show_bug.cgi?id=619445#c1 I'd like to propose simply changing that second "MUST" to a "SHOULD" or possibly even a "RECOMMENDED", thus allowing for clients to accept cert chains in different orderings as they already seem to do. (no change proposed for the first "MUST") I think there was also discussion on this list at some point suggesting changing that "MAY" for omitting the root CA cert to a "SHOULD" or a "MUST". (I think the argument for the latter was to reduce wasted bandwidth) Any reason this would be problematic? It'd be a simple change to add for the TLS 1.3 spec that would align things better with real-world usage. Dave From nobody Wed May 6 22:49:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586301ACEA2 for ; Wed, 6 May 2015 22:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqoMk5zl10QE for ; Wed, 6 May 2015 22:49:55 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 2684D1ACE9E for ; Wed, 6 May 2015 22:49:55 -0700 (PDT) Received: by wgyo15 with SMTP id o15so32356323wgy.2 for ; Wed, 06 May 2015 22:49:53 -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=w79v7UBmAtsrqbTifHjkk8HkqfwzvsbpPZHFyYqpRsg=; b=wYj8AEknZiqMtom5XwZrFyE1kRW0bzQ4OyN8sDaomQ8WrRfTQbJmtX2fIh25Lkq3T2 AbPTU/1NzXBizh7RqD6iCY1FUBqpXu+uHjF1pC1QgWuAaV4xwTsDxOVf4zu8Cn+4fYl7 +kHySFUoy1DUj8blavHnXKjTrmjONK19U1iSX1gFQ8jFa0Pmhn/BodPO6kl/TdcqXnK6 sY7f/FRbt66ujQ1qYPM8nXiY+9649lGdTeQg4say44cFNHdPRnkGolzmEM0U6lSZjACx PxsycK24hoXLIZzwq6SCHMtO1EIdzcDvEd4GNcrNJ90i1td8OHqxpoj2IhTZfUjF77eR rohQ== X-Received: by 10.180.99.231 with SMTP id et7mr3413212wib.23.1430977793761; Wed, 06 May 2015 22:49:53 -0700 (PDT) Received: from [10.4.44.202] ([82.102.169.113]) by mx.google.com with ESMTPSA id b5sm5538325wiw.8.2015.05.06.22.49.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 May 2015 22:49:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <201505062313.06092.davemgarrett@gmail.com> Date: Thu, 7 May 2015 08:49:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com> References: <201505062313.06092.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 05:49:57 -0000 Hi, Dave > On May 7, 2015, at 6:13 AM, Dave Garrett = wrote: >=20 > https://tools.ietf.org/html/rfc5246#section-7.4.2 > ---------------------------------------------------------------------- > certificate_list > This is a sequence (chain) of certificates. The sender's > certificate MUST come first in the list. Each following > certificate MUST directly certify the one preceding it. Because > certificate validation requires that root keys be distributed > independently, the self-signed certificate that specifies the = root > certificate authority MAY be omitted from the chain, under the > assumption that the remote end must already possess it in order = to > validate it in any case. > ---------------------------------------------------------------------- >=20 > It seems that in practice, nobody cares about that second "MUST=E2=80=9D= . It=E2=80=99s not that nobody cares about that second MUST. It=E2=80=99s = just that we=E2=80=99ve learned the hard way that a lot of servers get = it wrong, so we anyway had to run the whole = chain-sorting/chain-completing code anyway. > https://bugzilla.mozilla.org/show_bug.cgi?id=3D619445#c1 >=20 > I'd like to propose simply changing that second "MUST" to a "SHOULD" = or possibly even a "RECOMMENDED", thus allowing for clients to accept = cert chains in different orderings as they already seem to do. (no = change proposed for the first "MUST=E2=80=9D) People get it wrong, so let=E2=80=99s make it easy for them by relaxing = the requirement? Bleh. Might save some people from learning the hard = way that others get it wrong. But the thing with SHOULDs is that we = usually want an explanation of when it is OK to not follow the SHOULD. I = can=E2=80=99t think of any text for that. > I think there was also discussion on this list at some point = suggesting changing that "MAY" for omitting the root CA cert to a = "SHOULD" or a "MUST". (I think the argument for the latter was to reduce = wasted bandwidth) SHOULD is OK, MUST would imply perfect knowledge of how the other side = is configured. The root of trust may or may not be the self-signed = certificate. But it=E2=80=99s probably always fine to omit the = self-signed certificate. > Any reason this would be problematic? It'd be a simple change to add = for the TLS 1.3 spec that would align things better with real-world = usage. None that I can think of Yoav From nobody Wed May 6 22:50:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FED31ACED3 for ; Wed, 6 May 2015 22:50:26 -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 Maby55XR_HYi for ; Wed, 6 May 2015 22:50: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 EEBAA1ACEBA for ; Wed, 6 May 2015 22:50: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=uoa; t=1430977822; x=1462513822; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=O2ac2s3b/Sof9FV19JnouYoCGn1AVErnJvbFdy44FZg=; b=aa5JzTver1sfieOAuw20Y0W4gN3RZSqo8KDt4LpVt8+8Z6+YJkAm5EVn Mhx6iWfxB/D9+Gye+t47kGNB67uCDB7RrdNwLhcEAMB9dx8N8FwaY+LOq dm0Q5VhhqGIlrOHPnkqrIy6T+wSNHmh/NXQGmfTn39qoa5Rghuj/p6G1o E=; X-IronPort-AV: E=Sophos;i="5.13,383,1427713200"; d="scan'208";a="3488872" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 07 May 2015 17:50:19 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 7 May 2015 17:50:19 +1200 From: Peter Gutmann To: Dave Garrett , "tls@ietf.org" Thread-Topic: [TLS] Update spec to match current practices for certificate chain order Thread-Index: AQHQiHPHQz9aLKupu0CRDqxaUS0n3p1wAj1n Date: Thu, 7 May 2015 05:50:18 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB015B9E@uxcn10-tdc05.UoA.auckland.ac.nz> References: <201505062313.06092.davemgarrett@gmail.com> In-Reply-To: <201505062313.06092.davemgarrett@gmail.com> 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: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 05:50:26 -0000 Dave Garrett writes:=0A= =0A= >I'd like to propose simply changing that second "MUST" to a "SHOULD" or=0A= >possibly even a "RECOMMENDED", thus allowing for clients to accept cert=0A= >chains in different orderings as they already seem to do. (no change propo= sed=0A= >for the first "MUST")=0A= =0A= I suspect the first MUST can go as well, particularly if you're using code= =0A= that handles cert chains in other formats like CMS/PKCS #7, where the "chai= n"=0A= can contain any old rubbish and the chain-assembly code has to build the pa= th.=0A= For example my code looks for a cert containing the site name =0A= ("www.whatever.com") and then builds a chain up via the parent links until = it=0A= can't find any more useful certs. That just works no matter what the other= =0A= side sends.=0A= =0A= Peter.= From nobody Wed May 6 23:59:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53FE1AD34F for ; Wed, 6 May 2015 23:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.186 X-Spam-Level: X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, J_CHICKENPOX_21=0.6] 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 AvL3mtdzrrKI for ; Wed, 6 May 2015 23:59:26 -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 8CDD61AD2C4 for ; Wed, 6 May 2015 23:59:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E61AE283031; Thu, 7 May 2015 06:59:24 +0000 (UTC) Date: Thu, 7 May 2015 06:59:24 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150507065924.GH17272@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55487D88.7010909@openssl.org> <201505062313.06092.davemgarrett@gmail.com> <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 06:59:28 -0000 On Thu, May 07, 2015 at 08:49:21AM +0300, Yoav Nir wrote: > > I think there was also discussion on this list at some point suggesting > > changing that "MAY" for omitting the root CA cert to a "SHOULD" or a > > "MUST". (I think the argument for the latter was to reduce wasted bandwidth) Sorry, this is incompatible with use of DANE TLSA records when the ceritificate usage is DANE-TA(2). See: https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-3.1.2 https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.2 The first of these is currently in IETF LC, the second in DANE WG LC. > SHOULD is OK, MUST would imply perfect knowledge of how the other side is > configured. As you note, there is more than one way to verify certificates, and the server cannot know exactly which certificates are needed by the client. A SHOULD or MUST would be counter-productive. > The root of trust may or may not be the self-signed certificate. > But it?s probably always fine to omit the self-signed certificate. No, not always. > > Any reason this would be problematic? It'd be a simple change to add > > for the TLS 1.3 spec that would align things better with real-world usage. > > None that I can think of You won't be able to say that next time. :-) -- Viktor. From nobody Thu May 7 00:00:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889411B29A2 for ; Thu, 7 May 2015 00:00:09 -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 68EmZ8Xhj3G9 for ; Thu, 7 May 2015 00:00:07 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 852DC1B29A3 for ; Thu, 7 May 2015 00:00:07 -0700 (PDT) Received: by qgfi89 with SMTP id i89so16565331qgf.1 for ; Thu, 07 May 2015 00:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=+hRZA9O7czf4gzYyUbdkw+YbVs00GRlwLg7Y954PFLo=; b=bj8oRn1giqkydDmskULC7sJCnZuUYxIDXbUep1em9zvqlJjzMBtVOPQ0CGsUsy9AGM RpAqWtPpwHoqdvBqroamdVO7PJZt0GFkmleSClraOLiZy+2Ihw+YTObaJEBHMGsn55Lv sx+qtj0z8mWp06nzHPC/aHmzWdbNpRIzW9wTYCRPcRmaxE6g9Oq7TigzeJWByJZskhVe gAIhJdhRSiHXJhFvaVhb1JJQsRBMVPhGGVXPM/OB4wjkEOQt+ELKfmIsmB7SArhaSCQT 5XMPGelTvAp1n5U7ZkSloCfY55BVZQXjBj4A+LXEIwejlIO+j6wEDL9R/6xkRux7RWXP i5tg== X-Received: by 10.55.24.158 with SMTP id 30mr5147404qky.83.1430982006823; Thu, 07 May 2015 00:00:06 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id z198sm844667qhd.44.2015.05.07.00.00.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 May 2015 00:00:06 -0700 (PDT) From: Dave Garrett To: Yoav Nir , Peter Gutmann Date: Thu, 7 May 2015 03:00:04 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201505062313.06092.davemgarrett@gmail.com> <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com> In-Reply-To: <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201505070300.05183.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 07:00:09 -0000 On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote: > > On May 7, 2015, at 6:13 AM, Dave Garrett wrote: > > It seems that in practice, nobody cares about that second "MUST=E2=80= =9D. >=20 > It=E2=80=99s not that nobody cares about that second MUST. It=E2=80=99s j= ust that we=E2=80=99ve learned the hard way that a lot of servers get it wr= ong, so we anyway had to run the whole chain-sorting/chain-completing code = anyway. By "nobody cares" I mean that clients seem to be fine handling this now, ev= en if they'd rather not have had to. I don't see vendors evangelizing the p= roper ordering of certs as a high priority. > People get it wrong, so let=E2=80=99s make it easy for them by relaxing t= he requirement? Bleh. Might save some people from learning the hard way th= at others get it wrong. Well, we don't get anything from telling people to panic and abort the conn= ection if it's wrong. Handling the possibility of out-of-order certs is alr= eady a thing that has to be done in practice, so stating that up front woul= d improve real-world interop for any clients that might've done otherwise. In any case, there's not much point in having a "MUST" in the spec that doe= sn't really help and won't be enforced. > But the thing with SHOULDs is that we usually want an explanation of whe= n it is OK to not follow the SHOULD. I can=E2=80=99t think of any text for = that. With Mozilla's phase out of 1024-bit roots, some sites followed recommendat= ions to have two intermediates as a transitional measure. This may be usefu= l for future transitions as well. (not clear on the details here; please co= rrect me if I'm wrong) > > I think there was also discussion on this list at some point suggesting= changing that "MAY" for omitting the root CA cert to a "SHOULD" or a "MUST= ". (I think the argument for the latter was to reduce wasted bandwidth) >=20 > SHOULD is OK, MUST would imply perfect knowledge of how the other side is= configured. The root of trust may or may not be the self-signed certificat= e. But it=E2=80=99s probably always fine to omit the self-signed certificat= e. >=20 > > Any reason this would be problematic? It'd be a simple change to add fo= r the TLS 1.3 spec that would align things better with real-world usage. >=20 > None that I can think of >=20 > Yoav On Thursday, May 07, 2015 01:50:18 am Peter Gutmann wrote: > I suspect the first MUST can go as well, particularly if you're using code > that handles cert chains in other formats like CMS/PKCS #7, where the "ch= ain" > can contain any old rubbish and the chain-assembly code has to build the = path. > For example my code looks for a cert containing the site name=20 > ("www.whatever.com") and then builds a chain up via the parent links unti= l it > can't find any more useful certs. That just works no matter what the oth= er > side sends. >=20 > Peter. We might just want to SHOULD-ify the whole thing, then. Here's a stab at a rewrite with SHOULDs and generalized language: =2D--------------------------------------------------------------------- certificate_list This is a list of certificates needed for authentication. The sender's certificate SHOULD come first in the list, followed by additional certificates ordered by increasing authority. (e.g. sender, intermediate(s), certificate authority) Root certificate authority certificates SHOULD NOT be provided in this list, as validation generally requires the root keys be distributed independently. =2D--------------------------------------------------------------------- That may need some tweaking, but I think it clearly outlines the expectatio= ns and reasoning. How does that sound? Dave From nobody Thu May 7 06:52:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678FC1A7034 for ; Thu, 7 May 2015 06:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 JMzz9jsmoozK for ; Thu, 7 May 2015 06:52:17 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028E31A6FF6 for ; Thu, 7 May 2015 06:52:16 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 6EE8C44A45; Thu, 7 May 2015 15:52:14 +0200 (CEST) X-purgate-ID: 152705::1431006734-00005316-41B50EBA/0/0 X-purgate-size: 1568 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 5F44743976; Thu, 7 May 2015 15:52:14 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 500811B2D9; Thu, 7 May 2015 15:52:14 +0200 (CEST) In-Reply-To: <201505062313.06092.davemgarrett@gmail.com> To: Dave Garrett Date: Thu, 7 May 2015 15:52:14 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150507135214.500811B2D9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 13:52:19 -0000 Dave Garrett wrote: > https://tools.ietf.org/html/rfc5246#section-7.4.2 > ---------------------------------------------------------------------- > certificate_list > This is a sequence (chain) of certificates. The sender's > certificate MUST come first in the list. Each following > certificate MUST directly certify the one preceding it. Because > certificate validation requires that root keys be distributed > independently, the self-signed certificate that specifies the root > certificate authority MAY be omitted from the chain, under the > assumption that the remote end must already possess it in order to > validate it in any case. > ---------------------------------------------------------------------- > > It seems that in practice, nobody cares about that second "MUST". That isn't quite accurate. Up to 2013 our SSL implementation has been hard failing TLS handshakes with TLS peers that are sending garbled or incomplete chains. In 2013, I added a _simple_ reordering before certficate path validation. Missing certificates or alien certificates are still going to result in a fatal handshake failure. The one thing that I fail to understand: why did SSL implementations add sorting into the recipient side processing of the TLS Certificate handshake message, but *NOT* at the same time fix their sender-side processing of that handshake message to *NOT* send bogus certificat_lists in the first place. One of the most notorious offenders is OpenSSL. -Martin From nobody Thu May 7 06:58:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60AE1A898F for ; Thu, 7 May 2015 06:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 NSspzoZtHaSe for ; Thu, 7 May 2015 06:58:00 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008841A8848 for ; Thu, 7 May 2015 06:57:59 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 4DE0C2AE57; Thu, 7 May 2015 15:57:58 +0200 (CEST) X-purgate-ID: 152705::1431007078-00005316-A6D239B5/0/0 X-purgate-size: 1169 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3B2CE438FE; Thu, 7 May 2015 15:57:58 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2E0971B2D9; Thu, 7 May 2015 15:57:58 +0200 (CEST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB015B9E@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann Date: Thu, 7 May 2015 15:57:58 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150507135758.2E0971B2D9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 13:58:01 -0000 Peter Gutmann wrote: > Dave Garrett writes: > >>I'd like to propose simply changing that second "MUST" to a "SHOULD" or >>possibly even a "RECOMMENDED", thus allowing for clients to accept cert >>chains in different orderings as they already seem to do. (no change proposed >>for the first "MUST") > > I suspect the first MUST can go as well, particularly if you're using code > that handles cert chains in other formats like CMS/PKCS #7, where the "chain" > can contain any old rubbish and the chain-assembly code has to build the path. That would be a terrible idea. I believe that there is a non-marginal number of TLS implementations that requires the end-entity certificate to come first in the list, not just ours. > > For example my code looks for a cert containing the site name > ("www.whatever.com") and then builds a chain up via the parent links until it > can't find any more useful certs. That just works no matter what the other > side sends. Adding workarounds for clearly bogus behaviour is a very bad strategy, because it makes the situation worse for everyone in the long run. -Martin From nobody Thu May 7 07:20:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8A31A9004 for ; Thu, 7 May 2015 07:20:32 -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 A7plmH8dO370 for ; Thu, 7 May 2015 07:20:25 -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 BA6B81A8A48 for ; Thu, 7 May 2015 07:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1431008419; x=1462544419; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+t+BK45016c9arG/fcbxjqPFlPhBLeBJ3cCt+KkIjB0=; b=u72ham9uaCKI3npyr3qbNFGU5lMblfXPX6BZEYpdHax19hoVjRc6E6wS CuODX2MIEdZ7JjKWC4A80xSgOw01IUDsQwblwNAfuDQkOfTtwhwN87Yv+ pwC8gkIejf6/KS6VPqzXRd7c+oco9snbG/r/Q0FMlDdS4K4duIib9GFVT M=; X-IronPort-AV: E=Sophos;i="5.13,384,1427713200"; d="scan'208";a="3542549" 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; 08 May 2015 02:20:18 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 8 May 2015 02:20:17 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Update spec to match current practices for certificate chain order Thread-Index: AdCI0PBlwpfYkwi8TLGR/zDLR+HmmA== Date: Thu, 7 May 2015 14:20:16 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB016584@uxcn10-tdc05.UoA.auckland.ac.nz> 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: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 14:20:32 -0000 Martin Rex writes:=0A= >Peter Gutmann wrote:=0A= >> For example my code looks for a cert containing the site name=0A= >> ("www.whatever.com") and then builds a chain up via the parent links unt= il it=0A= >> can't find any more useful certs. That just works no matter what the ot= her=0A= >> side sends.=0A= >=0A= >Adding workarounds for clearly bogus behaviour is a very bad strategy,=0A= >because it makes the situation worse for everyone in the long run.=0A= =0A= In my case (and possibly others) it's not a workaround since the same code= =0A= that does PKCS #7/CMS also does TLS cert chains, in order to handle the mor= e=0A= open-ended PKCS #7 requirements it automatically deals with oddball TLS=0A= chains.=0A= =0A= Peter.=0A= From nobody Thu May 7 07:32:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D116A1A88CF for ; Thu, 7 May 2015 07:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-5, 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 FXwjzHUBe-91 for ; Thu, 7 May 2015 07:32:09 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8631A87A2 for ; Thu, 7 May 2015 07:32:09 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id AC48D449D9; Thu, 7 May 2015 16:32:07 +0200 (CEST) X-purgate-ID: 152705::1431009127-00005316-DCDB170E/0/0 X-purgate-size: 1127 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 9B7344396B; Thu, 7 May 2015 16:32:07 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9026C1B2DA; Thu, 7 May 2015 16:32:07 +0200 (CEST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB016584@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann Date: Thu, 7 May 2015 16:32:07 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150507143207.9026C1B2DA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 14:32:14 -0000 Peter Gutmann wrote: > Martin Rex writes: > >Peter Gutmann wrote: > >> For example my code looks for a cert containing the site name > >> ("www.whatever.com") and then builds a chain up via the parent links until it > >> can't find any more useful certs. That just works no matter what the other > >> side sends. > > > >Adding workarounds for clearly bogus behaviour is a very bad strategy, > >because it makes the situation worse for everyone in the long run. > > In my case (and possibly others) it's not a workaround since the same code > that does PKCS #7/CMS also does TLS cert chains, in order to handle the more > open-ended PKCS #7 requirements it automatically deals with oddball TLS > chains. PKCS#7/CMS uses a Issuer&Serial (or alternatively SKI) to clearly identify the end-entity certificate. In TLS, the identification is the first position in certificate_list. So it is not possible to "blindly reuse" the code with respect to identifying the end-entity certificate. For the certificate path beyond the end entity certificate, the approach may be similar. -Martin From nobody Thu May 7 07:43:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE3B1A90C7 for ; Thu, 7 May 2015 07:43:48 -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_66=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 W5rZTn_4Vj0l for ; Thu, 7 May 2015 07:43:47 -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 295B01A88F2 for ; Thu, 7 May 2015 07:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1431009827; x=1462545827; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=zJkYOB1RSwFszmBiLsd9yxAglhGcJxhdwF02bpl0ohY=; b=bDFQqqEv/RAGN6SRAotSHs0aTiiSWd/SuGcDKwAcacSSzrh/l9SbAQQO 1MQVLmIUf3phgTURP0pHZMj2hzoBE5DkrXymub5bXSqh+3MC7gETf+LUY kMCAROhF0FZcJb/VV4kbIIs9imkvwxSRwIqzip3pge/6xcHteO4gMw4Cu U=; X-IronPort-AV: E=Sophos;i="5.13,384,1427713200"; d="scan'208";a="3543959" 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; 08 May 2015 02:43:45 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 8 May 2015 02:43:45 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Update spec to match current practices for certificate chain order Thread-Index: AdCI1Dg/2ozacAakSXysMh8LQCn4jA== Date: Thu, 7 May 2015 14:43:45 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> 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: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 14:43:48 -0000 Martin Rex writes:=0A= =0A= >PKCS#7/CMS uses a Issuer&Serial (or alternatively SKI) to clearly identify= =0A= >the end-entity certificate. In TLS, the identification is the first posit= ion=0A= >in certificate_list. So it is not possible to "blindly reuse" the code wi= th=0A= >respect to identifying the end-entity certificate.=0A= =0A= Yes it is, as I mentioned in my previous message my code looks for the serv= er=0A= FQDN/whatever and uses the cert that contains that as the leaf cert. It's = the=0A= same process that's used for IssuerAndSerialNumber, SCEP client IDs, and=0A= various other things, "find the cert for the identified party, then follow= =0A= parent links to build the chain".=0A= =0A= Peter.= From nobody Thu May 7 08:24:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692221A92BA for ; Thu, 7 May 2015 08:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.038 X-Spam-Level: ** X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 JjkBBOEe9lDi for ; Thu, 7 May 2015 08:24:36 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870971A92BB for ; Thu, 7 May 2015 08:24:34 -0700 (PDT) Received: from mail-lb0-f177.google.com ([209.85.217.177]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0MORwj-1Yvcqz3V2r-005qVQ for ; Thu, 07 May 2015 17:24:32 +0200 Received: by lbbqq2 with SMTP id qq2so33631177lbb.3 for ; Thu, 07 May 2015 08:24:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.153.6.36 with SMTP id cr4mr3613497lad.56.1431012272035; Thu, 07 May 2015 08:24:32 -0700 (PDT) Received: by 10.25.25.132 with HTTP; Thu, 7 May 2015 08:24:31 -0700 (PDT) In-Reply-To: <20150506101230.32573.26774.idtracker@ietfa.amsl.com> References: <20150506101230.32573.26774.idtracker@ietfa.amsl.com> Date: Thu, 7 May 2015 17:24:31 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11348c3824e16705157f829d X-Provags-ID: V03:K0:bS9Pa2Jke/dquELivY+GUiZU1ey69riQdcmS6XQA7FvZMOxaRjp j062SH7rYz4xJuS424mklCtK1EZvyI1HMa1wZq39ow4eX7FGrGIs6OGcqAznL665c/Um22Y 1++Ds+KVSuebXjOHFnMIpPkM+D5Eq+ADjgFzv7G/4rCTWOo6tqJbnOKC8HilGETvbjGah1C KAVvKtQzhiPcC1eLZ3SFA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-ieft-tls-falsestart-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:24:38 -0000 --001a11348c3824e16705157f829d Content-Type: text/plain; charset=UTF-8 As discussed with Sean, draft-ieft-tls-falsestart-00 intentionally is essentially a copy of draft-bmoeller-tls-falsestart-01 (with only metadata updated), not because we don't want to make changes but because we want to start doing these between -00 to -01 for ease of tracking. I intend to change the following (and then expect new comments on the updated I-D resulting in a -02 revision): - The intended status should probably be "Informational". - Be clear that the document does not apply to TLS 1.3 and beyond, because these protocols come with new protocol flows designed to reduce the number of round-trip times. - Remove server-side False Start entirely, as the document (now) is mainly about describing existing deployments. (Server-side False Start isn't entirely pointless, but I don't think anyone ever saw a sufficiently compelling case for it to actually deploy it.) - State explicitly that for client implementations with a maximum version of TLS 1.2, normally the protocol version whitelist should be TLS 1.2 only (but clients that don't support TLS 1.2 may be using False Start with earlier protocol versions, and clients that support TLS 1.3 might disable False Start entirely -- that's what the TLS_FALLBACK_SCSV language is really about). - Recommend against use of False Start with (EC)DHE on any kind of explicit groups, and on named groups of insufficient size. (I don't think we should try to predict whether the ffdhe groups from draft-ietf-tls-negotiated-ff-dhe-08 will catch on with TLS 1.2, so False Start with traditional DHE shouldn't be entirely left out.) Then Brian had a comment about False Start with client certificates. I'm not yet sure what to make out of that. The main point of mentioning client certificate types in the I-D was to make sure that False Start isn't used with rsa_fixed_dh and the like (since client implementations might allow mixing client-side static DH with server-side ephemeral DH, assuming they support DH certs at all). Sending client certs in the clear may not be a good idea, but that issue seems entirely orthogonal to what False Start is all about. Do you see an actual problem about sending a client's signing cert specifically in a False Start handshake? Bodo ---------- Forwarded message ---------- From: Date: 2015-05-06 12:12 GMT+02:00 Subject: New Version Notification for draft-ieft-tls-falsestart-00.txt To: Adam Langley , Bodo Moeller , Nagendra Modadugu , Nagendra Modadugu < Nagendra@cs.stanford.edu> A new version of I-D, draft-ieft-tls-falsestart-00.txt has been successfully submitted by Bodo Moeller and posted to the IETF repository. Name: draft-ieft-tls-falsestart Revision: 00 Title: Transport Layer Security (TLS) False Start Document date: 2015-05-06 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-ieft-tls-falsestart-00.txt Status: https://datatracker.ietf.org/doc/draft-ieft-tls-falsestart/ Htmlized: https://tools.ietf.org/html/draft-ieft-tls-falsestart-00 Abstract: This document specifies an optional behavior of TLS implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. The TLS False Start feature leads to a latency reduction of one round trip for certain handshakes. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a11348c3824e16705157f829d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As discussed with Sean,=C2=A0draft-ieft-tls-falsestart-00 = intentionally is essentially a copy of=C2=A0draft-bmoeller-tls-falsestart-0= 1 (with only metadata updated), not because we don't want to make chang= es but because we want to start doing these between -00 to -01 for ease of = tracking.

I intend to change the following (and then exp= ect new comments on the updated I-D resulting in a -02 revision):

- The intended status should probably be "Informationa= l".

- Be clear that the document does not app= ly to TLS 1.3 and beyond, because these protocols come with new protocol fl= ows designed to reduce the number of round-trip times.

=
- Remove server-side False Start entirely, as the document (now) is ma= inly about describing existing deployments. (Server-side False Start isn= 9;t entirely pointless, but I don't think anyone ever saw a sufficientl= y compelling case for it to actually deploy it.)

-= State explicitly that for client implementations with a maximum version of= TLS 1.2, normally the protocol version whitelist should be TLS 1.2 only (b= ut clients that don't support TLS 1.2 may be using False Start with ear= lier protocol versions, and clients that support TLS 1.3 might disable Fals= e Start entirely -- that's what the TLS_FALLBACK_SCSV language is reall= y about).
=C2=A0
- Recommend against use of False Start= with (EC)DHE on any kind of explicit groups, and on named groups of insuff= icient size. (I don't think we should try to predict whether the ffdhe = groups from draft-ietf-tls-negotiated-ff-dhe-08 will catch on with TLS 1.2,= so False Start with traditional DHE shouldn't be entirely left out.)

Then Brian had a comment about False Start with cli= ent certificates. I'm not yet sure what to make out of that. The main p= oint of mentioning client certificate types in the I-D was to make sure tha= t False Start isn't used with=C2=A0rsa_fixed_dh and the like (since cli= ent implementations might allow mixing client-side static DH with server-si= de ephemeral DH, assuming they support DH certs at all). Sending client cer= ts in the clear may not be a good idea, but that issue seems entirely ortho= gonal to what False Start is all about. Do you see an actual problem about = sending a client's signing cert specifically in a False Start handshake= ?

Bodo



---------- Forwarded message ----------From: <internet-drafts@ietf.org= >
Date: 2015-05-06 12:12 GMT+02:00
Subject: New Version= Notification for draft-ieft-tls-falsestart-00.txt
To: Adam Langley <= agl@google.com>,= Bodo Moeller <bmo= eller@acm.org>, Nagendra Modadugu <nagendra@cs.stanford.edu>, Nagendra = Modadugu <= Nagendra@cs.stanford.edu>



A new version of I-D, draft-ieft-tls-falsestart-00.txt
has been successfully submitted by Bodo Moeller and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ieft-tls-falsestart
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Transport Layer Security (TLS) Fal= se Start
Document date:=C2=A0 2015-05-06
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http= s://www.ietf.org/internet-drafts/draft-ieft-tls-falsestart-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker= .ietf.org/doc/draft-ieft-tls-falsestart/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html= /draft-ieft-tls-falsestart-00


Abstract:
=C2=A0 =C2=A0This document specifies an optional behavior of TLS implementa= tions,
=C2=A0 =C2=A0dubbed False Start.=C2=A0 It affects only protocol timing, not= on-the-wire
=C2=A0 =C2=A0protocol data, and can be implemented unilaterally.=C2=A0 The = TLS False
=C2=A0 =C2=A0Start feature leads to a latency reduction of one round trip f= or
=C2=A0 =C2=A0certain handshakes.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a11348c3824e16705157f829d-- From nobody Thu May 7 08:52:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A201ACD07 for ; Thu, 7 May 2015 08:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6] 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 0ai7s0P_-EUz for ; Thu, 7 May 2015 08:52: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 C70CB1ACCF9 for ; Thu, 7 May 2015 08:51:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2E1CB283031; Thu, 7 May 2015 15:51:48 +0000 (UTC) Date: Thu, 7 May 2015 15:51:48 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150507155147.GO17272@mournblade.imrryr.org> References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:52:09 -0000 On Thu, May 07, 2015 at 02:43:45PM +0000, Peter Gutmann wrote: > >PKCS#7/CMS uses a Issuer&Serial (or alternatively SKI) to clearly identify > >the end-entity certificate. In TLS, the identification is the first position > >in certificate_list. So it is not possible to "blindly reuse" the code with > >respect to identifying the end-entity certificate. > > Yes it is, as I mentioned in my previous message my code looks for the server > FQDN/whatever and uses the cert that contains that as the leaf cert. It's the > same process that's used for IssuerAndSerialNumber, SCEP client IDs, and > various other things, "find the cert for the identified party, then follow > parent links to build the chain". I don't see such an ad-hoc approach as a compelling reason to remove the requirement that the end-entity certificate must come first. The MUST needs to stay. The TLS layer does not always know which SAN value will be used to authenticate the peer. Certificate verification can be delayed until the handshake is complete, and can be performed outside the TLS stack. The TLS stack needs the leaf certificate for key agreement. I summary, the only thing that could be tweaked is the requirement to order the intermediate certificates. The first MUST and final MAY are correct as they stand. And I think that the second MUST is a fine example of Postel's principle. Tolerance by many clients of servers that ignore the requirement does not invalidate the requirement. -- Viktor. From nobody Thu May 7 09:05:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970941ACCEF for ; Thu, 7 May 2015 09:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 D3zdscr9byMs for ; Thu, 7 May 2015 09:05:21 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D5D1ACDAF for ; Thu, 7 May 2015 09:05:00 -0700 (PDT) Received: from mail-la0-f54.google.com ([209.85.215.54]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0Mhqzr-1YcSDJ2phj-00MrX7 for ; Thu, 07 May 2015 18:04:58 +0200 Received: by labbd9 with SMTP id bd9so34178859lab.2 for ; Thu, 07 May 2015 09:04:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.119.163 with SMTP id kv3mr3678881lbb.101.1431014697780; Thu, 07 May 2015 09:04:57 -0700 (PDT) Received: by 10.25.25.132 with HTTP; Thu, 7 May 2015 09:04:57 -0700 (PDT) In-Reply-To: References: <20150506101230.32573.26774.idtracker@ietfa.amsl.com> Date: Thu, 7 May 2015 18:04:57 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb70e4abacc9f05158012fd X-Provags-ID: V03:K0:s9ocdiQh4iD8j/OhgkbsyT1iyoQnYLlN7anSlNJV4S1Bwgccjaf oFOjkbdaBycS8fDvCm36Dp0c7RARCFSOYzKjRFmERlVViLbWOqSrbOl6XmlHY3oXRKunL/T Mpbt5erJrEvSs/JajPFQyjpMPcXdANuEStL7Gg2cM0SxT+8Go+FGAXkIfJu80TjywyIKN3F Sk/P52UDS53W/+G1Lnmaw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [TLS] New Version Notification for draft-ieft-tls-falsestart-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:05:22 -0000 --047d7bb70e4abacc9f05158012fd Content-Type: text/plain; charset=UTF-8 Gah, it turns out I published the I-D as an IEFT document, not an IETF document. (I just learnt that the submission tool does not check the file name against the metadata in the file.) Expect https://www.ietf.org/internet-drafts/draft-ietf-tls-falsestart-00.txt to show up soon. Bodo --047d7bb70e4abacc9f05158012fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gah, it turns out I published the I-D as an IEFT document,= not an IETF document. (I just learnt that the submission tool does not che= ck the file name against the metadata in the file.) Expect=C2=A0http= s://www.ietf.org/internet-drafts/draft-ietf-tls-falsestart-00.txt to sh= ow up soon.

Bodo
<= /div> --047d7bb70e4abacc9f05158012fd-- From nobody Thu May 7 10:08:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1188F1A032D for ; Thu, 7 May 2015 10:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 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_NONE=-0.0001] 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 uj0j2u9YJV9b for ; Thu, 7 May 2015 10:08:18 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0211A19E5 for ; Thu, 7 May 2015 10:08:05 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id BD45C27BC084 for ; Thu, 7 May 2015 10:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=uFGwP/Mjm4WtKh15/ETyl70NHaM=; b=DU70VBTFSTQ5UlLrX bUDL8Kh2qcVgMCggw6pHQ/DcUrTjaWJvvGB0QGGXECT81PEgfISCbiwBO5QHK1Z8 SYWrohncs487t44SkYxwgODA9gpIKTfRmCLAVMY8UaR1tOTTXdBZYO7gnQ2vFGE+ zuKapSPkgxQdTz+3W+EUAe2SD8= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 8B4B627BC05D for ; Thu, 7 May 2015 10:08:03 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 7 May 2015 10:08:04 -0700 Message-ID: In-Reply-To: <20150507155147.GO17272@mournblade.imrryr.org> References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507155147.GO17272@mournblade.imrryr.org> Date: Thu, 7 May 2015 10:08:04 -0700 From: "Ryan Sleevi" To: tls@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 17:08:20 -0000 On Thu, May 7, 2015 8:51 am, Viktor Dukhovni wrote: > I summary, the only thing that could be tweaked is the requirement > to order the intermediate certificates. The first MUST and final > MAY are correct as they stand. And I think that the second MUST > is a fine example of Postel's principle. Tolerance by many clients > of servers that ignore the requirement does not invalidate the > requirement. To the extent this problem was caused (largely) by browsers, it's a problem that could (largely) be solved by browsers. The root cause I think is best captured by the fact that we don't have an X.500 directory, and thus RFC 2459/3280/5280 have never been sufficient t= o work in isolation because there's no notion of a global, shared trust store for who is authoritative and all of the trust relationships. Instead, we have the ad-hoc trust stores of major software vendors, and you find them in various different states through time and versions (e.g. the massive amounts of cross-signing that go on for CAs like Symantec-Verisign, StartCom, or Verizon-(GTE/Baltimore) Cybertrust) The disconnect exists because the TLS and X.509 subsystems are disconnected (as they reasonably can be), with TLS opting for RFC 5246 (and earlier), and X.509 clients needing to implement something like RFC 4158. In an RFC 4158 world, your inputs of intermediate CAs are unsorted = ( https://tools.ietf.org/html/rfc4158#section-2.7.2 ) - and may even be ignored ( https://tools.ietf.org/html/rfc4158#section-3.5.10 ) These sections aren't specs-leading-implementations - the leading implementations of path building were already doing what the spec merely documented after-the-fact. If a client wanted to ensure RFC 5246 compliance, it would need to explicitly add code to test that - coupling the TLS and X.509 implementations more tightly. In recent years, with the necessary attention on PKI, more clients (not exclusively browsers, but especially browsers) are bringing their PKI/X.509 implementations closer to their TLS implementations, and maybe this coupling isn't so bad. In an ideal world, I'd prefer the second MUST remain a MUST, because it makes implementing a TLS + RFC 5280 validator easier (e.g. without *requiring* an RFC 4158 discovery phase). However, in a pragmatic world, because major clients implement RFC 4158-like behaviours, and because in the changing landscape of CA hierarchies (both through acquisitions, but also through the deprecation of weak crypto like SHA-1 or RSA-1024 bit keys and the adoption of stronger crypto, such as ECC), it's increasingly necessary to implement something like RFC 4158 to work on the Internet at large, changing the second MUST to a SHOULD seems imminently sensible and reflects the realit= y today and going forward. The first MUST should remain - I can't see how any sane client would or could avoid that. The final MAY is also necessary/correct, judging by how the Web PKI actually works (plus the whole "self-issued for key rollover" captured in https://tools.ietf.org/html/rfc5280#section-6.1 that makes it problematic for a client to determine whether or not the 'root CA' is actually a 'self-issued for key rollover' intermediate) There's always the possibility that as browsers become increasingly proactive in communicating 'bad' (misconfigured), 'insecure', and 'sub-optimal' configurations, we'll find a world where major clients can safely and correctly *enforce* the 5246 behaviour as part of encouraging good server hygiene... From nobody Thu May 7 10:51:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118FC1ACE77 for ; Thu, 7 May 2015 10:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-5, 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 qK_FLH7rY2sx for ; Thu, 7 May 2015 10:51:38 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257E41ACE49 for ; Thu, 7 May 2015 10:51:38 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 30FFD2AB58; Thu, 7 May 2015 19:51:36 +0200 (CEST) X-purgate-ID: 152705::1431021096-00005316-EC567911/0/0 X-purgate-size: 2249 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id DB86443A82; Thu, 7 May 2015 19:51:35 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CEE581B2DA; Thu, 7 May 2015 19:51:35 +0200 (CEST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann Date: Thu, 7 May 2015 19:51:35 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150507175135.CEE581B2DA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 17:51:40 -0000 Peter Gutmann wrote: > Martin Rex writes: >> >>PKCS#7/CMS uses a Issuer&Serial (or alternatively SKI) to clearly identify >>the end-entity certificate. In TLS, the identification is the first position >>in certificate_list. So it is not possible to "blindly reuse" the code with >>respect to identifying the end-entity certificate. > > Yes it is, as I mentioned in my previous message my code looks for the server > FQDN/whatever and uses the cert that contains that as the leaf cert. It's the > same process that's used for IssuerAndSerialNumber, SCEP client IDs, and > various other things, "find the cert for the identified party, then follow > parent links to build the chain". I'm sorry, but I fail to understand what you mean. The TLS protocol layer explicitly has no business whatsoever with names in certificates, that has been spelled out clearly in all existing TLS specs. A TLS client should not know or care about the hostname of the server it is talking to, and there is no requirement what kind of stuff is contained in the server's certificate. Our TLS client does _not_ know the server's hostname (it gets a connected socket). https://tools.ietf.org/html/rfc5246#page-5 the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates *> exchanged are left to the judgment of the designers and implementors *> of protocols that run on top of TLS. As I said, it is impossible for the client to use the PKCS#7/CMS approach to locate the client certificate. The Definition of the TLS Certificate PDU has always contained this paragraph: https://tools.ietf.org/html/rfc6101#section-5.6.2 https://tools.ietf.org/html/rfc5246#page-48 Note: PKCS #7 [PKCS7] is not used as the format for the certificate vector because PKCS #6 [PKCS6] extended certificates are not used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task of parsing the list more difficult. Personally, I find it quite appalling how many broken TLS implementations out there fail to properly encode an ordered list of certificates into the Certificate handshake message. -Martin From nobody Thu May 7 11:35:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22541A87B2 for ; Thu, 7 May 2015 11:35: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 ueDvYFfPSMei for ; Thu, 7 May 2015 11:35:22 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 9204F1A1B51 for ; Thu, 7 May 2015 11:35:18 -0700 (PDT) Received: by qkx62 with SMTP id 62so33579014qkx.0 for ; Thu, 07 May 2015 11:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=wQkXwtXg9UmvDAYR+WWVn8EuxFD5oy7nemBhNOjaxUE=; b=mfDy6mmksSo1hgyC1F0lP2wjQGAYtePUWs8w1kG8QPtrXtTDt+tZIC7Nxw1gzh3w3Q anWweSTgncWBws5TXzz5ARf1jPGn6Pd257lBcH6hJgmHNF+WDK6myxog5u5os/FwDo7h PJAUGEq9SPZsW/TUtsxcBTcBepeMFsnclAgNeM9Ah5muHAHh2jXTLtY3PhlSRXuCAFMx muTYK1aNzMKANq7F6oP6GlemQ39+puZ9m1yW/yzeVLU0tkIx2fS3isWdl/Ph8PNrVgcq IKCYkyqJcAGiG7q1B349jbIUC2Mu6ujGL9+5sB6uYKWmd6e854XAhaDdwkWAh+lUz0rG /xgw== X-Received: by 10.140.17.50 with SMTP id 47mr539qgc.20.1431023717939; Thu, 07 May 2015 11:35:17 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id o90sm1926749qkh.25.2015.05.07.11.35.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 May 2015 11:35:17 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, ryan-ietftls@sleevi.com, Yoav Nir , mrex@sap.com, Peter Gutmann , Viktor Dukhovni Date: Thu, 7 May 2015 14:35:15 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507155147.GO17272@mournblade.imrryr.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505071435.15754.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 18:35:24 -0000 On Thursday, May 07, 2015 01:51:35 pm Martin Rex wrote: > Personally, I find it quite appalling how many broken TLS > implementations out there fail to properly encode an ordered list > of certificates into the Certificate handshake message. or more concisely: On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote: > Bleh. I think we're in fair agreement that this is sloppy, but it's sloppiness that should've been fixed long ago if we still wanted to fight it. I brought this issue up in response to a bug report for Firefox fully validating an EV cert list with an extra cert and things out of order. Mozilla and others seem to accept it just fine, so either the spec needs updating to reality or everyone should be adding new security errors to break it. The former makes more sense. On Thursday, May 07, 2015 01:08:04 pm Ryan Sleevi wrote: > The disconnect exists because the TLS and X.509 subsystems are > disconnected (as they reasonably can be), with TLS opting for RFC 5246 > (and earlier), and X.509 clients needing to implement something like RFC > 4158. In an RFC 4158 world, your inputs of intermediate CAs are unsorted ( > https://tools.ietf.org/html/rfc4158#section-2.7.2 ) - and may even be > ignored ( https://tools.ietf.org/html/rfc4158#section-3.5.10 ) [...] > In an ideal world, I'd prefer the second MUST remain a MUST, because it > makes implementing a TLS + RFC 5280 validator easier (e.g. without > *requiring* an RFC 4158 discovery phase). > > However, in a pragmatic world, because major clients implement RFC > 4158-like behaviours, and because in the changing landscape of CA > hierarchies (both through acquisitions, but also through the deprecation > of weak crypto like SHA-1 or RSA-1024 bit keys and the adoption of > stronger crypto, such as ECC), it's increasingly necessary to implement > something like RFC 4158 to work on the Internet at large, changing the > second MUST to a SHOULD seems imminently sensible and reflects the reality > today and going forward. > > The first MUST should remain - I can't see how any sane client would or > could avoid that. The final MAY is also necessary/correct, judging by how > the Web PKI actually works (plus the whole "self-issued for key rollover" > captured in https://tools.ietf.org/html/rfc5280#section-6.1 that makes it > problematic for a client to determine whether or not the 'root CA' is > actually a 'self-issued for key rollover' intermediate) Ok, so it looks like: 1) Fair bit of push-back against Peter's suggestion of relaxing the first MUST. 2) Begrudging agreement that the second MUST can be a SHOULD to match current realities. 3) The MAY shouldn't be a MUST, or SHOULD. Current: https://tools.ietf.org/html/rfc5246#section-7.4.2 certificate_list requirements draft 3a: ------------------------------------------------------------ certificate_list This is a list of certificates needed for authentication. The sender's certificate MUST come first in the list. Additional certificates needed to construct a valid certificate chain SHOULD be ordered by increasing scope of authority. (e.g. sender, intermediate(s), certificate authority) Root certificate authority certificates MAY be omitted from this list under the assumption that the peer possesses it in its trust store. ------------------------------------------------------------ This gets the 2119-ing as desired, with rewording to cover the reasoning needed to follow or not follow the SHOULD. certificate_list requirements draft 3b: ------------------------------------------------------------ certificate_list This is a list of certificates needed for authentication. The sender's certificate MUST come first in the list. Additional certificates needed to construct a valid certificate chain SHOULD be ordered by increasing scope of authority. (e.g. sender, intermediate(s), certificate authority) It is NOT RECOMMENDED to include root certificates that peers must already possess in order to validate the given chain. ------------------------------------------------------------ This rewords the CA cert part into a more clear recommendation. (i.e. more than a MAY, but not quite a SHOULD) Which, if either, of those two sounds good? Please also correct me if I've missed a subtlety here that needs to be taken into account. (or, or course, if I outright screwed something up ;) Dave From nobody Thu May 7 11:45:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCEF1AD082; Thu, 7 May 2015 11:45: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 xSEkgM3ltK9n; Thu, 7 May 2015 11:45:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5898A1ACF60; Thu, 7 May 2015 11:43:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150507184321.12750.6185.idtracker@ietfa.amsl.com> Date: Thu, 07 May 2015 11:43:21 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-falsestart-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 18:45:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) False Start Authors : Adam Langley Nagendra Modadugu Bodo Moeller Filename : draft-ietf-tls-falsestart-00.txt Pages : 11 Date : 2015-05-07 Abstract: This document specifies an optional behavior of TLS implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. The TLS False Start feature leads to a latency reduction of one round trip for certain handshakes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-falsestart-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 7 11:50:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223CC1A1B8E for ; Thu, 7 May 2015 11:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 qOyg5tdXblQO for ; Thu, 7 May 2015 11:50:26 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5F81A1A6B for ; Thu, 7 May 2015 11:50:26 -0700 (PDT) Received: from mail-la0-f42.google.com ([209.85.215.42]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0MVJlO-1YkPVO0uEw-00YhNn for ; Thu, 07 May 2015 20:50:24 +0200 Received: by layy10 with SMTP id y10so37381433lay.0 for ; Thu, 07 May 2015 11:50:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.161.66 with SMTP id xq2mr13787lbb.31.1431024622228; Thu, 07 May 2015 11:50:22 -0700 (PDT) Received: by 10.25.25.132 with HTTP; Thu, 7 May 2015 11:50:22 -0700 (PDT) In-Reply-To: <20150507184321.12750.6185.idtracker@ietfa.amsl.com> References: <20150507184321.12750.6185.idtracker@ietfa.amsl.com> Date: Thu, 7 May 2015 20:50:22 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3447e45df01051582626b X-Provags-ID: V03:K0:4uCRXe7UqzvNSDnVA2OwP6yhVt0+EIbMAsZPpWUF1WYgdVz7R/l PQq9yrlZ+7SlR5lsUN1Z7Mn+eXc4TGW5jmPrnv3N3+f4AJmzzOpkTISHv6h4An+Hz2L99ej J6JqvBF1ygX3kv3bh1u+wVW+LjUjrXi4IAmnZKS1JrIkHSiH8RyVuHbEGSII/yirdKIw+Y5 SUAeASnCt4bcBjSXqqyTQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-falsestart-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 18:50:28 -0000 --001a11c3447e45df01051582626b Content-Type: text/plain; charset=UTF-8 See https://www.ietf.org/mail-archive/web/tls/current/msg16193.html (and https://www.ietf.org/mail-archive/web/tls/current/msg16195.html :-/ ). Bodo 2015-05-07 20:43 GMT+02:00 : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security Working Group > of the IETF. > > Title : Transport Layer Security (TLS) False Start > Authors : Adam Langley > Nagendra Modadugu > Bodo Moeller > Filename : draft-ietf-tls-falsestart-00.txt > Pages : 11 > Date : 2015-05-07 > > Abstract: > This document specifies an optional behavior of TLS implementations, > dubbed False Start. It affects only protocol timing, not on-the-wire > protocol data, and can be implemented unilaterally. The TLS False > Start feature leads to a latency reduction of one round trip for > certain handshakes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tls-falsestart-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c3447e45df01051582626b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2015-05-07 = 20:43 GMT+02:00 <internet-drafts@ietf.org>:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Transport Layer Security Working Gro= up of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Transport Layer Security (TLS) False Start
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Adam= Langley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nagendra Modadugu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Bodo Moeller
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-falsestart-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-05-07

Abstract:
=C2=A0 =C2=A0This document specifies an optional behavior of TLS implementa= tions,
=C2=A0 =C2=A0dubbed False Start.=C2=A0 It affects only protocol timing, not= on-the-wire
=C2=A0 =C2=A0protocol data, and can be implemented unilaterally.=C2=A0 The = TLS False
=C2=A0 =C2=A0Start feature leads to a latency reduction of one round trip f= or
=C2=A0 =C2=A0certain handshakes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/<= /a>

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-falsestart-00

Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a11c3447e45df01051582626b-- From nobody Thu May 7 12:21:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878BB1A87CE for ; Thu, 7 May 2015 12:21:41 -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 adf-xHYFIvcZ for ; Thu, 7 May 2015 12:21:40 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001: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 F143D1A87C1 for ; Thu, 7 May 2015 12:21:39 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so2827372igb.0 for ; Thu, 07 May 2015 12:21:39 -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=rY1/yuT8d0f1EdJZFfKio2ieqVZ7vQ+o/YroF1n/0Uw=; b=SfPI2i/htrrCpTJpVQkM7bjKoOsLISXY8e8LNJEDpBF5IxAXjKvl/lbdEXvhCNX3KM INgx9jaL5x+HcUCQvsQ/lsG6wZqZPQ2qlW1qwxys85vc1h7Vt25Kfb8ojqh5X6BoJKUR wc1gn/W69V5bNbWLaesrAtwKbljT3HNCMnO04OnGwVXDe2wDBj/1QMLVNQYNboV+WfV5 sa1eSuaR1qxSXgOZUHMi4Fk/BZpE6n17kvH22EC+aUMm3mRJlARX0J6ECSB552ReWoYL oSdIPGqccvLsV79gw3a0JUroH0eM51Y80yJexRM4qmU8JegfYplbUUlxBgPjhhOXMNjz I+uQ== X-Received: by 10.42.213.136 with SMTP id gw8mr123844icb.95.1431026499461; Thu, 07 May 2015 12:21:39 -0700 (PDT) Received: from [10.0.1.4] (c-73-15-172-83.hsd1.ca.comcast.net. [73.15.172.83]) by mx.google.com with ESMTPSA id o2sm2160802igr.9.2015.05.07.12.21.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 May 2015 12:21:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fabrice Gautier X-Mailer: iPhone Mail (12H93) In-Reply-To: <201505071435.15754.davemgarrett@gmail.com> Date: Thu, 7 May 2015 12:21:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507155147.GO17272@mournblade.imrryr.org> <201505071435.15754.davemgarrett@gmail.com> To: Dave Garrett Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 19:21:41 -0000 > On May 7, 2015, at 11:35, Dave Garrett wrote: >=20 > so either the spec needs updating to reality or everyone should be adding n= ew security errors to break it. The former makes more sense. How about fixing the servers ? -- Fabrice= From nobody Thu May 7 13:18:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976791A92DE for ; Thu, 7 May 2015 13:18:37 -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 91VmjulFSIxU for ; Thu, 7 May 2015 13:18: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 9ABFC1A86F3 for ; Thu, 7 May 2015 13:18:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F38E3283031; Thu, 7 May 2015 20:18:33 +0000 (UTC) Date: Thu, 7 May 2015 20:18:33 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150507201833.GY17272@mournblade.imrryr.org> References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507155147.GO17272@mournblade.imrryr.org> <201505071435.15754.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201505071435.15754.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:18:37 -0000 On Thu, May 07, 2015 at 02:35:15PM -0400, Dave Garrett wrote: > Current: https://tools.ietf.org/html/rfc5246#section-7.4.2 > > certificate_list requirements draft 3a: > ------------------------------------------------------------ > certificate_list > This is a list of certificates needed for authentication. > The sender's certificate MUST come first in the list. > Additional certificates needed to construct a valid certificate > chain SHOULD be ordered by increasing scope of authority. > (e.g. sender, intermediate(s), certificate authority) > Root certificate authority certificates MAY be omitted from > this list under the assumption that the peer possesses it > in its trust store. > ------------------------------------------------------------ That's mostly fine (singular/plural conflict), though one might clarify the MAY further: certificate_list This is a list of certificates needed for authentication. The sender's certificate MUST come first in the list. Additional certificates needed to construct a valid certificate chain SHOULD be ordered by increasing scope of authority. (e.g. sender, intermediate(s), certificate authority). Root certificate authority certificates MAY be omitted from the list, provided supported peers are known to possesses any omitted certificates they may require in their trust stores. (When DANE-TA(2) trust-anchors are self-signed roots, they MUST not be omitted [draft-ietf-dane-ops]). Note, [draft-ietf-dane-ops] will be an RFC long before TLS 1.3 is done. > certificate_list requirements draft 3b: > ------------------------------------------------------------ > certificate_list > This is a list of certificates needed for authentication. > The sender's certificate MUST come first in the list. > Additional certificates needed to construct a valid certificate > chain SHOULD be ordered by increasing scope of authority. > (e.g. sender, intermediate(s), certificate authority) > It is NOT RECOMMENDED to include root certificates that > peers must already possess in order to validate the > given chain. > ------------------------------------------------------------ I think, that's still too strong. Note that often the chain construction is done by a library that augments the server leaf certificate with additional certificaets from the server's trust store, and this code does not know whether the root is needed in the chain or not. -- Viktor. From nobody Thu May 7 14:27:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861531B2C23 for ; Thu, 7 May 2015 14:27:17 -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 NnKbtOLlZyVB for ; Thu, 7 May 2015 14:27:16 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441551B2B48 for ; Thu, 7 May 2015 14:25:23 -0700 (PDT) Received: by yhcb70 with SMTP id b70so14626366yhc.0 for ; Thu, 07 May 2015 14:25:22 -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=Q/BsMuvbfvGHWej4WotTyjoaS1sGmrTLGR44DLjcIB4=; b=IrwKlsb6Bk3N2EYR9maOQ/qj8OkVoM8SKIoSU5fIMhz5JR6TwGY9eSlC7vH8JGRsY5 lGPhVUBcvmfxLlZbe1A06Tf5ebuyrhK/S8If7ZJnTHMCBdxq89wrtf9mzYxmij96i+Ht pGc779q9lAbu/L1U3rwN5uu+Ht8+c6sXvIirTtNINaNlb1ppl0GhlaoAMQK5r7KSZM8h Gi6mtNbd6CkqQYu15whjAwFlu6UZeVfVoBOJDoTMeUA7GKnLDZFrqPZGsPWK5HghaP4M a7PiIIZPgY5cqQ6Xho0KgSqJC0+d73g0uLFsxXaXOauP2edxpd4nihAOJQ6G/NbAcPuM WIGQ== MIME-Version: 1.0 X-Received: by 10.170.121.214 with SMTP id n205mr571130ykb.98.1431033922605; Thu, 07 May 2015 14:25:22 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Thu, 7 May 2015 14:25:22 -0700 (PDT) In-Reply-To: References: <20150506101230.32573.26774.idtracker@ietfa.amsl.com> Date: Thu, 7 May 2015 16:25:22 -0500 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-ieft-tls-falsestart-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 21:27:17 -0000 On 7 May 2015 at 10:24, Bodo Moeller wrote: > Sending client certs in the clear may not be a good idea, but that issue > seems entirely orthogonal to what False Start is all about. Do you see an > actual problem about sending a client's signing cert specifically in a False > Start handshake? If a client is willing to send their certificate in the clear, I see no reason to prevent them from sending this during False Start. The main risk with False Start is that the server has an increased risk of being impersonated. But the certificate is in the clear, so it's unclear what a client could lose by this. It's different if they were holding out for TLS 1.3 in the hopes that they might have confidentiality for the certificate. But that's a stack problem more than anything else. A stack might be configured for client certificate confidentiality and use TLS 1.3, or TLS <= 1.2 and renegotiation to accomplish that end depending on the ServerHello that it sees. If the client certificate is to be enciphered in an immediate renegotiation handshake, and both initial and renegotiation use False Start, the client should probably check the Finished message on the first before completing the renegotiation. Unless there are issues delaying the Finished delivery, the client should have that prior to when it needs to send the certificate. From nobody Thu May 7 14:37:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3271B2B2C for ; Thu, 7 May 2015 14:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 s7Htq8B_UnZE for ; Thu, 7 May 2015 14:37:40 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D78AF1B2B3D for ; Thu, 7 May 2015 14:37:40 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 45F4794065 for ; Thu, 7 May 2015 14:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=aiecN4yua3QTlXoeFvSg8yehCJw=; b=tgEaecqNyXxMfDD2P 6v8DpmbBo8uqIbMtLVmZayIkFDnSJjASRt9SkNEvKUkgtxxATuq8MfNIAmYmK8uu 0lv7tMFfQ/FlvZVMA1z1k7ottz4l32a6FW4BzmpAD8VxY9prfCuUhp+3t3qpVeef NkmcOm82BEy+1wGqZ0/piDVCL4= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 8DA139406D for ; Thu, 7 May 2015 14:37:37 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 7 May 2015 14:37:40 -0700 Message-ID: In-Reply-To: <20150507201833.GY17272@mournblade.imrryr.org> References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507155147.GO17272@mournblade.imrryr.org> <201505071435.15754.davemgarrett@gmail.com> <20150507201833.GY17272@mournblade.imrryr.org> Date: Thu, 7 May 2015 14:37:40 -0700 From: "Ryan Sleevi" To: tls@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 21:37:42 -0000 On Thu, May 7, 2015 1:18 pm, Viktor Dukhovni wrote: > That's mostly fine (singular/plural conflict), though one might > clarify the MAY further: > > certificate_list > This is a list of certificates needed for authentication. > The sender's certificate MUST come first in the list. Additional > certificates needed to construct a valid certificate chain > SHOULD be ordered by increasing scope of authority. (e.g. > sender, intermediate(s), certificate authority). Root > certificate authority certificates MAY be omitted from the > list, provided supported peers are known to possesses any > omitted certificates they may require in their trust stores. > (When DANE-TA(2) trust-anchors are self-signed roots, they > MUST not be omitted [draft-ietf-dane-ops]). While I appreciate the attentiveness to DANE's needs, it seems unnecessar= y to specify profile-specific details in the TLS specification, much in the same way we don't discuss profile-specific aspects of ciphersuite negotiations or the like. That is, I consider DANE-TA(2) trust anchors as a profile of how the TLS exchange works, not an intrinsic property that belongs in this spec. Regarding Dave's suggested rewording on the additional certificates, I think there's actually sizable ambiguity with respect to the terms chosen (sender, intermediate(s), certificate authority) that the original language is much clearer and less ambiguous on. At the risk of a bike-shed, I'll throw my contribution in, which aligns closer to the existing language, save for avoiding the notion of "root certificate authority certificates" in favour of the RFC 5280 term of trust anchor, which need not necessarily be a certificate. Functionally, this is equivalent, but hopefully provides clearer understanding. This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate SHOULD directly certify the one preceding it. Because certificate validation requires that trust anchors be distributed independently, a self-signed certificate that specifies the trust anchor MAY be omitted from the chain, provided supported peers are known to possess any omitted certificates they may require. So, for the DANE-TA(2) trust-anchor form, it requires that the trust anchor be express as a self-signed certificate, and is not possessed by the peer, ergo the MAY doesn't apply and the peer MUST send the certificate. But it avoids the cross-reference to a particular trust validation method. From nobody Thu May 7 14:45:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EE91ACE09 for ; Thu, 7 May 2015 14:45:06 -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 Bjn9ocC-o910 for ; Thu, 7 May 2015 14:45: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 718FF1B29BF for ; Thu, 7 May 2015 14:45:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6A255283031; Thu, 7 May 2015 21:45:03 +0000 (UTC) Date: Thu, 7 May 2015 21:45:03 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150507214503.GB17272@mournblade.imrryr.org> References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507155147.GO17272@mournblade.imrryr.org> <201505071435.15754.davemgarrett@gmail.com> <20150507201833.GY17272@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: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 21:45:06 -0000 On Thu, May 07, 2015 at 02:37:40PM -0700, Ryan Sleevi wrote: > On Thu, May 7, 2015 1:18 pm, Viktor Dukhovni wrote: > > That's mostly fine (singular/plural conflict), though one might > > clarify the MAY further: > > > > certificate_list > > This is a list of certificates needed for authentication. > > The sender's certificate MUST come first in the list. Additional > > certificates needed to construct a valid certificate chain > > SHOULD be ordered by increasing scope of authority. (e.g. > > sender, intermediate(s), certificate authority). Root > > certificate authority certificates MAY be omitted from the > > list, provided supported peers are known to possesses any > > omitted certificates they may require in their trust stores. > > (When DANE-TA(2) trust-anchors are self-signed roots, they > > MUST not be omitted [draft-ietf-dane-ops]). > > While I appreciate the attentiveness to DANE's needs, it seems unnecessary > to specify profile-specific details in the TLS specification, much in the > same way we don't discuss profile-specific aspects of ciphersuite > negotiations or the like. That is, I consider DANE-TA(2) trust anchors as > a profile of how the TLS exchange works, not an intrinsic property that > belongs in this spec. Sure, the parenthetical is by way of a "footnote", and can be droppped. The key point is the preceding sentence. > This is a sequence (chain) of certificates. The sender's certificate > MUST come first in the list. Each following certificate SHOULD > directly certify the one preceding it. Because certificate validation > requires that trust anchors be distributed independently, a > self-signed certificate that specifies the trust anchor MAY be omitted > from the chain, provided supported peers are known to possess any > omitted certificates they may require. Works for me. > So, for the DANE-TA(2) trust-anchor form, it requires that the trust > anchor be express as a self-signed certificate, and is not possessed by > the peer, ergo the MAY doesn't apply and the peer MUST send the > certificate. But it avoids the cross-reference to a particular trust > validation method. No problem, I had no major issues with the current MAY, and this new language improves on it by covering the essential caveat. -- Viktor. From nobody Thu May 7 15:49:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C561B2A07 for ; Thu, 7 May 2015 15:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2znMxnJ6MS10 for ; Thu, 7 May 2015 15:49:56 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC4C1B29BC for ; Thu, 7 May 2015 15:49:56 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 3173333D1E6; Thu, 7 May 2015 22:49:55 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Yoav Nir References: <201505062313.06092.davemgarrett@gmail.com> <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com> From: Geoffrey Keating Date: 07 May 2015 15:49:55 -0700 In-Reply-To: <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com> Message-ID: Lines: 59 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 22:49:57 -0000 Yoav Nir writes: > Hi, Dave >=20 > > On May 7, 2015, at 6:13 AM, Dave Garrett wrote: > >=20 > > https://tools.ietf.org/html/rfc5246#section-7.4.2 > > ---------------------------------------------------------------------- > > certificate_list > > This is a sequence (chain) of certificates. The sender's > > certificate MUST come first in the list. Each following > > certificate MUST directly certify the one preceding it. Because > > certificate validation requires that root keys be distributed > > independently, the self-signed certificate that specifies the root > > certificate authority MAY be omitted from the chain, under the > > assumption that the remote end must already possess it in order to > > validate it in any case. > > ---------------------------------------------------------------------- > >=20 > > It seems that in practice, nobody cares about that second "MUST=E2=80= =9D. >=20 > It=E2=80=99s not that nobody cares about that second MUST. It=E2=80=99s j= ust that we=E2=80=99ve learned the hard way that a lot of servers get it wr= ong, so we anyway had to run the whole chain-sorting/chain-completing code = anyway. >=20 > > https://bugzilla.mozilla.org/show_bug.cgi?id=3D619445#c1 > >=20 > > I'd like to propose simply changing that second "MUST" to a "SHOULD" or= possibly even a "RECOMMENDED", thus allowing for clients to accept cert ch= ains in different orderings as they already seem to do. (no change proposed= for the first "MUST=E2=80=9D) I'd like to see wording as follows: This is a sequence of certificates. The sender's certificate MUST come first in the list. The remaining certificates MAY be used by the client to establish trust in the first certificate. The sender SHOULD order these remaining certificates so that each certificate is used to establish trust in a certificate earlier in the order, and so that its preferred certificates are listed first. This answers the problem of multiple certificate paths, and doesn't prevent re-ordering by the client, and also allows the server to guide the client to the chain it prefers, which is important in some circumstances. For example, one chain might support EV, and another might be necessary for older clients, but both might be valid in some clients; the server would want to guide the client to the EV chain if it will work. Another alternative would be to say This is a sequence of certificates. The sender's certificates MUST come first in the list. The remaining certificates MAY be used by the client to establish trust in one of the sender's certificates. The sender SHOULD order these remaining certificates so that each certificate is used to establish trust in a certificate earlier in the order, and so that its preferred certificates are listed first. This explicitly allows the sender to send multiple certificates for itself, which would simplify a bunch of problems; SNI is no longer necessary (but still desirable), and it's no longer necessary to negotiate the certificate signing algorithms. From nobody Thu May 7 15:51:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DAE1B2BF9 for ; Thu, 7 May 2015 15:51: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 hcRTZemsFqL9 for ; Thu, 7 May 2015 15:51:02 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 BC8AA1B2BF7 for ; Thu, 7 May 2015 15:51:01 -0700 (PDT) Received: by qgfi89 with SMTP id i89so28762288qgf.1 for ; Thu, 07 May 2015 15:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=1zEYYFJGzKpjlG9TzN4q7FLZjHaSc4AexQdhk2oE770=; b=TeTGXBCW69kaV53BjGZ7QNWPtl5XhQBAOPfuw354mvZCnNXbUerD57mb0rHXtf2SOs TUm9zJV0sAvRmVIS9Ks2TfgosB3//cSwO4FM8jo9kz6torVKY+CD9yd89gt5KDIQ3tqH 77/iSDKHGF382uiwZOE/arFXeJGK+vmdtse4LjO8KId9i2EB92DHYzE/C3/02z1sdna6 Xt2dytsx57DUuLPrq/2XaqJOhScV3kCjutnBluEHy+sqeDRwUDEkjI3EgF4dHEf/7lBF XkK30dVxBS1rwimMw9nRZG4Mv1O5g2pDI3R+TzqWlTxaMggHiDEXDDH5r5qxGqwKvIz1 crrg== X-Received: by 10.140.43.100 with SMTP id d91mr1296950qga.77.1431039061061; Thu, 07 May 2015 15:51:01 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id h14sm2367058qhc.46.2015.05.07.15.51.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 May 2015 15:51:00 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, ryan-ietftls@sleevi.com Date: Thu, 7 May 2015 18:46:51 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507201833.GY17272@mournblade.imrryr.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505071846.52147.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 22:51:03 -0000 On Thursday, May 07, 2015 05:37:40 pm Ryan Sleevi wrote: > At the risk of a bike-shed, I'll throw my contribution in, which aligns > closer to the existing language, save for avoiding the notion of "root > certificate authority certificates" in favour of the RFC 5280 term of > trust anchor, which need not necessarily be a certificate. Functionally, > this is equivalent, but hopefully provides clearer understanding. > > This is a sequence (chain) of certificates. The sender's certificate > MUST come first in the list. Each following certificate SHOULD > directly certify the one preceding it. Because certificate validation > requires that trust anchors be distributed independently, a > self-signed certificate that specifies the trust anchor MAY be omitted > from the chain, provided supported peers are known to possess any > omitted certificates they may require. > > So, for the DANE-TA(2) trust-anchor form, it requires that the trust > anchor be express as a self-signed certificate, and is not possessed by > the peer, ergo the MAY doesn't apply and the peer MUST send the > certificate. But it avoids the cross-reference to a particular trust > validation method. "Trust anchor" is notably better, yes. However, the language of "directly certify the one preceding it" is problematic with multiple intermediates. I was looking to have the wording be more general to provide expectations there. I think the simplest way to resolve this might be to just drop usage of the word "the" here. So: This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate SHOULD directly certify one preceding it. Because certificate validation requires that trust anchors be distributed independently, a self-signed certificate that specifies a trust anchor MAY be omitted from the chain, provided supported peers are known to possess any omitted certificates they may require. This has the same ordering expectations as the more significant rewordings, but is very similar to the current language. Dave From nobody Thu May 7 21:51:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FCA1A8993 for ; Thu, 7 May 2015 21:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 MY5Bu1f3O5Iv for ; Thu, 7 May 2015 21:51:55 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 52B951A8982 for ; Thu, 7 May 2015 21:51:55 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id E0AD0678063; Thu, 7 May 2015 21:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=+SSqgtiktkCe073/E4tYC0GtjvQ=; b=KJB3YtEif75WEWo8g T1hRGNkt88U9VFNHJ493vbVgpfak5Kg4wFy/kWOsoqVOwTqlZWrTb3IrAf6stNHW reuG+c1PDtoKccL0fWbbMFAPRe7cohhNctDtEKy3UafMybVtWCyxNv3diFwJj0gj kJ3bqp7t4oPOrLWxGaJgtGAWyI= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 9212D678062; Thu, 7 May 2015 21:51:54 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 7 May 2015 21:51:53 -0700 Message-ID: In-Reply-To: References: <201505062313.06092.davemgarrett@gmail.com> <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com> Date: Thu, 7 May 2015 21:51:53 -0700 From: "Ryan Sleevi" To: "Geoffrey Keating" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 04:51:56 -0000 On Thu, May 7, 2015 3:49 pm, Geoffrey Keating wrote: > This answers the problem of multiple certificate paths, and doesn't > prevent re-ordering by the client, and also allows the server to guide > the client to the chain it prefers, which is important in some > circumstances. For example, one chain might support EV, and another > might be necessary for older clients, but both might be valid in some > clients; the server would want to guide the client to the EV chain if > it will work. The problem I have with that proposal is it conflicts with RFC 4158 and conflicts with client practice [at least, those most likely to be encountered at the web at large, in the context of HTTPS] That is, yes, it's true, you can totally send based on the server's preference, but there is zero obligation for the client to respect that preference - and indeed, no clients that support path discovery (rather than just path building) that I've observed actually would respect such a= n order. That is, they do RFC 4158 style optimizations, ranging from cachin= g the certificate validation path to using application-determined preferences (ranging from issuance date, key strength, etc) This sort of goes back to it being a change to the path building APIs to accommodate such language - the same reason that the current MUST is ignored. (Yes, I'm aware that libraries that simply perform path _verification_ - notably, OS X's & iOS's Security.framework and OpenSSL & derivatives - would implicitly respect such preferences. But they also fail fairly miserably at dealing with the Web PKI, as evidenced by OS X's repeated issues whenever there is a CA cross-signing or rollover, which has been quite common the past few years, so I don't particularly consider their behaviours emblematic of good behaviours) Admittedly, it's harmless language from a client implementation side - bu= t I fear that by describing it as such, it sets up an indirect expectation for servers and readers that clients SHOULD respect such ordering, when there is no such requirement and it'd be even more work to do than the current MUST. From nobody Fri May 8 05:23:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDE91B2A89 for ; Fri, 8 May 2015 05:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uPnSr9aTCQr for ; Fri, 8 May 2015 05:23:42 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::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 AEA891B2A11 for ; Fri, 8 May 2015 05:23:42 -0700 (PDT) Received: by qcbgu10 with SMTP id gu10so35892062qcb.2 for ; Fri, 08 May 2015 05:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fGskV1R47YFCz3/P/3rwrc7bd/DWhKhgIt3JuoMwc8k=; b=BzL7nqm14JNBZC+iRhvNrg0HX/QXxyeMBc/z/he9l94ojS9NjtBjbe4239DalS5CVY qHA1/8jQE25xxIzpb/4ZpZQ/mvrhUGdjelVj9s7O9k5GXh0MALrd7vOotTFTVbzDcr5D EHhXTvQiIbfIip7wt4dKEbamMw4cq6REH2nKTz8zMniBYBbPHuh8bSfhJQn8AErmJyzh neUWAw7GAjydKeHtcfGzobkq5Vlag4uBIwvK1rV8Vzn6TAI9vfmZVB9UqxlvOqmHuZUY RZJWLAaVy6ssY3MWuNZ0VTsz1Zb24eYMHPv+vu760ltx1Z0miDS7gU7iKUnhlQxh3Tcm pMbA== 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=fGskV1R47YFCz3/P/3rwrc7bd/DWhKhgIt3JuoMwc8k=; b=MGm4OrEG6b6bFuNAtSmnO0dX6/x7jpabm7YmvNdL7ICxt5Cqjzd3NCT8Et+0iwn+OG hgOS1+oIwRbZtZutk+372SqY386Vc+ia6GFZL2R0XZaIaaOWc6KGxfAmhhImVJGVTCug UKrajce9tQfVIyoJ+4zJPn1XDVyZuDTu82RM5kXW3w+rZ8I4l2RX0DJbV6n2DNIjGgSX CQHYVckd9YG0xJW7Yts8vcpwwkqwZgthzB1C+uNAYIq9g0orviwHBma1UIlJ+A2eErrI yORFtd345kQDwhRNbdr3mun2ovHLWIy4reatkkgSanXZkSbwB1DNnxm6eYzzDLZnL6fZ HsLQ== X-Gm-Message-State: ALoCoQk8pOWEsgqVlIOLJ72ixgj2s86aSUg0L7ksszD04PL5JuodnGoyj2TNhIuoj0fNkgrtrxus MIME-Version: 1.0 X-Received: by 10.140.92.51 with SMTP id a48mr4405187qge.30.1431087821912; Fri, 08 May 2015 05:23:41 -0700 (PDT) Received: by 10.229.155.138 with HTTP; Fri, 8 May 2015 05:23:41 -0700 (PDT) In-Reply-To: <201505062313.06092.davemgarrett@gmail.com> References: <201505062313.06092.davemgarrett@gmail.com> Date: Fri, 8 May 2015 13:23:41 +0100 Message-ID: From: Ben Laurie To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 12:23:44 -0000 On 7 May 2015 at 04:13, Dave Garrett wrote: > https://tools.ietf.org/html/rfc5246#section-7.4.2 > ---------------------------------------------------------------------- > certificate_list > This is a sequence (chain) of certificates. The sender's > certificate MUST come first in the list. Each following > certificate MUST directly certify the one preceding it. Because > certificate validation requires that root keys be distributed > independently, the self-signed certificate that specifies the root > certificate authority MAY be omitted from the chain, under the > assumption that the remote end must already possess it in order to > validate it in any case. > ---------------------------------------------------------------------- > > It seems that in practice, nobody cares about that second "MUST". > > https://bugzilla.mozilla.org/show_bug.cgi?id=619445#c1 > > I'd like to propose simply changing that second "MUST" to a "SHOULD" or possibly even a "RECOMMENDED", thus allowing for clients to accept cert chains in different orderings as they already seem to do. (no change proposed for the first "MUST") No thanks. Let's not encourage bad practices. For a start, if you relax the requirement you allow for ambiguous chains. > I think there was also discussion on this list at some point suggesting changing that "MAY" for omitting the root CA cert to a "SHOULD" or a "MUST". (I think the argument for the latter was to reduce wasted bandwidth) > > Any reason this would be problematic? It'd be a simple change to add for the TLS 1.3 spec that would align things better with real-world usage. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 8 07:19:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F111A1B84 for ; Fri, 8 May 2015 07:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, 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 n3Hn6zX_c4Uy for ; Fri, 8 May 2015 07:19:28 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B871A1B86 for ; Fri, 8 May 2015 07:19:28 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 4834D44C19; Fri, 8 May 2015 16:19:26 +0200 (CEST) X-purgate-ID: 152705::1431094766-00000B48-9273206D/0/0 X-purgate-size: 2366 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 284D443EC7; Fri, 8 May 2015 16:19:26 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1C16A1B2DE; Fri, 8 May 2015 16:19:26 +0200 (CEST) In-Reply-To: <201505071435.15754.davemgarrett@gmail.com> To: Dave Garrett Date: Fri, 8 May 2015 16:19:26 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 14:19:31 -0000 Dave Garrett wrote: > On Thursday, May 07, 2015 01:51:35 pm Martin Rex wrote: >> Personally, I find it quite appalling how many broken TLS >> implementations out there fail to properly encode an ordered list >> of certificates into the Certificate handshake message. > > or more concisely: > > On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote: >> Bleh. > > I think we're in fair agreement that this is sloppy, but it's sloppiness > that should've been fixed long ago if we still wanted to fight it. > > I brought this issue up in response to a bug report for Firefox fully > validating an EV cert list with an extra cert and things out of order. > Mozilla and others seem to accept it just fine, so either the spec > needs updating to reality or everyone should be adding new security > errors to break it. The former makes more sense. No, the former is clearly detrimental. Browsers, which haved added fancy colors and stuff to address bars for EV certs, really ought to punish servers sending bogus Certificate handshake messages by reducing the color feedback to mere black&white and not attributes (_not_ produce a warning! I believe the Google Chrome 42 behaviour for sha1-Signatures is totally wrong, because hardly anyone understands what the real issue is, and Chrome will not tell you which signature algorithms in which certs it is unsatisfied with). I believe that one of the causes why the problem exists at all is a lack of sensible PKI credential management on the server side. Properly done, the PKI software on the server side will refuse installation of a server certificate with an incomplete certification path directly to the administrator who is trying to install the certificate. The only person who can "fix" such a configuration error is the server admin, so the admin (a) should get to see that error and (b) get to see it upfront, even before starting a server with a bogus configuration. After successful server certificate chain verification (normally on maintenance operations on a server's PKI credential, or for servers lacking PKI credentials management, at least once on server start) the correct ordering of certificates is known, and that known ordering can then be used for thousands/millions of TLS handshakes without wasting any further CPU cycles. -Martin From nobody Fri May 8 07:51:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973A41A893B for ; Fri, 8 May 2015 07:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQI3RYOV9cqQ for ; Fri, 8 May 2015 07:51:14 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) (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 92C241A895E for ; Fri, 8 May 2015 07:51:13 -0700 (PDT) Received: from Morgan.missi.ncsc.mil (morgan.missi.ncsc.mil [144.51.60.155]) by stingray.missi.ncsc.mil with ESMTP id t48EpAuK030925 for ; Fri, 8 May 2015 10:51:10 -0400 (EDT) Received: from PINTO.missi.ncsc.mil ([fe80::60c7:cec6:b35c:deed]) by Morgan.missi.ncsc.mil ([::1]) with mapi id 14.03.0210.002; Fri, 8 May 2015 10:51:10 -0400 From: "Kemp, David P." To: "tls@ietf.org" Thread-Topic: [TLS] Update spec to match current practices for certificate chain order Thread-Index: AQHQiZn8GsXTU1lDEU6QPCBLhUKLhZ1yJW3w Date: Fri, 8 May 2015 14:51:09 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8D7F62F04@PINTO.missi.ncsc.mil> References: <201505071435.15754.davemgarrett@gmail.com> <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> In-Reply-To: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.60.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 14:51:16 -0000 There is nothing wrong with the client accepting a bag 'o certs that is 1) = incomplete, 2) has extra certs, or 3) has the exact number of certs in the = exact order needed to chain back to a server-trusted root, as long as the c= lient can validate a path back to a client-trusted root (using either cache= d or fetched certs if the bag doesn't work). PKIX specifies validation req= uirements that do not require servers to send anything, and sending a full = path with every handshake is an efficiency gain for the first connection bu= t a waste for all the rest. Servers can be strict in what they send by sending a server-trusted path in= chaining order as you suggest. But clients that cannot construct a valid= path on their own if the server's doesn't satisfy them are insufficiently = liberal. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex Sent: Friday, May 08, 2015 10:19 AM To: Dave Garrett Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate c= hain order Dave Garrett wrote: > On Thursday, May 07, 2015 01:51:35 pm Martin Rex wrote: >> Personally, I find it quite appalling how many broken TLS=20 >> implementations out there fail to properly encode an ordered list of=20 >> certificates into the Certificate handshake message. >=20 > or more concisely: >=20 > On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote: >> Bleh. >=20 > I think we're in fair agreement that this is sloppy, but it's=20 > sloppiness that should've been fixed long ago if we still wanted to fight= it. >=20 > I brought this issue up in response to a bug report for Firefox fully=20 > validating an EV cert list with an extra cert and things out of order. > Mozilla and others seem to accept it just fine, so either the spec=20 > needs updating to reality or everyone should be adding new security=20 > errors to break it. The former makes more sense. No, the former is clearly detrimental. Browsers, which haved added fancy colors and stuff to address bars for EV c= erts, really ought to punish servers sending bogus Certificate handshake me= ssages by reducing the color feedback to mere black&white and not attribute= s (_not_ produce a warning! I believe the Google Chrome 42 behaviour for s= ha1-Signatures is totally wrong, because hardly anyone understands what the= real issue is, and Chrome will not tell you which signature algorithms in = which certs it is unsatisfied with). I believe that one of the causes why the problem exists at all is a lack of= sensible PKI credential management on the server side. Properly done, the PKI software on the server side will refuse installation= of a server certificate with an incomplete certification path directly to = the administrator who is trying to install the certificate. The only person who can "fix" such a configuration error is the server admi= n, so the admin (a) should get to see that error and (b) get to see it upfr= ont, even before starting a server with a bogus configuration. After successful server certificate chain verification (normally on mainten= ance operations on a server's PKI credential, or for servers lacking PKI cr= edentials management, at least once on server start) the correct ordering o= f certificates is known, and that known ordering can then be used for thous= ands/millions of TLS handshakes without wasting any further CPU cycles. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 8 08:04:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D10C1A8A83 for ; Fri, 8 May 2015 08:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 FbhBfHcDU6d1 for ; Fri, 8 May 2015 08:04:01 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE421A8A89 for ; Fri, 8 May 2015 08:04:01 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id F3DFB2B030; Fri, 8 May 2015 17:03:58 +0200 (CEST) X-purgate-ID: 152705::1431097439-00000B48-19D04732/0/0 X-purgate-size: 2674 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id E3DFF43F1E; Fri, 8 May 2015 17:03:58 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id D695F1B2DE; Fri, 8 May 2015 17:03:58 +0200 (CEST) In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC8D7F62F04@PINTO.missi.ncsc.mil> To: "Kemp, David P." Date: Fri, 8 May 2015 17:03:58 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150508150358.D695F1B2DE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 15:04:03 -0000 Kemp, David P. wrote: > There is nothing wrong with the client accepting a bag 'o certs that > is 1) incomplete, 2) has extra certs, or 3) has the exact number of > certs in the exact order needed to chain back to a server-trusted > root, as long as the client can validate a path back to a > client-trusted root (using either cached or fetched certs if the > bag doesn't work). This is the TLS WG mailing list and the TLS protocol. You might be confusing this discussion with PKIX and CMS. None of what you enumerate applies to the TLS Certificate handshake message, because this carries well-explained MUSTs. > > PKIX specifies validation requirements that > do not require servers to send anything, and sending a full path > with every handshake is an efficiency gain for the first connection > but a waste for all the rest. For PKIX (rfc5280), the building of a certification path has been EXPLICITLY declared "out of scope", and it is pretty normal for TLS peers to not contain any kind of path building functionality and not to know more than "trust anchors" for verification of certificate chains provided by peers. What we're looking at here, is **interoperability** requirements. > > Servers can be strict in what they send by sending a server-trusted > path in chaining order as you suggest. This is an obvious misunderstanding of the TLS specification and the requirements keyword MUST: https://tools.ietf.org/html/rfc2119#section-1 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. Sending a complete and ordered certificate chain in the "certificate_list" element of the TLS Server Certificate handshake message is not an option, is is an "ABSOLUTE REQUIREMENT". > > But clients that cannot construct a valid path on their own if the > server's doesn't satisfy them are insufficiently liberal. Clients do not have to accomodate server that violate MUSTS. In most cases, it is detrimental and often dangerous to work around such protocol violations by the peer. And if all of what the client has is a very short list of trust anchors (in the optimal and safe configuration just one single trust anchor), then there is nothing besides a simple reordering and duplicate cert elimination that a sensible client can do about a misconfigured server that is using a defective TLS implementation. Either the certification path presented by the server crosses through the trust anchor(s) of the client or ends there -- then you get interop, or it doesn't then you get interop failure. -Martin From nobody Fri May 8 08:19:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4131A8A8E for ; Fri, 8 May 2015 08:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s1aSieQtDGk for ; Fri, 8 May 2015 08:19:28 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) (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 9EB381A8925 for ; Fri, 8 May 2015 08:19:28 -0700 (PDT) Received: from Morgan.missi.ncsc.mil (morgan.missi.ncsc.mil [144.51.60.155]) by stingray.missi.ncsc.mil with ESMTP id t48FJRpb031198 for ; Fri, 8 May 2015 11:19:27 -0400 (EDT) Received: from PINTO.missi.ncsc.mil ([fe80::60c7:cec6:b35c:deed]) by Morgan.missi.ncsc.mil ([::1]) with mapi id 14.03.0210.002; Fri, 8 May 2015 11:19:27 -0400 From: "Kemp, David P." To: "tls@ietf.org" Thread-Topic: [TLS] Update spec to match current practices for certificate chain order Thread-Index: AQHQiZn8GsXTU1lDEU6QPCBLhUKLhZ1yJW3wgABK2AD//74qcA== Date: Fri, 8 May 2015 15:19:26 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8D7F63F2A@PINTO.missi.ncsc.mil> References: <5B1D7E570380A64989D4C069F7D14BC8D7F62F04@PINTO.missi.ncsc.mil> <20150508150358.D695F1B2DE@ld9781.wdf.sap.corp> In-Reply-To: <20150508150358.D695F1B2DE@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.60.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 15:19:30 -0000 Martin Rex wrote: > Clients do not have to accomodate server that violate MUSTS. Absolutely correct. Accommodating a compliant server is the only mandator= y to implement requirement on clients. > In most cases, it is detrimental and often dangerous to work around > such protocol violations by the peer. How ??? > Either the certification path presented by the server crosses through > the trust anchor(s) of the client or ends there -- then you get interop, > or it doesn't then you get interop failure. Clients that provide value-added (optional) path construction functionality= do not fail, either operationally or security-wise. Perhaps no such clie= nts exist, now or in the future. But if they do, satisfying more than the = MUSTS does not make them non-compliant. From nobody Fri May 8 08:30:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59D21A026E for ; Fri, 8 May 2015 08:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_55=0.6, 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 kkW0RTPoQM_7 for ; Fri, 8 May 2015 08:29:59 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 987761A020B for ; Fri, 8 May 2015 08:29:59 -0700 (PDT) Received: by qkx62 with SMTP id 62so50300248qkx.0 for ; Fri, 08 May 2015 08:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=VUghM739rHBGoTUtqO+9lTVKUrA3784CJVRDQN4VqL0=; b=hOD0dUm6sPCfOuGiURItPWRQuyPGtnUdKlNuqisAILTxQGYuP8fH2eOLmucdQdpt8u v3XNRy5+uG8JuRIK+UA2zClRPdT5BvB+BnIzIUc/86LPwbePhCXWE0zVgrs9NWrjhmag DIBH5U+XE9+RSnyJjhtZszGh6PNh2WoXtdWoTsL4fE0v8cjgkMWUZhaAumvPpDqea9Um mPnUz+1ywb3qvNDjhXU662Q3vTtdeUB5jmlyAL6WU8CuI1+wfMqdfw9r75SIcL4TOXyc CjaoxFf1AraOvh5bH9c/UEpwsOBpshritUdvBQMUyONN/+1zJ5sJA1RaqHN6joq3dWd2 kmBg== X-Received: by 10.140.108.74 with SMTP id i68mr5543549qgf.73.1431098998627; Fri, 08 May 2015 08:29:58 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id f131sm3783810qhc.47.2015.05.08.08.29.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 May 2015 08:29:58 -0700 (PDT) From: Dave Garrett To: mrex@sap.com Date: Fri, 8 May 2015 11:29:56 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> In-Reply-To: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505081129.57194.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 15:30:01 -0000 On Friday, May 08, 2015 10:19:26 am Martin Rex wrote: > Dave Garrett wrote: > > On Thursday, May 07, 2015 01:51:35 pm Martin Rex wrote: > >> Personally, I find it quite appalling how many broken TLS > >> implementations out there fail to properly encode an ordered list > >> of certificates into the Certificate handshake message. > > > > or more concisely: > > > > On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote: > >> Bleh. > > > > I think we're in fair agreement that this is sloppy, but it's sloppiness > > that should've been fixed long ago if we still wanted to fight it. > > > > I brought this issue up in response to a bug report for Firefox fully > > validating an EV cert list with an extra cert and things out of order. > > Mozilla and others seem to accept it just fine, so either the spec > > needs updating to reality or everyone should be adding new security > > errors to break it. The former makes more sense. > > No, the former is clearly detrimental. > > Browsers, which haved added fancy colors and stuff to address bars > for EV certs, really ought to punish servers sending bogus Certificate > handshake messages by reducing the color feedback to mere black&white > and not attributes (_not_ produce a warning! I believe the Google > Chrome 42 behaviour for sha1-Signatures is totally wrong, because > hardly anyone understands what the real issue is, and Chrome will > not tell you which signature algorithms in which certs it is unsatisfied > with). Let me be clear: I don't fundamentally disagree with you. I think that protocols should be treated far more strictly than they tend to be and stuff like this should be a mandatory error if it's against the current spec. That said, if we step ~way~ far back, we're sort of hitting a standard human societal problem: given a problem, and a set of solutions, arguing for the ideal you can't get is an argument for the problem. Do you think we could compel every browser vendor to apply this (effectively) new standard uniformly, and make the changes all at the same time? I don't, especially not from the TLS spec. Vendors can't even drop critically insecure protocols in unison. I don't even have confidence that everyone could coordinate a token change of coloring in the UI for this one narrow case. This is a wire format issue, rather than a security one, so as long as we have an accepted format that is secure, then it doesn't really matter beyond that. I would agree that browsers should probably throw a warning into their consoles for this sort of thing, but not a user-facing action. Of all the problems TLS has, this is not one I think is worth worrying about too much. ;) > I believe that one of the causes why the problem exists at all > is a lack of sensible PKI credential management on the server side. Likely true, but outside of the current scope of action. Dave From nobody Fri May 8 08:35:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF2C1A903B for ; Fri, 8 May 2015 08:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 cp6yYWfkkM1V for ; Fri, 8 May 2015 08:35:39 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC231A903C for ; Fri, 8 May 2015 08:35:39 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id C0B4044C93; Fri, 8 May 2015 17:35:37 +0200 (CEST) X-purgate-ID: 152705::1431099337-00005316-89CE321C/0/0 X-purgate-size: 1630 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id B053043EDB; Fri, 8 May 2015 17:35:37 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A5A791B2DE; Fri, 8 May 2015 17:35:37 +0200 (CEST) In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC8D7F63F2A@PINTO.missi.ncsc.mil> To: "Kemp, David P." Date: Fri, 8 May 2015 17:35:37 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150508153537.A5A791B2DE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 15:35:41 -0000 Kemp, David P. wrote: > Martin Rex wrote: >> Clients do not have to accomodate server that violate MUSTS. > > Absolutely correct. Accommodating a compliant server is the > only mandatory to implement requirement on clients. > >> In most cases, it is detrimental and often dangerous to work around >> such protocol violations by the peer. > > How ??? Detrimental because it hides a server configuration error that can only be fixed on the server. The resulting behaviour of the end-user becomes seemingly non-deterministic. It may work with some clients and not work with others, and it may work after having been to other servers, but not directly after reboot. Just crazy. > >> Either the certification path presented by the server crosses through >> the trust anchor(s) of the client or ends there -- then you get interop, >> or it doesn't then you get interop failure. > > Clients that provide value-added (optional) path construction > functionality do not fail, either operationally or security-wise. I've seen epic failures here before. Such as chasing AIA for missing intermediate certs (not having a trusted cert store that contains it). That's a real security goof, and it was implemented by some clients. > > Perhaps no such clients exist, now or in the future. But if they do, > satisfying more than the MUSTS does not make them non-compliant. For a number implementors, convenience is more important than security, and they will skip anything that is difficult. Such as skipping certificate and certicate path validation for the peer completely. -Martin From nobody Fri May 8 08:41:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718DE1A9097 for ; Fri, 8 May 2015 08:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 3Ip1jHAdnwWH for ; Fri, 8 May 2015 08:41:14 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DDD1A9092 for ; Fri, 8 May 2015 08:41:14 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 124572B003; Fri, 8 May 2015 17:41:13 +0200 (CEST) X-purgate-ID: 152705::1431099673-0000413A-0DACEFC9/0/0 X-purgate-size: 618 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 0009643E7A; Fri, 8 May 2015 17:41:12 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id E84E51B2DE; Fri, 8 May 2015 17:41:12 +0200 (CEST) In-Reply-To: <20150508153537.A5A791B2DE@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Fri, 8 May 2015 17:41:12 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150508154112.E84E51B2DE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 15:41:15 -0000 Fixing typo (I'm sorry, I should have reviewed before sending): Martin Rex wrote: > Kemp, David P. wrote: >> Martin Rex wrote: >> >>> In most cases, it is detrimental and often dangerous to work around >>> such protocol violations by the peer. >> >> How ??? Detrimental because it hides a server configuration error that can only be fixed on the server. The resulting behaviour for the end-user becomes seemingly non-deterministic. It may work with some clients and not work with others, and it may work after having been to other servers, but not directly after reboot. Just crazy. -Martin From nobody Fri May 8 08:51:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180191A9235 for ; Fri, 8 May 2015 08:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 bbr7g94s5vfk for ; Fri, 8 May 2015 08:51:57 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7611A90A2 for ; Fri, 8 May 2015 08:51:57 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 46F942AFFA; Fri, 8 May 2015 17:51:56 +0200 (CEST) X-purgate-ID: 152705::1431100316-00000B48-7EB6F153/0/0 X-purgate-size: 931 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3489843EED; Fri, 8 May 2015 17:51:56 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2AF6F1B2DE; Fri, 8 May 2015 17:51:56 +0200 (CEST) In-Reply-To: To: Geoffrey Keating Date: Fri, 8 May 2015 17:51:56 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150508155156.2AF6F1B2DE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 15:51:59 -0000 The _existing_ description of the Contents of the TLS Certificate handshake message is among the few things that I really like in the TLS specification, and I believe that none of the proposed changes improves it, but many break it, or break it badly. Geoffrey Keating wrote: > > This explicitly allows the sender to send multiple certificates for > itself, which would simplify a bunch of problems; SNI is no longer > necessary (but still desirable), and it's no longer necessary to > negotiate the certificate signing algorithms. Huh??? This doesn't compute. There is just one digitally-signed object (or static RSA key exchange in TLS up to v1.2), so there is no "choice" among multiple server certificates. And every sensibly managed public CA ought to refuse signing the same public key for different names/identities/attributes (i.e. issuing different certs with the same public key). -Martin From nobody Fri May 8 13:18:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943791A8F45 for ; Fri, 8 May 2015 13:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g2IXYJQk1Dm for ; Fri, 8 May 2015 13:18:06 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F641A8F3F for ; Fri, 8 May 2015 13:18:06 -0700 (PDT) Received: from [10.0.69.63] (athyra.geoffk.org [198.0.208.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dragaera.releasedominatrix.com (Postfix) with ESMTP id C929533D04C; Fri, 8 May 2015 20:18:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Geoff Keating In-Reply-To: <20150508155156.2AF6F1B2DE@ld9781.wdf.sap.corp> Date: Fri, 8 May 2015 13:18:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150508155156.2AF6F1B2DE@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 20:18:09 -0000 > On 8 May 2015, at 8:51 am, Martin Rex wrote: > Geoffrey Keating wrote: >>=20 >> This explicitly allows the sender to send multiple certificates for >> itself, which would simplify a bunch of problems; SNI is no longer >> necessary (but still desirable), and it's no longer necessary to >> negotiate the certificate signing algorithms. >=20 > Huh??? >=20 > This doesn't compute. There is just one digitally-signed object > (or static RSA key exchange in TLS up to v1.2), so there is no > "choice" among multiple server certificates. There can be multiple certificates with the same public key, but = different subject identification.= From nobody Fri May 8 14:10:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5811A0052 for ; Fri, 8 May 2015 14:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 kvxjwtLuz5dG for ; Fri, 8 May 2015 14:10:22 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8951A002A for ; Fri, 8 May 2015 14:10:21 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id E308726408B; Fri, 8 May 2015 14:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=wkIPUusqAjj3N8jJ2B7Clr8WPVU=; b=USDtR+3ygI+RfbCdv rfWG+jWZVoa2Kf+i+i92GzSe/toM0ho7JXwxkKqT1NUhYy3j8qMgqFTcyi/3yEro +Kz1+Uyi9auJ8E9wRCBm+xYd5WtSOeoOeGi8PvwTX2xaeJYGxX6c06iQpU3Q8CpL ma7cekEEV+mJ0GfzCW1kDztjD0= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPA id DFA1E2640B4; Fri, 8 May 2015 14:10:18 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 8 May 2015 14:10:19 -0700 Message-ID: <20ca33d85bfab861c8e8f4dd60a607ee.squirrel@webmail.dreamhost.com> In-Reply-To: <201505081129.57194.davemgarrett@gmail.com> References: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> <201505081129.57194.davemgarrett@gmail.com> Date: Fri, 8 May 2015 14:10:19 -0700 From: "Ryan Sleevi" To: "Dave Garrett" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 21:10:29 -0000 On Fri, May 8, 2015 8:29 am, Dave Garrett wrote: > Let me be clear: I don't fundamentally disagree with you. While I have great respect for Martin, I do disagree and think he's fundamentally wrong here, for the reasons I already explained in my first message as to why what he's asking is not only *wrong*, but *unwise* and an unnecessary coupling of two intentionally-independent layers. > Do you > think we could compel every browser vendor to apply this (effectively)= new > standard uniformly, and make the changes all at the same time? As I said elsewhere, requiring ordering might be something browsers do in the future, but it's fundamentally coupling two things which are explicitly decoupled (and better off so) > I don't, > especially not from the TLS spec. Vendors can't even drop critically > insecure protocols in unison. I don't even have confidence that everyo= ne > could coordinate a token change of coloring in the UI for this one nar= row > case. And of course, coloring is the unquestionably wrong answer here from a usability study. It's not so much a bikeshed discussion as demonstrably bad for users and homeopathic cybersecurity :) > > I believe that one of the causes why the problem exists at all > > is a lack of sensible PKI credential management on the server side. > > Likely true, but outside of the current scope of action. The only way in which this protocol could have worked as described is in an X.500 world that no one should reasonably/sanely want. Outside of that= , we're talking about tradeoffs and compromise, and those are both sensible and necessary, so I agree wholeheartedly here :) From nobody Fri May 8 14:34:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13711A19F0 for ; Fri, 8 May 2015 14:34:51 -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 wp5jWs66Z6Pj for ; Fri, 8 May 2015 14:34:50 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 334471A0A6A for ; Fri, 8 May 2015 14:34:50 -0700 (PDT) Received: by qgdy78 with SMTP id y78so42984535qgd.0 for ; Fri, 08 May 2015 14:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=keoi3ONH5e/NENsBD7J16cDYsJeDTLqXqMHWqUKYl4w=; b=uNJ4gA6JNJTdKUdmxvPO/IZJWa5a0pciC0xs4hwna7a1A2WpATmy9Zz+8mnpHeguVR WEdUowHP7OdD3ojF0Rc8U5TE7CCLyx409lEZYFewtwAgDlgtRk2U/sfZAaMY6tgw511a AvwPzCWyIMFDOx9mIjyjmt4tzBnS2RELuwd7SUf0HYY6JKXQ+CZt525nmdgOd0A8w+5R DShph4IqbLKSVJPt5FbcMQptze5YRh8SbwdOdi8Q3rhRHhxutBDqZpl8ZnvMvpdNQ8tT puGuc9E/12Q9nY2qxIkpXwchkAsI9Fw8ax9l/jK+8EowcqGXy7ikaYnknILSKEDDq+7M Ar+Q== X-Received: by 10.140.100.200 with SMTP id s66mr58840qge.1.1431120889327; Fri, 08 May 2015 14:34:49 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id f131sm4446564qhc.47.2015.05.08.14.34.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 May 2015 14:34:48 -0700 (PDT) From: Dave Garrett To: ryan-ietftls@sleevi.com Date: Fri, 8 May 2015 17:34:47 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> <201505081129.57194.davemgarrett@gmail.com> <20ca33d85bfab861c8e8f4dd60a607ee.squirrel@webmail.dreamhost.com> In-Reply-To: <20ca33d85bfab861c8e8f4dd60a607ee.squirrel@webmail.dreamhost.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505081734.47783.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 21:34:51 -0000 On Friday, May 08, 2015 05:10:19 pm Ryan Sleevi wrote: > On Fri, May 8, 2015 8:29 am, Dave Garrett wrote: > > Let me be clear: I don't fundamentally disagree with you. > > While I have great respect for Martin, I do disagree and think he's > fundamentally wrong here, for the reasons I already explained in my first > message as to why what he's asking is not only *wrong*, but *unwise* and > an unnecessary coupling of two intentionally-independent layers. This is a two decade old set of security standards. If you want any strict separation of layers, you're going to need to start from scratch. (which we're hopefully doing soon with something QUIC based) Anything other than acknowledging this current situation as a mess and doing what you can where you can (e.g. HPKP) is not really practical. Wise as it may be to try to keep things decoupled, it's not the current reality. > And of course, coloring is the unquestionably wrong answer here from a > usability study. It's wrong just from a biological perspective, seeing how colorblindness of various forms is not uncommon. Dave From nobody Fri May 8 14:53:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F0A1A1A66 for ; Fri, 8 May 2015 14:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 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_NONE=-0.0001] 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 3DnxzUYjqF-o for ; Fri, 8 May 2015 14:53:35 -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 A49741A1A57 for ; Fri, 8 May 2015 14:53:35 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 7ED38200D9F9D; Fri, 8 May 2015 14:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=5FRY0ESmwpucRSPm8+yy/hq1ylE=; b=GsNx48R4KEi6i9h6M u2OdDVsmclUQ+t8QgeQRpiE2DpqEW72t+fTt9BnxS3YA8Utzpxv5dwpfQwmfTX/a wlYA2Hja/QSyZyVvhs0BV9rVkv4k1pXGHFAvipjNTFVNmkFlFx8Oinn6IGyHs661 OL9Zu/60yQa1/etLyaLg/xPrXw= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPA id 76F2D200D9F8D; Fri, 8 May 2015 14:53:34 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 8 May 2015 14:53:34 -0700 Message-ID: <7dd89312e9234c911e27edd81b2686d0.squirrel@webmail.dreamhost.com> In-Reply-To: <201505081734.47783.davemgarrett@gmail.com> References: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> <201505081129.57194.davemgarrett@gmail.com> <20ca33d85bfab861c8e8f4dd60a607ee.squirrel@webmail.dreamhost.com> <201505081734.47783.davemgarrett@gmail.com> Date: Fri, 8 May 2015 14:53:34 -0700 From: "Ryan Sleevi" To: "Dave Garrett" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 21:53:36 -0000 On Fri, May 8, 2015 2:34 pm, Dave Garrett wrote: > This is a two decade old set of security standards. If you want any st= rict > separation of layers, you're going to need to start from scratch. (whi= ch > we're > hopefully doing soon with something QUIC based) Anything other than > acknowledging this current situation as a mess and doing what you can > where you can (e.g. HPKP) is not really practical. > > Wise as it may be to try to keep things decoupled, it's not the curren= t > reality. I think you've misunderstood me. Hopefully a re-read of the original message will provide clarity. The "problem" caused is precisely *because* the layers are decoupled. To satisfy Martin's requirement (e.g. at a browser), you would necessarily *need* to couple the layers. And while it's true that browser's internal implementations have begun to blur the layers such that a tight coupling may not be entirely unreasonable, they are *not* coupled to the degree necessary to satisfy the second MUST, which is why we're in the present state. So by accepting the status quo and having the spec updated to reflect that, we agree that the decoupling/loose coupling is good. By changing clients to enforce the second MUST, we promote more coupling at the clients. That's not good in my view. From nobody Fri May 8 16:07:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B7E1A871E for ; Fri, 8 May 2015 16:07:58 -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 FA6HGA5B6Lvr for ; Fri, 8 May 2015 16:07:57 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09AB01A871A for ; Fri, 8 May 2015 16:07:49 -0700 (PDT) Received: by qku63 with SMTP id 63so58001467qku.3 for ; Fri, 08 May 2015 16:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=G0BbqF73XjDA9drk4cdFjj2hGWEJY4kNQMm3+08lKto=; b=BaNVloWEUfLX8nxAhK1NkDA9ZqGW3b8My4bQLyh+onm/4yCR/l0dJF7QDTGV8/n5zr eMvoFPepJnt9qAK9Tu4tCsdXh2wFhJLd1V8zCceHBVFut/KqMYjdX9vu8IEKy6nxGT4I MG2MIJeEiuuhRxbVaKQNYVFWY12LcCQXECkCgjtBPtGJWgR2+LmZw0miDgheaI9H5x7f 8xuiDPUTd42Kmv6Es/2na5QhomMkHGeJ3zsjVUDs0fFmfevWXz7IJQKrOpBXFJccHePG 2BhFOzSp6lgoK9YAZr0iDUdH2JmdumPTUOl+ROkWPhfbe5vNXlUtsds4z+yiIu4Alyj1 wFMQ== X-Received: by 10.55.51.141 with SMTP id z135mr762522qkz.84.1431126468267; Fri, 08 May 2015 16:07:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 143sm4619318qhw.21.2015.05.08.16.07.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 May 2015 16:07:47 -0700 (PDT) From: Dave Garrett To: ryan-ietftls@sleevi.com Date: Fri, 8 May 2015 19:07:46 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> <201505081734.47783.davemgarrett@gmail.com> <7dd89312e9234c911e27edd81b2686d0.squirrel@webmail.dreamhost.com> In-Reply-To: <7dd89312e9234c911e27edd81b2686d0.squirrel@webmail.dreamhost.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505081907.46745.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 23:07:58 -0000 On Friday, May 08, 2015 05:53:34 pm Ryan Sleevi wrote: > I think you've misunderstood me. I think we've both misunderstood each other a bit, which unfortunately tends to happen sometimes with larger responses and quotes. I'll be brief, as we're veering off-topic a bit. > So by accepting the status quo and having the spec updated to reflect > that, we agree that the decoupling/loose coupling is good. Yes, in this case. > By changing clients to enforce the second MUST, we promote more coupling > at the clients. That's not good in my view. What I was saying that I "don't fundamentally disagree" with is the notion that ideally the second MUST should be enforced more strictly. This is not a clean system where we can expect layers to be loosely coupled. We're just long past the point where this is realistic, and in this case strictness wouldn't give us any direct benefit. Dave From nobody Fri May 8 16:35:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2E1A871E for ; Fri, 8 May 2015 16:35:17 -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 g6r-DkL-W7AW for ; Fri, 8 May 2015 16:35:15 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 AFF141A871A for ; Fri, 8 May 2015 16:35:15 -0700 (PDT) Received: by qku63 with SMTP id 63so58265783qku.3 for ; Fri, 08 May 2015 16:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:message-id; bh=LuG+qzSKrwTpkdUVbjnnpOCwt7P0tFQ34cMTbxW/FpY=; b=CoUT6ouGwzn/NaqkmHv3xh95L45YgbQNHEHFHlkY08RDPJnTORKl+Zw6uLS0N+6h4U HzrTzwkGKHGKiGRbC/8b7/CmfCnArDeNCW//4hTIq738UD6aKBo6dm1HEF8295pJYcNw gGEQIeqUxabXin1+306NnpuAp5HentSm+BJb9vO1ykAKWddeYbO5HCT19KGBGNnHLWzt IuuOciOMkS9ugFkJaI3W75hbeLwbuxPMlre1c21m5Fhm90sxSi33TJtPIiFtDQ+MVPMV +7BCf8OZOnIZ9gB7YBe/b2vJ5/8tDRgtApOOK9TZEfZ0b7LPzc7e/xOZfy4UtDSk7Dxj ySGQ== X-Received: by 10.55.24.11 with SMTP id j11mr843938qkh.73.1431128114980; Fri, 08 May 2015 16:35:14 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id n13sm4672918qkh.8.2015.05.08.16.35.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 May 2015 16:35:14 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, ryan-ietftls@sleevi.com Date: Fri, 8 May 2015 19:35:13 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201505081935.13474.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 23:35:17 -0000 A PR with language based on this discussion: https://github.com/tlswg/tls13-spec/pull/169/files The text is mostly the same or similar, with the second "MUST" changed to a "SHOULD", and the term "trust anchor" replacing references to root keys/CA. Is this changeset acceptable? Dave From nobody Fri May 8 20:20:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7FC1A8A7E for ; Fri, 8 May 2015 20:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 JozKKle1VHT0 for ; Fri, 8 May 2015 20:20:38 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3415D1A8A67 for ; Fri, 8 May 2015 20:20:38 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3645C2AF60; Sat, 9 May 2015 05:20:36 +0200 (CEST) X-purgate-ID: 152705::1431141636-00005316-235CB2E8/0/0 X-purgate-size: 1741 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 11E1743E70; Sat, 9 May 2015 05:20:36 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 072AD1B2E2; Sat, 9 May 2015 05:20:36 +0200 (CEST) In-Reply-To: <201505081935.13474.davemgarrett@gmail.com> To: Dave Garrett Date: Sat, 9 May 2015 05:20:35 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 03:20:40 -0000 Dave Garrett wrote: > A PR with language based on this discussion: > https://github.com/tlswg/tls13-spec/pull/169/files > > The text is mostly the same or similar, with the second "MUST" changed > to a "SHOULD", and the term "trust anchor" replacing references to root > keys/CA. > > Is this changeset acceptable? I am violently opposed to this change. It creates new ambiguities, makes bogus, backwards-incompatible and interoperability-impairing behaviour appear less objectionable, while providing _zero_ benefit. The "original" requirements apply to the server's Certificate handshake message, i.e. which certificates and in what order the server is required to encode into the Server Certificate handshake message. The purpose of these requirements for the server is to facilitate the the client's job to verify the server's certificate, improve interoperability and create a predictable&deterministic client behaviour that should be independent from the particular client implementation as much as possible. Clients that are willing to perform unsafe path discovery on a Server's certificate handshake message will *NOT* be inconvenienced if the server puts the certificates in correct order and optionally omits only the self-signed rootCA certificate at the end. Clients that do not perform any fancy unsafe path discovery, on the other hand, may easily be non-interoperable with sloppy servers that do not properly compose their Server Certificate handshake message, and these Client are _not_ to blame for any resulting interop failure, because it is clearly the server TLS implementation that goofed when it produces a Server Certificate PDU that violates the MUSTs. -Martin From nobody Fri May 8 20:43:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE38B1A8AC5 for ; Fri, 8 May 2015 20:43:51 -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 gXGHDnUvE-sG for ; Fri, 8 May 2015 20:43:50 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8791A8ACB for ; Fri, 8 May 2015 20:43:50 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 79A8147B3B; Sat, 9 May 2015 03:43:49 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 6BBD347B47; Sat, 9 May 2015 03:43:49 +0000 (GMT) Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 677052030; Sat, 9 May 2015 03:43:49 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 8 May 2015 23:43:48 -0400 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.1076.000; Fri, 8 May 2015 23:43:48 -0400 From: "Salz, Rich" To: "mrex@sap.com" , Dave Garrett Thread-Topic: [TLS] Update spec to match current practices for certificate chain order Thread-Index: AQHQieehWirCHNDorkK9Q5tQbeeXFJ1zPXiA///DUeA= Date: Sat, 9 May 2015 03:43:47 +0000 Message-ID: <3b1c7847dbda4b3380c2ac7d4d17b9de@usma1ex-dag1mb2.msg.corp.akamai.com> References: <201505081935.13474.davemgarrett@gmail.com> <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> In-Reply-To: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> 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.57.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 03:43:52 -0000 I'm inclined to agree with Martin.=20 From nobody Fri May 8 20:51:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597881A8BC0 for ; Fri, 8 May 2015 20:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 Rz1VOv4GTnVC for ; Fri, 8 May 2015 20:51:51 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6C1A8BB1 for ; Fri, 8 May 2015 20:51:51 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id E40952F4071; Fri, 8 May 2015 20:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=7jP8b6OGr6I+Amue4St0wKjCSo4=; b=j7S7ePyk3sitBE2LZ v64auxTOxvMowxNzE3DZNZwVGGO51Q4yl/PNemEnzNttZsqrbG+AEDAFdmwkukei R7fy5UB+qX9dCycrCOR0XRPvDeg+S+NsuTWWMtjLgK+KJ3AW8MZgmnjR/fwTZVcK Ppa9GUE5KtXXg4P88ucFwtPhf0= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id B9A552F4065; Fri, 8 May 2015 20:51:50 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 8 May 2015 20:51:49 -0700 Message-ID: In-Reply-To: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> References: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> Date: Fri, 8 May 2015 20:51:49 -0700 From: "Ryan Sleevi" To: mrex@sap.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 03:51:52 -0000 On Fri, May 8, 2015 8:20 pm, Martin Rex wrote: > The purpose of these requirements for the server is to facilitate > the the client's job to verify the server's certificate, improve > interoperability and create a predictable&deterministic client > behaviour that should be independent from the particular client > implementation as much as possible. Of course, none of this has happened because the X.500 directory doesn't exist, each client's job also has to maintain an appropriate trust store, the server cannot know apriori what that trust store is unless it knows the client, and if it does know the client, it can know whether or not it supports a given behaviour. > Clients that are willing to perform unsafe path discovery on > a Server's certificate handshake message will *NOT* be inconvenienced > if the server puts the certificates in correct order and optionally > omits only the self-signed rootCA certificate at the end. I know nothing I say will dissuade you from calling it "unsafe path discovery", even though I rather vehemently disagree with you. I will simply point out, however, that were it not for this "unsafe path discovery", we would not finally be moving to a place where we might be able to turn off 1024-bit RSA keys used in intermediate and root certificates, because the PKI is hard and the Internet involves multiple stakeholders. > > Clients that do not perform any fancy unsafe path discovery, on the > other hand, may easily be non-interoperable with sloppy servers that > do not properly compose their Server Certificate handshake message, > and these Client are _not_ to blame for any resulting interop failure, > because it is clearly the server TLS implementation that goofed > when it produces a Server Certificate PDU that violates the MUSTs. If you're going to write a client that works on the Internet at large and is capable of moving at the speed of the Internet, the best I can say is "Cheer up and deal with it". Clients doing what you propose, rather than the thing you hate, hold Internet security back, so I'm not terribly sympathetic (e.g. https://access.redhat.com/articles/1413643 for the most recent example) While I realize it's just my opinion, in my role, any client that does what you state above I consider bugged and recommend against deploying. Because it either won't work on the Internet or, far more commonly, it will hold the people trying to secure it back, and in the process, hold the whole Internet hostage to their broken security. But c'est la vie. From nobody Fri May 8 21:49:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CD51A90E0 for ; Fri, 8 May 2015 21:49: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 c2eJkiErv-E9 for ; Fri, 8 May 2015 21:49:20 -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 E4A591A90DF for ; Fri, 8 May 2015 21:49:19 -0700 (PDT) Received: by qgfi89 with SMTP id i89so45956639qgf.1 for ; Fri, 08 May 2015 21:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=K1fbqS/q9nmg2x4IcYpHZJz0pbyLq3KWe/nDTxgQIHM=; b=xh2/3jyx9fJ92xId6QKAfPt0Zjq94nc5U+0T8Zj3MtIYmwobdxGqsw3wURkGte3AVS LPrRrHPRI0b1S+KhUt7NkgTJcblYJkfcJatc+hcyajBsNeuvgGGnw7kse7GcX38CcEiM efiQicYi8P+7Nbhuv1C1zo9K1jyux1kgvAsJMBwajqY+YKAITkpd8qaHMv3FaS5FLoeD z5PQoyOtHVRQTzzVfg5RPcrC4zs2TlFo1/ZXZNB6LRpfgaCAv1xIDEv2Kxe9ShkjdH80 Zh0GGIrva1u+4Yd2OL1RCzXUyeS7cRvIBP68ZazVMI7dTBl4r4xbifMefEsMhKDLGBHo z8Hg== X-Received: by 10.229.172.70 with SMTP id k6mr1632690qcz.10.1431146959063; Fri, 08 May 2015 21:49:19 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id l200sm5135582qhl.24.2015.05.08.21.49.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 May 2015 21:49:18 -0700 (PDT) From: Dave Garrett To: mrex@sap.com Date: Sat, 9 May 2015 00:49:16 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> In-Reply-To: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201505090049.17456.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 04:49:22 -0000 On Friday, May 08, 2015 11:20:35 pm Martin Rex wrote: > Dave Garrett wrote: > > A PR with language based on this discussion: > > https://github.com/tlswg/tls13-spec/pull/169/files > >=20 > > The text is mostly the same or similar, with the second "MUST" changed > > to a "SHOULD", and the term "trust anchor" replacing references to root > > keys/CA. > >=20 > > Is this changeset acceptable? >=20 > I am violently opposed to this change. >=20 > It creates new ambiguities, makes bogus, backwards-incompatible > and interoperability-impairing behaviour appear less objectionable, Yep, but it does convert interoperability-impairing behavior into interoper= able behavior. > while providing _zero_ benefit. It's not zero. Advantages: improved interoperability / implementation parity (like it or not) allows multiple intermediates for transitional capabilities Disadvantages: minor validation complexity increase (that already seems common) it's Wrong=E2=84=A2 > Clients that do not perform any fancy unsafe path discovery, on the =46ancy, maybe; unsafe, no. We're debating whether or not paperwork should = be accepted if page 3 was stapled between pages 1 and 2. In an ideal world,= no, but in a world after two decades of SSL/TLS... I don't care. The on-th= e-wire ordering is a minor technicality and there are legitimate use-cases = that need an update here, in addition to handling shoddy server implementat= ions. (Some server implementations seem to act like this because they leave= the specifics of ordering up to configuration by an admin that probably do= esn't know the spec.) See also Ryan's reply that cites the transitional issue in detail: https://www.ietf.org/mail-archive/web/tls/current/msg16226.html TL;DR: sanely phasing out 1024-bit RSA keys is dependent on this Also, you've attached the adjective "unsafe" to the terminology here withou= t providing a justification for doing so. Please explain a practical reason= why this would be unsafe and we might agree with you. If you can actually = show that this would be unsafe, and that mandating all clients to stop doin= g this and throw a fatal error is the best course of action, and can actual= ly get a consensus to this effect on this list, then I'd probably concur. A= s I said in a prior email in this thread, I'm generally in favor of strict = error enforcement when actually useful and properly coordinated. Arguing fo= r keeping the text as-is, however, is just ignoring the problem. {In case of possible misunderstanding: I do not ask rhetorical questions. I= 'm not being sarcastic and am genuinely curious if there is sufficient just= ification to consider this practice to be unsafe. I could see how it might = be risky for an already sloppy implementation to add support for, but I don= 't see how this feature itself makes this unsafe.} > other hand, may easily be non-interoperable with sloppy servers that > do not properly compose their Server Certificate handshake message, > and these Client are _not_ to blame for any resulting interop failure, > because it is clearly the server TLS implementation that goofed > when it produces a Server Certificate PDU that violates the MUSTs. Yes, very much so. *That is one of the primary reasons for this change.* Client implementers need to be given a heads-up that this is something they= need to account for, as this is already current practice. The proposed spe= c change is merely a documentation of this. Dave From nobody Fri May 8 22:34:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D001A910F for ; Fri, 8 May 2015 22:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmBRgBY2TF5O for ; Fri, 8 May 2015 22:34: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 5D35D1A910E for ; Fri, 8 May 2015 22:34:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F14F4283031; Sat, 9 May 2015 05:34:02 +0000 (UTC) Date: Sat, 9 May 2015 05:34:02 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150509053402.GN17272@mournblade.imrryr.org> References: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> <201505090049.17456.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201505090049.17456.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 05:34:09 -0000 On Sat, May 09, 2015 at 12:49:16AM -0400, Dave Garrett wrote: > > It creates new ambiguities, makes bogus, backwards-incompatible > > and interoperability-impairing behaviour appear less objectionable, > > Yep, but it does convert interoperability-impairing behavior into interoperable behavior. On the contrary, the currently required server behaviour is interoperable, and relaxing the rules is likely to reduce that interoperability if more servers violate the rules. The fact that many clients don't enforce the rules is not surprising, there is no Internet protocol police, and the spec does not require clients to enforce the rules. We must read the spec exclusively as a server requirement to order the chain. Client obligations in particular TLS applications may vary from application to application. Browsers may well jump through various hoops, and likely need to do so. Other applications do not. The world-wide-web is not the entire Internet, and browsers are not the only TLS-using applications. For example, Postfix (when configured to validate peer certificates via a set of local trust-anchors) does not tolerate missing intermediate certificates, the trust store it uses for this typically contains only self-signed trust-anchor certs. Yes, I know that the specific change of language is only about certificate order, and does not remove the requirement to send all the requisite certs. And in fact Postfix does tolerate out-of-order intermediates (because OpenSSL does). So my example is but an analogy, and does not *specifically* warrant retaining the order constraint, but other clients may be even more constrained, and that's OK for those particular applications. Nothing in the current server requirement precludes any client accomodations for servers that don't send the requisite chain. When those are appropriate, they can be employed. -- Viktor. From nobody Sat May 9 05:55:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7E71ACD0B for ; Sat, 9 May 2015 05:55:51 -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_40=-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 SfHZWSrUQkNo for ; Sat, 9 May 2015 05:55:47 -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 A07D21ACD0A for ; Sat, 9 May 2015 05:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1431176146; x=1462712146; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=UqqTucPR4zWkWNvb2yN1sf4RaSX07YD58lp8+SXZvxc=; b=c06u6O+TMNGykglPBc8ek8GxQQWQ5If4q9wEMtgv3cAQYqJjbNRnHCpj gnGY8Ngi3WrZX2rIZliL0SvBEEwcgk1XCushOllOvOfBKi6G2C6x1phSn zjj8UlUwMaIrUwdozY/fBSzlJTnLJzQ/weDH1y1dJLTCOy1+vjH72o7Tb 8=; X-IronPort-AV: E=Sophos;i="5.13,396,1427713200"; d="scan'208";a="3892852" 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; 10 May 2015 00:55:44 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 10 May 2015 00:55:43 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Update spec to match current practices for certificate chain order Thread-Index: AdCKV3UzODUTUzO2QVicmec9zXDrZw== Date: Sat, 9 May 2015 12:55:42 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB019AE1@uxcn10-tdc05.UoA.auckland.ac.nz> 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: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 12:55:51 -0000 Martin Rex writes:=0A= =0A= >A TLS client should not know or care about the hostname of the server it i= s=0A= >talking to, and there is no requirement what kind of stuff is contained in= =0A= >the server's certificate.=0A= =0A= Which is far too true, unfortunately, particularly among Android and iOS ap= ps,=0A= as recent research (e.g. "Why Eve and Mallory Love Android: An Analysis of= =0A= Android SSL (In)Security" and "The most dangerous code in the world:=0A= validating SSL certificates in non-browser software") has pointed out. Sti= ll,=0A= not caring whether the supposed www.bankofamerica.com presents a cert for= =0A= www.qwertyuiop.com doesn't strike me as a sound security strategy.=0A= =0A= >Our TLS client does _not_ know the server's hostname (it gets a connected= =0A= >socket).=0A= =0A= So it's like all the insecure Android and iOS apps?=0A= =0A= >I find it quite appalling how many broken TLS implementations out there fa= il=0A= >to properly encode an ordered list of certificates into the Certificate=0A= >handshake message.=0A= =0A= That's really small beans compared to the huge numbers of apps that don't c= are=0A= about what they're connecting to, one's a trivial (and arguably irrelevant)= =0A= protocol violation, the other is reducing the security of the TLS handshake= to=0A= anon-DH [0].=0A= =0A= Peter.=0A= =0A= [0] Whether browser PKI as currently practiced is much better than anon-DH = to=0A= begin with is a debate for a different mailing list :-).=0A= From nobody Sat May 9 06:09:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9915D1ACD12 for ; Sat, 9 May 2015 06:09:26 -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 ML7SAklbOXPr for ; Sat, 9 May 2015 06:09:24 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740141ACCD8 for ; Sat, 9 May 2015 06:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1431176964; x=1462712964; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=sMFocGkAZzhIhx7R3K37XjPGTGDhDr4Lz7nBheM3tDE=; b=HnhjBc3sh5HxoVlt2rQ4tuEZuoQLSLEpekMNh19Ug/U80bvfmAW9kdpZ OAioTxorIdYSM+q+I330qcuNZECA/EJGSZskaP3nuW0lTtTal4zm4ILAJ i/JzHfqQo+ID5H8/8ZflC+IwsSX8p959zImKP+DYQSn3N8E9snUA9ad2E U=; X-IronPort-AV: E=Sophos;i="5.13,396,1427713200"; d="scan'208";a="3893820" 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; 10 May 2015 01:09:15 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 10 May 2015 01:09:14 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Update spec to match current practices for certificate chain order Thread-Index: AdCKWVjP/Wn/1mVNQaGtvKPiHTh6MQ== Date: Sat, 9 May 2015 13:09:14 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB019B05@uxcn10-tdc05.UoA.auckland.ac.nz> 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: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 13:09:26 -0000 Martin Rex writes:=0A= =0A= >And every sensibly managed public CA ought to refuse signing the same publ= ic=0A= >key for different names/identities/attributes (i.e. issuing different cert= s=0A= >with the same public key).=0A= =0A= ITYM "No true Scotsman would sign the same public key for different=0A= names/identities/attributes".=0A= =0A= (Also, no sensibly managed public CA will issue certs for RFC 1918 addresse= s,=0A= unqualified domain names, "localhost", nonexistent domains, obviously bogus= =0A= domains like "your.server.address.com", and so on, so the tens of thousands= of=0A= certs like this that have been issued by public CAs must be a figment of ou= r=0A= imagination).=0A= =0A= Peter.= From nobody Sat May 9 15:52:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947201A1B65; Sat, 9 May 2015 15:52:50 -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 UOcd5wDY5eXw; Sat, 9 May 2015 15:52:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 419951A1B43; Sat, 9 May 2015 15:52:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150509225248.21800.83581.idtracker@ietfa.amsl.com> Date: Sat, 09 May 2015 15:52:48 -0700 Archived-At: Cc: draft-ietf-tls-session-hash@ietf.org, tls-chairs@ietf.org, draft-ietf-tls-session-hash.shepherd@ietf.org, draft-ietf-tls-session-hash.ad@ietf.org, tls@ietf.org Subject: [TLS] Barry Leiba's Discuss on draft-ietf-tls-session-hash-05: (with DISCUSS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 22:52:50 -0000 Barry Leiba has entered the following ballot position for draft-ietf-tls-session-hash-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a DISCUSS purely because I want to discuss it; whatever the result is, I will be clearing the DISCUSS, and not delaying the document on this point: The last paragraph of Section 4 makes me wonder whether this should "update" 5246. Basically, while this is an extension (which wouldn't normally use "updates"), it's one that you're proposing as standard behavior, and not really as an extension. From nobody Sun May 10 03:00:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85001B305F; Fri, 8 May 2015 14:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 4ZAGfSS52QGW; Fri, 8 May 2015 14:08:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F051ACEB6; Fri, 8 May 2015 14:08:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150508210811.2024.97744.idtracker@ietfa.amsl.com> Date: Fri, 08 May 2015 14:08:11 -0700 Archived-At: X-Mailman-Approved-At: Sun, 10 May 2015 03:00:37 -0700 Cc: draft-ietf-tls-session-hash@ietf.org, tls-chairs@ietf.org, draft-ietf-tls-session-hash.shepherd@ietf.org, draft-ietf-tls-session-hash.ad@ietf.org, tls@ietf.org Subject: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-session-hash-05: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 21:08:13 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-tls-session-hash-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for your work on this and a well-written draft! The considerations are very thorough, every time I had a question, I was able to find an answer in the draft. I do think a couple more references could be helpful though. 1. I think it would be good for section 6.4 to note that SSL 3.0 has been deprecated in https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ It's ahead of this draft in the RFC editor queue. 2. It might be good to have a pointer to the UTA TLS Attack RFC7457 as this attack is described in section 2.11 and there is no reference to a fix. It would be nice to show that known attacks are being resolved. https://tools.ietf.org/html/rfc7457#section-2.11 From nobody Mon May 11 04:29:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5867D1A3B9B for ; Mon, 11 May 2015 04:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4S9o9kfLZEh for ; Mon, 11 May 2015 04:28:55 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::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 A00CC1A007C for ; Mon, 11 May 2015 04:28:55 -0700 (PDT) Received: by qcbgy10 with SMTP id gy10so66886877qcb.3 for ; Mon, 11 May 2015 04:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Eo0Ito8JzxYBPyLNuoDrRQXiSkG5a8eXmrjhxLSfagI=; b=V18FzzQVa6BDhKY6uA+39FMmV0LholRBd20gwuspj7aXjtT50ALAruN468iMz5UpLS ihyrojLoldtUXxhiATMOsRaQgpydSEy1vYKp9elRZoCw1BVuGkI1QcsnNNtbQcHZXQtV Tg4zl6QIZXZpyq7XLTWCr+beV82MgKZPYN9w2BWnWZQo5zkG9//npaq+VDLtMGwy18Zu 0La02xBHLft+YEzhf95jhjEQ2fOyeS4w8kQ5TrB2ysuQqusFsvGqWjN61KdhpLgPV2W8 7542OJC4lMiwoRxmEDJFohXXQ4WeVOfFi+yzY3Qp98WCBDY3QtNoxNZeobuZEwCTs0mO cSDg== 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=Eo0Ito8JzxYBPyLNuoDrRQXiSkG5a8eXmrjhxLSfagI=; b=dkx50/KdXHsEzTI7MlDSXNMTcF29xNACm9nqFk+HvOET6Xs4FvQHNKMOGYR18NPcuk xRkHGxx2IVpH49S4SAbzoBao05GoH1ggnXpZ+PrN1SWbGUBlMIHCt33B5S0b8r+pHrgs UD1UmBO1GQAGhnu99T6Fk2ydo9iLj1h3b3i5GVEcKNRt7apa7QBOaU5I2CVnHhjLAsyl u5z6wshMPq87U8xgSqpPzyeDy59CqfkGkIijg1bhjRugUkKtXBKI7oJMSpGMD2tkzu2B eYlVtAY6icqEOCEoeIihNC2ClWCX1Z4G2yBXjJlrZhcoxXPT+67jcS1IftTWJw6FsOIe /OoQ== X-Gm-Message-State: ALoCoQnKQYy8AoGEFMXHwycSygpZmvB7EtkBrAs+aRWgKdZIVfiZcQo5hKO9uXlDlNTmB4kszjoX MIME-Version: 1.0 X-Received: by 10.55.22.23 with SMTP id g23mr20224910qkh.4.1431343734930; Mon, 11 May 2015 04:28:54 -0700 (PDT) Received: by 10.229.155.138 with HTTP; Mon, 11 May 2015 04:28:54 -0700 (PDT) In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC8D7F63F2A@PINTO.missi.ncsc.mil> References: <5B1D7E570380A64989D4C069F7D14BC8D7F62F04@PINTO.missi.ncsc.mil> <20150508150358.D695F1B2DE@ld9781.wdf.sap.corp> <5B1D7E570380A64989D4C069F7D14BC8D7F63F2A@PINTO.missi.ncsc.mil> Date: Mon, 11 May 2015 12:28:54 +0100 Message-ID: From: Ben Laurie To: "Kemp, David P." Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 11:28:58 -0000 On 8 May 2015 at 16:19, Kemp, David P. wrote: > Martin Rex wrote: >> Clients do not have to accomodate server that violate MUSTS. > > Absolutely correct. Accommodating a compliant server is the only mandatory to implement requirement on clients. > >> In most cases, it is detrimental and often dangerous to work around >> such protocol violations by the peer. > > How ??? Failure to strictly enforce protocols leads to security issues. For example: https://www.owasp.org/index.php/HTTP_Request_Smuggling From nobody Mon May 11 07:00:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DE71A88C9 for ; Mon, 11 May 2015 07:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 OK-3RfmJxu-E for ; Mon, 11 May 2015 07:00:00 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC011A0025 for ; Mon, 11 May 2015 07:00:00 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 412052AA1A; Mon, 11 May 2015 15:59:58 +0200 (CEST) X-purgate-ID: 152705::1431352798-00005316-8EF319DE/0/0 X-purgate-size: 2316 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 309CB4290C; Mon, 11 May 2015 15:59:58 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1F96C1B2E4; Mon, 11 May 2015 15:59:58 +0200 (CEST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB019AE1@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann Date: Mon, 11 May 2015 15:59:58 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150511135958.1F96C1B2E4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "" Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 14:00:02 -0000 Peter Gutmann wrote: > Martin Rex writes: >> >>A TLS client should not know or care about the hostname of the server it is >>talking to, and there is no requirement what kind of stuff is contained in >>the server's certificate. > > Which is far too true, unfortunately, particularly among Android and iOS apps, > as recent research (e.g. "Why Eve and Mallory Love Android: An Analysis of > Android SSL (In)Security" and "The most dangerous code in the world: > validating SSL certificates in non-browser software") has pointed out. Still, > not caring whether the supposed www.bankofamerica.com presents a cert for > www.qwertyuiop.com doesn't strike me as a sound security strategy. > >>Our TLS client does _not_ know the server's hostname (it gets a connected >>socket). > > So it's like all the insecure Android and iOS apps? You're obviously confusing application bugs with TLS bugs. As previously mentioned, all TLS specifications up to and including TLSv1.2 have been extremely clear that the name contained in the certifcates is a matter of the protocols & software layers on top of TLS, and none of TLS business: https://tools.ietf.org/html/rfc5246#page-5 the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. For (a part) of our code I am providing an abstraction that loads the (external) TLS implemenation, provides configurability for certain default behaviour, performs the client-side caching magic, and it does provide an rfc2818 section 3 server endpoint identity check for convenience, which the API caller can use or override. The TLS(!) implementation itself, however, does not get to see the server hostname. Now the fashion this has been wrapped by higher application layers, it is currently not possible for the _end_user_ to configure our (programmatic) HTTPS client to skip server certificate path validation or server endpoint identity checking, and some of the top-level apps programmers are unhappy, because they have to properly document how to configure their scenarios so that both checks succeed. -Martin From nobody Mon May 11 08:03:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85551A8A9B for ; Mon, 11 May 2015 08:03:30 -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 Y3djCG2l3B15 for ; Mon, 11 May 2015 08:03:28 -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 4AA521A8A29 for ; Mon, 11 May 2015 08:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1431356609; x=1462892609; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Q/u1TjVzY/BB9VY38EAlF5A5lIC7RCLWL7xD9qN30m8=; b=rwWRy7VKkGVYPEDlqzGW44RYJhV1gyPaGFrsvfzOgr8X9LpKMrD5EcTs UJuQLlb6x2mtyRW/FVpWJfYTmsIqJUJHn9HLGptvPjpLN93adFfKkDYSq stJU+M24HVYao3HH3tusSKQIgs2NWbZW/Vc21sEKoe6K/hiKKNoLqf1KM U=; X-IronPort-AV: E=Sophos;i="5.13,408,1427713200"; d="scan'208";a="4348932" 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; 12 May 2015 03:03:27 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 12 May 2015 03:03:26 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Update spec to match current practices for certificate chain order Thread-Index: AdCL+6Ggvko2QiXYRsOnC3jKu9WpAg== Date: Mon, 11 May 2015 15:03:25 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB01B158@uxcn10-tdc05.UoA.auckland.ac.nz> 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: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:03:31 -0000 Martin Rex writes:=0A= =0A= >As previously mentioned, all TLS specifications up to and including TLSv1.= 2=0A= >have been extremely clear that the name contained in the certifcates is a= =0A= >matter of the protocols & software layers on top of TLS, and none of TLS= =0A= >business:=0A= >=0A= >https://tools.ietf.org/html/rfc5246#page-5=0A= >=0A= > the decisions on how to initiate TLS=0A= > handshaking and how to interpret the authentication certificates=0A= > exchanged are left to the judgment of the designers and implementors=0A= > of protocols that run on top of TLS.=0A= =0A= Oh, I thought that was just marketing fluff rather than a hard-and-fast=0A= requirement. If it is a set requirement for the protocol though then it sh= ows=0A= a major disconnect between the protocol designers and its users, you've got= a=0A= protocol that promises to do cryptographic authentication of the server so= =0A= that developers of apps running on top of it don't have to deal with this, = and=0A= yet in that one sentence it quietly makes it Someone Else's Problem. So th= e=0A= developers of the thousands of vulnerable apps will be assuming that the TL= S=0A= layer [0] will do the checking for them, while the TLS layer can convenient= ly=0A= say "well, it's not my problem, and I've got the weasel-words to prove it".= =0A= =0A= Peter.=0A= =0A= [0] There's probably a better term to use here than Transport Layer Securit= y=0A= layer.= From nobody Mon May 11 09:57:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2B81ACDF0 for ; Mon, 11 May 2015 09:57:04 -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 XRksJrhEzMM2 for ; Mon, 11 May 2015 09:57:02 -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 812FF1A86E3 for ; Mon, 11 May 2015 09:57:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CD2A1283032; Mon, 11 May 2015 16:57:00 +0000 (UTC) Date: Mon, 11 May 2015 16:57:00 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150511165700.GY17272@mournblade.imrryr.org> References: <9A043F3CF02CD34C8E74AC1594475C73AB01B158@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB01B158@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:57:04 -0000 On Mon, May 11, 2015 at 03:03:25PM +0000, Peter Gutmann wrote: > >https://tools.ietf.org/html/rfc5246#page-5 > > > > the decisions on how to initiate TLS > > handshaking and how to interpret the authentication certificates > > exchanged are left to the judgment of the designers and implementors > > of protocols that run on top of TLS. > > Oh, I thought that was just marketing fluff rather than a hard-and-fast > requirement. If it is a set requirement for the protocol though then it shows > a major disconnect between the protocol designers and its users, you've got a > protocol that promises to do cryptographic authentication of the server so > that developers of apps running on top of it don't have to deal with this, and > yet in that one sentence it quietly makes it Someone Else's Problem. So the > developers of the thousands of vulnerable apps will be assuming that the TLS > layer [0] will do the checking for them, while the TLS layer can conveniently > say "well, it's not my problem, and I've got the weasel-words to prove it". Cynicism is a comfortable posture, but you surely know that different applications have different ways to verify the peer identity. There are various alternative name forms SRV-ID, DNS-ID or whatever the client and server operators bilaterally agree on out of band. The client may even be using leap-of-trust with pinning to authenticate the server. Also, with DANE TLSA certificate usage DANE-EE(3) the name binding is *outside* the certificate (handled by the TLSA record itself): https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-3.1.1 https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.1 -- Viktor. From nobody Mon May 11 11:20:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32D11ACE95 for ; Mon, 11 May 2015 11:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 sCACSVAM1VFR for ; Mon, 11 May 2015 11:20:55 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF991ACE6B for ; Mon, 11 May 2015 11:20:55 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 044812857A for ; Mon, 11 May 2015 18:20:54 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id E330528532 for ; Mon, 11 May 2015 18:20:53 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id BE0DA202F for ; Mon, 11 May 2015 18:20:53 +0000 (GMT) Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 11 May 2015 13:20:53 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1076.000; Mon, 11 May 2015 13:20:53 -0500 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Thread-Topic: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) Thread-Index: AQHQieY/gmukibBgKEmnwP9D0xEiS513auKA//+u2OA= Date: Mon, 11 May 2015 18:20:52 +0000 Message-ID: <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 18:20:56 -0000 PiBJZiB5b3UnZCBsaWtlIHRvIGV4cGxhaW4gaG93IGZvcm1hbGx5IGRvY3VtZW50aW5nIGV4aXN0 aW5nIGJlaGF2aW9yICh0aGF0IHdlIGFyZSBub3Qgb3RoZXJ3aXNlIHByb3Bvc2luZyBiZSBjaGFu Z2VkKSB3aWxsIHNvbWVob3cgcmVkdWNlIGludGVyb3BlcmFiaWxpdHkgZnVydGhlciwgdGhlbiBw bGVhc2UgZG8gc28gb24gdGhlIG1haWxpbmcgbGlzdC4NCg0KT2theSwgSSdsbCB0cnkuDQoNCldl IGFscmVhZHkgaGF2ZSBub24tY29tcGxpYW50IGJlaGF2aW9yLCBldmVuIHRob3VnaCB0aGUgc3Bl YyBpcyBwcmV0dHkgY2xlYXIgYW5kIHNvbWUgaW1wbGVtZW50YXRpb25zIHJlbHkgb24gY29tcGxp YW5jZSB3aXRoIHRoYXQgc3BlYy4gQW5kIG5vYm9keSBoYXMgc2FpZCB0aGF0IGl0J3MgYSBCQUQg cmVxdWlyZW1lbnQsIGp1c3QgdGhhdCBpdCdzIG5vdCB1bml2ZXJzYWxseSBpbXBsZW1lbnRlZC4N Cg0KU2xpZGluZyBiYWNrIGZyb20gdGhlIGN1cnJlbnQgcmVxdWlyZW1lbnQgc2VlbXMgbGlrZSBp dCB3aWxsIG9ubHkgYWRkIHRvIHRoZSB3aWdnbGUgcm9vbSBhbmQgYWxsb3cgZXZlbiBtb3JlIGFi ZXJyYW50IGJlaGF2aW9yLiAgVGhlIGNvbGxhcHNlIG9mIFdlc3Rlcm4gY2l2aWxpemF0aW9uLCBk b2dzIGFuZCBjYXRzIHNsZWVwaW5nIHRvZ2V0aGVyLCBldGMuICBPa2F5LCBwZXJoYXBzIEkgZXhh Z2dlcmF0ZS4NCg0KUmF0aGVyIHRoYW4gZ2l2aW5nIHVwLCB3ZSBzaG91bGQgYmUgc3BlbmRpbmcg YW55IGVmZm9ydCB0byBnZXQgY29tcGxpYW5jZS4NCg0K From nobody Mon May 11 11:41:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079651A892E for ; Mon, 11 May 2015 11:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 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_NONE=-0.0001] 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 bSOGypfgFJdn for ; Mon, 11 May 2015 11:41:56 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 866271A8924 for ; Mon, 11 May 2015 11:41:56 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 51C7340101F27; Mon, 11 May 2015 11:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=aYeQ7BaSAPeeRAfHtNJc2NA0Y64=; b=G/W6B35bwzFG+chjq D8yXjmTx6oTCA+lCh49spH5b71v6HIdEJ6XtFujjs8RxlSCp1AZxacKoIryMFZuH 9IoRf4O1+AzpOqYJBmN05R0amCu2PjzqhtmOb6WoEJc+WhjLGHtzKWViDZiMhJ+j 4L3hX6Shz1uPAOHyC1VOR7NP7w= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPA id 75C5D400DB936; Mon, 11 May 2015 11:41:52 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Mon, 11 May 2015 11:41:56 -0700 Message-ID: <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> In-Reply-To: <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> References: <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> Date: Mon, 11 May 2015 11:41:56 -0700 From: "Ryan Sleevi" To: "Salz, Rich" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 18:41:58 -0000 On Mon, May 11, 2015 11:20 am, Salz, Rich wrote: > > If you'd like to explain how formally documenting existing behavior > > (that we are not otherwise proposing be changed) will somehow reduce > > interoperability further, then please do so on the mailing list. > > Okay, I'll try. > > We already have non-compliant behavior, even though the spec is pretty > clear and some implementations rely on compliance with that spec. And > nobody has said that it's a BAD requirement, just that it's not > universally implemented. That's not true. I've explicitly stated it's a BAD requirement, and tried to give concrete examples. I'll be explicit: 1) I think clients, such as Martin's, that implement normative checking o= f ordering and are used for the Internet at large (e.g. between servers and clients that are not controlled by a single entity) are bad for Internet security. 2) I think clients, such as Martin's and Geoff's, that do not implement RFC 4158 path discovery are bad for Internet security. 3) I think language that encourages or requires clients to normatively enforce such ordering are bad for Internet security. So to be clear, I disagree with my colleague, Ben Laurie, rather substantially here. The context is that: 1) I'm involved in maintaining one of the largest client web browsers' PK= I stack. Thus, I deal with brokenness on a daily basis. 2) I'm involved in dealing with the PKI stacks of a variety of platforms, some open-source, some closed-source, and with a variety of versions. 3) I'm involved in the CA/Browser Forum and have spent the past several years trying to work in deprecation of insecure cryptography (in the case of certificates, SHA-1, RSA signatures <=3D 1024-bits, and in general, RS= A signatures vs ECC) I say all this to say "I've seen things", and when it comes to gross hacks, few people are as more affected and have more visibility to them than those doing things similar to me. All of that to say I think the current language encourages bad practice. In my original email, I tried to establish why: 1) Clients have disparate trust-stores. Absent the X.500 directory, this is a fact of life. The set of trust anchors recognized by Microsoft will and is different than those recognized by Mozilla, for a variety of legitimate reasons that will not change, no matter what the IETF does. 2) As such, there is no single trusted path. RFC 4158 spells this out in abundant detail, and the figures contained should be "required skimming" for any of this discussion. 3) Implementing path discovery is hard. RFC 4158 spells out why. It's als= o necessary, as the first two points here spell out. Clients that don't support RFC 4158 "break" if a trusted path cannot be found. In order to handle deprecations of SHA-1, for example, certificate paths need to be replaced with their SHA-256 equivalent. To handle the deprecation of RSA-1024 bit, alternative paths must be supplied. To handl= e the deprecation of RSA in favour of ECC, alternative paths must be supplied. If you fail to supply those, clients break. When clients break, servers have to choose between breaking clients and doing the right thing or keeping clients working. For obvious and understandable business reasons, "keeping clients working= " is always going to be the preferable case. "Keeping clients working" is equivalent to "holding security back" So servers do the sensible thing. They try to find a way to keep clients working WHILE doing the right thing. This takes many forms. The most obvious and understandable being *supply all the paths the server knows about to the client*. Clients that don't do "insecure AIA fetching" (as Martin likes to pejoratively phrase it, as I disagree with him on this point substantially), but that thankfully don't implement Martin's strict checking (which luckily, few do), this works as a viable means of providing acceptable paths to them. At the cost of violating the TLS RFC in a part of language that *enforcing* requires more work and introduces more security issues to clients. If every client had RFC 4158 capable path discovery, would I still advocate relaxing the language? Honestly, yes, because it should be up to the server to balance the tradeoffs between client interoperability. If every client enforced the TLS requirements, as Martin advocates, it would directly and concretely harm the ability to push for reform in the PKI system used by the most prominent deployment of TLS (the HTTPS Web), because clients that lack "insecure AIA fetching" would simply break when the Web PKI changes. There are many ways to mitigate this, and luckily, modern cryptographic libraries are starting to see the wisdom that Microsoft saw nearly 10 years ago, when they made CryptoAPI automatically update the trust store and handle trust migrations. However, in an IoT world, where things are using libraries like OpenSSL, and which lack RFC 4158 path discovery, I'm increasingly concerned that we will see greater ossification and calcification of the PKI stores, preventing much needed security reform. So yes, I do see this current language as objectively and quantifiably BA= D for security. I think implementing it in a TLS client library (since it i= s NOT required of PKI libraries or implementations, and RFC 4158 rightly dissuades it) introduces more attack surface and more complexity for negative gains on security and maintainability. From nobody Mon May 11 11:55:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22931A8821 for ; Mon, 11 May 2015 11:55:19 -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 PeXPE-QnPTj3 for ; Mon, 11 May 2015 11:55:17 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883001A87EF for ; Mon, 11 May 2015 11:55:17 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.154.19; Mon, 11 May 2015 18:55:15 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0154.018; Mon, 11 May 2015 18:55:15 +0000 From: Andrei Popov To: "ryan-ietftls@sleevi.com" , "Salz, Rich" Thread-Topic: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) Thread-Index: AQHQieY/gmukibBgKEmnwP9D0xEiS513auKA//+u2OCAAAbJAIAAAk8A Date: Mon, 11 May 2015 18:55:15 +0000 Message-ID: References: <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> In-Reply-To: <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sleevi.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(189998001)(77156002)(2501003)(46102003)(19580395003)(87936001)(19580405001)(2656002)(92566002)(99286002)(5001960100002)(2950100001)(5001770100001)(40100003)(77096005)(54356999)(76176999)(86362001)(15975445007)(50986999)(74316001)(33656002)(102836002)(76576001)(62966003)(106116001)(86612001)(93886004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2015 18:55:15.2636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 18:55:20 -0000 I agree with Ryan on this. It would be awesome to be able to keep certifica= te_list ordering simple, but in reality we can't, for the reasons Ryan eloq= uently presented. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ryan Sleevi Sent: Monday, May 11, 2015 11:42 AM To: Salz, Rich Cc: TLS@ietf.org (tls@ietf.org) Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirement= s to match current practice (#169) On Mon, May 11, 2015 11:20 am, Salz, Rich wrote: > > If you'd like to explain how formally documenting existing behavior=20 > > (that we are not otherwise proposing be changed) will somehow reduce=20 > > interoperability further, then please do so on the mailing list. > > Okay, I'll try. > > We already have non-compliant behavior, even though the spec is=20 > pretty clear and some implementations rely on compliance with that=20 > spec. And nobody has said that it's a BAD requirement, just that it's=20 > not universally implemented. That's not true. I've explicitly stated it's a BAD requirement, and tried t= o give concrete examples. I'll be explicit: 1) I think clients, such as Martin's, that implement normative checking of = ordering and are used for the Internet at large (e.g. between servers and c= lients that are not controlled by a single entity) are bad for Internet sec= urity. 2) I think clients, such as Martin's and Geoff's, that do not implement RFC= 4158 path discovery are bad for Internet security. 3) I think language that encourages or requires clients to normatively enfo= rce such ordering are bad for Internet security. So to be clear, I disagree with my colleague, Ben Laurie, rather substantia= lly here. The context is that: 1) I'm involved in maintaining one of the largest client web browsers' PKI = stack. Thus, I deal with brokenness on a daily basis. 2) I'm involved in dealing with the PKI stacks of a variety of platforms, s= ome open-source, some closed-source, and with a variety of versions. 3) I'm involved in the CA/Browser Forum and have spent the past several yea= rs trying to work in deprecation of insecure cryptography (in the case of c= ertificates, SHA-1, RSA signatures <=3D 1024-bits, and in general, RSA sign= atures vs ECC) I say all this to say "I've seen things", and when it comes to gross hacks,= few people are as more affected and have more visibility to them than thos= e doing things similar to me. All of that to say I think the current language encourages bad practice. In my original email, I tried to establish why: 1) Clients have disparate trust-stores. Absent the X.500 directory, this is= a fact of life. The set of trust anchors recognized by Microsoft will and = is different than those recognized by Mozilla, for a variety of legitimate = reasons that will not change, no matter what the IETF does. 2) As such, there is no single trusted path. RFC 4158 spells this out in ab= undant detail, and the figures contained should be "required skimming" for any of this discussion. 3) Implementing path discovery is hard. RFC 4158 spells out why. It's also = necessary, as the first two points here spell out. Clients that don't suppo= rt RFC 4158 "break" if a trusted path cannot be found. In order to handle deprecations of SHA-1, for example, certificate paths ne= ed to be replaced with their SHA-256 equivalent. To handle the deprecation = of RSA-1024 bit, alternative paths must be supplied. To handle the deprecat= ion of RSA in favour of ECC, alternative paths must be supplied. If you fail to supply those, clients break. When clients break, servers have to choose between breaking clients and doi= ng the right thing or keeping clients working. For obvious and understandable business reasons, "keeping clients working" is always going to be the preferable case. "Keeping clients working" is equivalent to "holding security back" So servers do the sensible thing. They try to find a way to keep clients wo= rking WHILE doing the right thing. This takes many forms. The most obvious and understandable being *supply al= l the paths the server knows about to the client*. Clients that don't do "insecure AIA fetching" (as Martin likes to pejorativ= ely phrase it, as I disagree with him on this point substantially), but tha= t thankfully don't implement Martin's strict checking (which luckily, few d= o), this works as a viable means of providing acceptable paths to them. At = the cost of violating the TLS RFC in a part of language that *enforcing* re= quires more work and introduces more security issues to clients. If every client had RFC 4158 capable path discovery, would I still advocate= relaxing the language? Honestly, yes, because it should be up to the serve= r to balance the tradeoffs between client interoperability. If every client= enforced the TLS requirements, as Martin advocates, it would directly and = concretely harm the ability to push for reform in the PKI system used by th= e most prominent deployment of TLS (the HTTPS Web), because clients that la= ck "insecure AIA fetching" would simply break when the Web PKI changes. There are many ways to mitigate this, and luckily, modern cryptographic lib= raries are starting to see the wisdom that Microsoft saw nearly 10 years ag= o, when they made CryptoAPI automatically update the trust store and handle= trust migrations. However, in an IoT world, where things are using librari= es like OpenSSL, and which lack RFC 4158 path discovery, I'm increasingly c= oncerned that we will see greater ossification and calcification of the PKI= stores, preventing much needed security reform. So yes, I do see this current language as objectively and quantifiably BAD = for security. I think implementing it in a TLS client library (since it is = NOT required of PKI libraries or implementations, and RFC 4158 rightly diss= uades it) introduces more attack surface and more complexity for negative g= ains on security and maintainability. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon May 11 14:23:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FE61A9006 for ; Mon, 11 May 2015 14:23:09 -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 ksf2vdgj5mrX for ; Mon, 11 May 2015 14:23:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 032611A6F11 for ; Mon, 11 May 2015 14:23:07 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EB33147D33; Mon, 11 May 2015 21:23:06 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id DFB3C47D30; Mon, 11 May 2015 21:23:06 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id C64362036; Mon, 11 May 2015 21:23:06 +0000 (GMT) Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 11 May 2015 16:23:06 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1076.000; Mon, 11 May 2015 16:23:06 -0500 From: "Salz, Rich" To: "ryan-ietftls@sleevi.com" Thread-Topic: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) Thread-Index: AQHQieY/gmukibBgKEmnwP9D0xEiS513auKA//+u2OCAAFqaAP//2SNw Date: Mon, 11 May 2015 21:23:05 +0000 Message-ID: <5d538c5de674408188c46dacec41fb25@ustx2ex-dag1mb4.msg.corp.akamai.com> References: <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> In-Reply-To: <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.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.40.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 21:23:09 -0000 > That's not true. I've explicitly stated it's a BAD requirement, and tried= to give > concrete examples. >=20 > I'll be explicit: Thanks for taking the time to write all that up. From nobody Mon May 11 18:51:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95C01A6EFE for ; Mon, 11 May 2015 18:51:47 -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 EUhZMh8wuQjY for ; Mon, 11 May 2015 18:51:46 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 305331A6EFC for ; Mon, 11 May 2015 18:51:46 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4372D28628; Tue, 12 May 2015 01:51:45 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 269862861C; Tue, 12 May 2015 01:51:45 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id E932880077; Tue, 12 May 2015 01:51:44 +0000 (GMT) Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 11 May 2015 20:51:44 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1076.000; Mon, 11 May 2015 20:51:44 -0500 From: "Salz, Rich" To: "ryan-ietftls@sleevi.com" Thread-Topic: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) Thread-Index: AQHQieY/gmukibBgKEmnwP9D0xEiS513auKA//+u2OCAAFqaAIAAJDNg Date: Tue, 12 May 2015 01:51:43 +0000 Message-ID: References: <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> In-Reply-To: <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.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.57.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 01:51:47 -0000 > That's not true. I've explicitly stated it's a BAD requirement, and tried= to give > concrete examples. Okay, you have convinced me. Thanks From nobody Tue May 12 05:23:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633891ACD07 for ; Tue, 12 May 2015 05:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 3zVfr2Fvojcu for ; Tue, 12 May 2015 05:22:57 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177A41ACC8A for ; Tue, 12 May 2015 05:22:56 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 8D6DD8191C; Tue, 12 May 2015 15:22:54 +0300 (EEST) Date: Tue, 12 May 2015 15:22:54 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150512122254.GA2287@LK-Perkele-VII> References: <201505081935.13474.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201505081935.13474.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:22:59 -0000 On Fri, May 08, 2015 at 07:35:13PM -0400, Dave Garrett wrote: > A PR with language based on this discussion: > https://github.com/tlswg/tls13-spec/pull/169/files > > The text is mostly the same or similar, with the second "MUST" changed > to a "SHOULD", and the term "trust anchor" replacing references to > root keys/CA. > > Is this changeset acceptable? What's the point of this change? To allow server to send multiple certificate chains (all starting from one EE cert) at once? If it is that, why isn't topological ordering still required to be correct (certificates signed preceed certificates signing)? And does this proposed change allow server to send incomplete certificate chains? According to SSL Pulse (May 2015), about 5% of servers have incomplete chains, and it is marked as a problem. Also, regarding "chain-building", one has to be careful with its interaction with HPKP, which is currently as-deployed the _only_ mechanism that can be usefully used to harden a site against misissued certificates (too bad it is qute a footgun, especially due to chain rewriting). -Ilari From nobody Tue May 12 05:37:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629731B2C14 for ; Tue, 12 May 2015 05:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pqOMEYCYnKm for ; Tue, 12 May 2015 05:37:17 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::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 48E681B2C13 for ; Tue, 12 May 2015 05:37:15 -0700 (PDT) Received: by qcbgy10 with SMTP id gy10so2969424qcb.3 for ; Tue, 12 May 2015 05:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ciiNf3nf+w0cywgUOz3EA080SuWUzo0pHRproVHBYms=; b=g+yXtDnSTyEzbj3JKmQVSiPOTxH9o9z2+N5aA3Ks3KYIcpzV7RXfJTVTpHHAco1e0J XtnNGZWenc7I1waYWKE2XFRL5/AHZTdil0HjZuDWekHSZvhUNkF09ZUQW3XZAK7QdGdt a4V6JyFOEz5ZrTvErQxot85SIBjQD62zE913sOQZJy9iQAkQtsbpKeUhgWhmj8qS43m8 M7p0FTVywEVadIrsx1QTnRZBHYtfjBljARymHSgtePa32EyS4O5sIWQzy4H7wc+nSsbn MLfa6kjgrRzYEbyYW+MWuYIXlQ66SgmA7hggx/6W+AiXrdpbVtlNVAaqVuG0v97oUs8B SxUQ== 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=ciiNf3nf+w0cywgUOz3EA080SuWUzo0pHRproVHBYms=; b=HTAcPSZ5D5GExKTlnlF4803UYVvHZi9K+KNGwaLOy480L+7Zv8uQ5xZP/LWRvyUOE0 TYHxlzYCIrse1BGkVQ7O1H7g51dP9tezZZlkJf4UxNmEsWd2kkUvmAfrrdWPmp1zmlv7 9PPx6drdleH6BnFuKvvqidWXMueUTbVHe+Ngm6txZH01y69AytZSIY8FkGDFHO/ZzAzv 1CNKi/MeSPXcWWAAnD5s57eO1EkKlx2B6U3SSsU31rypDV2QdwofJD39Kdmyx26tAj0z HnG6JvbBq02dJj/5s2f9uY9zSQQ6Z8VFlu8WqFDl79lTLH0UrL020Z2WvAefeWHG3i/g Px5w== X-Gm-Message-State: ALoCoQkvfmF5e/EjdMix9zjNhjIDcDtndce6J8XaFJ9d9GSKIZpOEIukRQsHDdtxWo4jq468GROc MIME-Version: 1.0 X-Received: by 10.140.149.23 with SMTP id 23mr19624210qhv.48.1431434234504; Tue, 12 May 2015 05:37:14 -0700 (PDT) Received: by 10.229.155.138 with HTTP; Tue, 12 May 2015 05:37:14 -0700 (PDT) In-Reply-To: <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> References: <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> Date: Tue, 12 May 2015 13:37:14 +0100 Message-ID: From: Ben Laurie To: ryan-ietftls@sleevi.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:37:18 -0000 On 11 May 2015 at 19:41, Ryan Sleevi wrote: > So to be clear, I disagree with my colleague, Ben Laurie, rather > substantially here. To be fair, I mostly, or maybe even completely, agree with you on further thought. I just wish that path validation were less complicated! I still have a concern around servers that are missing certificates that are needed to complete validation at all, which the proposed language change would permit. I agree that the supplied certs have to cover multiple possible validation paths, and hence cannot follow a strict "each cert validates the next" ordering. It would be nice, however, to put an end to the current chaos. From nobody Tue May 12 06:14:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325EC1B2C3A for ; Tue, 12 May 2015 06:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 T_MiT_PzDMJq for ; Tue, 12 May 2015 06:14:55 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509451B2C10 for ; Tue, 12 May 2015 06:14:55 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 2A04E444AF; Tue, 12 May 2015 15:14:53 +0200 (CEST) X-purgate-ID: 152705::1431436493-0000413A-090215DA/0/0 X-purgate-size: 5375 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 15D8D41E16; Tue, 12 May 2015 15:14:53 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 083471B2EB; Tue, 12 May 2015 15:14:53 +0200 (CEST) In-Reply-To: <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> To: ryan-ietftls@sleevi.com Date: Tue, 12 May 2015 15:14:53 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512131453.083471B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 13:14:58 -0000 Ryan Sleevi wrote: > > 1) I think clients, such as Martin's, that implement normative checking of > ordering and are used for the Internet at large (e.g. between servers and > clients that are not controlled by a single entity) are bad for Internet > security. Huh? I never described anything like that "normative checking". My client simply feeds the certificate chain from the TLS Certificate handshake message, up to an issure that is recognized as trust anchor directly into the certificate path validation function (rfc5280, section 6.1) just like rfc5246 and rfc5280 _designed_ this to be. > > 2) I think clients, such as Martin's and Geoff's, that do not implement > RFC 4158 path discovery are bad for Internet security. rfc4158 is a pretty complex and dumb idea. AND, it is *NOT* a standard. It is explicitly ignored by PKIX (rfc5280). btw. there is *NO* secure approach described for path discovery in rfc4158. So if you do not have a prepopulated local store with all intermediate certs, it can not possibly work in a secure fashion (and a universal, trusted, omniscient directory which can be securely accessed is non-existent). > > 3) I think language that encourages or requires clients to normatively > enforce such ordering are bad for Internet security. You are misreading the existing language. What has been written, applies to the *SENDER* of the Certificate handshake message, not to the recipient. As previously described, the purpose is to make the job of verifying the server certificate easy for the recipient. > > In my original email, I tried to establish why: > 1) Clients have disparate trust-stores. Absent the X.500 directory, this > is a fact of life. The set of trust anchors recognized by Microsoft will > and is different than those recognized by Mozilla, for a variety of > legitimate reasons that will not change, no matter what the IETF does. Correct. Not a problem with the existing text. > 2) As such, there is no single trusted path. RFC 4158 spells this out in > abundant detail, and the figures contained should be "required skimming" > for any of this discussion. The existing requirements do *NOT* say that there can only be one trusted path. It is up to the server to decide which path to send. If there are multiple possible pathes, the choice of which particular path the server sends will have an impact on interoperability, because not all clients might be able to verify all paths. > 3) Implementing path discovery is hard. RFC 4158 spells out why. It's also > necessary, as the first two points here spell out. Clients that don't > support RFC 4158 "break" if a trusted path cannot be found. Implementing rfc4158 will pretty much always result is serious security problems (or an unmanagable monster). rfc4158 is not a standard and actively ignored by rfc5280, so it is not even part of the Internet Security Architecture. > > In order to handle deprecations of SHA-1, for example, certificate paths > need to be replaced with their SHA-256 equivalent. To handle the > deprecation of RSA-1024 bit, alternative paths must be supplied. To handle > the deprecation of RSA in favour of ECC, alternative paths must be > supplied. Not at all. Whether the server uses a ECDSA certificate instead of an RSA certificate is determined by the cipher suite that the server chooses (ECDHE_ECDSA vs ECDHE_RSA), so the path has been determined when the Server's certificate handshake message needs to be composed. But noone with a security clue would be using ECDSA for online signatures. And doubly so, not with NSA-backdoored curves. > > Clients that don't do "insecure AIA fetching" (as Martin likes to > pejoratively phrase it, as I disagree with him on this point > substantially), but that thankfully don't implement Martin's strict > checking (which luckily, few do), this works as a viable means of > providing acceptable paths to them. At the cost of violating the TLS RFC > in a part of language that *enforcing* requires more work and introduces > more security issues to clients. You're putting words in my mouth that I certainly never said. The current language applies *ONLY* to the sender of the Certificate handshake message. It does not require any particular behaviour for the client to verify the server certificate. Which kind of certificate path discovery are you thinking of? Forward/upward AIA chasing is a formally provable security problem. Web Browsers may not care about this, because the aggressively execute active content received over insecure channels all the time, and perform millions of requests without consent from the user and entirely careless about the security implications. non-negligent programmatic TLS clients are different, and so are non-negligent servers. > > If every client had RFC 4158 capable path discovery, would I still > advocate relaxing the language? Honestly, yes, because it should be up to > the server to balance the tradeoffs between client interoperability. If > every client enforced the TLS requirements, as Martin advocates, I'm not, and never did advocate for a specific client behaviour. The existing text is purely about requirements on the *SENDER* of the Certificate handshake PDU. -Martin From nobody Tue May 12 06:58:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403581B2D30 for ; Tue, 12 May 2015 06:58:52 -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 8T9PidquStOo for ; Tue, 12 May 2015 06:58:49 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBB51B2D32 for ; Tue, 12 May 2015 06:58:49 -0700 (PDT) Received: by widdi4 with SMTP id di4so155117239wid.0 for ; Tue, 12 May 2015 06:58: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=UKKQ5Mpeu6spv2ggpiQEAsHuY7TYCMAI/Rw3U+/7Oqc=; b=1AgFGzXA6HbGvYDX7LudabSoruCDB+czwzSz4VNU6nysCAhvKD5BwpO/v6IdrxKu+U vcrLx9GEpe6I2FzNG6FdeXfLRRP7A/AhkFUKFxzn2IY+NIkyKvCMPtMyvlQ5UVLSuQm8 dKZlvG9wQxYBPdJt3bdtO0bnRexREXOPiZO+tZo8jxL0sqWrLfSgzMly/W8LuZ+we60W cMePJcAnc/PeU9yVa7ROS6ju/kqytAXfWcS6rcdDpytHQ+iM/0pHpg0mI8kMw9mJt7ws VOH3/FuimxFDWCH6qzUs8kkiGgZIKRtH7R53sKwgJYKo8XpwQOsfTLG4Z0L/EdON/DpQ VOtA== MIME-Version: 1.0 X-Received: by 10.180.99.42 with SMTP id en10mr5525453wib.83.1431439128001; Tue, 12 May 2015 06:58:48 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Tue, 12 May 2015 06:58:47 -0700 (PDT) In-Reply-To: <20150512131453.083471B2EB@ld9781.wdf.sap.corp> References: <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> <20150512131453.083471B2EB@ld9781.wdf.sap.corp> Date: Tue, 12 May 2015 06:58:47 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 13:58:52 -0000 On Tue, May 12, 2015 at 6:14 AM, Martin Rex wrote: > Ryan Sleevi wrote: >> >> 1) I think clients, such as Martin's, that implement normative checking of >> ordering and are used for the Internet at large (e.g. between servers and >> clients that are not controlled by a single entity) are bad for Internet >> security. > > Huh? I never described anything like that "normative checking". > > My client simply feeds the certificate chain from the TLS Certificate > handshake message, up to an issure that is recognized as trust anchor > directly into the certificate path validation function (rfc5280, > section 6.1) just like rfc5246 and rfc5280 _designed_ this to be. How does the server know which trust anchors will be accepted, particularly in cases involving cross-validation? > > >> >> 2) I think clients, such as Martin's and Geoff's, that do not implement >> RFC 4158 path discovery are bad for Internet security. > > rfc4158 is a pretty complex and dumb idea. AND, it is *NOT* a standard. > It is explicitly ignored by PKIX (rfc5280). > > btw. there is *NO* secure approach described for path discovery in > rfc4158. So if you do not have a prepopulated local store with > all intermediate certs, it can not possibly work in a secure fashion > (and a universal, trusted, omniscient directory which can be securely > accessed is non-existent). Let's look at actual code implementing this "complex and dumb idea". https://golang.org/src/crypto/x509/verify.go What security property is violated by this code, as a result of implementing RFC 4158? Of course, I'm not saying this idea isn't complex and dumb. It has exponential complexity in some cases, may encode 3-SAT (I've been thinking hard about how to do that, and have some ideas involving path constraints) etc, etc. But it's a unfortunate result of how badly PKIX is designed that something like this becomes necessary. The restriction in RFC 5280 won't function in many reasonable scenarios. Or are you saying that cross-validation doesn't exist, that all clients have the same root stores, so we don't need it anyway, and that we can use multiple chains for the cases of algorithm depreciation? > > >> >> 3) I think language that encourages or requires clients to normatively >> enforce such ordering are bad for Internet security. > > You are misreading the existing language. What has been written, applies > to the *SENDER* of the Certificate handshake message, not to the recipient. > As previously described, the purpose is to make the job of verifying > the server certificate easy for the recipient. > > >> >> In my original email, I tried to establish why: >> 1) Clients have disparate trust-stores. Absent the X.500 directory, this >> is a fact of life. The set of trust anchors recognized by Microsoft will >> and is different than those recognized by Mozilla, for a variety of >> legitimate reasons that will not change, no matter what the IETF does. > > Correct. Not a problem with the existing text. > > >> 2) As such, there is no single trusted path. RFC 4158 spells this out in >> abundant detail, and the figures contained should be "required skimming" >> for any of this discussion. > > The existing requirements do *NOT* say that there can only be one trusted > path. It is up to the server to decide which path to send. If there > are multiple possible pathes, the choice of which particular path the > server sends will have an impact on interoperability, because not all > clients might be able to verify all paths. How does the server know which path a client that connects to it will trust? > > >> 3) Implementing path discovery is hard. RFC 4158 spells out why. It's also >> necessary, as the first two points here spell out. Clients that don't >> support RFC 4158 "break" if a trusted path cannot be found. > > > Implementing rfc4158 will pretty much always result is serious security > problems (or an unmanagable monster). > > rfc4158 is not a standard and actively ignored by rfc5280, so it is > not even part of the Internet Security Architecture. > > >> >> In order to handle deprecations of SHA-1, for example, certificate paths >> need to be replaced with their SHA-256 equivalent. To handle the >> deprecation of RSA-1024 bit, alternative paths must be supplied. To handle >> the deprecation of RSA in favour of ECC, alternative paths must be >> supplied. > > Not at all. Whether the server uses a ECDSA certificate instead of > an RSA certificate is determined by the cipher suite that the server > chooses (ECDHE_ECDSA vs ECDHE_RSA), so the path has been determined when > the Server's certificate handshake message needs to be composed. That only determines which leaf was used. It's of course true that one could provide two separate paths, and have servers pick between them based on the leaf. Is that how you propose we deal with this problem? > > But noone with a security clue would be using ECDSA for online signatures. > And doubly so, not with NSA-backdoored curves. I didn't know you were an algebraic geometer, or a cryptographer. What security problem does ECDSA have when used online? P256 is backdoored how again? > > >> >> Clients that don't do "insecure AIA fetching" (as Martin likes to >> pejoratively phrase it, as I disagree with him on this point >> substantially), but that thankfully don't implement Martin's strict >> checking (which luckily, few do), this works as a viable means of >> providing acceptable paths to them. At the cost of violating the TLS RFC >> in a part of language that *enforcing* requires more work and introduces >> more security issues to clients. > > You're putting words in my mouth that I certainly never said. > > The current language applies *ONLY* to the sender of the Certificate > handshake message. It does not require any particular behaviour for > the client to verify the server certificate. > > Which kind of certificate path discovery are you thinking of? > Forward/upward AIA chasing is a formally provable security problem. > Web Browsers may not care about this, because the aggressively > execute active content received over insecure channels all the time, > and perform millions of requests without consent from the user and > entirely careless about the security implications. non-negligent > programmatic TLS clients are different, and so are non-negligent servers. What exactly is the issue here? I'm not familiar enough with AIA to understand what you think people do and why you think it is a problem. If you could actually explain the problems, preferably with example exploits, it would be appreciated. Sincerely, Watson Ladd -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue May 12 07:49:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4447B1B2E06 for ; Tue, 12 May 2015 07:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ps8HoTo2wk0 for ; Tue, 12 May 2015 07:49:02 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 B50C71B2E01 for ; Tue, 12 May 2015 07:49:02 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4CEmxqF009108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 12 May 2015 10:49:00 -0400 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4CEmvwV002184 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 May 2015 10:48:58 -0400 Message-ID: <1431442136.16387.11.camel@redhat.com> From: Nikos Mavrogiannopoulos To: ryan-ietftls@sleevi.com Date: Tue, 12 May 2015 16:48:56 +0200 In-Reply-To: <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> References: <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 14:49:04 -0000 On Mon, 2015-05-11 at 11:41 -0700, Ryan Sleevi wrote: > That's not true. I've explicitly stated it's a BAD requirement, and tried > to give concrete examples. > > I'll be explicit: > > 1) I think clients, such as Martin's, that implement normative checking of > ordering and are used for the Internet at large (e.g. between servers and > clients that are not controlled by a single entity) are bad for Internet > security. > 2) I think clients, such as Martin's and Geoff's, that do not implement > RFC 4158 path discovery are bad for Internet security. That is of course if you define Internet as the web, and "security" as the web PKI. What you are in fact describing is a failure of the web PKI which RFC 4158 makes apparent. When you define trust as "anything my browser trusts", then indeed you are going to have trust issues once you switch to a browser from a different vendor. Nevertheless, RFC 4158 is far from being a standard (just an informational RFC), and there are standard's track extensions which can address the issue [0] and can allow the server to decide which path to send. Does your good for Internet implementation utilize it? regards, Nikos [0]. https://tools.ietf.org/html/rfc6066#section-6 From nobody Tue May 12 09:06:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945EF1A6EFB for ; Tue, 12 May 2015 09:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.351 X-Spam-Level: X-Spam-Status: No, score=-5.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_28=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, 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 DMM7WBKThbwP for ; Tue, 12 May 2015 09:06:03 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDD91ACD56 for ; Tue, 12 May 2015 09:05:58 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 7E3462AA1F; Tue, 12 May 2015 18:05:56 +0200 (CEST) X-purgate-ID: 152705::1431446756-00000B48-0D9C8549/0/0 X-purgate-size: 3823 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4619441283; Tue, 12 May 2015 18:05:56 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3923C1B2EB; Tue, 12 May 2015 18:05:56 +0200 (CEST) In-Reply-To: To: ryan-ietftls@sleevi.com Date: Tue, 12 May 2015 18:05:56 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512160556.3923C1B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:06:05 -0000 Ryan Sleevi wrote: > > If you're going to write a client that works on the Internet at large and > is capable of moving at the speed of the Internet, the best I can say is > "Cheer up and deal with it". Clients doing what you propose, rather than > the thing you hate, hold Internet security back, so I'm not terribly > sympathetic (e.g. https://access.redhat.com/articles/1413643 for the most > recent example) New 2048-bit rootCA certs have been around for several years, and the transition from old 1024-bit rootCAs to 2048-bit rootCAs is a non-problem. It definitely is *NOT* a problem for the existing requirements on the Certificate handshake message. Let's use the Web-Server above (https://access.redhat.com/) as example. (1) Server cert: (2048-bit RSA) Subject: CN=access.redhat.com Issuer: CN=VeriSign Akamai SureServer CA G14-SHA1 (2) ServerCA cert: (2048-bit RSA) Subject: CN=VeriSign Akamai SureServer CA G14-SHA1 Issuer: CN=Baltimore CyberTrust Root (3) CrossCA cert (2048-bit RSA, sha1WithRsaEncryption signature): Subject: CN=Baltimore CyberTrust Root Issuer: CN=GTE CyberTrust Global Root (4) (old) RootCA cert (1024-bit RSA) Subject: CN=GTE CyberTrust Global Root Issuer: CN=GTE CyberTrust Global Root The server https://access.redhat.com sends (1)+(2)+(3) from the above certificate path (and in the correct order), and is omitting only the self-signed 1024-bit RootCA cert (4) from the end of the path in the TLS Certificate Handshake message. FireFox 34.0.5 is a little weird, because it verifies the above path against the old 1024-bit RootCA, although it is in possession of the new Baltimore 2048-bit rootCA Certificate: (3b) new Baltimore RootCA cert (2048-bit RSA) Subject: CN=Baltimore CyberTrust Root Issuer: CN=Baltimore CyberTrust Root FireFox 37.0.1 seems to have been improved and properly recognize that it only needs (1)+(2) from the Servers certificate handshake message to verify the servers certificate against its (3b) trust anchor. Would the server at https://access.redhat.com/ only be sending (1)+(2) in the Certificate Handshake message, then old clients, which have the old 1024-bit GTE CyberTrust Gobal Root in their trust anchor store but not the new self-signed 2048-bit Baltimore Cybertrust Root, would not be able to verify the server certificate (because of the lack of that CrossCA cert). New clients, which have the new self-signed 2048-bit Baltimore CyberTrust Root should be able to recognize that they only need (1)+(2) from the Server Certificate to chain against a known trust anchor. FireFox 34.0.5 seems a little dense. Given the above path, when the client has the new 2048-bit Baltimore rootCA cert, then the client should always perform the verification against the new RootCA when the server Certificate handshake message starts with certificate (1)+(2), and independent of whether the certificate handshake message futher includes (3) or (3)+(4) or (3b). Valid alternative forward paths for the server are: (a) (1)+(2) (b) (1)+(2)+(3) (c) (1)+(2)+(3)+(4) (d) (1)+(2)+(3b) and (b) or (c) will have a higher likelyhood of interop that (a) or (d) because of the legacy clients in the installed base. Now in case that a client has (2) configured as a trust anchor, it would only be using (1) from the Server certificate handshake message (and ignore the other included certificates), and in case that a client as (1) configured as a trust anchor, it would also only be looking at certificate (1), determining that it has this certificate configured as trust anchor, and perform all checks based on that local trust anchor. -Martin From nobody Tue May 12 09:24:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986B11A90E5 for ; Tue, 12 May 2015 09:24:08 -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 8Oss1ANTQdyx for ; Tue, 12 May 2015 09:24:07 -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 07B161A9235 for ; Tue, 12 May 2015 09:24:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 613D8283031; Tue, 12 May 2015 16:24:05 +0000 (UTC) Date: Tue, 12 May 2015 16:24:05 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150512162405.GM17272@mournblade.imrryr.org> References: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> 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: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:24:08 -0000 On Fri, May 08, 2015 at 08:51:49PM -0700, Ryan Sleevi wrote: > I know nothing I say will dissuade you from calling it "unsafe path > discovery", even though I rather vehemently disagree with you. I will > simply point out, however, that were it not for this "unsafe path > discovery", we would not finally be moving to a place where we might be > able to turn off 1024-bit RSA keys used in intermediate and root > certificates, because the PKI is hard and the Internet involves multiple > stakeholders. FWIW, OpenSSL does no path discovery. Whatever certificates the server sends, there is a linearly ordered subset[1] of these that achieves the same validation result as the original heap of certs for all OpenSSL-based clients. So sending something other than a linearly ordered list has no value. With OpenSSL 1.0.2 recently tweaked to do trust-store look-asides for nodes in the middle of the provided linear list, as also noted by Martin cross-signing with SHA256 or RSA 2048, ... works just fine. -- Viktor. [1] If we assign ordinals to the heap elements in order of appearance, the equivalent linear list is the chain (successor == issuer of predecessor) that sorts lexically first. That is for each chain element, the issuer with the smallest heap ordinal is chosen and no other issuers from the heap are considered. This is augmented with look-aside at each chain layer into the trust store, to identify a locally trusted alternative issuer. From nobody Tue May 12 09:31:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864F01A9055 for ; Tue, 12 May 2015 09:31:18 -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 HjT-TNK3NJUd for ; Tue, 12 May 2015 09:31:17 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF04A1A8FD6 for ; Tue, 12 May 2015 09:31:16 -0700 (PDT) Received: by wief7 with SMTP id f7so116499819wie.0 for ; Tue, 12 May 2015 09:31: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 :content-type; bh=vgicBQgXc1En9btCdEPH9gFQCV9li4qnSXksgP0GcEE=; b=xgTvnV7ln5N48FnXktQu+93UJg1JMTrBxRmf816zfTm9zszgQ1qGfgXutdjyXXum/X 13E2QGPHz6y28qhdJemyE3ZDpHQYv6j7a88BVbHQNtAyDTUotAiTdDOG9/qsccG+3b89 oebHKV2wvGko9c0tv4SwgcODAuMB9OhOCzXOQYZBWCb4XTvcXe7a5x1hnE3D9+x//Aik dBYBrcW8wSo+cQhukpm16W3RPtX9PSw18JklEwSywGLTt7JWvSUmZGVPaLvAcIOvgWLV 5vaSQcyufi0YWlo6sbNWZS/ie5IR2F1Hoyz8ChHuQZh56aiLrnvn5JqCHw0rAVqo/zSn 6Bvw== MIME-Version: 1.0 X-Received: by 10.194.157.225 with SMTP id wp1mr31294741wjb.32.1431448275486; Tue, 12 May 2015 09:31:15 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Tue, 12 May 2015 09:31:15 -0700 (PDT) In-Reply-To: <20150512162405.GM17272@mournblade.imrryr.org> References: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> <20150512162405.GM17272@mournblade.imrryr.org> Date: Tue, 12 May 2015 09:31:15 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:31:18 -0000 On Tue, May 12, 2015 at 9:24 AM, Viktor Dukhovni wrote: > On Fri, May 08, 2015 at 08:51:49PM -0700, Ryan Sleevi wrote: > >> I know nothing I say will dissuade you from calling it "unsafe path >> discovery", even though I rather vehemently disagree with you. I will >> simply point out, however, that were it not for this "unsafe path >> discovery", we would not finally be moving to a place where we might be >> able to turn off 1024-bit RSA keys used in intermediate and root >> certificates, because the PKI is hard and the Internet involves multiple >> stakeholders. > > FWIW, OpenSSL does no path discovery. Whatever certificates the > server sends, there is a linearly ordered subset[1] of these that > achieves the same validation result as the original heap of certs > for all OpenSSL-based clients. So sending something other than a > linearly ordered list has no value. > > With OpenSSL 1.0.2 recently tweaked to do trust-store look-asides > for nodes in the middle of the provided linear list, as also noted > by Martin cross-signing with SHA256 or RSA 2048, ... works just > fine. So the actual requirement is for a linearization of the DAG of certs, and this will produce the same results as considering all chains in the DAG? Or am I misunderstanding you? Sincerely, Watson Ladd > > -- > Viktor. > > [1] If we assign ordinals to the heap elements in order of appearance, > the equivalent linear list is the chain (successor == issuer of > predecessor) that sorts lexically first. That is for each chain > element, the issuer with the smallest heap ordinal is chosen and > no other issuers from the heap are considered. > > This is augmented with look-aside at each chain layer into the > trust store, to identify a locally trusted alternative issuer. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue May 12 09:44:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9011A8ACC for ; Tue, 12 May 2015 09:44:49 -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 kXrw7glft2Pz for ; Tue, 12 May 2015 09:44:48 -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 15B0D1A898D for ; Tue, 12 May 2015 09:44:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DF80B283031; Tue, 12 May 2015 16:44:46 +0000 (UTC) Date: Tue, 12 May 2015 16:44:46 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150512164446.GP17272@mournblade.imrryr.org> References: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp> <20150512162405.GM17272@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: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:44:49 -0000 On Tue, May 12, 2015 at 09:31:15AM -0700, Watson Ladd wrote: > > FWIW, OpenSSL does no path discovery. Whatever certificates the > > server sends, there is a linearly ordered subset[1] of these that > > achieves the same validation result as the original heap of certs > > for all OpenSSL-based clients. So sending something other than a > > linearly ordered list has no value. > > > > With OpenSSL 1.0.2 recently tweaked to do trust-store look-asides > > for nodes in the middle of the provided linear list, as also noted > > by Martin cross-signing with SHA256 or RSA 2048, ... works just > > fine. > > So the actual requirement is for a linearization of the DAG of certs, > and this will produce the same results as considering all chains in > the DAG? Or am I misunderstanding you? OpenSSL only constructs one candidate path through the supplied heap (with lookaside into a trust store at each link). Therefore, with respect to OpenSSL clients, supplying anything that is not the lexically first chain is a waste of bandwidth. If that lexically first linear chain does not work (possibly truncated if an intermediate element is signed by a local trust anchor), validation fails. -- Viktor. From nobody Tue May 12 10:07:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB4C1ACD0F for ; Tue, 12 May 2015 10:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 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_NONE=-0.0001] 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 FtvbxhE-lhhK for ; Tue, 12 May 2015 10:07:51 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFD81A9107 for ; Tue, 12 May 2015 10:07:51 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id E25F56780C6; Tue, 12 May 2015 10:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=5rWfoBMMmCZgoNHVdHrCzJ1QqR0=; b=WKOmDXDfcO8X1u9XV SxGhDvN4q2eT0/gcEvusxn40AuPM/bcRCmmVfMtG5S/bUByVoBzBwxnnmeqbW5AY AfJNKfdD6DJhZhTT4ky0dor5kCEH/TEW02QkPL1r7c4oLcWYsKuEjLfVgbf+Mqc3 T/hT05c+PtPxgwEMbwOlokhmNk= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 7F7B1678063; Tue, 12 May 2015 10:07:44 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 10:07:50 -0700 Message-ID: <5ec0a679151b6aad1473a8e1f4ee3e0d.squirrel@webmail.dreamhost.com> In-Reply-To: <20150512160556.3923C1B2EB@ld9781.wdf.sap.corp> References: <20150512160556.3923C1B2EB@ld9781.wdf.sap.corp> Date: Tue, 12 May 2015 10:07:50 -0700 From: "Ryan Sleevi" To: mrex@sap.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 17:07:52 -0000 On Tue, May 12, 2015 9:05 am, Martin Rex wrote: > New 2048-bit rootCA certs have been around for several years, and the > transition from old 1024-bit rootCAs to 2048-bit rootCAs is a non-prob= lem. > > It definitely is *NOT* a problem for the existing requirements on > the Certificate handshake message. I'm sorry, but I'm going to have to disagree with you again, because whil= e this is the way the world looks on paper, it's not the way the world work= s in practice. Your example (access.redhat.com) is one that we had to work around on OS = X due to quirks of the client not supporting trust anchors (e.g. https://code.google.com/p/chromium/issues/detail?id=3D236112 ). That is, if you supply your (b) or (c), for example, you'll break any application using Security.framework for certificate verification (including all those that use CFURL & friends). It seems that Safari has special logic not present in the OS to work around that issue. So servers supply (a) or (d). Now you can rail about clients all you want, and I might be inclined to agree with you, but it highlights that the world is not as pretty as you want. Now, with respect to cross-certificates, it's a regular occurrence to see situations like (1) Leaf-signed-by-(2) (2) Intermediate-signed-by-(3) (3a) Intermediate-signed-by-(4) (3b) Intermediate-signed-by-(5) (4) Root 1 [an existing root] (5) Root 2 [a new root applying for inclusion] In this case, valid paths are [for old clients] (1)+(2)+(3a)+(4) [for new clients] (1)+(2)+(3b)+(5) As much as you might wish to yell that they shouldn't have done (3a)/(3b) like that, and instead (5) should have been certified by (4), there are a large number of reasons why that doesn't happen, and the above is actuall= y quite common (I know of at least three different organizations who will have to go through the above flow right now to avoid issues) The maximum compatibility with clients is (1)+(2)+(3a)+(4)+(3b)+(5) As gross and as ugly as that may seem, when working with various clients' libraries, that config is what gets the most working. That's why I suppor= t the language relaxation, in its simplest form. Now, if clients did AIA fetching ubiquitously, you might supply (1)+(2)+(3a) and have (2)'s AIA point to (3b). Clients that trust (4) wil= l work "out of the box", while clients that trust (5) will do an AIA chase off (2) to get (3b). Over time, you might determine that more clients hav= e (5) than (4), so then you invert it to (1)+(2')+(3b), where (2') is a version of 2 whose AIA points to (3a). This is the PKI we live in. It's not going away - it's here and has been for the past decades. If you fully control your client, server, and PKI, the language is entirely reasonable. But few people do. From nobody Tue May 12 10:13:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299BD1ACD59 for ; Tue, 12 May 2015 10:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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_NONE=-0.0001] 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 PrZ_m3g6mdc1 for ; Tue, 12 May 2015 10:13:27 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCC31ACD58 for ; Tue, 12 May 2015 10:13:27 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 9BADD2004F323; Tue, 12 May 2015 10:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=s39T4xEm9Sz3ZZ4PrkvSrsAkhOs=; b=KglT8F0/hYRpCF+c2 3jHRgXH3AStWdPzqKsV5LJQ7C0racMLeugfGN5iPgDEpKhSJEmpanPFyPV5j6Sna K5HxZtpRtp3LEu3V0jos34Ve0JZYW8AhX4XcVcis/bMszamVE61YLWMFPyVEf06b jRilBn6Yq45oCGwtz8N2S8vEw0= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id B35CE2004F328; Tue, 12 May 2015 10:13:22 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 10:13:26 -0700 Message-ID: In-Reply-To: <1431442136.16387.11.camel@redhat.com> References: <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> <1431442136.16387.11.camel@redhat.com> Date: Tue, 12 May 2015 10:13:26 -0700 From: "Ryan Sleevi" To: "Nikos Mavrogiannopoulos" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 17:13:28 -0000 On Tue, May 12, 2015 7:48 am, Nikos Mavrogiannopoulos wrote: > Nevertheless, RFC 4158 is > far from being a standard (just an informational RFC), I don't think I presented it as a standard - just what the major PKI clients that most users interact with on a daily basis do. I didn't suggest it was the whole Internet. But for the PKI that people rely on for their daily interactions online (aka the Web PKI), which is used far beyond *just* web browsers (as https://access.redhat.com/articles/1413643 reminds us), the security here is relevant, and perhaps essentially so. > and there are > standard's track extensions which can address the issue [0] and can > allow the server to decide which path to send. Does your good for > Internet implementation utilize it? > [0]. https://tools.ietf.org/html/rfc6066#section-6 There are no plans at present to implement, and it's unlikely we would. Without wanting to get into a separate discussion, the privacy and performance implications of such an extension are extremely undesirable. Just because there's a Standards Track I-D doesn't mean it is wise or desirable ( http://tools.ietf.org/html/rfc6961 is another example), and just because it's an Informational Draft doesn't mean it's not widely supported (CryptoAPI, Java, and NSS, for example, all follow the logic of 4158) If I phrased your concern more objectively, would ubiquitous support "tomorrow" for RFC 6066 cause me to remove support for relaxing the language? No, because we still have the world we live in today. And havin= g spec language reflect an idealized, unrealistic future instead of the reality we live in just does more harm than good. Much like references to the X.500 Global Directory. From nobody Tue May 12 10:40:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557AF1A1BB1 for ; Tue, 12 May 2015 10:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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_NONE=-0.0001] 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 jExVIADzubUo for ; Tue, 12 May 2015 10:40:29 -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 37E061A024E for ; Tue, 12 May 2015 10:40:29 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id E859C2006000F; Tue, 12 May 2015 10:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=g2ndjz5/Y3YF70URw7EA8KUhC8w=; b=Oe487hGVEkjPxslLX Ys6HIbpRvBorBFk8WR67/+98w9jfopibJk53Q+yeVKv8Ca3RriJ+tYi5+bUQbiOE 6fkyDsHzs5EZE42KaVJk3g21Qd8H5g+T6deJfts7k8hVRwThzGSHw4b8HQh0Oj2F 3ziGPTlY90RFbksWPhAyM7gddw= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id 167DA2005D11A; Tue, 12 May 2015 10:40:28 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 10:40:28 -0700 Message-ID: In-Reply-To: <20150512131453.083471B2EB@ld9781.wdf.sap.corp> References: <20150512131453.083471B2EB@ld9781.wdf.sap.corp> Date: Tue, 12 May 2015 10:40:28 -0700 From: "Ryan Sleevi" To: mrex@sap.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 17:40:30 -0000 On Tue, May 12, 2015 6:14 am, Martin Rex wrote: > Huh? I never described anything like that "normative checking". "Up to 2013 our SSL implementation has been hard failing TLS handshakes with TLS peers that are sending garbled or incomplete chains." This, in context, and combined with your follow-up qualifiers, suggested = a level of checking beyond RFC 5280. > rfc4158 is a pretty complex and dumb idea. AND, it is *NOT* a standard= . > It is explicitly ignored by PKIX (rfc5280). Only to the extent that RFC 5280 Section 6 deals specifically with the validation of a given certification path, while leaving out of scope (but acknowledged rather extensively throughout the documentation, especially for extensions) the building/discovery of said paths. Indeed, Section 3.2 calls out some of the complexities and acknowledgemen= t that inherent in the PKI is the possibility of multiple certification paths. Section 6.2 further acknowledges this. Merely I think it's a mistake and misleading to suggest that RFC 4158 is an interesting side-note in the history of PKI, when in fact it describes the behaviour of some of the largest (by end-user) clients out there (Windows' CryptoAPI, Mozilla's NSS in various flavours, Java's JCA/CertPath APIs). > btw. there is *NO* secure approach described for path discovery in > rfc4158. So if you do not have a prepopulated local store with > all intermediate certs, it can not possibly work in a secure fashion > (and a universal, trusted, omniscient directory which can be securely > accessed is non-existent). Probably not for the TLS list, but since you bring this up virtually ever= y time when discussing PKI issues, it may help if you actually write up the threat model or where you see it as "not secure". I see Watson has equall= y requested this. It's probably not suitable for the PKIX WG (given the impeding/actual shu= t down - I can't remember timelines), but I think it'd be useful for the community at large, and separate from the TLS WG, for you to actually elaborate on this claim. > The existing requirements do *NOT* say that there can only be one trus= ted > path. It is up to the server to decide which path to send. If there > are multiple possible pathes, the choice of which particular path the > server sends will have an impact on interoperability, because not all > clients might be able to verify all paths. I think this is the heart of the matter. The current language forces a choice for server operators that is often untenable - reject a set of valid clients, who COULD work, in order to preserve spec purity that few clients enforce explicitly. The proposed language change reflects the reality - that when options exist that require a server operator to choose between, say, 25% of their clients working while respecting the spec, 50% of their clients working while respecting the spec, or 70% of their clients working while ignoring the spec, they will choose the 70%, even if it means violating the spec. (As to why 70 < 50 + 25, let's pretend, for sake of discussion, that 5% o= f the clients behave like yours and enforce a strict ordering, either implicitly by only using an RFC 5280 algorithm, or explicitly by imposing such a requirement during the TLS handshake) > Not at all. Whether the server uses a ECDSA certificate instead of > an RSA certificate is determined by the cipher suite that the server > chooses (ECDHE_ECDSA vs ECDHE_RSA), so the path has been determined wh= en > the Server's certificate handshake message needs to be composed. This was not the issue I was referring to; you can have an ECC leaf issue= d off an RSA intermediate or root. Indeed, this is not at all uncommon, and while decrying it probably won't be useful for this thread, we should at least acknowledge it. There are a variety of business and operational reasons that led to this, but there are situations in which a given CA may have an ECC root recognized in one set of clients, and an RSA root recognized in a set of other clients, and thus again, multiple paths exist. And I'm further setting aside the issues between ServerKeyExchange authentication vs Server Certificate authentication, which is a whole hos= t of other worms w/ the existing SignatureAndHashAlgorithms. That's its own issue that I'm not wanting to dive into. > But noone with a security clue would be using ECDSA for online signatu= res. ... > And doubly so, not with NSA-backdoored curves. ... Such incredible claims that I'm going to have to leave them unaddressed, as apparently I and my colleagues are not true Scotsmen. From nobody Tue May 12 11:14:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A7C1ACE31 for ; Tue, 12 May 2015 11:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 idPujV85z6vu for ; Tue, 12 May 2015 11:14:41 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A811ACE29 for ; Tue, 12 May 2015 11:14:32 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 6CEBE2A94F; Tue, 12 May 2015 20:14:30 +0200 (CEST) X-purgate-ID: 152705::1431454470-0000413A-4E849506/0/0 X-purgate-size: 5609 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 36A6D412BF; Tue, 12 May 2015 20:14:30 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2BAB51B2EB; Tue, 12 May 2015 20:14:30 +0200 (CEST) In-Reply-To: <5ec0a679151b6aad1473a8e1f4ee3e0d.squirrel@webmail.dreamhost.com> To: ryan-ietftls@sleevi.com Date: Tue, 12 May 2015 20:14:30 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512181430.2BAB51B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:14:52 -0000 Ryan Sleevi wrote: > On Tue, May 12, 2015 9:05 am, Martin Rex wrote: >> New 2048-bit rootCA certs have been around for several years, and the >> transition from old 1024-bit rootCAs to 2048-bit rootCAs is a non-problem. >> >> It definitely is *NOT* a problem for the existing requirements on >> the Certificate handshake message. > > I'm sorry, but I'm going to have to disagree with you again, because while > this is the way the world looks on paper, it's not the way the world works > in practice. > > Your example (access.redhat.com) is one that we had to work around on OS X > due to quirks of the client not supporting trust anchors (e.g. > https://code.google.com/p/chromium/issues/detail?id=236112 ). > > That is, if you supply your (b) or (c), for example, you'll break any > application using Security.framework for certificate verification > (including all those that use CFURL & friends). It seems that Safari has > special logic not present in the OS to work around that issue. If that particular client really goofs the certificate path validation in presence of an unneeded crossCA (plus optional untrusted rootCA) while succeeding certificate path validation when neither of these additional certificates is present, then it is obviously defective and ought to be fixed-- and this silly bug should have been found and fixed a few years ago -- because several public CAs have been doing this for years. The straight forward workaround for such a defective client would have been to import the crossCA certificate incarnation of the new Baltimore RootCA certificate as additional trust anchor (since *ANY* certificate can be declared a trust anchor, it does not need to be self-signed). > > Now, with respect to cross-certificates, it's a regular occurrence to see > situations like > > (1) Leaf-signed-by-(2) > (2) Intermediate-signed-by-(3) > (3a) Intermediate-signed-by-(4) > (3b) Intermediate-signed-by-(5) > (4) Root 1 [an existing root] > (5) Root 2 [a new root applying for inclusion] > > In this case, valid paths are > [for old clients] > (1)+(2)+(3a)+(4) > > [for new clients] > (1)+(2)+(3b)+(5) > > As much as you might wish to yell that they shouldn't have done (3a)/(3b) > like that, and instead (5) should have been certified by (4), there are a > large number of reasons why that doesn't happen, and the above is actually > quite common (I know of at least three different organizations who will > have to go through the above flow right now to avoid issues) > > The maximum compatibility with clients is > (1)+(2)+(3a)+(4)+(3b)+(5) > > As gross and as ugly as that may seem, when working with various clients' > libraries, that config is what gets the most working. That's why I support > the language relaxation, in its simplest form. Myself, I have not seen any such Certificate handshake messages so far (like in a customer support incident). Do you have an example (URL) of a server with such a configuration? (I actually do not know how the TLS client, for which I'm still doing maintenance, will handle this). At least the above would be properly ordered up to and including a self-signed rootCA certificate. So clients that trust the old root might be able to see the match to a known trust anchor and simply ignore the trailing junk. But for simple clients that trust only the newer root, this certificate path is probably invalid (and in violation of the current requirements), and there is no easy approach to make such a certificate_list comprehensible to such a client (that only trusts the new root). > > Now, if clients did AIA fetching ubiquitously, you might supply > (1)+(2)+(3a) and have (2)'s AIA point to (3b). Clients that trust (4) will > work "out of the box", while clients that trust (5) will do an AIA chase > off (2) to get (3b). Over time, you might determine that more clients have > (5) than (4), so then you invert it to (1)+(2')+(3b), where (2') is a > version of 2 whose AIA points to (3a). "AIA chasing" is obviously insecure and a huge security problem. If you look at how the certificate path validation is designed in PKIX (rfc5280) section 6.1+, it works from the trust anchor down towards the end-entity certificate, and the algorithm will not use any information from an untrusted certificate _unless_ an already trusted certificate can be used to verify the signature on the still untrusted certificate, and that verification has succeeded. AIA chasing walks the chain in the opposite direction, and would use information (a download-URL) from a still untrusted certificate to perform a download. As I previously said, this might look normal for a browser, because browser do stupid things all the time, but it would be definitely irresponsible for a PKIX implementation to do something like this, and perform a download of an object with an URL from an untrusted certificate provided by the communication peer. The other problem here is inefficiency. In a number of environments performing network data exchanges during certificate path validation is a complete non-starter. To at least fix the security side of the problem, the publication of additional certs would have to work strictly top down. I.e. the trust anchor cert will have to indicate the location where to obtain additional crossCA certificates, and the serverCA cert would need to have additional attributes added, enumerating the rootCAs under which the server certificate will be alternatively verifiable. -Martin From nobody Tue May 12 11:54:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4433F1AD366 for ; Tue, 12 May 2015 11:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 oUBWc4jSv7JV for ; Tue, 12 May 2015 11:54:13 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E27C1A8887 for ; Tue, 12 May 2015 11:54:13 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id D1DD82A8D5; Tue, 12 May 2015 20:54:10 +0200 (CEST) X-purgate-ID: 152705::1431456850-00005316-5150F627/0/0 X-purgate-size: 4043 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 6FEE641369; Tue, 12 May 2015 20:54:10 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 648121B2EB; Tue, 12 May 2015 20:54:10 +0200 (CEST) In-Reply-To: To: ryan-ietftls@sleevi.com Date: Tue, 12 May 2015 20:54:10 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512185410.648121B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:54:16 -0000 Ryan Sleevi wrote: > On Tue, May 12, 2015 6:14 am, Martin Rex wrote: > > Huh? I never described anything like that "normative checking". > > "Up to 2013 our SSL implementation has been hard failing TLS handshakes > with TLS peers that are sending garbled or incomplete chains." > > This, in context, and combined with your follow-up qualifiers, suggested a > level of checking beyond RFC 5280. Actually, no, I never did suggest anything like that. I'm simply following standards in an obvious and straightforward fashion. The relevant snippets from PKIX rfc5280, section 6: >From Section 6.2 Using the Path Validation Algorithm: While each certification path begins with a specific trust anchor, there is no requirement that all certification paths validated by a particular system share a single trust anchor. The selection of one or more trusted CAs is a local decision. A system may provide any one of its trusted CAs as the trust anchor for a particular path. The inputs to the path validation algorithm may be different for each path. The inputs to the "Basic Path Validation" algorithm in rfc5280, section 6.1 are described with: https://tools.ietf.org/html/rfc5280#page-73 To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions: (a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; (b) certificate 1 is issued by the trust anchor; (c) certificate n is the certificate to be validated (i.e., the target certificate); and (d) for all x in {1, ..., n}, the certificate was valid at the time in question. A certificate MUST NOT appear more than once in a prospective certification path. When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Information about trust anchors is provided as inputs to the certification path validation algorithm (Section 6.1.1). Since the TLS Certificate handshake message is *REQUIRED* to supply the certificate chain in order, it is only necessary to determine whether any issuer(!) on that list of ordered certificates is recognized as a locally available trust anchor, and then provide that trust anchor plus the certificates up to the one issued by the recognized trust anchor straight to the "Basic Path Validation" function. > >> rfc4158 is a pretty complex and dumb idea. AND, it is *NOT* a standard. >> It is explicitly ignored by PKIX (rfc5280). > > Only to the extent that RFC 5280 Section 6 deals specifically with the > validation of a given certification path, while leaving out of scope (but > acknowledged rather extensively throughout the documentation, especially > for extensions) the building/discovery of said paths. X.509 would require an omniscient trusted directory to perform certificate path discovery, and the Certificate Path Validation algorithm in rfc5280 section 6.1 clearly rules out AIA chasing as a permissible approach for certificate path discovery, because this approach would be clearly insecure and irresponsible. > > Indeed, Section 3.2 calls out some of the complexities and acknowledgement > that inherent in the PKI is the possibility of multiple certification > paths. Section 6.2 further acknowledges this. > > Merely I think it's a mistake and misleading to suggest that RFC 4158 is > an interesting side-note in the history of PKI, when in fact it describes > the behaviour of some of the largest (by end-user) clients out there > (Windows' CryptoAPI, Mozilla's NSS in various flavours, Java's > JCA/CertPath APIs). Sounds like plenty of security holes to exploit and many frantic patch days to come. -Martin From nobody Tue May 12 12:04:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DFC1A7034 for ; Tue, 12 May 2015 12:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 FN8vEo3eZd7T for ; Tue, 12 May 2015 12:04:54 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CAC21A1AA6 for ; Tue, 12 May 2015 12:04:54 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id C052A2AB37; Tue, 12 May 2015 21:04:52 +0200 (CEST) X-purgate-ID: 152705::1431457492-00005316-033EFE3B/0/0 X-purgate-size: 1115 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 609E94136C; Tue, 12 May 2015 21:04:52 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5470E1B2EB; Tue, 12 May 2015 21:04:52 +0200 (CEST) In-Reply-To: <5ec0a679151b6aad1473a8e1f4ee3e0d.squirrel@webmail.dreamhost.com> To: ryan-ietftls@sleevi.com Date: Tue, 12 May 2015 21:04:52 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512190452.5470E1B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:04:55 -0000 Now there would be a different *CORRECT* approach to the below problem, rather than the dirty hack you described, and that would be fully backwards compatible: Ryan Sleevi wrote: > > Now, with respect to cross-certificates, it's a regular occurrence to see > situations like > > (1) Leaf-signed-by-(2) > (2) Intermediate-signed-by-(3) > (3a) Intermediate-signed-by-(4) > (3b) Intermediate-signed-by-(5) > (4) Root 1 [an existing root] > (5) Root 2 [a new root applying for inclusion] > > In this case, valid paths are > [for old clients] > (1)+(2)+(3a)+(4) > > [for new clients] > (1)+(2)+(3b)+(5) > > The maximum compatibility with clients is > (1)+(2)+(3a)+(4)+(3b)+(5) The *CORRECT* approach would be to issue a cross-CA certificate for (5) Root 2 signed by (4) Root 1, lets call it (5b), and the correct path to send for servers would be (1)+(2)+(3b)+(5b)+(4) that would be fully conforming with the existing requirements, fully comprehensible for clients that feed the certificate_list from the Certificate handshake message into "Basic Path Validation". -Martin From nobody Tue May 12 12:07:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F32C1A87EF for ; Tue, 12 May 2015 12:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 cKRgLmhOJTl0 for ; Tue, 12 May 2015 12:07:17 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DA83F1A8703 for ; Tue, 12 May 2015 12:07:17 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 0BBDF2AC085; Tue, 12 May 2015 12:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=QHZOgKELVuZJ3nGvhPoOQ8FdaZI=; b=rvdsstMh1wVwyEWYk t1ZqOzxVU6ySotHkmpv2MPN7Ogtutbrl4IxntfNYzlAaHBw7SWEy7+FdB0VIrJtD 9aQOo0HaDEH0+IRj1Ni/p3LXfwOjwXpigM4HcwVeX8S5hBGqOC01fc1dsCIh26oM ntikzUVFIRN7hyMcaSiI8dVgxM= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id 024942AC06E; Tue, 12 May 2015 12:07:14 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 12:07:16 -0700 Message-ID: <17a92a9a6272ba2735dd0553fb527c3a.squirrel@webmail.dreamhost.com> In-Reply-To: <20150512190452.5470E1B2EB@ld9781.wdf.sap.corp> References: <20150512190452.5470E1B2EB@ld9781.wdf.sap.corp> Date: Tue, 12 May 2015 12:07:16 -0700 From: "Ryan Sleevi" To: mrex@sap.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:07:18 -0000 On Tue, May 12, 2015 12:04 pm, Martin Rex wrote: > The *CORRECT* approach would be to issue a cross-CA certificate > for (5) Root 2 signed by (4) Root 1, lets call it (5b), and > the correct path to send for servers would be > > (1)+(2)+(3b)+(5b)+(4) > > that would be fully conforming with the existing requirements, > fully comprehensible for clients that feed the certificate_list > from the Certificate handshake message into "Basic Path Validation". How did I know you would suggest this? Ah, because I addressed it in the original email, when I said "As much as you might wish to yell that they shouldn't have done (3a)/(3b= ) like that, and instead (5) should have been certified by (4), there are a large number of reasons why that doesn't happen, and the above is actuall= y quite common (I know of at least three different organizations who will have to go through the above flow right now to avoid issues)" So, moving on :) From nobody Tue May 12 12:14:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94F91A7034 for ; Tue, 12 May 2015 12:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 PWbuX05ro1mX for ; Tue, 12 May 2015 12:14:48 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB98F1A1AA6 for ; Tue, 12 May 2015 12:14:47 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id EDCA744450; Tue, 12 May 2015 21:14:45 +0200 (CEST) X-purgate-ID: 152705::1431458086-00005316-8092B018/0/0 X-purgate-size: 1639 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 9D27541376; Tue, 12 May 2015 21:14:45 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 8FB0A1B2EB; Tue, 12 May 2015 21:14:45 +0200 (CEST) In-Reply-To: <17a92a9a6272ba2735dd0553fb527c3a.squirrel@webmail.dreamhost.com> To: ryan-ietftls@sleevi.com Date: Tue, 12 May 2015 21:14:45 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512191445.8FB0A1B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:14:49 -0000 Ryan Sleevi wrote: > On Tue, May 12, 2015 12:04 pm, Martin Rex wrote: >> The *CORRECT* approach would be to issue a cross-CA certificate >> for (5) Root 2 signed by (4) Root 1, lets call it (5b), and >> the correct path to send for servers would be >> >> (1)+(2)+(3b)+(5b)+(4) >> >> that would be fully conforming with the existing requirements, >> fully comprehensible for clients that feed the certificate_list >> from the Certificate handshake message into "Basic Path Validation". > > How did I know you would suggest this? > > Ah, because I addressed it in the original email, when I said > > "As much as you might wish to yell that they shouldn't have done (3a)/(3b) > like that, and instead (5) should have been certified by (4), there are a > large number of reasons why that doesn't happen, and the above is actually > quite common (I know of at least three different organizations who will > have to go through the above flow right now to avoid issues)" there is no "shouldn't have done (3a)/(3b)". They can simple create that crossCA cert *NOW* and start distributing it, and things will work just fine. The problem with your original proposal is, that no *CORRECT* TLS implementation will allow you to send such junk in a TLS Certificate handshake message, so this will simply not be an option. Right now, we still have a stick to make that CA create such a crossCA cert. But you're not only asking to make client tolerate junk, you seem to be asking to actively break correct TLS implementations to start sending junk and create new interoperability problems. -Martin From nobody Tue May 12 12:16:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B3B1A7034 for ; Tue, 12 May 2015 12:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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_NONE=-0.0001] 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 rIXC6DzcNdR1 for ; Tue, 12 May 2015 12:16:14 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 181BF1A8940 for ; Tue, 12 May 2015 12:16:14 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id CDD752007E5A3; Tue, 12 May 2015 12:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=CRMmXqnnXVvhe3vBpVdnSqeQBBw=; b=XJJ+ovnZZJ0CGeEbx HFWocj9ffGTJ369iyIGLUZpT90GvqxSDIfm2XNVNfFrtQHcUyS6NGPcdXymVlU+h am4jdBkNAOtCOvz2WWTBQIQRbHQRc6K9DJ/NlikoqJZgN6VFXt/IANVr6N6UK/dg 3/c+kIYn/jbRuPCMyFIAcyGNKQ= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id 622AF2007E5A2; Tue, 12 May 2015 12:16:12 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 12:16:13 -0700 Message-ID: <8d15ecf26f59aecebe0e210c95e68cea.squirrel@webmail.dreamhost.com> In-Reply-To: <20150512185410.648121B2EB@ld9781.wdf.sap.corp> References: <20150512185410.648121B2EB@ld9781.wdf.sap.corp> Date: Tue, 12 May 2015 12:16:13 -0700 From: "Ryan Sleevi" To: mrex@sap.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:16:15 -0000 On Tue, May 12, 2015 11:54 am, Martin Rex wrote: > X.509 would require an omniscient trusted directory to perform certifi= cate > path discovery, and the Certificate Path Validation algorithm in > rfc5280 section 6.1 clearly rules out AIA chasing as a permissible > approach for certificate path discovery, because this approach would > be clearly insecure and irresponsible. Again, Martin, you're making unsubstantiated and inaccurate claims. To the extent it's relevant to the discussion for the TLS WG, I will simply note that RFC 5280 does not say anything about path discovery precisely because discovery is out of scope for validation. Validation is consistent, while discovery depends on a myriad of cases and protocols outside of the narrow view of TLS. e.g. the validation of certificates in PKCS#7 or in S/MIME. So yes, RFC 5280 doesn't discuss how to do path discovery, because it's out of scope, even though it repeatedly describes extensions and options for how to do path discovery *that rely on parsing the untrusted certificate* RFC 5280 does not call AIA chasing as insecure, and in fact, acknowledges it exists precisely to make discovery possible. However, to the points at hand, at least it establishes why you object to the change. You view it as predicated upon a fundamentally insecure algorithm. While I (and many others, as evidenced by implementation and discussion) would disagree with you, and I personally feel your claims of standards imprimatur to be lacking, it at least provides a clear rational= e for your disagreement. I don't think it'd be helpful for consensus building for me to try and demonstrate where I think even RFC 5280 would disagree with your conclusions, but if others feel themselves swayed by Martin's arguments, = I would be happy to add that fuel to the discussion. From nobody Tue May 12 12:22:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542961ACE81 for ; Tue, 12 May 2015 12:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFlTOntFc-aH for ; Tue, 12 May 2015 12:22:39 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 907861A8955 for ; Tue, 12 May 2015 12:22:38 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 5AB9C3B80A0; Tue, 12 May 2015 12:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=DADSz0rT/i6VOxfiXqOypwt/m94=; b=FazH5UpfOkPPZujHi k3YapaFk3WmoxFsRCF5EU/K2oUeJKyCan6Wia7z7QH5Kb9NDmiR9drc+bGJZFvK2 pPcgfuuRdZ2SkxrlE3uAmVGxlBXRwAR27i4UkAgpP+L12BBapCC40lxUBaUXinVR 7Y7asYcDb07yj7AJvK9+YYxJAc= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id 6A44C3B8057; Tue, 12 May 2015 12:22:37 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 12:22:38 -0700 Message-ID: In-Reply-To: <20150512191445.8FB0A1B2EB@ld9781.wdf.sap.corp> References: <20150512191445.8FB0A1B2EB@ld9781.wdf.sap.corp> Date: Tue, 12 May 2015 12:22:38 -0700 From: "Ryan Sleevi" To: mrex@sap.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:22:41 -0000 On Tue, May 12, 2015 12:14 pm, Martin Rex wrote: > there is no "shouldn't have done (3a)/(3b)". They can simple create > that crossCA cert *NOW* and start distributing it, and things will > work just fine. Again, that's an assumption about the possibilities of change that are no= t bourne out by the realities of the PKI. In a variety of circumstances, there are actively reasons why creating a crossCA is *not* valid or will *not* resolve issues for clients. In particular, issuing such a cross-CA may violate appropriate WebTrust or ETSI guidelines that CAs are required to adhere to, or violate the CA's own CP/CPS. I'm sure that's an invitation for more decrying, but it's the reality we live in, and compared to the alternatives, it's actually a *good* thing, even if it makes spec purity hard. > The problem with your original proposal is, that no *CORRECT* TLS > implementation will allow you to send such junk in a TLS Certificate > handshake message, so this will simply not be an option. Not an option conforming with the TLS spec, I fully acknowledge. But it's an area where a number of clients never implemented (again, layering - it's more work and more attack surface to actually enforce tha= t requirement), and it's an area where a number of servers actively ignore because "working for clients" is more important than theoretical spec purity. Which is sort of why we're here discussing this in the first place - whether or not we want to acknowledge reality or not. But I don't think we're making productive progress here, so it's probably worth me bowing out. It does seem like we're at a fundamental and ideological impasse with regards to path discovery, and while I can try t= o convince you that RFC 4158-like behaviours are good for all clients, I suspect neither this list nor this issue is the right medium for it. I leave it up to the editors & chairs to evaluate consensus, the relevant arguments for and against, and the behaviours of clients (both for and against). From nobody Tue May 12 12:29:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4011A87BB for ; Tue, 12 May 2015 12:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 t_ez1OFkvWCz for ; Tue, 12 May 2015 12:29:54 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93CC1A87B0 for ; Tue, 12 May 2015 12:29:53 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 69BEE2A8C0; Tue, 12 May 2015 21:29:51 +0200 (CEST) X-purgate-ID: 152705::1431458991-0000413A-C2791023/0/0 X-purgate-size: 2724 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D8EAB41399; Tue, 12 May 2015 21:29:50 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C93F21B2EB; Tue, 12 May 2015 21:29:50 +0200 (CEST) In-Reply-To: <8d15ecf26f59aecebe0e210c95e68cea.squirrel@webmail.dreamhost.com> To: ryan-ietftls@sleevi.com Date: Tue, 12 May 2015 21:29:50 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:29:56 -0000 Ryan Sleevi wrote: > On Tue, May 12, 2015 11:54 am, Martin Rex wrote: > > X.509 would require an omniscient trusted directory to perform certificate > > path discovery, and the Certificate Path Validation algorithm in > > rfc5280 section 6.1 clearly rules out AIA chasing as a permissible > > approach for certificate path discovery, because this approach would > > be clearly insecure and irresponsible. > > Again, Martin, you're making unsubstantiated and inaccurate claims. > > To the extent it's relevant to the discussion for the TLS WG, I will > simply note that RFC 5280 does not say anything about path discovery > precisely because discovery is out of scope for validation. Validation is > consistent, while discovery depends on a myriad of cases and protocols > outside of the narrow view of TLS. e.g. the validation of certificates in > PKCS#7 or in S/MIME. > > So yes, RFC 5280 doesn't discuss how to do path discovery, because it's > out of scope, even though it repeatedly describes extensions and options > for how to do path discovery *that rely on parsing the untrusted > certificate* *Parsing* an untrusted certificate is not the problem. But doing _more_ than comparing contents to something you trust is where the security problem starts. > > RFC 5280 does not call AIA chasing as insecure, and in fact, acknowledges > it exists precisely to make discovery possible. With the prerequisite of a conscious and informed active consent by a human administrator during out-of-band maintenance/administration, using AIA to download a certificate can be an accetable security trade-off. But a machine/automata/algorithm that will automatically download objects from URLs from still-untrusted data provided by the peer is definitely insecure and irresponsible. > > However, to the points at hand, at least it establishes why you object to > the change. You view it as predicated upon a fundamentally insecure > algorithm. While I (and many others, as evidenced by implementation and > discussion) would disagree with you, and I personally feel your claims of > standards imprimatur to be lacking, it at least provides a clear rationale > for your disagreement. > > I don't think it'd be helpful for consensus building for me to try and > demonstrate where I think even RFC 5280 would disagree with your > conclusions, but if others feel themselves swayed by Martin's arguments, I > would be happy to add that fuel to the discussion. I'm still waiting for an example why you would need to send junk in the Certificate handshake message, which could not be avoided by the offending CAs issuing proper crossCAs instead. -Martin From nobody Tue May 12 12:52:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FA81A8955 for ; Tue, 12 May 2015 12:52:58 -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 tocJ7O113S5V for ; Tue, 12 May 2015 12:52:52 -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 291E31A87D2 for ; Tue, 12 May 2015 12:52:52 -0700 (PDT) Received: by wizk4 with SMTP id k4so169088450wiz.1 for ; Tue, 12 May 2015 12:52:50 -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=4j1d17QOLRpMhcgPfymCTYit98ibZW3ToQpW1A0ResU=; b=PUjDvPiWFRAD0jPgXjD1+zsYJL1HuupgxFya3sasicAopIKLLVNmjKzVZuBXgAPM1E DDZsJTGEXfAyWjJJbke8QzQCDMQaHXRoGowdGwmezY8XBO0Dg06Q39IWKWEu4As8XK3k 4FRsjy71i/ZmMjVViRqAEqKSs2pxEnHOyYpKbrOTdURgIOC7yLv6osKUMHqRopxtLdV2 uvQ9vVbLBM+1dKsYDJCEu3mENeV16qZmqdBgExPhUAQbPTO7SImB5xySXFrHCHgiRNeq wXY0iQu8ldRXMx4oWPW6/bZRTIobnjUPEIkJwefb0pA2bKY74MwZE5X823ZoeGZGRR/p XS8A== X-Received: by 10.194.187.15 with SMTP id fo15mr33741706wjc.100.1431460370787; Tue, 12 May 2015 12:52:50 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id bh7sm29262991wjb.8.2015.05.12.12.52.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 May 2015 12:52:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> Date: Tue, 12 May 2015 22:52:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <939995E0-4ED0-479A-8B3A-628FE2C8C31B@gmail.com> References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:52:58 -0000 >=20 > But a machine/automata/algorithm that will automatically download = objects > from URLs from still-untrusted data provided by the peer is definitely > insecure and irresponsible. >=20 In that sense, how is AIA different from revocation checking? Whether = you use CRLs or OCSP, you=E2=80=99re following a URL in the (still = untrusted or at least possibly revoked) certificate to retrieve an = object. Yoav From nobody Tue May 12 13:04:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611DC1A88ED for ; Tue, 12 May 2015 13:04: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 bIP_cX7MjEB3 for ; Tue, 12 May 2015 13:04:03 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 979341A8A08 for ; Tue, 12 May 2015 13:04:03 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 62011F984; Tue, 12 May 2015 16:04:01 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 01EB920624; Tue, 12 May 2015 16:03:36 -0400 (EDT) From: Daniel Kahn Gillmor To: mrex@sap.com, ryan-ietftls@sleevi.com In-Reply-To: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> User-Agent: Notmuch/0.20~rc1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 12 May 2015 16:03:36 -0400 Message-ID: <87lhgtbm1z.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:04:05 -0000 On Tue 2015-05-12 15:29:50 -0400, Martin Rex wrote: > With the prerequisite of a conscious and informed active consent by a human > administrator during out-of-band maintenance/administration, using AIA to > download a certificate can be an accetable security trade-off. > > But a machine/automata/algorithm that will automatically download objects > from URLs from still-untrusted data provided by the peer is definitely > insecure and irresponsible. Doesn't this argument suggest that we should go ahead and relax the text as suggested? If: * automated cert fetching is bad (i'm inclined to agree with you about this, Martin, since it would embed www-like promiscuous network activity in protocols that don't currently suffer from it), and * cert validation is hard (as evidenced by the litany of problems people have getting it right), and * no unified/global trust anchor exists (because people have different perspectives on the world), and * servers don't know what the clients preferred trust anchors are (and probably shouldn't require the client to announce this perspective to perform a TLS handshake, for privacy reasons), and * we need to be able to upgrade existing PKI smoothly, because breaking existing clients will prevent most deployers from ever upgrading anything, Then: * it seems like we ought to explicitly permit servers to ship the certificates capable of forming multiple verification chains in the TLS handshake, so that clients have all the certs they need to find their preferred path, without having to do AIA fetching. Given that servers *already do this*, the argument seems even stronger. I agree with Martin that this is super-dirty and a far more complex system than anyone sane would have designed from first principles. But i still think it's the right thing to do given the ugly state of the network today. --dkg From nobody Tue May 12 13:23:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89E01AD069; Tue, 12 May 2015 13:23:42 -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 O_lC0RXpsyEp; Tue, 12 May 2015 13:23:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 716A61AD060; Tue, 12 May 2015 13:23:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150512202341.6056.59460.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 13:23:41 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:23:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-ff-dhe-09.txt Pages : 26 Date : 2015-05-12 Abstract: Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "EC Named Curve Registry" to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 12 13:37:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B171AD072 for ; Tue, 12 May 2015 13:37:20 -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 vKzzAaf05PdT for ; Tue, 12 May 2015 13:37:19 -0700 (PDT) Received: from ipesa2.cygnacom.com (ipesa2.cygnacom.com [65.242.48.201]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB14A1AD06F for ; Tue, 12 May 2015 13:37:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEABJjUlUKPDLZ/2dsb2JhbABcg2NeBsZ7CoYFAoIMAQEBAQEBgQuEIAEBAQQBAQE3NAsMBAIBCA0EBAEBAR4FBAcnCxQJCAIEAQ0FCIgpCModAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLOYQ6CUIHBoQnBZ5dhlKEfIYmg1WBBIEjNoE9b4EDAgUfHIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,417,1427774400"; d="scan'208";a="90985" Received: from unknown (HELO svaexch2.cygnacom.com) ([10.60.50.217]) by ipesa2.cygnacom.com with ESMTP; 12 May 2015 16:37:18 -0400 Received: from svaexch1.cygnacom.com (10.60.50.216) by svaexch2.cygnacom.com (10.60.50.217) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 12 May 2015 16:37:16 -0400 Received: from svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e]) by svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e%12]) with mapi id 15.00.1076.000; Tue, 12 May 2015 16:37:16 -0400 From: Santosh Chokhani To: Daniel Kahn Gillmor , "mrex@sap.com" , "ryan-ietftls@sleevi.com" Thread-Topic: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) Thread-Index: AQHQieY/gmukibBgKEmnwP9D0xEiS513auKA//+u2OCAAEnXAIABNvSAgABKNACAABSYAIAABimAgAADzgCAAAlvAP//weOQ Date: Tue, 12 May 2015 20:37:15 +0000 Message-ID: <9f4a6b908fe044c5af767c0e2646f1b3@svaexch1.cygnacom.com> References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <87lhgtbm1z.fsf@alice.fifthhorseman.net> In-Reply-To: <87lhgtbm1z.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.117.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:37:21 -0000 I do not have objections to server sending a certificate bag so that one or= more paths can be formed/built/discovered by the client. However, I disagree with several things Martin says about AIA chasing and R= FC 4158. To me, most of what he says has been argued on PKIX and I do not = see any security concerns. While one can argue that SIA chasing is ideal s= ince your next step is always from a vetted pointer, as others have pointed= out CRL DP and OCSP situation is no different. If the AIA pointer has poi= soned data in it, you will not decode the certificate or the certificate ba= g correctly. Besides in a cross-certified world, a server has one view of the trust anch= ors and a client might reside in cross-certified domain, necessitating AIA = chasing on some CA certificate at some point. If you like, clients can do = SIA chasing, but not many folks implement SIA on the producer side (i.e., t= he CAs) or on the consumer side (i.e., the TLS client). In that scenario, = there would be no need for the server to send certificate chain or bag; sim= ply server certificate will suffice. BTW, while not related to validating the server certificate, some of the po= pular browsers have had issues in the area of client authenticated TLS, whe= re the browser will not even present a legitimate client certificate since = it terminates on a trust anchor from the browser's perspective and that tru= st anchor not being in the server's hints list, albeit server can build a p= ath to the client certificate. Again, this is endemic to cross-certified e= nvironments. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor Sent: Tuesday, May 12, 2015 4:04 PM To: mrex@sap.com; ryan-ietftls@sleevi.com Cc: TLS@ietf.org (tls@ietf.org) Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirement= s to match current practice (#169) On Tue 2015-05-12 15:29:50 -0400, Martin Rex wrote: > With the prerequisite of a conscious and informed active consent by a=20 > human administrator during out-of-band maintenance/administration,=20 > using AIA to download a certificate can be an accetable security trade-of= f. > > But a machine/automata/algorithm that will automatically download=20 > objects from URLs from still-untrusted data provided by the peer is=20 > definitely insecure and irresponsible. Doesn't this argument suggest that we should go ahead and relax the text as= suggested? If: * automated cert fetching is bad (i'm inclined to agree with you about this, Martin, since it would embed www-like promiscuous network activity in protocols that don't currently suffer from it), and * cert validation is hard (as evidenced by the litany of problems people have getting it right), and * no unified/global trust anchor exists (because people have different perspectives on the world), and * servers don't know what the clients preferred trust anchors are (and probably shouldn't require the client to announce this perspective to perform a TLS handshake, for privacy reasons), and * we need to be able to upgrade existing PKI smoothly, because breaking existing clients will prevent most deployers from ever upgrading anything, Then: * it seems like we ought to explicitly permit servers to ship the certificates capable of forming multiple verification chains in the TLS handshake, so that clients have all the certs they need to find their preferred path, without having to do AIA fetching. Given that servers *already do this*, the argument seems even stronger. I agree with Martin that this is super-dirty and a far more complex system = than anyone sane would have designed from first principles. But i still th= ink it's the right thing to do given the ugly state of the network today. --dkg _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue May 12 13:51:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6D1AD1A6 for ; Tue, 12 May 2015 13:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-5, 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 2g9UKZwOP8qk for ; Tue, 12 May 2015 13:51:33 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6A41AD0C6 for ; Tue, 12 May 2015 13:51:32 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id F364744704; Tue, 12 May 2015 22:51:30 +0200 (CEST) X-purgate-ID: 152705::1431463891-0000413A-F0D8DC97/0/0 X-purgate-size: 1502 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id DB8BB412A8; Tue, 12 May 2015 22:51:30 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CBCF61B2EB; Tue, 12 May 2015 22:51:30 +0200 (CEST) In-Reply-To: <939995E0-4ED0-479A-8B3A-628FE2C8C31B@gmail.com> To: Yoav Nir Date: Tue, 12 May 2015 22:51:30 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512205130.CBCF61B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:51:40 -0000 Yoav Nir wrote: [ Charset UTF-8 unsupported, converting... ] > >> >> But a machine/automata/algorithm that will automatically download objects >> from URLs from still-untrusted data provided by the peer is definitely >> insecure and irresponsible. > > In that sense, how is AIA different from revocation checking? > Whether you use CRLs or OCSP, you?re following a URL in the > (still untrusted or at least possibly revoked) certificate > to retrieve an object. Possibly revoked? yes. Untrusted? *NO*. Look at the algorithm in rfc5280 again. https://tools.ietf.org/html/rfc5280#section-6.1.3 6.1.3. Basic Certificate Processing The basic path processing actions to be performed for certificate i (for all i in [1..n]) are listed below. (a) Verify the basic certificate information. The certificate MUST satisfy each of the following: (1) The signature on the certificate can be verified using working_public_key_algorithm, the working_public_key, and the working_public_key_parameters. (2) The certificate validity period includes the current time. (3) At the current time, the certificate is not revoked. This may be determined by obtaining the appropriate CRL (Section 6.3), by status information, or by out-of-band mechanisms. (4) The certificate issuer name is the working_issuer_name. -Martin From nobody Tue May 12 14:09:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CBF1AD17F for ; Tue, 12 May 2015 14:09:35 -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 Uj5Y4yIda_P8 for ; Tue, 12 May 2015 14:09:33 -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 E0CF11AD259 for ; Tue, 12 May 2015 14:08:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 535AE283031; Tue, 12 May 2015 21:08:31 +0000 (UTC) Date: Tue, 12 May 2015 21:08:31 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150512210831.GQ17272@mournblade.imrryr.org> References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <87lhgtbm1z.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lhgtbm1z.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:09:35 -0000 On Tue, May 12, 2015 at 04:03:36PM -0400, Daniel Kahn Gillmor wrote: > Doesn't this argument suggest that we should go ahead and relax the text > as suggested? > > If: > > * automated cert fetching is bad (i'm inclined to agree with you about > this, Martin, since it would embed www-like promiscuous network > activity in protocols that don't currently suffer from it), and > > * cert validation is hard (as evidenced by the litany of problems > people have getting it right), and > > * no unified/global trust anchor exists (because people have different > perspectives on the world), and > > * servers don't know what the clients preferred trust anchors are (and > probably shouldn't require the client to announce this perspective to > perform a TLS handshake, for privacy reasons), and > > * we need to be able to upgrade existing PKI smoothly, because breaking > existing clients will prevent most deployers from ever upgrading > anything, > > Then: > > * it seems like we ought to explicitly permit servers to ship the > certificates capable of forming multiple verification chains in the > TLS handshake, so that clients have all the certs they need to find > their preferred path, without having to do AIA fetching. > > Given that servers *already do this*, the argument seems even stronger. I don't know which clients choke on bags/heaps of certificates rather than linear chains. OpenSSL tolerates a heap. However, as mentioned previously for OpenSSL clients, the heap contains an equivalent chain that works equally well for those clients. Thus one can take a middle ground, where servers are allowed to send non-chains (heaps/bags/...), but clients are *not* required or expected to try all possible paths. To the extent that some clients try multiple paths, the server operator may benefit from such a configuration, but various clients will build some single path out of the heap and either succeed or fail with that. Allowing servers to send a heap seems mostly harmless, provided we're not also *requiring* clients to do the full combinatorial explosion path construction. If the extent of the change is to allow mutually consenting clients and servers to play that game, I have no objections. That does of course introduce possible harm to clients that simply don't work when given a heap even to the extent of building a single candidate chain. No idea whether such clients are a significant obstacle. -- Viktor. From nobody Tue May 12 14:11:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C891A901D for ; Tue, 12 May 2015 14:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_32=0.6, 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 xtE2qzCbVrLW for ; Tue, 12 May 2015 14:11:49 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79771A8A87 for ; Tue, 12 May 2015 14:11:48 -0700 (PDT) Received: by wgnd10 with SMTP id d10so21262684wgn.2 for ; Tue, 12 May 2015 14:11:47 -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=O2WqTsAJ5JUxrmJcPW8pOrzswcAZOy1c1a2dyP6qXWw=; b=tXnzOPOrlBwt4EFH6bWhVKPqTOgEJQ3ofBhVdAc6V1krIKcZ32Sev7hs/AMdkE5HKV O7MPMVGajhtC+QGNvKFP5hLpxplAOcLHNe/9ISWqwBYD2kB4xNmNILV3MbT4xdIypI1J ZNMOld0p58pEF9O1WYxf9VdLAcruhN+8CG8iNeg72RUvuvsEVb7ttj87Zff9vJJ7+4AW MifWPy/hwuWmv7vzjwF1pLnW2bdVMs8Vc3ITmxTWag4DF4AoWxAUu4rFmuz8F8Ok6MkM c9ES2hbFrbCO6VZI7BLqHfbJjNLjOky/GgrTwXeb6TTfGnGpQgF10FEiHpTsc86uQMOw FWDw== X-Received: by 10.180.84.201 with SMTP id b9mr32467268wiz.28.1431465107540; Tue, 12 May 2015 14:11:47 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id fa8sm4665590wib.14.2015.05.12.14.11.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 May 2015 14:11:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <20150512205130.CBCF61B2EB@ld9781.wdf.sap.corp> Date: Wed, 13 May 2015 00:11:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150512205130.CBCF61B2EB@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:11:50 -0000 > On May 12, 2015, at 11:51 PM, Martin Rex wrote: >=20 > Yoav Nir wrote: > [ Charset UTF-8 unsupported, converting... ] >>=20 >>>=20 >>> But a machine/automata/algorithm that will automatically download = objects >>> from URLs from still-untrusted data provided by the peer is = definitely >>> insecure and irresponsible. >>=20 >> In that sense, how is AIA different from revocation checking? >> Whether you use CRLs or OCSP, you?re following a URL in the >> (still untrusted or at least possibly revoked) certificate >> to retrieve an object. >=20 > Possibly revoked? yes. >=20 > Untrusted? *NO*. Look at the algorithm in rfc5280 again. In case a CA mis-issues a certificate, such as when giving someone who = is decidedly not Microsoft a certificate for www.microsoft.com, what it = should do is to revoke that certificate. That=E2=80=99s the only way to = un-emit the certificate other than patch all relying parties. So as long = as you haven=E2=80=99t checked revocation, the certificate is not only = potentially revoked (someone stole my private key), it=E2=80=99s also = potentially mis-issued.=20 I think the section you quote below says that. You haven=E2=80=99t done = path validation until you=E2=80=99ve checked revocation for every = certificate. > https://tools.ietf.org/html/rfc5280#section-6.1.3 >=20 > 6.1.3. Basic Certificate Processing >=20 >=20 > The basic path processing actions to be performed for certificate i > (for all i in [1..n]) are listed below. >=20 > (a) Verify the basic certificate information. The certificate > MUST satisfy each of the following: >=20 > (1) The signature on the certificate can be verified using > working_public_key_algorithm, the working_public_key, and > the working_public_key_parameters. >=20 > (2) The certificate validity period includes the current = time. >=20 > (3) At the current time, the certificate is not revoked. = This > may be determined by obtaining the appropriate CRL > (Section 6.3), by status information, or by out-of-band > mechanisms. >=20 > (4) The certificate issuer name is the working_issuer_name. >=20 >=20 >=20 > -Martin From nobody Tue May 12 14:23:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9C91ACD10 for ; Tue, 12 May 2015 14:23: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 xncdaROrt77K for ; Tue, 12 May 2015 14:23:33 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 5FC6D1ACCF2 for ; Tue, 12 May 2015 14:23:33 -0700 (PDT) Received: by qku63 with SMTP id 63so15506932qku.3 for ; Tue, 12 May 2015 14:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=tGvkzihuE9ZcgldHr824EaK4E5XQYM+Q5/0gXsLc+7M=; b=gwFLiSm88dn6rlF9NO5npdzwDJrCveabuGOt0uX3ZgjlMmPfFEPPCxhXuWXA+UgOmN JAYpTvN2JGWfMqbKGoiLCBh0tuiZcCRGhcM8+vi6SJXNaILVBAf1Swq4tNJy65HWTqcS dVG5iD5nAb8KkDySN20jOBrJvtYUZDdPt6mtt6Ke523LBkdBz0p2cw2m2x1Qpq39azcs c11k6Sihrbo2wjnSobK7CqxkI8F4o1f9+x2jHY5MrkIF7A70nPvJ9EsvKaJBjsReKDYa Y/4cdfNNnfvPGQrdE7uZ1mYbd/5NwwEafmx6zR7SKDnn+W3u8910qn9SM7u+3oJYjynQ FCuA== X-Received: by 10.55.18.17 with SMTP id c17mr37775467qkh.25.1431465812692; Tue, 12 May 2015 14:23:32 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 21sm14126983qhy.1.2015.05.12.14.23.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 12 May 2015 14:23:32 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 12 May 2015 17:23:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <87lhgtbm1z.fsf@alice.fifthhorseman.net> <20150512210831.GQ17272@mournblade.imrryr.org> In-Reply-To: <20150512210831.GQ17272@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505121723.30855.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:23:35 -0000 On Tuesday, May 12, 2015 05:08:31 pm Viktor Dukhovni wrote: > Thus one can take a middle ground, where servers are allowed to > send non-chains (heaps/bags/...), but clients are *not* required > or expected to try all possible paths. To the extent that some > clients try multiple paths, the server operator may benefit from > such a configuration, but various clients will build some single > path out of the heap and either succeed or fail with that. > > Allowing servers to send a heap seems mostly harmless, provided > we're not also *requiring* clients to do the full combinatorial > explosion path construction. If the extent of the change is > to allow mutually consenting clients and servers to play that > game, I have no objections. The current proposal is that implementations SHOULD support lists that are not strictly linear, but not MUST. Implementations would still be permitted to reject cert lists they can't handle, for whatever reason. Dave From nobody Tue May 12 14:32:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3661A9127 for ; Tue, 12 May 2015 14:32:01 -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 aVdMUP1iSncj for ; Tue, 12 May 2015 14:32:00 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBDF81A90DB for ; Tue, 12 May 2015 14:31:58 -0700 (PDT) Received: by qcyk17 with SMTP id k17so12422434qcy.1 for ; Tue, 12 May 2015 14:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=Mk6pcYVs9nx0UHPhX9WtHKjXIQUAxnD9n4vOLsMP74Y=; b=fZhbh4VrRZMDqCQ44OUfFddlxOszjwJXpOClkzy2tEEDm2DrQjwt9EIvpnCMIL7fXL U88X3jITouFStJh0L5mZ/tH/+SYAU2e6+0oJzSrPG9KNgDB8p9PRYTrbaV5tiVrDONVZ UH8XkzaDFHHKo/UtTNcE9iLRcP6ApMk5e0wud/HHSK6BHQstaJuuEEhh1jajLOagIzPk YWSeIdii37m1QPlrzg0p3DO0cwOMTR+zAs/TheAeOwk3Nbrc8SWsqvaomCkpeot5jAHb Oe62EdE0B+8ezlLVx7Q3Nt8zFGQsU6IvEZiJ3bPM4qwr7ypd0e/B+IM20wLE0LhPAjNu uiMg== X-Received: by 10.55.22.88 with SMTP id g85mr37344263qkh.48.1431466318207; Tue, 12 May 2015 14:31:58 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 38sm14129961qkt.2.2015.05.12.14.31.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 12 May 2015 14:31:57 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, ryan-ietftls@sleevi.com Date: Tue, 12 May 2015 17:31:56 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201505121731.56644.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:32:02 -0000 I've added some general additional language to the PR to add more detail explaining the changes. If there's anything that needs to be changed in order to make this as clear as needed, please comment on the PR. (e.g. we might want to add more specifics) https://github.com/tlswg/tls13-spec/pull/169/files Dave From nobody Tue May 12 14:39:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3901A9035 for ; Tue, 12 May 2015 14:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 qQ41W7KhvqBH for ; Tue, 12 May 2015 14:39:21 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA861AD151 for ; Tue, 12 May 2015 14:38:55 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 5EA4344362; Tue, 12 May 2015 23:38:53 +0200 (CEST) X-purgate-ID: 152705::1431466733-00000B48-E63B16F8/0/0 X-purgate-size: 778 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4AAA34141E; Tue, 12 May 2015 23:38:53 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 435ED1B2EB; Tue, 12 May 2015 23:38:53 +0200 (CEST) In-Reply-To: <201505121731.56644.davemgarrett@gmail.com> To: Dave Garrett Date: Tue, 12 May 2015 23:38:53 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512213853.435ED1B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:39:22 -0000 Dave Garrett wrote: > I've added some general additional language to the PR to add more > detail explaining the changes. If there's anything that needs to be > changed in order to make this as clear as needed, please comment > on the PR. (e.g. we might want to add more specifics) > > https://github.com/tlswg/tls13-spec/pull/169/files One of the worst problems in your proposed text is the replacment of the term "self-signed [...] root certificate authority" with two bogus occurrences of the term "trust anchor". Trust anchor is a _strictly_ local concept, so this term MUST NOT be used in the description of the TLS Certificate PDU. self-signed root certificate authority is a simple technical term, that does *NOT* imply trust by any party. -Martin From nobody Tue May 12 14:46:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27641A9130 for ; Tue, 12 May 2015 14:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 aPQwi19GR8Nl for ; Tue, 12 May 2015 14:46:01 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4D71A9127 for ; Tue, 12 May 2015 14:46:01 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 4204844631 for ; Tue, 12 May 2015 23:46:00 +0200 (CEST) X-purgate-ID: 152705::1431467160-00005316-5569D7E1/0/0 X-purgate-size: 1302 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 35B3F41303 for ; Tue, 12 May 2015 23:46:00 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2B9191B2EB; Tue, 12 May 2015 23:46:00 +0200 (CEST) In-Reply-To: <20150512210831.GQ17272@mournblade.imrryr.org> To: tls@ietf.org Date: Tue, 12 May 2015 23:46:00 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512214600.2B9191B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:46:03 -0000 Viktor Dukhovni wrote: > On Tue, May 12, 2015 at 04:03:36PM -0400, Daniel Kahn Gillmor wrote: >> Then: >> >> * it seems like we ought to explicitly permit servers to ship the >> certificates capable of forming multiple verification chains in the >> TLS handshake, so that clients have all the certs they need to find >> their preferred path, without having to do AIA fetching. >> >> Given that servers *already do this*, the argument seems even stronger. > > Allowing servers to send a heap seems mostly harmless, provided > we're not also *requiring* clients to do the full combinatorial > explosion path construction. To the contrary, allowing servers to send a heap is the opening of a rotten can of worms. Next you see defective clients use that as an excuse for not fixing e.g. their lack of recognizing a trust anchor when it is included as crossCA variant in the certificate_list. Next you see the users of particular broken, unfixed clients asking why they can not configure a particular heap of junk, to cater their broken clients, with a particular perfectly correct TLS implementation (that properly encodes only a linear list of certificates into certificate_list). Really, with the proposed change, the shit already hits the fan. -Martin From nobody Tue May 12 14:50:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E951AD324 for ; Tue, 12 May 2015 14:50: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 oUxQ499D8Egv for ; Tue, 12 May 2015 14:50:54 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 008E71A9173 for ; Tue, 12 May 2015 14:50:54 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 0AF48F984 for ; Tue, 12 May 2015 17:50:50 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id AB07B20624; Tue, 12 May 2015 17:50:26 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF TLS Working Group User-Agent: Notmuch/0.20~rc1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 12 May 2015 17:50:25 -0400 Message-ID: <873831bh3y.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [TLS] changes to draft-ietf-tls-negotiated-ff-dhe-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:50:55 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi TLS folks-- As a result of ongoing feedback, i've made several more minor changes to draft-ietf-tls-negotiated-ff-dhe, which are now visible in version 09 of that document. There were several minor nits addressed, but the following minor changes are slightly more than nits: * the draft clarifies that the named ffdhe* groups do have a small subgroup, but that it is easily avoided (as opposed to custom groups, in which possible small subgroups are either unknown or expensive to avoid).=20=20 * slight tuning of some of the RFC 2119 language. * explicitly relaxing the old requirement that the Supported Groups extension needed to be sent only when ECDHE ciphersuites were offered, which no one appears to have followed anyway * Added a new section describing local policy for compatible clients that are considering accepting custom groups from the server, with baseline guidance for how to protect users by at least ensuring that the length of the group is minimally strong (no attempt is made to enumerate all possible local policy or to claim there is only one legitimate local policy). * encourage bounds checking of the public share against the group modulus, regardless of whether a named group is used. Thanks to all the folks who gave feedback on the draft. Regards, --dkg =20=20=20 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJVUnWiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcDaMQANUkwffhNvIElpHyIgwYuMMn tEKd1syXF+rSHyl/42yorPX2yzMZ7LVDah85wJthfMXYBA32g6F0QeaOvcjbwFFl /neVeaIfdiLdqCFJWiLl9L9HqN9kKFtEdk2OOHBc5NrwOAHzPkIRwXEHDQ7bZd+O 4LTDKVhTe0R5MZ7PYUeBH6WWZ0SP21cXlX/BNKOK3dZ2n8s8vvioRPE0GCXLbP4o 524wzomUa0QWiiByo/HGBaflsp5p9PiA6YOL9Ef9VcLN3GKWG2qXSptYwiNKe27Y pDCVwCnDmbOJNzChLkl/anR6WWo89rOtPBj+dWpKSdOpGN+g8Ptmg6Glvn4wjwkE tDhXyQhQUMEtrqUKKDr+QJ7rQDB/dCTSIoQUAhGLv6BXMd7/VDESfZRZ0dkCQFld wQElTB1LYHUEOjyH4GCR63mO2bL5C96BtDPiROGP+QMB/8G+Mr5IowioygPd1ndn gcgRH2FKWUS3WQYEeSHskHfDBfHHS8q6Cn+WXSOV2T45s8HUHvlkc7rvJ90PR4+I f6xyQbLMnVkveMv84RhS73fmmz0ejh1x2c76ATkRvyrf4GPNTbaK6fT4+rPGyu2i JUHIypMGLK0b2qV/A7xufRAI3HQpKZPJefWWULHu7cYTpX73TApDOrUDkdOjuovW TzON/FESPmd99kKXX9rT =FT2M -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 12 15:03:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204871AD358 for ; Tue, 12 May 2015 15:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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_NONE=-0.0001] 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 JY1sxf_Sx0zT for ; Tue, 12 May 2015 15:03:16 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E6ABA1AD356 for ; Tue, 12 May 2015 15:03:16 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id A2E9F6740D9; Tue, 12 May 2015 15:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=tvEOo9JN6YeFOQNDZ4MGR0Av61M=; b=fCiXg2xnEFPv8F+vd Rw1/hNc1lKA1e5dmwLP5Ml3o76gGyoSdbs/2hizL2w9Z8vKULqPyXlpsBvXU56Ca um1fNdyTaTjXmFE0RX8x5L9PIHCuXsgQ+475Hso3Wh1hFQFgXUfgnMymAlctzz04 UWrtvdqajEvzbvMQnBD4rD7y2A= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id 3145767409D; Tue, 12 May 2015 15:03:16 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 15:03:16 -0700 Message-ID: In-Reply-To: <20150512213853.435ED1B2EB@ld9781.wdf.sap.corp> References: <20150512213853.435ED1B2EB@ld9781.wdf.sap.corp> Date: Tue, 12 May 2015 15:03:16 -0700 From: "Ryan Sleevi" To: mrex@sap.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 22:03:18 -0000 On Tue, May 12, 2015 2:38 pm, Martin Rex wrote: > One of the worst problems in your proposed text is the replacment > of the term "self-signed [...] root certificate authority" with > two bogus occurrences of the term "trust anchor". > > Trust anchor is a _strictly_ local concept, so this term > MUST NOT be used in the description of the TLS Certificate PDU. > > self-signed root certificate authority is a simple technical term, > that does *NOT* imply trust by any party. > > -Martin > Martin, You will find the reasoning already provided in past messages for why thi= s proposed terminology change. "self-signed root certificate authority" is, unquestionably, NOT a simple technical term (considering how many times i= t has confused people, I should think this obvious). Please do re-read the message is which I provided the justification for this change, and hopefully provide counter-factual evidence if there is any. Considering that "trust anchor" is a term extensively used in RFC 5280, I also fail to understand your objection about it being a "local only" concept. This is entirely in line with the current language where you can omit certificates that you know your peer does not need. I'm happy to work to resolve the objections, but I can't help but feel like some, like this, aren't well justified or supported. From nobody Tue May 12 15:30:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8660A1A90AA for ; Tue, 12 May 2015 15:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.751 X-Spam-Level: X-Spam-Status: No, score=-4.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-5, 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 VdlPrfB2mpdG for ; Tue, 12 May 2015 15:30:38 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727D51AD356 for ; Tue, 12 May 2015 15:30:36 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id CBF582AA0B; Wed, 13 May 2015 00:30:34 +0200 (CEST) X-purgate-ID: 152705::1431469834-0000413A-03064581/0/0 X-purgate-size: 5144 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id B7A0E413F8; Wed, 13 May 2015 00:30:34 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id ACC2C1B2EB; Wed, 13 May 2015 00:30:34 +0200 (CEST) In-Reply-To: To: Yoav Nir Date: Wed, 13 May 2015 00:30:34 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512223034.ACC2C1B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 22:30:41 -0000 Yoav Nir wrote: > >> Martin Rex wrote: >> >> Yoav Nir wrote: >>> >>>> But a machine/automata/algorithm that will automatically download objects >>>> from URLs from still-untrusted data provided by the peer is definitely >>>> insecure and irresponsible. >>> >>> In that sense, how is AIA different from revocation checking? >>> Whether you use CRLs or OCSP, you?re following a URL in the >>> (still untrusted or at least possibly revoked) certificate >>> to retrieve an object. >> >> Possibly revoked? yes. >> >> Untrusted? *NO*. Look at the algorithm in rfc5280 again. > > In case a CA mis-issues a certificate, such as when giving someone > who is decidedly not Microsoft a certificate for www.microsoft.com, > what it should do is to revoke that certificate. Yes. So what? When you use the AIA OCSP or CRLDP information from a certificate during certificate path validation, you do this only after you have verified the CA signature on the certificate, which confirms that the CA placed this information in the certificate. Whether the entity who controls the private key is really the one who the CA thought he was or whom the Subject/SAN identifies, is not yet relevant. > > That's the only way to un-emit the certificate other than patch all > relying parties. So as long as you haven't checked revocation, > the certificate is not only potentially revoked (someone stole my > private key), it's also potentially mis-issued. Correct. but the issues that you listed do not make the OCSP responder location and CRLDP info within that certificate untrustworthy. In case that you wonder what happens if a CA is more throughly compromised, i.e. that someone manages not only to get certs mis-issued under a false identity, but also with arbitrary attributes in them -- well, this is something that the folks who invented X.509 claimed that it can not possibly happen, because they did not design their approach to distribute the CRL&OCSP distribution info to account for this (or they would have had to distribute this information through the CA certificate rather than through the end-entity certificate. If you have or suspect that kind of CA breach (e.g. DigiNotar), then your only course of action is to immediately and completely nuke the entire PKI (i.e. revoke the CA certificate, respond to all issuer&serial requests for that issuer to your OCSP responder with "revoked". > > I think the section you quote below says that. > You haven't done path validation until you've checked revocation > for every certificate. I believe the enumeration to be an _ordered_ list, because it uses numbers rather than bullets. I realize that there are folks who have issues with doing stuff properly "in order". Now there is one obvious defect in that list/order. item number (4) should really be number (1). This is not a security issue to do (4) last rather than first, but it is an obvious usability issue to anyone with experience in customer support. In the wild, you will often find cause that are non-malicious why an out-of-order certificate chain finds its way into the Basic Path Validation function. I assume that the weird TLS servers that Ryan is setting up send their bogus heaps of certs with non-malicious intent. If that happens for the below ordering of operations - you needlessly waste lots of CPU cycles in a asymmetric crypto operation that will predictably fail - you will typically get an error that says "digital signature verification failure", because a digital signature verification fails here. - this failure will typically preempt all further checking, and the fact that working_issuer_name differs from the issuer of the current cert may get totally lost. When doing customer support, it is vital to know that a certificate path validation failure happend because the peer sent junk instead of a well-formed certification path in the TLS Certificate handshake message, and that the digital signature verification failure is not a data corruption or attack. > >> https://tools.ietf.org/html/rfc5280#section-6.1.3 >> >> 6.1.3. Basic Certificate Processing >> >> >> The basic path processing actions to be performed for certificate i >> (for all i in [1..n]) are listed below. >> >> (a) Verify the basic certificate information. The certificate >> MUST satisfy each of the following: >> >> (1) The signature on the certificate can be verified using >> working_public_key_algorithm, the working_public_key, and >> the working_public_key_parameters. >> >> (2) The certificate validity period includes the current time. >> >> (3) At the current time, the certificate is not revoked. This >> may be determined by obtaining the appropriate CRL >> (Section 6.3), by status information, or by out-of-band >> mechanisms. >> >> (4) The certificate issuer name is the working_issuer_name. >> -Martin From nobody Tue May 12 15:38:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B501AD36F for ; Tue, 12 May 2015 15:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 a99r3ru2X41A for ; Tue, 12 May 2015 15:38:40 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7EC1AD36A for ; Tue, 12 May 2015 15:38:40 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id F266F2A63E; Wed, 13 May 2015 00:38:38 +0200 (CEST) X-purgate-ID: 152705::1431470319-00000B48-3C90AF7D/0/0 X-purgate-size: 1946 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id DD7584143F; Wed, 13 May 2015 00:38:38 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id D2CE01B2EB; Wed, 13 May 2015 00:38:38 +0200 (CEST) In-Reply-To: To: ryan-ietftls@sleevi.com Date: Wed, 13 May 2015 00:38:38 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150512223838.D2CE01B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 22:38:42 -0000 Ryan Sleevi wrote: > On Tue, May 12, 2015 2:38 pm, Martin Rex wrote: >> One of the worst problems in your proposed text is the replacment >> of the term "self-signed [...] root certificate authority" with >> two bogus occurrences of the term "trust anchor". >> >> Trust anchor is a _strictly_ local concept, so this term >> MUST NOT be used in the description of the TLS Certificate PDU. >> >> self-signed root certificate authority is a simple technical term, >> that does *NOT* imply trust by any party. > > You will find the reasoning already provided in past messages for why this > proposed terminology change. "self-signed root certificate authority" is, > unquestionably, NOT a simple technical term (considering how many times it > has confused people, I should think this obvious). Then add the line of text from rfc5280 or X.509 that explain what a self-signed CA certificate is. > > Please do re-read the > message is which I provided the justification for this change, and > hopefully provide counter-factual evidence if there is any. I is *IMPOSSIBLE* to justify the use of "trust anchor" here. > > Considering that "trust anchor" is a term extensively used in RFC 5280, rfc5280 explicitly describes "trust anchor" to have only a *local* meaning! see rfc5280, section 6.2 (which I previously quoted). https://tools.ietf.org/html/rfc5280#section-6.2 > > I also fail to understand your objection about it being a "local only" > concept. This is entirely in line with the current language where you can > omit certificates that you know your peer does not need. The Certificate handshake message PDU is produced by one TLS peer (sender) and consumed/interpreted by the *OTHER* TLS peer. But the concept of a trust anchor is a thoroughly local issue, so the use of the terminology for the TLS Certificate PDU is provably incorrect for at least one TLS peer. -Martin From nobody Tue May 12 15:51:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93011A92DC for ; Tue, 12 May 2015 15:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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_NONE=-0.0001] 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 ZOWZnMzYDrdO for ; Tue, 12 May 2015 15:51:28 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A64151A92BA for ; Tue, 12 May 2015 15:51:28 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 6D4BA67C091; Tue, 12 May 2015 15:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=Ppg5s5T2knYGEIcUMSMd2SGZifk=; b=p5u9LiwwKU+Viieoh t4P8/f8jyPZEq7PfHSieAT/VlvHlQTBQR3qXmPb96qkGyUN2RNcWEaxtgoFcOwCX h85lUYPkPQ/UpVHxXw/1GmZMPpc8pOQtGIjiCAdVCXyT5HdVMBxO/CoNwqzJReme x++mMb+CkvFfVD/oJC5uH5gfZQ= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPA id 3B91A67C07D; Tue, 12 May 2015 15:51:28 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 15:51:28 -0700 Message-ID: In-Reply-To: <20150512223838.D2CE01B2EB@ld9781.wdf.sap.corp> References: <20150512223838.D2CE01B2EB@ld9781.wdf.sap.corp> Date: Tue, 12 May 2015 15:51:28 -0700 From: "Ryan Sleevi" To: mrex@sap.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 22:51:29 -0000 On Tue, May 12, 2015 3:38 pm, Martin Rex wrote: > Then add the line of text from rfc5280 or X.509 that explain what a > self-signed CA certificate is. A self-signed CA certificate is not the same as a self-signed root CA certificate, for example, nor are they to be confused with a self-issued root CA certificate, which may not necessarily be self-signed. > I is *IMPOSSIBLE* to justify the use of "trust anchor" here. I'll take that as you declining to read or respond then. > rfc5280 explicitly describes "trust anchor" to have only a *local* > meaning! > see rfc5280, section 6.2 (which I previously quoted). > https://tools.ietf.org/html/rfc5280#section-6.2 I don't think the text supports your claim, but it's clear that no matter how compelling the argument, there's no room for you to budge on this. It is unfortunate, but at least consistent. > The Certificate handshake message PDU is produced by one TLS peer (sen= der) > and consumed/interpreted by the *OTHER* TLS peer. But the concept of > a trust anchor is a thoroughly local issue, so the use of the terminol= ogy > for the TLS Certificate PDU is provably incorrect for at least one TLS > peer. No, it's not, but again, I don't think there's any room left for progress on the matter, since it seems less and less likely to get a technical discussion of the facts. If the TLS peer knows, through whatever means (RFC 6066, out of band prio= r agreement, incantations of the illuminati passed from generation to generation), the trust anchor of the peer, it may omit any certificates that follow that trust anchor. How is that a difficult or wrong concept? In the case of DANE, the peer needs all certificates, including the self-signed, self-issued CA certificate expressed in the DANE record. In the case of clients, if the server has perfect knowledge, then it can omit the unnecessary certificates. We've already established extensively why the myriad trust stores and clients make such apriori knowledge on the Internet at large difficult to impossible, and I think it's foolish to claim that 1) We replace the entire PKI with some future system 2) We replace the entire client TLS space with some future system that ignores RFC 4158 (which will not happen) 3) We replace the entire server TLS space with some future system that strictly enforces the TLS requirements (which will not happen; the ample evidence of SSL3, RC4, Renego, etc provide ample proof of this) So we deal with the system we have, the constraints we have, the clients we have, the PKI we have, and we seek rough consensus and running code. The vast majority of running code disagrees with you, and, by proxy, the spec. Can we at least agree to that much? From nobody Tue May 12 16:04:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCA61B29BE for ; Tue, 12 May 2015 16:04:27 -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 vu3_Z3TyA8Kl for ; Tue, 12 May 2015 16:04:26 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231641B29C0 for ; Tue, 12 May 2015 16:04:26 -0700 (PDT) Received: by obcus9 with SMTP id us9so17124931obc.2 for ; Tue, 12 May 2015 16:04: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:from:date:message-id:subject:to :cc:content-type; bh=KZavZjuGT5oNGWpIWTnKcHSSYW/Kcia8LSIW1LnY6rU=; b=BcTqSJBzlu5DAL/xlIbeVxXiGB54hSL0vD4PXX6BXBA3NJv8xf/V24w437LwoDQhxH uODLu793ZLcjdRZLkjGrD0KnRnpCGaQ0OokH8B2bYBpo62MonCnqqMU7Z+sfyTaHMTQz UI4X3yiixl8MPRa3TFvFqgjXCEVQe9bPcECFEqQ+VndwQhW9PzbdI73r4Q8/Ec2lXrd/ kkU+4ette6fiMyiEC6E0WZyb0q+VEROB9w3ImUDrXlUj/pdNY8a970piQ0liXGtQ8FYi IwDbuC6HZi1Tb/tQwLcMk3+esmbjzRwm2LAV8b2DBQjVDWnzRNuNImEAS7+Z8nDnZzN+ D1Lw== X-Received: by 10.202.49.77 with SMTP id x74mr13219028oix.86.1431471865538; Tue, 12 May 2015 16:04:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.213.206 with HTTP; Tue, 12 May 2015 16:04:05 -0700 (PDT) In-Reply-To: References: <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> <20150512131453.083471B2EB@ld9781.wdf.sap.corp> From: Fabrice Gautier Date: Tue, 12 May 2015 16:04:05 -0700 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 23:04:27 -0000 On Tue, May 12, 2015 at 6:58 AM, Watson Ladd wrote: > On Tue, May 12, 2015 at 6:14 AM, Martin Rex wrote: >> Ryan Sleevi wrote: >>> >>> 1) I think clients, such as Martin's, that implement normative checking of >>> ordering and are used for the Internet at large (e.g. between servers and >>> clients that are not controlled by a single entity) are bad for Internet >>> security. >> >> Huh? I never described anything like that "normative checking". >> >> My client simply feeds the certificate chain from the TLS Certificate >> handshake message, up to an issure that is recognized as trust anchor >> directly into the certificate path validation function (rfc5280, >> section 6.1) just like rfc5246 and rfc5280 _designed_ this to be. > > How does the server know which trust anchors will be accepted, > particularly in cases involving cross-validation? Isn't that the purpose of the "Trusted CA Indication" extension in RFC 6066 ? I don't know of anything implementing it though.... -- Fabrice From nobody Tue May 12 17:16:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2381A8710 for ; Tue, 12 May 2015 17:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 ir8xxXdTIAJh for ; Tue, 12 May 2015 17:16:39 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C7E1A870B for ; Tue, 12 May 2015 17:16:38 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 6F55B2AB81; Wed, 13 May 2015 02:16:36 +0200 (CEST) X-purgate-ID: 152705::1431476196-0000413A-86932C39/0/0 X-purgate-size: 1492 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 48A60414BE; Wed, 13 May 2015 02:16:36 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3C5141B2EB; Wed, 13 May 2015 02:16:36 +0200 (CEST) In-Reply-To: <5ec0a679151b6aad1473a8e1f4ee3e0d.squirrel@webmail.dreamhost.com> To: ryan-ietftls@sleevi.com Date: Wed, 13 May 2015 02:16:36 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150513001636.3C5141B2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 00:16:41 -0000 Ryan Sleevi wrote: > > Your example (access.redhat.com) is one that we had to work around on OS X > due to quirks of the client not supporting trust anchors (e.g. > https://code.google.com/p/chromium/issues/detail?id=236112 ). > > That is, if you supply your (b) or (c), for example, you'll break any > application using Security.framework for certificate verification > (including all those that use CFURL & friends). It seems that Safari has > special logic not present in the OS to work around that issue. When looking at the above bug report, I agree with the particular statement of rsleevi@chromium.org's bug report: This allows the 'proper' chain to be built (eg: through AIA fetching). However, such behaviour is not desirable for both performance reasons and because it may mask real configuration errors (eg: Issue 122500 ) Has adding the crossCA variant of the new Baltimore rootCA cert ever been considered/tried? I mean dropping the old 1024-bit rootCA should become irrelevant when the the 2048-bit crossCA variant is added as trust anchor. There is no practical difference between the self-signed variant and the crossCA variant of that trust-anchor. And if the PKIX implemenation is a little dense and does not recognize the equivalence all by itself, then configuring both variants as trust anchors should do the necessary magic. Did the supplier of the relevant PKIX implementation fix this implementation shortcoming? -Martin From nobody Tue May 12 17:21:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1CD1A8772 for ; Tue, 12 May 2015 17:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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_NONE=-0.0001] 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 MGjo8YxYvA6P for ; Tue, 12 May 2015 17:21:17 -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 B4E521A8715 for ; Tue, 12 May 2015 17:21:06 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 7A3462005E619; Tue, 12 May 2015 17:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=rrBqlTTZMXGO/wRDylAQfDARwJY=; b=PDyoHg76ylPZDEtB9 gn1HjiYGydVgpFEP8zRNYDJFmAjTpwBCYFD+sVCbNdoEru9IgnI1P3XYrP4suZ54 cqO1EXUwW+l5Tufk6mxUGD+DfQL5rSviORCDHhc0h4a09nhQWNvC59UgGVROF9rD g35/eLUGMFiOMwVmrJ7Ghs4+xM= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 04C412005E605; Tue, 12 May 2015 17:21:06 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 17:21:06 -0700 Message-ID: <652608d7316105c234ad043db5997945.squirrel@webmail.dreamhost.com> In-Reply-To: <20150513001636.3C5141B2EB@ld9781.wdf.sap.corp> References: <20150513001636.3C5141B2EB@ld9781.wdf.sap.corp> Date: Tue, 12 May 2015 17:21:06 -0700 From: "Ryan Sleevi" To: mrex@sap.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Update spec to match current practices for certificate chain order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 00:21:17 -0000 On Tue, May 12, 2015 5:16 pm, Martin Rex wrote: > Has adding the crossCA variant of the new Baltimore rootCA cert ever > been considered/tried? Yes. It doesn't work. > I mean dropping the old 1024-bit rootCA should > become irrelevant when the the 2048-bit crossCA variant is added > as trust anchor. There is no practical difference between the > self-signed variant and the crossCA variant of that trust-anchor. > And if the PKIX implemenation is a little dense and does not recognize > the equivalence all by itself, then configuring both variants as > trust anchors should do the necessary magic. In a world different than our own, anything is possible. In the world we have, we deal with an imperfect reality and make it work. > Did the supplier of the relevant PKIX implementation fix this > implementation > shortcoming? Nope. Considering it is not required of an RFC 5280-compliant implementation to support that, any claims that the relevant supplier should would largely be inconsistent with your past messages. Even if you'd be correct in arguing they should. From nobody Tue May 12 17:28:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286731A8825 for ; Tue, 12 May 2015 17:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2gTu1JU10po for ; Tue, 12 May 2015 17:28:05 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) (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 9F1551A87D0 for ; Tue, 12 May 2015 17:28:05 -0700 (PDT) Received: by oign205 with SMTP id n205so19191394oig.2 for ; Tue, 12 May 2015 17:28:05 -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=grE8weNDMQntMZFE4F7pVgymc6qx/P/8GGoKM+aZxvc=; b=GN4nRa6DLol0dYLQb9EHDaQo3LNMtEgy8y+WOgQh0VPfruyT4sTfIkMYpEdnZqzszj zY7o/BYfZ1+sB8T6XvgovEZzHfmOYgDQuwyj3huR5gr1HpQYGo1Xogwo02GhHBMAwPqH ANQuKzT0+67Tluu2iEp1qeYQH0/T/tFGN7ruHU7KBwpuN4WTaHlp04K405aEoqVVv5xs 4Q7gnJ3TokQyawgbNyCBZHzmnMuX6YQudllhxFinhkwXubiYfdxdporGaOpvLZEh/JJM 9rcygwALxh0AlPAbrPeTpWEKsPki8tX+cm8zAhkdjqK1GTWQG9LZkuKAWFeUp0K36LYq 98Lw== X-Gm-Message-State: ALoCoQmTDpv2fsfnX5gVV/FUw10JUfYvFHaclrsHwGzC2liwxJvBAFk0/InMEMqupTcsqVK2VXuO MIME-Version: 1.0 X-Received: by 10.60.101.137 with SMTP id fg9mr14056868oeb.83.1431476885041; Tue, 12 May 2015 17:28:05 -0700 (PDT) Received: by 10.76.90.97 with HTTP; Tue, 12 May 2015 17:28:04 -0700 (PDT) In-Reply-To: <939995E0-4ED0-479A-8B3A-628FE2C8C31B@gmail.com> References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <939995E0-4ED0-479A-8B3A-628FE2C8C31B@gmail.com> Date: Tue, 12 May 2015 14:28:04 -1000 Message-ID: From: Brian Smith To: Yoav Nir Content-Type: multipart/alternative; boundary=089e010d9e8a3cc7b90515ebafc2 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 00:28:07 -0000 --089e010d9e8a3cc7b90515ebafc2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > > But a machine/automata/algorithm that will automatically download objec= ts > > from URLs from still-untrusted data provided by the peer is definitely > > insecure and irresponsible. > > In that sense, how is AIA different from revocation checking? Whether you > use CRLs or OCSP, you=E2=80=99re following a URL in the (still untrusted = or at > least possibly revoked) certificate to retrieve an object. > When you fetch CRLs or OCSP responses, you are using a URL that has been authenticated by a trusted issuer, assuming you do revocation checking from the root to the end-entity, which is the safer way of doing it. Whereas, in AIA cert fetching you are making a request to an unauthenticated URL. That is quite a big difference, because it is much harder to get a CA to sign a certificate with your chosen OCSP URL than it is to just forge your own certificate with whatever AIA caIssuers URL you want to have. Ultimately, a client shouldn't fetch OCSP responses or CRLs either, for many reasons. One of the big reasons is that those fetches greatly increase the attack surface of the client beyond what is otherwise necessary. Instead we need to move to a model where revocation information is always provided within the TLS handshake (e.g. OCSP stapling and/or short-lived certificates). Consequently, we shouldn't accept AIA cert fetching as good or even reasonable behavior based on analogies to revocation information fetching. Cheers, Brian --089e010d9e8a3cc7b90515ebafc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yoav= Nir <ynir.ietf@gmail.com> wrote:
> But a machine/automata/algorithm that will = automatically download objects
> from URLs from still-untrusted data provided by the peer is definitely=
> insecure and irresponsible.

In that sense, how is AIA different from revocation checking? Whethe= r you use CRLs or OCSP, you=E2=80=99re following a URL in the (still untrus= ted or at least possibly revoked) certificate to retrieve an object.

When you fetch CRLs or OCSP responses, you ar= e using a URL that has been authenticated by a trusted issuer, assuming you= do revocation checking from the root to the end-entity, which is the safer= way of doing it. Whereas, in AIA cert fetching you are making a request to= an unauthenticated URL. That is quite a big difference, because it is much= harder to get a CA to sign a certificate with your chosen OCSP URL than it= is to just forge your own certificate with whatever AIA caIssuers URL you = want to have.

Ultimately, a client shouldn't f= etch OCSP responses or CRLs either, for many reasons. One of the big reason= s is that those fetches greatly increase the attack surface of the client b= eyond what is otherwise necessary. Instead we need to move to a model where= revocation information is always provided within the TLS handshake (e.g. O= CSP stapling and/or short-lived certificates).

Con= sequently, we shouldn't accept AIA cert fetching as good or even reason= able behavior based on analogies to revocation information fetching.
<= div>
Cheers,
Brian
--089e010d9e8a3cc7b90515ebafc2-- From nobody Tue May 12 18:57:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E827F1A8AE8 for ; Tue, 12 May 2015 18:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx1vz--2xH42 for ; Tue, 12 May 2015 18:57:00 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.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 68A9E1A871E for ; Tue, 12 May 2015 18:57:00 -0700 (PDT) Received: by oiko83 with SMTP id o83so20432815oik.1 for ; Tue, 12 May 2015 18:56:59 -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=slquH3Ph58JBoAU7GqtKtUVhER9ubixgPNbAdNoQhjU=; b=AE1pkK7k3piJR/Deae6LMS/H/VdY/EWJqBgu1j8sCTrQHDpHmgHxleOHYcIYD/uDRu r+g4DxuKrm8JcwkwLr/OKCbY+xhzPxMoU2iiqJ0Pa12+deqoQYv8TClb3PsOPgD+X10A Nd4DVL9JFO7FeI5+lPHza6S1CdobJEYLZni0eaFJpgE61CI+WTe/GEt8FkWALHZrdn/g M2awSJmcqOFsc9HGcCsY7nTlP+/ofYxuPc7UmH98cnRwkM3YXFQeNQfpV/vvNwsR8N7e Bf5blKGnPy6JOR57ybvsIE0z/4XAADgF9MY8lBG0iCzOJYc2GK5sWpAAOR+aL/yTXpvP hFzw== X-Gm-Message-State: ALoCoQmKNjtBY0NdCtdK0x1Wbz/uBr34MbszxoiPHiIOwGCJ0gi0Iiu19V7LkKHqLtY5YIvIPQ6G MIME-Version: 1.0 X-Received: by 10.182.246.3 with SMTP id xs3mr14013210obc.17.1431482219782; Tue, 12 May 2015 18:56:59 -0700 (PDT) Received: by 10.76.90.97 with HTTP; Tue, 12 May 2015 18:56:59 -0700 (PDT) In-Reply-To: References: <20150506101230.32573.26774.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 15:56:59 -1000 Message-ID: From: Brian Smith To: Bodo Moeller Content-Type: multipart/alternative; boundary=001a11c2f59e3679a90515ecedcb Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-ieft-tls-falsestart-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 01:57:04 -0000 --001a11c2f59e3679a90515ecedcb Content-Type: text/plain; charset=UTF-8 On Thu, May 7, 2015 at 5:24 AM, Bodo Moeller wrote: > - The intended status should probably be "Informational". > I think it is worthwhile for it to be a standards-track document. "Informational" status would likely result in it not getting sufficient review. > - Recommend against use of False Start with (EC)DHE on any kind of > explicit groups, and on named groups of insufficient size. (I don't think > we should try to predict whether the ffdhe groups from > draft-ietf-tls-negotiated-ff-dhe-08 will catch on with TLS 1.2, so False > Start with traditional DHE shouldn't be entirely left out.) > To clarify my previous suggestion: I suggest removing the mentions of DHE and recommending to not do DHE with False Start at all unless/until we have agreed on the text for criteria for allowing DHE. I think it will be a while before the text for DHE criteria are agreed to, and having text suggesting that DHE as commonly implemented is OK to do with False Start is harmful. Also note that Google Chrome dropped support for False Start with DHE cipher suites the day I suggested that they do so on this mailing list a few weeks ago, so neither Firefox nor Chrome (will) support it. (If there are any more clients that still support False Start with DHE cipher suites, they probably should stop doing so soon.) > Then Brian had a comment about False Start with client certificates. I'm > not yet sure what to make out of that. The main point of mentioning client > certificate types in the I-D was to make sure that False Start isn't used > with rsa_fixed_dh and the like (since client implementations might allow > mixing client-side static DH with server-side ephemeral DH, assuming they > support DH certs at all). Sending client certs in the clear may not be a > good idea, but that issue seems entirely orthogonal to what False Start is > all about. Do you see an actual problem about sending a client's signing > cert specifically in a False Start handshake? > Assume that the client is an agent of some real person who is using a certificate that binds their identity to the certificate's keypair. For example, this might be a government-issued smartcard that is used for e-voting or taxpaying. The certificate contains personally-identifying information including the user's name and/or location of residence. Obviously, it's terrible to send that information in the clear. It is true that TLS already encourages it to be sent in the clear, without False Start. Encouraging this malpractice by giving it the False Start performance boost effectively discourages us from fixing the privacy issue. But, let's say we don't care about improving privacy. Then, would it be OK to False Start when client certificates are used? It isn't clear to me that it is OK. By signing the CertificateVerify with the his private key, the client end-user is offering a level of non-repudiation for any content that he/she sends on the connection. Potentially that non-repudiation could have serious (e.g. legal) consequences for the end-user, so it seems better to err on the side of caution and wait for the handshake to be fully authenticated before sending any application data. Also, there are some regulations regarding how TLS is to be done in certain environments (e.g. US Government DoD), and it seems likely that False Start is inappropriate according to those regulations. Client certificates are often used in such environments, and so by not supporting False Start with Client Certificates, we end up doing the right thing there. In other words, requesting a client certificate is a strong indicator that the server probably doesn't want us to do False Start. Also, frankly, use of client certificates is rare in the types of stuff I normally work on, and there was (is) no motivation to optimize that case. So, it literally wasn't (isn't) a good use of time to analyze whether False Start should be used with client certificates. ChannelID is quite a lot like client certificates and I understand why one would hope that ChannelID and False Start work well together. It seems likely that considerations that apply to client certificates also apply to ChannelID, but I don't think we should use an analysis of False Start with client certificates as a proxy for an analysis of False Start with ChannelID. Especially since ChannelID got reformulated into an application-layer thing en route to being standardized, it seems better to analyze it separately. Cheers, Brian --001a11c2f59e3679a90515ecedcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 7, 2015 at 5:24 AM, Bodo Moeller <bmoeller@acm.org> w= rote:
- The intended status shoul= d probably be "Informational".

<= /div>
I think it is worthwhile for it to be a standards-track document.= "Informational" status would likely result in it not getting suf= ficient review.
=C2=A0
- Recommend against use of False Start with (EC)DHE on any kind of explic= it groups, and on named groups of insufficient size. (I don't think we = should try to predict whether the ffdhe groups from draft-ietf-tls-negotiat= ed-ff-dhe-08 will catch on with TLS 1.2, so False Start with traditional DH= E shouldn't be entirely left out.)
To clarify my previous suggestion: I suggest removing the menti= ons of DHE and recommending to not do DHE with False Start at all unless/un= til we have agreed on the text for criteria for allowing DHE. I think it wi= ll be a while before the text for DHE criteria are agreed to, and having te= xt suggesting that DHE as commonly implemented is OK to do with False Start= is harmful. Also note that Google Chrome dropped support for False Start w= ith DHE cipher suites the day I suggested that they do so on this mailing l= ist a few weeks ago, so neither Firefox nor Chrome (will) support it. (If t= here are any more clients that still support False Start with DHE cipher su= ites, they probably should stop doing so soon.)
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
Then Brian had a comment a= bout False Start with client certificates. I'm not yet sure what to mak= e out of that. The main point of mentioning client certificate types in the= I-D was to make sure that False Start isn't used with=C2=A0rsa_fixed_d= h and the like (since client implementations might allow mixing client-side= static DH with server-side ephemeral DH, assuming they support DH certs at= all). Sending client certs in the clear may not be a good idea, but that i= ssue seems entirely orthogonal to what False Start is all about. Do you see= an actual problem about sending a client's signing cert specifically i= n a False Start handshake?

= Assume that the client is an agent of some real person who is using a certi= ficate that binds their identity to the certificate's keypair. For exam= ple, this might be a government-issued smartcard that is used for e-voting = or taxpaying. The certificate contains personally-identifying information i= ncluding the user's name and/or location of residence.

Obviously, it's terrible to send that information in the clear= . It is true that TLS already encourages it to be sent in the clear, withou= t False Start. Encouraging this malpractice by giving it the False Start pe= rformance boost effectively discourages us from fixing the privacy issue.

But, let's say we don't care about improvin= g privacy. Then, would it be OK to False Start when client certificates are= used? It isn't clear to me that it is OK. By signing the CertificateVe= rify with the his private key, the client end-user is offering a level of n= on-repudiation for any content that he/she sends on the connection. Potenti= ally that non-repudiation could have serious (e.g. legal) consequences for = the end-user, so it seems better to err on the side of caution and wait for= the handshake to be fully authenticated before sending any application dat= a.

Also, there are some regulations regarding how = TLS is to be done in certain environments (e.g. US Government DoD), and it = seems likely that False Start is inappropriate according to those regulatio= ns. Client certificates are often used in such environments, and so by not = supporting False Start with Client Certificates, we end up doing the right = thing there. In other words, requesting a client certificate is a strong in= dicator that the server probably doesn't want us to do False Start.

Also, frankly, use of client certificates is rare in = the types of stuff I normally work on, and there was (is) no motivation to = optimize that case. So, it literally wasn't (isn't) a good use of t= ime to analyze whether False Start should be used with client certificates.=

ChannelID is quite a lot like client certificates= and I understand why one would hope that ChannelID and False Start work we= ll together. It seems likely that considerations that apply to client certi= ficates also apply to ChannelID, but I don't think we should use an ana= lysis of False Start with client certificates as a proxy for an analysis of= False Start with ChannelID. Especially since ChannelID got reformulated in= to an application-layer thing en route to being standardized, it seems bett= er to analyze it separately.

Cheers,
Bri= an

--001a11c2f59e3679a90515ecedcb-- From nobody Tue May 12 19:08:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1B21A9051 for ; Tue, 12 May 2015 19:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2Pyvd0TT_rb for ; Tue, 12 May 2015 19:08:13 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (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 6246F1A904D for ; Tue, 12 May 2015 19:08:13 -0700 (PDT) Received: by oiko83 with SMTP id o83so20591840oik.1 for ; Tue, 12 May 2015 19:08:12 -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=pXK/8kfzVeTaZwNp4Jt99FqlmzKBFjZycdaKh8oNaeA=; b=HPzU8jhO0H4iETyN10nuzAfEeeuCpUnbm84p/jAZk151QjaIkhwyK/egPoBTmeF8Jh bGd1IctyPLZj/qwhmKm90eQb+MKDII4MHOdxrzjZBT/VM2T08O3PbOyimmaxmqwkJTlL Rzif/gy7oZuDg7wFtXKk5jT52pc9YcLysfsYR9hnOdloAqg+6I9frAZVoaN4tL53wcu1 VniAdmFDvlg/nFvhJGDLFQWhPEyNimaL+kaYSeCByFEY0xSxgL1XB7KO/5xph8FkXi9N pbQ5d7lunIjhxfPyOg9gGl6QziP7QlDicJafq7qXc0knjmMNnfvpg147cRAhqqTfyxhV pqCw== X-Gm-Message-State: ALoCoQkwXN0eIV7MK2JBuK4S4NgMfEL0njvW7DU2I3tLNQBi+xIfM+qIYD/u7v3xPFtsB/sCqQtl MIME-Version: 1.0 X-Received: by 10.202.91.11 with SMTP id p11mr13463329oib.125.1431482892867; Tue, 12 May 2015 19:08:12 -0700 (PDT) Received: by 10.76.90.97 with HTTP; Tue, 12 May 2015 19:08:12 -0700 (PDT) In-Reply-To: References: <20150506101230.32573.26774.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 16:08:12 -1000 Message-ID: From: Brian Smith To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113d29ee54eeb30515ed15ed Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-ieft-tls-falsestart-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 02:08:18 -0000 --001a113d29ee54eeb30515ed15ed Content-Type: text/plain; charset=UTF-8 On Thu, May 7, 2015 at 11:25 AM, Martin Thomson wrote: > If the client certificate is to be enciphered in an immediate > renegotiation handshake, and both initial and renegotiation use False > Start, the client should probably check the Finished message on the > first before completing the renegotiation. Unless there are issues > delaying the Finished delivery, the client should have that prior to > when it needs to send the certificate. > We should just say that False Start should only be done during the initial handshake, and MUST NOT be done during renegotiation. Do any implementations False Start during renegotiation? Note that you can create a session during the initial TLS handshake and then resume that session during the renegotiation, so there was already a way to nearly guarantee a 1-RTT renegotiation handshake with vanilla TLS, as long as both sides support session resumption. And, if either implementation is too conservative to implement session resumption, that's a good hint that they'd rather not do False Start either. Cheers, Brian --001a113d29ee54eeb30515ed15ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 7, 2015 at 11:25 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
If the client = certificate is to be enciphered in an immediate
renegotiation handshake, and both initial and renegotiation use False
Start, the client should probably check the Finished message on the
first before completing the renegotiation. Unless there are issues
delaying the Finished delivery, the client should have that prior to
when it needs to send the certificate.

= We should just say that False Start should only be done during the initial = handshake, and MUST NOT be done during renegotiation. Do any implementation= s False Start during renegotiation?

Note that you = can create a session during the initial TLS handshake and then resume that = session during the renegotiation, so there was already a way to nearly guar= antee a 1-RTT renegotiation handshake with vanilla TLS, as long as both sid= es support session resumption. And, if either implementation is too conserv= ative to implement session resumption, that's a good hint that they'= ;d rather not do False Start either.

Cheers,
=
Brian

--001a113d29ee54eeb30515ed15ed-- From nobody Tue May 12 22:59:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CEF1AC3E1 for ; Tue, 12 May 2015 22:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1VjN3H_46HY for ; Tue, 12 May 2015 22:59:23 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 D71001AC3DB for ; Tue, 12 May 2015 22:59:22 -0700 (PDT) Received: by wgin8 with SMTP id n8so32057808wgi.0 for ; Tue, 12 May 2015 22:59:21 -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 :message-id:references:to; bh=vIA9kFIaqpgXRXkSl2EB9W2LN7PkMkTx7R6HAkeGQnA=; b=bcZQDLB+GqlcvegSwlFNHxp6fyGsFQm6zmTUyz2L14vgXxdulkDSp+LiA5nGn0kIa4 H9UXSzxpIxGpPeCTtnK0nGarNc/Ya2u/NbHh01rDMtzueOoH4qbv6cawsjE2bQLirUaz HHCLgfPJM/Hzk/VAnmiK/D5ljKmm1wYWUlMaW2z+ht47Pj5yDeLbL55ZUtqUUXPOebg9 JLrKb4P78UcvFY62wlj/ChrlAmduow7fMoaSdAVJZPVjdW8vtm9E651I8wLGSxtCiN6z ZpOXt4ppm2M7WHxPtr/oKF9WNxVlvVXJhhDuvNtmfT5UlzTViQxnzHN4EOtT6RXQnEDF My7A== X-Received: by 10.180.219.42 with SMTP id pl10mr11407414wic.70.1431496761639; Tue, 12 May 2015 22:59:21 -0700 (PDT) Received: from [10.4.33.237] ([82.102.169.113]) by mx.google.com with ESMTPSA id hu1sm6207318wib.6.2015.05.12.22.59.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 May 2015 22:59:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4F8B5D50-4DFB-4A8F-8B33-FA09405C1765" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Wed, 13 May 2015 08:58:54 +0300 Message-Id: References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <939995E0-4ED0-479A-8B3A-628FE2C8C31B@gmail.com> To: Brian Smith X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 05:59:25 -0000 --Apple-Mail=_4F8B5D50-4DFB-4A8F-8B33-FA09405C1765 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 13, 2015, at 3:28 AM, Brian Smith wrote: >=20 > Yoav Nir > wrote: > > But a machine/automata/algorithm that will automatically download = objects > > from URLs from still-untrusted data provided by the peer is = definitely > > insecure and irresponsible. >=20 > In that sense, how is AIA different from revocation checking? Whether = you use CRLs or OCSP, you=E2=80=99re following a URL in the (still = untrusted or at least possibly revoked) certificate to retrieve an = object. >=20 > When you fetch CRLs or OCSP responses, you are using a URL that has = been authenticated by a trusted issuer, assuming you do revocation = checking from the root to the end-entity, which is the safer way of = doing it. Whereas, in AIA cert fetching you are making a request to an = unauthenticated URL. That is quite a big difference, because it is much = harder to get a CA to sign a certificate with your chosen OCSP URL than = it is to just forge your own certificate with whatever AIA caIssuers URL = you want to have. >=20 > Ultimately, a client shouldn't fetch OCSP responses or CRLs either, = for many reasons. One of the big reasons is that those fetches greatly = increase the attack surface of the client beyond what is otherwise = necessary. Instead we need to move to a model where revocation = information is always provided within the TLS handshake (e.g. OCSP = stapling and/or short-lived certificates). >=20 > Consequently, we shouldn't accept AIA cert fetching as good or even = reasonable behavior based on analogies to revocation information = fetching. I see. I understand the difference, I just don=E2=80=99t think it = matters. I also disagree with your assertion that clients shouldn=E2=80=99= t fetch OCSP responses, CRLs or AIAs. Sending stapled OCSP responses or = an entire certificate chain is a good optimization and makes the TLS = handshake end more quickly. I can see why people would like that. But = fetching these things from the Internet is no different from fetching = other items from the Internet. Clients do this all the time. I agree that this increases the attack surface, but what kinds of = attacks are we talking about? A very mild DoS attack by pointing the = client at a URL with a petabyte of random data? An invalid CRL? A badly = formatted CA certificate that will cause a buffer overflow on the = client? That kind of certificate could have been sent in the handshake. = These risks seem to me to be part life on the Internet. They=E2=80=99re = not worth the issues of sending large objects over UDP for DTLS for = example. So I agree that for regular TLS sending the entire chain is = the right thing to do, as is sending a stapled OCSP response. I just = don=E2=80=99t think building a chain through other means is in any way = =E2=80=9Cbad=E2=80=9D.=20 Yoav --Apple-Mail=_4F8B5D50-4DFB-4A8F-8B33-FA09405C1765 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 13, 2015, at 3:28 AM, Brian Smith <brian@briansmith.org> wrote:

Yoav = Nir <ynir.ietf@gmail.com> wrote:
> = But a machine/automata/algorithm that will automatically download = objects
> from URLs from still-untrusted data provided by the peer is = definitely
> insecure and irresponsible.

In that sense, how is AIA different from revocation checking? = Whether you use CRLs or OCSP, you=E2=80=99re following a URL in the = (still untrusted or at least possibly revoked) certificate to retrieve = an object.

When you fetch CRLs or OCSP responses, = you are using a URL that has been authenticated by a trusted issuer, = assuming you do revocation checking from the root to the end-entity, = which is the safer way of doing it. Whereas, in AIA cert fetching you = are making a request to an unauthenticated URL. That is quite a big = difference, because it is much harder to get a CA to sign a certificate = with your chosen OCSP URL than it is to just forge your own certificate = with whatever AIA caIssuers URL you want to have.
Ultimately, a client shouldn't fetch = OCSP responses or CRLs either, for many reasons. One of the big reasons = is that those fetches greatly increase the attack surface of the client = beyond what is otherwise necessary. Instead we need to move to a model = where revocation information is always provided within the TLS handshake = (e.g. OCSP stapling and/or short-lived certificates).

Consequently, we = shouldn't accept AIA cert fetching as good or even reasonable behavior = based on analogies to revocation information = fetching.

I see. I understand the difference, I just = don=E2=80=99t think it matters. I also disagree with your assertion that = clients shouldn=E2=80=99t fetch OCSP responses, CRLs or AIAs. Sending = stapled OCSP responses or an entire certificate chain is a good = optimization and makes the TLS handshake end more quickly. I can see why = people would like that. But fetching these things from the Internet is = no different from fetching other items from the Internet. Clients do = this all the time.

I = agree that this increases the attack surface, but what kinds of attacks = are we talking about? A very mild DoS attack by pointing the client at a = URL with a petabyte of random data? An invalid CRL? A badly formatted CA = certificate that will cause a buffer overflow on the client?  That = kind of certificate could have been sent in the handshake. These risks = seem to me to be part life on the Internet. They=E2=80=99re not worth = the issues of sending large objects over UDP for DTLS for example. =  So I agree that for regular TLS sending the entire chain is the = right thing to do, as is sending a stapled OCSP response. I just don=E2=80= =99t think building a chain through other means is in any way = =E2=80=9Cbad=E2=80=9D. 

Yoav

= --Apple-Mail=_4F8B5D50-4DFB-4A8F-8B33-FA09405C1765-- From nobody Tue May 12 23:23:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7B41A0A6A for ; Tue, 12 May 2015 23:23:30 -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 vwxjYQ1K9OPh for ; Tue, 12 May 2015 23:23: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 612461A06FD for ; Tue, 12 May 2015 23:23:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 296C8283032; Wed, 13 May 2015 06:23:28 +0000 (UTC) Date: Wed, 13 May 2015 06:23:28 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150513062327.GS17272@mournblade.imrryr.org> References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <939995E0-4ED0-479A-8B3A-628FE2C8C31B@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: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 06:23:30 -0000 On Wed, May 13, 2015 at 08:58:54AM +0300, Yoav Nir wrote: > So I agree that for regular TLS sending the entire chain is the right > thing to do, as is sending a stapled OCSP response. I just don't think > building a chain through other means is in any way "bad". It can be at least onerous. Clients speaking a given protocol may not be at liberty to connect to anything other than their peer, and may not posess an HTTP stack with which to make out-of-band requests. The SSL/TLS library cannot transparently attempt such additional connections with consent and mediation for connection establishment and event loop integration from the application layer to engage in the additional communications. So in-band is definitely simpler, and leaks less data to third parties. -- Viktor. From nobody Wed May 13 03:23:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114CA1B2A94 for ; Wed, 13 May 2015 03:23:29 -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 RCD5yCA_so2z for ; Wed, 13 May 2015 03:23:24 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438421B2A93 for ; Wed, 13 May 2015 03:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1431512604; x=1463048604; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=GK/fhZ+Q6tsn85i9MKABB44aNSZK9zzydd13we2zP3c=; b=ZPMuHG9WgXY7mbPq4teIBeo+VLLN/4ZLvBZcb6nC6Ynll7efq8U9ICp0 j7TKQETBK1Y7EfcqeY1+wUBp9BGXJEbHDTwlyNls14S9989p/EyJvaHMP 7f2H0Nd4grL/8xasiUhDrfJRbq6cYKZ49Z6DCIlMpDzoVLrHq2QO3UA/F U=; X-IronPort-AV: E=Sophos;i="5.13,420,1427713200"; d="scan'208";a="5008525" 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; 13 May 2015 22:23:22 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 13 May 2015 22:23:21 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) Thread-Index: AdCNZtX0Kozv4h0+SPSSG9VnfrD5Ww== Date: Wed, 13 May 2015 10:23:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB01D53C@uxcn10-tdc05.UoA.auckland.ac.nz> 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: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 10:23:29 -0000 Martin Rex writes:=0A= =0A= >When you use the AIA OCSP or CRLDP information from a certificate during= =0A= >certificate path validation, you do this only after you have verified the = CA=0A= >signature on the certificate,=0A= =0A= Possibly, but when you use the AIA CA information to find the CA cert to=0A= validate the one you've got, you're using unvalidated data.=0A= =0A= Also, OCSP has a great facility (serviceLocator) for an untrusted client to= =0A= tell the server to access any location the client tells it to [0]. It's a= =0A= great way to scan the CA's internal network, walk up the IP address range a= t=0A= port 445 and time the responses. I didn't try any further tricks, but if I= 'd=0A= passed it on to some pen-tester friends I'm sure they could have had some f= un=0A= with the capability.=0A= =0A= >but the issues that you listed do not make the OCSP responder location and= =0A= >CRLDP info within that certificate untrustworthy.=0A= =0A= No, OCSP has its own built-in mechanisms for doing that. In addition the C= A=0A= AIA is untrustworthy, because you need to process the cert and use the AIA = in=0A= order to verify whether the information that you've just acted on is legit.= =0A= =0A= Peter.=0A= =0A= [0] Another one of the many "what *were* they thinking" things you can find= by=0A= reading PKI RFCs.=0A= From nobody Wed May 13 05:55:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFA21A90CD for ; Wed, 13 May 2015 05:55:33 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD_jqpk28rh0 for ; Wed, 13 May 2015 05:55:27 -0700 (PDT) Received: from ipesa2.cygnacom.com (ipesa2.cygnacom.com [65.242.48.201]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCFD1A90AD for ; Wed, 13 May 2015 05:55:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQKADVJU1UKPDLY/2dsb2JhbABcgkVKVF4GgkpOyU8CHIEeTAEBAQEBAYELQQWDWgEBAQMBIwpMBQsCAQUDDQEDBAEBASMEAwICAh8RFAkIAgQBDQUIEYd+AwoIBbVejS4NhHwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqCTYI4BgGCaIFFBZAgi1ABgnqGVIR+gwmDH4NXI2GBWYE9PjGBAyIggQEBAQE X-IronPort-AV: E=Sophos;i="5.13,420,1427774400"; d="scan'208,217";a="91536" Received: from unknown (HELO svaexch1.cygnacom.com) ([10.60.50.216]) by ipesa2.cygnacom.com with ESMTP; 13 May 2015 08:55:24 -0400 Received: from svaexch1.cygnacom.com (10.60.50.216) by svaexch1.cygnacom.com (10.60.50.216) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 13 May 2015 08:55:23 -0400 Received: from svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e]) by svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e%12]) with mapi id 15.00.1076.000; Wed, 13 May 2015 08:55:23 -0400 From: Santosh Chokhani To: Yoav Nir , Brian Smith Thread-Topic: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) Thread-Index: AQHQieY/gmukibBgKEmnwP9D0xEiS513auKA//+u2OCAAEnXAIABNvSAgABKNACAABSYAIAABimAgAADzgCAAAZpgIAATOoAgABcbwCAAC+ToA== Date: Wed, 13 May 2015 12:55:22 +0000 Message-ID: References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <939995E0-4ED0-479A-8B3A-628FE2C8C31B@gmail.com> 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: [108.31.66.4] Content-Type: multipart/alternative; boundary="_000_cf9a644498a74eb3b870970eef93ed22svaexch1cygnacomcom_" MIME-Version: 1.0 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 12:55:33 -0000 --_000_cf9a644498a74eb3b870970eef93ed22svaexch1cygnacomcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFlvYXYuDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgWW9hdiBOaXINClNlbnQ6IFdlZG5lc2RheSwgTWF5IDEzLCAyMDE1 IDE6NTkgQU0NClRvOiBCcmlhbiBTbWl0aA0KQ2M6IFRMU0BpZXRmLm9yZyAodGxzQGlldGYub3Jn KQ0KU3ViamVjdDogUmU6IFtUTFNdIFt0bHMxMy1zcGVjXSByZWxheCBjZXJ0aWZpY2F0ZV9saXN0 IG9yZGVyaW5nIHJlcXVpcmVtZW50cyB0byBtYXRjaCBjdXJyZW50IHByYWN0aWNlICgjMTY5KQ0K DQoNCk9uIE1heSAxMywgMjAxNSwgYXQgMzoyOCBBTSwgQnJpYW4gU21pdGggPGJyaWFuQGJyaWFu c21pdGgub3JnPG1haWx0bzpicmlhbkBicmlhbnNtaXRoLm9yZz4+IHdyb3RlOg0KDQpZb2F2IE5p ciA8eW5pci5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbT4+IHdyb3Rl Og0KPiBCdXQgYSBtYWNoaW5lL2F1dG9tYXRhL2FsZ29yaXRobSB0aGF0IHdpbGwgYXV0b21hdGlj YWxseSBkb3dubG9hZCBvYmplY3RzDQo+IGZyb20gVVJMcyBmcm9tIHN0aWxsLXVudHJ1c3RlZCBk YXRhIHByb3ZpZGVkIGJ5IHRoZSBwZWVyIGlzIGRlZmluaXRlbHkNCj4gaW5zZWN1cmUgYW5kIGly cmVzcG9uc2libGUuDQoNCkluIHRoYXQgc2Vuc2UsIGhvdyBpcyBBSUEgZGlmZmVyZW50IGZyb20g cmV2b2NhdGlvbiBjaGVja2luZz8gV2hldGhlciB5b3UgdXNlIENSTHMgb3IgT0NTUCwgeW914oCZ cmUgZm9sbG93aW5nIGEgVVJMIGluIHRoZSAoc3RpbGwgdW50cnVzdGVkIG9yIGF0IGxlYXN0IHBv c3NpYmx5IHJldm9rZWQpIGNlcnRpZmljYXRlIHRvIHJldHJpZXZlIGFuIG9iamVjdC4NCg0KV2hl biB5b3UgZmV0Y2ggQ1JMcyBvciBPQ1NQIHJlc3BvbnNlcywgeW91IGFyZSB1c2luZyBhIFVSTCB0 aGF0IGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQgYnkgYSB0cnVzdGVkIGlzc3VlciwgYXNzdW1pbmcg eW91IGRvIHJldm9jYXRpb24gY2hlY2tpbmcgZnJvbSB0aGUgcm9vdCB0byB0aGUgZW5kLWVudGl0 eSwgd2hpY2ggaXMgdGhlIHNhZmVyIHdheSBvZiBkb2luZyBpdC4gV2hlcmVhcywgaW4gQUlBIGNl cnQgZmV0Y2hpbmcgeW91IGFyZSBtYWtpbmcgYSByZXF1ZXN0IHRvIGFuIHVuYXV0aGVudGljYXRl ZCBVUkwuIFRoYXQgaXMgcXVpdGUgYSBiaWcgZGlmZmVyZW5jZSwgYmVjYXVzZSBpdCBpcyBtdWNo IGhhcmRlciB0byBnZXQgYSBDQSB0byBzaWduIGEgY2VydGlmaWNhdGUgd2l0aCB5b3VyIGNob3Nl biBPQ1NQIFVSTCB0aGFuIGl0IGlzIHRvIGp1c3QgZm9yZ2UgeW91ciBvd24gY2VydGlmaWNhdGUg d2l0aCB3aGF0ZXZlciBBSUEgY2FJc3N1ZXJzIFVSTCB5b3Ugd2FudCB0byBoYXZlLg0KDQpVbHRp bWF0ZWx5LCBhIGNsaWVudCBzaG91bGRuJ3QgZmV0Y2ggT0NTUCByZXNwb25zZXMgb3IgQ1JMcyBl aXRoZXIsIGZvciBtYW55IHJlYXNvbnMuIE9uZSBvZiB0aGUgYmlnIHJlYXNvbnMgaXMgdGhhdCB0 aG9zZSBmZXRjaGVzIGdyZWF0bHkgaW5jcmVhc2UgdGhlIGF0dGFjayBzdXJmYWNlIG9mIHRoZSBj bGllbnQgYmV5b25kIHdoYXQgaXMgb3RoZXJ3aXNlIG5lY2Vzc2FyeS4gSW5zdGVhZCB3ZSBuZWVk IHRvIG1vdmUgdG8gYSBtb2RlbCB3aGVyZSByZXZvY2F0aW9uIGluZm9ybWF0aW9uIGlzIGFsd2F5 cyBwcm92aWRlZCB3aXRoaW4gdGhlIFRMUyBoYW5kc2hha2UgKGUuZy4gT0NTUCBzdGFwbGluZyBh bmQvb3Igc2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVzKS4NCg0KQ29uc2VxdWVudGx5LCB3ZSBzaG91 bGRuJ3QgYWNjZXB0IEFJQSBjZXJ0IGZldGNoaW5nIGFzIGdvb2Qgb3IgZXZlbiByZWFzb25hYmxl IGJlaGF2aW9yIGJhc2VkIG9uIGFuYWxvZ2llcyB0byByZXZvY2F0aW9uIGluZm9ybWF0aW9uIGZl dGNoaW5nLg0KDQpJIHNlZS4gSSB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlLCBJIGp1c3QgZG9u 4oCZdCB0aGluayBpdCBtYXR0ZXJzLiBJIGFsc28gZGlzYWdyZWUgd2l0aCB5b3VyIGFzc2VydGlv biB0aGF0IGNsaWVudHMgc2hvdWxkbuKAmXQgZmV0Y2ggT0NTUCByZXNwb25zZXMsIENSTHMgb3Ig QUlBcy4gU2VuZGluZyBzdGFwbGVkIE9DU1AgcmVzcG9uc2VzIG9yIGFuIGVudGlyZSBjZXJ0aWZp Y2F0ZSBjaGFpbiBpcyBhIGdvb2Qgb3B0aW1pemF0aW9uIGFuZCBtYWtlcyB0aGUgVExTIGhhbmRz aGFrZSBlbmQgbW9yZSBxdWlja2x5LiBJIGNhbiBzZWUgd2h5IHBlb3BsZSB3b3VsZCBsaWtlIHRo YXQuIEJ1dCBmZXRjaGluZyB0aGVzZSB0aGluZ3MgZnJvbSB0aGUgSW50ZXJuZXQgaXMgbm8gZGlm ZmVyZW50IGZyb20gZmV0Y2hpbmcgb3RoZXIgaXRlbXMgZnJvbSB0aGUgSW50ZXJuZXQuIENsaWVu dHMgZG8gdGhpcyBhbGwgdGhlIHRpbWUuDQoNCkkgYWdyZWUgdGhhdCB0aGlzIGluY3JlYXNlcyB0 aGUgYXR0YWNrIHN1cmZhY2UsIGJ1dCB3aGF0IGtpbmRzIG9mIGF0dGFja3MgYXJlIHdlIHRhbGtp bmcgYWJvdXQ/IEEgdmVyeSBtaWxkIERvUyBhdHRhY2sgYnkgcG9pbnRpbmcgdGhlIGNsaWVudCBh dCBhIFVSTCB3aXRoIGEgcGV0YWJ5dGUgb2YgcmFuZG9tIGRhdGE/IEFuIGludmFsaWQgQ1JMPyBB IGJhZGx5IGZvcm1hdHRlZCBDQSBjZXJ0aWZpY2F0ZSB0aGF0IHdpbGwgY2F1c2UgYSBidWZmZXIg b3ZlcmZsb3cgb24gdGhlIGNsaWVudD8gIFRoYXQga2luZCBvZiBjZXJ0aWZpY2F0ZSBjb3VsZCBo YXZlIGJlZW4gc2VudCBpbiB0aGUgaGFuZHNoYWtlLiBUaGVzZSByaXNrcyBzZWVtIHRvIG1lIHRv IGJlIHBhcnQgbGlmZSBvbiB0aGUgSW50ZXJuZXQuIFRoZXnigJlyZSBub3Qgd29ydGggdGhlIGlz c3VlcyBvZiBzZW5kaW5nIGxhcmdlIG9iamVjdHMgb3ZlciBVRFAgZm9yIERUTFMgZm9yIGV4YW1w bGUuICBTbyBJIGFncmVlIHRoYXQgZm9yIHJlZ3VsYXIgVExTIHNlbmRpbmcgdGhlIGVudGlyZSBj aGFpbiBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8sIGFzIGlzIHNlbmRpbmcgYSBzdGFwbGVkIE9D U1AgcmVzcG9uc2UuIEkganVzdCBkb27igJl0IHRoaW5rIGJ1aWxkaW5nIGEgY2hhaW4gdGhyb3Vn aCBvdGhlciBtZWFucyBpcyBpbiBhbnkgd2F5IOKAnGJhZOKAnS4NCg0KWW9hdg0KDQo= --_000_cf9a644498a74eb3b870970eef93ed22svaexch1cygnacomcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIFlvYXYuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Zb2F2IE5pcjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIE1heSAxMywgMjAxNSAxOjU5IEFNPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBTbWl0aDxi cj4NCjxiPkNjOjwvYj4gVExTQGlldGYub3JnICh0bHNAaWV0Zi5vcmcpPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbVExTXSBbdGxzMTMtc3BlY10gcmVsYXggY2VydGlmaWNhdGVfbGlzdCBvcmRl cmluZyByZXF1aXJlbWVudHMgdG8gbWF0Y2ggY3VycmVudCBwcmFjdGljZSAoIzE2OSk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXkgMTMsIDIw MTUsIGF0IDM6MjggQU0sIEJyaWFuIFNtaXRoICZsdDs8YSBocmVmPSJtYWlsdG86YnJpYW5AYnJp YW5zbWl0aC5vcmciPmJyaWFuQGJyaWFuc21pdGgub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvYXYg TmlyICZsdDs8YSBocmVmPSJtYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnluaXIuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEJ1dCBhIG1hY2hpbmUvYXV0b21h dGEvYWxnb3JpdGhtIHRoYXQgd2lsbCBhdXRvbWF0aWNhbGx5IGRvd25sb2FkIG9iamVjdHM8YnI+ DQomZ3Q7IGZyb20gVVJMcyBmcm9tIHN0aWxsLXVudHJ1c3RlZCBkYXRhIHByb3ZpZGVkIGJ5IHRo ZSBwZWVyIGlzIGRlZmluaXRlbHk8YnI+DQomZ3Q7IGluc2VjdXJlIGFuZCBpcnJlc3BvbnNpYmxl Ljxicj4NCjxicj4NCkluIHRoYXQgc2Vuc2UsIGhvdyBpcyBBSUEgZGlmZmVyZW50IGZyb20gcmV2 b2NhdGlvbiBjaGVja2luZz8gV2hldGhlciB5b3UgdXNlIENSTHMgb3IgT0NTUCwgeW914oCZcmUg Zm9sbG93aW5nIGEgVVJMIGluIHRoZSAoc3RpbGwgdW50cnVzdGVkIG9yIGF0IGxlYXN0IHBvc3Np Ymx5IHJldm9rZWQpIGNlcnRpZmljYXRlIHRvIHJldHJpZXZlIGFuIG9iamVjdC48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4g eW91IGZldGNoIENSTHMgb3IgT0NTUCByZXNwb25zZXMsIHlvdSBhcmUgdXNpbmcgYSBVUkwgdGhh dCBoYXMgYmVlbiBhdXRoZW50aWNhdGVkIGJ5IGEgdHJ1c3RlZCBpc3N1ZXIsIGFzc3VtaW5nIHlv dSBkbyByZXZvY2F0aW9uIGNoZWNraW5nIGZyb20gdGhlIHJvb3QgdG8gdGhlIGVuZC1lbnRpdHks IHdoaWNoIGlzIHRoZSBzYWZlciB3YXkgb2YgZG9pbmcgaXQuIFdoZXJlYXMsIGluIEFJQSBjZXJ0 IGZldGNoaW5nDQogeW91IGFyZSBtYWtpbmcgYSByZXF1ZXN0IHRvIGFuIHVuYXV0aGVudGljYXRl ZCBVUkwuIFRoYXQgaXMgcXVpdGUgYSBiaWcgZGlmZmVyZW5jZSwgYmVjYXVzZSBpdCBpcyBtdWNo IGhhcmRlciB0byBnZXQgYSBDQSB0byBzaWduIGEgY2VydGlmaWNhdGUgd2l0aCB5b3VyIGNob3Nl biBPQ1NQIFVSTCB0aGFuIGl0IGlzIHRvIGp1c3QgZm9yZ2UgeW91ciBvd24gY2VydGlmaWNhdGUg d2l0aCB3aGF0ZXZlciBBSUEgY2FJc3N1ZXJzIFVSTCB5b3Ugd2FudA0KIHRvIGhhdmUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVsdGltYXRl bHksIGEgY2xpZW50IHNob3VsZG4ndCBmZXRjaCBPQ1NQIHJlc3BvbnNlcyBvciBDUkxzIGVpdGhl ciwgZm9yIG1hbnkgcmVhc29ucy4gT25lIG9mIHRoZSBiaWcgcmVhc29ucyBpcyB0aGF0IHRob3Nl IGZldGNoZXMgZ3JlYXRseSBpbmNyZWFzZSB0aGUgYXR0YWNrIHN1cmZhY2Ugb2YgdGhlIGNsaWVu dCBiZXlvbmQgd2hhdCBpcyBvdGhlcndpc2UgbmVjZXNzYXJ5LiBJbnN0ZWFkIHdlIG5lZWQgdG8N CiBtb3ZlIHRvIGEgbW9kZWwgd2hlcmUgcmV2b2NhdGlvbiBpbmZvcm1hdGlvbiBpcyBhbHdheXMg cHJvdmlkZWQgd2l0aGluIHRoZSBUTFMgaGFuZHNoYWtlIChlLmcuIE9DU1Agc3RhcGxpbmcgYW5k L29yIHNob3J0LWxpdmVkIGNlcnRpZmljYXRlcykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbnNlcXVlbnRseSwgd2Ugc2hvdWxkbid0IGFj Y2VwdCBBSUEgY2VydCBmZXRjaGluZyBhcyBnb29kIG9yIGV2ZW4gcmVhc29uYWJsZSBiZWhhdmlv ciBiYXNlZCBvbiBhbmFsb2dpZXMgdG8gcmV2b2NhdGlvbiBpbmZvcm1hdGlvbiBmZXRjaGluZy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzZWUuIEkgdW5k ZXJzdGFuZCB0aGUgZGlmZmVyZW5jZSwgSSBqdXN0IGRvbuKAmXQgdGhpbmsgaXQgbWF0dGVycy4g SSBhbHNvIGRpc2FncmVlIHdpdGggeW91ciBhc3NlcnRpb24gdGhhdCBjbGllbnRzIHNob3VsZG7i gJl0IGZldGNoIE9DU1AgcmVzcG9uc2VzLCBDUkxzIG9yIEFJQXMuIFNlbmRpbmcgc3RhcGxlZCBP Q1NQIHJlc3BvbnNlcyBvciBhbiBlbnRpcmUgY2VydGlmaWNhdGUgY2hhaW4gaXMgYSBnb29kIG9w dGltaXphdGlvbg0KIGFuZCBtYWtlcyB0aGUgVExTIGhhbmRzaGFrZSBlbmQgbW9yZSBxdWlja2x5 LiBJIGNhbiBzZWUgd2h5IHBlb3BsZSB3b3VsZCBsaWtlIHRoYXQuIEJ1dCBmZXRjaGluZyB0aGVz ZSB0aGluZ3MgZnJvbSB0aGUgSW50ZXJuZXQgaXMgbm8gZGlmZmVyZW50IGZyb20gZmV0Y2hpbmcg b3RoZXIgaXRlbXMgZnJvbSB0aGUgSW50ZXJuZXQuIENsaWVudHMgZG8gdGhpcyBhbGwgdGhlIHRp bWUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVl IHRoYXQgdGhpcyBpbmNyZWFzZXMgdGhlIGF0dGFjayBzdXJmYWNlLCBidXQgd2hhdCBraW5kcyBv ZiBhdHRhY2tzIGFyZSB3ZSB0YWxraW5nIGFib3V0PyBBIHZlcnkgbWlsZCBEb1MgYXR0YWNrIGJ5 IHBvaW50aW5nIHRoZSBjbGllbnQgYXQgYSBVUkwgd2l0aCBhIHBldGFieXRlIG9mIHJhbmRvbSBk YXRhPyBBbiBpbnZhbGlkIENSTD8gQSBiYWRseSBmb3JtYXR0ZWQgQ0EgY2VydGlmaWNhdGUgdGhh dA0KIHdpbGwgY2F1c2UgYSBidWZmZXIgb3ZlcmZsb3cgb24gdGhlIGNsaWVudD8gJm5ic3A7VGhh dCBraW5kIG9mIGNlcnRpZmljYXRlIGNvdWxkIGhhdmUgYmVlbiBzZW50IGluIHRoZSBoYW5kc2hh a2UuIFRoZXNlIHJpc2tzIHNlZW0gdG8gbWUgdG8gYmUgcGFydCBsaWZlIG9uIHRoZSBJbnRlcm5l dC4gVGhleeKAmXJlIG5vdCB3b3J0aCB0aGUgaXNzdWVzIG9mIHNlbmRpbmcgbGFyZ2Ugb2JqZWN0 cyBvdmVyIFVEUCBmb3IgRFRMUyBmb3IgZXhhbXBsZS4gJm5ic3A7U28gSQ0KIGFncmVlIHRoYXQg Zm9yIHJlZ3VsYXIgVExTIHNlbmRpbmcgdGhlIGVudGlyZSBjaGFpbiBpcyB0aGUgcmlnaHQgdGhp bmcgdG8gZG8sIGFzIGlzIHNlbmRpbmcgYSBzdGFwbGVkIE9DU1AgcmVzcG9uc2UuIEkganVzdCBk b27igJl0IHRoaW5rIGJ1aWxkaW5nIGEgY2hhaW4gdGhyb3VnaCBvdGhlciBtZWFucyBpcyBpbiBh bnkgd2F5IOKAnGJhZOKAnS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+WW9hdjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_cf9a644498a74eb3b870970eef93ed22svaexch1cygnacomcom_-- From nobody Wed May 13 10:11:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F4F1B3058; Wed, 13 May 2015 10:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 IUZKXgyJpfrT; Wed, 13 May 2015 10:11:39 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927C71ACC86; Wed, 13 May 2015 10:11:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,421,1427752800"; d="scan'208";a="118888187" Received: from 178.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.178]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 13 May 2015 19:11:27 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: <20150508210811.2024.97744.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 19:11:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86F03518-FE79-4236-939B-4250F2185B86@gmail.com> References: <20150508210811.2024.97744.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls@ietf.org, draft-ietf-tls-session-hash@ietf.org, The IESG , draft-ietf-tls-session-hash.shepherd@ietf.org, draft-ietf-tls-session-hash.ad@ietf.org, tls-chairs@ietf.org Subject: Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-session-hash-05: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 17:11:40 -0000 A question about procedure: I agree with both Kathleen's and Barry=92s comments. Should I incorporate them at this stage to produce a new draft, or = should I wait for=20 some official notification? Best, Karthik On 08 May 2015, at 23:08, Kathleen Moriarty = wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-tls-session-hash-05: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for your work on this and a well-written draft! The > considerations are very thorough, every time I had a question, I was = able > to find an answer in the draft. I do think a couple more references > could be helpful though. >=20 > 1. I think it would be good for section 6.4 to note that SSL 3.0 has = been > deprecated in > https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ > It's ahead of this draft in the RFC editor queue. >=20 > 2. It might be good to have a pointer to the UTA TLS Attack RFC7457 as > this attack is described in section 2.11 and there is no reference to = a > fix. It would be nice to show that known attacks are being resolved.=20= > https://tools.ietf.org/html/rfc7457#section-2.11 >=20 >=20 From nobody Wed May 13 11:12:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2891ACD7B for ; Wed, 13 May 2015 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, 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 2T8zo1dHQWDE for ; Wed, 13 May 2015 11:12:22 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7331ACD86 for ; Wed, 13 May 2015 11:12:15 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 96A74446B2; Wed, 13 May 2015 20:12:13 +0200 (CEST) X-purgate-ID: 152705::1431540733-00005316-29E8C384/0/0 X-purgate-size: 1336 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7496C421EA; Wed, 13 May 2015 20:12:13 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 690401B2F3; Wed, 13 May 2015 20:12:13 +0200 (CEST) In-Reply-To: To: Yoav Nir Date: Wed, 13 May 2015 20:12:13 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150513181213.690401B2F3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 18:12:24 -0000 Yoav Nir wrote: > >> Brian Smith wrote: >> >> When you fetch CRLs or OCSP responses, you are using a URL that has been >> authenticated by a trusted issuer, assuming you do revocation checking >> from the root to the end-entity, which is the safer way of doing it. >> Whereas, in AIA cert fetching you are making a request to an >> unauthenticated URL. That is quite a big difference, because it is >> much harder to get a CA to sign a certificate with your chosen OCSP URL >> than it is to just forge your own certificate with whatever >> AIA caIssuers URL you want to have. >> [...] >> Consequently, we shouldn't accept AIA cert fetching as good or even >> reasonable behavior based on analogies to revocation information fetching. > > I see. I understand the difference, I just don?t think it matters. > [...] > I agree that this increases the attack surface, but what kinds of > attacks are we talking about? In the TLS WG, we do not need to defer PKIX specifications for dangerous behaviour, because such behaviour was already proposed in the very first TLS extensions document (rfc3546), and equipped with security considerations that give a glimpse at the attackers vast possibilities from such a facility. https://tools.ietf.org/html/rfc3546#section-6.3 -Martin From nobody Wed May 13 13:58:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8244D1A8F39 for ; Wed, 13 May 2015 13:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 eZTQcUjJNvWY for ; Wed, 13 May 2015 13:58:21 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0561A8AC4 for ; Wed, 13 May 2015 13:58:21 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id C3476188780; Wed, 13 May 2015 23:58:18 +0300 (EEST) Date: Wed, 13 May 2015 23:58:17 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150513205817.GA24851@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> <20150413181144.GA720@LK-Perkele-VII> <20150413191733.GB1016@LK-Perkele-VII> <20150413194605.GA1377@LK-Perkele-VII> <20150414054606.GA7053@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150414054606.GA7053@LK-Perkele-VII> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 20:58:23 -0000 On Tue, Apr 14, 2015 at 08:46:06AM +0300, Ilari Liusvaara wrote: > On Mon, Apr 13, 2015 at 12:57:51PM -0700, Martin Thomson wrote: > > On 13 April 2015 at 12:46, Ilari Liusvaara wrote: > > > On Mon, Apr 13, 2015 at 12:30:04PM -0700, Martin Thomson wrote: > > >> > > >> You assume that 0-RTT doesn't fall into that third category. I hadn't. > > > > > > Well, the only examples of 3) I can come up with would be > > > - Resumption-only (fail enteriely if not resumable) > > > - Something possibly triggering some new type (neither 1RTT, 2RTT > > > nor abbrevated) of handshake. > > > > > > Of course, I then have trouble even thinking what such new type > > > of handshake could be. > > > > Well, 0-RTT could be a third category. As Hugo originally proposed > > it, this would have the authentication of the connection be based on > > successfully proving the ability to generate g^xy. That's stronger > > than resumption, but relies on the authentication of a previous > > session in the same way that resumption does. You might consider that > > to be resumption, or not. > > I don't consider that to be resumption, since asymmetric crypto is > involved (the whole point of resumption is to avoid asymmetric > crypto). Well, the question is really where the keying material for encrypting/ decrypting 0-RTT is obtained. There are three obvious candidates: 1) (x*S_old = s_old*X, ClientRandom) 2) (rPMS, ClientRandom) 3) (PSK, ClientRandom) [(x*S=s*X, ClientRandom) and (x*S_new=s_new*X, ClientRandom) do not work, the first is mathematically ill-defined, and the second is uncomputable for client] Each is obvious candidate to one server key exchange type: 1) for full DHE handshake. 2) for abbrevated handshake. 3) for full pure-PSK handshake. However, no other combination works well, either because it makes the server sad, or the server doesn't have the needed keys. Unifying abbrevated and pure-PSK handshakes doesn't help much here (since keys presumably won't match). Now, the real issue: Suppose that client is willing to accept multiple of the three key exchange types (full-DHE, abbrevated and pure-PSK) at once. Now, all three are expected to use different keys. Under what keys does client encipher the 0RTT data? Indirect keying (key wrapping) leads to "interesting" security analysis, as inner encryption effectively becomes unauthenticated. (Also, the used 0-RTT key, if any has to be mixed in with appMS to prevent an attack). -Ilari From nobody Wed May 13 14:01:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3508B1A8FD6; Wed, 13 May 2015 14:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTJ4hVP-Hdkx; Wed, 13 May 2015 14:01: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 879A21A8BB2; Wed, 13 May 2015 14:01:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4428DBE54; Wed, 13 May 2015 22:01:19 +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 TssYlQl7zSzg; Wed, 13 May 2015 22:01:17 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.109]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AE85FBE51; Wed, 13 May 2015 22:01:17 +0100 (IST) Message-ID: <5553BB9D.6070804@cs.tcd.ie> Date: Wed, 13 May 2015 22:01:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Karthikeyan Bhargavan , Kathleen Moriarty References: <20150508210811.2024.97744.idtracker@ietfa.amsl.com> <86F03518-FE79-4236-939B-4250F2185B86@gmail.com> In-Reply-To: <86F03518-FE79-4236-939B-4250F2185B86@gmail.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tls@ietf.org, draft-ietf-tls-session-hash@ietf.org, The IESG , draft-ietf-tls-session-hash.shepherd@ietf.org, draft-ietf-tls-session-hash.ad@ietf.org, tls-chairs@ietf.org Subject: Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-session-hash-05: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 21:01:22 -0000 On 13/05/15 18:11, Karthikeyan Bhargavan wrote: > A question about procedure: > > I agree with both Kathleen's and Barry’s comments. > Should I incorporate them at this stage to produce a new draft, or should I wait for > some official notification? Probably best to hold off until after the IESG call tomorrow in case we collect some more comments. So, I'd say let's wait 'till Friday for document editing, but do feel free to respond by email in the meantime. S > > Best, > Karthik > > On 08 May 2015, at 23:08, Kathleen Moriarty wrote: > >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-tls-session-hash-05: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thank you for your work on this and a well-written draft! The >> considerations are very thorough, every time I had a question, I was able >> to find an answer in the draft. I do think a couple more references >> could be helpful though. >> >> 1. I think it would be good for section 6.4 to note that SSL 3.0 has been >> deprecated in >> https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ >> It's ahead of this draft in the RFC editor queue. >> >> 2. It might be good to have a pointer to the UTA TLS Attack RFC7457 as >> this attack is described in section 2.11 and there is no reference to a >> fix. It would be nice to show that known attacks are being resolved. >> https://tools.ietf.org/html/rfc7457#section-2.11 >> >> > From nobody Wed May 13 14:19:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682DD1ACE64 for ; Wed, 13 May 2015 14:19:01 -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 Pn1-GEe6TQ9J for ; Wed, 13 May 2015 14:19:00 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B30A1ACE52 for ; Wed, 13 May 2015 14:19:00 -0700 (PDT) Received: by yhda23 with SMTP id a23so17564642yhd.2 for ; Wed, 13 May 2015 14:18:59 -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=b3bP2T7iiWWtvBOxlvdpv/NrAWlnTURQnLQYIY1nW9o=; b=PhhautS0Eg3gFbo0OPRmuvDMD3YNgGdrcvOfLKjFlypJUiL1UM94CDMgx0e0Ao4Lay bX7nc/WH78DKYZlVkGGZnXd/W8pAh1pYgjTqQbMSLm+5mdjLKjYOrUIi6v3xPpPkhdpZ Qz/NTsc0ofCPQ64yo1MVyZ0tqoIoBKTzbRvJ+x2xvt8vqeQMt2OPnWAOa6zyMVK6BaM7 8NFUKbPhntZXW8ju2YkBuonHG9XAb1i3jzHOG/71n0xzzqvJUdBgFgx9pq2bAJ+g/G8V vFzsmGeLr2VO059ECSDZjb2Eupn3irfIxsw+XbBqhALLFa2ynNLhCxbMBrCvFQtDp7yZ yf/Q== MIME-Version: 1.0 X-Received: by 10.170.44.208 with SMTP id 199mr940941ykm.101.1431551939630; Wed, 13 May 2015 14:18:59 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Wed, 13 May 2015 14:18:59 -0700 (PDT) In-Reply-To: <20150513205817.GA24851@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> <20150413181144.GA720@LK-Perkele-VII> <20150413191733.GB1016@LK-Perkele-VII> <20150413194605.GA1377@LK-Perkele-VII> <20150414054606.GA7053@LK-Perkele-VII> <20150513205817.GA24851@LK-Perkele-VII> Date: Wed, 13 May 2015 14:18:59 -0700 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 21:19:01 -0000 On 13 May 2015 at 13:58, Ilari Liusvaara wrote: > Suppose that client is willing to accept multiple of the three key > exchange types (full-DHE, abbrevated and pure-PSK) at once. Now, > all three are expected to use different keys. Under what keys does > client encipher the 0RTT data? Why wouldn't the client just choose and signal the option they chose? BTW, it has been suggested that there might need to be some material from the server contributed to this mix to prevent an unknown key share attack. So secret[x] + ClientRandom is not quite sufficient. From nobody Wed May 13 15:29:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3D1A9062 for ; Wed, 13 May 2015 15:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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_NONE=-0.0001] 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 3ORK5XSIZN0E for ; Wed, 13 May 2015 15:29:41 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 34F9F1ACEDE for ; Wed, 13 May 2015 15:29:30 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 0D790778093; Wed, 13 May 2015 15:29:30 -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=kqam7CMbZclyy+ wIPook4jz98xY=; b=Zi/7VsVw7oqXlLf42diQSZ7ioIr07wxx5iv+uzayZMZ6qT KEAXa7hrKeVOtT5tQgVPpSkP89KNw+NtywPnWuByUZUkHC1DIqdcaelq/sE47SIr S5AHsHp5iT8s59GvIH6hiwW9FgSXvbvqelPVRioGk9UhUIxhbyg2pSdHe3OsQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPA id A981177808C; Wed, 13 May 2015 15:29:29 -0700 (PDT) Date: Wed, 13 May 2015 17:29:29 -0500 From: Nico Williams To: Ilari Liusvaara Message-ID: <20150513222927.GZ7287@localhost> References: <20150412165542.GA19481@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150412165542.GA19481@LK-Perkele-VII> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:29:42 -0000 On Sun, Apr 12, 2015 at 07:55:42PM +0300, Ilari Liusvaara wrote: > I thought about 0-RTT some more, here are some questions. Few > might be protocol-relevant, most are only about guidance. > > 1) What is the recommended 0-RTT API model on server side > (also consider server apps or app implementations that don't > support 0-RTT)? The app should request 0-RTT data; server should drop it if not requested before receipt of ClientHello. > 2) What are the semantics of successfully received 0-RTT transfer > (especially considering the client-side autoretransmit on > failure)? Leave it to the app. A replay cache option would be nice, but the app probably needs to provide this itself (since, after all, it's not just a question of "have we seen this before", but also, "have we processed this before"). > 3) How does 0-RTT interact with ALPN (especially considering > potential for multiple protocol candidates)? The client has committed to an application protocol. Although that's not necessarily quite so true: elsewhere we're talking about an RFC2712 (Kerberos in TLS) replacement where ideally we could start sending GSS-API context tokens as early as possible (when the client doesn't want confidentiality protection for its name). Such a protocol could still negotiate from N>1 application protocols. (GSS-in-TLS as an application protocol using 0-RTT data is a perfect example of a *safe* use of 0-RTT data, provided that the intention is to also do channel binding. Don't think about GSS too hard here. Just think about the point that some 0-RTT uses will be quite safe.) > 4) Can handshake with attempted 0-RTT be securely downgraded to > v1.2 (obviously causes the 0-RTT to fail)? Sure, but the 0-RTT data must get dropped. > 5) There is potential footgun if 0-RTT is used with (DH-)PSK: The > PSK authenticates the connection immediately, but 0-RTT is > as replayable as ever. What to do with that? 0-RTT is a footgun. Choice of ciphersuite seems a bit beside the point, though it's possible that positive authentication status of the client may cause applications to fire the footgun. I'd insist on the authentication status not being complete until the handshake completes in all cases, and I'd insist on pointing out that the 0-RTT data is a lot of rope. > 6) The same as above, but when attempting to resume a session. > with a client certificate (since cc is property of session)? Ditto. > 7) What guidance to give regarding what data can be put to 0-RTT, > considering its replayability? First, that it's replayable. Second, that the application should only send such data where doing so is idempotent, or where it is part of something like an application-layer authentication protocol that will do its own replay protection, or where the application has its own replay detection cache. > 8) If resumption attempt has 0-RTT data, what keying material is > used for the 0-RTT? In principle, none. However, a key derived from the resumption ticket's session key would be nice. See below. The PSK case could be similar as well. > 9) Can server roll over its 0-RTT keys without waiting for the > previous ones to expire? In relation to (8)? No. But we could do something where we use timestamps, a la Kerberos, to greatly reduce the time window that any replay caches have to protect, at least for session resumption 0-RTT data! > 10) How is attacker establishing a session (or at least decoding > server's first application flight) replaying captured > 0-RTT data prevented (since that could leak quite a bit of > info about what's in 0-RTT blob)? Or not? IIUC, it isn't. Nico -- From nobody Wed May 13 22:59:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819CF1B33B7 for ; Wed, 13 May 2015 22:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 ygO-SeM4ZftS for ; Wed, 13 May 2015 22:59:33 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957E31B33B0 for ; Wed, 13 May 2015 22:59:32 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id DB5CD818AA; Thu, 14 May 2015 08:59:29 +0300 (EEST) Date: Thu, 14 May 2015 08:59:29 +0300 From: Ilari Liusvaara To: Nico Williams Message-ID: <20150514055929.GA27098@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> <20150513222927.GZ7287@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150513222927.GZ7287@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 05:59:42 -0000 On Wed, May 13, 2015 at 05:29:29PM -0500, Nico Williams wrote: > On Sun, Apr 12, 2015 at 07:55:42PM +0300, Ilari Liusvaara wrote: > > > 2) What are the semantics of successfully received 0-RTT transfer > > (especially considering the client-side autoretransmit on > > failure)? > > Leave it to the app. A replay cache option would be nice, but the app > probably needs to provide this itself (since, after all, it's not just a > question of "have we seen this before", but also, "have we processed > this before"). If 0-RTT fails, client's first reaction is probably to replay the failed 0-RTT data, or something equivalent to it... > > 3) How does 0-RTT interact with ALPN (especially considering > > potential for multiple protocol candidates)? > > The client has committed to an application protocol. > > Although that's not necessarily quite so true: elsewhere we're talking > about an RFC2712 (Kerberos in TLS) replacement where ideally we could > start sending GSS-API context tokens as early as possible (when the > client doesn't want confidentiality protection for its name). Such a > protocol could still negotiate from N>1 application protocols. > > (GSS-in-TLS as an application protocol using 0-RTT data is a perfect > example of a *safe* use of 0-RTT data, provided that the intention is to > also do channel binding. Don't think about GSS too hard here. Just > think about the point that some 0-RTT uses will be quite safe.) So consideration that only put compatible ALPN IDs (that could lead to connection failures, due to incomplete set)? > > 4) Can handshake with attempted 0-RTT be securely downgraded to > > v1.2 (obviously causes the 0-RTT to fail)? > > Sure, but the 0-RTT data must get dropped. Actually, thinking about it, ability to tolerate downgrade (losing 0-RTT) isn't that important if one has already to restrict ALPN. > > 8) If resumption attempt has 0-RTT data, what keying material is > > used for the 0-RTT? > > In principle, none. However, a key derived from the resumption ticket's > session key would be nice. See below. > > The PSK case could be similar as well. Well, None means unencrypted? :-) And yes, resumption ticket / PSK key would be nice, saves server quite expensive asymmetric-key operation. > > 9) Can server roll over its 0-RTT keys without waiting for the > > previous ones to expire? > > In relation to (8)? No. But we could do something where we use > timestamps, a la Kerberos, to greatly reduce the time window that any > replay caches have to protect, at least for session resumption 0-RTT > data! I mean server doing full (DH) handshake, accepting 0-RTT and signaling new 0-RTT keys for future connections in the same connection. (Obviously if session keys are used, the 0-RTT keys expire with the session context). I.e. C->S: [full DH, 0-RTT data: encrypted using x*S_0, (kid k_0)] S->C: [0-RTT accepted] S->C: [new 0-RTT key S_1 (kid k_1), expected valid until T_1] S->C: [Handshake complete] (In "DH-based" key exchange, it is undefined behaviour for server to attempt that, since it makes no distinction between old and new key). > > 10) How is attacker establishing a session (or at least decoding > > server's first application flight) replaying captured > > 0-RTT data prevented (since that could leak quite a bit of > > info about what's in 0-RTT blob)? Or not? > > IIUC, it isn't. AFAIK, if 0-RTT is accepted, hashing in 0-RTT keys (or closely related values) should take care of that. -Ilari From nobody Wed May 13 23:09:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7521ACF09 for ; Wed, 13 May 2015 23:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 gIDNXRBoJEwF for ; Wed, 13 May 2015 23:09:02 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7ED11B33CD for ; Wed, 13 May 2015 23:09:01 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id D8B1590041; Thu, 14 May 2015 09:08:59 +0300 (EEST) Date: Thu, 14 May 2015 09:08:59 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150514060859.GB27098@LK-Perkele-VII> References: <20150413181144.GA720@LK-Perkele-VII> <20150413191733.GB1016@LK-Perkele-VII> <20150413194605.GA1377@LK-Perkele-VII> <20150414054606.GA7053@LK-Perkele-VII> <20150513205817.GA24851@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 06:09:04 -0000 On Wed, May 13, 2015 at 02:18:59PM -0700, Martin Thomson wrote: > On 13 May 2015 at 13:58, Ilari Liusvaara wrote: > > Suppose that client is willing to accept multiple of the three key > > exchange types (full-DHE, abbrevated and pure-PSK) at once. Now, > > all three are expected to use different keys. Under what keys does > > client encipher the 0RTT data? > > > Why wouldn't the client just choose and signal the option they chose? Just one allowed, or multiple (server picks one)? :-) > BTW, it has been suggested that there might need to be some material > from the server contributed to this mix to prevent an unknown key > share attack. So secret[x] + ClientRandom is not quite sufficient. Any specifics? Is this somehow related to attack that arises if client does not do Proof-of-Possession of the 0-RTT key[1]? [1] AFAIK, one way to do that PoP is to mix the key (or closely related value) into appMS if 0-RTT is accepted. -Ilari From nobody Thu May 14 01:52:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254101B3553; Thu, 14 May 2015 01:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEei44ZYG6Sn; Thu, 14 May 2015 01:52: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 0F2F11B3550; Thu, 14 May 2015 01:52:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F2F50BE79; Thu, 14 May 2015 09:52:17 +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 Q5_TXH2vK1WJ; Thu, 14 May 2015 09:52:16 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.109]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 66EEEBE54; Thu, 14 May 2015 09:52:16 +0100 (IST) Message-ID: <55546240.3010902@cs.tcd.ie> Date: Thu, 14 May 2015 09:52:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150509225248.21800.83581.idtracker@ietfa.amsl.com> In-Reply-To: <20150509225248.21800.83581.idtracker@ietfa.amsl.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-tls-session-hash.shepherd@ietf.org, draft-ietf-tls-session-hash.ad@ietf.org, tls-chairs@ietf.org, draft-ietf-tls-session-hash@ietf.org, tls@ietf.org Subject: Re: [TLS] Barry Leiba's Discuss on draft-ietf-tls-session-hash-05: (with DISCUSS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 08:52:22 -0000 Folks - I note this didn't get an answer. I don't recall that the WG considered it, and I'm sure if it had the conclusion could have gone either way (and a random choice would have been fine too:-) but can you confirm or correct me on that please? If you can do it before the telechat today (by ~1400 UTC) that'd be great. Thanks, S. On 09/05/15 23:52, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-tls-session-hash-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a DISCUSS purely because I want to discuss it; whatever the > result is, I will be clearing the DISCUSS, and not delaying the document > on this point: The last paragraph of Section 4 makes me wonder whether > this should "update" 5246. Basically, while this is an extension (which > wouldn't normally use "updates"), it's one that you're proposing as > standard behavior, and not really as an extension. > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu May 14 01:58:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F991B3554; Thu, 14 May 2015 01:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 FCuRHyD3WNQw; Thu, 14 May 2015 01:58:18 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBA21A1BA5; Thu, 14 May 2015 01:58:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,426,1427752800"; d="scan'208";a="145893277" Received: from wifi-auth-191208.inria.fr ([128.93.191.208]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 14 May 2015 10:58:15 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: <55546240.3010902@cs.tcd.ie> Date: Thu, 14 May 2015 10:58:14 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20150509225248.21800.83581.idtracker@ietfa.amsl.com> <55546240.3010902@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls@ietf.org, draft-ietf-tls-session-hash@ietf.org, The IESG , draft-ietf-tls-session-hash.shepherd@ietf.org, Barry Leiba , draft-ietf-tls-session-hash.ad@ietf.org, tls-chairs@ietf.org Subject: Re: [TLS] Barry Leiba's Discuss on draft-ietf-tls-session-hash-05: (with DISCUSS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 08:58:20 -0000 The session-hash draft has roughly the same impact as RFC5746, which says: "Updates: 5246, 4366, 4347, 4346, 2246" We would be happy to add this list or a subset. Other RFCs affected by the current proposal are: rfc5929, rfc5705, rfc5746. Should we note these in any way, other than as Informative References? Best, Karthik On 14 May 2015, at 10:52, Stephen Farrell wrote: > > Folks - I note this didn't get an answer. I don't recall that the WG > considered it, and I'm sure if it had the conclusion could have gone > either way (and a random choice would have been fine too:-) but can > you confirm or correct me on that please? If you can do it before the > telechat today (by ~1400 UTC) that'd be great. > > Thanks, > S. > > On 09/05/15 23:52, Barry Leiba wrote: >> Barry Leiba has entered the following ballot position for >> draft-ietf-tls-session-hash-05: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This is a DISCUSS purely because I want to discuss it; whatever the >> result is, I will be clearing the DISCUSS, and not delaying the document >> on this point: The last paragraph of Section 4 makes me wonder whether >> this should "update" 5246. Basically, while this is an extension (which >> wouldn't normally use "updates"), it's one that you're proposing as >> standard behavior, and not really as an extension. >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> From nobody Thu May 14 08:29:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEF71ACD6A for ; Thu, 14 May 2015 02:24: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, 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 cm0h78EglwRE for ; Thu, 14 May 2015 02:24:08 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 9676B1A70E1 for ; Thu, 14 May 2015 02:24:07 -0700 (PDT) Received: by wicnf17 with SMTP id nf17so86799151wic.1 for ; Thu, 14 May 2015 02:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:content-type:message-id:mime-version:subject:date:references :cc:to; bh=RheGW+1Jhrl806REyjaqbbpw+9jVPMz6hzmnjBnqrpc=; b=WHnLrt9/eMIJcn0bk2Cw9IiH9WfnoWpIyXLpIcnf/Wz80QIjy+bMcKg0VmjX1dFDC4 BAPPTNh3ngnoYrZhdWUjSXoZknBl2vQbi+XtNRx44K400mGj/r/FDGmBpOUs7ljVFQmh qyhH2pm4eTi8mr6XQVKEc/luPbzEwev0kiDNE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:cc:to; bh=RheGW+1Jhrl806REyjaqbbpw+9jVPMz6hzmnjBnqrpc=; b=blVgjlQ38DLeBH97QUQORB7AKevXetn8qgn8wSf81qI30T5EUiaqofuzuhJGkFTVLb 0eqaZi+LfjU8tsxF7gzRhZcZH2VYRojQC3A09t6i3E/jcqi+YPd9EFRwp9BUE530CBQG oi7CWyBNoRm4c993q7kycjSMQQqyZQKXDFeGVoaUxju5Ip9Ox23ZJud51MJWwtjvWPmp ozA2g/P+u/Mrkh7v7EXLEFVm6B643RkqzotwhADguG9FVLCeP/8ccXq0LcpXLfsnj2NF B+T3IeMutvRRaReNo3N4K1CGPSob+fiB7jPKpiyHSeAGQgLzQGQzaJPXYes/A9KX7tuQ 2mug== X-Gm-Message-State: ALoCoQlbsmrhNRdnrmIlIf+CmN8e21cI5w/IH+vgQJaxp8mVShIxbq2QukAQUmcYECAsEIbT53b7 X-Received: by 10.194.118.135 with SMTP id km7mr5983026wjb.125.1431595446317; Thu, 14 May 2015 02:24:06 -0700 (PDT) Received: from [192.168.0.3] (cpc12-lewi13-2-0-cust138.2-4.cable.virginm.net. [82.22.12.139]) by mx.google.com with ESMTPSA id um5sm37171274wjc.1.2015.05.14.02.24.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 02:24:05 -0700 (PDT) From: Vlad Krasnov Content-Type: multipart/alternative; boundary="Apple-Mail=_B8079043-AEA9-433B-B05A-CF48F7C49D1C" Message-Id: <31102898-FF04-49BB-9DCB-5BBF60E7D26E@cloudflare.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Date: Thu, 14 May 2015 10:24:03 +0100 References: <20150513193848.6725.71264.idtracker@ietfa.amsl.com> To: tls@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Thu, 14 May 2015 08:28:58 -0700 Cc: Olafur Gudmundsson , John Graham-Cumming Subject: [TLS] Fwd: New Version Notification for draft-vkrasnov-tls-jumpstart-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:24:10 -0000 --Apple-Mail=_B8079043-AEA9-433B-B05A-CF48F7C49D1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello all, This is yet another TLS handshake acceleration method we devised in = CloudFlare.=20 It parallelizes the TLS handshake with the TCP handshake, by sending = part of the data over UDP. It is extremely easy to implement in software, legacy compatible, does = not require any prior communication with the server, and will work with = any current or future version of TLS. The real world savings are a whole RTT in both directions, although over = unreliable channels a fallback to legacy protocol may take place, = without notable performance penalty. For session resumption the protocol has essentially 0-RTT (completely = absorbed in TCP latency). Please review and provide your comments. Thanks, Vlad > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-vkrasnov-tls-jumpstart-00.txt > Date: 13 May 2015 20:38:48 BST > To: "Vlad Krasnov" , "Vlad Krasnov" = >=20 >=20 > A new version of I-D, draft-vkrasnov-tls-jumpstart-00.txt > has been successfully submitted by Vlad Krasnov and posted to the > IETF repository. >=20 > Name: draft-vkrasnov-tls-jumpstart > Revision: 00 > Title: Transport Layer Security (TLS) Jump Start > Document date: 2015-05-13 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-vkrasnov-tls-jumpstart-00.txt > Status: = https://datatracker.ietf.org/doc/draft-vkrasnov-tls-jumpstart/ > Htmlized: = https://tools.ietf.org/html/draft-vkrasnov-tls-jumpstart-00 >=20 >=20 > Abstract: > This document specifies an optional behavior of TLS implementation > called Jump Start. It alters the way the initial Client and Server > handshake messages reach their destination, but not the protocol > data, and can be implemented unilaterally. The TLS Jump Start > feature leads to a latency reduction of one round trip for all > handshakes (on average). >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_B8079043-AEA9-433B-B05A-CF48F7C49D1C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello all,

This is yet another TLS handshake acceleration method we = devised in CloudFlare. 
It parallelizes the TLS = handshake with the TCP handshake, by sending part of the data over = UDP.

It is = extremely easy to implement in software, legacy compatible, does not = require any prior communication with the server, and will work with any = current or future version of TLS.
The real world = savings are a whole RTT in both directions, although over unreliable = channels a fallback to legacy protocol may take place, without notable = performance penalty.
For session resumption the = protocol has essentially 0-RTT (completely absorbed in TCP = latency).

Please= review and provide your comments.

Thanks,
Vlad

Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-vkrasnov-tls-jumpstart-00.txt
Date: = 13 May 2015 20:38:48 BST
To: = "Vlad Krasnov" <vlad@cloudflare.com>, "Vlad Krasnov" <vlad@cloudflare.com>


A new version of I-D, = draft-vkrasnov-tls-jumpstart-00.txt
has been successfully = submitted by Vlad Krasnov and posted to the
IETF = repository.

Name: = draft-vkrasnov-tls-jumpstart
Revision: 00
Title:= = Transport Layer Security (TLS) Jump Start
Document = date: = 2015-05-13
Group: Individual Submission
Pages:= = 8
URL: =            https://www.ietf.org/internet-drafts/draft-vkrasnov-tls-jumpsta= rt-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-vkrasnov-tls-jumpstart/<= /a>
Htmlized:       https://tools.ietf.org/html/draft-vkrasnov-tls-jumpstart-00=


Abstract:
=   This document specifies an optional behavior of TLS = implementation
  called Jump Start.  It = alters the way the initial Client and Server
=   handshake messages reach their destination, but not the = protocol
  data, and can be implemented = unilaterally.  The TLS Jump Start
=   feature leads to a latency reduction of one round trip for = all
  handshakes (on average).




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


= --Apple-Mail=_B8079043-AEA9-433B-B05A-CF48F7C49D1C-- From nobody Thu May 14 18:55:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0F11B2D4A for ; Thu, 14 May 2015 18:55:15 -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, 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 Pu21N-DNc2y6 for ; Thu, 14 May 2015 18:55:10 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id DE9C41B2D42 for ; Thu, 14 May 2015 18:55:09 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 21D37165E5A; Fri, 15 May 2015 01:55:09 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 16777165E58; Fri, 15 May 2015 01:55:09 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 126EF1E07E; Fri, 15 May 2015 01:55:09 +0000 (GMT) Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 14 May 2015 20:55:08 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1076.000; Thu, 14 May 2015 20:55:08 -0500 From: "Salz, Rich" To: Vlad Krasnov , "tls@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-vkrasnov-tls-jumpstart-00.txt Thread-Index: AQHQjlq46CW6qi1NDkijh9Axl1/L0Z18RsRg Date: Fri, 15 May 2015 01:55:08 +0000 Message-ID: <8e1f4f150dc248e8b47af7e6c33a5376@ustx2ex-dag1mb4.msg.corp.akamai.com> References: <20150513193848.6725.71264.idtracker@ietfa.amsl.com> <31102898-FF04-49BB-9DCB-5BBF60E7D26E@cloudflare.com> In-Reply-To: <31102898-FF04-49BB-9DCB-5BBF60E7D26E@cloudflare.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.43.219] Content-Type: multipart/alternative; boundary="_000_8e1f4f150dc248e8b47af7e6c33a5376ustx2exdag1mb4msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: Olafur Gudmundsson , John Graham-Cumming Subject: Re: [TLS] Fwd: New Version Notification for draft-vkrasnov-tls-jumpstart-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 01:55:15 -0000 --_000_8e1f4f150dc248e8b47af7e6c33a5376ustx2exdag1mb4msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If an adversary just wants to DoS your server, they don't care if you respo= nd or not, and can trivially send thousands of clientHello messages with sp= oofed IP address. Or am I missing something obvious? It's like DNS floodi= ng, but with extra CPU cost, isn't it? -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_8e1f4f150dc248e8b47af7e6c33a5376ustx2exdag1mb4msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If an adversary just want= s to DoS your server, they don’t care if you respond or not, and can = trivially send thousands of clientHello messages with spoofed IP address.  Or am I missing something obvious?  It’s like= DNS flooding, but with extra CPU cost, isn’t it?

 <= /p>

-- 

Senior Architect, Akamai = Technologies

IM: richsalz@jabber.at Tw= itter: RichSalz

 <= /p>

--_000_8e1f4f150dc248e8b47af7e6c33a5376ustx2exdag1mb4msgcorpak_-- From nobody Thu May 14 19:38:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243471A1B4C for ; Thu, 14 May 2015 19:38:01 -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 pS9CChY4lHrX for ; Thu, 14 May 2015 19:38:00 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65891A1ADF for ; Thu, 14 May 2015 19:37:59 -0700 (PDT) Received: by wicnf17 with SMTP id nf17so118866802wic.1 for ; Thu, 14 May 2015 19:37:58 -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=a81xJcz9m7UEqFn2WtGLG+51ikXIoX0NuTs2Zznkn9c=; b=qN4DHOEy/RyTEz9DSzYfqKYyBQoIUzom3WsftpAjGexQEBgjgzlfTuyZyYyph5mWc1 B3h9ko1KBTDH73UZR+C0L6SUq0uLbDiJqutDf+3f+n36InZOZj0JwDpWBRjsXrX4w4PQ l4M1F6O/9S66iBRu4q0lmOKkir8agcB50/EowPwtVy50hCFuu7F3g0oHmvrxYJj3x0EI cL4mc8bqyb/iZ/si4xCju+1+v4Obi5OP460t28O7oKYEQyh4Rx81RBZAItWB0NNV5qlH 53YQtOQ1QpBCQHxh8G3pLLIcJ/KxUJy4f4UU/OhZixqdLaLmbXZzWYeP4W6IJ0ngPmqf 6wnA== MIME-Version: 1.0 X-Received: by 10.194.123.4 with SMTP id lw4mr4887162wjb.94.1431657478657; Thu, 14 May 2015 19:37:58 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Thu, 14 May 2015 19:37:58 -0700 (PDT) Date: Thu, 14 May 2015 19:37:58 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] DoS risks from draft-vkrasnov-tls-jumpstart-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 02:38:01 -0000 Dear all, I'd like to explain some of the ways in which draft-vkrasnov-tls-jumpstart may provide opportunity for mischief. The first, and most obvious, is that responses are considerably larger than requests, leading to amplification. The second is that each request creates state that is supposed to be stored on the server, leading to exhaustion of server resources. There does not appear to be a cookie mechanism to mitigate this problem. For resumed connections these problems are much less serious. It may be that resumption only is a better fit for this approach to latency reduction. Sincerely, Watson Ladd From nobody Thu May 14 23:14:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EEE1A92B2 for ; Thu, 14 May 2015 23:14: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, 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 Epmt5of3Jkh6 for ; Thu, 14 May 2015 23:14:30 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56851A9239 for ; Thu, 14 May 2015 23:14:29 -0700 (PDT) Received: by wibt6 with SMTP id t6so44733549wib.0 for ; Thu, 14 May 2015 23:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5GsieQfsoK6WGtQM1jPahI0aTglnyTuhaqHjVuQXr88=; b=xOTqgegtOP+rL7IThnnnLoHv8sYMikZXYFc3ab6T1E5Ti+nL9QALDQpyS2/1D+LanA LxUZeHnMoSWfZiQVxj2hW/TX5H/5CLUuRa+QEs8jWLQoSd9YBi7nXlAxH7pI4yrjMmB4 JqHJd5Ic5mwqCx7zQPtwIwKntm2zZETs1Q0Zk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5GsieQfsoK6WGtQM1jPahI0aTglnyTuhaqHjVuQXr88=; b=XybuqBZ0lVGjaKDkpm3eCWkkVZhchrGi+rRQEx6b9/nvcyh+aBWnlwnfNr6sp0ijgw +ZrNMloU+siGbg1SMQwBVUdw1mAILjzNDhEbukiBT2m6dP4yd5K9TjF0nJSRtDt/pVGO k8mYakctZEcBgdWq8/njAg5ceGqPYm0UL3Q0bTDdx8LMHqF2AD4748LSjBATJXHI6Xu/ 3deIByWS/iAgVBTThd+Vuw71LXgtO/xg+Jkj6HU80Y7tyC00Kwz9MfCrWHrnJm9x1tWT KOXU/Hyhfr/kmvKOrhiQKDRUVFjgr9DRWXhVtpgC3lG8oaQ6QK3eH+1O4EjJl+BBiFGX +ArA== X-Gm-Message-State: ALoCoQn3YFbpQ/421e7nwvgzf0DuR1PoGAe3BPUGwi5TL20ZU9W8QpvZ44lYxddVH11NE5wggUiN X-Received: by 10.194.176.225 with SMTP id cl1mr14796291wjc.45.1431670468706; Thu, 14 May 2015 23:14:28 -0700 (PDT) Received: from [192.168.0.3] (cpc12-lewi13-2-0-cust138.2-4.cable.virginm.net. [82.22.12.139]) by mx.google.com with ESMTPSA id mc20sm1297415wic.15.2015.05.14.23.14.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 23:14:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_13D9DA84-FF32-471F-8143-13A74C10F135" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Vlad Krasnov In-Reply-To: <8e1f4f150dc248e8b47af7e6c33a5376@ustx2ex-dag1mb4.msg.corp.akamai.com> Date: Fri, 15 May 2015 07:14:26 +0100 Message-Id: <624E2A34-1421-443C-A03C-E86259BCF590@cloudflare.com> References: <20150513193848.6725.71264.idtracker@ietfa.amsl.com> <31102898-FF04-49BB-9DCB-5BBF60E7D26E@cloudflare.com> <8e1f4f150dc248e8b47af7e6c33a5376@ustx2ex-dag1mb4.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Olafur Gudmundsson , "tls@ietf.org" , John Graham-Cumming Subject: Re: [TLS] Fwd: New Version Notification for draft-vkrasnov-tls-jumpstart-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 06:14:32 -0000 --Apple-Mail=_13D9DA84-FF32-471F-8143-13A74C10F135 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The idea is that the server does not have to respond at all. If there is = an oncoming attack, the server can operate in legacy mode and the client = does not need to know. It also does not have to respond to every single request.=20 Moreover the server can choose the amount of history it wants to keep = under normal operation, and to not increase it further, until some are = completed or timed out. Also for ECDHE and regular RSA connection the cost of a ServerHello is = negligible. > On 15 May 2015, at 02:55, Salz, Rich wrote: >=20 > If an adversary just wants to DoS your server, they don=E2=80=99t care = if you respond or not, and can trivially send thousands of clientHello = messages with spoofed IP address. Or am I missing something obvious? = It=E2=80=99s like DNS flooding, but with extra CPU cost, isn=E2=80=99t = it? > =20 > --=20 > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz --Apple-Mail=_13D9DA84-FF32-471F-8143-13A74C10F135 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The idea is that the server does not have to respond at all. = If there is an oncoming attack, the server can operate in legacy mode = and the client does not need to know.
It also does not = have to respond to every single request. 
Moreover = the server can choose the amount of history it wants to keep under = normal operation, and to not increase it further, until some are = completed or timed out.
Also for ECDHE and regular = RSA connection the cost of a ServerHello is negligible.


On = 15 May 2015, at 02:55, Salz, Rich <rsalz@akamai.com> wrote:

If an adversary just wants to DoS your = server, they don=E2=80=99t care if you respond or not, and can trivially = send thousands of clientHello messages with spoofed IP address.  Or = am I missing something obvious?  It=E2=80=99s like DNS flooding, = but with extra CPU cost, isn=E2=80=99t it?
 
-- 
Senior Architect, Akamai Technologies
IM: richsalz@jabber.at Twitter: = RichSalz

= --Apple-Mail=_13D9DA84-FF32-471F-8143-13A74C10F135-- From nobody Thu May 14 23:22:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1D91ACE2A for ; Thu, 14 May 2015 23:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 D-i92Ka3gsvK for ; Thu, 14 May 2015 23:21:59 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 8915C1ACD58 for ; Thu, 14 May 2015 23:21:59 -0700 (PDT) Received: by wguv19 with SMTP id v19so39265346wgu.1 for ; Thu, 14 May 2015 23:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0N9OUc1DYP0bH7/qMJ1+lNPmt/BOf5HFe8pXwPuwq84=; b=Up5i25UY/tHS82NZmnl1mNLuNgBQECzBx+dpVHXySqvowqiZWUYdU1VRVcKftlBM/m LYzF49dU0EeO+5yx1o1LadRHUQLoGCWOKTKX3580IVZZUIEkD0Kp8Slew3K8zgbJfdOW bMG+X+pI3jq/HtHG/0KV0NZ0jDWDGIHZ9LYEo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=0N9OUc1DYP0bH7/qMJ1+lNPmt/BOf5HFe8pXwPuwq84=; b=ilk5UdWoo2cYWP+zvXBG4TkP//ysERGvP3awddWyW99WoZtxSdPFhNGrMucW8Xy7iR wFj1A8vVJyx+di8VAXQLHmzH+ho2ZkLO8nt9gBFxfARQSNKJ4Bc9wPOPTDfCpT9L5cpF sHx1D4uMuPJQiu7vDfQuYZisZ+aMLSplJDKpoXb7gAO+7gD5CxIFn5zI/J45REckLi7Y Z7C4A2q2azQSH38ZSj8wNfdVGHp20fd8rYObOshBG0z36TtpCbUvleBlQB6DScGRCmT6 g45NDdnGNnnnE0jLOzYk66oW5XzJcYhGWadizIGDU+1nRGd+2BYz32sU092hbb7nPa0M inUw== X-Gm-Message-State: ALoCoQnkuY44hOBtm68QWvGP47jYf4QTG4BOZIh7nfe8duxo5YTwn4J5cjn06Xuou6jQMlTTpPJF X-Received: by 10.194.192.166 with SMTP id hh6mr9773107wjc.127.1431670918309; Thu, 14 May 2015 23:21:58 -0700 (PDT) Received: from [192.168.0.3] (cpc12-lewi13-2-0-cust138.2-4.cable.virginm.net. [82.22.12.139]) by mx.google.com with ESMTPSA id df1sm1656813wib.12.2015.05.14.23.21.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 23:21:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Vlad Krasnov In-Reply-To: Date: Fri, 15 May 2015 07:21:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18F08C72-4C23-413E-B002-F0EF0318D3E6@cloudflare.com> References: To: Watson Ladd X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DoS risks from draft-vkrasnov-tls-jumpstart-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 06:22:01 -0000 Hi, For the first part - that is a regular amplification attack, which in = that case has lower amplification factor than many other existing UDP = protocols.=20 I also address this in "Security considerations=E2=80=9D chapter, where = I propose a general technique to mitigate attacks of such type, that may = apply to other UDP protocols as well. For the second - the server chooses how much history to keep, and the = timeout period for initiated handshakes. If the history is full, it will = start ignoring incoming ClientHellos. Under normal operation a typical serve can handle all incoming = connections. Under attack it can easily fallback to legacy operation.=20 Thanks, Vlad > On 15 May 2015, at 03:37, Watson Ladd wrote: >=20 > Dear all, >=20 > I'd like to explain some of the ways in which > draft-vkrasnov-tls-jumpstart may provide opportunity for mischief. The > first, and most obvious, is that responses are considerably larger > than requests, leading to amplification. The second is that each > request creates state that is supposed to be stored on the server, > leading to exhaustion of server resources. There does not appear to be > a cookie mechanism to mitigate this problem. >=20 > For resumed connections these problems are much less serious. It may > be that resumption only is a better fit for this approach to latency > reduction. >=20 > Sincerely, > Watson Ladd >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 15 02:43:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C488D1AD080 for ; Fri, 15 May 2015 02:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 2Bmr5acc9E1g for ; Fri, 15 May 2015 02:43:24 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [67.18.44.28]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459FD1ACDA7 for ; Fri, 15 May 2015 02:43:24 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 44934B90C541C; Fri, 15 May 2015 04:43:23 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 33D5AB90C53FE for ; Fri, 15 May 2015 04:43:23 -0500 (CDT) Received: from [204.42.252.17] (port=52855 helo=[5.5.33.184]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YtC9K-0003w3-RH for tls@ietf.org; Fri, 15 May 2015 04:43:23 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <873831bh3y.fsf@alice.fifthhorseman.net> Date: Fri, 15 May 2015 11:43:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F8DEA05-0BC6-464E-8E6A-BF762484E039@ieca.com> References: <873831bh3y.fsf@alice.fifthhorseman.net> To: IETF TLS Working Group X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 204.42.252.17 X-Exim-ID: 1YtC9K-0003w3-RH X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([5.5.33.184]) [204.42.252.17]:52855 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] IANA questions (was Re: changes to draft-ietf-tls-negotiated-ff-dhe-09) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 09:43:25 -0000 During the review process, IANA regularly verifies that they understand = what they=92re do wrt any IANA assignments noted in the IANA = considerations section. Their questions got us to thinking about the = following two points: 1. Currently the registry in which the FFDHE groups will be added is = named "EC Named Curve Registry.=94 Now that we=92re adding DH groups = into that registry it would be clearer if it were renamed =93Supported = Groups Registry=94. This change does not affect interoperability, it = only impacts the name of the registry. We can also get them to add a = note that indicates this registry was renamed, i.e., =93Renamed from EC = Named Curve Registry=94 so folks can follow along. The registry can be = found here: = http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-pa= rameters-8 2. The =93Extensions Type=94 registry associated with this extension is = =93elliptic_curves=94, see value #10 in the registry, this should/could = also be changed to =93supported_groups=94. The registry can be found = here: = http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype= -values.xhtml#tls-extensiontype-values-1 If you object to these changes please let us know by May 20th. spt On May 12, 2015, at 23:50, Daniel Kahn Gillmor = wrote: > Hi TLS folks-- >=20 > As a result of ongoing feedback, i've made several more minor changes = to > draft-ietf-tls-negotiated-ff-dhe, which are now visible in version 09 = of > that document. >=20 > There were several minor nits addressed, but the following minor = changes > are slightly more than nits: >=20 > * the draft clarifies that the named ffdhe* groups do have a small > subgroup, but that it is easily avoided (as opposed to custom = groups, > in which possible small subgroups are either unknown or expensive to > avoid). =20 >=20 > * slight tuning of some of the RFC 2119 language. >=20 > * explicitly relaxing the old requirement that the Supported Groups > extension needed to be sent only when ECDHE ciphersuites were > offered, which no one appears to have followed anyway >=20 > * Added a new section describing local policy for compatible clients > that are considering accepting custom groups from the server, with > baseline guidance for how to protect users by at least ensuring that > the length of the group is minimally strong (no attempt is made to > enumerate all possible local policy or to claim there is only one > legitimate local policy). >=20 > * encourage bounds checking of the public share against the group > modulus, regardless of whether a named group is used. >=20 > Thanks to all the folks who gave feedback on the draft. >=20 > Regards, >=20 > --dkg >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 15 10:42:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985311A00B5 for ; Fri, 15 May 2015 10:42:34 -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 SoExRWbEtBZo for ; Fri, 15 May 2015 10:42:33 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 4BE5F1A00B0 for ; Fri, 15 May 2015 10:42:33 -0700 (PDT) Received: by ykec202 with SMTP id c202so36277785yke.2 for ; Fri, 15 May 2015 10:42:32 -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=vrWVV4lTQzdngcklBl+nVXqOR+49WB+wuveXXYC6Iaw=; b=kx+MfYrLlJnLgLk/2Mq50KeCPOjjAoTOdvVpERgAAt19TjXDazn2hfOmGoZhjwLjRJ o2TsqmgQtTGyTdkG7AYmzT9SRN09xrpZNZzhXNik6ED0zZ1zwVpPAGjgYFaZjfahAE16 0Xp8UIUa9vhaR7hSpdYa+UhFpQ+AXelyMFrlkn7KpdbAzXIAAQwSso/XBW9IGeXMrhug Byzx6Y5otU635dK0LuwUOlfF7ObeClCALnFWuOKWT6/3vafFOyGPSpjZV3/pOo4MAMcI l97P+M70mOssweKxGN6K3K2qLkyfp4eVlDkKwROMUO8Lxe5yodua25XAgFvRt8rOfyjh 2Gyg== MIME-Version: 1.0 X-Received: by 10.236.20.230 with SMTP id p66mr10689798yhp.181.1431711752682; Fri, 15 May 2015 10:42:32 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 15 May 2015 10:42:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 May 2015 10:42:32 -0700 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DoS risks from draft-vkrasnov-tls-jumpstart-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 17:42:34 -0000 On 14 May 2015 at 19:37, Watson Ladd wrote: > There does not appear to be > a cookie mechanism to mitigate this problem. You are absolutely right about this. DTLS does offer a mechanism like this, and it seems likely that it will become part of TLS 1.3, but attempting to retrofit a performance optimization onto TLS 1.2 without that sort of basic DoS mitigation seems unwise. Maybe DTLS 1.3 will use the padding extension to avoid the amplification attack too. One advantage of the cookie mechanism is that it is optional. You can get the performance benefits when the server isn't stressed and still have a fallback in case of high load. From nobody Fri May 15 10:43:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C971A00C0 for ; Fri, 15 May 2015 10:43:18 -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 nipVLH9MITRO for ; Fri, 15 May 2015 10:43:16 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BD81A00DB for ; Fri, 15 May 2015 10:43:16 -0700 (PDT) Received: by ykep21 with SMTP id p21so36253461yke.3 for ; Fri, 15 May 2015 10:43: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:content-transfer-encoding; bh=rMAQ1d2xk9SxNiFJO++YdeUF7QrO75zkwrGPqwhOpD8=; b=DxgJRRBSIkvK+9movy63XMsXFEWgw+T0IdCHtzLYpQZeC6Mt9EHlY0DrKgRCvBDLdq AiFBYRPLVC1wmrUaiAeq9ZknWQ6RlDU3eUdk6oJyzzITs4WJr460kCKJamuTrnKzUave /7HERKlIt/MtxpBFyHlBjA9Gs01enrUvrh488YKUgjZq98R/D9zB4ofn8MiHYKkhmvOG 5JbYdyJIycUa6/1VS6eOqlJOh1IErryajA81jAP4sVs9WDxeFjdwiT5M8YmkpmrxHpXz 2JZ/lb9jD3NIotUEs3QeZZg3TKQe0Tv+je5nzx73c0cX9mxJNM2uOc2HGNj8KlEvCJTw p7Ag== MIME-Version: 1.0 X-Received: by 10.170.44.208 with SMTP id 199mr11943869ykm.101.1431711795881; Fri, 15 May 2015 10:43:15 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 15 May 2015 10:43:15 -0700 (PDT) In-Reply-To: <6F8DEA05-0BC6-464E-8E6A-BF762484E039@ieca.com> References: <873831bh3y.fsf@alice.fifthhorseman.net> <6F8DEA05-0BC6-464E-8E6A-BF762484E039@ieca.com> Date: Fri, 15 May 2015 10:43:15 -0700 Message-ID: From: Martin Thomson To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] IANA questions (was Re: changes to draft-ietf-tls-negotiated-ff-dhe-09) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 17:43:18 -0000 These are good changes. On 15 May 2015 at 02:43, Sean Turner wrote: > During the review process, IANA regularly verifies that they understand w= hat they=E2=80=99re do wrt any IANA assignments noted in the IANA considera= tions section. Their questions got us to thinking about the following two = points: > > 1. Currently the registry in which the FFDHE groups will be added is name= d "EC Named Curve Registry.=E2=80=9D Now that we=E2=80=99re adding DH grou= ps into that registry it would be clearer if it were renamed =E2=80=9CSuppo= rted Groups Registry=E2=80=9D. This change does not affect interoperabilit= y, it only impacts the name of the registry. We can also get them to add a= note that indicates this registry was renamed, i.e., =E2=80=9CRenamed from= EC Named Curve Registry=E2=80=9D so folks can follow along. The registry c= an be found here: > http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-8 > > 2. The =E2=80=9CExtensions Type=E2=80=9D registry associated with this e= xtension is =E2=80=9Celliptic_curves=E2=80=9D, see value #10 in the registr= y, this should/could also be changed to =E2=80=9Csupported_groups=E2=80=9D.= The registry can be found here: > http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml#tls-extensiontype-values-1 > > If you object to these changes please let us know by May 20th. > > spt > > On May 12, 2015, at 23:50, Daniel Kahn Gillmor wr= ote: > >> Hi TLS folks-- >> >> As a result of ongoing feedback, i've made several more minor changes to >> draft-ietf-tls-negotiated-ff-dhe, which are now visible in version 09 of >> that document. >> >> There were several minor nits addressed, but the following minor changes >> are slightly more than nits: >> >> * the draft clarifies that the named ffdhe* groups do have a small >> subgroup, but that it is easily avoided (as opposed to custom groups, >> in which possible small subgroups are either unknown or expensive to >> avoid). >> >> * slight tuning of some of the RFC 2119 language. >> >> * explicitly relaxing the old requirement that the Supported Groups >> extension needed to be sent only when ECDHE ciphersuites were >> offered, which no one appears to have followed anyway >> >> * Added a new section describing local policy for compatible clients >> that are considering accepting custom groups from the server, with >> baseline guidance for how to protect users by at least ensuring that >> the length of the group is minimally strong (no attempt is made to >> enumerate all possible local policy or to claim there is only one >> legitimate local policy). >> >> * encourage bounds checking of the public share against the group >> modulus, regardless of whether a named group is used. >> >> Thanks to all the folks who gave feedback on the draft. >> >> Regards, >> >> --dkg >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 15 13:09:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E091A1B79 for ; Fri, 15 May 2015 13:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_55=0.6, 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 JcDCqCtC1_E4 for ; Fri, 15 May 2015 13:09:26 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (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 E35B11A1B2C for ; Fri, 15 May 2015 13:09:25 -0700 (PDT) Received: by wguv19 with SMTP id v19so63790654wgu.1 for ; Fri, 15 May 2015 13:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DoBRfREVez9Tph0xPzjPj38F4NnOYBh4eRwyDQqzhOQ=; b=x6bIQXr1RjJBGoLFO8Th2wwBpKG1Gdg6EqwmcFI5eCYgRN5jv55UL+lm7mw7nAAvMY 1o9drbCCwepQ9PrLI7XFxcg8B83vrY/jQJo0BvFdzL4/PEnBen+R40Io1bDfypSXJmXP 0o/zXTR2ByiP6KXmHR40zveZMoWqMoXtNMw2A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=DoBRfREVez9Tph0xPzjPj38F4NnOYBh4eRwyDQqzhOQ=; b=iY04b5eEujbUtWOAP3UuD1S6MLdmydJPe9u1jW+E6q17aBE1ge7ng0sD48ai68w5UD Y8JocSDMJbvwbuP53Zsi/N+sJ65pIQsCefq0XjicNwF4M71rnzpDkFj2JhDfS523gbfX F7w5VP+09SvyNZesRr2LLMXV/JQO3nJ27XB44cIr/EBa5gGF3qgidecjcDPWOI+eEQaC MCldqcUttWbDT18eZGwTUtLnEJ8G57n1KiMWn/XUrCuNccgTghR0eEvJw85bVn5ad2JJ wsYH9IL7ReZqgKkf1ZDtVA972VZ3q24GfZoa3e4+Ai11C+7Lw/3q5RRtztcCZKFalvKV KSRw== X-Gm-Message-State: ALoCoQm+MH0oihsYlW4rs0+UqInKHwV4YrqR3k+quDBxyZwdWUXI6BIwf13/bhZlwkRhASPWuiG/ X-Received: by 10.194.86.101 with SMTP id o5mr22068263wjz.8.1431720564583; Fri, 15 May 2015 13:09:24 -0700 (PDT) Received: from [192.168.0.3] (cpc12-lewi13-2-0-cust138.2-4.cable.virginm.net. [82.22.12.139]) by mx.google.com with ESMTPSA id mc20sm4471171wic.15.2015.05.15.13.09.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 May 2015 13:09:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Vlad Krasnov In-Reply-To: Date: Fri, 15 May 2015 21:09:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82930F97-545D-47AA-AA0E-FECCD45244F1@cloudflare.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DoS risks from draft-vkrasnov-tls-jumpstart-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 20:09:27 -0000 The cookie mechanism is good, but misses the point of this protocol. First of all, cookie generation and validation by itself is not a = computationally free operation. More importantly requesting a cookie = takes a round that we are trying to save. On the other hand a modest 8-core Haswell based server, can perform well = over 300,000 ECDSA+ECDHE ServerHellos per second, that means that a = 10GBit card would be overwhelmed by the incoming ClientHello before the = CPU is. Non forward secrecy handshakes do not require any real = computation on the ServerHello. But the server should not get to the point of taking so many requests. = The idea is that if the server suspects something or is under any kind = of attack or even without any reason at all, does not have to respond = over UDP, and nothing bad happens, the connection continues as usual = over TCP without a hiccup. A normal server would keep a state for say 10,000 - 20,000 handshakes = per second (less than 1MB of data with ECDHE, and well below modern = processor capabilities), and refuse to accept more than that. Of course = larger servers will decide how much they are willing to accept. That = means that while the extension itself can be DoSed, but the legacy = connection will take place as usual over TCP and the client wouldn=E2=80=99= t know. You don=E2=80=99t need a cookie for that at all. The padding can take care of an amplification attack, although the = amplification for a typical certificate chain, is less than 10x. And a = server shall not respond to a client more than once for a given period = of time via UDP. I think that makes the protocol very resilient to = regular amplification attacks, especially compared to protocols like DNS = or SSDP. Most of the time servers are not flooded, and therefore most of the time = connections will be accelerated significantly. > On 15 May 2015, at 18:42, Martin Thomson = wrote: >=20 > On 14 May 2015 at 19:37, Watson Ladd wrote: >> There does not appear to be >> a cookie mechanism to mitigate this problem. >=20 > You are absolutely right about this. DTLS does offer a mechanism like > this, and it seems likely that it will become part of TLS 1.3, but > attempting to retrofit a performance optimization onto TLS 1.2 without > that sort of basic DoS mitigation seems unwise. Maybe DTLS 1.3 will > use the padding extension to avoid the amplification attack too. >=20 > One advantage of the cookie mechanism is that it is optional. You can > get the performance benefits when the server isn't stressed and still > have a fallback in case of high load. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 15 15:27:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECF01A89A7 for ; Fri, 15 May 2015 15:27:48 -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 zKJBQbtNmam0 for ; Fri, 15 May 2015 15:27:47 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056DA1A89A2 for ; Fri, 15 May 2015 15:27:46 -0700 (PDT) Received: by oica37 with SMTP id a37so93241184oic.0 for ; Fri, 15 May 2015 15:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=u42YD9oRrluE4v5ZwDjvGxML0wKdNLc8RmDkyJmC85s=; b=nIv8k9sjvXWl27wK9SnGOg7FzS17SDadnzsXsk65YXVeykQzSQvt9Do0QpcanJD2bL GSYrlwx/PWlWDybF1IH94VdGJgMi44/0xnElX3eNmLGJXG7Awgukazj3DLclj03x9Xfb XuKgSidoqBQ0opQeopJTq4CI7hfYYejSaPv7CgBM5Tpoh4WvO8lw6csZ9K1oLNXDDkFY 60CsWPMscqI/7IUmKfMI3vtcYcwBtWGLMYt3g8T5SAaGwnzUD0B/K2cKmGdPQ56r6xfx jQufYysoaML3BvzLh3httZTpCacInohpDY3/DyHB7fjpCMORTAtk/29N4lQnCiWDsvoO 1dZA== X-Received: by 10.202.49.77 with SMTP id x74mr9771303oix.86.1431728866180; Fri, 15 May 2015 15:27:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.213.206 with HTTP; Fri, 15 May 2015 15:27:25 -0700 (PDT) From: Fabrice Gautier Date: Fri, 15 May 2015 15:27:25 -0700 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] RFC 6961 implementations ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 22:27:48 -0000 Hi, Does anyone knows of existing (or planned) implementations of RFC 6961 (Multiple Certificate Status Request Extension)*, either on the client or server side ? I haven't seen support in the usual suspects... Thanks. (*) https://tools.ietf.org/html/rfc6961 -- Fabrice From nobody Fri May 15 18:51:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280FD1ACE02 for ; Fri, 15 May 2015 18:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 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_NONE=-0.0001] 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 hP-4E7lIx9_q for ; Fri, 15 May 2015 18:51:48 -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 825ED1A9004 for ; Fri, 15 May 2015 18:51:48 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 809B41B4091; Fri, 15 May 2015 18:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=zLm8Fg6StKI9PP08fThFdN36nKU=; b=NI1G33k5QwNqe7v6g 1xwuurOKpvAII+7/gr05p0HKtrranR/XvAABdjk09GILvIJD46pLmZ+Gd+nV7PFP UMcoCbwzKVcnEaOUdBf7CxJC8sOdCvbL6Etm2BNPUI7ilUyxuf9FJEmqxCfNYxAB B6v6L/+WX5wcH24O66yV4e0IQk= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id 2EA9B1B4085; Fri, 15 May 2015 18:51:47 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 15 May 2015 18:51:47 -0700 Message-ID: In-Reply-To: References: Date: Fri, 15 May 2015 18:51:47 -0700 From: "Ryan Sleevi" To: "Fabrice Gautier" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RFC 6961 implementations ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 01:51:49 -0000 On Fri, May 15, 2015 3:27 pm, Fabrice Gautier wrote: > Hi, > > Does anyone knows of existing (or planned) implementations of RFC 6961 > (Multiple Certificate Status Request Extension)*, either on the client > or server side ? > > I haven't seen support in the usual suspects... There aren't any plans for Chromium at this time, nor do I know of any implementations. From nobody Fri May 15 18:56:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBED11ACE2B for ; Fri, 15 May 2015 18:56:54 -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 ra0OsCZJKpK3 for ; Fri, 15 May 2015 18:56:51 -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 184101ACE25 for ; Fri, 15 May 2015 18:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1431741411; x=1463277411; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=rSZzJAePfyowUjZwlllNtjlVZDmtlLvqzebHG4q9mNY=; b=BYPVV2LV7cAJ7vN1+EN7uyRH7un1hk1ENPHWMDDxFqmejsSPmCvi/V+6 VxsTUodNNhVIpEfg9Kl+E4RDPv7cR1DKfUeXUfZQI3VKIPQd9Nmkpejnu KwPhoDjIph3tLNifV2OH9G7q3EVyXAX/M9Z63B966Nds4oWppE8eYjuND 4=; X-IronPort-AV: E=Sophos;i="5.13,437,1427713200"; d="scan'208";a="7293608" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 May 2015 13:56:49 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Sat, 16 May 2015 13:56:49 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] RFC 6961 implementations ? Thread-Index: AdCPe5IAG2KgAMvSRUmvJAh7LuBW2g== Date: Sat, 16 May 2015 01:56:48 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB022161@uxcn10-tdc05.UoA.auckland.ac.nz> 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: [TLS] RFC 6961 implementations ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 01:56:55 -0000 So now I'm curious, why is something that nothing seems to implement and no= -=0A= one really seems to care about a standards-track RFC? Shouldn't it be=0A= experimental?=0A= =0A= Peter.=0A= From nobody Fri May 15 19:54:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0DA1AD1A3 for ; Fri, 15 May 2015 19:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 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_NONE=-0.0001] 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 dDonBGSqnalR for ; Fri, 15 May 2015 19:54:45 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 237111AD1D5 for ; Fri, 15 May 2015 19:54:45 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id DAAD51636; Fri, 15 May 2015 19:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=mq231bJOpxCyM91saumXKhBLWPE=; b=VPAjqSRIhZ/eSbuaR 5MM0BWE+eTK2LPza2w4x4SZXfxTIoH1QXdJIrUvGf8Cpd2I6+He2w4Z2JTAC6xUQ L1D2PG0RBw8g2qhFqFWTYjVFUQfJexyMHAnZbDfMLmb2a+wnEW5y66swmrIQNGdt Iw8pd/KE8FsZExFnngCsg0P23M= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 4A17F161D; Fri, 15 May 2015 19:54:43 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 15 May 2015 19:54:43 -0700 Message-ID: <1320006fb3082b17b2b13f74d273bf28.squirrel@webmail.dreamhost.com> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB022161@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AB022161@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Fri, 15 May 2015 19:54:43 -0700 From: "Ryan Sleevi" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RFC 6961 implementations ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 02:54:46 -0000 On Fri, May 15, 2015 6:56 pm, Peter Gutmann wrote: > So now I'm curious, why is something that nothing seems to implement a= nd > no- > one really seems to care about a standards-track RFC? Shouldn't it be > experimental? To be clear, at the time of the discussions, we were considering it. But the product - and direction - have evolved, and the value, necessity, and tradeoffs of it aren't appropriate for us. That said, I think it still serves a use case and a population, and still think in its isolation, it's a solid approach to the problem it sets out to solve. So I think the rough consensus is still there, even from us. Just not the running code. From nobody Sat May 16 10:46:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9101A8747; Sat, 16 May 2015 10:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5Ip9fuKSRN5; Sat, 16 May 2015 10:46:43 -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 9B18A1A7011; Sat, 16 May 2015 10:46:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7954DBEFD; Sat, 16 May 2015 18:46:41 +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 gp04BKqzcxk3; Sat, 16 May 2015 18:46:39 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.109]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 244F3BEF7; Sat, 16 May 2015 18:46:39 +0100 (IST) Message-ID: <5557827E.7050601@cs.tcd.ie> Date: Sat, 16 May 2015 18:46:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Karthikeyan Bhargavan References: <20150509225248.21800.83581.idtracker@ietfa.amsl.com> <55546240.3010902@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org, draft-ietf-tls-session-hash@ietf.org, The IESG , draft-ietf-tls-session-hash.shepherd@ietf.org, Barry Leiba , draft-ietf-tls-session-hash.ad@ietf.org, tls-chairs@ietf.org Subject: Re: [TLS] Barry Leiba's Discuss on draft-ietf-tls-session-hash-05: (with DISCUSS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 17:46:46 -0000 Hiya, First, I don't think there's much energy for this issue but we should get it sorted and move on. So, how about if we add that this updates 5246 and leave it at that? The meaning there is that anyone who writes a new implementation of 5246 really ought also do this too. I don't think there's any possible harm to adding that and doing so achieves whatever possible good effect there might be from the addition of any "Updates" relationship. If I hear nothing, I'll add an RFC editor note to that effect in a few days and hopefully that'll be sufficient for Barry to clear his discuss. (Barry, if not, please say what would work.) Cheers, S. On 14/05/15 09:58, Karthikeyan Bhargavan wrote: > The session-hash draft has roughly the same impact as RFC5746, which says: > "Updates: 5246, 4366, 4347, 4346, 2246" > > We would be happy to add this list or a subset. > > Other RFCs affected by the current proposal are: rfc5929, rfc5705, rfc5746. > > Should we note these in any way, other than as Informative References? > > Best, > Karthik > > > On 14 May 2015, at 10:52, Stephen Farrell wrote: > >> >> Folks - I note this didn't get an answer. I don't recall that the WG >> considered it, and I'm sure if it had the conclusion could have gone >> either way (and a random choice would have been fine too:-) but can >> you confirm or correct me on that please? If you can do it before the >> telechat today (by ~1400 UTC) that'd be great. >> >> Thanks, >> S. >> >> On 09/05/15 23:52, Barry Leiba wrote: >>> Barry Leiba has entered the following ballot position for >>> draft-ietf-tls-session-hash-05: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> This is a DISCUSS purely because I want to discuss it; whatever the >>> result is, I will be clearing the DISCUSS, and not delaying the document >>> on this point: The last paragraph of Section 4 makes me wonder whether >>> this should "update" 5246. Basically, while this is an extension (which >>> wouldn't normally use "updates"), it's one that you're proposing as >>> standard behavior, and not really as an extension. >>> >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> > From nobody Sat May 16 14:24:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542BA1A8765 for ; Sat, 16 May 2015 14:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 nZpxBiCSeHxd for ; Sat, 16 May 2015 14:24:36 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31741A8761 for ; Sat, 16 May 2015 14:24:36 -0700 (PDT) Received: by iepk2 with SMTP id k2so146333360iep.3 for ; Sat, 16 May 2015 14:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=YwuLgalugehZHrEzgfZKyAATJGIA7RxraNYokWODO/Y=; b=fDeRPERHdZTiazR+P9CnkYHV5eyEGuTrKGxpKmXOtHkSY7C0AfQRwR+irg29o5twPv yUbRKRG3uE2TR3oyPQYfNrvjieOKK07Xlk82NZ+kzTvH4cMlulDUNtg/TAFjlZRPv7tk XkpHOtxDhz+j3fubF5KNFg3FIBPbCnz97rRI7N54Yu3IDfvcw9+vrOKwPMx++tUQGJxV CxF+Z90cKOsooeRgLFN1L93wHirmD7n2dUrIoUo+WnkR9VSTSBCvWt/jG8Etd9Yhj+ld i4++EldZCBRRZEuOO0ccwEJRUDdwAu/N+YIcUjwEhkgRGyr/GOkhI/nqqfTzP1SoiSee IalQ== MIME-Version: 1.0 X-Received: by 10.50.78.100 with SMTP id a4mr6102764igx.34.1431811476049; Sat, 16 May 2015 14:24:36 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Sat, 16 May 2015 14:24:35 -0700 (PDT) Date: Sat, 16 May 2015 17:24:35 -0400 Message-ID: From: Jeffrey Walton To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Status of Cha-Cha/Poly Cipher Suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 21:24:38 -0000 What is the status of cipher suite values for the CHA-CHA/Poly Cipher suites? The Chrome browser is now warning when either AES/GCM or CHA-CHA/Poly Cipher suites are not used. Lack of the cipher suite values is holding up OpenSSL's implementation. [1] If the IETF considers Chrome (26% market share [2]) and Apache/OpenSSL based servers (52% market share [3]), then it appears, then the cipher suite values are long overdue. Assigning the cipher suite values (whether the TLS WG approves of them or not) appear to be consistent with RFC 3935: In attempting to resolve the question of the IETF's scope, perhaps the fairest balance is struck by this formulation: "protocols and practices for which secure and scalable implementations are expected to have wide deployment and interoperation on the Internet, or to form part of the infrastructure of the Internet." The cipher suites already affects millions to billions of users and devices. [1] https://mta.openssl.org/pipermail/openssl-users/2015-March/000866.html [2] https://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=0 [3] http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html From nobody Sat May 16 15:02:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFB61A87A1 for ; Sat, 16 May 2015 15:02: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 9JGSNMUfcXNN for ; Sat, 16 May 2015 15:02:27 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::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 AFF571A879C for ; Sat, 16 May 2015 15:02:26 -0700 (PDT) Received: by wguv19 with SMTP id v19so88212599wgu.1 for ; Sat, 16 May 2015 15:02:25 -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=YAZ1Qup7MVBeiJeInLrQ0DHsSaaeuvvyxLSn5dTZS78=; b=OplDIALldqxJffkBoMv6w4IOD+JrTUtDUiaMrSf8i/bWzKzXdjaSbQOus/N+wN+Ydt 8P/tdMDTzZ+u4Quu2PI5Tt/vvOky4F7fFm5DK8eDkFe7kQWNZWIi471kFQYZtr2Tr2+b gFoaYksDzAk8kEwuMGmGO9UHkofHdNX6r0utmYUlUxc6Zb+oClW6vwSJSbKWhGA0jlQ4 QW8eGN0Ox+amcOGJKJh5SaeIl47zshdXb7fcZ2eHD4EVUXuJU/7QKRCRdiFhO+2ReXhF 7n6YBoOOM240Zq5d0G8IX1zBCj7meTtilpWXLRCRfxmXVqdD8ABuWw4m4hRj+O7maDPB lmWg== X-Received: by 10.180.78.65 with SMTP id z1mr8974233wiw.14.1431813745471; Sat, 16 May 2015 15:02:25 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id di7sm4673455wib.23.2015.05.16.15.02.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 May 2015 15:02:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Sun, 17 May 2015 01:02:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <476C5289-6C8F-4591-BABA-4FD61A895A11@gmail.com> References: To: noloader@gmail.com X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Status of Cha-Cha/Poly Cipher Suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 22:02:28 -0000 Hi, Jeffrey The algorithm document has just been published: https What remains for the TLS working group to do is to adopt a draft for = ChaCha20-Poly1305 in TLS. There already is a candidate: https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05 Once that=E2=80=99s done, the document can both progress and if needed, = people can request early assignment of identifiers. The ciphersuite = registry has a =E2=80=9Cspecification required=E2=80=9D policy. Strictly = speaking, the private draft could be enough - we don=E2=80=99t have to = have an RFC, but practically speaking, this document will only get = assignment after it is adopted by the WG. This is a similar procedure to that followed by the IPsecME working = group, which has just finished WGLC on the IPsec version of this draft. Yoav > On May 17, 2015, at 12:24 AM, Jeffrey Walton = wrote: >=20 > What is the status of cipher suite values for the CHA-CHA/Poly Cipher = suites? >=20 > The Chrome browser is now warning when either AES/GCM or CHA-CHA/Poly > Cipher suites are not used. >=20 > Lack of the cipher suite values is holding up OpenSSL's = implementation. [1] >=20 > If the IETF considers Chrome (26% market share [2]) and Apache/OpenSSL > based servers (52% market share [3]), then it appears, then the cipher > suite values are long overdue. >=20 > Assigning the cipher suite values (whether the TLS WG approves of them > or not) appear to be consistent with RFC 3935: >=20 > In attempting to resolve the question of the IETF's scope, perhaps > the fairest balance is struck by this formulation: "protocols and > practices for which secure and scalable implementations are expected > to have wide deployment and interoperation on the Internet, or to > form part of the infrastructure of the Internet." >=20 > The cipher suites already affects millions to billions of users and = devices. >=20 > [1] = https://mta.openssl.org/pipermail/openssl-users/2015-March/000866.html > [2] = https://www.netmarketshare.com/browser-market-share.aspx?qprid=3D0&qpcusto= md=3D0 > [3] = http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.= html >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat May 16 15:07:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A541A87AB for ; Sat, 16 May 2015 15:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8RvMpNhh4Ar for ; Sat, 16 May 2015 15:07:43 -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 2CB711A87AA for ; Sat, 16 May 2015 15:07:43 -0700 (PDT) Received: by qgew3 with SMTP id w3so26527416qge.2 for ; Sat, 16 May 2015 15:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=wTuGw6vIqHIunK0Ghkgg5UOCjc5P2Rn7a6UU1bHFkTg=; b=J/9In75PoxmPCRsYOsaZjT6OvjP2gYLQyVUw+XwmFJbJdpeegpSfKA1s0Ux/IaS3/9 QztfuRDG+qF3i+VHzDwtb5/39Al5r6imMRAhD28gFAhCG4AUz5FQkoO/nqUKKEnZ6qjM NqWGv/bwJ99ACLqgnMbT/Ut2Jrq7yM0rRFelpFDRL827EASQgoqN1FKd5u/v07wfX/Zy 9Kqu5ORI32mmF4ASIHe5lSv1SfmC4X01AdH+iOAEkdZAmvncBnI5wovT3IE0nrScutKu oqjPUh0/BOsMHvzt35byrZnogbCzFRg7r6dW8nicK8vjSp8/WWhWs1sgdDoQ6LMXj4Yw rasg== X-Received: by 10.140.133.18 with SMTP id 18mr21666640qhf.84.1431814062465; Sat, 16 May 2015 15:07:42 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id f4sm3834907qhe.9.2015.05.16.15.07.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 16 May 2015 15:07:42 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 16 May 2015 18:07:40 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <476C5289-6C8F-4591-BABA-4FD61A895A11@gmail.com> In-Reply-To: <476C5289-6C8F-4591-BABA-4FD61A895A11@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505161807.41038.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Status of Cha-Cha/Poly Cipher Suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 22:07:44 -0000 On Saturday, May 16, 2015 06:02:23 pm Yoav Nir wrote: > The algorithm document has just been published: https https://tools.ietf.org/html/rfc7539 > What remains for the TLS working group to do is to adopt a draft for ChaCha20-Poly1305 in TLS. There already is a candidate: > https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05 From nobody Sat May 16 15:26:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5581A7034 for ; Sat, 16 May 2015 15:25:59 -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 sf3D6bvpw7uO for ; Sat, 16 May 2015 15:25:58 -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 BB3AE1A1BC0 for ; Sat, 16 May 2015 15:25:57 -0700 (PDT) Received: by wizk4 with SMTP id k4so33781608wiz.1 for ; Sat, 16 May 2015 15:25:56 -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=ujFOtrEVnVOHrTScFXsXTk/c0VtbTApjF9FX7iDXhPc=; b=YgDhpe9sGWMhT/1wYlZQTXvoqUDUwIr/3ryVSC6dF3/CgmQZyeknaVtwrhwA1Vc2XB EfZiNePnVGf2Ij1Wn2g4URqJFXj6QtHEKE/Uljsems0PWbuvJOTpc5ccCQZ+SrQD7RO0 KNMtMom1ArwW9wHstlOFhqW5W8Dj+sYj9MmDV8EXqNzw2cIIFsBLE60miigxP6vqkUxV olauRmeK/5RCfkb8DL1xp4vvxnUrfIJXaaGGl/EL2epUhfFlRT6kbnzEAODC1sd8QDML l9wgHOCowhCHXWJgzX9uZ4QAXWWAWck6VJNLL6RemQGGBVPG01jebMMO+gYViqJJpnQW HWwg== X-Received: by 10.180.76.8 with SMTP id g8mr8777235wiw.79.1431815156467; Sat, 16 May 2015 15:25:56 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id i13sm4768734wic.13.2015.05.16.15.25.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 May 2015 15:25:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <201505161807.41038.davemgarrett@gmail.com> Date: Sun, 17 May 2015 01:25:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1E572E86-B7ED-4560-8D0E-6C2B17FF7842@gmail.com> References: <476C5289-6C8F-4591-BABA-4FD61A895A11@gmail.com> <201505161807.41038.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Status of Cha-Cha/Poly Cipher Suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 22:25:59 -0000 Thanks. > On May 17, 2015, at 1:07 AM, Dave Garrett = wrote: >=20 > On Saturday, May 16, 2015 06:02:23 pm Yoav Nir wrote: >> The algorithm document has just been published: https >=20 > https://tools.ietf.org/html/rfc7539 >=20 >> What remains for the TLS working group to do is to adopt a draft for = ChaCha20-Poly1305 in TLS. There already is a candidate: >> https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05 From nobody Sat May 16 16:55:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC301A8858 for ; Sat, 16 May 2015 16:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B15UAdXzR61K for ; Sat, 16 May 2015 16:54:55 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563561A8857 for ; Sat, 16 May 2015 16:54:55 -0700 (PDT) Received: by qcvo8 with SMTP id o8so74265067qcv.0 for ; Sat, 16 May 2015 16:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:message-id; bh=bj5hIE1cHpB2Zr7l/golkKfMgTO0xzubzFdxLJKJ2HM=; b=wdfYGiki4t3xKbPJHkBtSEzPT6yYO38zWPPJXNY2HqpCIoVA3tCnysOWAywUYNWWOx mSKnO+V7UhYbk+e3hdo7qMxQql6ZSOcI1npNhi/Wz0E550W6IUTmuS1vq5WndpJ38eEC K6vqDq75kOnY3NKsTZkjdBPVDe1BXoY/Tw6o3iRrrnfgxRLn1LDPCT5eiKAckPQXx3xe zqi6E8Ds7hZzyYTlyOiutN81FNgaM9eDBS7bQCDzDcWBm1CZMJs6iy/BHC4DYv7JD6X6 pbal7woJy+uCUmAbdfCmaRPOJrP++c3MOryXuuPRqkmPnpzv1+WL6SoZ8mxnesCmCrmU QPbA== X-Received: by 10.55.52.18 with SMTP id b18mr34857422qka.85.1431820494641; Sat, 16 May 2015 16:54:54 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id e18sm3980687qhc.22.2015.05.16.16.54.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 16 May 2015 16:54:53 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Sat, 16 May 2015 19:54:52 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201505161954.52817.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: [TLS] Encrypt content type (#51) + Remove TLSCiphertext.version (#144) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 23:54:57 -0000 Is there enough agreement on list for consensus on: https://github.com/tlswg/tls13-spec/pull/51/files & https://github.com/tlswg/tls13-spec/issues/144 ? This would get us to the point of no AD for AEAD, as noted by Martin Thomson. https://www.ietf.org/mail-archive/web/tls/current/msg15490.html Dave From nobody Sat May 16 17:24:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D168D1A886D for ; Sat, 16 May 2015 17:24:02 -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 1SO2qpUJg1Tr for ; Sat, 16 May 2015 17:24:01 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.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 3EA471A886C for ; Sat, 16 May 2015 17:24:01 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so35507715wic.0 for ; Sat, 16 May 2015 17:24:00 -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:from:date :message-id:subject:to:cc:content-type; bh=ytVmJl0wEJzdy1M6pg0H5l606xbuTT5ul6hZwV7tu/o=; b=MPldCQ9r4EJxjrSxld12FqiTrKI9GlaQ20uz9Nh42TFS+10MyP62dsXjslmR7zs86I ZY2Vm055bAmc4V1fMdT2+tibSKGjFo2FV3K2JkMbWgePsEBppCUTMDyd/XWuWCXu6oyS +9o58ObY/jRR3Pa7mA16k+tuQZXx2/tcLa+axLCrgfVJ1OSqhhLIMnEXfsYIu1dnG33y Du3Iu9I5YlSRNQjoLZe6p0Y8LWBvNLc4Vvl/X+myYJIRiKjbPLKYg1p5qHuyINT+gEOF F4h1BU2AO6V+34gv3t78lORPw4hs5zB/imbxhK3TXTxTMYW+eFD/Nt3ETnC8dj91pZBh SnNA== X-Gm-Message-State: ALoCoQmYvHaeEwnV7oQ6rkDJdL6KMpmZI57ayMW80Fm19Gg9a+nfBGuFLHDIu0wk4GXKKXCdB+hm X-Received: by 10.180.8.98 with SMTP id q2mr5200714wia.53.1431822240004; Sat, 16 May 2015 17:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Sat, 16 May 2015 17:23:19 -0700 (PDT) In-Reply-To: <201505161954.52817.davemgarrett@gmail.com> References: <201505161954.52817.davemgarrett@gmail.com> From: Eric Rescorla Date: Sat, 16 May 2015 17:23:19 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=f46d04426e38ff4e7f05163c176b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypt content type (#51) + Remove TLSCiphertext.version (#144) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 00:24:03 -0000 --f46d04426e38ff4e7f05163c176b Content-Type: text/plain; charset=UTF-8 On Sat, May 16, 2015 at 4:54 PM, Dave Garrett wrote: > Is there enough agreement on list for consensus on: > https://github.com/tlswg/tls13-spec/pull/51/files > & > https://github.com/tlswg/tls13-spec/issues/144 > ? > > This would get us to the point of no AD for AEAD, as noted by Martin > Thomson. > https://www.ietf.org/mail-archive/web/tls/current/msg15490.html No. I believe that the present consensus is to retain the existing version bytes in place but just leave them fixed. -Ekr > > Dave > --f46d04426e38ff4e7f05163c176b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sat, May 16, 2015 at 4:54 PM, Dave Garrett <davemgarrett@gmail.com= > wrote:
Is there enough ag= reement on list for consensus on:
https://github.com/tlswg/tls13-spec/pull/51/files
&
https://github.com/tlswg/tls13-spec/issues/144
?

This would get us to the point of no AD for AEAD, as noted by Martin Thomso= n.
https://www.ietf.org/mail-archive/web/tls/current/msg154= 90.html

No. I believe that the present = consensus is to retain the existing version bytes
in place but ju= st leave them fixed.

-Ekr

<= br>
Dave

--f46d04426e38ff4e7f05163c176b-- From nobody Sat May 16 17:24:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B611A8866 for ; Sat, 16 May 2015 17:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 7iMfKxiHlKCj for ; Sat, 16 May 2015 17:24:52 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6371A8871 for ; Sat, 16 May 2015 17:24:52 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so23857615igb.0 for ; Sat, 16 May 2015 17:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=3DBXetVFmii4X6rSn5B1KrQGXOOxtfZt5tin/e4imGs=; b=E9v4FKS/PZFQsa1xlFA2Pd7ygwTKeCl9rKDUZH86nUuYtMdInfIoCgiwqEdQzlUF/o Zz+ph8ANCoIH7yIyGIngDSNjk5VrETKRgebZ1twrXUMcEgbNKYbOjPnXgS/zsVHtsTyn IWsK+Q7i5jmGocdwio2JNQQmFKtCfUxSE1Rq/lxkUzJY5M8EGSRQaGkLu+APkBLL/piw brNhl/VI9qOejWhdA05/2iskJgOJarh0jIHCi2Ga/t+GTIxSqpJmWH6wQcN5zsIdMmcd yBgb9uUZd1WI7o3NSBkNJj/Zp9V2Ou4rgNqaf+8PXp7FwLpef1ODDaUcEPKg3kAau0L3 50Gg== MIME-Version: 1.0 X-Received: by 10.50.78.100 with SMTP id a4mr6606551igx.34.1431822292227; Sat, 16 May 2015 17:24:52 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Sat, 16 May 2015 17:24:52 -0700 (PDT) Date: Sat, 16 May 2015 20:24:52 -0400 Message-ID: From: Jeffrey Walton To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Why is padding still actively being used? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 00:24:54 -0000 Integrated Encryption Schemes, like ECIES and DHAES, don't pad in the Data Encapsulation Mechanism (DEM) or Key Encapsulation Mechanism (KEM). In the case of a KEM, they fill the parameter to the size of the underlying field, and then use a derivation function to digest it. Removing the padding simplifies the proofs and removes the oracles related to the padding. When possible, why does TLS still pad and backfill with 0's rather than filling to the underlying field size and/or digesting? (And I understand block ciphers need padding, so sometimes padding is required in the IES equivalent of a DEM). From nobody Sat May 16 18:04:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEBA1A889F for ; Sat, 16 May 2015 18:04:33 -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 nbLe3_nHjEiL for ; Sat, 16 May 2015 18:04:31 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C141A88A7 for ; Sat, 16 May 2015 18:04:31 -0700 (PDT) Received: by qgf59 with SMTP id 59so702453qgf.3 for ; Sat, 16 May 2015 18:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=PhQK6U78yHDuvz+aLWEe/WVe3G1FAtxjFfapWHd8VVw=; b=NDdPyjWV0pUP7FVIkSnxupzy5sMCxrzKdxcGeiAPB4B6//s57/6foP11AVrD39VtlM d1/+FsvYgFlvi01c3S00Bwot4dH0xvxCZkUjrnGK5fkhSya7mW4g1c0znafrXmzb7RvJ 0LdI+5pm7VyfCM2pTHQ1iK+FFoxDwaj3DCY8N5AUMIk8NfD93Mms9AKLAd9Suz/zD9Bv TCvN6s38Z62vQUg8/3mVGsi5rnnf+tiQITr7sm9aXgkn3CTNlkCgLc3cXiCfW4zzxmXS thIxlBMCNAnS2JM6w48j+AywYRtl4zUutMzjfdSJiXIEpjpPXUQ9lYkM0t1D7aLas3sG +Bhg== X-Received: by 10.140.30.166 with SMTP id d35mr20788088qgd.85.1431824670615; Sat, 16 May 2015 18:04:30 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id m134sm4073889qhb.30.2015.05.16.18.04.30 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 16 May 2015 18:04:30 -0700 (PDT) From: Dave Garrett To: "tls@ietf.org" Date: Sat, 16 May 2015 21:04:28 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201505161954.52817.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505162104.28920.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Encrypt content type (#51) + Remove TLSCiphertext.version (#144) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 01:04:33 -0000 On Saturday, May 16, 2015 08:23:19 pm Eric Rescorla wrote: > On Sat, May 16, 2015 at 4:54 PM, Dave Garrett > wrote: > > Is there enough agreement on list for consensus on: > > https://github.com/tlswg/tls13-spec/pull/51/files > > & > > https://github.com/tlswg/tls13-spec/issues/144 > > ? > > > > This would get us to the point of no AD for AEAD, as noted by Martin > > Thomson. > > https://www.ietf.org/mail-archive/web/tls/current/msg15490.html > > No. I believe that the present consensus is to retain the existing version > bytes in place but just leave them fixed. To be clear, the proposal would be to drop TLSCiphertext.version, but NOT TLSPlaintext.version. The latter needs to stay in place for compatibility, but the former is after version negotiation and provides no useful info. Just a waste of 2 bytes for every record at that point. The version number is currently in the context string for the certificate verification signatures, and Martin suggested mixing it into the PRF/HKDF info string to make the keying material dependent on the version number. (see quoted mailing list URL) Dave From nobody Sat May 16 20:26:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D2B1A1C02 for ; Sat, 16 May 2015 20:26:58 -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 yewqtzlMw_D7 for ; Sat, 16 May 2015 20:26:56 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.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 6493F1A1BFE for ; Sat, 16 May 2015 20:26:56 -0700 (PDT) Received: by wizk4 with SMTP id k4so37952608wiz.1 for ; Sat, 16 May 2015 20:26:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZFs7DeJrlNcqzJjo9RcJBBB5xBiVXcp9OvkHLu4LF4c=; b=bKxbK1XbMdN6af9OjqduEFgzd57N870i3z04TJSI5ilmx6lJyrWTdzUwnPgIQOVN9u ujsKmn1WW9nwkTBzGMHWeK+vcGrvU4U6ROAEygHSQYgEoZwI+mxNIHGTklc3olxZkJy0 9H+XVxTCL3HOiD2+s8Pm/3RlLkE3jQUqeUAx+LtAhKfNRqCpfrfgpszpnyMoYQMdkJhn 3x3L+eRQYUitDTPJwV5wBE95Q9IUfeWwnup/UAi5ug5ERa5xOTVIDTLV69Px4oOaRwYB R6zWd2tHGaRCK2fN83Tg3H5YnvJw5GI1ljBItIJ3j0EYAMyOYIsputvtiZ1OctEK1+9T ownw== X-Gm-Message-State: ALoCoQkmaKAwMs9BdYT5mBljCpheuYcc6q8Mz39YL0fXgE5g7p9HAJjM/+ttYcJr3FUKxvazrinx X-Received: by 10.194.133.73 with SMTP id pa9mr10865930wjb.148.1431833215175; Sat, 16 May 2015 20:26:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Sat, 16 May 2015 20:26:14 -0700 (PDT) In-Reply-To: <201505162104.28920.davemgarrett@gmail.com> References: <201505161954.52817.davemgarrett@gmail.com> <201505162104.28920.davemgarrett@gmail.com> From: Eric Rescorla Date: Sat, 16 May 2015 20:26:14 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=089e011771a92b216405163ea601 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypt content type (#51) + Remove TLSCiphertext.version (#144) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 03:26:58 -0000 --089e011771a92b216405163ea601 Content-Type: text/plain; charset=UTF-8 The issue is that there are believed to be middleboxes which depend on the length being in the right place. -Ekr On Sat, May 16, 2015 at 6:04 PM, Dave Garrett wrote: > On Saturday, May 16, 2015 08:23:19 pm Eric Rescorla wrote: > > On Sat, May 16, 2015 at 4:54 PM, Dave Garrett > > wrote: > > > Is there enough agreement on list for consensus on: > > > https://github.com/tlswg/tls13-spec/pull/51/files > > > & > > > https://github.com/tlswg/tls13-spec/issues/144 > > > ? > > > > > > This would get us to the point of no AD for AEAD, as noted by Martin > > > Thomson. > > > https://www.ietf.org/mail-archive/web/tls/current/msg15490.html > > > > No. I believe that the present consensus is to retain the existing > version > > bytes in place but just leave them fixed. > > To be clear, the proposal would be to drop TLSCiphertext.version, but NOT > TLSPlaintext.version. The latter needs to stay in place for compatibility, > but the former is after version negotiation and provides no useful info. > Just a > waste of 2 bytes for every record at that point. The version number is > currently in the context string for the certificate verification > signatures, and > Martin suggested mixing it into the PRF/HKDF info string to make the keying > material dependent on the version number. (see quoted mailing list URL) > > > Dave > --089e011771a92b216405163ea601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The issue is that there are believed to be middleboxes whi= ch depend on the length being
in the right place.

<= div>-Ekr


On Sat, May 16, 2015 at 6:04 PM, Dave Garrett <<= a href=3D"mailto:davemgarrett@gmail.com" target=3D"_blank">davemgarrett@gma= il.com> wrote:
On Saturday, May 16, 2015 08:23:19 pm Eric Re= scorla wrote:
> On Sat, May 16, 2015 at 4:54 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > Is there enough agreement on list for consensus on:
> > https://github.com/tlswg/tls13-spec/pull/51/files
> > &
> > https://github.com/tlswg/tls13-spec/issues/144
> > ?
> >
> > This would get us to the point of no AD for AEAD, as noted by Mar= tin
> > Thomson.
> > https://www.ietf.org/mail-archive/web/tls/curr= ent/msg15490.html
>
> No. I believe that the present consensus is to retain the existing ver= sion
> bytes in place but just leave them fixed.

To be clear, the proposal would be to drop TLSCiphertext.versio= n, but NOT
TLSPlaintext.version. The latter needs to stay in place for compatibility,<= br> but the former is after version negotiation and provides no useful info. Ju= st a
waste of 2 bytes for every record at that point. The version number is
currently in the context string for the certificate verification signatures= , and
Martin suggested mixing it into the PRF/HKDF info string to make the keying=
material dependent on the version number. (see quoted mailing list URL)


Dave

--089e011771a92b216405163ea601-- From nobody Sat May 16 22:29:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FAC1A897A for ; Sat, 16 May 2015 22:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 koFQiZuAus8p for ; Sat, 16 May 2015 22:29:39 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F0E1A888F for ; Sat, 16 May 2015 22:29:38 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 8414F817E7; Sun, 17 May 2015 08:29:36 +0300 (EEST) Date: Sun, 17 May 2015 08:29:36 +0300 From: Ilari Liusvaara To: Jeffrey Walton Message-ID: <20150517052936.GA26393@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why is padding still actively being used? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 05:29:42 -0000 On Sat, May 16, 2015 at 08:24:52PM -0400, Jeffrey Walton wrote: > Integrated Encryption Schemes, like ECIES and DHAES, don't pad in the > Data Encapsulation Mechanism (DEM) or Key Encapsulation Mechanism > (KEM). In the case of a KEM, they fill the parameter to the size of > the underlying field, and then use a derivation function to digest it. > > Removing the padding simplifies the proofs and removes the oracles > related to the padding. > > When possible, why does TLS still pad and backfill with 0's rather > than filling to the underlying field size and/or digesting? Are you talking about leading zero stripping in Diffie-Hellman key exchange? I think many bignum libs perform that kind of thing, which is a good source of bugs (especially in big-endian). However, if using dedicated arithmetic (generic bignums are not safe) for fields available in TLS 1.3, that kind of stripping is just extra complexity and source of bugs. Thinking about padding, I think there should be some sort of payload padding under AE, fro those applications that want to hide lengths of messages. In TLS 1.2, it could easily be added as new "compression" mechanism, but those are not supported in TLS 1.3. -Ilari From nobody Sat May 16 22:42:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84341A897E for ; Sat, 16 May 2015 22:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 pKAUDlWRRAt6 for ; Sat, 16 May 2015 22:42:16 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032231A897D for ; Sat, 16 May 2015 22:42:16 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 002279005A; Sun, 17 May 2015 08:42:13 +0300 (EEST) Date: Sun, 17 May 2015 08:42:13 +0300 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20150517054213.GB26393@LK-Perkele-VII> References: <476C5289-6C8F-4591-BABA-4FD61A895A11@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <476C5289-6C8F-4591-BABA-4FD61A895A11@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Status of Cha-Cha/Poly Cipher Suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 05:42:18 -0000 On Sun, May 17, 2015 at 01:02:23AM +0300, Yoav Nir wrote: > Hi, Jeffrey > > The algorithm document has just been published: https > > What remains for the TLS working group to do is to adopt a draft for > ChaCha20-Poly1305 in TLS. There already is a candidate: > https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05 The only comment I have regarding that draft is that it doesn't specify what to stick to record payload. Ciphertext (|P| bytes) || Tag (16 bytes), right? > Once that’s done, the document can both progress and if needed, people > can request early assignment of identifiers. The ciphersuite registry > has a “specification required” policy. Strictly speaking, the private > draft could be enough - we don’t have to have an RFC, but practically > speaking, this document will only get assignment after it is adopted > by the WG. As note, GnuTLS 3.4.x implements (disabled by default) the abovementioned draft, using CSID CCA0-CCA7 (which are noted in the draft). > > On May 17, 2015, at 12:24 AM, Jeffrey Walton wrote: > > > > Lack of the cipher suite values is holding up OpenSSL's implementation. [1] > > > > If the IETF considers Chrome (26% market share [2]) and Apache/OpenSSL > > based servers (52% market share [3]), then it appears, then the cipher > > suite values are long overdue. Also, due to widespread use, the Chrome Chacha CSID CC13-CC15 could be marked as "reserved" (or even given names), preferably with note pointing to draft-agl-tls-chacha20poly1305-04 (there is perecedent for marking CSID as reserved due to existing use). Those are not interoperable with the ones in GnuTLS. -Ilari From nobody Sat May 16 23:29:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E658E1A8997; Sat, 16 May 2015 23:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9UTBWl1lo7p; Sat, 16 May 2015 23:29:45 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B9E1A09CF; Sat, 16 May 2015 23:29:44 -0700 (PDT) Received: by igcau1 with SMTP id au1so26338019igc.1; Sat, 16 May 2015 23:29:44 -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=Ys8ZdDRejM8f1HLVebTGZna8Pd8pdK/7RwYRmmRcFbQ=; b=vdBYVc48GwC3Q3xMVJ/6zg4LUYJkkhjgsG26+InWyaC4T5Mg69Fipka8NIi0pyX4Im alhYXf2sdPR71VvuTW7kkHhnfG/p3Cv+BsbmzWOlJQSfymfqumq6EYFCH+ZBalbTdC5g pvBAmjhUnWqfU54KKx/nvBCl1GPXKM6I0EuMN4Uxxlvhisy/dWEZAhp6XGEWfyeOntkz +mWYWUL247UGnPiLsWdPpqhy9EqdXcjZArE3TvkQyeJ4qEOLetCQq5NU3qCK9YK8Cfep 6SyhZr5P+SLPZ0E3yO26bHCi69BEUgYHo+mCuBFKi7gdgu2KFsM35jIIx57LTSK9LQl4 9mgQ== MIME-Version: 1.0 X-Received: by 10.50.13.67 with SMTP id f3mr7633697igc.12.1431844184417; Sat, 16 May 2015 23:29:44 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Sat, 16 May 2015 23:29:44 -0700 (PDT) In-Reply-To: <5557827E.7050601@cs.tcd.ie> References: <20150509225248.21800.83581.idtracker@ietfa.amsl.com> <55546240.3010902@cs.tcd.ie> <5557827E.7050601@cs.tcd.ie> Date: Sun, 17 May 2015 07:29:44 +0100 X-Google-Sender-Auth: 6uAV0I7w21V0gTs2ckjrBr-VkPc Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0112ccf2fc6de3051641339c Archived-At: Cc: Karthikeyan Bhargavan , "draft-ietf-tls-session-hash@ietf.org" , "tls@ietf.org" , "draft-ietf-tls-session-hash.shepherd@ietf.org" , "tls-chairs@ietf.org" , "draft-ietf-tls-session-hash.ad@ietf.org" , The IESG Subject: Re: [TLS] Barry Leiba's Discuss on draft-ietf-tls-session-hash-05: (with DISCUSS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 06:29:47 -0000 --089e0112ccf2fc6de3051641339c Content-Type: text/plain; charset=ISO-8859-1 That is a perfect answer, and I will clear my discuss now, and let you all do the right thing, whatever you decide that is. Barry On Saturday, May 16, 2015, Stephen Farrell wrote: > > Hiya, > > First, I don't think there's much energy for this issue but we > should get it sorted and move on. > > So, how about if we add that this updates 5246 and leave it at that? > > The meaning there is that anyone who writes a new implementation > of 5246 really ought also do this too. > > I don't think there's any possible harm to adding that and doing > so achieves whatever possible good effect there might be from the > addition of any "Updates" relationship. > > If I hear nothing, I'll add an RFC editor note to that effect in > a few days and hopefully that'll be sufficient for Barry to clear > his discuss. (Barry, if not, please say what would work.) > > Cheers, > S. > > On 14/05/15 09:58, Karthikeyan Bhargavan wrote: > > The session-hash draft has roughly the same impact as RFC5746, which > says: > > "Updates: 5246, 4366, 4347, 4346, 2246" > > > > We would be happy to add this list or a subset. > > > > Other RFCs affected by the current proposal are: rfc5929, rfc5705, > rfc5746. > > > > Should we note these in any way, other than as Informative References? > > > > Best, > > Karthik > > > > > > On 14 May 2015, at 10:52, Stephen Farrell > wrote: > > > >> > >> Folks - I note this didn't get an answer. I don't recall that the WG > >> considered it, and I'm sure if it had the conclusion could have gone > >> either way (and a random choice would have been fine too:-) but can > >> you confirm or correct me on that please? If you can do it before the > >> telechat today (by ~1400 UTC) that'd be great. > >> > >> Thanks, > >> S. > >> > >> On 09/05/15 23:52, Barry Leiba wrote: > >>> Barry Leiba has entered the following ballot position for > >>> draft-ietf-tls-session-hash-05: Discuss > >>> > >>> When responding, please keep the subject line intact and reply to all > >>> email addresses included in the To and CC lines. (Feel free to cut this > >>> introductory paragraph, however.) > >>> > >>> > >>> Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > >>> for more information about IESG DISCUSS and COMMENT positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found here: > >>> https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> This is a DISCUSS purely because I want to discuss it; whatever the > >>> result is, I will be clearing the DISCUSS, and not delaying the > document > >>> on this point: The last paragraph of Section 4 makes me wonder whether > >>> this should "update" 5246. Basically, while this is an extension > (which > >>> wouldn't normally use "updates"), it's one that you're proposing as > >>> standard behavior, and not really as an extension. > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >>> > > > > --089e0112ccf2fc6de3051641339c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is a perfect answer, and I will clear my discuss now, and let you all = do the right thing, whatever you decide that is.

Barry

On Saturday, May 16, 2015, Stephen Farrell <stephen.farrell@cs.tcd.ie> wro= te:

Hiya,

First, I don't think there's much energy for this issue but we
should get it sorted and move on.

So, how about if we add that this updates 5246 and leave it at that?

The meaning there is that anyone who writes a new implementation
of 5246 really ought also do this too.

I don't think there's any possible harm to adding that and doing so achieves whatever possible good effect there might be from the
addition of any "Updates" relationship.

If I hear nothing, I'll add an RFC editor note to that effect in
a few days and hopefully that'll be sufficient for Barry to clear
his discuss. (Barry, if not, please say what would work.)

Cheers,
S.

On 14/05/15 09:58, Karthikeyan Bhargavan wrote:
> The session-hash draft has roughly the same impact as RFC5746, which s= ays:
> "Updates: 5246, 4366, 4347, 4346, 2246"
>
> We would be happy to add this list or a subset.
>
> Other RFCs affected by the current proposal are: rfc5929, rfc5705, rfc= 5746.
>
> Should we note these in any way, other than as Informative References?=
>
> Best,
> Karthik
>
>
> On 14 May 2015, at 10:52, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>>
>> Folks - I note this didn't get an answer. I don't recall t= hat the WG
>> considered it, and I'm sure if it had the conclusion could hav= e gone
>> either way (and a random choice would have been fine too:-) but ca= n
>> you confirm or correct me on that please? If you can do it before = the
>> telechat today (by ~1400 UTC) that'd be great.
>>
>> Thanks,
>> S.
>>
>> On 09/05/15 23:52, Barry Leiba wrote:
>>> Barry Leiba has entered the following ballot position for
>>> draft-ietf-tls-session-hash-05: Discuss
>>>
>>> When responding, please keep the subject line intact and reply= to all
>>> email addresses included in the To and CC lines. (Feel free to= cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to https://www.ietf.org/iesg/stateme= nt/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.=
>>>
>>>
>>> The document, along with other ballot positions, can be found = here:
>>> https://datatracker.ietf.org/doc/draft-ietf-t= ls-session-hash/
>>>
>>>
>>>
>>> --------------------------------------------------------------= --------
>>> DISCUSS:
>>> --------------------------------------------------------------= --------
>>>
>>> This is a DISCUSS purely because I want to discuss it; whateve= r the
>>> result is, I will be clearing the DISCUSS, and not delaying th= e document
>>> on this point:=A0 The last paragraph of Section 4 makes me won= der whether
>>> this should "update" 5246.=A0 Basically, while this = is an extension (which
>>> wouldn't normally use "updates"), it's one t= hat you're proposing as
>>> standard behavior, and not really as an extension.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>

--089e0112ccf2fc6de3051641339c-- From nobody Sat May 16 23:32:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE0E1A89AD; Sat, 16 May 2015 23:32:33 -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 rMaFetof4koC; Sat, 16 May 2015 23:32:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F061A89A8; Sat, 16 May 2015 23:32:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150517063232.27827.1718.idtracker@ietfa.amsl.com> Date: Sat, 16 May 2015 23:32:32 -0700 Archived-At: Cc: draft-ietf-tls-session-hash@ietf.org, tls-chairs@ietf.org, draft-ietf-tls-session-hash.shepherd@ietf.org, draft-ietf-tls-session-hash.ad@ietf.org, tls@ietf.org Subject: [TLS] Barry Leiba's Yes on draft-ietf-tls-session-hash-05: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 06:32:33 -0000 Barry Leiba has entered the following ballot position for draft-ietf-tls-session-hash-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The last paragraph of Section 4 makes me wonder whether this should "update" 5246. Basically, while this is an extension (which wouldn't normally use "updates"), it's one that you're proposing as standard behavior, and not really as an extension. From nobody Sun May 17 06:28:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991D41A92BD for ; Sun, 17 May 2015 06:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 p2P1RXEi9pJR for ; Sun, 17 May 2015 06:28:26 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 C688C1A0173 for ; Sun, 17 May 2015 06:28:25 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so70337497wic.0 for ; Sun, 17 May 2015 06:28:23 -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:from:date :message-id:subject:to:cc:content-type; bh=GBGp+1SDozKld3IsM2pzCCKlRj/EaTESPj71JcmiBUE=; b=CsRO5gCSYE8EJZAl81S0dHazFyshThbI89aeA3FepZEaj0+BvADPhmG2TmRtQvMFAL quF7APiGXPwoOgozud6OvcrNmH/KB1Xp0aoejth4dVPGknDTdlXcvR80B2C96QQp2GYE P/Zumm1QlMhCpk1BPXEWbLCiHhFQ/eggUjI0zO+4j+D5BOPhYWIiVQaMVNmtFwmz/0L1 raY7/IGe/vLz8+PxXFbeZ7JPZvy6o8sy9Z/Jx9zkCuHrON4Z/y1yZemYjzobF8AwKLAk NsD8c9ebARoA8DJsXjWyQHR+yXaGRhEXW8eGTqgCu1iPpPE7apwSFfHHbbmu2X6z2c9v oVSw== X-Gm-Message-State: ALoCoQnK7Ug82eAOxswIvMFXvuOpBzTPFroJ0Y/c6peBfUoT7Wi8ALf1gSqcZuiePqe6CxkK7TOW X-Received: by 10.194.86.101 with SMTP id o5mr36205970wjz.8.1431869303637; Sun, 17 May 2015 06:28:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Sun, 17 May 2015 06:27:43 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 17 May 2015 06:27:43 -0700 Message-ID: To: Joseph Salowey Content-Type: multipart/alternative; boundary=089e0102f352355f530516470d67 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus for AEAD IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 13:28:27 -0000 --089e0102f352355f530516470d67 Content-Type: text/plain; charset=UTF-8 The following PR makes this change: https://github.com/tlswg/tls13-spec/pull/155 Target merge date: 5/20 Note 1: I haven't done anything about changing derivation one way or the other. These are orthogonal issues. Note 2: Should the ChaCha draft adopt this change as well, since it's already incompatible with the encoding TLS 1.2 uses for GCM? -Ekr On Fri, Apr 24, 2015 at 10:10 AM, Joseph Salowey wrote: > The general consensus on the list seems to prefer to derive "IV" and use > it to make the AEAD nonce less predictable. Most folks seemed to be OK with > this approach. In Dallas, there was significant support for using the > derived "IV" as a per session XOR mask for the counter. If you have > objections to this approach please respond on the list by May 1, 2015 . > > Cheers, > > Joe > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e0102f352355f530516470d67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The following PR makes this change:

Target merge date: 5/2= 0


Note 1: I haven't done anythi= ng about changing derivation one way or the
other. These are orth= ogonal issues.

Note 2: Should the ChaCha draft= adopt this change as well, since it's
already incompatible w= ith the encoding TLS 1.2 uses for GCM?

-Ekr
<= div>

On Fri, Apr 24, 2015 at 10:10 AM, Joseph Salowey <<= a href=3D"mailto:joe@salowey.net" target=3D"_blank">joe@salowey.net>= wrote:
The general consensus on the list seems to prefer to d= erive "IV" and use it to make the AEAD nonce less predictable. Mo= st folks seemed to be OK with this approach. =C2=A0 =C2=A0In Dallas, there = was significant support for using the derived "IV" as a per sessi= on XOR mask for the counter.=C2=A0 If you have objections to this approach = please respond on the list by May 1, 2015 .=C2=A0

Cheers,

Joe=C2=A0
=

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--089e0102f352355f530516470d67-- From nobody Sun May 17 06:41:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5AC1AC3C9 for ; Sun, 17 May 2015 06:41: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 OawgfkhJOs37 for ; Sun, 17 May 2015 06:41:49 -0700 (PDT) Received: from mail-wg0-x242.google.com (mail-wg0-x242.google.com [IPv6:2a00:1450:400c:c00::242]) (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 7ABD81AC3C3 for ; Sun, 17 May 2015 06:41:48 -0700 (PDT) Received: by wggy19 with SMTP id y19so13785682wgg.2 for ; Sun, 17 May 2015 06:41:47 -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=a6mr/HWaPmR8Vp4daprTFWOPMOwxbjxahM7GIDJIawk=; b=xWsFjjDLB5rt/U0syg5Fj8oDSrwP+VIKeiFxjujme5GZp8ziu/DDSveD78fmK0gSHS uo0iCswZw4LYrUDZW1n+1mO1Ivnre/KOoNW51FS/THwYI9x85L1ZaXrGAQkMAgDiI4z1 1S30mkr1oZ3wTACjrgei5kXLncrDEd8VW6dERmARxldj8K/KWWKI8OhWXgGEyxb9+AX+ eFV0kolCXQ4Nc2OR40S4Eq/zvOwye8Yog0xRmzwffG6PJW1ecOmeKynZoRvkGxkyOEAJ 3YzRe81aOM0LR8ybc86M8YGWp3/fsdONbBitOQ1Zxfmlh3xQCcu0x+3gVKgn/vZ/2WPq la8g== X-Received: by 10.194.109.97 with SMTP id hr1mr34584766wjb.10.1431870107297; Sun, 17 May 2015 06:41:47 -0700 (PDT) Received: from [172.24.250.138] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id gw7sm7660493wib.15.2015.05.17.06.41.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 May 2015 06:41:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Sun, 17 May 2015 16:41:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus for AEAD IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 13:41:50 -0000 > On May 17, 2015, at 4:27 PM, Eric Rescorla wrote: > Note 2: Should the ChaCha draft adopt this change as well, since it's > already incompatible with the encoding TLS 1.2 uses for GCM? IMO ChaCha should do the same as GCM in TLS 1.2, and do the new thing in = TLS 1.3. ChaCha20-Poly1305 has experimental running code and should be = ready and deployable far earlier than TLS 1.3. =20 IOW ChaCha should do like GCM in both versions. Yoav From nobody Sun May 17 08:50:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589811A0E10 for ; Sun, 17 May 2015 08:50:32 -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_20=-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 VNW1NlsZrvWS for ; Sun, 17 May 2015 08:50:27 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (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 8F1011A0277 for ; Sun, 17 May 2015 08:50:27 -0700 (PDT) Received: by qcvo8 with SMTP id o8so79044903qcv.0 for ; Sun, 17 May 2015 08:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=e0auz+EA0d//zIhd97duE3wt+kzk0bkuWgO3dqCwuxQ=; b=BHsUn6PTWGAOVv2HrLILv5CwQ0QVnR7085jmHwrsYzfRoWG49kjYnEURHZSbqC22ym f+YXzHwUfni90UELUkxdz+Ipv3xepYc4641N2GD+2gKr3kpOE18jaPbKOHYpQHfbvubM Q4hY5fXRqAnyDF9R1aPh95KTqbIkU5w6nZhjVw3lnJjRsSpO35VNHIt6NCQXptPfYeBB 7MwvJ9NVZMoZdn9TRFPZ5y/YNEgq0P2DFAHS86PAC7mxojwrKw4W/Lh+Ii0VwlTi0/IG I91dnbX/82AHu+Tyi37RazvvEXIe5h9vYzye/sU8pzQPiA2dr3JSyktx72IKExVEod5E x+zQ== X-Received: by 10.140.81.39 with SMTP id e36mr24008103qgd.10.1431877826817; Sun, 17 May 2015 08:50:26 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id i106sm5220036qgi.30.2015.05.17.08.50.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 May 2015 08:50:26 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sun, 17 May 2015 11:50:24 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150517052936.GA26393@LK-Perkele-VII> In-Reply-To: <20150517052936.GA26393@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505171150.25191.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Why is padding still actively being used? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 15:50:32 -0000 On Sunday, May 17, 2015 01:29:36 am Ilari Liusvaara wrote: > Thinking about padding, I think there should be some sort of > payload padding under AE, fro those applications that want to hide > lengths of messages. > > In TLS 1.2, it could easily be added as new "compression" mechanism, > but those are not supported in TLS 1.3. We could recycle/rename the "compression" field into "encoding", have existing codepoints for compression reserved and prohibited, and add new codepoints for padding schemes to use. https://www.iana.org/assignments/comp-meth-ids/comp-meth-ids.xhtml#comp-meth-ids-2 This would let endpoints negotiate different padding levels, which might be useful. Dave From nobody Sun May 17 11:33:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87341A0077 for ; Sun, 17 May 2015 11:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, 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 fpsJlxfzkNxu for ; Sun, 17 May 2015 11:33:27 -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 82B9B1A006F for ; Sun, 17 May 2015 11:33:27 -0700 (PDT) Received: by wizk4 with SMTP id k4so52995893wiz.1 for ; Sun, 17 May 2015 11:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nb+veBQdicKo3PD4QZsBsC2GlPkDCOmLrRpfKoFKMu8=; b=pjWnvAAKjDOxCTV3I1lvDI3Ef9I4cpCsAn+YL0+2BNMaC4K75hn68v81z1hd62IBE3 9A7pjCPOInYDgUdl02ww2N9ZGoCvTLIezHGXvb7ruIsmIpXu3Zl2j8D4PwjRi6NmHi1H xnV2fIXXyFhDfCM2muFavKB9nisvBxloPdA24= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nb+veBQdicKo3PD4QZsBsC2GlPkDCOmLrRpfKoFKMu8=; b=D50/qIDpl/STbpUruq48D678nPSAk7+BEjn4AKMjIV+zDYKbpdyfQf//Ob8IBlWf1n Nim8MEoatff3ViVfz+O/F92NulaLiDGP+smqgiuaSgqz/Pgv9u8N+aYbMKlpJdF+8iwU //b0kZQ28uHhiC/yuwb3TrmV7NtZMsagfAIr74spvKwp4N01PkJfTsxF0iPhcha4vykO S53VKaCyjrPuizfrnyWfRPCsldN9mB70Xj33vRwbb1vlz1FX6Y+UGRNJB3HA1q21Q34u z0hU+WTHBJ73ED0+rcMoHyQGxrFRHN+4ZQ1SqqHU2xg7lL7uZcAPE4iLHPsmkj25xkgN Nu3g== X-Gm-Message-State: ALoCoQmaNhG/QJ/L/JVGX5qSKZOW5UxK1oBOy8tx7erdIWe/VCgKh54Z1WK9EfYxEfPNcRfHIs51 X-Received: by 10.180.104.197 with SMTP id gg5mr15563361wib.27.1431887606312; Sun, 17 May 2015 11:33:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.141.80 with HTTP; Sun, 17 May 2015 11:33:05 -0700 (PDT) In-Reply-To: <20150517052936.GA26393@LK-Perkele-VII> References: <20150517052936.GA26393@LK-Perkele-VII> From: Tom Ritter Date: Sun, 17 May 2015 13:33:05 -0500 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why is padding still actively being used? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 18:33:29 -0000 On 17 May 2015 at 00:29, Ilari Liusvaara wrote: > Thinking about padding, I think there should be some sort of > payload padding under AE, fro those applications that want to hide > lengths of messages. https://github.com/tlswg/tls13-spec/pull/147 I believe this had achieved rough consensus in the March interim. -tom From nobody Sun May 17 12:32:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EC91A9086 for ; Sun, 17 May 2015 12:32:36 -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 xXLdEYFeiMMK for ; Sun, 17 May 2015 12:32:33 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::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 7873B1A0334 for ; Sun, 17 May 2015 12:32:33 -0700 (PDT) Received: by qgf59 with SMTP id 59so6391462qgf.3 for ; Sun, 17 May 2015 12:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=i9YZavd2HNqEnY87QSztPDiMtEnxfPCFD5sOFCTc8AU=; b=Z86YqZ+HntXSiyeRsWCmqsznEPnWVUAAyHGmh9vG/8kJA1FvrAeTDQVwKnOPzZq4We 8gXl8Mp9NPcsSSmC5aLDCaND1V14SXwU5ozfRoHeUhCKzNgzRvHaqCAWOYsAeO5WK8jy C1qKE3VpFHNld8J+Hb3f9LuBZcz6F+4YWhW3QJwf7rr7lQtjHCL52cbIUrcDMb/QfYKV GYbgHuM4YtzPCrJF0B1qHxZ72k7ddfVIHvPbZoPLu0ajTKTq0XpLRGsXmL+rXXjjvZTV MF9QKw+KySpoKXTqVrzG/FgP0AzlQVQa1FoMcDK+XGA8yT5XCkf1XLJdDLVm+7mR8f/6 THFA== X-Received: by 10.140.133.199 with SMTP id 190mr3626403qhf.17.1431891152815; Sun, 17 May 2015 12:32:32 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b109sm5552679qga.48.2015.05.17.12.32.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 May 2015 12:32:32 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sun, 17 May 2015 15:32:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150517052936.GA26393@LK-Perkele-VII> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505171532.31109.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Why is padding still actively being used? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 19:32:36 -0000 On Sunday, May 17, 2015 02:33:05 pm Tom Ritter wrote: > On 17 May 2015 at 00:29, Ilari Liusvaara wrote: > > Thinking about padding, I think there should be some sort of > > payload padding under AE, fro those applications that want to hide > > lengths of messages. > > https://github.com/tlswg/tls13-spec/pull/147 > > I believe this had achieved rough consensus in the March interim. Is it really necessary to have a separate application_data_padded content type? It'd be simpler to just keep using existing types but amend it with a padding field and require it always be used at minimum to pad up to the nearest multiple of N-bytes. (something low for the default) Additional padding would be optional, but all data would get some minimum. Dave From nobody Sun May 17 14:30:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5611ACE3A for ; Sun, 17 May 2015 14:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, 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 hLqdvVSe9RXf for ; Sun, 17 May 2015 14:30:13 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 5E7771ACE35 for ; Sun, 17 May 2015 14:30:13 -0700 (PDT) Received: by wgbhc8 with SMTP id hc8so134310346wgb.3 for ; Sun, 17 May 2015 14:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=4+DkW6OYlVK0mk9ww0lFwChDYzeA5RcinKhqNZiJE0o=; b=kOac1aYh/K3fC+Rp/WJDc4s/GjmMQM+hLsRFjg6Y/6QgVFajUbIE+GwHGCEUhcTDd1 tgkjaYEKuBb2mU35wo2cRhGJfOu0SKuIcpJr3POkwKmoudL36r8ai5oUj0GMbXB/H9V0 hwZMW5JlEsIDaNo9Nvd41wCBqf46AMK5U5cL4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=4+DkW6OYlVK0mk9ww0lFwChDYzeA5RcinKhqNZiJE0o=; b=NjKKf/nBrXb+/KA5DO2ut4t2vKTF5tU1RF/foowTzUQYzmgFMqIMyCFaANZAhz1WrM dxPyDo5g063VcDtGOHeFDRFcyuxyTJyv3mG+1WHAIa+ntFq6dTlK9Pm+bK8Nyv9ZC9h7 N2qhdwVzBbMYy5szy8azoM7vrwwLNB4uZQk3g9RgfR7r/W2DKr2Q1zhiUO6ZZZyCDynY zkizU1oPSE0BEdTWx5HAxlnQUzcTsZwYDB/1NvLrRB/Hn257inBinEZacOgoK3Qxzkg0 o7HqPu2MW2L4SWkTE898zMvtLq+tCB7N4uZHAZaPSPIzvK3zi8pmw0EAswFqpO5645Yy nCog== X-Gm-Message-State: ALoCoQkP6b/WWbkjN1fgHsCMBBvbVk2ABRJ4p4ENabowMpksL/7SoWYJLp42z2N0fahHSV2jiQGZ X-Received: by 10.194.71.51 with SMTP id r19mr26114807wju.74.1431898212113; Sun, 17 May 2015 14:30:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.141.80 with HTTP; Sun, 17 May 2015 14:29:51 -0700 (PDT) In-Reply-To: <201505171532.31109.davemgarrett@gmail.com> References: <20150517052936.GA26393@LK-Perkele-VII> <201505171532.31109.davemgarrett@gmail.com> From: Tom Ritter Date: Sun, 17 May 2015 16:29:51 -0500 Message-ID: To: Dave Garrett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why is padding still actively being used? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 21:30:14 -0000 On 17 May 2015 at 14:32, Dave Garrett wrote: > Is it really necessary to have a separate application_data_padded content= type? It'd be simpler to just keep using existing types but amend it with = a padding field and require it always be used at minimum to pad up to the n= earest multiple of N-bytes. (something low for the default) Additional padd= ing would be optional, but all data would get some minimum. That was the first proposal, but the extra bytes on every message for people who weren't using padding were deemed to be prohibitive. -tom From nobody Mon May 18 01:15:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3399E1A87A2 for ; Mon, 18 May 2015 01:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYGwPiZ2gr3a for ; Mon, 18 May 2015 01:15:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79AC1A87A7 for ; Mon, 18 May 2015 01:15:09 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 007028EB3E; Mon, 18 May 2015 08:15:08 +0000 (UTC) Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4I8F44g008295 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 18 May 2015 04:15:06 -0400 Message-ID: <1431936904.2880.0.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Yoav Nir Date: Mon, 18 May 2015 10:15:04 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus for AEAD IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 08:15:11 -0000 On Sun, 2015-05-17 at 16:41 +0300, Yoav Nir wrote: > > On May 17, 2015, at 4:27 PM, Eric Rescorla wrote: > > > > > Note 2: Should the ChaCha draft adopt this change as well, since it's > > already incompatible with the encoding TLS 1.2 uses for GCM? > > IMO ChaCha should do the same as GCM in TLS 1.2, and do the new thing in TLS 1.3. ChaCha20-Poly1305 has experimental running code and should be ready and deployable far earlier than TLS 1.3. > IOW ChaCha should do like GCM in both versions. I concur with that. It makes a very complex protocol otherwise. From nobody Mon May 18 01:20:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9561A87A2 for ; Mon, 18 May 2015 01:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SouXSpQK-8wP for ; Mon, 18 May 2015 01:19:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 D0C671A87BA for ; Mon, 18 May 2015 01:19:58 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4I8JlTx027905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 18 May 2015 04:19:47 -0400 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4I8JiKp016845 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 18 May 2015 04:19:46 -0400 Message-ID: <1431937184.2880.5.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Ilari Liusvaara Date: Mon, 18 May 2015 10:19:44 +0200 In-Reply-To: <20150517054213.GB26393@LK-Perkele-VII> References: <476C5289-6C8F-4591-BABA-4FD61A895A11@gmail.com> <20150517054213.GB26393@LK-Perkele-VII> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Status of Cha-Cha/Poly Cipher Suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 08:20:00 -0000 On Sun, 2015-05-17 at 08:42 +0300, Ilari Liusvaara wrote: > On Sun, May 17, 2015 at 01:02:23AM +0300, Yoav Nir wrote: > > Hi, Jeffrey > > What remains for the TLS working group to do is to adopt a draft for > > ChaCha20-Poly1305 in TLS. There already is a candidate: > > https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05 > > The only comment I have regarding that draft is that it doesn't specify > what to stick to record payload. Ciphertext (|P| bytes) || Tag (16 bytes), > right? Hi, I believed that the output format was explicit in rfc7539, but I was wrong. I've clarified that point and hopefully that will be included in the next draft update. > > Once that’s done, the document can both progress and if needed, people > > can request early assignment of identifiers. The ciphersuite registry > > has a “specification required” policy. Strictly speaking, the private > > draft could be enough - we don’t have to have an RFC, but practically > > speaking, this document will only get assignment after it is adopted > > by the WG. > As note, GnuTLS 3.4.x implements (disabled by default) the abovementioned > draft, using CSID CCA0-CCA7 (which are noted in the draft). Indeed, we've added new code points to allow interoperability testing. regards, Nikos From nobody Mon May 18 03:37:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AB61A8895 for ; Mon, 18 May 2015 03:36:59 -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 6u9Vth9mH6-z for ; Mon, 18 May 2015 03:36:58 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::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 CBFAC1A8858 for ; Mon, 18 May 2015 03:36:57 -0700 (PDT) Received: by wgjc11 with SMTP id c11so21360581wgj.0 for ; Mon, 18 May 2015 03:36:56 -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=hpPaWyHnuntsuWQAmkmxQeQHj6okGRt7VYaKB+xBUx8=; b=SfwfUqNvgp0HSVKDpv/ZudZ5jJe2dVdO1EjHMTNxqTfDZHENUMnp2HhQcUfJgbLbgM 4S5q2OScBFxscq0/NZ+lI/Fqa04v1i4vC1rnDL27kOyevDlnLhd9yYJwoJKdMAcfBACw n+EudbmX8SICCYBIJtKrRkBnhX0mQfZlOE2lKbue0Uely1qhWr7RTIwswWx1wWLTPrOk vic+gOemXGzk5UbR8smMx97szmEmv1YVUybNEThq41AghM1mOSKwH0f979FmSFOV9Rcf aNp9CIznumBuoYgvddUd9FZLTW2m2i1tCKs1QET0weVgU2td35f3gHWEXypkvAZ5HAnS gx2Q== X-Received: by 10.180.76.8 with SMTP id g8mr20376533wiw.79.1431945416564; Mon, 18 May 2015 03:36:56 -0700 (PDT) Received: from [172.24.250.138] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id xy5sm16234335wjc.35.2015.05.18.03.36.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 May 2015 03:36:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <1431937184.2880.5.camel@redhat.com> Date: Mon, 18 May 2015 13:36:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9072027B-A48B-460A-8B52-8DC364690B98@gmail.com> References: <476C5289-6C8F-4591-BABA-4FD61A895A11@gmail.com> <20150517054213.GB26393@LK-Perkele-VII> <1431937184.2880.5.camel@redhat.com> To: "tls@ietf.org" X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [TLS] Status of Cha-Cha/Poly Cipher Suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 10:36:59 -0000 > On May 18, 2015, at 11:19 AM, Nikos Mavrogiannopoulos = wrote: >=20 > On Sun, 2015-05-17 at 08:42 +0300, Ilari Liusvaara wrote: >> On Sun, May 17, 2015 at 01:02:23AM +0300, Yoav Nir wrote: >>> Hi, Jeffrey >>> What remains for the TLS working group to do is to adopt a draft for >>> ChaCha20-Poly1305 in TLS. There already is a candidate: >>> https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05 >>=20 >> The only comment I have regarding that draft is that it doesn't = specify >> what to stick to record payload. Ciphertext (|P| bytes) || Tag (16 = bytes), >> right? >=20 > Hi, > I believed that the output format was explicit in rfc7539, but I was > wrong. I've clarified that point and hopefully that will be included = in > the next draft update. >=20 >>> Once that=E2=80=99s done, the document can both progress and if = needed, people >>> can request early assignment of identifiers. The ciphersuite = registry >>> has a =E2=80=9Cspecification required=E2=80=9D policy. Strictly = speaking, the private >>> draft could be enough - we don=E2=80=99t have to have an RFC, but = practically >>> speaking, this document will only get assignment after it is adopted >>> by the WG. >> As note, GnuTLS 3.4.x implements (disabled by default) the = abovementioned >> draft, using CSID CCA0-CCA7 (which are noted in the draft). >=20 > Indeed, we've added new code points to allow interoperability testing. So what=E2=80=99s stopping the chairs from polling the group for = adoption? Chairs? Yoav= From nobody Mon May 18 07:29:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EC61A906C for ; Mon, 18 May 2015 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, 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 A5_76hPr7wXd for ; Mon, 18 May 2015 07:29:30 -0700 (PDT) Received: from gateway21.websitewelcome.com (gateway21.websitewelcome.com [192.185.46.113]) (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 88AF71A9008 for ; Mon, 18 May 2015 07:29:30 -0700 (PDT) Received: by gateway21.websitewelcome.com (Postfix, from userid 500) id D849AC4E0E87; Mon, 18 May 2015 09:29:29 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway21.websitewelcome.com (Postfix) with ESMTP id C5542C4E0E62 for ; Mon, 18 May 2015 09:29:29 -0500 (CDT) Received: from [173.73.121.66] (port=57813 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YuM2q-0006Ps-WE; Mon, 18 May 2015 09:29:29 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <9072027B-A48B-460A-8B52-8DC364690B98@gmail.com> Date: Mon, 18 May 2015 10:29:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <476C5289-6C8F-4591-BABA-4FD61A895A11@gmail.com> <20150517054213.GB26393@LK-Perkele-VII> <1431937184.2880.5.camel@redhat.com> <9072027B-A48B-460A-8B52-8DC364690B98@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.66 X-Exim-ID: 1YuM2q-0006Ps-WE X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [173.73.121.66]:57813 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Status of Cha-Cha/Poly Cipher Suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 14:29:31 -0000 On May 18, 2015, at 06:36, Yoav Nir wrote: >=20 >> On May 18, 2015, at 11:19 AM, Nikos Mavrogiannopoulos = wrote: >>=20 >> On Sun, 2015-05-17 at 08:42 +0300, Ilari Liusvaara wrote: >>> On Sun, May 17, 2015 at 01:02:23AM +0300, Yoav Nir wrote: >>>> Hi, Jeffrey >>>> What remains for the TLS working group to do is to adopt a draft = for >>>> ChaCha20-Poly1305 in TLS. There already is a candidate: >>>> https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05 >>>=20 >>> The only comment I have regarding that draft is that it doesn't = specify >>> what to stick to record payload. Ciphertext (|P| bytes) || Tag (16 = bytes), >>> right? >>=20 >> Hi, >> I believed that the output format was explicit in rfc7539, but I was >> wrong. I've clarified that point and hopefully that will be included = in >> the next draft update. >>=20 >>>> Once that=92s done, the document can both progress and if needed, = people >>>> can request early assignment of identifiers. The ciphersuite = registry >>>> has a =93specification required=94 policy. Strictly speaking, the = private >>>> draft could be enough - we don=92t have to have an RFC, but = practically >>>> speaking, this document will only get assignment after it is = adopted >>>> by the WG. >>> As note, GnuTLS 3.4.x implements (disabled by default) the = abovementioned >>> draft, using CSID CCA0-CCA7 (which are noted in the draft). >>=20 >> Indeed, we've added new code points to allow interoperability = testing. >=20 > So what=92s stopping the chairs from polling the group for adoption? >=20 > Chairs? >=20 > Yoav Let=92s just say it=92s coming in the not to distant future. spt From nobody Mon May 18 08:56:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A981AC41A; Mon, 18 May 2015 08:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 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_NONE=-0.0001] 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 N9hpjNn821JD; Mon, 18 May 2015 08:56:30 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 80C3B1AC3FE; Mon, 18 May 2015 08:56:29 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 2CECA778090; Mon, 18 May 2015 08:56:29 -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=BrbX3lRptpDfL9 QGV1hWmmDodic=; b=iJMboh6bBro422MxuTxW5DHrLs3QI61/NIK952brI6Aj0f 4Qxrt4UNEEOwX6FyjtiB55Q7lXUhPR6Dse8nG4QfiViU7LUgB2q3y9EoReEuJYdS VsMtDmIyGTVy3qhe3VxEC6TCjZyB5zVsestVYWfk+7EuJ4muOgHQ1DpR561og= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPA id E93F0778088; Mon, 18 May 2015 08:56:27 -0700 (PDT) Date: Mon, 18 May 2015 10:56:25 -0500 From: Nico Williams To: Karthikeyan Bhargavan Message-ID: <20150518155624.GK7287@localhost> References: <20150509225248.21800.83581.idtracker@ietfa.amsl.com> <55546240.3010902@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: tls-chairs@ietf.org, The IESG , draft-ietf-tls-session-hash.shepherd@ietf.org, draft-ietf-tls-session-hash.ad@ietf.org, Barry Leiba , draft-ietf-tls-session-hash@ietf.org, tls@ietf.org Subject: Re: [TLS] Barry Leiba's Discuss on draft-ietf-tls-session-hash-05: (with DISCUSS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 15:56:31 -0000 On Thu, May 14, 2015 at 10:58:14AM +0200, Karthikeyan Bhargavan wrote: > The session-hash draft has roughly the same impact as RFC5746, which says: > "Updates: 5246, 4366, 4347, 4346, 2246" +1 to updating RFC5246 and related. > We would be happy to add this list or a subset. > > Other RFCs affected by the current proposal are: rfc5929, rfc5705, rfc5746. > > Should we note these in any way, other than as Informative References? RFC5929 is affected in this way: by the effective addition of a security consideration when used without the session hash extension. So yes, RFC5929 should be updated even though its channel binding definitions won't change. Nico -- From nobody Mon May 18 09:53:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBAA1AD1DB for ; Mon, 18 May 2015 09:52:59 -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 aZu1lQtolhFQ for ; Mon, 18 May 2015 09:52:57 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::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 5B9021A1BE6 for ; Mon, 18 May 2015 09:52:57 -0700 (PDT) Received: by wgfl8 with SMTP id l8so43613165wgf.2 for ; Mon, 18 May 2015 09:52:56 -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=cQ4Y2OyB6tGff0kqg+d40170BQHNu8kLCmf12rihZLo=; b=O0ppgWbQaPawlj9D5nCkhE+oiMBd02GmboYYKKqDxSQZcvFrEVxqOeOhogEeP9ynDz BRSLaMKzMzsl4itsy+Uk1KF07ygF3DmjKA4yrqzN2wsuEHZic88pLZ0dvGQyY+rWRtI8 mIL4klb7hgWEODVSpOZeZCmo7vgQNz+dNfuZdcc/5OaCjz5K/HJYwsBoEQft4MS5d4vc sV0vQaAbMrNOxoKmlc1jQgIptBRo2OVT2LXbhJWOOV0AZdvlcKMJJmRqy3kfqdrGQJQU UewcGdWpMLWl9iuDlx2nzhqDdKgb0eL7qRsk2nt5iYILLg/kM0zsEq8KflDg9cRd707E SEIw== MIME-Version: 1.0 X-Received: by 10.194.172.130 with SMTP id bc2mr34834799wjc.85.1431967976078; Mon, 18 May 2015 09:52:56 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Mon, 18 May 2015 09:52:55 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Mon, 18 May 2015 09:52:55 -0700 (PDT) In-Reply-To: References: <476C5289-6C8F-4591-BABA-4FD61A895A11@gmail.com> <20150517054213.GB26393@LK-Perkele-VII> <1431937184.2880.5.camel@redhat.com> <9072027B-A48B-460A-8B52-8DC364690B98@gmail.com> Date: Mon, 18 May 2015 09:52:55 -0700 Message-ID: From: Watson Ladd To: Sean Turner Content-Type: multipart/alternative; boundary=089e013c63428b455105165e06e4 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Status of Cha-Cha/Poly Cipher Suites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:52:59 -0000 --089e013c63428b455105165e06e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, May 18, 2015 at 7:29 AM, Sean Turner wrote: > On May 18, 2015, at 06:36, Yoav Nir wrote: > >> >>> On May 18, 2015, at 11:19 AM, Nikos Mavrogiannopoulos wrote: >>> >>> On Sun, 2015-05-17 at 08:42 +0300, Ilari Liusvaara wrote: >>>> On Sun, May 17, 2015 at 01:02:23AM +0300, Yoav Nir wrote: >>>>> Hi, Jeffrey >>>>> What remains for the TLS working group to do is to adopt a draft for >>>>> ChaCha20-Poly1305 in TLS. There already is a candidate: >>>>> https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05 >>>> >>>> The only comment I have regarding that draft is that it doesn't specif= y >>>> what to stick to record payload. Ciphertext (|P| bytes) || Tag (16 bytes), >>>> right? >>> >>> Hi, >>> I believed that the output format was explicit in rfc7539, but I was >>> wrong. I've clarified that point and hopefully that will be included in >>> the next draft update. >>> >>>>> Once that=E2=80=99s done, the document can both progress and if neede= d, people >>>>> can request early assignment of identifiers. The ciphersuite registry >>>>> has a =E2=80=9Cspecification required=E2=80=9D policy. Strictly speak= ing, the private >>>>> draft could be enough - we don=E2=80=99t have to have an RFC, but pra= ctically >>>>> speaking, this document will only get assignment after it is adopted >>>>> by the WG. >>>> As note, GnuTLS 3.4.x implements (disabled by default) the abovementioned >>>> draft, using CSID CCA0-CCA7 (which are noted in the draft). >>> >>> Indeed, we've added new code points to allow interoperability testing. >> >> So what=E2=80=99s stopping the chairs from polling the group for adoptio= n? >> >> Chairs? >> >> Yoav > > Let=E2=80=99s just say it=E2=80=99s coming in the not to distant future. To quote John von Neumann: "If you say why not tomorrow, I say why not today? If you say today at 5 o'clock, I say why not one o'clock?" > > spt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --089e013c63428b455105165e06e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, May 18, 2015 at 7:29 AM, Sean Turner <turners@ieca.com> wrote:
> On May 18, 2015, at 06:36, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
>>
>>> On May 18, 2015, at 11:19 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>>>
>>> On Sun, 2015-05-17 at 08:42 +0300, Ilari Liusvaara wrote:
>>>> On Sun, May 17, 2015 at 01:02:23AM +0300, Yoav Nir wrote:<= br> >>>>> Hi, Jeffrey
>>>>> What remains for the TLS working group to do is to ado= pt a draft for
>>>>> ChaCha20-Poly1305 in TLS. There already is a candidate= :
>>>>> https://tools.ietf.org/html/draft-mavrogiannopoulos= -chacha-tls-05
>>>>
>>>> The only comment I have regarding that draft is that it do= esn't specify
>>>> what to stick to record payload. Ciphertext (|P| bytes) ||= Tag (16 bytes),
>>>> right?
>>>
>>> Hi,
>>> I believed that the output format was explicit in rfc7539, but= I was
>>> wrong. I've clarified that point and hopefully that will b= e included in
>>> the next draft update.
>>>
>>>>> Once that=E2=80=99s done, the document can both progre= ss and if needed, people
>>>>> can request early assignment of identifiers. The ciphe= rsuite registry
>>>>> has a =E2=80=9Cspecification required=E2=80=9D policy.= Strictly speaking, the private
>>>>> draft could be enough - we don=E2=80=99t have to have = an RFC, but practically
>>>>> speaking, this document will only get assignment after= it is adopted
>>>>> by the WG.
>>>> As note, GnuTLS 3.4.x implements (disabled by default) the= abovementioned
>>>> draft, using CSID CCA0-CCA7 (which are noted in the draft)= .
>>>
>>> Indeed, we've added new code points to allow interoperabil= ity testing.
>>
>> So what=E2=80=99s stopping the chairs from polling the group for a= doption?
>>
>> Chairs?
>>
>> Yoav
>
> Let=E2=80=99s just say it=E2=80=99s coming in the not to distant futur= e.

To quote John von Neumann: "If you say why not tomorrow= , I say why not today? If you say today at 5 o'clock, I say why not one= o'clock?"

>
> spt
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

--089e013c63428b455105165e06e4-- From nobody Mon May 18 16:00:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5D31ACDFE for ; Mon, 18 May 2015 16:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 dCbqtWht_I3T for ; Mon, 18 May 2015 16:00:13 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 5563E1ACDFD for ; Mon, 18 May 2015 16:00:13 -0700 (PDT) Received: by qkgx75 with SMTP id x75so119750888qkg.1 for ; Mon, 18 May 2015 16:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=LP2zp15JX1D6yLwn1m3mysfCOeNAIBqTXh8T886VzYs=; b=eyiJmhe+RiEPIsQwH9gqMur7VJFfFp2Gkk6LpSXYSuDU3Zjyz6s0CPxjPA3jVuCVtG T6Ps/pHfp02s3Nb5GtPU0TnQpz0kkkwYkVWCZrzSeJHhVrCpY+ad+v9IVHG9yX8iwzbY Gz5tbRShx0ZJeY7xRY5JZ0CuCZV4eTbb/K44N/ISLKlLISPFFuldbaXGwHW8ZrpVbhGV Yh+PGBZ7tqIPO86+jFnufOskgMQpwaqrQfwgpwq/3gZ+6il4hikcjKH68nv8Sjeq8D2S fS9d1mDaAcrAt18Y82pJamfLyM8zK0azoUuXshobsycfUMCV76JqSD6cHgR9xybjVY4b 5ETA== X-Received: by 10.140.145.85 with SMTP id 82mr33811952qhr.32.1431990012519; Mon, 18 May 2015 16:00:12 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 139sm7884238qhb.26.2015.05.18.16.00.11 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 May 2015 16:00:11 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 18 May 2015 19:00:09 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201505181900.10185.davemgarrett@gmail.com> Archived-At: Subject: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 23:00:15 -0000 https://github.com/tlswg/tls13-spec/pull/169/files Of note, see also: https://www.ietf.org/mail-archive/web/tls/current/msg16238.html The discussion on this list got quite long and at least one person changed their opinion on the topic. I'd like to figure out where we stand on this now. The primary people advocating for this are myself and Ryan Sleevi. The primary person advocating against this is Martin Rex. Who else is in favor or against, at the moment? Regardless of your opinion, is there anything else that needs to be added to the changeset? (If you think this is problematic, what needs to be added to reduce that?) Also, the topic of AIA cert fetching came up, with people both arguing for and against. Personally, I don't think cert chain verification should be triggering any network activity unless explicitly approved beforehand. Do we need to add a note of some kind with regard to this topic? Could we make OCSP stapling a requirement in some way to at least address that? In an ideal world, I'd prefer either the server sends 100% of what's needed to verify, or the handshake should fail. (this is beginning to get off-topic from the main issue, though) Don't interpret this as a full vote or consensus call just yet. I'm just trying to assess what needs to be discussed to move forward on the topic in some way. Dave From nobody Mon May 18 16:49:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E811B2B71 for ; Mon, 18 May 2015 16:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0rWggtN-lSfv for ; Mon, 18 May 2015 16:48:58 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBA21B2B70 for ; Mon, 18 May 2015 16:48:58 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 94BC333D08B; Mon, 18 May 2015 23:48:55 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Dave Garrett References: <201505181900.10185.davemgarrett@gmail.com> From: Geoffrey Keating Date: 18 May 2015 16:48:55 -0700 In-Reply-To: <201505181900.10185.davemgarrett@gmail.com> Message-ID: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 23:49:00 -0000 Dave Garrett writes: > https://github.com/tlswg/tls13-spec/pull/169/files > > Of note, see also: > https://www.ietf.org/mail-archive/web/tls/current/msg16238.html > > The discussion on this list got quite long and at least one person changed their opinion on the topic. I'd like to figure out where we stand on this now. > > The primary people advocating for this are myself and Ryan Sleevi. > The primary person advocating against this is Martin Rex. > > Who else is in favor or against, at the moment? I am for it, as it documents existing practice. > Also, the topic of AIA cert fetching came up, with people both > arguing for and against. I believe this is out of scope for TLS; it is not a transport layer issue. We should therefore not discuss it in the TLS RFC. There's already discussion of some security impacts of AIA in RFC 5280, but not this particular issue; I think that would be a good place to mention the issue. From nobody Tue May 19 05:11:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EEE1A872F for ; Tue, 19 May 2015 05:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYLAmxHpp5dN for ; Tue, 19 May 2015 05:11:16 -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 6847F1A88D0 for ; Tue, 19 May 2015 05:11: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=1432037469; x=1463573469; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+ZhcZPEmz49zR0WYzh7/YhMObytVkoG6T7ot7br9fB4=; b=xFTAB1OTnm+gdY9TJ+uuJJbx9ShgBJ9ydyX/2UGpqbab1dNkQif5z5lR yyTOZAbQ3EqiWAK3tMJemE2FVMoJzF9FM8SJu2TGOfa4IVUiMxZLtEhyk ZSNsCJuSR69ZZEUITyJImW6Q4R4EtyhmEb90OT+i+bdzvwahmVb6DcVOr zHznJNxtSGpFQHJSfKtvjt+U1Iv8trfhmcCi968NN9UJ5YePB0KGopQ15 1cXzTV5e/3/L26a6OllaxWslUAc4SVlWbIUxaYFpakS9wSAVmEvexWZPz NyIHLt/O2ape4cqKFM4JLtAWIxu1CxGS89ndQMgei9hLv/9g7BMV47bCS w==; X-IronPort-AV: E=Sophos;i="5.13,457,1427713200"; d="scan'208";a="16882793" 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; 20 May 2015 00:11:07 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 20 May 2015 00:11:07 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi Thread-Index: AdCSLOLGJVnE1j84SD6Bm7bXqoznGw== Date: Tue, 19 May 2015 12:11:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB02512C@uxcn10-tdc05.UoA.auckland.ac.nz> 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: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 12:11:19 -0000 Dave Garrett writes:=0A= =0A= >Who else is in favor or against, at the moment?=0A= =0A= I'm in favour of relaxing the requirements to match real-world practice.=0A= =0A= Peter.=0A= From nobody Tue May 19 09:39:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2AE1ACC81 for ; Tue, 19 May 2015 09:39:03 -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 stAhuW_dUFdF for ; Tue, 19 May 2015 09:39:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0123.outbound.protection.outlook.com [207.46.100.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9189E1B2FFF for ; Tue, 19 May 2015 09:39:01 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.166.22; Tue, 19 May 2015 16:39:00 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0166.017; Tue, 19 May 2015 16:39:00 +0000 From: Andrei Popov To: Peter Gutmann , "" Thread-Topic: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi Thread-Index: AdCSLOLGJVnE1j84SD6Bm7bXqoznGwAJP6uQ Date: Tue, 19 May 2015 16:38:59 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AB02512C@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB02512C@uxcn10-tdc05.UoA.auckland.ac.nz> 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=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 3:kDyCbaVXmWXmQGSI991Ohats0FUdwQKqm53+gSiwS7t06BBFFJuZkt06zcLi103hnBiDRtw3UMIdhF3ICtN5M3liGIR7DafHcV8bqAjsjIU98x6UoCJS+Ac1gvTd+6Z6c9KKt8IRFwIUSAKL7VujPA==; 10:RFnocmthslLy8/RVL+PJ2XZdMw1ITSG32Sit6qVCi19dKql/CYths7Xz1zOKf8JmX7nnk/db4H6b9xkxpeRelI+Jryk1I/fILgTPTFaP82k=; 6:bb5HLb8adhVbVwJPi7I+Qf4cgh7LgBgee5ZXM5+ASYgGMBRpR0cnvxdvVYRehs6v x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(54094003)(377454003)(189002)(74316001)(87936001)(68736005)(77096005)(15975445007)(2656002)(102836002)(33656002)(54356999)(76176999)(99286002)(189998001)(62966003)(77156002)(105586002)(5001830100001)(5001860100001)(5001770100001)(2950100001)(2900100001)(4001540100001)(81156007)(40100003)(107886002)(76576001)(50986999)(97736004)(122556002)(5001960100002)(86362001)(106356001)(64706001)(101416001)(19580405001)(19580395003)(86612001)(46102003)(92566002)(219693003)(3826002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.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) 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: 19 May 2015 16:38:59.4991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Subject: Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 16:39:03 -0000 +1. Since we're not going to change implementations to conform to the curre= nt strict requirements (because it would have been a breaking change), we c= an as well relax the requirements. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann Sent: Tuesday, May 19, 2015 5:11 AM To: Subject: Re: [TLS] relax certificate_list requirements - opinion call (was = Re: [tls13-spec] relax certificate_list ordering requirements to match curr= ent practice (#169)) I wonder if anyone is reading the full subject line or= does it just get truncated at some poi Dave Garrett writes: >Who else is in favor or against, at the moment? I'm in favour of relaxing the requirements to match real-world practice. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue May 19 12:07:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88521ACE02 for ; Tue, 19 May 2015 12:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 wuln4hMOoyP8 for ; Tue, 19 May 2015 12:07:34 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 203861AC427 for ; Tue, 19 May 2015 12:07:34 -0700 (PDT) Received: by qgde91 with SMTP id e91so12610576qgd.0 for ; Tue, 19 May 2015 12:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=2jTcoYEqIIap4+djR2Xtoa9k83TslLBe843+thvSGn8=; b=ix1VJ252G7KOBDSU8dtLHOLGFY6BstpDfxuyDk8dpca4pW1mxQUoisynvqrxwk709I GESHC/Rk5a/Mu4El/KNkgBllyEV1mTkZsnBJ78p5k8ksOFxinGgn1EjCO6eISb8Bh0GL 5xzUJGIKGcvOw4k13paHpf6K1m5zn4RAJ6Lf8H+WfsyVTVYVL0P1khDwbsbZbyb+uWZe VjC8GXkO3SZBXij5TS1RchEoelVjyJ7M6JtO7ypvLG0VG6O0h7XWTbZSBQFnTB7XlfK1 K3I480AhDxEhYUyDX/wL9KaWX4+0bMDjBgAvmvMuVL6gDMQO/hXwMx7VZ7qeAAUvfze2 mHFg== X-Received: by 10.55.49.71 with SMTP id x68mr61368048qkx.62.1432062453383; Tue, 19 May 2015 12:07:33 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 197sm9554645qhq.23.2015.05.19.12.07.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 May 2015 12:07:32 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 19 May 2015 15:07:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201505191507.31022.davemgarrett@gmail.com> Archived-At: Subject: [TLS] consensus to drop non-ECC DSA from TLS 1.3 spec? (was: DSA should die) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:07:35 -0000 https://www.ietf.org/mail-archive/web/tls/current/msg15773.html The topic of completely dropping DSA was brought up a while back, and the WG seemed to be mostly in favor of it. (in favor of using ECDSA instead, if not wanting to use RSA) Cutting it out of the spec would get rid of a fair bit of obsolete text that doesn't need to be there anymore, which would simplify things a bit. Did we ever get to a point where consensus could be called in favor of killing it? (The threads on the topic veered off into how to make cipher selection better, the result of that line of discussion being that cipher suites should be restricted to negotiating the symmetric cipher and the rest should be negotiated by mandating usage of existing extensions that can do so. No consensus was agreed upon doing that, though, but that's another issue.) Dave From nobody Tue May 19 12:23:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C85F1A882E for ; Tue, 19 May 2015 12:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 B8kNgqozHPro for ; Tue, 19 May 2015 12:23:18 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8C61A86EB for ; Tue, 19 May 2015 12:23:18 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 95C692B531; Tue, 19 May 2015 21:23:16 +0200 (CEST) X-purgate-ID: 152705::1432063396-00000B48-CB21883C/0/0 X-purgate-size: 1092 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 8317F41892; Tue, 19 May 2015 21:23:16 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 74DA91B310; Tue, 19 May 2015 21:23:16 +0200 (CEST) In-Reply-To: To: Andrei Popov Date: Tue, 19 May 2015 21:23:16 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150519192316.74DA91B310@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "" Subject: Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:23:20 -0000 Peter Gutmann wrote: > Dave Garrett writes: > > >Who else is in favor or against, at the moment? > > I'm in favour of relaxing the requirements to match real-world practice. Andrei Popov wrote: > > +1. Since we're not going to change implementations to conform > to the current strict requirements (because it would have been > a breaking change), we can as well relax the requirements. Please do not mess this up *again* -- and clearly sort out where you see any requirements that you feel are a problem. The existing text does not place *ANY* requirement on what the client may accept. The requirements are exclusively about what the server is required to send. Andrei: Is it possible to make Microsoft SChannel send arbitrary heaps of certificates in the Server Certificate handshake message? If yes, how is it exactly configured what junk in what order gets sent? Or were you actually thinking about client behaviour -- where the existing text does not (and never intended to) place any specific behaviour. -Martin From nobody Tue May 19 13:56:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45FC1AD0B4 for ; Tue, 19 May 2015 13:56: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR0U0B1OtaYq for ; Tue, 19 May 2015 13:56:22 -0700 (PDT) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (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 151171A90BF for ; Tue, 19 May 2015 13:56:22 -0700 (PDT) Received: by qkgx75 with SMTP id x75so18925200qkg.1 for ; Tue, 19 May 2015 13:56: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:date:message-id:subject:from:to :content-type; bh=aVzT2gcXndkK4EbGBhdosHqVVJl/nz49Yjxu/Hcfh+o=; b=GuPqztLa77vzPe8TYySaloth5KF4oXFukbA102wY4fFQN9ubLKuu8N084KkXyUmUFR pqPA/SL4CvyrrrHT6H41sOJqayxRZr8UE9UrjjbLpL6VDdTJBe45KzIqoBXQTEF4qsMS LipfMQcr2j+QwzLkX0+6hohms9+YgeMa4iIv6FIYnOQYldS5wbEF6ZVU5WBSopys0DW0 lnT9hZIeM9CoNwMAHpx3imftjnkGxt764IBhy0OIgCq9H9OwMqauwzE0FJfiwir5nZYB K8htUZI8X5fgZ2fnn0ew3puQHrHRnBQgrX4TZwoEuG1RaiS0wL7bkQUQdjZ6HJBWS6j7 yzIw== X-Gm-Message-State: ALoCoQkmxU/km8+ts6wh5bG95u9leRhdesJ68Zj+Fliva3clyDyy4PNwFHif2I+Na2rBeq46wDeU MIME-Version: 1.0 X-Received: by 10.55.27.78 with SMTP id b75mr43201209qkb.7.1432068981305; Tue, 19 May 2015 13:56:21 -0700 (PDT) Received: by 10.96.161.169 with HTTP; Tue, 19 May 2015 13:56:21 -0700 (PDT) Date: Tue, 19 May 2015 13:56:21 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1147e48cecc7790516758a9b Archived-At: Subject: [TLS] Summary of MTI discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:56:23 -0000 --001a1147e48cecc7790516758a9b Content-Type: text/plain; charset=UTF-8 Below is a summary of the current state of the MTI discussions. I expect the details will evolve over time, but some of the main actions are a call for adoption for the ChaCha20 and Curve25519 drafts and removal of non elliptic curve DSA from TLS 1.3. The call for adoptions will come in separate messages. Thanks, J&S o Symmetric: AES-GCM 128 - Consensus to Support MUST ChaCha20-Poly1305 - Consensus seems to be somewhere between a SHOULD and a MUST AES-GCM-256 - rough consensus for SHOULD to match UTA draft o Hash: SHA-256 - Consensus for MUST SHA-384 - rough consensus for SHOULD to match UTA draft o Key Agreement: ECDH P-256 - Consensus for MUST 25519 - Consensus seems to be somewhere between a SHOULD and a MUST o Signature: DSA - consensus to remove RSA - consensus for a MUST but need more detail on hash and signature algorithms Perhaps RSA-PSS with SHA-256 and SHA-384 ECDSA P-256 - seems as if there is a consensus for a MUST, need more detail on hash and signature algorithms - ECDSA with SHA-256 and SHA-384 Other signature algorithms are TBD Cheers, Joe --001a1147e48cecc7790516758a9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Below is a summary of the cu= rrent state of the MTI discussions. =C2=A0 I expect the details will evolve= over time, but some of the main actions are a call for adoption for the Ch= aCha20 and Curve25519 drafts and removal of non elliptic curve DSA from TLS= 1.3.=C2=A0 The call for adoptions will come in separate messages. =C2=A0= =C2=A0

Thanks,

J&S

o Symmetric:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 AES-GCM = 128 - Consensus =C2=A0to Support MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ChaCha= 20-Poly1305 - Consensus seems to be somewhere between a SHOULD and a MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 AES-GCM-256 -= =C2=A0rough consensus for SHOULD to match UTA draft


o Hash:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 SHA-256 - Consensus for MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHA-384 - rough consensus for = SHOULD to match UTA draft


o Key = Agreement: ECDH
=C2=A0 =C2=A0 =C2=A0 =C2=A0 P-256 - Consensus for MUST=C2=A0 =C2=A0 =C2=A0 =C2=A0 25519 -=C2=A0Consensus seems to be somewhere = between a SHOULD and a MUST

o Signature:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DSA - consensus to remove
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RSA - consensus for = a MUST but need more detail on hash and signature algorithms =C2=A0Perhaps = RSA-PSS with SHA-256 and SHA-384
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ECDSA P-2= 56 - seems as if there is a consensus for a MUST, need more detail on hash = and signature algorithms - ECDSA with SHA-256 and SHA-384
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Other signature algorithms are TBD

Cheers,

Joe
--001a1147e48cecc7790516758a9b-- From nobody Tue May 19 14:09:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87ACA1B3205 for ; Tue, 19 May 2015 14:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 xVtWDEpeaUyx for ; Tue, 19 May 2015 14:09:35 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 7ECAF1A90BF for ; Tue, 19 May 2015 14:09:35 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 116DD1C211B; Tue, 19 May 2015 23:09:33 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id E2C8F1FE014F; Tue, 19 May 2015 23:09:32 +0200 (CEST) Date: Tue, 19 May 2015 23:09:32 +0200 From: Kurt Roeckx To: Dave Garrett Message-ID: <20150519210932.GA25790@roeckx.be> References: <201505191507.31022.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201505191507.31022.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] consensus to drop non-ECC DSA from TLS 1.3 spec? (was: DSA should die) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:09:37 -0000 On Tue, May 19, 2015 at 03:07:30PM -0400, Dave Garrett wrote: > https://www.ietf.org/mail-archive/web/tls/current/msg15773.html > > The topic of completely dropping DSA was brought up a while back, and the WG seemed to be mostly in favor of it. (in favor of using ECDSA instead, if not wanting to use RSA) Cutting it out of the spec would get rid of a fair bit of obsolete text that doesn't need to be there anymore, which would simplify things a bit. Did we ever get to a point where consensus could be called in favor of killing it? The usage of DSA certificates is so low that I know about 4 certificates that didn't expire yet, but haven't seen any for more than a year. Firefox recently (March 31) stopped supporting DSA certificates and I don't know of any problems with that change. So I see no need to support it in TLS 1.3. Kurt From nobody Tue May 19 14:32:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B901B3351 for ; Tue, 19 May 2015 14:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.673 X-Spam-Level: * X-Spam-Status: No, score=1.673 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FSL_HELO_BARE_IP_2=1.675, RCVD_IN_DNSWL_NONE=-0.0001, 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 KfQzUN1sB3P6 for ; Tue, 19 May 2015 14:32:36 -0700 (PDT) Received: from gateway24.websitewelcome.com (gateway24.websitewelcome.com [192.185.50.252]) (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 C79971B335A for ; Tue, 19 May 2015 14:32:28 -0700 (PDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway24.websitewelcome.com (Postfix) with ESMTP id 7A3146AED562 for ; Tue, 19 May 2015 16:32:01 -0500 (CDT) Received: from [173.73.121.66] (port=58484 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Yup7I-0004l5-S2 for tls@ietf.org; Tue, 19 May 2015 16:32:01 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 19 May 2015 17:31:59 -0400 To: IETF TLS Working Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.66 X-Exim-ID: 1Yup7I-0004l5-S2 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [173.73.121.66]:58484 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:32:37 -0000 All, This message serves two purposes: 1) It is the WG call for adoption of: http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-chacha-tls/ This draft specifies the use of the ChaCha stream cipher with Poly1305 = in the TLS and DTLS protocols. The WG needs this draft to specify code = points in support of the recent MTI consensus call (see = http://www.ietf.org/mail-archive/web/tls/current/msg16343.html). If you = object to the adoption of this draft as a WG item, please respond to the = list indicating why by 20150602. 2) It is a request for an early code point assignment: We have a request for an early code point assignment for the cipher = suites listed in the draft. If you have a concern with an early code = point assignment for the ciphers listed in this draft, please respond to = the list indicating why by 20150602. =20 Thanks, J&S= From nobody Tue May 19 14:51:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040121B33E8 for ; Tue, 19 May 2015 14:51:49 -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 uIW7WL974aGt for ; Tue, 19 May 2015 14:51:44 -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 1633D1B33E1 for ; Tue, 19 May 2015 14:51:44 -0700 (PDT) Received: by wibt6 with SMTP id t6so38630686wib.0 for ; Tue, 19 May 2015 14:51:42 -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=7cLdNJggpWE6u0tk+o+IrBuUs0uBvX8jROwIrWC4h1M=; b=YD4TwYUvLGL8Ob+EII+oPQtGueGQ+6Cj3mOcNxrcZWPM1n0eFGGffs/MC+h7sMT63R E6AuUlVrgmisKF3YlUrNP2KlKwvSZWsx8zQt/2Mq7aiZDJVf3j7VMUrW3rlXe7Q0pNjO wFAt5bZmcKUnljEPCk3rz9m0+eYuRSRl9HMaDB/2yrBmJo4KZzvcL+S/OByugf3btdCQ Vn+loudbJ6y3fN8CDJByKmeDO3cyTJTcLL3Txi9qUL33GH9LJzUZlDwbnnz5Ql77A8EA dJBFWC4D5rmdGcnp14SyTrmXHF2NIUHdIrk+ECmmo3YEFIKuPgRMuBqzh5XrEKMo8Ucc 1AHQ== X-Received: by 10.194.216.230 with SMTP id ot6mr59651850wjc.68.1432072302764; Tue, 19 May 2015 14:51:42 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id y7sm23617431wjw.16.2015.05.19.14.51.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 May 2015 14:51:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Wed, 20 May 2015 00:51:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> References: To: Sean Turner X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:51:49 -0000 1) All for it 2) I question the need for TLS_DHE_ ciphersuites, and I seriously doubt = anybody=E2=80=99s going to use those with ChaCha20 =E2=80=9Cin the = wild=E2=80=9D. Other than that, I=E2=80=99m all for early assignment as = it would allow us to get the algorithms into code-bases and test = interoperability quicker. Yoav > On May 20, 2015, at 12:31 AM, Sean Turner wrote: >=20 > All, >=20 > This message serves two purposes: >=20 > 1) It is the WG call for adoption of: >=20 > http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-chacha-tls/ >=20 > This draft specifies the use of the ChaCha stream cipher with Poly1305 = in the TLS and DTLS protocols. The WG needs this draft to specify code = points in support of the recent MTI consensus call (see = http://www.ietf.org/mail-archive/web/tls/current/msg16343.html). If you = object to the adoption of this draft as a WG item, please respond to the = list indicating why by 20150602. >=20 > 2) It is a request for an early code point assignment: >=20 > We have a request for an early code point assignment for the cipher = suites listed in the draft. If you have a concern with an early code = point assignment for the ciphers listed in this draft, please respond to = the list indicating why by 20150602. =20 >=20 > Thanks, >=20 > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue May 19 15:14:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FED1B345D for ; Tue, 19 May 2015 15:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 zQSao3XKm9-k for ; Tue, 19 May 2015 15:14:47 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BBF1B345A for ; Tue, 19 May 2015 15:14:45 -0700 (PDT) Received: by yhom41 with SMTP id m41so8343872yho.1 for ; Tue, 19 May 2015 15:14:44 -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:content-transfer-encoding; bh=P7hCEGrGBU8GcFvdrsmz7F/z7bYdkcoVO+T8exITrC8=; b=cy86OqTiS0QE34D1AOUo1mIWKCyT+nfu8Ilmzrm0YjJIyUZKigg4CIlK5acEiQt/g+ K3nAY/Q0ECIPC2WA+oW3gS9k4I1JdwRUaxfBwdVheL3XIrFNG++V/NcOXkBWkS1PSWvV ndV9A1rGgyWzcahtiFMe6wT+eQUz9RuUXbPlPz+OMEbd6x5GTEd6Sbeat3Ow+OIRXP+b jPqi/uBk/8w2rOPs7GZHeFndMs2u8KU7WNABXDesveA19YIBgy5JUT5aXUPjKSFL4SQm izari7cJbi6OGoqr0dXsehvglz+/5aS4YFuptfIjyZ6T6BubZfzCx+X0jppVWcAshvxT ThdQ== MIME-Version: 1.0 X-Received: by 10.236.47.169 with SMTP id t29mr28458935yhb.69.1432073683997; Tue, 19 May 2015 15:14:43 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Tue, 19 May 2015 15:14:43 -0700 (PDT) In-Reply-To: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> Date: Tue, 19 May 2015 15:14:43 -0700 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:14:49 -0000 On 19 May 2015 at 14:51, Yoav Nir wrote: > 2) I question the need for TLS_DHE_ ciphersuites, and I seriously doubt a= nybody=E2=80=99s going to use those with ChaCha20 =E2=80=9Cin the wild=E2= =80=9D. Other than that, I=E2=80=99m all for early assignment as it would a= llow us to get the algorithms into code-bases and test interoperability qui= cker. I tend to agree. Can someone reply with a brief explanation of why each of the following is needed? Hopefully better than what I was able to devise: TLS_RSA_WITH_CHACHA20_POLY1305 Because we're scared of ephemeral key exchange for some reason ? TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 Because ECDHE is good, and RSA is widespread. TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 Because this is what we actually want. TLS_DHE_RSA_WITH_CHACHA20_POLY1305 Because we need a backup for EC. TLS_DHE_PSK_WITH_CHACHA20_POLY1305 Because ECDHE is nice, but we need a backup, even for little things ? TLS_PSK_WITH_CHACHA20_POLY1305 Because little things don't like paying for asymmetric crypto. TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 Because little things need nice things too. TLS_RSA_PSK_WITH_CHACHA20_POLY1305 Because little things like doing bignum exponentiation without any PFS payoff, but RSA alone isn't "secure enough" ? The thing that concerns me most is that we aren't saying that PFS is required outside of PSK. I understand the carve-out we've made for the little things, but I don't understand why we are defining RSA-based suites without PFS. Of comparable concern is the RSA_PSK stuff. I wasn't around for the definition of these originally, but they make basically no sense to me. I get the DHE_PSK thing if you justify it using the same basis as DHE_RSA, but it might be that the little things can just take a pass on PFS without ECDHE. Would it be unreasonable to cut the list to ... ? TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 TLS_DHE_RSA_WITH_CHACHA20_POLY1305 TLS_PSK_WITH_CHACHA20_POLY1305 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 Also, I'm not against DHE in general, and I think that it's worth keeping around for a little longer. However. If we consider DHE_RSA worth doing, then the only logic I can concoct would provide almost equal justification for DHE_ECDSA. From nobody Tue May 19 15:15:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8EA1B3459 for ; Tue, 19 May 2015 15:15:16 -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 1R2sdlOMC_8M for ; Tue, 19 May 2015 15:15:14 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 8B5A51A1EF2 for ; Tue, 19 May 2015 15:15:14 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so134142247wic.0 for ; Tue, 19 May 2015 15:15:13 -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:from:date :message-id:subject:to:cc:content-type; bh=v+6Ijp6tbwjlSMiSjNiBPtE28ySVj89t1YPo6Y13fRs=; b=P8N4l9uZW8qNmfBGfVs9nYqf6gkBuXXTSt5xQ1YN4ntbxZXlamCuImn7fQ5Tta40FV V/MXpzeLKqLPLi7AEG3DbaSJAJr+Rq8o/foxOlie7ql9es30qN/h1L6E33FwnrcEwlPE I6AIjlgLZUSd75/LTlBlNOYz7lhq/el8UzcIuqgzZLabSKb4QjE5dx6JJ4TX+GxvBWvh YSVtwFINkEo1c48o9K3VBUE02JlFUrQfFTOjmDap9UEXpeTHyiKzCZ43HoY4X+IenGfx EAycU4zz2sn1NEvbqmhJ9OXP0efaJg0InHToeHZBl5ycXWNlvkZx23Q/e6RGLJzOGQeM WYlg== X-Gm-Message-State: ALoCoQkXMzC4IKW+T+rj0uos43tIiGYYtbhnoNGF0yQj6oOwAqh8hGNsTnV90jaLIIsCcQ+pLlwG X-Received: by 10.194.79.225 with SMTP id m1mr5247683wjx.8.1432073713370; Tue, 19 May 2015 15:15:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Tue, 19 May 2015 15:14:32 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 19 May 2015 15:14:32 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=047d7b10c903fa5d8d051676a4c5 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:15:16 -0000 --047d7b10c903fa5d8d051676a4c5 Content-Type: text/plain; charset=UTF-8 On Tue, May 19, 2015 at 2:31 PM, Sean Turner wrote: > All, > > This message serves two purposes: > > 1) It is the WG call for adoption of: > > http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-chacha-tls/ > > This draft specifies the use of the ChaCha stream cipher with Poly1305 in > the TLS and DTLS protocols. The WG needs this draft to specify code points > in support of the recent MTI consensus call (see > http://www.ietf.org/mail-archive/web/tls/current/msg16343.html). If you > object to the adoption of this draft as a WG item, please respond to the > list indicating why by 20150602. > > 2) It is a request for an early code point assignment: > > We have a request for an early code point assignment for the cipher suites > listed in the draft. If you have a concern with an early code point > assignment for the ciphers listed in this draft, please respond to the list > indicating why by 20150602. > I am in favor of this draft. Prior to doing the code point assignment, however, we should resolve the question of the per-record nonce algorithm. The current draft uses an algorithm that is not consistent either with the algorithm we use for GCM or TLS 1.3. - TLS 1.2 GCM: 32-bit fixed salt || 64-bit explicit per-record IV - TLS 1.3: fixed mask XORed with the record sequence number - ChaCha: 32-bit fixed salt || record sequence number On another thread, people have expressed the opinion that ChaCha should be consistent with GCM for both 1.2 and 1.3, but if we're going to do that we minimally need to change the algorithm for 1.2 (at the cost of 8 bytes per record). I don't have a strong opinion about this, but we should resolve it now. -Ekr Thanks, > > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b10c903fa5d8d051676a4c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 19, 2015 at 2:31 PM, Sean Turner <turners@ieca.com><= /span> wrote:
All,

This message serves two purposes:

1) It is the WG call for adoption of:

http://datatracker.ietf.org/doc/draft-mavrogiannopou= los-chacha-tls/

This draft specifies the use of the ChaCha stream cipher with Poly1305 in t= he TLS and DTLS protocols.=C2=A0 The WG needs this draft to specify code po= ints in support of the recent MTI consensus call (see htt= p://www.ietf.org/mail-archive/web/tls/current/msg16343.html).=C2=A0 If = you object to the adoption of this draft as a WG item, please respond to th= e list indicating why by 20150602.

2) It is a request for an early code point assignment:

We have a request for an early code point assignment for the cipher suites = listed in the draft.=C2=A0 If you have a concern with an early code point a= ssignment for the ciphers listed in this draft, please respond to the list = indicating why by 20150602.

I am in fav= or of this draft.

Prior to doing the code point as= signment, however, we should resolve
the question of the per-reco= rd nonce algorithm. The current draft uses
an algorithm that is n= ot consistent either with the algorithm we use for
GCM or TLS 1.3= .

- TLS 1.2 GCM: 32-bit fixed salt || 64-bit expli= cit per-record IV
- TLS 1.3: fixed mask XORed with the record seq= uence number
- ChaCha: 32-bit fixed salt || record sequence numbe= r

On another thread, people have expressed the opi= nion that ChaCha should
be consistent with GCM for both 1.2 and 1= .3, but if we're going to do that
we minimally need to change= the algorithm for 1.2 (at the cost of 8 bytes
per record).
=

I don't have a strong opinion about this, but we sh= ould resolve it now.

-Ekr


Thanks,

J&S
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--047d7b10c903fa5d8d051676a4c5-- From nobody Tue May 19 15:28:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AC01B3474 for ; Tue, 19 May 2015 15:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYK7V4naAtbV for ; Tue, 19 May 2015 15:28:00 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8D81B346D for ; Tue, 19 May 2015 15:28:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,460,1427752800"; d="scan'208";a="125038269" Received: from ra178-1-88-163-20-214.fbx.proxad.net (HELO [192.168.0.24]) ([88.163.20.214]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 May 2015 00:27:58 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Benjamin Beurdouche In-Reply-To: Date: Wed, 20 May 2015 00:27:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69A42A6B-0F36-4F54-BD0D-52F0BFE7AA2F@inria.fr> References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:28:03 -0000 > On 20 May 2015, at 00:14, Martin Thomson = wrote: >=20 > On 19 May 2015 at 14:51, Yoav Nir wrote: >> 2) I question the need for TLS_DHE_ ciphersuites, and I seriously = doubt anybody=E2=80=99s going to use those with ChaCha20 =E2=80=9Cin the = wild=E2=80=9D. Other than that, I=E2=80=99m all for early assignment as = it would allow us to get the algorithms into code-bases and test = interoperability quicker. >=20 > I tend to agree. Can someone reply with a brief explanation of why > each of the following is needed? Hopefully better than what I was > able to devise: >=20 > TLS_RSA_WITH_CHACHA20_POLY1305 > Because we=E2=80=99re scared of ephemeral key exchange for some reason = ? I am not, so you shouldn=E2=80=99t =3DP > TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 > Because ECDHE is good, and RSA is widespread. Yes > TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 > Because this is what we actually want. Yes > TLS_DHE_RSA_WITH_CHACHA20_POLY1305 > Because we need a backup for EC. Better safe than sorry. > TLS_DHE_PSK_WITH_CHACHA20_POLY1305 > Because ECDHE is nice, but we need a backup, even for little things ? Is this sentence hiding something ? ;) I am really not sure about this one, why since there is EC=E2=80=A6 > TLS_PSK_WITH_CHACHA20_POLY1305 > Because little things don=E2=80=99t like paying for asymmetric crypto. Fair enough > TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 > Because little things need nice things too. Yes > TLS_RSA_PSK_WITH_CHACHA20_POLY1305 > Because little things like doing bignum exponentiation without any PFS > payoff, but RSA alone isn=E2=80=99t "secure enough" ? Arf ! chop off it=E2=80=99s RSA !=20 > The thing that concerns me most is that we aren't saying that PFS is > required outside of PSK. I understand the carve-out we've made for > the little things, but I don't understand why we are defining > RSA-based suites without PFS. >=20 > Of comparable concern is the RSA_PSK stuff. I wasn't around for the > definition of these originally, but they make basically no sense to > me. Agreed > I get the DHE_PSK thing if you justify it using the same basis as > DHE_RSA, but it might be that the little things can just take a pass > on PFS without ECDHE. >=20 > Would it be unreasonable to cut the list to ... ? > TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 > TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 > TLS_DHE_RSA_WITH_CHACHA20_POLY1305 > TLS_PSK_WITH_CHACHA20_POLY1305 > TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 I completely agree with Martin on this list, we probably do not need = more ciphersuites than those. > Also, I'm not against DHE in general, and I think that it's worth > keeping around for a little longer. However. If we consider DHE_RSA > worth doing, then the only logic I can concoct would provide almost > equal justification for DHE_ECDSA. I really don=E2=80=99t think DHE_ECDSA will ever by massively used =E2=80=A6= It would be like having RSA_ECDSA =3Ds.. Cheers, B. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue May 19 16:17:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E337D1B3543 for ; Tue, 19 May 2015 16:17: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 WDOonm7gr2oK for ; Tue, 19 May 2015 16:17:38 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 6CF191B3542 for ; Tue, 19 May 2015 16:17:38 -0700 (PDT) Received: by qgez61 with SMTP id z61so11912948qge.1 for ; Tue, 19 May 2015 16:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=XMYuNG1hZ66k5LNKvexDlL6Tgud0yCEG1kJVqjumG2U=; b=NwyB63rOdO8WbhH7TeX5ya8rZOClbhY5jpz3cluJQzpQzf7pE4yyM0grounl3vpz4C YGejJEIJcbvDcsu/SEfGbKIcI5NwLQLv2Z0mesnJePxegMbuWx7tDO+jn/hMXous1yjV weW3QnsDDAAmkeJiN5s2jWAOQgLgPrAmrcXSEZ69GQcb8pHCobor9gsOrAB1RNXubre/ DPEAaG7LZanrEtBBMVCnzK/MLYnzHRGQYQGxriwZli4E8Bfh1xdIItkDoHoMjRw8iPBB c9sNbgOBmJzT7jziDRTx0ptWQhwJAI397qDQ5HSiPHlDXxH+1mYb8HP90OjT5iXh87+z Tuxg== X-Received: by 10.55.21.221 with SMTP id 90mr63530301qkv.44.1432077457722; Tue, 19 May 2015 16:17:37 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 34sm10087947qkr.47.2015.05.19.16.17.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 May 2015 16:17:37 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 19 May 2015 19:17:35 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505191917.36099.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Summary of MTI discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 23:17:40 -0000 On Tuesday, May 19, 2015 04:56:21 pm Joseph Salowey wrote: > o Key Agreement: ECDH > P-256 - Consensus for MUST > 25519 - Consensus seems to be somewhere between a SHOULD and a MUST The doc currently has an inline "OPEN ISSUE: Triage curve list." (doesn't appear to be a separate issue filed for it) So, in addition to MTI and any other additions, a list to remove support for should also be compiled. I'm guessing at least all <224bit would be on the chopping block. I don't think the specifics of this got discussed on list yet. Dave From nobody Tue May 19 22:30:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B071B3586 for ; Tue, 19 May 2015 22:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_40=-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 2UNslpoTXaxD for ; Tue, 19 May 2015 22:30:43 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA251B3583 for ; Tue, 19 May 2015 22:30:43 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 54333166167; Wed, 20 May 2015 05:30:42 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 49356166166; Wed, 20 May 2015 05:30:42 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 465161E080; Wed, 20 May 2015 05:30:42 +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; Wed, 20 May 2015 00:30:41 -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; Wed, 20 May 2015 00:30:41 -0500 From: "Salz, Rich" To: Sean Turner , IETF TLS Working Group Thread-Topic: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls Thread-Index: AQHQkntXQQefPrlX2020Mw5b0R8H3Z2EVx7w Date: Wed, 20 May 2015 05:30:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.146.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 05:30:44 -0000 I'm in favor of support, but we should trim the code point list. From nobody Tue May 19 23:43:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23981A87BE for ; Tue, 19 May 2015 23:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8y7iZCgh9q4 for ; Tue, 19 May 2015 23:43:07 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (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 C75CD1A6F7B for ; Tue, 19 May 2015 23:43:07 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4K6h5Wg018643; Wed, 20 May 2015 02:43:05 -0400 Date: Wed, 20 May 2015 02:43:04 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Eric Rescorla Message-ID: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [94.112.138.148, 10.5.101.181] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls Thread-Index: 71av2TE/1QAhQclLN93J3CV+uiELQw== Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 06:43:10 -0000 ----- Original Message ----- > I am in favor of this draft. > > Prior to doing the code point assignment, however, we should resolve > the question of the per-record nonce algorithm. The current draft uses > an algorithm that is not consistent either with the algorithm we use for > GCM or TLS 1.3. > > - TLS 1.2 GCM: 32-bit fixed salt || 64-bit explicit per-record IV > - TLS 1.3: fixed mask XORed with the record sequence number > - ChaCha: 32-bit fixed salt || record sequence number I think the chacha draft is consistent with the TLS 1.2 GCM draft. The TLS 1.2 GCM draft allows as an option (MAY) to have "32-bit fixed salt || record sequence number", and in fact all implementations do that. So this draft simply ratifies that approach and changes that requirement to MUST. The approach in TLS 1.3 is a novel one and I don't think it suits this draft. regards, Nikos From nobody Tue May 19 23:58:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B641A8795 for ; Tue, 19 May 2015 23:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFqk103eVBC3 for ; Tue, 19 May 2015 23:58:03 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (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 6F81B1A6F27 for ; Tue, 19 May 2015 23:58:03 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4K6w1Ji036333; Wed, 20 May 2015 02:58:01 -0400 Date: Wed, 20 May 2015 02:58:01 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Martin Thomson Message-ID: <567925460.1076064.1432105081320.JavaMail.zimbra@redhat.com> In-Reply-To: References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [94.112.138.148, 10.5.101.181] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls Thread-Index: NmMYpdoO1bRAlV+romA6wjBOXBqB2w== Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 06:58:05 -0000 ----- Original Message ----- > I tend to agree. Can someone reply with a brief explanation of why > each of the following is needed? Hopefully better than what I was > able to devise: I don't think one would have to explain each and every usage of a ciphersuite. If applications don't need it they won't use it. > TLS_RSA_WITH_CHACHA20_POLY1305 > Because we're scared of ephemeral key exchange for some reason ? I believe the main argument is that this draft is supposed to provide ciphersuites to used by existing protocols and applications which already use RSA. Yes, I agree that some of them would need to be updated to provide PFS, but this draft doesn't update those apps/protocols. A protocol that I know that relies on the RSA ciphersuites is the anyconnect vpn protocol (even though its usage doesn't affect PFS). > TLS_DHE_PSK_WITH_CHACHA20_POLY1305 > Because ECDHE is nice, but we need a backup, even for little things ? That was my intention. To provide DHE as backup to ECDHE, since they are not susceptible to the same attacks. It is now especially relevant since we will have fixed groups for DHE. > TLS_RSA_PSK_WITH_CHACHA20_POLY1305 > Because little things like doing bignum exponentiation without any PFS > payoff, but RSA alone isn't "secure enough" ? I don't have much data for this ciphersuite. If someone has a strong argument on why it shouldn't be included I wouldn't object. > The thing that concerns me most is that we aren't saying that PFS is > required outside of PSK. I understand the carve-out we've made for > the little things, but I don't understand why we are defining > RSA-based suites without PFS. I agree. However, note that this draft is not the place to argue for that, but rather the protocols that rely on non-PFS ciphersuites. > Of comparable concern is the RSA_PSK stuff. I wasn't around for the > definition of these originally, but they make basically no sense to > me. The idea was to provide both certificate auth for the server and PSK auth for the client. The implementation was less than ideal. > Also, I'm not against DHE in general, and I think that it's worth > keeping around for a little longer. However. If we consider DHE_RSA > worth doing, then the only logic I can concoct would provide almost > equal justification for DHE_ECDSA. There is no DHE_ECDSA key exchange defined for TLS. Otherwise there would be no reason for these ciphersuites to be there. regards, Nikos From nobody Wed May 20 00:13:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25E61A6F27 for ; Wed, 20 May 2015 00:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J25Tu7cgjTyh for ; Wed, 20 May 2015 00:13: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 F24A11A88A9 for ; Wed, 20 May 2015 00:13:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8D1EEBECF; Wed, 20 May 2015 08:13:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mMuAy6BGPUo; Wed, 20 May 2015 08:13:00 +0100 (IST) Received: from [192.168.49.129] (unknown [119.145.14.6]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 89EBEBECA; Wed, 20 May 2015 08:12:58 +0100 (IST) Message-ID: <555C33F6.4020402@cs.tcd.ie> Date: Wed, 20 May 2015 08:12:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos , Martin Thomson References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> <567925460.1076064.1432105081320.JavaMail.zimbra@redhat.com> In-Reply-To: <567925460.1076064.1432105081320.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 07:13:24 -0000 Hi, While I am generally against ciphersuite proliferation I think its a good idea to register some of these now. I would note however that you only need the temporary registrations for things with which people want to work now - any future proofing can be done as the draft progresses so the WG do not need to decide all of this now. And of course, there is always the potential for non-interoperable changes to happen during the WG process which is another good reason to not register more than the absolute minimum of codepoints now. So please restrict the early registration list to those that are needed *right now*. Anything that can wait months, should wait months. Thanks, S. On 20/05/15 07:58, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- >> I tend to agree. Can someone reply with a brief explanation of why >> each of the following is needed? Hopefully better than what I was >> able to devise: > I don't think one would have to explain each and every usage > of a ciphersuite. If applications don't need it they won't use it. > >> TLS_RSA_WITH_CHACHA20_POLY1305 >> Because we're scared of ephemeral key exchange for some reason ? > I believe the main argument is that this draft is supposed to provide > ciphersuites to used by existing protocols and applications which already > use RSA. Yes, I agree that some of them would need to be updated to provide > PFS, but this draft doesn't update those apps/protocols. A protocol that > I know that relies on the RSA ciphersuites is the anyconnect vpn protocol > (even though its usage doesn't affect PFS). > >> TLS_DHE_PSK_WITH_CHACHA20_POLY1305 >> Because ECDHE is nice, but we need a backup, even for little things ? > That was my intention. To provide DHE as backup to ECDHE, since they > are not susceptible to the same attacks. It is now > especially relevant since we will have fixed groups for DHE. > >> TLS_RSA_PSK_WITH_CHACHA20_POLY1305 >> Because little things like doing bignum exponentiation without any PFS >> payoff, but RSA alone isn't "secure enough" ? > I don't have much data for this ciphersuite. If someone has a strong argument > on why it shouldn't be included I wouldn't object. > >> The thing that concerns me most is that we aren't saying that PFS is >> required outside of PSK. I understand the carve-out we've made for >> the little things, but I don't understand why we are defining >> RSA-based suites without PFS. > I agree. However, note that this draft is not the place to argue for that, > but rather the protocols that rely on non-PFS ciphersuites. > >> Of comparable concern is the RSA_PSK stuff. I wasn't around for the >> definition of these originally, but they make basically no sense to >> me. > The idea was to provide both certificate auth for the server and PSK > auth for the client. The implementation was less than ideal. > >> Also, I'm not against DHE in general, and I think that it's worth >> keeping around for a little longer. However. If we consider DHE_RSA >> worth doing, then the only logic I can concoct would provide almost >> equal justification for DHE_ECDSA. > There is no DHE_ECDSA key exchange defined for TLS. Otherwise there would > be no reason for these ciphersuites to be there. > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed May 20 04:10:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0601A0062 for ; Wed, 20 May 2015 04:10:29 -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 N3ML5LHtdrfL for ; Wed, 20 May 2015 04:10:27 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 B9F981A005F for ; Wed, 20 May 2015 04:10:26 -0700 (PDT) Received: by wghq2 with SMTP id q2so48985434wgh.1 for ; Wed, 20 May 2015 04:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8YATUiV4rj17RY/vWnguWmx7hYnaMPUwAvoab33O9y8=; b=VD3OtKwxupfLm2GZBR4XvzzdJr6l2AAc0/zrdRCOgYVWkH//jxyo9cy+jFYkI7r6LM 3iLMUwgesR0x0NVwk/ouKtWpsu75gxqNcAfBTqeZd325R7LchFipbeaZS9g3580R2Xvz mUE54LaRDc4+LEThp2w7syMVv7X8PVJxNWgKr0hE8IoyXqh4ltrG4fAtWBzN6X+ormOD uUArbmHw/M86zLT1UYHj/ZisJYXn1Iu87L5UCe7WHDGs2qOWFFHTwo5FlXJYceHCLM0H p4D6dkfPnkwPJe7dJVkXAZjiyz8bnD5lddGofxpdbSQYuXc21wNIXHecM54TkXXCCirp F8/Q== X-Received: by 10.194.84.100 with SMTP id x4mr34674910wjy.69.1432120225487; Wed, 20 May 2015 04:10:25 -0700 (PDT) Received: from [192.168.1.234] ([2.54.11.25]) by mx.google.com with ESMTPSA id gt10sm2876599wib.20.2015.05.20.04.10.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 04:10:24 -0700 (PDT) Message-ID: <555C6B9D.2060302@gmail.com> Date: Wed, 20 May 2015 14:10:21 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , Nikos Mavrogiannopoulos , Martin Thomson References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> <567925460.1076064.1432105081320.JavaMail.zimbra@redhat.com> <555C33F6.4020402@cs.tcd.ie> In-Reply-To: <555C33F6.4020402@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 11:10:29 -0000 At ipsecme, we had a few incompatible changes between WG adoption of our own chacha draft, and WGLC. So I would recommend against early registration altogether. Thanks, Yaron On 05/20/2015 10:12 AM, Stephen Farrell wrote: > > Hi, > > While I am generally against ciphersuite proliferation I > think its a good idea to register some of these now. I > would note however that you only need the temporary > registrations for things with which people want to work > now - any future proofing can be done as the draft > progresses so the WG do not need to decide all of this > now. And of course, there is always the potential for > non-interoperable changes to happen during the WG > process which is another good reason to not register > more than the absolute minimum of codepoints now. > > So please restrict the early registration list to > those that are needed *right now*. Anything that can > wait months, should wait months. > > Thanks, > S. > > > On 20/05/15 07:58, Nikos Mavrogiannopoulos wrote: >> ----- Original Message ----- >>> I tend to agree. Can someone reply with a brief explanation of why >>> each of the following is needed? Hopefully better than what I was >>> able to devise: >> I don't think one would have to explain each and every usage >> of a ciphersuite. If applications don't need it they won't use it. >> >>> TLS_RSA_WITH_CHACHA20_POLY1305 >>> Because we're scared of ephemeral key exchange for some reason ? >> I believe the main argument is that this draft is supposed to provide >> ciphersuites to used by existing protocols and applications which already >> use RSA. Yes, I agree that some of them would need to be updated to >> provide >> PFS, but this draft doesn't update those apps/protocols. A protocol that >> I know that relies on the RSA ciphersuites is the anyconnect vpn protocol >> (even though its usage doesn't affect PFS). >> >>> TLS_DHE_PSK_WITH_CHACHA20_POLY1305 >>> Because ECDHE is nice, but we need a backup, even for little things ? >> That was my intention. To provide DHE as backup to ECDHE, since they >> are not susceptible to the same attacks. It is now >> especially relevant since we will have fixed groups for DHE. >> >>> TLS_RSA_PSK_WITH_CHACHA20_POLY1305 >>> Because little things like doing bignum exponentiation without any PFS >>> payoff, but RSA alone isn't "secure enough" ? >> I don't have much data for this ciphersuite. If someone has a strong >> argument >> on why it shouldn't be included I wouldn't object. >> >>> The thing that concerns me most is that we aren't saying that PFS is >>> required outside of PSK. I understand the carve-out we've made for >>> the little things, but I don't understand why we are defining >>> RSA-based suites without PFS. >> I agree. However, note that this draft is not the place to argue for >> that, >> but rather the protocols that rely on non-PFS ciphersuites. >> >>> Of comparable concern is the RSA_PSK stuff. I wasn't around for the >>> definition of these originally, but they make basically no sense to >>> me. >> The idea was to provide both certificate auth for the server and PSK >> auth for the client. The implementation was less than ideal. >> >>> Also, I'm not against DHE in general, and I think that it's worth >>> keeping around for a little longer. However. If we consider DHE_RSA >>> worth doing, then the only logic I can concoct would provide almost >>> equal justification for DHE_ECDSA. >> There is no DHE_ECDSA key exchange defined for TLS. Otherwise there would >> be no reason for these ciphersuites to be there. >> regards, >> Nikos >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed May 20 04:20:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE16C1A0065 for ; Wed, 20 May 2015 04:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqO9i9saTl_A for ; Wed, 20 May 2015 04:20:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 DB0501A0122 for ; Wed, 20 May 2015 04:20:48 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4KBKkOx013528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 20 May 2015 07:20:47 -0400 Received: from unused (unused [10.10.51.124] (may be forged)) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4KBKiwi023351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 May 2015 07:20:46 -0400 Message-ID: <1432120843.2926.0.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Yaron Sheffer Date: Wed, 20 May 2015 13:20:43 +0200 In-Reply-To: <555C6B9D.2060302@gmail.com> References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> <567925460.1076064.1432105081320.JavaMail.zimbra@redhat.com> <555C33F6.4020402@cs.tcd.ie> <555C6B9D.2060302@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 11:20:50 -0000 On Wed, 2015-05-20 at 14:10 +0300, Yaron Sheffer wrote: > At ipsecme, we had a few incompatible changes between WG adoption of our > own chacha draft, and WGLC. So I would recommend against early > registration altogether. Could you summarize the changes done for ipsecme in case they are relevant for this draft as well? regards, Nikos From nobody Wed May 20 04:24:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F761A01A5 for ; Wed, 20 May 2015 04:24: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 Qijr8d5_u_xk for ; Wed, 20 May 2015 04:24:02 -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 6A60A1A016A for ; Wed, 20 May 2015 04:24:02 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so151073096wic.0 for ; Wed, 20 May 2015 04:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Mfu/dC3OacQtNWLzGqxPPl2Dk2lM/BtNe2aklb3/9Yk=; b=nmzkxKusvAax0LXVDakrLGKvVVj5YE6Sh1x8rTdOWfFAbmbpXQwaLTXjEB47/8SM7X TEeKcKUzCynKYciK8YY4Xhu8Lw34pULVYKeJ5pNf+Wq9YYEuNDRJt9I/XHSiVqq57Bms dtB126iDvurFqIUfKx1ndUt/dGYj/i0S72xsmg5oPRqXoEGA73mf3c1add7SjsL04rS4 uUQspq9PIgev6SOaxggIzlA0zhZ/BMSSD27m/8WOS9aWplQxrAo1Ir75uesyqPh9Mcln B382i47nUxGUeAdRytuJjTfylf9Bq8To+HX3AUnZb0zOwJMWInfKwSp7DBlzerb0/NNU x/zQ== X-Received: by 10.194.2.47 with SMTP id 15mr64377970wjr.101.1432121041122; Wed, 20 May 2015 04:24:01 -0700 (PDT) Received: from [192.168.1.234] ([2.54.11.25]) by mx.google.com with ESMTPSA id js3sm26318152wjc.5.2015.05.20.04.23.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 04:24:00 -0700 (PDT) Message-ID: <555C6ECE.2000201@gmail.com> Date: Wed, 20 May 2015 14:23:58 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> <567925460.1076064.1432105081320.JavaMail.zimbra@redhat.com> <555C33F6.4020402@cs.tcd.ie> <555C6B9D.2060302@gmail.com> <1432120843.2926.0.camel@redhat.com> In-Reply-To: <1432120843.2926.0.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 11:24:03 -0000 I cannot, sorry. But a diff between -00 and -08 shows (among other things) differences in the order of data items that are covered by the Poly1305 tag. Thanks, Yaron On 05/20/2015 02:20 PM, Nikos Mavrogiannopoulos wrote: > On Wed, 2015-05-20 at 14:10 +0300, Yaron Sheffer wrote: >> At ipsecme, we had a few incompatible changes between WG adoption of our >> own chacha draft, and WGLC. So I would recommend against early >> registration altogether. > > Could you summarize the changes done for ipsecme in case they are > relevant for this draft as well? > > regards, > Nikos > > From nobody Wed May 20 06:10:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460561A1A07 for ; Wed, 20 May 2015 06:10: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 8r59VAln15qZ for ; Wed, 20 May 2015 06:10:41 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 CE99C1A19EF for ; Wed, 20 May 2015 06:10:40 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so149216972wic.0 for ; Wed, 20 May 2015 06:10:39 -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=9sdnf0tG2Pjw0bZ+QXgc/x+974aynyyPNUHVUcN8/Wg=; b=0wsYlWN6/0UdebW4Agh/LRfV2JNF5o2l8MfxZkI/2NQ7wpneUjZeONwnzVF9UBQN3U sjtULYpaD7u4WAmUAMJm7A4s07OIgRRio1q36NOPdwf8eH9KbIAW2A1puATyD9NUmgq4 ow8SyYXh0+3hRAUAd08H/P0lr+xR8YPSE1Ttcn+xzs3BzIYNWZ3OdiKKxXEb9FYequHu FaIGcIVbaHApYgWCZYO8tabWtkic09cCQgu3bIznb+Fk//vGCLiQz4wKBo9agtX5zqk9 iy+pVcHr0ppZF4qpwkNDzwTeRAt9xU4M+bC7BSHLxkKlzW7tVPptzXm+i71fE9SZgDJp pk8A== X-Received: by 10.180.103.231 with SMTP id fz7mr41394792wib.35.1432127439580; Wed, 20 May 2015 06:10:39 -0700 (PDT) Received: from [172.24.251.137] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id t17sm3442268wij.1.2015.05.20.06.10.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 06:10:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <1432120843.2926.0.camel@redhat.com> Date: Wed, 20 May 2015 16:10:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9F02C316-AA7E-4440-8727-3A62F7F83D9C@gmail.com> References: <3FCBCBD5-9295-4A8D-BD27-71377B6B8E7C@gmail.com> <567925460.1076064.1432105081320.JavaMail.zimbra@redhat.com> <555C33F6.4020402@cs.tcd.ie> <555C6B9D.2060302@gmail.com> <1432120843.2926.0.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 13:10:46 -0000 > On May 20, 2015, at 2:20 PM, Nikos Mavrogiannopoulos = wrote: >=20 > On Wed, 2015-05-20 at 14:10 +0300, Yaron Sheffer wrote: >> At ipsecme, we had a few incompatible changes between WG adoption of = our=20 >> own chacha draft, and WGLC. So I would recommend against early=20 >> registration altogether. >=20 > Could you summarize the changes done for ipsecme in case they are > relevant for this draft as well? Not much. The changes were mostly clarifications, examples, and fixing = the construction of AAD for Poly1305 input for both IPsec and IKE. We did have some TBDs in the draft over whether we would set the 32-bit = salt to zero or derive it from keying material (as for GCM). We decided = on the latter. That question is also open in this working group, at = least for TLS 1.2. Yoav From nobody Wed May 20 06:22:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FDF1A1A0B for ; Wed, 20 May 2015 06:22:12 -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 SXDVk3prBiDO for ; Wed, 20 May 2015 06:22:11 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.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 CE1CD1A1AA8 for ; Wed, 20 May 2015 06:22:06 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so149641603wic.1 for ; Wed, 20 May 2015 06:22:05 -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:from:date :message-id:subject:to:cc:content-type; bh=Xlo3A4EgYAWjlhFJKKtsUaSuZ+y4NtQlIOAFLhnziZU=; b=LYvqTqTt6q2ueLvICr83b43nMF7JhS3E78TzO922Hq/FsyB3x3315MJfv9ds1+NfOs N5NDDVdz1d11hWfanl93Ar6ppdSsa/Uoya8oc2W4nUpN8YWCAvuFWYeGQn/LzNh3xMhG j0IlOgkHH3LcVSUcfNuH9CIG3CIVa/AWlMyHsz5lI7blBC+hCvatEOnyqUeOOfP9Asb3 i8frF9nJ4Abh5vkmCQaC3S89eJmXUhYvVPklmeujMYB1kItd3u3/6LHkZF0D1ghou70Y KxCDiD7L8FvpDTRoph8MskwnX2jJJNNjEAao5RgPpVrdmKfmYJR0m3CnZTTDnxQ63iot IpbQ== X-Gm-Message-State: ALoCoQmizHYblL62I6VqnXEBKT2rCWVy3Pm/4LP1IDUpC//uzsZUynL611HvpEvl/1HM27neFKSe X-Received: by 10.180.73.176 with SMTP id m16mr157619wiv.68.1432128125608; Wed, 20 May 2015 06:22:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Wed, 20 May 2015 06:21:25 -0700 (PDT) In-Reply-To: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> From: Eric Rescorla Date: Wed, 20 May 2015 06:21:25 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=f46d043c7e5833370a05168350df Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 13:22:13 -0000 --f46d043c7e5833370a05168350df Content-Type: text/plain; charset=UTF-8 On Tue, May 19, 2015 at 11:43 PM, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- > > I am in favor of this draft. > > > > Prior to doing the code point assignment, however, we should resolve > > the question of the per-record nonce algorithm. The current draft uses > > an algorithm that is not consistent either with the algorithm we use for > > GCM or TLS 1.3. > > > > - TLS 1.2 GCM: 32-bit fixed salt || 64-bit explicit per-record IV > > - TLS 1.3: fixed mask XORed with the record sequence number > > - ChaCha: 32-bit fixed salt || record sequence number > > I think the chacha draft is consistent with the TLS 1.2 GCM draft. The TLS > 1.2 GCM draft allows as an option (MAY) to have "32-bit fixed salt || > record sequence number", > and in fact all implementations do that. So this draft simply ratifies that > approach and changes that requirement to MUST. Not just that. It also doesn't carry the RSN on the wire, which the GCM one does. -Ekr The approach in TLS 1.3 is a novel > one and I don't think it suits this draft. > > regards, > Nikos > --f46d043c7e5833370a05168350df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 19, 2015 at 11:43 PM, Nikos Mavrogiannopoulos <nmav@redhat.c= om> wrote:
----- Original Message -----
> I am in favor of this draft.
>
> Prior to doing the code point assignment, however, we should resolve > the question of the per-record nonce algorithm. The current draft uses=
> an algorithm that is not consistent either with the algorithm we use f= or
> GCM or TLS 1.3.
>
> - TLS 1.2 GCM: 32-bit fixed salt || 64-bit explicit per-record IV
> - TLS 1.3: fixed mask XORed with the record sequence number
> - ChaCha: 32-bit fixed salt || record sequence number

I think the chacha draft is consistent with the TLS 1.2 GCM draft. T= he TLS
1.2 GCM draft allows as an option (MAY) to have "32-bit fixed salt || = record sequence number",
and in fact all implementations do that. So this draft simply ratifies that=
approach and changes that requirement to MUST.

<= div>Not just that. It also doesn't carry the RSN on the wire, which the= GCM one does.

-Ekr

The approach in TLS 1.3 is a novel
one and I don't think it suits this draft.

regards,
Nikos

--f46d043c7e5833370a05168350df-- From nobody Wed May 20 07:06:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA771A701D for ; Wed, 20 May 2015 07:06:16 -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 GVzTRPKWry_N for ; Wed, 20 May 2015 07:06:14 -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 7D7421A7D83 for ; Wed, 20 May 2015 07:05:26 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so156269088wic.0 for ; Wed, 20 May 2015 07:05:25 -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=ZEEEsJxaZKkV7ImDCYK6JpQyjqTP3Q8TApvrpfvUFQE=; b=A0Ux9RvkeuQN2Dn263GYdZW/aFTaW53FMld26TUkEK4yJN4+vgL6rRYf4lZJ2xXQYO KJ5h5qNMFe+Qw/3PAxFsdS5WsUMf2F05lMtniZniks6UBiW0B9st6iCvgWiQjFcuw0gS w5jwXGHZE7UjgysvcgtPazUzulMvqyD4E/5Xgv1p/vhxW7D1Oq97YntqZXA0GU0LSDuq i+wG7cyGBODxe7mTHR5tLI1W+hJm4YihUhR6TCzTR4B8ZjazZ8YcyAYQYEnXHN4+y3ub NqAg/0k3SNdLMn6Z8CAJ2zequZEvatuuTzfwAhnl1ICOjB563Mi0sZbk3pfnjxmn8QtR Llag== MIME-Version: 1.0 X-Received: by 10.194.248.227 with SMTP id yp3mr187776wjc.32.1432130725186; Wed, 20 May 2015 07:05:25 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Wed, 20 May 2015 07:05:25 -0700 (PDT) Date: Wed, 20 May 2015 10:05:25 -0400 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 14:06:16 -0000 https://weakdh.org/ Transcript hashing will solve this problem. In the meantime, you want to turn off DH_EXPORT. There are also implications for false start. Chrome has already announced countermeasures. I'm pretty sure this won't be the last issue of this nature. Sincerely, Watson Ladd From nobody Wed May 20 07:49:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BF81A87BE for ; Wed, 20 May 2015 07:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, 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 L7ZxtGttnBVJ for ; Wed, 20 May 2015 07:49:06 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 0FFAF1A87B0 for ; Wed, 20 May 2015 07:49:06 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so55599916wgb.3 for ; Wed, 20 May 2015 07:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Hx0SDxdrM8cBAdwe/tm17IJmINt6E3juLKO5Bn+nq4U=; b=tbEcD84z2OYRANe0IF+cJhlQUGLzZ1hzWcKbI58ZinHsBcooUYnRWhx4OuIFidYRy7 bWjwaYr/kOK3xfv8yDNP5njFtupaBd1l2eGwTuKmqe6GyWFgkCZSLqfhMJ2WQiCyHYYP 8myMRHWpeoia1SsLrnmReQQ4LLv4iuQwR+zqI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Hx0SDxdrM8cBAdwe/tm17IJmINt6E3juLKO5Bn+nq4U=; b=kimOB7UlF0q6TPaJ42c9Z0wUZeiCEZCbojYTULtTXeHCiULidgWYgFCVNKQ6I2KB70 /hjiM9xNDGLTORPBWUQtd5V388MVu9wHyT0O98L1I1RuDZyJB2ruxEaQxidz1MumWgFa 1Bb8Q935LnN8QfzJuhNv2kD/EfeLXsRKAnzKa4EtMXiBX3R3EWQjfGmfvPp8DbxwCYWU M0/TqXwKyfk8dX2o5rCd+dgHFpK66bsVmMYaw7Y3lYMvjj7CvGj9WriU5yVcx0ng4uOJ L3irX/ioNO3lA7kZtScNt2FlWOxWo5nackST9yrusdiO0kFsAeazPgZ1ctUuP+e/ADuN fNLQ== X-Gm-Message-State: ALoCoQnFoQveJ+WvkQGh07te6F7NzcC9Yp7Wy+1nsf7KeIcthTkOL8R9sWfVGgBA9zpFqRU2jyIo X-Received: by 10.194.122.200 with SMTP id lu8mr64390222wjb.30.1432133344756; Wed, 20 May 2015 07:49:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.141.80 with HTTP; Wed, 20 May 2015 07:48:44 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Wed, 20 May 2015 09:48:44 -0500 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 14:49:07 -0000 On 20 May 2015 at 09:05, Watson Ladd wrote: > https://weakdh.org/ > > Transcript hashing will solve this problem. Will it? (Or at least, I'm not sure where you intend to include the transcript hash, in which case - maybe.) I think the issue is the same as the Section 4.4 here: https://www.schneier.com/paper-ssl-revised.pdf - the underlying cause being that the ephemeral parameters' signature doesn't include enough context. In Schneier's, the algorithm needed to be included (it still isn't, in TLS 1.2 - we just (hope) we have stricter checking on the data in implementations). In this one, the signature could be argued to be needed to go over the ciphersuite (to say "Don't use these parameters except with this ciphersuite"), maybe more data (to say "Only uses these parameters if you've sent me this transcript"), or even arguably no change at all: don't sign things you don't intend to use. (Not that that last one is good IMO.) If you mean hash the transcript into the master secret (e.g. the extended master secret draft) - I don't think that's a fix. The client will hash all of its handshake messages into its master secret - but the client is talking to _me_ the attacker. I copy-and-paste the server's ephemeral parameters, and the signature, but I can derive the same MS as the client and happily talk to the client, decrypting and passing the data back along to the server who I'm talking to in a different connection. -tom From nobody Wed May 20 07:59:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B5B1A8834 for ; Wed, 20 May 2015 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fENP9cVJbudZ for ; Wed, 20 May 2015 07:59:29 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEED41A882F for ; Wed, 20 May 2015 07:59:28 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 58C01699D4; Wed, 20 May 2015 17:59:26 +0300 (EEST) Date: Wed, 20 May 2015 17:59:26 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20150520145925.GA17676@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 14:59:34 -0000 On Wed, May 20, 2015 at 10:05:25AM -0400, Watson Ladd wrote: > https://weakdh.org/ > > Transcript hashing will solve this problem. AFAICT, extended_master_secret won't save you from this. The problem is screwed up server key PoP, and EMS will not fix that (TLS 1.3 does). Also, this is not the first attack arising from the way server key PoP is done... BTW: Client key PoP is not screwed, so attacker can't forward client certs... > In the meantime, you want to turn off DH_EXPORT. Only works on serverside... > There are also implications for false start. I have regarded using false start with non-named groups (and thus without key checks) as a bad idea. -Ilari From nobody Wed May 20 08:02:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9D11A883A for ; Wed, 20 May 2015 08:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgu87yGH4GCW for ; Wed, 20 May 2015 08:02:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9DB01A883E for ; Wed, 20 May 2015 08:02:53 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 46819AC7D2; Wed, 20 May 2015 15:02:53 +0000 (UTC) Received: from vpn-59-54.rdu2.redhat.com (vpn-59-54.rdu2.redhat.com [10.10.59.54]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4KF2okf009543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 May 2015 11:02:52 -0400 Message-ID: <1432134170.2926.9.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Wed, 20 May 2015 17:02:50 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:02:55 -0000 On Wed, 2015-05-20 at 10:05 -0400, Watson Ladd wrote: > https://weakdh.org/ > > Transcript hashing will solve this problem. In the meantime, you want > to turn off DH_EXPORT. The interesting thing is that there are no DHE_EXPORT ciphersuites. From nobody Wed May 20 08:14:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4CB1A87BD for ; Wed, 20 May 2015 08:14:00 -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 BjY0MO20D5cL for ; Wed, 20 May 2015 08:13:58 -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 0C3231A87BC for ; Wed, 20 May 2015 08:13:58 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so153120293wic.1 for ; Wed, 20 May 2015 08:13:56 -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 :message-id:references:to; bh=fBhLgiG2BouMOBHkXPvkcwevsSjHoRDla6NnsZa3ap4=; b=IQxtcLRqCZ/YizmQV4A7KNt9sILcGho3G7Xs52TjjsgnB9nMoJ54G/SVY2+uZz08kh 7AytAmwWHnu7MMBXgYP9tvslakBSCF1jiYzpCDkxGacDSZ8gb0FDWkiFMW3Gv1uU+de0 SWUcUqENTxCGxBWHKxmhUpVACH4kMnPfTSRBwphmu5MMzdhmdW54w5PjVV8KufuUCKv0 UZo1Gr+aLSsL5dr78hPoGONy8IoQivVMkts/OLTxCYr6QscQ+SnKgKd5ogLGNYbOt6sj Gv3gikT0r89beJEkycJKs7T+LB8aUytvztkXCK7x59Zo/ck+Xk3dSSCulsaflvRkIlx1 t8iQ== X-Received: by 10.180.188.100 with SMTP id fz4mr40259938wic.91.1432134836816; Wed, 20 May 2015 08:13:56 -0700 (PDT) Received: from [172.24.251.137] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id 9sm27317437wjr.11.2015.05.20.08.13.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 08:13:56 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_014F9BC8-EE1D-47C0-B18C-5F51D79A5DEE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Wed, 20 May 2015 18:13:52 +0300 Message-Id: <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> To: Eric Rescorla X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:14:00 -0000 --Apple-Mail=_014F9BC8-EE1D-47C0-B18C-5F51D79A5DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 20, 2015, at 4:21 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, May 19, 2015 at 11:43 PM, Nikos Mavrogiannopoulos = > wrote: > ----- Original Message ----- > > I am in favor of this draft. > > > > Prior to doing the code point assignment, however, we should resolve > > the question of the per-record nonce algorithm. The current draft = uses > > an algorithm that is not consistent either with the algorithm we use = for > > GCM or TLS 1.3. > > > > - TLS 1.2 GCM: 32-bit fixed salt || 64-bit explicit per-record IV > > - TLS 1.3: fixed mask XORed with the record sequence number > > - ChaCha: 32-bit fixed salt || record sequence number >=20 > I think the chacha draft is consistent with the TLS 1.2 GCM draft. The = TLS > 1.2 GCM draft allows as an option (MAY) to have "32-bit fixed salt || = record sequence number", > and in fact all implementations do that. So this draft simply ratifies = that > approach and changes that requirement to MUST. >=20 > Not just that. It also doesn't carry the RSN on the wire, which the = GCM one does. Yes, there=E2=80=99s that. I think that we should leave the record IV = (which this draft makes equal to the RSN, while RFC 5288 allows to be = chosen in any way) in the record for TLS 1.2.=20 In 1.3 we=E2=80=99re anyway planning to do it differently and omit the = IV, so we should do it there for both algorithms It=E2=80=99s a waste of 8 bytes, but that will give us one more reason = to implement 1.3, no? Yoav= --Apple-Mail=_014F9BC8-EE1D-47C0-B18C-5F51D79A5DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 20, 2015, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Tue, May 19, 2015 at 11:43 PM, Nikos = Mavrogiannopoulos <nmav@redhat.com> wrote:
-----= Original Message -----
> I am in favor of this = draft.
>
> Prior to doing the code = point assignment, however, we should resolve
> the = question of the per-record nonce algorithm. The current draft uses
> an algorithm that is not consistent either with the = algorithm we use for
> GCM or TLS 1.3.
>
> - TLS 1.2 GCM: 32-bit fixed salt || = 64-bit explicit per-record IV
> - TLS 1.3: fixed mask = XORed with the record sequence number
> - ChaCha: = 32-bit fixed salt || record sequence number

I think the chacha draft is consistent with the TLS = 1.2 GCM draft. The TLS
1.2 GCM draft allows as an option = (MAY) to have "32-bit fixed salt || record sequence number",
and in fact all implementations do that. So this draft simply = ratifies that
approach and changes that requirement to = MUST.

Not= just that. It also doesn't carry the RSN on the wire, which the GCM one = does.

Yes, there=E2=80=99s that. I think that we should = leave the record IV (which this draft makes equal to the RSN, while RFC = 5288 allows to be chosen in any way)  in the record for TLS = 1.2. 
In 1.3 we=E2=80=99re anyway planning to do it = differently and omit the IV, so we should do it there for both = algorithms
It=E2=80=99s a waste of 8 bytes, but that will give us = one more reason to implement 1.3, no?

Yoav
= --Apple-Mail=_014F9BC8-EE1D-47C0-B18C-5F51D79A5DEE-- From nobody Wed May 20 08:15:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4141A8771 for ; Wed, 20 May 2015 08:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 wqeslDjgEFaa for ; Wed, 20 May 2015 08:15:33 -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 C73AA1A8755 for ; Wed, 20 May 2015 08:15:32 -0700 (PDT) Received: by lagv1 with SMTP id v1so79213465lag.3 for ; Wed, 20 May 2015 08:15:31 -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:content-transfer-encoding; bh=tvhgvswzrFDrwtf2NpSMYbTVCNTil3SdLM1bFdwHvUQ=; b=i+fw8EHexZvIMF6Y4O8qNs/QmbIS9a5jn+ek+vuSkDVUO9M4lmU4cSLBqAgne9TxJj JcftAw7pCZBeyAQYQDhDdoH0qKP5ompzELdt9FxEoBnP6xkY5AnPAt6+K0leQaBjpIIQ zHAq9Hn0if0YNlTtTnj7wOwNZGOMW5+7M36fRO8X0YvGlhhqSW86vhWRUs6wkHiZ0heP x9zuPHIXGLqemoC0EETDDYiEMUv900gO8UPtPcRkyLanYcfAD3bUqf2M4xQYoXHE7axF YFrSBItexjSyg1Cz//YbACDSoKM8obQsL/oT6HNqKfcSEmxumLcd3tmbKgklb74tij+a Bs6w== MIME-Version: 1.0 X-Received: by 10.112.242.40 with SMTP id wn8mr18082107lbc.57.1432134931208; Wed, 20 May 2015 08:15:31 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.89.69 with HTTP; Wed, 20 May 2015 08:15:31 -0700 (PDT) In-Reply-To: <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> Date: Wed, 20 May 2015 08:15:31 -0700 X-Google-Sender-Auth: thwphdLym26bStbUNJPX_1LsNCc Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:15:39 -0000 On Wed, May 20, 2015 at 8:13 AM, Yoav Nir wrote: > Yes, there=E2=80=99s that. I think that we should leave the record IV (wh= ich this > draft makes equal to the RSN, while RFC 5288 allows to be chosen in any w= ay) > in the record for TLS 1.2. > In 1.3 we=E2=80=99re anyway planning to do it differently and omit the IV= , so we > should do it there for both algorithms > It=E2=80=99s a waste of 8 bytes, but that will give us one more reason to= implement > 1.3, no? Nope, not going waste 8 bytes per record for no reason. The world has wasted enough network bandwidth on that in AES-GCM already. Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed May 20 08:20:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597B61A87BF for ; Wed, 20 May 2015 08:20: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 XrYwdDmvydnD for ; Wed, 20 May 2015 08:20:04 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.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 E76771A8830 for ; Wed, 20 May 2015 08:20:00 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so153309046wic.1 for ; Wed, 20 May 2015 08:19:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=KCPjctPjAGQ4rJhhteHFkqezdCWjAqOMHVcd9NmYjLA=; b=AdCyqeA7yeb/KLTMvfieE9EQeJdscD2u1aCyfFYRhs3zZT7HkJQPvCNzeWvQARukLp 865dOMKf6NpkqYdhBnvQBg+JZwnYAMOoZB+DgmKAFCu/GCwB8Gf15+QvN/4Wv/sIVn2A eeaUWMVmW0amze+eQv09Ma970crmvMk9zXx10GsybzucKdNhM8QjpNau42U6FkkLHTZU z1c/opmfrdcSo6SAYDGhDUifk00v+TmJjrxURngfdOEq6dKG9gsIVdmH0WWW0nXEVAzX C14F8Fha3TBT8AWLOd26iOJE26pnUBywaFwhjO2nStZfAuRMPkHJ37SlnkfF4JeJeruC MBBw== X-Gm-Message-State: ALoCoQkcec3bdqe0kyHwHerwMuR3omgp26XLYPvIVuBGLAUtLsLzQz7ShKaBapr5gGZ86VcZnKAl X-Received: by 10.180.221.9 with SMTP id qa9mr20595222wic.52.1432135199217; Wed, 20 May 2015 08:19:59 -0700 (PDT) Received: from [172.16.1.29] ([188.21.236.102]) by mx.google.com with ESMTPSA id k2sm3993888wif.3.2015.05.20.08.19.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 08:19:57 -0700 (PDT) Message-ID: <555CA61C.5090405@azet.org> Date: Wed, 20 May 2015 17:19:56 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <1432134170.2926.9.camel@redhat.com> In-Reply-To: <1432134170.2926.9.camel@redhat.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0B02A49BB4B9BB7F35DD917B" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:20:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0B02A49BB4B9BB7F35DD917B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Nikos Mavrogiannopoulos wrote: > On Wed, 2015-05-20 at 10:05 -0400, Watson Ladd wrote: >> https://weakdh.org/ >> >> Transcript hashing will solve this problem. In the meantime, you want >> to turn off DH_EXPORT.=20 >=20 > The interesting thing is that there are no DHE_EXPORT ciphersuites. >=20 I was also wondering about that. IANA has no entries for DHE_EXPORT*. As far as I can tell there isn't even information on the searchable web on that. If you google DHE_EXPORT it'll point you to this very paper and that's about it. Aaron --------------enig0B02A49BB4B9BB7F35DD917B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVXKYcAAoJEOTbZJL9ubXVVBIP/1n5xOq9S242jX5B3HcIwlyU Lv7u5iUReJlpKryl+RD5/SbE6knQA2oudilnEN1kyzvCW224Hlsxr9X+VVD+1RA9 9J4EZm53U9yN9FWZ4VcEz4nBZ6VueOZtndudBXGCp/Am7yAdR65lntqwfRgLstgF LFnqmHZloqKmI2DxxDuAZKZ94zpenILISlv8g885IsNZxSnWp6MAxtkTbA41QCZz I6Sep4i9hs/+c6VPwyNAeH7dy80rye6TBpXgH4OyMPYQMtRqnTW7BQe4aSLCYjmZ Y05ufQzti4j0CP/Zc8Q/PUhOAeI0ePWeNI4nk9FmBefH9dWVzwVxKa0ePeCSDZq6 4h2XTeHc6dn/YFUWbDsdQmaZaJ3ySJ6o5RQi9+Pl20pvHqsdJK0X9Jj6HtY++qeL 6jRW+GRfuw2CrL0CLekRN9QCWsaw05kjyoorCjbjoGtbzEG8sA1qVSppMtGF3Hmi jq6aBri3UW+bbomTXaBCFP3/7p2t2y5U0Z0t9hBEiZA0h+h2COHgRiGki/vwClsn horw6sCfsyX+jiD8SCeBBiRfQRTkqOJRZc9GO+A/BzGsa/Y2qR8BX9K/Ly/I4ggs aF6EugdbyRrSi8W4L3DsXxVz51KbLqYX1CtaBhBrIU1k2Hxqq6fKY9W2Hvp/5dw8 3vz4poOscTFH6OaSHcUn =CqKO -----END PGP SIGNATURE----- --------------enig0B02A49BB4B9BB7F35DD917B-- From nobody Wed May 20 08:30:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F17E1A888F for ; Wed, 20 May 2015 08:30:40 -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 R6-d-DuFpESt for ; Wed, 20 May 2015 08:30:38 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (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 204D81A87BF for ; Wed, 20 May 2015 08:30:37 -0700 (PDT) Received: by wghq2 with SMTP id q2so56928217wgh.1 for ; Wed, 20 May 2015 08:30:36 -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:from:date :message-id:subject:to:cc:content-type; bh=zWSU/Jc+echgiKinhX/N4k+v9EFT8RvmYaOMgSY30ac=; b=UKQbHddvhOQbySeGHoGcCY6dweyC2/72mFdSVQcV1MTdjxUrPAd6ij4NkpqPfRKyey FUzZw0Wezy1VQfgirIYHOnc7JiAUuyl29c4xQB9FhUhRR8Rm2AIm+CYijJyO+TzhF6Gn 8V9wn8XAL3YUzu6b0XaSTX/3tDixmVdBTu4IwQTr8+YNz0UR8Afae0VU3BG+syU+vz0/ JV88YAe4SHRbpRoRfYmX+2dy1Om98DeJjYb7NfKt9BmhI91a7INY6kwbYj2l1oKjJdvU lO86vh272Wjw6cFPBvV6bCFmo0VRrGzsaY3+7KuPZiZsSnDQYu3yn7pl4jwuJwK+mt3d MFMg== X-Gm-Message-State: ALoCoQnqt6tIFYKKl2EXYOr8jvcGK2aTt1qcw2plhuzSlOq2oIx/Uu0A9BUeufxTPxkAiiMqer3C X-Received: by 10.194.133.73 with SMTP id pa9mr45069330wjb.148.1432135836758; Wed, 20 May 2015 08:30:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Wed, 20 May 2015 08:29:56 -0700 (PDT) In-Reply-To: References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> From: Eric Rescorla Date: Wed, 20 May 2015 08:29:56 -0700 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=089e011771a9d2051f0516851bd9 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:30:40 -0000 --089e011771a9d2051f0516851bd9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 20, 2015 at 8:15 AM, Adam Langley wrote: > On Wed, May 20, 2015 at 8:13 AM, Yoav Nir wrote: > > Yes, there=E2=80=99s that. I think that we should leave the record IV (= which this > > draft makes equal to the RSN, while RFC 5288 allows to be chosen in any > way) > > in the record for TLS 1.2. > > In 1.3 we=E2=80=99re anyway planning to do it differently and omit the = IV, so we > > should do it there for both algorithms > > It=E2=80=99s a waste of 8 bytes, but that will give us one more reason = to > implement > > 1.3, no? > > Nope, not going waste 8 bytes per record for no reason. The world has > wasted enough network bandwidth on that in AES-GCM already. > What would you think of just adopting the 1.3 approach then? I don't have a strong opinion on this, but it seems a pity to have three separate mechanisms. -Ekr --089e011771a9d2051f0516851bd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 20, 2015 at 8:15 AM, Adam Langley <agl@imperialviolet= .org> wrote:
On Wed, May 20, 2015 at 8:13 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> Yes, there=E2=80=99s that. I think that we should leave the record IV = (which this
> draft makes equal to the RSN, while RFC 5288 allows to be chosen in an= y way)
> in the record for TLS 1.2.
> In 1.3 we=E2=80=99re anyway planning to do it differently and omit the= IV, so we
> should do it there for both algorithms
> It=E2=80=99s a waste of 8 bytes, but that will give us one more reason= to implement
> 1.3, no?

Nope, not going waste 8 bytes per record for no reason. The world ha= s
wasted enough network bandwidth on that in AES-GCM already.

What would you think of just adopting the 1.3 approach= then?

I don't have a strong opinion on this, = but it seems a pity to have three
separate mechanisms.
=
-Ekr


--089e011771a9d2051f0516851bd9-- From nobody Wed May 20 08:33:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AC81A8897 for ; Wed, 20 May 2015 08:33:09 -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 h8JumU8RK_w4 for ; Wed, 20 May 2015 08:33:07 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7896F1A87BB for ; Wed, 20 May 2015 08:33:07 -0700 (PDT) Received: by lagr1 with SMTP id r1so79324975lag.0 for ; Wed, 20 May 2015 08:33:05 -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=Q3/WJ9QvKOFn0BfZl/hs7ss3WBoZs8BgujL5W8HAyc0=; b=fwTymhg+DnDCC1W0mwGpDIcIfxC6FWTZJbb0fQfPlc+/yXzm6M3CWP52vsv/eAszvG Z5nxMV5Vjq3NVbpjOMwhG6ff+RBdeTfCRZtNNJSj4vEIta00HdQ+H6EVq8RWozWzgfXv 4wPwVecf45p8WglzEKalXFxbZ7DY3uHQ6Sn4HfRITilyScKOOSyk3QeSq/YjwFjHoAaO 9uXAtuzzelNRTd38YIDIyuwmmNFHdda3JdjBCGU2M72XuDP4DCyL0Bea+mq/j+B6mG78 eWFUIkwpEhV7XLoxOxB/hVtLSNBG9eKSmOKzhGnbkCAuuVVvNIq4l+xFs9voIlaV9B7y o1lQ== MIME-Version: 1.0 X-Received: by 10.152.29.6 with SMTP id f6mr1522371lah.85.1432135985928; Wed, 20 May 2015 08:33:05 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.89.69 with HTTP; Wed, 20 May 2015 08:33:05 -0700 (PDT) In-Reply-To: References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> Date: Wed, 20 May 2015 08:33:05 -0700 X-Google-Sender-Auth: 0FYQ5yPYGVHv9cIu247RxSc3xJA Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:33:09 -0000 On Wed, May 20, 2015 at 8:29 AM, Eric Rescorla wrote: > What would you think of just adopting the 1.3 approach then? Sure. Although I half suspect that the final TLS might change again and we would still end up with three modes :) But that's not a big deal. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed May 20 08:36:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5809B1A8840 for ; Wed, 20 May 2015 08:36: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 WuKMEwkNI1x6 for ; Wed, 20 May 2015 08:36:05 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.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 CCB9A1A883F for ; Wed, 20 May 2015 08:36:04 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so159485580wic.0 for ; Wed, 20 May 2015 08:36: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:from:date :message-id:subject:to:cc:content-type; bh=SULuD1nFC+4BhaXE/4MqkQiF10kOs5JhIWDKfr9AQQk=; b=fd1j0Yx3TV8VwboGq9CY7zcSHEyHs20V50igIaCAzN1+35AEHq+xeQmVpPOYGo1VI5 rfKTz6z90arj0/siL723K4W85s2X4n7OvuibpT4+JwazzmnHKkA9pvELYUlc7WBK6Yx+ KypiyytwhC1OX+XMjvVkaxCDu23SftRHL7CIkQU1VYy6IOllfvDarwrwI6jOnFuScu25 Rawv1GZWGRieayJ7FMUy1xstsw6U9ommP4YFOF9fLaAIUZLtoHkg7okcNHrpwF9q33/D GPH7dVTkS1FjIIOV28AntPEUHx/o0FMM209CC0Sjb0fZsFH8ekkfeMKlJZQVL9+2jtBi qFtg== X-Gm-Message-State: ALoCoQmPRra24t4bIrX8wPbpt6I4kPiwu3GY2yZSMQd2EWJrWyi5JfE7HrLjt7T6V0yQr7zTt3NM X-Received: by 10.180.212.106 with SMTP id nj10mr43542678wic.53.1432136163621; Wed, 20 May 2015 08:36:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Wed, 20 May 2015 08:35:22 -0700 (PDT) In-Reply-To: References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> From: Eric Rescorla Date: Wed, 20 May 2015 08:35:22 -0700 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=001a11c329484d901b0516852f6b Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:36:06 -0000 --001a11c329484d901b0516852f6b Content-Type: text/plain; charset=UTF-8 On Wed, May 20, 2015 at 8:33 AM, Adam Langley wrote: > On Wed, May 20, 2015 at 8:29 AM, Eric Rescorla wrote: > > What would you think of just adopting the 1.3 approach then? > > Sure. Although I half suspect half suspect? optimist! that the final TLS might change again > and we would still end up with three modes :) But that's not a big > deal. It will mean that we need a different set of code points than the current ones, right? -Ekr > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > --001a11c329484d901b0516852f6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 20, 2015 at 8:33 AM, Adam Langley <agl@imperialviolet= .org> wrote:
On Wed, May 20, 2015 at 8:29 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> What would you think of just adopting the 1.3 approach then?

Sure. Although I half suspect

half s= uspect? optimist!


that the final TLS might change again
and we would still end up with three modes :) But that's not a big
deal.

It will mean that we need a different= set of code points than the current
ones, right?

<= /div>
-Ekr
=C2=A0

--001a11c329484d901b0516852f6b-- From nobody Wed May 20 08:48:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424111A885C for ; Wed, 20 May 2015 08:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JWTJ9u_JtgM for ; Wed, 20 May 2015 08:48:14 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (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 81BFF1A891C for ; Wed, 20 May 2015 08:47:57 -0700 (PDT) Received: by qget53 with SMTP id t53so25511972qge.3 for ; Wed, 20 May 2015 08:47:56 -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=uPojY/wJHbHnm50rI9ENdS0ChU8fAwy+7D9VGY4BZQQ=; b=KrhKONuD8L6uMtnXOb0EfB0urkQ3LpcsY6FkliO66DTsKUB/glZrMcHZxUAOgk4ly3 iDRwD4zm6H+5uQDmg410yn5v07Wwp4gPioSb9W1YdKTxEDBDwnbm9IDKkTbLnJD2eQng nxwEGQJ/lx78nEHS8MAqNcMe2qU8Bkm98BPAlL2Eq4q7GRGOzIFhKF+VuKjE3+oqs7WP a+Ixinmk8qPDmpx0PiqGTCrzu0fQ59Mah7mSCbY0TOg0UoVHySMOFQdoiwIldll3JiV2 jxHDu/FxYoVvKP/llcZFOVwFKVzE30lBMR4A3HUVMo9LlTnqH0ziiz63R50V55muz7mn +09w== X-Gm-Message-State: ALoCoQnH4pwvPoUxHSr6zS9HT+WRE9mn+5mYAjNjndlGDKo86gu19tIj9pt3+P65ogFTL/VeNKpu MIME-Version: 1.0 X-Received: by 10.55.33.30 with SMTP id h30mr7609579qkh.87.1432136875692; Wed, 20 May 2015 08:47:55 -0700 (PDT) Received: by 10.96.161.169 with HTTP; Wed, 20 May 2015 08:47:55 -0700 (PDT) Date: Wed, 20 May 2015 08:47:55 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114055a8bee86b05168559d6 Archived-At: Subject: [TLS] Call for WG adoption draft-josefsson-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:48:16 -0000 --001a114055a8bee86b05168559d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is the WG call for adoption of: https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt This draft specifies the use of Curve25519 for ephemeral key exchange in the TLS and DTLS. This draft serves as the starting point (it=E2=80=99s ex= pired and needs to be updated in light of http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/). If you object to the adoption of this draft, please let us know why by 20150602. Note: We=E2=80=99re not doing an early code point assignment for this draft= , because it clearly needs to resurrected and tweaked. Once that happens, there=E2=80=99s nothing stopping a request from the authors for an early co= de point assignment. Thanks, J/S --001a114055a8bee86b05168559d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is the WG call for ado= ption of:

<= a href=3D"https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06= .txt" target=3D"_blank" style=3D"font-size:13px">https://www.ietf.org/archi= ve/id/draft-josefsson-tls-curve25519-06.txt

This draft spe= cifies the use of Curve25519 for ephemeral key exchange in the TLS and DTLS= .=C2=A0 This draft serves as the starting point (it=E2=80=99s expired and n= eeds to be updated in light of=C2=A0http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/).=C2=A0 If you object to the adoption of this draft, p= lease let us know why by 20150602.

Note: We=E2=80=99re = not doing an early code point assignment for this draft, because it clearly= needs to resurrected and tweaked.=C2=A0 Once that happens, there=E2=80=99s= nothing stopping a request from the authors for an early code point assign= ment.

Thanks,

J/S
--001a114055a8bee86b05168559d6-- From nobody Wed May 20 08:51:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3061A88C5 for ; Wed, 20 May 2015 08:51:13 -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 1OagPD_0z0D2 for ; Wed, 20 May 2015 08:51:12 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.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 36F5B1A88AE for ; Wed, 20 May 2015 08:51:02 -0700 (PDT) Received: by wichy4 with SMTP id hy4so65098589wic.1 for ; Wed, 20 May 2015 08:51:01 -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:from:date :message-id:subject:to:cc:content-type; bh=LVL5A4nwZEQVxWJRscJ3J5h3DGTCBEBd+E4To6Lt220=; b=Ij5ZtzNOqq79MarYgZvFHEXTC8M/YIvmGkXIZgZxy/6LEmki49Jxiw1a6MjRlPV7DS FBrHaL/1HeYCVHG7uq16NEMvlAc6pzDOowCYPwOvZGfWc5JGLjHpUQMsgso1u4su+gVd Dt5kM4fp+MNBlrxsL8GSWYKKJEjjVH92m2upxvjyVJvK8tr6BbpC9v80YiAZFGTm2ME+ QG34vJDFtbdjl2AYPuPSR5l92EDgHiNPpyQKK2ZmAhaYYbeBV+5g/akld/dZq2LD5GFM ANK87S+4HK/w+WxOqfGnpUjN6+SfwgWpB+mwZ/gEXZZfNcKh6DpSAfGJ+SlEwQDQM6TT W6yQ== X-Gm-Message-State: ALoCoQntgmRqn//QjLWarEWquSwqYdu9QSlrr4jzJcrVHxqDGygFzNiVlNYI+rPLU4xAMzsk1lw2 X-Received: by 10.194.79.225 with SMTP id m1mr883054wjx.8.1432137060936; Wed, 20 May 2015 08:51:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Wed, 20 May 2015 08:50:20 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 20 May 2015 08:50:20 -0700 Message-ID: To: Joseph Salowey Content-Type: multipart/alternative; boundary=047d7b10c903c9835c0516856430 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:51:13 -0000 --047d7b10c903c9835c0516856430 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am in favor of adopting this draft. -Ekr On Wed, May 20, 2015 at 8:47 AM, Joseph Salowey wrote: > This is the WG call for adoption of: > > https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt > > This draft specifies the use of Curve25519 for ephemeral key exchange in > the TLS and DTLS. This draft serves as the starting point (it=E2=80=99s = expired > and needs to be updated in light of > http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/). If you object > to the adoption of this draft, please let us know why by 20150602. > > Note: We=E2=80=99re not doing an early code point assignment for this dra= ft, > because it clearly needs to resurrected and tweaked. Once that happens, > there=E2=80=99s nothing stopping a request from the authors for an early = code point > assignment. > > Thanks, > > J/S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --047d7b10c903c9835c0516856430 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am in favor of adopting this draft.

-= Ekr


On Wed, May 20, 2015 at 8:47 AM, Joseph Salowey <joe@salowey.ne= t> wrote:
= This is the WG call for adoption of:<= br style=3D"font-size:13px">
https://www.ietf.org/archive/id/draft-josef= sson-tls-curve25519-06.txt

This draft specifies the use of= Curve25519 for ephemeral key exchange in the TLS and DTLS.=C2=A0 This draf= t serves as the starting point (it=E2=80=99s expired and needs to be update= d in light of=C2=A0http://datatr= acker.ietf.org/doc/draft-irtf-cfrg-curves/).=C2=A0 If you object to the adoption of this draft, please let us know = why by 20150602.

Note: We=E2=80=99re not doing an early= code point assignment for this draft, because it clearly needs to resurrec= ted and tweaked.=C2=A0 Once that happens, there=E2=80=99s nothing stopping = a request from the authors for an early code point assignment.

Thanks,

J/S

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--047d7b10c903c9835c0516856430-- From nobody Wed May 20 08:56:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7D41A88C2 for ; Wed, 20 May 2015 08:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG1LCX8LMkym for ; Wed, 20 May 2015 08:56:26 -0700 (PDT) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869A91A88A9 for ; Wed, 20 May 2015 08:56:26 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t4KFuQoI010793; Wed, 20 May 2015 11:56:26 -0400 Date: Wed, 20 May 2015 11:56:25 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Eric Rescorla Message-ID: <86328675.1427913.1432137385798.JavaMail.zimbra@redhat.com> In-Reply-To: References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [94.112.138.148, 10.5.101.181] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls Thread-Index: Inn4GZ1VOLDelCt8YTK2v3pYBScYvQ== Archived-At: Cc: Adam Langley , IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:56:27 -0000 ----- Original Message ----- > What would you think of just adopting the 1.3 approach then? > I don't have a strong opinion on this, but it seems a pity to have three > separate mechanisms. I don't really see it as a separate mechanism, it just omits the bytes which are redundant. The TLS 1.3 is a separate mechanism, and TLS 1.3 is not final yet. While I'd prefer to see the draft published than not, I wouldn't like to use an experimental mechanism, and my preference would be to use the current mechanism without the redundant bytes. From nobody Wed May 20 08:57:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9731A88C2 for ; Wed, 20 May 2015 08:57:55 -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_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7Zgk1T4n5Or for ; Wed, 20 May 2015 08:57:53 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (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 C07381A88BD for ; Wed, 20 May 2015 08:57:53 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4KFvpSE003095; Wed, 20 May 2015 11:57:51 -0400 Date: Wed, 20 May 2015 11:57:51 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Aaron Zauner Message-ID: <1715199014.1428711.1432137471073.JavaMail.zimbra@redhat.com> In-Reply-To: <555CA61C.5090405@azet.org> References: <1432134170.2926.9.camel@redhat.com> <555CA61C.5090405@azet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [94.112.138.148, 10.5.101.181] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: Another IRINA bug in TLS Thread-Index: sY+e7/3MdGObvz+1IfCCZ3xtRBoLqg== Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:57:55 -0000 ----- Original Message ----- > Hi, > Nikos Mavrogiannopoulos wrote: > > On Wed, 2015-05-20 at 10:05 -0400, Watson Ladd wrote: > >> https://weakdh.org/ > >> > >> Transcript hashing will solve this problem. In the meantime, you want > >> to turn off DH_EXPORT. > > The interesting thing is that there are no DHE_EXPORT ciphersuites. > I was also wondering about that. IANA has no entries for DHE_EXPORT*. As > far as I can tell there isn't even information on the searchable web on > that. If you google DHE_EXPORT it'll point you to this very paper and > that's about it. They are most probably using sloppy language and mean the DHE ciphersuites with parameters of 512 bits or less. regards, Nikos From nobody Wed May 20 09:03:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E353E1A892A for ; Wed, 20 May 2015 09:03:33 -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 3gkbIYMXM1jz for ; Wed, 20 May 2015 09:03:27 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.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 E8C2D1A892E for ; Wed, 20 May 2015 09:03:26 -0700 (PDT) Received: by wizk4 with SMTP id k4so160694616wiz.1 for ; Wed, 20 May 2015 09:03:25 -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:from:date :message-id:subject:to:cc:content-type; bh=EQx/D/wftzhMBWMm5aJsJE4t9Mdb7z4mv+gFfM0O9cI=; b=S+UeVzzKx/JH3lmJepzfCZ7XD/72YYcicGnhvHJYnaiH4FLcQOhLHIhOOlDsLs1FN9 C1EFGMAvXVXG2SVb+UO/H5/Phou3DoBmHJ9ggbdef6rypysk14z38EUltno7cmduXGzC tpbklG2Xy5oORdcrOd3um0ir473MCrwzQENoARsLwwIOT8XoX2vxrmRmasNzjcSqwZFX SEuwNpZ+DBUwlBAIDQo7kKv8d27MZ4YNeCLLHOPoDLHBYnOGMaz7CkNkzFG02Ip6zcdh 66fS4Z+pjtUd5gernJ3s9hIEs+Q7S0IOFizYUhj+N/UOs2pSd0XMrI0FthAvdEuTL7HY eykw== X-Gm-Message-State: ALoCoQnliEOJvl195ymtqLe2ATFYj8Lf0xgO/ag0SrD6f8Do0bhje2vyEN52Jgrt0p2e1Z7IkeRY X-Received: by 10.194.59.79 with SMTP id x15mr64409172wjq.81.1432137805707; Wed, 20 May 2015 09:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Wed, 20 May 2015 09:02:45 -0700 (PDT) In-Reply-To: <86328675.1427913.1432137385798.JavaMail.zimbra@redhat.com> References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> <86328675.1427913.1432137385798.JavaMail.zimbra@redhat.com> From: Eric Rescorla Date: Wed, 20 May 2015 09:02:45 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=047d7b8737ae2dd25a051685918f Archived-At: Cc: Adam Langley , IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:03:34 -0000 --047d7b8737ae2dd25a051685918f Content-Type: text/plain; charset=UTF-8 On Wed, May 20, 2015 at 8:56 AM, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- > > What would you think of just adopting the 1.3 approach then? > > I don't have a strong opinion on this, but it seems a pity to have three > > separate mechanisms. > > I don't really see it as a separate mechanism, it just omits the bytes > which > are redundant. Well, it's separate in the sense that you can't just swap out the GCM for ChaCha alg-ids. As I said, I don't feel strongly about this, but I do feel strongly that we should decide this before doing the code point allocation (it's not an obstacle to accepting the draft), and since Yoav has raised the point about consistency, we should probably address it now. -Ekr > The TLS 1.3 is a separate mechanism, and TLS 1.3 is not final > yet. While I'd prefer to see the draft published than not, I wouldn't like > to > use an experimental mechanism, and my preference would be to use the > current > mechanism without the redundant bytes. > > --047d7b8737ae2dd25a051685918f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 20, 2015 at 8:56 AM, Nikos Mavrogiannopoulos <nmav@redhat.co= m> wrote:
= ----- Original Message -----
> What would you think of just adopting the 1.3 approach then?
> I don't have a strong opinion on this, but it seems a pity to have= three
> separate mechanisms.

I don't really see it as a separate mechanism, it just omits the= bytes which
are redundant.

Well, it's separate in = the sense that you can't just swap out the GCM for ChaCha
alg= -ids.

As I said, I don't feel strongly about t= his, but I do feel strongly that we should
decide this before doi= ng the code point allocation (it's not an obstacle to
accepti= ng the draft), and since Yoav has raised the point about consistency,
=
we should probably address it now.

-Ekr
=


=C2=A0
The TLS 1.3 is a separate mechanism, and TLS 1.3 is not final
yet. While I'd prefer to see the draft published than not, I wouldn'= ;t like to
use an experimental mechanism, and my preference would be to use the curren= t
mechanism without the redundant bytes.


--047d7b8737ae2dd25a051685918f-- From nobody Wed May 20 09:09:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6561A8958 for ; Wed, 20 May 2015 09:09:14 -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 z6hrkSvNMHPk for ; Wed, 20 May 2015 09:09:13 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::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 9F61D1A88E6 for ; Wed, 20 May 2015 09:09:12 -0700 (PDT) Received: by lagr1 with SMTP id r1so80898501lag.0 for ; Wed, 20 May 2015 09:09:11 -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=44hM/UkubB1bnhNgfeAANstJ0nsqmNaV4lU0KGjztqo=; b=Au9bNjQZpZFyKxHBRzo/lqIGNLBgKhxVCQHM2GJE8lXFrMg31jCC0NhMBSSChFtSh2 QslADO48VpjVQylI97GDfGTgCOhaPQk1wpVICmiK52eD3XZYzcCM3jTa2xBhsZmQMO0Y Y8dabvydiiEOTGbjadwVXMmWDuDQQEME29vl60fNA3e4XAvfIECz95g604fZL8r4EEc1 EF8Qaa+MwZ11gkEL+lptIyRgMcFDf1UOonZbbwJIOm9s8ujLpqm9TMXv/oPGs6odWvzS 2wPrdY8ie7vAi0YLnWZ4V9yF6H36Bo/Ji3lPj/VCnedDNlurSnZKo7cTv+LVhbtSMgFU GV/g== MIME-Version: 1.0 X-Received: by 10.112.16.167 with SMTP id h7mr27014060lbd.124.1432138151140; Wed, 20 May 2015 09:09:11 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.89.69 with HTTP; Wed, 20 May 2015 09:09:11 -0700 (PDT) In-Reply-To: References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> Date: Wed, 20 May 2015 09:09:11 -0700 X-Google-Sender-Auth: o6Y8xreEsp4UwAfxrYE7I1bv7Zo Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:09:14 -0000 On Wed, May 20, 2015 at 8:35 AM, Eric Rescorla wrote: > It will mean that we need a different set of code points than the current > ones, right? Not quite sure that I follow you here: We will need a different set of code points than the ones currently squatted for ChaCha (0xcc13 etc), but the draft already specifies that. (And the AEAD construction is slightly different.) However, if we specified the current TLS 1.3 nonce scheme for ChaCha in TLS 1.2, but TLS 1.3 changed before it was final, I don't think the code points would need to change again. It would just be the case that the code points, when used in TLS 1.3, use whatever TLS 1.3 ends up doing and, in previous versions, they use what TLS 1.3 does now. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed May 20 09:11:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9FF1A88D8 for ; Wed, 20 May 2015 09:11:42 -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 wSKi1DijsMRY for ; Wed, 20 May 2015 09:11:40 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 84AFD1A87E9 for ; Wed, 20 May 2015 09:11:40 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B510B285B6; Wed, 20 May 2015 16:11:39 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 9BA462867C; Wed, 20 May 2015 16:11:39 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 8126D2029; Wed, 20 May 2015 16:11:39 +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; Wed, 20 May 2015 11:11: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; Wed, 20 May 2015 11:11:38 -0500 From: "Salz, Rich" To: Adam Langley , Eric Rescorla Thread-Topic: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls Thread-Index: AQHQkshAhGeeQykKlUuaRwhXbkB8uZ2FLf+AgAAfawCAAAB2gIAABAcAgAAA4YCAAACkAIAACXKA//+sqHA= Date: Wed, 20 May 2015 16:11:38 +0000 Message-ID: <452813fc788f48f6adde836dde966f9c@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> 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.146.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:11:42 -0000 > would need to change again. It would just be the case that the code point= s, > when used in TLS 1.3, use whatever TLS 1.3 ends up doing and, in previous > versions, they use what TLS 1.3 does now. Have we done that before, had codepoints whose meaning depended on verson? From nobody Wed May 20 09:13:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507CF1A8930 for ; Wed, 20 May 2015 09:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 FTRhZ6KlNs6m for ; Wed, 20 May 2015 09:13:52 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.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 C275B1A892F for ; Wed, 20 May 2015 09:13:51 -0700 (PDT) Received: by wgjc11 with SMTP id c11so58254253wgj.0 for ; Wed, 20 May 2015 09:13:50 -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:from:date :message-id:subject:to:cc:content-type; bh=zyp7kTIZ9Rk//MmN5XIXhYsBWOVl+u8yGiUEOTQ88Rs=; b=QcpWblNxESJgyiEsF+2VluXRKhqAmz/2FC7KoAxRmgp7McmUnKN1jHmK24mhTNy9D1 BHuYuTX/iv9y9uVvOt8pQHRKWo09AkTqkn35F4VrLqVeC+WsKxlQLnaom3z6UQGVgnWa Xsaei35I2n1qUl71GA66hjycEZzkmY/BD5DupZnuYs9oUUMveYjzHeT2XdDbqPL2wvbA hdSIHq/ySCl328IaC4SN+GhZ3x2PeLeAcHx7abK3hUlUApMY+tYH8kQgitYsKqrYOyPT X8/THy7tIPL8hYvHEuP75snVN9zfDrFO0wflbiSvgHeKWQfNmf0pXjlWFPZbhxOPUKeA zZfA== X-Gm-Message-State: ALoCoQlJRqBOlKYOsy6iWskYLIM5jWU1S60oMgRnC1A4Lvz5ok8fUfrHOiphLPSplIJcnLxyW5MP X-Received: by 10.180.73.176 with SMTP id m16mr1624808wiv.68.1432138430548; Wed, 20 May 2015 09:13:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Wed, 20 May 2015 09:13:10 -0700 (PDT) In-Reply-To: References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> From: Eric Rescorla Date: Wed, 20 May 2015 09:13:10 -0700 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=f46d043c7e586c2ee5051685b61c Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:13:53 -0000 --f46d043c7e586c2ee5051685b61c Content-Type: text/plain; charset=UTF-8 On Wed, May 20, 2015 at 9:09 AM, Adam Langley wrote: > On Wed, May 20, 2015 at 8:35 AM, Eric Rescorla wrote: > > It will mean that we need a different set of code points than the current > > ones, right? > > Not quite sure that I follow you here: > > We will need a different set of code points than the ones currently > squatted for ChaCha (0xcc13 etc), but the draft already specifies > that. (And the AEAD construction is slightly different.) > Oh, sorry, I hadn't noticed that. I agree with your analysis below. > However, if we specified the current TLS 1.3 nonce scheme for ChaCha > in TLS 1.2, but TLS 1.3 changed before it was final, I don't think the > code points would need to change again. It would just be the case that > the code points, when used in TLS 1.3, use whatever TLS 1.3 ends up > doing and, in previous versions, they use what TLS 1.3 does now. > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > --f46d043c7e586c2ee5051685b61c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 20, 2015 at 9:09 AM, Adam Langley <agl@imperialviolet= .org> wrote:
On Wed, May 20, 2015 at 8:35 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> It will mean that we need a different set of code points than the curr= ent
> ones, right?

Not quite sure that I follow you here:

We will need a different set of code points than the ones currently
squatted for ChaCha (0xcc13 etc), but the draft already specifies
that. (And the AEAD construction is slightly different.)

Oh, sorry, I hadn't noticed that. I agree with your a= nalysis below.

=C2=A0
However, if we specified the current TLS 1.3 nonce scheme for ChaCha
in TLS 1.2, but TLS 1.3 changed before it was final, I don't think the<= br> code points would need to change again. It would just be the case that
the code points, when used in TLS 1.3, use whatever TLS 1.3 ends up
doing and, in previous versions, they use what TLS 1.3 does now.


Cheers

AGL

--
Adam Langley agl@imperialviolet.o= rg https:/= /www.imperialviolet.org

--f46d043c7e586c2ee5051685b61c-- From nobody Wed May 20 09:14:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B873A1A8958 for ; Wed, 20 May 2015 09:14:08 -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 eJOPu0fwWo7M for ; Wed, 20 May 2015 09:14:07 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E071A8942 for ; Wed, 20 May 2015 09:14:06 -0700 (PDT) Received: by wgfl8 with SMTP id l8so58223189wgf.2 for ; Wed, 20 May 2015 09:14:05 -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:from:date :message-id:subject:to:cc:content-type; bh=I0hmZKbCzaIcjRPnz0VrU2jVkXb+cSgCjH7jTUmGUSM=; b=ehybP0YupdK6a1MNiUj9R5WPcPA7MZT9pXF8O0YroNZFvfUL1/6UbVfHO+FmafKF/o 7QSVXdY9TW91JroTHvLhBBYfRqSLQgPq1Tuf8WzYT/tsgZmQ1/JA4mhlaE9fomRbdzxq rPjDeVCQLvEX4ekqYdRSDl/qvJaui1xpG/u/UFfOtM+7aQ7iO00LRFIW+bLn124m40Fa z5j4rIzn6rUvb8YKuQOR9PJ0ww3km9F6+lkvRccJCAD1L80BUcRwVbQkCghPe7omy7Q9 bIeBZd0mB5BnwohCYc8DWEInT/GIW1yCA/fyOTT3c+myEXICexTKsdB80/MdFAXhUC2l 7mmg== X-Gm-Message-State: ALoCoQm2A7h4Vm7DnaljlYve4avZEyST6lYfKqOlfMJAosk9yHgAROBWdPKJBjBLdsJj9OgB16dy X-Received: by 10.180.74.208 with SMTP id w16mr43084484wiv.31.1432138445612; Wed, 20 May 2015 09:14:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Wed, 20 May 2015 09:13:25 -0700 (PDT) In-Reply-To: References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> From: Eric Rescorla Date: Wed, 20 May 2015 09:13:25 -0700 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=f46d0438921751fd36051685b78a Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:14:08 -0000 --f46d0438921751fd36051685b78a Content-Type: text/plain; charset=UTF-8 TLS 1.1 mass changed the way we do IVs for all cipher suites. -Ekr On Wed, May 20, 2015 at 9:13 AM, Eric Rescorla wrote: > > > On Wed, May 20, 2015 at 9:09 AM, Adam Langley > wrote: > >> On Wed, May 20, 2015 at 8:35 AM, Eric Rescorla wrote: >> > It will mean that we need a different set of code points than the >> current >> > ones, right? >> >> Not quite sure that I follow you here: >> >> We will need a different set of code points than the ones currently >> squatted for ChaCha (0xcc13 etc), but the draft already specifies >> that. (And the AEAD construction is slightly different.) >> > > Oh, sorry, I hadn't noticed that. I agree with your analysis below. > > > >> However, if we specified the current TLS 1.3 nonce scheme for ChaCha >> in TLS 1.2, but TLS 1.3 changed before it was final, I don't think the >> code points would need to change again. It would just be the case that >> the code points, when used in TLS 1.3, use whatever TLS 1.3 ends up >> doing and, in previous versions, they use what TLS 1.3 does now. >> >> >> Cheers >> >> AGL >> >> -- >> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org >> > > --f46d0438921751fd36051685b78a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TLS 1.1 mass changed the way we do IVs for all cipher suit= es.

-Ekr


On Wed, May 20, 2015 at 9:13 AM, Eric = Rescorla <ekr@rtfm.com> wrote:
=


On Wed, May 20, 2015 at 9:09 AM, Adam Langley <a= gl@imperialviolet.org> wrote:
On Wed, May 20, 2015 at 8:35 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> It will mean that we need a different set of code points than the curr= ent
> ones, right?

Not quite sure that I follow you here:

We will need a different set of code points than the ones currently
squatted for ChaCha (0xcc13 etc), but the draft already specifies
that. (And the AEAD construction is slightly different.)

Oh, sorry, I hadn't noticed that. I agree with= your analysis below.

=C2=A0
However, if we specified the current TLS 1.3 nonce scheme for ChaCha
in TLS 1.2, but TLS 1.3 changed before it was final, I don't think the<= br> code points would need to change again. It would just be the case that
the code points, when used in TLS 1.3, use whatever TLS 1.3 ends up
doing and, in previous versions, they use what TLS 1.3 does now.


--f46d0438921751fd36051685b78a-- From nobody Wed May 20 09:15:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A406D1A892F for ; Wed, 20 May 2015 09:15:14 -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 4rs15hyBxuw6 for ; Wed, 20 May 2015 09:15:08 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id AD80F1A1A00 for ; Wed, 20 May 2015 09:15:08 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4B4C7285A0; Wed, 20 May 2015 16:15:08 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 38790285B7; Wed, 20 May 2015 16:15:08 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 1F49880068; Wed, 20 May 2015 16:15:08 +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; Wed, 20 May 2015 11:15:07 -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; Wed, 20 May 2015 11:15:07 -0500 From: "Salz, Rich" To: Aaron Zauner , Nikos Mavrogiannopoulos Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYnxhI4gELzT02Lcfjvc108eJ2FSdkAgAAExwD//7tYsA== Date: Wed, 20 May 2015 16:15:06 +0000 Message-ID: References: <1432134170.2926.9.camel@redhat.com> <555CA61C.5090405@azet.org> In-Reply-To: <555CA61C.5090405@azet.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.146.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:15:14 -0000 OpenSSL and logjam, fyi: http://openssl.org/blog/blog/2015/05/20/logjam-fre= ak-upcoming-changes/ Includes explanation of why "export" is important. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Wed May 20 09:23:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFD71A1AA9 for ; Wed, 20 May 2015 09:23: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 WmKvN4x0ZWdS for ; Wed, 20 May 2015 09:23:44 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC601A8907 for ; Wed, 20 May 2015 09:23:26 -0700 (PDT) Received: by wgfl8 with SMTP id l8so58482817wgf.2 for ; Wed, 20 May 2015 09:23: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=ekdjZaDtUq1fdaekqWtgysaox7MTNHySKoe0ZV29v4c=; b=RoEU4aUV9jscPH8E4JUZXK5E7UtwZDNVTt59u1GgqdrotUBTZnuxwFesF4Wr9ZoGbk Y03SVo/S4XWvQZVHJgG5e8xDsd87vS6rX0hU4m3zNl+YdrUGz6/yOnWob4Y20e0pS5Hy 6VUZSrG8DfxYbrr7KNmDDCUKyl4JG3/+gKKirWVdNf8gq8xPT9piqkoo6ctaublQOmSO c1jS5U201/mJ/eol3WmAN1YHrhyN0gLYgDDspp+mUbU9X9vm6WnFi7XBTPO5kB2gj9K1 uXj+R7eZlpZEXv286duwWFroCVe+Y/gaqwoy0VXHRYKafS5CKPZjsNi70TffAkYu56lv M6nw== MIME-Version: 1.0 X-Received: by 10.180.187.141 with SMTP id fs13mr43428326wic.26.1432139005277; Wed, 20 May 2015 09:23:25 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Wed, 20 May 2015 09:23:25 -0700 (PDT) In-Reply-To: <555CA61C.5090405@azet.org> References: <1432134170.2926.9.camel@redhat.com> <555CA61C.5090405@azet.org> Date: Wed, 20 May 2015 12:23:25 -0400 Message-ID: From: Watson Ladd To: Aaron Zauner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:23:46 -0000 On Wed, May 20, 2015 at 11:19 AM, Aaron Zauner wrote: > Hi, > > Nikos Mavrogiannopoulos wrote: >> On Wed, 2015-05-20 at 10:05 -0400, Watson Ladd wrote: >>> https://weakdh.org/ >>> >>> Transcript hashing will solve this problem. In the meantime, you want >>> to turn off DH_EXPORT. >> >> The interesting thing is that there are no DHE_EXPORT ciphersuites. >> > > I was also wondering about that. IANA has no entries for DHE_EXPORT*. As > far as I can tell there isn't even information on the searchable web on > that. If you google DHE_EXPORT it'll point you to this very paper and > that's about it. This is what I get for writing before coffee. They do mean DHE_EXPORT to refer to dhe_rsa_export and dhe_dss_export, as "defined" in RFC 2246. These are ciphersuite values. Tom Ritter's comments are correct: synchronization isn't going to work here, and we should either disable insecure ciphers entirely or ensure that signatures of keys indicate the context. Clients need to do more validation of DH parameters. Finally, as DJB pointed out on twitter so long as insecure options need to be removed. Not disabled, removed. That way bugs like this one, or other negotiation bugs, cannot lead to insecure ciphers being used. Sincerely, Watson Ladd > > Aaron > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed May 20 09:58:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60AA1A8965 for ; Wed, 20 May 2015 09:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuQeTjxAvtHd for ; Wed, 20 May 2015 09:58:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836341A88F8 for ; Wed, 20 May 2015 09:58:14 -0700 (PDT) Received: from BN3PR0301CA0056.namprd03.prod.outlook.com (10.160.152.152) by DM2PR0301MB0701.namprd03.prod.outlook.com (10.160.96.27) with Microsoft SMTP Server (TLS) id 15.1.160.19; Wed, 20 May 2015 16:58:11 +0000 Received: from BN1AFFO11OLC003.protection.gbl (2a01:111:f400:7c10::187) by BN3PR0301CA0056.outlook.office365.com (2a01:111:e400:401e::24) with Microsoft SMTP Server (TLS) id 15.1.166.22 via Frontend Transport; Wed, 20 May 2015 16:58:11 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1AFFO11OLC003.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Wed, 20 May 2015 16:58:09 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) with Microsoft SMTP Server (TLS) id 15.1.112.16; Wed, 20 May 2015 16:58:07 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Wed, 20 May 2015 16:58:06 +0000 From: Santiago Zanella-Beguelin To: "tls@ietf.org" Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2FE+rT Date: Wed, 20 May 2015 16:58:06 +0000 Message-ID: <1432141085848.37685@microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.151.241.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11OLC003; 1:DY8JdvR4ihlXrOEv//LZF8rrh0t3CGFKrjEXPUoFJOQ3OZn94NbGMDRuZu3C6KgDN57ruSfO8jphMAFL4/nh63xL3b6viko/AeXtj7lTEHBhY5NOYWuVY64ytaAj0Epr5eJQTjI49sfya3Et1Tr0w4Itsf8cnijQMLK8OfjkfOu0+yeGXdFvegfNJQGbMKuj+lHDahObDSiP5s0+lB5T7UgVZ+TfxdKttGrmTeNNLYL554SSjcqpeCUOuYsgy3cMlPU6Fgu0kfp7tD4JBBw8yg== X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(189002)(55674003)(31014004)(377454003)(66066001)(4001540100001)(6806004)(86362001)(50466002)(64706001)(86146001)(2656002)(87936001)(86612001)(2501003)(76176999)(46102003)(50986999)(102836002)(2900100001)(15975445007)(68736005)(81156007)(97736004)(77156002)(450100001)(54356999)(92566002)(106466001)(23756003)(110136002)(5001960100002)(189998001)(107886002)(5001860100001)(5001830100001)(117636001)(5001920100001)(106116001)(2351001)(16796002)(62966003)(2950100001)(47776003)(69596002)(19580395003)(19580405001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0701; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0701; 2:osxaQnLfgWr2rsPonEzGVyuHd5VOPnE8UTcNAcqsFCNKZTmwhS5i8HcY1/vp6qce; 2:h7JKt1q7U9ocIlrhcwY30tjSfkQ3wtWUjiLihmzdNwMOvRNN3cQEFCkWC3W/pIi7nMPI5eqOIBmrdDlS2bIwnvgAgqbRnxybQuya9Zo8DwQ0YW35g6VTRdxKEtlDRg1EBcyFgNCVy+j33O+9XSmx4JulMoKcns/LSifAQsiutlfDCXkeF6yYc2sMQbAOfUSTrzwWXXkhtFPWfBFgXjC3TZNIyV+T8uICKmFg6SOWq8dmBt49b/dhHH0SWRp1iSwW; 6:qBbtiac0UgmB/LOqWCil1uHyN0hkz4p1tL6PV06RqptFnlnzo3gBmFDAIgPP4lESMiLbSVpRrRJmiSCkNkeaEyNNvopNSHDG3TlWzWqL95H+bo6IqzQWl/5Jq/dCgVyYSBAvaD702cVrXoM1r/p03gE2s+ZGElKL4O0zJty5TQkxBiBoiMf6nu/2nCmB7tk3b6485sZIgyytjkN5LkQcEG2DkJJezAo2mcy0o3MoEqLaI/mESekt20f+1RimYF9L49YC48jzuRMTdLkGfG1jnH/ncnMqPevkCbOOzlYwtip3oBjRcmnI4SW1FhXU/yMAhzN2Yto7RySEm5Jn2JYRL2NljNXjBFLIZKRm8Kd+a6eQ/JQk4zqRa1ngvB1xvpv8j9XhvaDgahlw8473dQhG/iyB4EoIH2MUS3V7nIop2JtShrbhkMHcf6IuH3Qk4FoYjLRl94MSjNEF0guSOKQGcVGdOu1G4+mcdMzofVLHVRdv2MDGqqal4PpEd/vxrRns X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0701; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:DM2PR0301MB0701; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0701; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0701; 3:u5kWi18+I8DBINXjsW9ppv2lCLz50DW5DlHrYbhoD2GwJ5g4Ti+Vm1xCiA+gHIV5+QFeLnL+K6YxqDMelCeR9vMrdOTNdHBLjxTHqxxI+kje7SEt6zwsB05Ni6d/qg40osQf7uLBH4Yev00wlmeXPnxUJq++BQuKe8daLI2BmXp58ukQ+gXoOfcmq/21KRBTYgWuW1QRODSK6T2clTV8E72SCj9KV6FBB4BCoSynYyemuo6+YU+RwhFDQoqVAiXBla7hOhFzk9/hK4va+sfG8FyMFgVSkC8CtxXQqE+mFFhswO1Q0YjjO4Xjm7mQLnLh X-Forefront-PRVS: 0582641F53 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DM2PR0301MB0701; 9:o+6h2R4y5/MFfqkZzILI9h1lYXUJzqrmZLKoQB?= =?iso-8859-1?Q?P3gUr9nnl5tcuQPko+sSLQ242aUUH+Iu7gpuOjy0lgYRKaj4KETV2VsYcx?= =?iso-8859-1?Q?jYpIoBxh8JQoZalGjeZu2/xP83XoBdccxaT7/j5N3spGgBESMIxkXNg0C/?= =?iso-8859-1?Q?YoGT8RLAn2x5aiNBlXW4OVe75eRQ0e25i18oyRhN6sejvelXLeSsnzVbbo?= =?iso-8859-1?Q?RzKvaMQZ7JT4r0VTaCX72V9rsVpHeL1f++fjTQ5Mspv6erg3HQ02a5wfns?= =?iso-8859-1?Q?l5AcA5iRsXCagX54RaqP5jpW8LI5K20dNDiJpggk4PW+KEkufcPFhNPANf?= =?iso-8859-1?Q?ztOxPImSLbF1LOPbeYrSNJBRNwY2omqWhL8c38Ic4hmh5uJdMN+AuJTHH7?= =?iso-8859-1?Q?rYRsOs3dONvdGAqMh/bQdHYyZwDtRkSTR8l82ooM5t3b7Ra/4NLXEi4i+B?= =?iso-8859-1?Q?rcH91jv+BDVocE05RreO2irUjp0GwCiUj4Qp9TsETmIonbr+zsCgN096w/?= =?iso-8859-1?Q?cSfx18pY52Txbr+GO05l/jcRXZCpxI9EfKkDIxXrHkYUlx6/vukTmQVdqx?= =?iso-8859-1?Q?bXQ2CU7+DRVK65hWXBYA7aSh4FivliTRu3MjUxoshpy8lVRIvfBe96s+vd?= =?iso-8859-1?Q?MGSyE5DydCzzcbLzWw7LHfiwyGZkx+SvO6Ws7BoOSoDjvq5x62XlIDlj1V?= =?iso-8859-1?Q?4/rDejU5MDtNrfBudaewaGvMu4Vw3aNYfL/qo1qxgtbmAMgaXEupZ0yFsu?= =?iso-8859-1?Q?Rr7RqDCiOT+gXUUdViOZC0PPpfFBulrILDQCVEXrH9DVutj5eqnjuKbpBF?= =?iso-8859-1?Q?ZanIijFA69aO45CfP5b+iQDQxe3RUKcI4A8jh8moVXSL7uG+DeWLh8LDO8?= =?iso-8859-1?Q?34gRSFKSEAqjzsx6SkzgAjR7jOGlqYRVXixEts7J+922pYpLvhpLCGq75x?= =?iso-8859-1?Q?qWovM3gjj3Uh7+B5eMTeXLyQUKs1R894wY5RuHu20gnmku9Mvux4M4lCFb?= =?iso-8859-1?Q?5HJ5cggEYP9sgLbB478m271hytG4pd8vNFZMnBPM3iWSCPNb6IPUdcHv56?= =?iso-8859-1?Q?6uJQ91mnxNyYDe+fWlK20nWC8BcVuvzoujEEHLbIc9gHOsBUDXQTRSKjed?= =?iso-8859-1?Q?bfFh0RJwBlPvPLcaCokmPNskYlRPnLLQMh7sbNacn2Gf2YP6zAGd+Pu8tE?= =?iso-8859-1?Q?Dro0ilV6BcKnX4TyL0NahExbiV5hK1EdITWV0f2u4iUnZ9ctVIodpa1eiK?= =?iso-8859-1?Q?xFlfIh77BC+TOCCXNPcKNI/+6Mal9QcL65ayHWpDzQeQA+OTGJ19ps4dSt?= =?iso-8859-1?Q?HdQxa1JPyCCqlSox3VgfljynudEFC2iqccDHsEezJTsGYXIEmdtPbWqEbE?= =?iso-8859-1?Q?yreRtyeIo=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0701; 3:ptJACe62OUObNS9VTwgV50Ja9oGQls/VHSCr60Dvers2gmc3hefmGyK0TTcfb8kpasJtjBcafV7yl+lUwT5iFB6jTa2u3YWpykREA+xy9+uaXKzVu3CmBkW21EPinmCkhtKdx8tETiyH6OvaK8uH5Q==; 10:gfvJyjqDR0EcmsF66UsM8PhdvQImDQmiZk123j0R/dOYj3LO9ZkeIgVwuwd0iX1eMY5qYhoxVL4foDekFImKAE/PChf22Z6gKIklW1MFRiA=; 6:RLjtXamV+a/7gJVJLSWKdjCxkG3saZpQb2zjdBcphT6tOwJ8oT/9QwjQTT3tP9Cm X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2015 16:58:09.8165 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0701 Archived-At: Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:58:16 -0000 Indeed, we are lazy and didn't want to write things like TLS_DHE_DSS_EXPORT= _WITH_DES40_CBC_SHA in full. The extended master secret extension won't prevent the attack because the d= owngrade happens within the handshake and before key confirmation. If the signature in the ServerKeyExchange message covered a hash of the tra= nscript so far (including the ciphersuite that the server chose), downgradi= ng to "DHE_EXPORT" would no longer be possible. To be fair, it's not an "INRIA bug". It's joint work with U. Penn, U. Michi= gan, Johns Hopkins, and Microsoft Research (funded in part by the Microsoft= Research-Inria joint centre in Paris). Cheers, --Santiago ________________________________________ From: TLS on behalf of Watson Ladd Sent: Wednesday, May 20, 2015 3:05 PM To: tls@ietf.org Subject: [TLS] Another IRINA bug in TLS https://weakdh.org/ Transcript hashing will solve this problem. In the meantime, you want to turn off DH_EXPORT. There are also implications for false start. Chrome has already announced countermeasures. I'm pretty sure this won't be the last issue of this nature. Sincerely, Watson Ladd _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls= From nobody Wed May 20 10:15:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993531A896D for ; Wed, 20 May 2015 10:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 OrEsg-CaplyE for ; Wed, 20 May 2015 10:15:06 -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 99CEA1A8932 for ; Wed, 20 May 2015 10:15:05 -0700 (PDT) Received: from iller (c-def5e555.014-1001-73746f1.cust.bredbandsbolaget.se [85.229.245.222]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4KHEoEi015562 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 20 May 2015 19:14:55 +0200 Message-ID: <1432142087.2946.11.camel@josefsson.org> From: Simon Josefsson To: tls@ietf.org Date: Wed, 20 May 2015 19:14:47 +0200 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-f8dcQi7twUTHmn+QdMvF" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [TLS] Strawman on EdDSA/Ed25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:15:07 -0000 --=-f8dcQi7twUTHmn+QdMvF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear WG, Support for EdDSA/Ed25519 in TLS has been suggested a couple of times. I have started to work on an I-D to describe more precisely what that would actually mean, and here is an initial strawman document: https://tools.ietf.org/html/draft-josefsson-tls-eddsa-00 I'm confident I missed some major pieces of the puzzle, but feedback and review is welcome so the document can be improved into something that can be implemented and interoperate. Until the main parts have been fleshed out please email me directly and I'll try to do the best I can to merge feedback into the document. If the WG chairs permit, that discussion could also be done on this list. The best form of feedback would be in the form of merge requests or a clearly described issue in the issue tracker. Please see: https://gitlab.com/jas/ietf-tls-eddsa One aspect I'm aware of is that there is no OID allocated nor specification of PKIX certificates with EdDSA/Ed25519 public keys. I'm not sure the above document is the right place for doing that though, and more thinking around this topic is especially appreciated. Cheers, /Simon --=-f8dcQi7twUTHmn+QdMvF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJVXMEHAAoJEIYLf7sy+BGd4a4H/3Gw6Rb81Lwlngt6at/0y9aD 82LjuluAIkQDzafXXMrZGL98xrPjiVkMRRF/MWPQQl4Jovw5C4CTEVhOEcVwGB/z XB4XkS4Ps95YOfFW71JVLoTjb4RG2N5H7GF+B7NCjNz++xkggo1BpDh+a105R/2e hQE+LwqR4mxsjUmmlQwAvRINCbTMt7QA0NTeZgSXltQxvcoXlJI5H9ZHx3602dQg e2jDdRyFC9CJq0HTck7qmBFrbr1NXrqsweTevTUnHOwSdMN9PXGOR5MWdMMnLVwL 3DBkbZHXZSY5BiEE4a4j2RR8DsqxcsPy3fWsDF0O6uIzZQI2r6pH6daMyfAb+aI= =DwdY -----END PGP SIGNATURE----- --=-f8dcQi7twUTHmn+QdMvF-- From nobody Wed May 20 10:15:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF21A896B for ; Wed, 20 May 2015 10:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 BAb4KQhvvi6M for ; Wed, 20 May 2015 10:15:07 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEB51A890B for ; Wed, 20 May 2015 10:15:06 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id A264B1A25DE; Wed, 20 May 2015 20:15:04 +0300 (EEST) Date: Wed, 20 May 2015 20:15:04 +0300 From: Ilari Liusvaara To: Joseph Salowey Message-ID: <20150520171504.GA21197@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:15:16 -0000 On Wed, May 20, 2015 at 08:47:55AM -0700, Joseph Salowey wrote: > This is the WG call for adoption of: > > https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt > > This draft specifies the use of Curve25519 for ephemeral key exchange in > the TLS and DTLS. This draft serves as the starting point (it’s expired > and needs to be updated in light of > http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/). If you object to > the adoption of this draft, please let us know why by 20150602. Adopt. > Note: We’re not doing an early code point assignment for this draft, > because it clearly needs to resurrected and tweaked. Once that happens, > there’s nothing stopping a request from the authors for an early code point > assignment. Agreed: - Add curve448? - Do bit masking like cfrg-curves specifies? - Add zero key check like crfg-curves specifies[1]? - Why the point format and prefix? Expecting other point formats without new codepoint allocation[2]? Or some software engineering reason? [1] While it is not helpful with properly designed protocols, it is helpful with less-well-designed ones. It is very cheap anyway. [2] AFAIK, not allowed in 1.3 anyway. -Ilari From nobody Wed May 20 11:19:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0051A8A56 for ; Wed, 20 May 2015 11:19:02 -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 8ai3z9G38LUy for ; Wed, 20 May 2015 11:19:00 -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 433761A8A55 for ; Wed, 20 May 2015 11:18:59 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so157941927wic.0 for ; Wed, 20 May 2015 11:18:58 -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 :message-id:references:to; bh=aqfnMbG20+vMOVFOUegUgWBm50jyP0/dIAaIvRHPdQs=; b=kH/qXGeGFSMzS7DD5oBTCJv0TVBovnl0ubR51qV9FMfNUh60V7XzAibbi7V0TwWDGv tKtX4QE7g2bgc0LMKBTA+glexEubUEfyflKG3b+4pBIiUo90ccVe9M1X0qin5nVhggg3 8ZzcBiKOmZp0ghThd2Cdzdi6LLdH/XEUPvXfMIX72GZ5JmKUdwykjXp7ym7k+fA026jx qOc1bzySSq9dn6Rin6C8aOiXwV3spA8UHKPzPgXgqXwR1J2cuVNflpGWooktv9UJm62q FxVSOIr4OiU1j+1ZBRPj057vImpE/Ic2Xdm4C/puKoUm7t803gNFoQjGcR6rEpggSFqV IINw== X-Received: by 10.194.142.242 with SMTP id rz18mr56214766wjb.76.1432144872579; Wed, 20 May 2015 11:01:12 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id l6sm4636048wib.18.2015.05.20.11.01.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 11:01:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_358D02BC-1907-4B3E-B5DF-9B0EA967DCCA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Wed, 20 May 2015 21:01:09 +0300 Message-Id: <0A275078-EE74-483F-8065-B9CD7808E5EB@gmail.com> References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> <86328675.1427913.1432137385798.JavaMail.zimbra@redhat.com> To: Eric Rescorla X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Adam Langley , IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:19:02 -0000 --Apple-Mail=_358D02BC-1907-4B3E-B5DF-9B0EA967DCCA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 20, 2015, at 7:02 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Wed, May 20, 2015 at 8:56 AM, Nikos Mavrogiannopoulos = > wrote: > ----- Original Message ----- > > What would you think of just adopting the 1.3 approach then? > > I don't have a strong opinion on this, but it seems a pity to have = three > > separate mechanisms. >=20 > I don't really see it as a separate mechanism, it just omits the bytes = which > are redundant. >=20 > Well, it's separate in the sense that you can't just swap out the GCM = for ChaCha > alg-ids. >=20 > As I said, I don't feel strongly about this, TBH I don=E2=80=99t feel strongly about this either. It=E2=80=99s a bit = of an ugly piece of code to handle this, but not ugly enough to make it = worth arguing this for a long time. > but I do feel strongly that we should > decide this before doing the code point allocation That=E2=80=99s your call, but as Stephen said there is always the = potential for non-interoperable changes to happen during the WG process. = I don=E2=80=99t see this as blocking, but I was told the same at IPsecME = when I made the same request. Yoav= --Apple-Mail=_358D02BC-1907-4B3E-B5DF-9B0EA967DCCA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 20, 2015, at 7:02 PM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Wed, May 20, 2015 at 8:56 AM, = Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
----- Original Message -----
> What would you think of just adopting the 1.3 approach then?
> I don't have a strong opinion on this, but it seems a pity to have = three
> separate mechanisms.

I don't really see it as a separate mechanism, it just omits the = bytes which
are redundant.

Well, it's separate in the sense that you can't just swap out = the GCM for ChaCha
alg-ids.

As I said, I don't feel strongly about = this,

TBH I don=E2=80=99t feel strongly about this = either. It=E2=80=99s a bit of an ugly piece of code to handle this, but = not ugly enough to make it worth arguing this for a long time.

but I do feel strongly that we = should
decide this before doing the code point = allocation

That=E2=80=99s your call, but as Stephen said = there is always the potential for non-interoperable changes to = happen during the WG process. I don=E2=80=99t see this as blocking, but = I was told the same at IPsecME when I made the same request.

Yoav
= --Apple-Mail=_358D02BC-1907-4B3E-B5DF-9B0EA967DCCA-- From nobody Wed May 20 11:23:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEE11A8A60 for ; Wed, 20 May 2015 11:23:29 -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 wL5WKRQXCjOh for ; Wed, 20 May 2015 11:23:28 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 2E5311A8A55 for ; Wed, 20 May 2015 11:23:28 -0700 (PDT) Received: by ykeo186 with SMTP id o186so18696502yke.0 for ; Wed, 20 May 2015 11:23:27 -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:content-transfer-encoding; bh=lEHR0fFRse1YTDPHE+3YEFy+2kjTrXUMmFQwMvIYBSA=; b=jIdHFOTVbvsXUhw2TjhfFckqJgpcL4G+QJfvd55bXOWUI0lKU+EyVLxqkm5AERXog+ rZEHFvERARCOyaWl79ufd2ok2MoMBgO6bS5ew6+4WIGozMO/WrvSMkYjIJr2kx4iREBM dK6Z6d6uU9wZbldD+iHJoEnf5CBWNElK1Xj0vnkjDmQXi/EtLmj6Jg5zLhxFlY2S4Nc7 cY0GF05d7GaFg6ZWY+MHh9pD0g0rGZQb5/GQrPRXSybPnnMUbKywSYzmDzsbJx+Ly/Zk HjKE2bKKqYT/Fak3jji6hGVpkk+qLShJFgejnZoKqssMznTrSzg3vBBjEvSsZp0PkXwU /Png== MIME-Version: 1.0 X-Received: by 10.170.61.141 with SMTP id d135mr36172173ykd.26.1432146207623; Wed, 20 May 2015 11:23:27 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Wed, 20 May 2015 11:23:27 -0700 (PDT) In-Reply-To: <0A275078-EE74-483F-8065-B9CD7808E5EB@gmail.com> References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> <86328675.1427913.1432137385798.JavaMail.zimbra@redhat.com> <0A275078-EE74-483F-8065-B9CD7808E5EB@gmail.com> Date: Wed, 20 May 2015 11:23:27 -0700 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Adam Langley , IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:23:29 -0000 On 20 May 2015 at 11:01, Yoav Nir wrote: > That=E2=80=99s your call, but as Stephen said there is always the potenti= al for > non-interoperable changes to happen during the WG process. I don=E2=80=99= t see this > as blocking, but I was told the same at IPsecME when I made the same > request. We're talking about a code point allocation. That usually requires a commitment to semantics first. From nobody Wed May 20 11:43:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1611A8958 for ; Wed, 20 May 2015 11:43:45 -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 gFBsnA8Z8xhm for ; Wed, 20 May 2015 11:43:44 -0700 (PDT) Received: from mail-wi0-x241.google.com (mail-wi0-x241.google.com [IPv6:2a00:1450:400c:c05::241]) (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 9C3D51A8A7F for ; Wed, 20 May 2015 11:43:43 -0700 (PDT) Received: by wivr20 with SMTP id r20so6924910wiv.3 for ; Wed, 20 May 2015 11:43:42 -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=nzkcrlVAPqU94lVlSvyx8KuSoPU9Y7vifwSeRqSNotE=; b=qyQImVy6mJnjLb32qxoMH/NPIo7lOBI/YckH7jRY8fvrpV/2zHpy8pUtSVXVqKfsAJ Z2aFdunnKepAF71emxJwYK0Ib4r+PlCF1dScDP7FSXJM9lg5rMlqveRqzejvr3jjCzUE ca0nhThR3wFqrcqdW1Xdq+XIU8H3tZFa3vVi/wlxJaiDzaPmneYZccMNHVNX7QMmCa6y l13/DkNhQdWVm8ElLJ3LAFWgldHIoSRbJysEDxaRTP7Zl+CXAgNx61Jm+kGROvsYiLF3 jy7RIw8JuLhvkS2a+ylVYN0zQMUIX3BboioTMVN/6X8UondIHU5dnPXnx8Lp5+6l7gv9 CBig== X-Received: by 10.194.23.234 with SMTP id p10mr12192125wjf.52.1432147422333; Wed, 20 May 2015 11:43:42 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id h5sm28168160wjn.20.2015.05.20.11.43.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 11:43:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Wed, 20 May 2015 21:43:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> <86328675.1427913.1432137385798.JavaMail.zimbra@redhat.com> <0A275078-EE74-483F-8065-B9CD7808E5EB@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Adam Langley , IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:43:46 -0000 > On May 20, 2015, at 9:23 PM, Martin Thomson = wrote: >=20 > On 20 May 2015 at 11:01, Yoav Nir wrote: >> That=E2=80=99s your call, but as Stephen said there is always the = potential for >> non-interoperable changes to happen during the WG process. I don=E2=80=99= t see this >> as blocking, but I was told the same at IPsecME when I made the same >> request. >=20 > We're talking about a code point allocation. That usually requires a > commitment to semantics first. There=E2=80=99s never a commitment. Until a draft is approved by the = IESG anything can be changed. Yoav From nobody Wed May 20 11:46:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C251A8A83 for ; Wed, 20 May 2015 11:46: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 biHRCcp8cI_f for ; Wed, 20 May 2015 11:46:34 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED971A8A82 for ; Wed, 20 May 2015 11:46:34 -0700 (PDT) Received: by yhcb70 with SMTP id b70so15351177yhc.0 for ; Wed, 20 May 2015 11:46:33 -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:content-transfer-encoding; bh=4VR6oDvkTeMfYbanbp58c/sqngxTtph7DprVGdzsE0o=; b=HctSws/jpkzOPzTYp8Ewtup+xebbAp7IlcNqYNBN4EmhJwn0kRqnoppZgW02vOxIOI QR8qG7MczlYWKReJy6fA0LrVzFP25gWWUz/RQJxf3HkyXXIQCCIwYMjDoTY8xmSbJmjn 7wq59a2gG6HQG9OD9PKH0enQ2f5ZmsLzhx7V2ki7WFzO72a/0oDlXjjk88KkQYlLLVEV UEKCPVLJSwrncJfjmGhPZ94U0mtGtwyKCNqoV8Z/hwnC0lPPf7ijuHR3FKr57iJIWS/x 23Fxk6M0RuFDv4ErEdi/6Xh4w3RZxeD6fsHwOuzFq2kPLoOahzyDkZb2aZOb6bwUILyh g5lg== MIME-Version: 1.0 X-Received: by 10.236.41.169 with SMTP id h29mr32970420yhb.100.1432147593447; Wed, 20 May 2015 11:46:33 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Wed, 20 May 2015 11:46:33 -0700 (PDT) In-Reply-To: References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> <86328675.1427913.1432137385798.JavaMail.zimbra@redhat.com> <0A275078-EE74-483F-8065-B9CD7808E5EB@gmail.com> Date: Wed, 20 May 2015 11:46:33 -0700 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Adam Langley , IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:46:35 -0000 On 20 May 2015 at 11:43, Yoav Nir wrote: >> We're talking about a code point allocation. That usually requires a >> commitment to semantics first. > > There=E2=80=99s never a commitment. Until a draft is approved by the IESG= anything can be changed. What value is there in a code point if no two parties are able to agree on its semantics? I believe that the conditions for an early request are: 1. we agree that there is enough demand for whatever it is now and don't want to wait until the IESG approve a spec 2. we agree that the semantics are stable enough This might meet the first, but it looks like the second is a little less fi= rm. From nobody Wed May 20 12:07:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0961A8A65 for ; Wed, 20 May 2015 12:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 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_NONE=-0.0001] 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 24KuWhg7aRAu for ; Wed, 20 May 2015 12:07:30 -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 C09A71A8AAE for ; Wed, 20 May 2015 12:07:30 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 63315200D3096; Wed, 20 May 2015 12:07:30 -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=tVQ7OMLg7IMX0H g0RoB92+WAjN8=; b=ZCJyOF/L2C6YbxuH+pmXdd0i7h7+aeuA0R4BGtooUeDA7x 1WFRF+cKPKOCX+P+Alyrlc7UgjisVoKPdRICFMeegcKkL85fluhQNwo+x6+gxygC FHA5rvb9xdjUUrwIMhcm9lG/7mVedJrZEY9kCSOLygf6Mh8NtCeet5+zCCbSw= 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 9C282200D3090; Wed, 20 May 2015 12:07:29 -0700 (PDT) Date: Wed, 20 May 2015 14:07:28 -0500 From: Nico Williams To: Simon Josefsson Message-ID: <20150520190727.GD19183@localhost> References: <1432142087.2946.11.camel@josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432142087.2946.11.camel@josefsson.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:07:35 -0000 On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote: > Support for EdDSA/Ed25519 in TLS has been suggested a couple of times. I'm in favor. > One aspect I'm aware of is that there is no OID allocated nor > specification of PKIX certificates with EdDSA/Ed25519 public keys. I'm > not sure the above document is the right place for doing that though, > and more thinking around this topic is especially appreciated. It's an OID. You can get your own OID arc and then allocate an OID. Is it important to separate the addition of a PKIX algorithm OID from the TLS bits? Well, it is neater that way. Nico -- From nobody Wed May 20 12:27:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724EF1A8BB7 for ; Wed, 20 May 2015 12:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Arfvi1jNRxPl for ; Wed, 20 May 2015 12:27:43 -0700 (PDT) Received: from mail-wi0-x241.google.com (mail-wi0-x241.google.com [IPv6:2a00:1450:400c:c05::241]) (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 CE9D11A8BB4 for ; Wed, 20 May 2015 12:27:42 -0700 (PDT) Received: by wivz2 with SMTP id z2so7051348wiv.0 for ; Wed, 20 May 2015 12:27:41 -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=ECHxHKiK2H21LXUidcllvvKU4WK0D41QuMZJ5YffF54=; b=g2YkG5dzxAJ/UW0Ln+ghC0QG8IO///fINBK7cDBmt0tYwNwqIgbKxkpIeYHCUcUpS9 a7MRWGE4FXppRHisE6Foa0LZb3m1dooGvgqfAivdLYFkpXghrOjJALzkuB2BY+r7eyWt teZukhDoa4WKtdEHVhj22rR0cgG4cK8HUG/O4DWSPEuZfuOjmd/2KU7bEQRpomZhvDHo vZ8nAQFaxXv8csBUY+WsoMbdxs57wiEdVhger6QyDrgB5IQxu0dYORp+xoymeXxn1Js2 74qnrz/5Wm7dAE8BfreZnLKwu8u8gT3yFM/4Et/D/SnxM7Hl2xlMFNOEFsrG+Yy0MHHZ FPDw== X-Received: by 10.194.222.137 with SMTP id qm9mr68463555wjc.43.1432150061627; Wed, 20 May 2015 12:27:41 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id u6sm28334254wjy.13.2015.05.20.12.27.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 12:27:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Wed, 20 May 2015 22:27:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <28BB0FC7-2173-4CBB-8551-33018B1C888D@gmail.com> References: <1269593170.1072986.1432104184832.JavaMail.zimbra@redhat.com> <86AF5010-12A3-410A-AE23-9A0643D536EE@gmail.com> <86328675.1427913.1432137385798.JavaMail.zimbra@redhat.com> <0A275078-EE74-483F-8065-B9CD7808E5EB@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Adam Langley , IETF TLS Working Group Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:27:44 -0000 > On May 20, 2015, at 9:46 PM, Martin Thomson = wrote: >=20 > On 20 May 2015 at 11:43, Yoav Nir wrote: >>> We're talking about a code point allocation. That usually requires = a >>> commitment to semantics first. >>=20 >> There=E2=80=99s never a commitment. Until a draft is approved by the = IESG anything can be changed. >=20 > What value is there in a code point if no two parties are able to > agree on its semantics? =20 But we do agree on the semantics. They are whatever=E2=80=99s in the = latest draft. And that=E2=80=99s good enough to implement and test = interoperability. Of course if you ship it as anything other than an = experimental feature, you are risking getting interoperability problems = later, but this is no different from any draft, including those that do = not require code point assignments. > I believe that the conditions for an early > request are: >=20 > 1. we agree that there is enough demand for whatever it is now and > don't want to wait until the IESG approve a spec > 2. we agree that the semantics are stable enough >=20 > This might meet the first, but it looks like the second is a little = less firm. From nobody Wed May 20 12:43:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7E1A9039 for ; Wed, 20 May 2015 12:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 ict2GnFqu27O for ; Wed, 20 May 2015 12:43:27 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DAFF1A9035 for ; Wed, 20 May 2015 12:43:27 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id A4F3B2BBF0; Wed, 20 May 2015 21:43:25 +0200 (CEST) X-purgate-ID: 152705::1432151005-00000B48-CFD3C752/0/0 X-purgate-size: 1410 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 923334112E; Wed, 20 May 2015 21:43:25 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 878AA1B316; Wed, 20 May 2015 21:43:25 +0200 (CEST) In-Reply-To: To: Tom Ritter Date: Wed, 20 May 2015 21:43:25 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150520194325.878AA1B316@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:43:30 -0000 Tom Ritter wrote: > On 20 May 2015 at 09:05, Watson Ladd wrote: >> https://weakdh.org/ >> >> Transcript hashing will solve this problem. > > Will it? (Or at least, I'm not sure where you intend to include the > transcript hash, in which case - maybe.) > > I think the issue is the same as the Section 4.4 here: > https://www.schneier.com/paper-ssl-revised.pdf - the underlying cause > being that the ephemeral parameters' signature doesn't include enough > context. In Schneier's, the algorithm needed to be included (it > still isn't, in TLS 1.2 - we just (hope) we have stricter checking on > the data in implementations). Correct. For some unclear reason, the original signature over the ServerKeyExchange handshake message was ill-designed, in that it does not cover all prior handshake messages (ClientHello,ServerHello, ServerCertificate), but only the ClientHello.random & ServerHello.random besides the Servers parameters. Now the issue of weak ephemeral Diffie-Helman keys has been raised here before (14-May-2007): http://www.ietf.org/mail-archive/web/tls/current/msg01647.html and a few other occasions. The last time that I remember the behaviour of the installed base (not refusing short or bogus DH parameters) being described as a problem was in the description of the Triple-Handshake-Attack (return of renego). -Martin From nobody Wed May 20 12:50:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1192C1A9048 for ; Wed, 20 May 2015 12:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 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_NONE=-0.0001] 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 e1oew5qsN7mp for ; Wed, 20 May 2015 12:50:25 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1EA1A9046 for ; Wed, 20 May 2015 12:50:25 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 3C5652005E810; Wed, 20 May 2015 12:50:25 -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=fXAfgcqhLvNVXP V4gSnpSnnq1hQ=; b=BiiZ8bOaDhG3xDg8tIVu4fdXz2L2g92daCg8vBj+pVZAVv 7Wnp/hZJujWLtubvXKkA8D95r5j8mg1iC1ai3QsDMZdvbGuJSzsf8sbMLp2fmZr/ m6sPTeR5Vt1dfKcDaWBfZptwMSz5T2ObjPSvAf5DH1RKvfibiSz9snJA77UFo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPA id D4D362005E80F; Wed, 20 May 2015 12:50:24 -0700 (PDT) Date: Wed, 20 May 2015 14:50:24 -0500 From: Nico Williams To: Joseph Salowey Message-ID: <20150520195023.GF19183@localhost> References: 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: "tls@ietf.org" Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:50:29 -0000 On Wed, May 20, 2015 at 08:47:55AM -0700, Joseph Salowey wrote: > This is the WG call for adoption of: > > https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt Adopt. Nico -- From nobody Wed May 20 13:30:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7096E1A90A4 for ; Wed, 20 May 2015 13:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 cLH9Ey09mVQd for ; Wed, 20 May 2015 13:30:14 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017461A9059 for ; Wed, 20 May 2015 13:30:14 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 5DCE7188780; Wed, 20 May 2015 23:30:11 +0300 (EEST) Date: Wed, 20 May 2015 23:30:11 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20150520203011.GA25549@LK-Perkele-VII> References: <1432142087.2946.11.camel@josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1432142087.2946.11.camel@josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 20:30:16 -0000 On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote: > > Support for EdDSA/Ed25519 in TLS has been suggested a couple of times. > I have started to work on an I-D to describe more precisely what that > would actually mean, and here is an initial strawman document: > > https://tools.ietf.org/html/draft-josefsson-tls-eddsa-00 > > I'm confident I missed some major pieces of the puzzle, but feedback and > review is welcome so the document can be improved into something that > can be implemented and interoperate. More ciphersuites? The signature algorithm negotiation (extension 13) doesn't work in practice? > One aspect I'm aware of is that there is no OID allocated nor > specification of PKIX certificates with EdDSA/Ed25519 public keys. I'm > not sure the above document is the right place for doing that though, > and more thinking around this topic is especially appreciated. AFAIK, a way to put the key into PKIX SPKI is required for the new signature algorithm to be useful. And that means OIDs. The curve itself is 1.3.6.1.4.1.11591.15.1, but AFAIK, there is no OID for the signature primitive. I think one can find more expertise about how to put various keys into SPKI in the PKIX mailinglist. Reading the PKIX specs, it seems like there are two ways: 1) Use algorithm "Unresricted" and use a new point format to denote LE edwards points. 2) Define new algorithm (OID) for EdDSA, put the curve OID as parameter and the LE edwards point as the key. -Ilari From nobody Wed May 20 14:49:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893A71A92AE for ; Wed, 20 May 2015 14:49:04 -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 K4CLzawo8KSG for ; Wed, 20 May 2015 14:49:02 -0700 (PDT) Received: from mail-wi0-x242.google.com (mail-wi0-x242.google.com [IPv6:2a00:1450:400c:c05::242]) (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 3B2991A8AD1 for ; Wed, 20 May 2015 14:49:02 -0700 (PDT) Received: by wibbw19 with SMTP id bw19so7492307wib.2 for ; Wed, 20 May 2015 14:49:01 -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 :message-id:references:to; bh=Me2OHsMzBgaP9BnDQECC/wruPQZMQ9fC4ud/Cf6RyJs=; b=vB5nJaJo61vNW70UbFRAZ0/9R1/xvNVWjqdbP4dKw/3fzbRik91BpP3pxs5TdTaenU Ao9TT6Ir6nHTnLJzRhpxpCafyJP0AhJrTXMuB5mYV0gDJlPU8hAie0nRkhupBnfgW2Fx hxoRcYqbu7Rb3q1wIHwTWJzRbsEGpKGkGJEt8PxKIb03Ti7ZbzhvHnWv9ZdjgzYqoDAl Wjq3jABgnkd94blCi1jYLG1rF6zEgJqp3kFn2MHbr3PYZHD1yFxoaQXOPJcsN8y0nr7s 2GNcRjXvFvWhXnPwl4GvZPJOfeF3PS28fI56TXKEK8jDiokwZL43h+2BQ1I+Qx7vP0lz q4HQ== X-Received: by 10.180.160.228 with SMTP id xn4mr13632wib.62.1432158541011; Wed, 20 May 2015 14:49:01 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id i6sm28850305wjf.29.2015.05.20.14.48.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 14:48:59 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BF89D4DC-DFDB-4118-94B1-6E6FBD873EBF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Thu, 21 May 2015 00:48:57 +0300 Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 21:49:04 -0000 --Apple-Mail=_BF89D4DC-DFDB-4118-94B1-6E6FBD873EBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Me too. I notice that while the draft doesn=E2=80=99t say that explicitly, it = uses existing *_ECDHE_* ciphersuites, so that no new ciphersuites are = required, despite the fact that this ECDHE has different point formats = and different back-end math than the existing ECDHE. I wonder if we can = also get away with using *ECDSA* ciphersuites for EdDSA signatures. Yoav > On May 20, 2015, at 6:50 PM, Eric Rescorla wrote: >=20 > I am in favor of adopting this draft. >=20 > -Ekr >=20 >=20 > On Wed, May 20, 2015 at 8:47 AM, Joseph Salowey > wrote: > This is the WG call for adoption of: >=20 > https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt = >=20 > This draft specifies the use of Curve25519 for ephemeral key exchange = in the TLS and DTLS. This draft serves as the starting point (it=E2=80=99= s expired and needs to be updated in light of = http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ = ). If you = object to the adoption of this draft, please let us know why by = 20150602. >=20 > Note: We=E2=80=99re not doing an early code point assignment for this = draft, because it clearly needs to resurrected and tweaked. Once that = happens, there=E2=80=99s nothing stopping a request from the authors for = an early code point assignment. >=20 > Thanks, >=20 > J/S --Apple-Mail=_BF89D4DC-DFDB-4118-94B1-6E6FBD873EBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Me too.

I = notice that while the draft doesn=E2=80=99t say that explicitly, it uses = existing *_ECDHE_* ciphersuites, so that no new ciphersuites are = required, despite the fact that this ECDHE has different point formats = and different back-end math than the existing ECDHE.  I wonder if = we can also get away with using *ECDSA* ciphersuites for EdDSA = signatures.

Yoav

On May 20, 2015, at 6:50 PM, = Eric Rescorla <ekr@rtfm.com> wrote:

I am in favor of adopting this draft.

-Ekr


On Wed, May 20, 2015 at 8:47 AM, Joseph Salowey = <joe@salowey.net> wrote:
This is the WG call = for adoption of:

https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-= 06.txt

This draft specifies the use of Curve25519 for ephemeral key = exchange in the TLS and DTLS.  This draft serves as the starting = point (it=E2=80=99s expired and needs to be updated in light = of http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/).  If you object to the = adoption of this draft, please let us know why by 20150602.

Note: We=E2=80=99re = not doing an early code point assignment for this draft, because it = clearly needs to resurrected and tweaked.  Once that happens, = there=E2=80=99s nothing stopping a request from the authors for an early = code point assignment.

Thanks,

J/S

= --Apple-Mail=_BF89D4DC-DFDB-4118-94B1-6E6FBD873EBF-- From nobody Wed May 20 15:27:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F361ABB19 for ; Wed, 20 May 2015 15:27:32 -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 NZKaViAqTl49 for ; Wed, 20 May 2015 15:27:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D397E1A9301 for ; Wed, 20 May 2015 15:27:30 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.166.22; Wed, 20 May 2015 22:27:29 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0166.017; Wed, 20 May 2015 22:27:28 +0000 From: Andrei Popov To: "mrex@sap.com" Thread-Topic: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi Thread-Index: AdCSLOLGJVnE1j84SD6Bm7bXqoznGwAJP6uQAAXX/AAAODgicA== Date: Wed, 20 May 2015 22:27:28 +0000 Message-ID: References: <20150519192316.74DA91B310@ld9781.wdf.sap.corp> In-Reply-To: <20150519192316.74DA91B310@ld9781.wdf.sap.corp> 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=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:ed31::5] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 3:eTaidhdUlv/gfroOpNWtLDovF32etpzsWcj2kA+sZZi4VgFvb/AFC2QXU4tOICngUHVkeTcKdRQ22sKmhpHpKhT+rAvyC2regcpm7UyTBJ/P7XFMJZMiMRL/Dm8/pi31wOOdZfnTv4JCoSYDHsdIbQ==; 10:zw0WY58mkwN368P+kZWma50pyaj7Ja/TX2U2+JkQ02QRnCRsmmGDHnHNf5CZXa7pnjJ7OyyLa4p2TazE4NhEFZ8yChZql2ELUHB2cJsbxog=; 6:rPhTKnmiTRaJhOe6dgrpnGLBrs6+5KGuPs+9c4M7LX6Zmb4m9b5iBrSUWdl+vuts x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 0582641F53 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(54094003)(189002)(377454003)(199003)(13464003)(24454002)(51704005)(54356999)(76176999)(50986999)(68736005)(64706001)(5001860100001)(99286002)(5001830100001)(2950100001)(2900100001)(15975445007)(102836002)(77096005)(86362001)(76576001)(2351001)(106356001)(2501003)(5001960100002)(110136002)(86612001)(77156002)(62966003)(122556002)(189998001)(40100003)(19580405001)(87936001)(33656002)(2656002)(46102003)(74316001)(101416001)(19580395003)(5001920100001)(92566002)(105586002)(81156007)(97736004)(4001540100001)(7059030)(219693003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2015 22:27:28.0502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Cc: "" Subject: Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 22:27:32 -0000 This isn't about a specific TLS implementation. As Ryan explained (http://w= ww.ietf.org/mail-archive/web/tls/current/msg16238.html), servers today have= to deviate from the certificate_list ordering requirements for a variety o= f practical reasons. Clients can't take advantage of these requirements, be= cause servers violate them. So if neither clients nor servers can in practi= ce implement this RFC language, why don't we drop it? Cheers, Andrei -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Tuesday, May 19, 2015 12:23 PM To: Andrei Popov Cc: Peter Gutmann; Subject: Re: [TLS] relax certificate_list requirements - opinion call (was = Re: [tls13-spec] relax certificate_list ordering requirements to match curr= ent practice (#169)) I wonder if anyone is reading the full subject line or= does it just get truncated at some poi Peter Gutmann wrote: > Dave Garrett writes: >=20 > >Who else is in favor or against, at the moment? >=20 > I'm in favour of relaxing the requirements to match real-world practice. Andrei Popov wrote: > > +1. Since we're not going to change implementations to conform > to the current strict requirements (because it would have been a=20 > breaking change), we can as well relax the requirements. Please do not mess this up *again* -- and clearly sort out where you see an= y requirements that you feel are a problem. The existing text does not place *ANY* requirement on what the client may a= ccept. The requirements are exclusively about what the server is required = to send. Andrei: Is it possible to make Microsoft SChannel send arbitrary heaps of = certificates in the Server Certificate handshake message? If yes, how is i= t exactly configured what junk in what order gets sent? Or were you actually thinking about client behaviour -- where the existing = text does not (and never intended to) place any specific behaviour. -Martin From nobody Wed May 20 15:55:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208131AC3E1 for ; Wed, 20 May 2015 15:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 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_NONE=-0.0001] 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 lmjOAS9-rzHG for ; Wed, 20 May 2015 15:55:14 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E61911AC3D8 for ; Wed, 20 May 2015 15:55:14 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id B8F542004F320; Wed, 20 May 2015 15:55:14 -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:content-transfer-encoding; s= cryptonector.com; bh=9YWf3mKWAhAfgmwkL8GRDrk+iDA=; b=mZM8M2Sz/GV lOU6M8pKxjN3AM68y9h8V/ghgOtdZe2TG9Vr9jqPY5XQp+ON0KLy8WTkiiy8vvks eI0Yrs0LhJJXQqwh3yNaupwhBBj4pxx9JNuKQGfXnrCtvqVh3INRjz9UMzNZLDum r/Cn1jeryMcs5O6sZLeZej6g7H+fZ3Tw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id 4440B2004F31E; Wed, 20 May 2015 15:55:14 -0700 (PDT) Date: Wed, 20 May 2015 17:55:13 -0500 From: Nico Williams To: Yoav Nir Message-ID: <20150520225512.GI19183@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 22:55:16 -0000 On Thu, May 21, 2015 at 12:48:57AM +0300, Yoav Nir wrote: > I notice that while the draft doesn=E2=80=99t say that explicitly, it u= ses > existing *_ECDHE_* ciphersuites, so that no new ciphersuites are > required, despite the fact that this ECDHE has different point formats > and different back-end math than the existing ECDHE. I wonder if we > can also get away with using *ECDSA* ciphersuites for EdDSA > signatures. I think so. That would be excellent. (One case of not adding a factor to the ciphersuite cartesian product. Rejoice.) From nobody Wed May 20 17:22:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77991ACD48 for ; Wed, 20 May 2015 17:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.151 X-Spam-Level: X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 Q90VBN1EroBg for ; Wed, 20 May 2015 17:22:25 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9F81ACD39 for ; Wed, 20 May 2015 17:22:25 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 4ACAA2BC79; Thu, 21 May 2015 02:22:23 +0200 (CEST) X-purgate-ID: 152705::1432167743-0000413A-275A46C6/0/0 X-purgate-size: 2823 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3507E4116B; Thu, 21 May 2015 02:22:23 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 27E1F1B317; Thu, 21 May 2015 02:22:23 +0200 (CEST) In-Reply-To: To: Andrei Popov Date: Thu, 21 May 2015 02:22:23 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150521002223.27E1F1B317@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "" Subject: Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 00:22:28 -0000 Andrei Popov wrote: > > This isn't about a specific TLS implementation. As Ryan explained > (http://www.ietf.org/mail-archive/web/tls/current/msg16238.html), > servers today have to deviate from the certificate_list ordering > requirements for a variety of practical reasons. Clients can't take > advantage of these requirements, because servers violate them. > So if neither clients nor servers can in practice implement this > RFC language, why don't we drop it? Not adhering to the requirements will cause *REAL* interoperability problems in the installed base, because there are implementations that will fail if TLS peers start sending junk. For 13 years, our implementation was very strict and tolerated not even duplicates nor incorrect order of path certificates Currently, the amount of TLS servers and TLS clients that are sending junk seems to either negigible small, or limited to pure Web-Browser to third-party Web-Server scenarios, i.e. pretty much none of our customers are trying to make our software interoperate with such clients or servers. I get to see most non-trivial SSL interop problems that our customers report for usage scenarios, and what I've seen looks like a _very_low_ number of misconfigured Apaches with OpenSSL with these three kinds of problems: - missing path CA certificates (e.g. yesterday, after a service provider for invoicing has switched from a verisign-issued server certificate, where it properly sent all path certificates to a GeoTrust-issued server certificate, where the server is sending only the server certificate) - duplicate certificate in the chain - garbled certificate chain (wrong oder of path certificates) For the handful of customers who had that interop problem, contacting the server admin and having them fix their server configuration was possible every time, and I could point to the spec after analyzing the problem to pass the blame. So what "flexibility" there is in some implementations is much less relevant than with how much actual abuse there currently is in the installed base. And to me, the visible level of abuse is low, so the resulting amount of de-facto interop problems is low. The only motivation that has been given for changing the requirements is that folks consider it necessary to promote the amount of abuse in the installed base -- which is going to create interoperability problems and headaches as a result. For those who have been and still are ignoring the requirements in the specification today, why do you need these requirements changed? You seemed to not have a problem ignoring the reasonable guidance (that greatly simplifies implementations) all the time anyway -- you evidently do not need this change. -Martin From nobody Wed May 20 19:15:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02C51ACE69 for ; Wed, 20 May 2015 19:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 SrHYVVRf989O for ; Wed, 20 May 2015 19:15:54 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B381ACE6D for ; Wed, 20 May 2015 19:15:54 -0700 (PDT) Received: by qctt3 with SMTP id t3so32850870qct.1 for ; Wed, 20 May 2015 19:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=wW6uTZQPdRHSXiwwqeg6J6QoYGtTCHzAvvwp0n9FiqA=; b=CSEO1AVgr4c1aE4MCYLmbSfIBQl9w4M7DCUNV9vo67xjl8brp1HN53wj2+9Yu1tCG9 n/0zlORcg44bFODobviALgLz7YQxibDDGaOGVO1oSRMEMK8uDFcoGiC/N+ZNweeFsu4V yM5GFOy6VcBIS9pD3d6vKxN7teyNRZHQbTVJUQuBgceHMvjsobSpsFo56kzxiRAQPLtk lufsqD2u1prBxkHUDOkP1CWZkm0/ixwruslcIWWv9604tCXIHEmhCNBA0KFew5p5Kp/5 Gl5ludFgH6K5a7cWqcyxxxG6hZ1KuEHXnXEDfHSBCNYhXICF3WWdCkGY+Kch1yePKBOX sn8g== X-Received: by 10.140.42.105 with SMTP id b96mr443362qga.105.1432174553990; Wed, 20 May 2015 19:15:53 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id k85sm12464727qkh.48.2015.05.20.19.15.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 May 2015 19:15:53 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, mrex@sap.com Date: Wed, 20 May 2015 22:15:51 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150521002223.27E1F1B317@ld9781.wdf.sap.corp> In-Reply-To: <20150521002223.27E1F1B317@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505202215.52302.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 02:15:56 -0000 On Wednesday, May 20, 2015 08:22:23 pm Martin Rex wrote: > Currently, the amount of TLS servers and TLS clients that are sending > junk seems to either negigible small, or limited to pure Web-Browser to > third-party Web-Server scenarios, i.e. pretty much none of our customers > are trying to make our software interoperate with such clients or servers. [...] > For the handful of customers who had that interop problem, contacting > the server admin and having them fix their server configuration was > possible every time, and I could point to the spec after analyzing > the problem to pass the blame. Thank you for posting the actual concrete reason why you're opposing this. That said, your argument is basically just that it doesn't affect you so it's not worth dealing with. TLS is a general security protocol used on the Web, not just by your customers. In the same way that IoT people will have to deal with stuff that isn't ideal for tiny embedded systems, people not accustomed to the mess that is the Web will have to deal with stuff that isn't ideal for people who can actually contact server admins every time. The ability to reliably contact server admins to deal with interop reports from users sounds wonderful, but it's a fantasy to us trying to triage the mess on the Web side of the spectrum. Seriously; we're not debating this issue from the same world, but TLS has to operate in both. Also, I don't care about blame; I don't want to pass the buck; I just want the thing to work (without affecting security, which this does not). > in the installed base -- which is going to create interoperability > problems and headaches as a result. You're worried about creating the reality that already exists. (replying to quote out of order) > Not adhering to the requirements will cause *REAL* interoperability > problems in the installed base, because there are implementations > that will fail if TLS peers start sending junk. For 13 years, > our implementation was very strict and tolerated not even duplicates > nor incorrect order of path certificates The requirements are still a SHOULD, though. As said elsewhere, unless an actual case as to why not to can be provided, a SHOULD should be interpreted as a MUST. In your case of an admin screw up, you still can point at it and say "I told you so". (Though, I'd much rather the server implementor fix the fact that the admin was capable of configuring it wrongly in the first place.) If you get a list you can't parse because of two intermediates that are different but both valid, yeah, you'll want to update your implementations to handle that. If you want a hard requirement of an aborted handshake and error message on something stupid like an exact duplicate, I'd actually be on your side for that one, but I suspect others would not be. > For those who have been and still are ignoring the requirements in > the specification today, why do you need these requirements changed? I'm going to point to Ryan's big post again: https://www.ietf.org/mail-archive/web/tls/current/msg16238.html If all paths the server has can be provided to the client, then various different clients with different capabilities can all be supported, and the server can transition to newer capabilities with less breakage. This is directly helpful to adoption rates in the real world. A tactic of forcing everyone to "Break the Web" and just cut off the old stuff all at once might actually be a better idea, but you try convincing anyone to actually do that. We can't even kill off stuff like insecure fallback that was _never_ legitimate. :/ Dave From nobody Wed May 20 19:35:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6EC1ACE7C for ; Wed, 20 May 2015 19:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 Ujj0Y4_Xm5iv for ; Wed, 20 May 2015 19:35:07 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471C71ACE78 for ; Wed, 20 May 2015 19:35:07 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 5A1EF458A1; Thu, 21 May 2015 04:35:05 +0200 (CEST) X-purgate-ID: 152705::1432175705-0000413A-4EA279CA/0/0 X-purgate-size: 2465 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4003B411BE; Thu, 21 May 2015 04:35:05 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 34E031B317; Thu, 21 May 2015 04:35:05 +0200 (CEST) In-Reply-To: <201505202215.52302.davemgarrett@gmail.com> To: Dave Garrett Date: Thu, 21 May 2015 04:35:05 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150521023505.34E031B317@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 02:35:09 -0000 Dave Garrett wrote: > On Wednesday, May 20, 2015 08:22:23 pm Martin Rex wrote: >> Currently, the amount of TLS servers and TLS clients that are sending >> junk seems to either negigible small, or limited to pure Web-Browser to >> third-party Web-Server scenarios, i.e. pretty much none of our customers >> are trying to make our software interoperate with such clients or servers. >[...] >> For the handful of customers who had that interop problem, contacting >> the server admin and having them fix their server configuration was >> possible every time, and I could point to the spec after analyzing >> the problem to pass the blame. > > That said, your argument is basically just that it doesn't affect you so it's > not worth dealing with. TLS is a general security protocol used on the Web, > not just by your customers. In the same way that IoT people will have to > deal with stuff that isn't ideal for tiny embedded systems, people not > accustomed to the mess that is the Web will have to deal with stuff that > isn't ideal for people who can actually contact server admins every time. > > The ability to reliably contact server admins to deal with interop reports > from users sounds wonderful, but it's a fantasy to us trying to triage the > mess on the Web side of the spectrum. Seriously; we're not debating > this issue from the same world, but TLS has to operate in both. You are totally missing the point. I *DO* care quite a lot about interoperability, and about the amount of work that others will have to interop with us. The issue here is about improving implementations that they become easier to use. It is not possible to "misconfigure" our SSL implementation so that it sends junk in the TLS handshake. The admin will face an error and a refusal to install&use an incomplete certificate chain on the server side, so that no peer will ever have to deal with the problem with our software sending junk in a Certificate handshake messages. I added this check into our PKI credentials maintenance on purpose about a decade ago. The proposed change does not encourage other implementers to improve their implementations to catch and complain problems as soon as they are created to the person that is in the best position to fix it, but rather the opposite. Because I *DO* care, I do not want to see others promoting a mess that currently seems to be limited (and still fixable). -Martin From nobody Wed May 20 20:21:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981591ACEB3 for ; Wed, 20 May 2015 20:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 eGmrFnnc47YB for ; Wed, 20 May 2015 20:21:53 -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 BE5951ACEBA for ; Wed, 20 May 2015 20:21:53 -0700 (PDT) Received: by qkgx75 with SMTP id x75so45305498qkg.1 for ; Wed, 20 May 2015 20:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=86d32JP1gT85yjhNW8vFX+gnUnhRHWnn0nXHcXQHqq0=; b=KnaOYWyZySr0m2ycUF4TmpC4zr9nPB2m8zXTRm8J0V7iiaZnYYYyjkE97ujb/tumjQ rUe0Fa/V6KY0PT4IcP4w2ML+BtOvZpA3r7EUrBEfQw3FIgH6rQzm1LTkK25JtIen4Sej 40lr3wnacPK0AqSVE/lJ2iuJtW6dSx/oSe+/H3X1ZcoFgpTQwS57AKH5xNRxVa6q7gZ9 42jtjYMIYvTGE8hIRhTOd/M9yYO97SBWtTYd8UNOaWRFEadkVAtE11BNO3iitrJsGupu cYH5zev7EzWPME06rMaChiOzxSYlgRieoLIKfm2g9C2V0AjCjS8uWJKvefTFCimyuuQT /TWA== X-Received: by 10.55.21.8 with SMTP id f8mr1286356qkh.2.1432178513050; Wed, 20 May 2015 20:21:53 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 18sm12485734qgh.40.2015.05.20.20.21.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 May 2015 20:21:52 -0700 (PDT) From: Dave Garrett To: mrex@sap.com Date: Wed, 20 May 2015 23:21:51 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150521023505.34E031B317@ld9781.wdf.sap.corp> In-Reply-To: <20150521023505.34E031B317@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505202321.51733.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 03:21:55 -0000 On Wednesday, May 20, 2015 10:35:05 pm Martin Rex wrote: > The issue here is about improving implementations that they become > easier to use. It is not possible to "misconfigure" our SSL implementation > so that it sends junk in the TLS handshake. But it is very possible to do that with other server implementations. Yeah, you could say it's _because_ clients allowed otherwise, but... they _did_. Here's a 7 year old post from this list that I stumbled over when searching for info on the topic: https://www.ietf.org/mail-archive/web/tls/current/msg02962.html This is not a new issue. Sorry, you lost this argument a decade ago and we're trying to clean up the mess after the fact. It's a topic that apparently didn't get discussed properly in the past, and I'm trying to change that so that interop doesn't get worse. > The proposed change does not encourage other implementers to improve > their implementations to catch and complain problems as soon as they > are created to the person that is in the best position to fix it, As I said prior, this is where I agree with you and disagree with Ryan. It is, however, only something that can be done if everyone enforces it, which is most certainly not the case. Strictly enforcing this is simply not viable. This would've needed to have been done at the end of the prior century to be a thing we could rely on. Someone else suggested creating a TLS implementation test suite that everyone could be expected to pass in order to ensure the known pitfalls are all addressed. That would really help with this sort of issue. > that currently seems to be limited (and still fixable). Sorry, it's not. You're very lucky to be in an environment where server crap is fixable to deal with clients enforcing the spec fully. Again, there are also legitimate reasons to have lists that are not strictly linear, and planning for them is very helpful. Dave From nobody Wed May 20 23:10:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932D21A0196 for ; Wed, 20 May 2015 23:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.412 X-Spam-Level: X-Spam-Status: No, score=0.412 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RAZOR2_CHECK=0.922, 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 UMJ3Lqlj24_X for ; Wed, 20 May 2015 23:10:15 -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 CFD8D1A01F4 for ; Wed, 20 May 2015 23:10:14 -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=1432188614; x=1463724614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ipUuxZWu4oVjI9B2DGYjpyTYxpdvn/msm7Is+Ex7KBE=; b=r08Jg2q8GF+hvc0rSX1GkNYKqTZu81bFz8iIaPphp/6GMi1pfhbEBUHF IeqS4TO2pfBCn5D+A2ffhCfvPJjakxGbev8nWS8lu1gtbuBId+LVUTPx0 Jx2wmOUSgD1EJkGjwxaYnnAG3EMc52lDgCdVMrFRwMoFVBChOlb6oaMU0 cqmWiPmJFlf4zqCogdFRoUYAeXVl5KKW+oCqYePYBvoVTm6c12JxFl2gr zqsnspcC+imf1VfwE3JK9ZOGDBy7qkKR4LEwD52bIADRPPeifMoAaVffg cgC4Kze/dtO5tMOObVUT7kjtKbgMkJeqBGezoRQVa73lM17LGshJ2vJSh A==; X-IronPort-AV: E=Sophos;i="5.13,466,1427713200"; d="scan'208";a="17317398" 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; 21 May 2015 18:10:08 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Thu, 21 May 2015 18:10:08 +1200 From: Peter Gutmann To: Nikos Mavrogiannopoulos , Watson Ladd Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkw4JVMtcBYvTQEKRMz73PbflFJ2F8257 Date: Thu, 21 May 2015 06:10:08 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> References: , <1432134170.2926.9.camel@redhat.com> In-Reply-To: <1432134170.2926.9.camel@redhat.com> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 06:10:18 -0000 Nikos Mavrogiannopoulos writes:=0A= >On Wed, 2015-05-20 at 10:05 -0400, Watson Ladd wrote:=0A= >> https://weakdh.org/=0A= >>=0A= >> Transcript hashing will solve this problem. In the meantime, you want=0A= >> to turn off DH_EXPORT.=0A= >=0A= >The interesting thing is that there are no DHE_EXPORT ciphersuites.=0A= =0A= No, the interesting thing (or more accurately the MASSIVE SCREAMING WTF) is= =0A= that there are widely-deployed web server and browser implementations out= =0A= there that will still use 512-bit keys. Not custom embedded environments= =0A= where you're using TLS as a privacy screen and anything that counters basic= =0A= packet sniffing is just fine, but production public-internet web servers an= d=0A= browsers. The point to make isn't "fancy security mechanism X would have= =0A= prevented this" but "why are these things still using crypto at the level o= f=0A= RC4_40_WITH_MD5" in 2015?=0A= =0A= Peter.= From nobody Thu May 21 00:29:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20F91A1BD1 for ; Thu, 21 May 2015 00:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPB3o7dNUfll for ; Thu, 21 May 2015 00:29:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 829671A1BCC for ; Thu, 21 May 2015 00:29:08 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4L7T7hE024930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 May 2015 03:29:07 -0400 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4L7T4uT003254 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 03:29:07 -0400 Message-ID: <1432193344.3243.2.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Santiago Zanella-Beguelin Date: Thu, 21 May 2015 09:29:04 +0200 In-Reply-To: <1432141085848.37685@microsoft.com> References: <1432141085848.37685@microsoft.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 07:29:10 -0000 On Wed, 2015-05-20 at 16:58 +0000, Santiago Zanella-Beguelin wrote: > Indeed, we are lazy and didn't want to write things like TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA in full. Are you sure you refer to TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA in that paper for the attack? I doubt this ciphersuite is supported by any browser at all, and for sure this ciphersuite is not supported by any web site (it requires an export DSA certificate, and there are none on the internet). regards, Nikos From nobody Thu May 21 00:46:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE931A212D for ; Thu, 21 May 2015 00:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWgUboFRTtk9 for ; Thu, 21 May 2015 00:46:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 E64421A6F20 for ; Thu, 21 May 2015 00:46:50 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4L7km3b001883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 May 2015 03:46:48 -0400 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4L7ki6J002042 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 03:46:46 -0400 Message-ID: <1432194404.3243.6.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Thu, 21 May 2015 09:46:44 +0200 In-Reply-To: References: <1432134170.2926.9.camel@redhat.com> <555CA61C.5090405@azet.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 07:46:52 -0000 On Wed, 2015-05-20 at 12:23 -0400, Watson Ladd wrote: > They do mean DHE_EXPORT to refer to dhe_rsa_export and dhe_dss_export, > as "defined" in RFC 2246. These are ciphersuite values. I stand corrected. It is an interesting attack, but it is very surprising to see ghosts like these ciphersuites present in real servers. regards, Nikos From nobody Thu May 21 00:49:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C871A6EE9 for ; Thu, 21 May 2015 00:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AFMRbjL-aBX for ; Thu, 21 May 2015 00:49:11 -0700 (PDT) Received: from BLU004-OMC1S28.hotmail.com (blu004-omc1s28.hotmail.com [65.55.116.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131FA1A3BA4 for ; Thu, 21 May 2015 00:49:11 -0700 (PDT) Received: from BLU177-W40 ([65.55.116.9]) by BLU004-OMC1S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 21 May 2015 00:49:10 -0700 X-TMN: [zneZ0y7HkzaTExIDjrSYSTlDBsQ1cxZ7] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Nikos Mavrogiannopoulos , Santiago Zanella-Beguelin Date: Thu, 21 May 2015 00:49:10 -0700 Importance: Normal In-Reply-To: <1432193344.3243.2.camel@redhat.com> References: , <1432141085848.37685@microsoft.com>, <1432193344.3243.2.camel@redhat.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 May 2015 07:49:10.0304 (UTC) FILETIME=[9F720200:01D0939A] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 07:49:12 -0000 AFAIK neither IE or Netscape ever supported=A0DHE_RSA_EXPORT either=2C and = when the EXPORT1024 suites was created they did not bother with DHE_RSA sui= tes either.=0A= =0A= ----------------------------------------=0A= > From: nmav@redhat.com=0A= > To: santiago@microsoft.com=0A= > Date: Thu=2C 21 May 2015 09:29:04 +0200=0A= > CC: tls@ietf.org=0A= > Subject: Re: [TLS] Another IRINA bug in TLS=0A= >=0A= > On Wed=2C 2015-05-20 at 16:58 +0000=2C Santiago Zanella-Beguelin wrote:= =0A= >> Indeed=2C we are lazy and didn't want to write things like TLS_DHE_DSS_E= XPORT_WITH_DES40_CBC_SHA in full.=0A= >=0A= > Are you sure you refer to TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA in that= =0A= > paper for the attack? I doubt this ciphersuite is supported by any=0A= > browser at all=2C and for sure this ciphersuite is not supported by any= =0A= > web site (it requires an export DSA certificate=2C and there are none on= =0A= > the internet).=0A= >=0A= > regards=2C=0A= > Nikos=0A= >=0A= >=0A= > _______________________________________________=0A= > TLS mailing list=0A= > TLS@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tls=0A= = From nobody Thu May 21 00:53:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8261A6F2D for ; Thu, 21 May 2015 00:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.001 X-Spam-Level: X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 hKxjzOlt7olS for ; Thu, 21 May 2015 00:53:41 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BDB81A6EE9 for ; Thu, 21 May 2015 00:53:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,467,1427752800"; d="scan'208,217,223";a="152297474" Received: from unknown (HELO [172.19.248.70]) ([64.88.227.134]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 21 May 2015 09:53:34 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_6AB1B475-C590-4AAE-87F2-53349AAD2826" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: <1432194404.3243.6.camel@redhat.com> Date: Thu, 21 May 2015 00:53:29 -0700 Message-Id: References: <1432134170.2926.9.camel@redhat.com> <555CA61C.5090405@azet.org> <1432194404.3243.6.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 07:53:43 -0000 --Apple-Mail=_6AB1B475-C590-4AAE-87F2-53349AAD2826 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 =46rom the protocol point of view, this is yet another instance of the = =93cross-protocol attack=94 [1.2] as we note in the longer version of the paper. The DHE_EXPORT signature = can be used=20 with DHE, enabling the attack. [1] D. Wagner and B. Schneier. Analysis of the SSL 3.0 protocol. In 2nd = Usenix Workshop on Electronic Commerce, 1996.=20 [2] N. Mavrogiannopoulos, F. Vercauteren, V. Velichkov, and B. Preneel. = A cross-protocol attack on the TLS protocol. In ACM CCS, pages 62=9672, = 2012. On 21 May 2015, at 00:46, Nikos Mavrogiannopoulos = wrote: > On Wed, 2015-05-20 at 12:23 -0400, Watson Ladd wrote: >=20 >> They do mean DHE_EXPORT to refer to dhe_rsa_export and = dhe_dss_export, >> as "defined" in RFC 2246. These are ciphersuite values. >=20 > I stand corrected. It is an interesting attack, but it is very > surprising to see ghosts like these ciphersuites present in real > servers. >=20 > regards, > Nikos >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_6AB1B475-C590-4AAE-87F2-53349AAD2826 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
=46rom the protocol point of view, this is yet = another instance of the =93cross-protocol attack=94 [1.2]
as = we note in the longer version of the paper. The DHE_EXPORT signature can = be used 
with DHE, enabling the = attack.

[1] D. Wagner and B. Schneier. Analysis of the = SSL 3.0 protocol. In 2nd Usenix Workshop on = Electronic Commerce, = 1996. 
[2] N. Mavrogiannopoulos, F. Vercauteren, V. Velichkov, and B. Preneel. A cross-protocol attack on the TLS protocol. In = ACM CCS, pages 62=9672, 2012.


On 21 May 2015, at 00:46, = Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:

On Wed, = 2015-05-20 at 12:23 -0400, Watson Ladd wrote:

They do mean DHE_EXPORT to refer to dhe_rsa_export and = dhe_dss_export,
as "defined" in RFC 2246. These are ciphersuite = values.

I stand corrected. It is an interesting = attack, but it is very
surprising to see ghosts like these = ciphersuites present in = real
servers.

regards,
Nikos


_____________________= __________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mail= man/listinfo/tls

= --Apple-Mail=_6AB1B475-C590-4AAE-87F2-53349AAD2826-- From nobody Thu May 21 01:02:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482241A6F05 for ; Thu, 21 May 2015 01:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dai7sDJEH3WX for ; Thu, 21 May 2015 01:02:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AF31A6F34 for ; Thu, 21 May 2015 01:02:03 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id B2388293307; Thu, 21 May 2015 08:02:02 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-204-20.brq.redhat.com [10.40.204.20]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4L81wGf025531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 04:02:00 -0400 Message-ID: <555D90F6.10103@redhat.com> Date: Thu, 21 May 2015 10:01:58 +0200 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Peter Gutmann , Nikos Mavrogiannopoulos , Watson Ladd References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 08:02:05 -0000 On 05/21/2015 08:10 AM, Peter Gutmann wrote: > Nikos Mavrogiannopoulos writes: >> On Wed, 2015-05-20 at 10:05 -0400, Watson Ladd wrote: >>> https://weakdh.org/ >>> >>> Transcript hashing will solve this problem. In the meantime, you want >>> to turn off DH_EXPORT. >> >> The interesting thing is that there are no DHE_EXPORT ciphersuites. > > No, the interesting thing (or more accurately the MASSIVE SCREAMING WTF) is > that there are widely-deployed web server and browser implementations out > there that will still use 512-bit keys. But removing that support is going to be tricky. If the server has only export-grade DH parameters (but does not actually support export cipher suites), and it is willing to negotiate DHE cipher suites, you end up with an interop failure, although you could well negotiate a reasonable secure connection without a forward secrecy cipher suite. Maybe we need SCSVs which express constraints on the size of the DH prime? If the server cannot match the constraints due to its configuration, then it would not use forward secrecy. That would give (me at least) much more confidence for large-scale roll-out. It would be a pity if, as a result of fixing this, more email is sent over the wire completely in the clear. -- Florian Weimer / Red Hat Product Security From nobody Thu May 21 01:10:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAB61A70FE for ; Thu, 21 May 2015 01:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCafKIMd3bav for ; Thu, 21 May 2015 01:10:02 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9D01A6F34 for ; Thu, 21 May 2015 01:10:02 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 17F098E6FE; Thu, 21 May 2015 08:10:02 +0000 (UTC) Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4L89xS8013552 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 04:10:00 -0400 Message-ID: <1432195799.3243.18.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Florian Weimer Date: Thu, 21 May 2015 10:09:59 +0200 In-Reply-To: <555D90F6.10103@redhat.com> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 08:10:03 -0000 On Thu, 2015-05-21 at 10:01 +0200, Florian Weimer wrote: > But removing that support is going to be tricky. If the server has only > export-grade DH parameters (but does not actually support export cipher > suites), and it is willing to negotiate DHE cipher suites, you end up > with an interop failure, although you could well negotiate a reasonable > secure connection without a forward secrecy cipher suite. > Maybe we need SCSVs which express constraints on the size of the DH > prime? If the server cannot match the constraints due to its > configuration, then it would not use forward secrecy. That would give > (me at least) much more confidence for large-scale roll-out. I think it would make sense to push for adoption of: https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09 However, that would not solve the incompatibility issue with old servers. For that to happen, either the whole DHE ciphersuite space has to be reassigned to new numbers, or move the DHE ciphersuites to the end of the client's list. regards, Nikos From nobody Thu May 21 02:30:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD371A906E for ; Thu, 21 May 2015 02:30:46 -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 8s2-02-l7q80 for ; Thu, 21 May 2015 02:30:45 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (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 4F4B61A905D for ; Thu, 21 May 2015 02:30:45 -0700 (PDT) Received: by wghq2 with SMTP id q2so79311770wgh.1 for ; Thu, 21 May 2015 02:30:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=QUZfKQwh5DsOEvRgvr7NKv97dbq2DsAOgcad3WzwiWs=; b=lx1zWsVUNvg7B8YsGo3yP9CsYrRm38ND9IAicTyOmVXxIqwKEHyt/XjGJOdkHMh4gS dqcKxNFQYUeKa6lN68rnkWh3Dh0Y35+g9BAhZfsmhKW/Ym3uUx3TKtVVumlQbohey6fz az/rXih7FOpoMC8Z6H4G96UH9trifejrX0o+T9VBqur/oxkmMiB7yuvSKPrF49HZxqX6 GkFajBBWC+S+sHZl7emrCLwB4+Li9BICXW1USuwuwUm29WUgJBCYYPY1Z/PTNjYguv87 s1iWt+uKXyrNK5FAUxvYoy55eIUggC//lXaFXx5siF/tHnAcl/1uTUGxsBc5PvR3FEvQ VqIA== X-Gm-Message-State: ALoCoQnQcLf2wRsKaxyBa3uMcsKHP9hZehqdm6nm8SE65phOwRsDl4gzO8Nl/OsOFZrKplj2/Qt8 X-Received: by 10.180.106.195 with SMTP id gw3mr4435735wib.25.1432200643909; Thu, 21 May 2015 02:30:43 -0700 (PDT) Received: from [10.60.20.24] ([193.170.94.190]) by mx.google.com with ESMTPSA id ex2sm31153032wjd.28.2015.05.21.02.30.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 02:30:42 -0700 (PDT) Message-ID: <555DA5C0.30409@azet.org> Date: Thu, 21 May 2015 11:30:40 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Joseph Salowey References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1177BA8A057978360DAB90FA" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 09:30:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1177BA8A057978360DAB90FA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Joseph Salowey wrote: > This is the WG call for adoption of: >=20 > https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt >=20 > This draft specifies the use of Curve25519 for ephemeral key exchange i= n > the TLS and DTLS. This draft serves as the starting point (it=E2=80=99= s expired > and needs to be updated in light > of http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/). If you > object to the adoption of this draft, please let us know why by 2015060= 2. No objection, adopt. Good that this is being worked on again. >=20 > Note: We=E2=80=99re not doing an early code point assignment for this d= raft, > because it clearly needs to resurrected and tweaked. Once that happens= , > there=E2=80=99s nothing stopping a request from the authors for an earl= y code > point assignment. Agreed. Aaron --------------enig1177BA8A057978360DAB90FA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIbBAEBCgAGBQJVXaXAAAoJEOTbZJL9ubXVWtcP9R2VsET0PPCF1MGJQM3RlDu3 ERa96HDEM+bAokIZRmez6Ps8wxXUTS8KEBRUWbxtEqAImvOcMc08YvR9rJe3P5yX HdUsUvN8XQF9+Ha4g2njq/JnOuNV+s5IJlwzq7WymPjiAAWVxVRggDU9Vq9uH9om 6fpJdxeWf6cmOpXjQqVeSbmh8fijDAqS0nh75dwLCP1/XObn2Ox1HHmGuFnmvkp8 5daCxCnsuM3dFIE/Cq7b7RSVkYIRKqqWVRvJdZNyiY0ZtJ8RcWq5sua6igdjZPqX ZQkhJiNdbENcn+7JkQcFKD31YDigZncPHIEIHVCOsiE+HAfePgqCl3npNXEZD0Qv JX2kIFGeJ0MeCVXw1rndyR0ulcwjOcnjELROCxxXW8c3Nem4nsZ8hvAWplzbupmA 4vjqNirUxtBqNu2v6+CJvKInvHsCal/llByoJIrWfsT8+X1+SKcQQZGWfDNT2SkM 8dvWbI8p0yZz81uDYSsylT4YqOxF5mALfoTUodUyhq0BsShphWb3K5qQw2g2yMFm TipLvReUlipkFmVvXaN8StgAP+GpOTqBOETtzNAczk4JG1k4ontkmB1uMiP0fP5N mHTYRVwM1tROR6aLKGRKQDZMVpM55AbaLCEKEezCTSWlUUlHbGS1zsvOeWhkVGeO LexgnzkDonOVyIirAT8= =vDT6 -----END PGP SIGNATURE----- --------------enig1177BA8A057978360DAB90FA-- From nobody Thu May 21 02:59:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FED1AC529 for ; Thu, 21 May 2015 02:59:41 -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 UNd5Ebsv1wnM for ; Thu, 21 May 2015 02:59:40 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378C91AC432 for ; Thu, 21 May 2015 02:59:39 -0700 (PDT) Received: from CO2PR03CA0036.namprd03.prod.outlook.com (10.141.194.163) by DM2PR0301MB0847.namprd03.prod.outlook.com (10.160.215.145) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 09:59:36 +0000 Received: from BN1BFFO11FD005.protection.gbl (2a01:111:f400:7c10::1:193) by CO2PR03CA0036.outlook.office365.com (2a01:111:e400:1414::35) with Microsoft SMTP Server (TLS) id 15.1.160.19 via Frontend Transport; Thu, 21 May 2015 09:59:36 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1BFFO11FD005.mail.protection.outlook.com (10.58.144.68) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Thu, 21 May 2015 09:59:35 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB030.064d.mgd.msft.net (141.251.50.210) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 21 May 2015 09:59:34 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Thu, 21 May 2015 09:59:34 +0000 From: Santiago Zanella-Beguelin To: Nikos Mavrogiannopoulos Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2FE+rTgAD1qgCAAClNNg== Date: Thu, 21 May 2015 09:59:33 +0000 Message-ID: <1432202373093.34978@microsoft.com> References: <1432141085848.37685@microsoft.com>,<1432193344.3243.2.camel@redhat.com> In-Reply-To: <1432193344.3243.2.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.151.241.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD005; 1:o83637sL92BIwBWVr4oiELC/O35nRBgn5T8Jyxfj69Mzx15RhjuTzErhIgg6aO/ovWwrKfrXdlDYEna4YKBaXQgx0Hy8svcgl5TQpNtQLT7jsow2jtCa9PCbZto9tY1kGdQVUUu3XgDAksozRNqWQtAI7SXrZifCkiImI496yFOdfzW5TgBboCZzg35vBi3GNjL8MPesQm1mSbi+jxXj6ahOHewTa4T+0CiARb+0dEY9vDUU6vux9mJenWuq1WiHMNV/O9XMr+COEFHRfqaPmCEjKBNS45tnlMaLyyM8zxmQOx5k5GB5R8R9Sj2SPcZo X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(24454002)(189002)(199003)(377454003)(377424004)(2656002)(6806004)(87936001)(16796002)(23756003)(189998001)(5001960100002)(110136002)(97736004)(81156007)(62966003)(77156002)(46102003)(5001860100001)(5001830100001)(2900100001)(2950100001)(92566002)(102836002)(86612001)(68736005)(19580395003)(69596002)(19580405001)(86362001)(86146001)(117636001)(54356999)(47776003)(76176999)(50986999)(106116001)(66066001)(4001540100001)(64706001)(106466001)(50466002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0847; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0847; 2:T9qiVFBoI2A5f9gYMCaF4RwoQoM4Mv/ny9DI2O5/kQQuqVFlaSmQT2bjY0NfyDuq; 2:wcDWv+VrJwavzWKbKh9XOaoI6mVJXRBu6l/kj557YoYdgWDk8WnzHxvkYSy/34m8yEcN7ZzPqnaaLep/2IgvInWklPoLC4KPxx0I9ehK/sp181YJCEJSfVVMVdC2m9PnFEhy7VWvZrp9OfiYA7cOVwme8X0YYPvELHQNbc+heLsiUQxvQ4ScSra5d7N1WLHzurONUM06qjq02WaoDAhjGGvphfjye9+kljfWnY5La9r7OH0t4ZBAQlAgorn6U0N/; 6:8nEzTWU0Ug9b7/hCe3wVcOnVmhHAYUHtCakmuGJh6LBt7TNxpxlzUDUZcOVHlJmhfl3C/XYLVPHfIenVNRlWC/AF/NjfQEwv0WLcN7TwfYNl5P0jHIK5XmwjxYrMfYoyG3C6n7QakVMfRoXJUqVF3FYAs3C3PDodI/K4YEEu3c+MMh/RbOu1RAQMJEMxG1f1X3aJAWj6eR2/EYpOqz81IWyPPGSsDSYKsftK8UQ5XZng7UJnwG0PE2hp4WlJtO6wGqQxOcHtJnVzTCfpxK5VS25oJL6M5Gbvwy2/9VPqwPxEyjMWvl1VeKdQlWo18Elt8eaJpGmz5VWPaI9sc8RirCvez8YzqDXdNvrcauwe5m/BdnJrJc0eCD8iGr+UUvCFaliJSXcmPhDdg068bRTFb+wznM0hiXo2NEsvyaeLBD4vogCAmJSKgkeBOQW18ilFoNeRNtkwoR2sF5vlL+yLWKXh3pnsDUajwYTxGaVMpx2lpbqwplgiW7EWfGO97eTi X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0847; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:DM2PR0301MB0847; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0847; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0847; 3:ZbCQzlVInSZVTLO4VS2GZXg1eeVHKhbIx8KgXAsOny6Tg6JDCXEGQifrpA8k6dqb3Hi87hS5oOMPUQKyRXrVSCJ7E3gKCx8CrhxqKspyOmlGMcFV2l8+pHtj9h48jYnk3Ww0TWvC00ydYgTleA5qTb4q385tCb809hLHBGJbZ0Lvyg08bY63AjBGhmM3O4EwkqcU9zR/K0bIU4EMLs/ihWBT3o3x3wrZlWWv0cP3HUGMt0BdOaz8+lOw7JVf0u0SqYi6OiY6ZgMfFUJGn0DXDc/CH7AS3woDfBPss7X2eqpbG2M4WT5KgDcl4sOCtyQ6 X-Forefront-PRVS: 0583A86C08 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DM2PR0301MB0847; 9:SXZKBjn87dp/FB8ZDan0kRLQXtJmflmV1J2g/5?= =?iso-8859-1?Q?N9P5pkZIs6KUV0Otl0BN44rAZI/tIE3KVeQ63IpM6LXb4MwkHXJh199lW8?= =?iso-8859-1?Q?szL8kJbjXjP6WEZr0tZCvwPS7uMo5C8YFIoonnehuNNQSt4RtMLsTnRsp3?= =?iso-8859-1?Q?Dianb1Xa7q0L3Z0cXXuvgjZP0IEKNBD84tCEBAP2DZIiwqRpwEF+TIjmDl?= =?iso-8859-1?Q?ss1iIBHJweWxqwSKsMIylL6GbMneN1HB1bgX9R8LdAtXR6Viv6IvSf2sSf?= =?iso-8859-1?Q?ohKWFN3Mn5p6cL8peVNOmRD7H1uEoTfML316C6uqZuN0JWTrStT4+Syvt1?= =?iso-8859-1?Q?+7MALOG9ygj25wJpcJe7MUZM+frOn9YLQPcTdx3ZSXbGpvecmbpZjSCVHX?= =?iso-8859-1?Q?cV7//UWt7x6/emePlojFKdVqUvDSyJKgAhs92g65lhViBrkElUIT0mlHGb?= =?iso-8859-1?Q?u4/CeH2YeC9QSKPu49iwNMg2wISw+txJGe3sqRBu0Qo66s6X0uqfvwcWnY?= =?iso-8859-1?Q?by9/hVXCm8zoxzkU2zCnoL0lO6flkSqATe82OMRmNE0Rb/Ibkbtx5dGKQT?= =?iso-8859-1?Q?EcrFdLwMiub50uv7PP3KOiYmVIhRq/zBL44wHlqrz1033LTt0aWlplpyoK?= =?iso-8859-1?Q?T294rhpBIsC5Oi6kxahAGSKVXcvYP/KQCgCSBhyU6RsIEkr4iySNjPdr//?= =?iso-8859-1?Q?1jNHLHEPjTDniKzScjBdwCU5uYYAJv+7NV9qq7/d5/zUBQp/Gm5a6aJYVU?= =?iso-8859-1?Q?HGysHzIR0sOFu2s/0xP/3iA7X50wfjdRTuJ6gg+3iu2rK9jdMztH1Bve/G?= =?iso-8859-1?Q?g3oybXHlN8Cet0opPVa7bd98m3lQt1X0vV/0kpm6bE1fe4bU0cfwOSF2j9?= =?iso-8859-1?Q?KX5RtwWu/Ys1drlCcmM+D4g+KYaqdv6ItAawQTlzgLgNdK+chwJY3yayKl?= =?iso-8859-1?Q?FjyvodIYAYA+M7mT7PBW+VGGfWjR85q2rVJwC3UWmy8fBoSNWVroIjzK7s?= =?iso-8859-1?Q?0IbAJ3A3jDQcMyAabqs3h9f0TLFD7V3hfj2wU0L9wtlSh7yT6nRlET1+Yc?= =?iso-8859-1?Q?X7sxJS6lB/yBZl/7BwUdTeB9PJzVU6+SYcNDQLalis5EaNGeNifFq6KI0g?= =?iso-8859-1?Q?0yuOF11RGzkoUOFIe6r8uvWAU8Txxz2nOBjz8loLKwuP+pX5HLU63nY4yv?= =?iso-8859-1?Q?Ht/vJgY4ysJT3+iw38koIuC44vw9yUvJrw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0847; 3:CA8rGMJEPpwmD1MOZKFDExTfIdMYPNZKXbUxd2KaKhSxEfb9rSAl+/EVW/1tvAtKTjEQUR+fFkzX9D2Rn3vnf9d8pIb7wABpnIu+VXYRuHt540Qy+lGq+Us0j52IbzlLG8SDvLtnHyQY/BqSOOnrwA==; 10:C9pvgR8lLy5+qTpNouJPlWmyFfcSVtsTFSTcfyiZXUzqRcR/fE82f0GeDQI15CdvXcbQfp6OHeehEZt1/aOnqKC5o97fWSkh7aacoNZnpAA=; 6:io9dNvHv5rtSR8pILP39rzimkGhLzNjs4ugy6GHrYPZ0U63EpmN3Tll/Xyylxdaw X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 09:59:35.2196 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0847 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 09:59:41 -0000 > Are you sure you refer to TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA in that p= aper for the attack? That was just an example, and you're right that's an uncommon ciphersuite.= =20 We did find many HTTPS servers supporting TLS_DHE_RSA_EXPORT_WITH_DES40_CBC= _SHA. Cheers, --Santiago ________________________________________ From: Nikos Mavrogiannopoulos Sent: Thursday, May 21, 2015 8:29 AM To: Santiago Zanella-Beguelin Cc: tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS On Wed, 2015-05-20 at 16:58 +0000, Santiago Zanella-Beguelin wrote: > Indeed, we are lazy and didn't want to write things like TLS_DHE_DSS_EXPO= RT_WITH_DES40_CBC_SHA in full. Are you sure you refer to TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA in that paper for the attack? I doubt this ciphersuite is supported by any browser at all, and for sure this ciphersuite is not supported by any web site (it requires an export DSA certificate, and there are none on the internet). regards, Nikos From nobody Thu May 21 03:02:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43781AC529 for ; Thu, 21 May 2015 03:02: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_40=-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 rl74psV8wyJJ for ; Thu, 21 May 2015 03:02: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 4CF831AC7E8 for ; Thu, 21 May 2015 03:02:22 -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=1432202542; x=1463738542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ur6zE8g1lykfbx88zwPUpVkovbbBNrW9dQh/wMwj1bo=; b=4GFPPFuU3CRSfIgpxVoUfPB3HFZiwcmTv1pZ3a0abdzt+o+BrM5d5ics SA74BJie8f7ZigywkZcC1XMXaJOtCcmGTJcVnz9FkVwcW01u4B7k9aPhf 6Q7ooTWQTzUWfr3rj6iB+FLsweKsjjFCP33fdi8U/SnOMOSbUP5vK3F/G 2MSuXJadhqVyYnsCNASZWsBr05bhXAKEcttfhFM4YgRVTAUXk12GGK9fU tqULgSSc4IcP5uA4Dr/42WWbn6+khnxUD4MnZ2WRZEH9Ksm6HiR1B/B/b eTyU/ekngEdc1H+NLp2A4nu7EnpiHneJzE/XudGaZLQbt7XKCmK6h4vmR Q==; X-IronPort-AV: E=Sophos;i="5.13,468,1427713200"; d="scan'208";a="17342568" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 May 2015 22:02:20 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 21 May 2015 22:02:20 +1200 From: Peter Gutmann To: Santiago Zanella-Beguelin , "Nikos Mavrogiannopoulos" Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvVMtcBYvTQEKRMz73PbflFJ2FE+rTgAAsgACAACoLgIAAyXnu Date: Thu, 21 May 2015 10:02:19 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB028124@uxcn10-tdc05.UoA.auckland.ac.nz> References: <1432141085848.37685@microsoft.com>, <1432193344.3243.2.camel@redhat.com>, <1432202373093.34978@microsoft.com> In-Reply-To: <1432202373093.34978@microsoft.com> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 10:02:27 -0000 Santiago Zanella-Beguelin writes:=0A= =0A= >We did find many HTTPS servers supporting TLS_DHE_RSA_EXPORT_WITH_DES40_CB= C_SHA.=0A= =0A= Just to make sure that's not a typo, you're saying you *did* (not didn't) f= ind=0A= many servers supporting 40-bit DES as a cipher? Wow. How many approximate= ly,=0A= are we talking tens, thousands, millions?=0A= =0A= Peter.=0A= From nobody Thu May 21 03:10:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAAA1ACC8D for ; Thu, 21 May 2015 03:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 sIGc67npWDdn for ; Thu, 21 May 2015 03:10:19 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E97E1AC399 for ; Thu, 21 May 2015 03:10:19 -0700 (PDT) Received: from 236.168.251.212.customer.cdi.no ([212.251.168.236]:53476 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YvNQf-0007wG-Mh; Thu, 21 May 2015 12:10:17 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Santiago Zanella-Beguelin" , "Nikos Mavrogiannopoulos" , "Peter Gutmann" References: <1432141085848.37685@microsoft.com> <1432193344.3243.2.camel@redhat.com> <1432202373093.34978@microsoft.com> <9A043F3CF02CD34C8E74AC1594475C73AB028124@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Thu, 21 May 2015 12:10:07 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB028124@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Opera Mail/12.17 (Win32) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 10:10:22 -0000 On Thu, 21 May 2015 12:02:19 +0200, Peter Gutmann wrote: > Santiago Zanella-Beguelin writes: > >> We did find many HTTPS servers supporting >> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA. > > Just to make sure that's not a typo, you're saying you *did* (not > didn't) find > many servers supporting 40-bit DES as a cipher? Wow. How many > approximately, > are we talking tens, thousands, millions? For reference, in my 530K sample (Biased towards Alexa top million sites) there are 60000 servers (11.38%) that have that specific cipher suite enabled, as of Monday this week. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From nobody Thu May 21 03:11:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8199A1ACCE2 for ; Thu, 21 May 2015 03:11:11 -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 fCO6zEZ9ilUI for ; Thu, 21 May 2015 03:11: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 0F6781ACCE1 for ; Thu, 21 May 2015 03:11:08 -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=1432203069; x=1463739069; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=j4wGe8p4uI/1S7SJtubqzgtEYgbWwoDPTozWTTDtClY=; b=QV3UmGFAXgzu3mm4yoa7NckGd+io1s3psLAzsiCw//0fGuUfskhzqOQ8 uYHsTkIf5EdWaxWhfJZ7Td031nyZJgj+zxN77mqtrqZZaNC9ZxCt+z8Aw Q0G7aVqXMEvK1blZsBh6OF/xAqm4YoSpZ9SRkMkrcHn1NCF9RC+84n63r h5mkV1/1MjWK7SFb/o4CLQ+3Qclf03bNuzZN70dJQ8yueCvwZJLGPQsSY qk8TcgU/LcYVcO5dQlxygf02orJTdFSKtBA3ZkpRppgc7X7PwDit/3mnM bat83BMnxZfgJgxiwCzVFoN1F0bydgFVlqgXu0EewWlJGeXHkaEo1gkPP w==; X-IronPort-AV: E=Sophos;i="5.13,468,1427713200"; d="scan'208";a="17343403" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 May 2015 22:11:07 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Thu, 21 May 2015 22:11:07 +1200 From: Peter Gutmann To: Dave Garrett , "tls@ietf.org" , "mrex@sap.com" Thread-Topic: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi Thread-Index: AdCSLOLGJVnE1j84SD6Bm7bXqoznGwAJP6uQAAXX/AAAODgicP//WvuAgAAftICAAU2jZQ== Date: Thu, 21 May 2015 10:11:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB02813A@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20150521002223.27E1F1B317@ld9781.wdf.sap.corp>, <201505202215.52302.davemgarrett@gmail.com> In-Reply-To: <201505202215.52302.davemgarrett@gmail.com> 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: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 10:11:11 -0000 Dave Garrett writes:=0A= =0A= >That said, your argument is basically just that it doesn't affect you so i= t's=0A= >not worth dealing with. TLS is a general security protocol used on the Web= ,=0A= >not just by your customers.=0A= =0A= That was what I was going to reply to Martin's post with, "how many embedde= d=0A= devices did you sample when you came to the conclusion that the problem was= =0A= negligible"? I was only yesterday dealing with one, a PLC, that (a) return= ed=0A= a handshake failure if you connected to it with a TLS version greater than= =0A= 1.0, (b) sent out garbled (but arguably valid) DH parameters, (c) seemed to= =0A= order the certs in its chain at random (or at least it wasn't consistent ov= er=0A= multiple connections), and (d) had an invalid cert. Their defence was that= =0A= other vendors had been successfully interoperating with them for years, and= my=0A= code was at fault. However if your world consists only of IIS and Apache (= and=0A= presumably NetWeaver?) then it's easier to pretend that this stuff doesn't= =0A= happen.=0A= =0A= Peter.= From nobody Thu May 21 03:16:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E39F1ACC8D for ; Thu, 21 May 2015 03:16:32 -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 DisqPJLJEilP for ; Thu, 21 May 2015 03:16:30 -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 7DEC81ACC86 for ; Thu, 21 May 2015 03:16:30 -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=1432203390; x=1463739390; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uLZxmOrUt/iD0z5uUWvcRBBb0Kbh2/SZjXvz3Pkwhro=; b=lTyJBpliTCmL1sraco3KOLH/LLJcWDNqnuvXtrMKG8MlAOxGThABOAQ9 cnsJoE/CVifeVwhv7vjLOvMVQhGBTo2RrvkXQ/va11fN0A+I5MLYtlWwt RjJ8m9xsWyOhJoOgwIeXxkILQHSQgaKi/bTNWXA7cSJ/UQohkBNt3u6Tq MgFTvyXLUaGa7K5DIf+opwmCQNLYu9LglnEdhKInn2+1O3eaa+5eajSqT HMULm25n1KgdYw4/A99IfOcqqIUyeV50D5fvS1bb87NBRpTSoEPNTEZaa BvxAH4Zkj+fdYX3EMwna9bjaS1DyfqbgLU47uVJgCeItykNdlYsD2NKVq w==; X-IronPort-AV: E=Sophos;i="5.13,468,1427713200"; d="scan'208";a="17343854" 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; 21 May 2015 22:16:29 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Thu, 21 May 2015 22:16:29 +1200 From: Peter Gutmann To: "Yngve N. Pettersen" , Santiago Zanella-Beguelin , Nikos Mavrogiannopoulos Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvVMtcBYvTQEKRMz73PbflFJ2FE+rTgAAsgACAACoLgIAAyXnu//85e4CAAMnTAg== Date: Thu, 21 May 2015 10:16:28 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB028164@uxcn10-tdc05.UoA.auckland.ac.nz> References: <1432141085848.37685@microsoft.com> <1432193344.3243.2.camel@redhat.com> <1432202373093.34978@microsoft.com> <9A043F3CF02CD34C8E74AC1594475C73AB028124@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 10:16:32 -0000 Yngve N. Pettersen writes:=0A= =0A= >For reference, in my 530K sample (Biased towards Alexa top million sites)= =0A= >there are 60000 servers (11.38%) that have that specific cipher suite=0A= >enabled, as of Monday this week.=0A= =0A= Hmm, so what's the next escalation level beyond the previous "GIANT SCREAMI= NG=0A= WTF"? Perhaps a twelve-storey WTF with a magnificent entrance hall, carpet= ing=0A= throughout, 24-hour portage, and an enormous sign on the roof, saying 'This= Is=0A= a Major [0] WTF'?=0A= =0A= Peter.=0A= =0A= [0] Or perhaps General Sir Anthony Cecil Hogmanay Melchett.= From nobody Thu May 21 03:32:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBF11A7D84 for ; Thu, 21 May 2015 03:32:49 -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 0KTJKe1tbcYk for ; Thu, 21 May 2015 03:32:48 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 AA0F41A1B73 for ; Thu, 21 May 2015 03:32:47 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so8518876wic.1 for ; Thu, 21 May 2015 03:32:46 -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=SvVZI9FFFHV3ftiGGkPinwy19ScoWikZR1IQgfR8aCo=; b=NJVIJFiNJw/ef2KBEQ+KcyQWzjWbPTJegJiiWAlCp8yrHxp0e0SP/G8KHWMz3mcznM 1QA5jMiO8sXFIasoChueRBvdKi8A316eHHkKNSTn5HHGsX5R8PvA24ut5I68ZKxBNo2q HoqcRtCIldrxvDGknarYiSS3elTOFFymUKjlFxZv9OJFlrUkKDQ+a6O8MWlEY2f5ug4y 4NL5JPRwX5EhSwQ5F6gcEp3ezJxZ5sP+zZkCmNkdFgnrx1TnNH+HEsOBCP5cszETewv8 gukX4LxKYwLZYo6NT3y7Q9LTwBk6XBGUOo3qHTuM2LCnEsrlb+Mv6kui3EBfixY3/Gv2 VkKQ== X-Received: by 10.180.86.234 with SMTP id s10mr4853111wiz.50.1432204366435; Thu, 21 May 2015 03:32:46 -0700 (PDT) Received: from [172.24.248.107] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id j12sm31432068wjn.48.2015.05.21.03.32.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 03:32:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB028164@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Thu, 21 May 2015 13:32:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5B3D89E1-6C07-45B4-BCBA-0551EFEB4299@gmail.com> References: <1432141085848.37685@microsoft.com> <1432193344.3243.2.camel@redhat.com> <1432202373093.34978@microsoft.com> <9A043F3CF02CD34C8E74AC1594475C73AB028124@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB028164@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 10:32:49 -0000 > On May 21, 2015, at 1:16 PM, Peter Gutmann = wrote: >=20 > Yngve N. Pettersen writes: >=20 >> For reference, in my 530K sample (Biased towards Alexa top million = sites) >> there are 60000 servers (11.38%) that have that specific cipher suite >> enabled, as of Monday this week. >=20 > Hmm, so what's the next escalation level beyond the previous "GIANT = SCREAMING > WTF=E2=80=9D? =20 If the website turned out to be a bank or an HMO? From nobody Thu May 21 04:04:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BB11ACD9D for ; Thu, 21 May 2015 04:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RAZOR2_CHECK=0.922, 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 Qq7WKXE8Sr5F for ; Thu, 21 May 2015 04:04:49 -0700 (PDT) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2081ACD9A for ; Thu, 21 May 2015 04:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=B2r8Zv7FCl2fxVn8fu2Qb1MkjRH74VIg9/9DUUtzudM=; b=YUY4ItJJpf3D9DXdX/2L+xv6uvQn8b2W2vLBLguyvdUxL3gk81EYs7dkri52wIypu2Q05Jq6bdSaeCRyI2JNwkKdduJ/mrC4j3rDoWvoS0sWdoYKoL7PbDDcBhf1pZQr29K8yZGjevJdOXZmgesZhw60W0lcQm8sbUgq6Idp4AFw6TPLSEcGLyeBinR9NGYJvhYZaCuic/1+PrH9fM0EKA+zTEVRwsNGzWfgA6LgJDPILkQHNolb2T3+ohdhHQoJyUayMBhEdJEUDG9vNDTDHDdcryfqOLb0O9oVzWPtVLitYZnj15Pskf1A6S3n/H0MkRNqUgxrIqG80edj7BYBQQ==; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (envelope-from ) id 1YvOHP-0005ln-RF for tls@ietf.org; Thu, 21 May 2015 13:04:47 +0200 Message-ID: <555DBBC6.9040504@delignat-lavaud.fr> Date: Thu, 21 May 2015 13:04:38 +0200 From: Antoine Delignat-Lavaud User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <20150520145925.GA17676@LK-Perkele-VII> In-Reply-To: <20150520145925.GA17676@LK-Perkele-VII> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090000030608040101010207" Archived-At: Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 11:04:51 -0000 This is a cryptographically signed message in MIME format. --------------ms090000030608040101010207 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Le 5/20/2015 4:59 PM, Ilari Liusvaara a =E9crit : > On Wed, May 20, 2015 at 10:05:25AM -0400, Watson Ladd wrote: >> https://weakdh.org/ >> >> Transcript hashing will solve this problem. > AFAICT, extended_master_secret won't save you from this. This is correct. Unfortunately, the realization that the signature on=20 the ServerKeyExchange message suffers from the same weakness (it only=20 covers nonce instead of current session-hash) as the master key=20 derivation came a bit late into the session-hash draft standardization=20 (however, browser vendors were given ample time to address this issue). It is worth noting that Nikos had previously proposed to extend the=20 context coverage of the SKE signature to prevent a cross-ciphersuite atta= ck. It is not clear at this point whether draft-ietf-tls-session-hash can be = extended to replace nonces with the current session-hash in the SKE=20 signature without causing standardization issues. Antoine --------------ms090000030608040101010207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMeDCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPDCCBSSgAwIBAgIDCiD2MA0GCSqGSIb3DQEB CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNjAyMTEyMTQw WhcNMTUwNjAzMTkyMzIzWjBQMSMwIQYDVQQDDBphbnRvaW5lQGRlbGlnbmF0LWxhdmF1ZC5m cjEpMCcGCSqGSIb3DQEJARYaYW50b2luZUBkZWxpZ25hdC1sYXZhdWQuZnIwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnuB5o086zUAnLAP5jwwowGXdVyyjW3b+hPqxbfmqQ 80w++3Y9tq7g/hv3Du48+R56lso9WU+ztTPIosV0gengqZ+1qy9CiYlGCyIH7vvZYKUGBOEx sgUXXEhlthvABwFicde6kvS0lZKDV1CGIBAnr1Uw3TGE2dus7PczqVqz1xEgZl52yuDOQtH6 4tsk2gepdm3/4+SwQk97U0gUUkil99G241aKDf5v6RyAI3l98HPQgW++tkfhFSd4l1EKQP+m kGEfTho4Faquv/kObmCnVHwObLSymTpvddOAVX2uIEUYgH4+tRo1KTDu38nyqJ4Yt7/XR8OP GVWl8qpiEyI3AgMBAAGjggLgMIIC3DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFJPVqSTS3td9084jBAkk2K7OutkN MB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMCUGA1UdEQQeMByBGmFudG9pbmVA ZGVsaWduYXQtbGF2YXVkLmZyMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcG CCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEa gb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAx IFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJl bGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2Yg dGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz MS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQsFAAOCAQEAsrmvTlAjPMbOZmNv4xyzsazhr5nUL9J3JUt6xb/QbTnXvtd/ 7oOFS5BUIesckXyRtHA7zv3sCFShYM5I7WQ1SR2L0uAAwHq6v0k/ZcwKDQGqTTMO+tVX+PlS jf/zYXwa6JSpt2X8CuCVPbYXFElXT9ty9CBZ/yonFAvnhpnzwT1fSTpCv84OA8KVbZ62tHgD UZbl4jHk3NoJ1mVZtDmi5bfQuHgB0BNxx8o8mHVmCZU7Od+gvZ6EyJ70eSJIXGyEsafM/SHC Xef131DC4A2Lcef/ktHpYoE5URkn2JQZulEzAUSEL4yGBlm8IohGSlCsr1yuEMInsqv0QB3N OP0ehTGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Awog9jAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNTA1MjExMTA0MzhaMCMGCSqGSIb3DQEJBDEWBBTA72ulANbO4LPbCxoCCqJe 6WRXHjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDCiD2MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgMKIPYwDQYJKoZIhvcNAQEBBQAEggEAidMfLoygJo8xEny4/h// DjL8vx2P3gCeMATUVlfJnFZ6OcPYoH9i/tr7of9P0yiV+/IIYCCqvWIZ4CLCZ2cfoL0coMuO ge/KJ77KYfEWFKKRO/BbAh41rxSJvrQcpDvdZL9sFDIUdemazdesJNaubHOowBDPMEOvRMFa iXiLMP958w+pofxSdrze0fcR5yPBbsd4ZO2aBfS3p1S5xMpkUaG4LQIkZ0rVb/zeRtrvTNFh uVVOH2WIR6Q+QtGMmL0PhdlNQcDVtULEtviBUCJEZjfXGsST79bwEH2HpmITVWhC4L60aIPL CbMzO0YnV6iV3pqhrJtfIy86lHw5DsT+5QAAAAAAAA== --------------ms090000030608040101010207-- From nobody Thu May 21 04:10:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3611ACD9A for ; Thu, 21 May 2015 04:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwj7XbqH7u5J for ; Thu, 21 May 2015 04:10:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 40BB21ACDA3 for ; Thu, 21 May 2015 04:09:35 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4LB9XPe023856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 May 2015 07:09:33 -0400 Received: from oldenburg.str.redhat.com (ovpn-204-20.brq.redhat.com [10.40.204.20]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4LB9UQe014300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 07:09:32 -0400 Message-ID: <555DBCE6.7080308@redhat.com> Date: Thu, 21 May 2015 13:09:26 +0200 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> In-Reply-To: <1432195799.3243.18.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 11:10:02 -0000 On 05/21/2015 10:09 AM, Nikos Mavrogiannopoulos wrote: > On Thu, 2015-05-21 at 10:01 +0200, Florian Weimer wrote: > >> But removing that support is going to be tricky. If the server has only >> export-grade DH parameters (but does not actually support export cipher >> suites), and it is willing to negotiate DHE cipher suites, you end up >> with an interop failure, although you could well negotiate a reasonable >> secure connection without a forward secrecy cipher suite. >> Maybe we need SCSVs which express constraints on the size of the DH >> prime? If the server cannot match the constraints due to its >> configuration, then it would not use forward secrecy. That would give >> (me at least) much more confidence for large-scale roll-out. > > I think it would make sense to push for adoption of: > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09 Interesting. But do we want to encourage the use of additional magic primes? > However, that would not solve the incompatibility issue with old > servers. You mean, if the client rejects handshakes with defective primes, it will not be able to connect to servers which use them? -- Florian Weimer / Red Hat Product Security From nobody Thu May 21 04:15:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FCA1ACDAE for ; Thu, 21 May 2015 04:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9Z0duBuBfKH for ; Thu, 21 May 2015 04:15:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1291ACDA3 for ; Thu, 21 May 2015 04:15:12 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id AFEE06C for ; Thu, 21 May 2015 11:15:11 +0000 (UTC) Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBF94o021348 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 07:15:11 -0400 Message-ID: <1432206909.3243.45.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Florian Weimer Date: Thu, 21 May 2015 13:15:09 +0200 In-Reply-To: <555DBCE6.7080308@redhat.com> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 11:15:13 -0000 On Thu, 2015-05-21 at 13:09 +0200, Florian Weimer wrote: > >> But removing that support is going to be tricky. If the server has only > >> export-grade DH parameters (but does not actually support export cipher > >> suites), and it is willing to negotiate DHE cipher suites, you end up > >> with an interop failure, although you could well negotiate a reasonable > >> secure connection without a forward secrecy cipher suite. > >> Maybe we need SCSVs which express constraints on the size of the DH > >> prime? If the server cannot match the constraints due to its > >> configuration, then it would not use forward secrecy. That would give > >> (me at least) much more confidence for large-scale roll-out. > > I think it would make sense to push for adoption of: > > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09 > Interesting. But do we want to encourage the use of additional magic > primes? We do the same with elliptic curves. We agreed on some groups and use these for simplicity. With arbitrary groups, a client cannot verify the quality of the parameters of the provided group by the server. It can only check its size which is an insufficient test if a client wants to enforce a particular security level. > > However, that would not solve the incompatibility issue with old > > servers. > You mean, if the client rejects handshakes with defective primes, it > will not be able to connect to servers which use them? The use case that will fail, is if there is a server which is configured to prefer DHE ciphersuites, and is setup with 512-bit primes, then no client will be able to connect to it, unless it disables DHE. regards, Nikos From nobody Thu May 21 04:20:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CCE1ACDE5 for ; Thu, 21 May 2015 04:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpuWA0dkKC2c for ; Thu, 21 May 2015 04:20:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 61C821ACDD0 for ; Thu, 21 May 2015 04:20:34 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBKXfB030499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 21 May 2015 07:20:34 -0400 Received: from oldenburg.str.redhat.com (ovpn-204-20.brq.redhat.com [10.40.204.20]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBKVVB023844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 07:20:33 -0400 Message-ID: <555DBF7E.9050807@redhat.com> Date: Thu, 21 May 2015 13:20:30 +0200 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> In-Reply-To: <1432206909.3243.45.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 11:20:35 -0000 On 05/21/2015 01:15 PM, Nikos Mavrogiannopoulos wrote: >> Interesting. But do we want to encourage the use of additional magic >> primes? > > We do the same with elliptic curves. I think the situation with curves is markedly different because individual curves can have quite different properties. With safe DH primes of similar size, one is presumably as good as the other. > We agreed on some groups and use > these for simplicity. With arbitrary groups, a client cannot verify the > quality of the parameters of the provided group by the server. It could still run a primality check on (p - 1) / 2. > It can only check its size which is an insufficient test if a client wants to > enforce a particular security level. On the other hand, a broken server might leak key material by other means, and if that happens, there is nothing a client can do about that. >>> However, that would not solve the incompatibility issue with old >>> servers. >> You mean, if the client rejects handshakes with defective primes, it >> will not be able to connect to servers which use them? > > The use case that will fail, is if there is a server which is configured > to prefer DHE ciphersuites, and is setup with 512-bit primes, then no > client will be able to connect to it, unless it disables DHE. Yes, this is a tough scenario to solve. -- Florian Weimer / Red Hat Product Security From nobody Thu May 21 04:31:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5371ACE96 for ; Thu, 21 May 2015 04:31: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, 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 KsatrP1fBUwz for ; Thu, 21 May 2015 04:31:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564C21ACE7A for ; Thu, 21 May 2015 04:31:09 -0700 (PDT) Received: from BN3PR0301MB0833.namprd03.prod.outlook.com (10.160.154.143) by BN3PR0301MB1249.namprd03.prod.outlook.com (10.161.207.25) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 11:31:08 +0000 Received: from BN3PR0301CA0067.namprd03.prod.outlook.com (10.160.152.163) by BN3PR0301MB0833.namprd03.prod.outlook.com (10.160.154.143) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 11:31:06 +0000 Received: from BN1BFFO11FD032.protection.gbl (2a01:111:f400:7c10::1:138) by BN3PR0301CA0067.outlook.office365.com (2a01:111:e400:401e::35) with Microsoft SMTP Server (TLS) id 15.1.166.22 via Frontend Transport; Thu, 21 May 2015 11:31:06 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1BFFO11FD032.mail.protection.outlook.com (10.58.144.95) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Thu, 21 May 2015 11:31:05 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 21 May 2015 11:31:04 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Thu, 21 May 2015 11:31:04 +0000 From: Santiago Zanella-Beguelin To: Florian Weimer , Nikos Mavrogiannopoulos Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWE= Date: Thu, 21 May 2015 11:31:04 +0000 Message-ID: <1432207863352.27057@microsoft.com> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com>,<555DBF7E.9050807@redhat.com> In-Reply-To: <555DBF7E.9050807@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.151.241.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD032; 1:vhB3hve6XQBRkhtOEjUZA9EIbs3bsGjzVAfgxVm+QGP1KeSTnXo0evcx0IoeAb1hZ75QApUMnnbiAzMN/Q9Ib++nbwJpZk6tfZ2WmucVy6bgfEekTMG0PU3l29QHmyWzOrWNURIhq6sp4SG+IWMvHiLKaWwNMTIyorurnOXtPvus6HwaVIGl7tAwxZ4wZIbV3RTdPQsa+yvDBpx41B9ZvCF02bbwjxPv8u2hbSirY0V4yO4wQEXR+Au8nsh9DFNIvFQA6b2qE8GgXkad5oM2IftygUKo8z+7gDtKZKuqvz0kG/6f9E27rBYCiYEUy2NO X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(479174004)(189002)(51704005)(199003)(24454002)(377454003)(106466001)(106116001)(69596002)(5001830100001)(5001860100001)(5001770100001)(117636001)(50466002)(6806004)(23756003)(19580405001)(19580395003)(36756003)(189998001)(68736005)(47776003)(92566002)(50986999)(102836002)(15975445007)(81156007)(86612001)(46102003)(4001540100001)(86146001)(93886004)(2656002)(2900100001)(87936001)(5001960100002)(97736004)(66066001)(2950100001)(64706001)(62966003)(77156002)(86362001)(76176999)(16796002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0833; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB0833; 2:7BFW4Ihpedy1a+0klN3ANV6sR7fEbqRZ92RQBheGsJzOxzeFEbcMLbgBbrUX3oM0; 2:zYqKwwYOwv8bnpkvDV3BP3OYUEK8VpW2ZhQ6PKE/s2rrG5yUpxjeR0Oz8oG2Mx6ZwR/OJvdX/VAUWhYcrBwJhe+n/VTOGTwHZZD8EW3EsPukGKxElpVMzV9Qj+mK7npUzpWEGt4vW8QYiRHEjYjpkVH3jHrs0yRhGP235wUJHA8i/EKBRIFjHqE1QT8JcTNgzwF86ubXwZ3MdsY95oD5x/djXBw4z+R+cKol3uM7fcNzqS2tD+Pzdgit/xJndibk; 6:JYtR3ezLMc0QaytcWqPOsqu4FlHggfpgHES0GKBpfFcRUnL/e8NEanG6O2/EUuM2oMGDBflqOdV5DLnss2GA1L1GBHQwIV8LlZ2+REBBHyw+FC7TrNHhAHzRudRHvFWAPJXGlHr+pPCwbGzP1KHEOBdomtFQ0X4AMaJVmKwo5gQm9L2EhpkxDxjQXWkOOJa9fISyhkeAgggEiz7Jl1ywW2NLxwFOQhkKO+iCtoKv5RJ2HGbFZnjss/hFs+uvLRJoNHj8iFaKDZyDlqZoB1xXwvzSWB6b4QyGCq71L/eab/YLohb+HGNJw4PUjF6guwZ4pDjnFF9apS2pvGgHSPdPznJa0vfmme8Qy9gCzYzdfiezy40pXFL93Sp3lTJF6LXAqtK81+VGe+K1omeRv00Msc8sxjTaR68KDQlDEaN0//LiiO7QYrKSCthtP514H244jaH/l05HMvHZIlFKe3Be9rI7Qawdu+Xu0v3no8xjruhdNn/bHOCQR8/1g0tUQ2IJ X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0833; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN3PR0301MB0833; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0833; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB0833; 3:ORi2cdlgQJIZlbWdChwM6qnSd3GeQTZLYO10loo4b+MEcSV/5xJgJ+3kLSz/cmxgf4vQruC5GlR4ec5SLaYvFAW3Vnz/HLVFGCAJNf7x0KL1LVSvi9VumqGUoa/kv1YszrYWM94CJ8j7CuwjTywFDNfvLLmt8D7BadLc5rsTl3y+QLyaPIG4OfeSuKgaCk4lYHYroc8C5APL2XfJciPaKsqDxnAVMNQnhrhbPhBVseq1zGrsNIkLo4P4ROc7XWsIbWBaa51GcbqTMwBgHn75nepvEJuGvZQ45uVKm1Q9iwvZDnIsrIfcNt6EEI9JfF9j X-Forefront-PRVS: 0583A86C08 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN3PR0301MB0833; 9:Qt3F8vVR4vZUMQA+6p7MwbDgLB19+1jQnSCF+B?= =?iso-8859-1?Q?58iUyIESfvt8dmea+u/Jhehi4tqPwx7LtYI8OI0omlS7+WHdOaawgBY8Op?= =?iso-8859-1?Q?+bqyacZCEPtNhvcXPbTPDvrkdJAe6zKf5OqetsvCdpfeXRkroLsP3IAYMu?= =?iso-8859-1?Q?NKq+DL1ansv4vLpDNPqzAaedGkHjneM+Dy5n4Bw5t1xImuy4yOD9guNfnv?= =?iso-8859-1?Q?WcyXELhMXDPOJeJy2buXpK3DG1ZHT9MyZnszNSlRkYnMWN0ua9VqZYpqO1?= =?iso-8859-1?Q?kL+eSwf1sH+0TgQE9UCTE8vmB4hJcNjux7JONkV+GInYw44zmi5oOzZUmu?= =?iso-8859-1?Q?W4DKnbx6mJw25aSGmt7OkkktRmOHFFFAudU/BHEMiKF5p6OQPKs2MXacU/?= =?iso-8859-1?Q?xwoiZ/mL8b2xDzqwuYJ+RahMfiEFGUR2F1Uv4QZ4UEOCZUECRGIdx/tqc5?= =?iso-8859-1?Q?yDtZzgHjF7vmK6cjUbJ2WjybPM8aeF6vz8duK4uQkcenBZVq+rpckBnsdK?= =?iso-8859-1?Q?I/j8A1QQVrKP4HsO/RNw4sdgLnvtHupfwOgZcgoCflfFDI77r2BsPsY+oF?= =?iso-8859-1?Q?3QjqUPsdIV0B5FkMlCGKML2q3QPJm5CsS//qDuBaXS0B9nk2lY+6hiZsSp?= =?iso-8859-1?Q?hR0vBwNh73IKN498Z0646UWYDLwd0m70nB3Ejj5zHT99dnxOG1A7iJX1K2?= =?iso-8859-1?Q?vTDYtXonPG7nPHCvc8jsVD5aEKbWvzh1vejnsyT9O085UsXhdYNlKxv9qm?= =?iso-8859-1?Q?sIi2mqw8O9ILv0JBmqmc07L/yiY5QAcr75z+kqTTmMGU/G1/sBDtNbkQu/?= =?iso-8859-1?Q?yf0m/4/iOMuHzTpBMpKc8Y7AfXhUxS7k6YzIRgM9xHyfndKoH57KakPVwH?= =?iso-8859-1?Q?GITBoL9vf6YKg9rZ8cuFMKFWuDfXyyMDyh1WW3uzxkd6+2RJx9rXqwQm8Z?= =?iso-8859-1?Q?dfxxSSGEbI78K7q6oiRxlx5VXPtyzM1wLlSt0bL0++n0KPcNv/evo/2Dn5?= =?iso-8859-1?Q?Wm7S0rhgXIazAHqDkNSiZp/pk6Gdiml1xBctR5QpCD6/zeSwuFbLP9y1en?= =?iso-8859-1?Q?NbobmvrA5EtFobesfS0Sawqos5d2JyDgea0Na40vs0xrqRW0SoHOG9cVgj?= =?iso-8859-1?Q?SH/8ZNMvlOQEhkNmdChANR/lIrhXq7XJUWmy3u92gl367I+u6WOGWMg8FP?= =?iso-8859-1?Q?c64K6/p1AmdOF8m1GM68punJeR4gnGbT+6J2Q/AP5DBu0gh/Tsq1iarceI?= =?iso-8859-1?Q?up4bHDhku+rhmPI6UwKQqm44QqrpDyDNie05KckXD6tHy/KF5ByXkvD+T8?= =?iso-8859-1?Q?lQA=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB0833; 3:hjogSGYGQ/G0benf77qmZALOdIFJtKtLdAMAA8rAcx7x22abz9n/+G0FSehNMR0uS9ICIdCyDvV0e4j44YzesUrW2wcevH4uNVpPHtG0QIawa8oIiTPx0Gl5AGyO+f7fb59BnN2iiLbHL14yttDNFg==; 10:yWnfbYceP7twHKkrG/CVkE9BuDUmWeE5YruBtVy8uu7puBJSS8A+1WdaDKjbe2sjrJwc7FsiiaDqXvTR28PWfxJ3MkL11t0lBUDwten2mTE=; 6:HIwSQZ54pTEYdr2+/zCUFOoM9Yt60O0YEBTGnRDBWQR8+QsBdF3e3rpiuxiIcddQ X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 11:31:05.6457 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0833 X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB1249; 2:B1xxsnYTFSfEvk+kYA6VZDhRvjDIPkdg3nRzn5/HCqoGbH5DdncHs6MKCNcA6Rpl; 2:uePjfmSa4AI+qZd7aS57ReNkztVIPODiAb7RdGdG+8TalGbX+c0cj2BtB0HImSY3r5oWLk2NOG4vgt+HWLdNMxIPR1ABKMrLfYA5tnTQI3ttn0KkYwZQ4j6bE2cANUNX5gIGk0I7sjuMJlWaSJfksZRY3GHnskguNjh6vvctew1HMexjutXkxsO5JNYI19sYlqUnxsOIBtTlrIGu3FAxzaZKSkkz7mrUjiarsUZmUl/lfjAzYlcyMsBlNWKttfOr; 9:4vlMBheuvRkZd6XrZR2WohvG4v+0/ZeQhFYFW/czteMNnvjNpsmD1D3EeRLkXXniGS0f6q+hhWwxw6QZWkA6GzmgDVfRV0OSutu3T+2hUrEi6p/Xcs7u+usC97qGPcj4BQNP0yWTRdGdOHYhPyUlhQ== X-OriginatorOrg: microsoft.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 11:31:11 -0000 Deprecating non-safe DH primes and having clients test primality of p and (= p-1)/2 goes a long way. It doesn't rule out all weak groups or trapdoors. ________________________________________ From: TLS on behalf of Florian Weimer Sent: Thursday, May 21, 2015 12:20 PM To: Nikos Mavrogiannopoulos Cc: tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS On 05/21/2015 01:15 PM, Nikos Mavrogiannopoulos wrote: >> Interesting. But do we want to encourage the use of additional magic >> primes? > > We do the same with elliptic curves. I think the situation with curves is markedly different because individual curves can have quite different properties. With safe DH primes of similar size, one is presumably as good as the other. > We agreed on some groups and use > these for simplicity. With arbitrary groups, a client cannot verify the > quality of the parameters of the provided group by the server. It could still run a primality check on (p - 1) / 2. > It can only check its size which is an insufficient test if a client want= s to > enforce a particular security level. On the other hand, a broken server might leak key material by other means, and if that happens, there is nothing a client can do about that. >>> However, that would not solve the incompatibility issue with old >>> servers. >> You mean, if the client rejects handshakes with defective primes, it >> will not be able to connect to servers which use them? > > The use case that will fail, is if there is a server which is configured > to prefer DHE ciphersuites, and is setup with 512-bit primes, then no > client will be able to connect to it, unless it disables DHE. Yes, this is a tough scenario to solve. -- Florian Weimer / Red Hat Product Security _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 21 04:42:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146761ACE63 for ; Thu, 21 May 2015 04:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jg2v4gaFJVR for ; Thu, 21 May 2015 04:42:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 D361E1ACE11 for ; Thu, 21 May 2015 04:42:20 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBgKGK022785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 May 2015 07:42:20 -0400 Received: from oldenburg.str.redhat.com (ovpn-204-20.brq.redhat.com [10.40.204.20]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBgHaC026339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 07:42:19 -0400 Message-ID: <555DC498.2000109@redhat.com> Date: Thu, 21 May 2015 13:42:16 +0200 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Santiago Zanella-Beguelin , Nikos Mavrogiannopoulos References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com>, <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> In-Reply-To: <1432207863352.27057@microsoft.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 11:42:22 -0000 On 05/21/2015 01:31 PM, Santiago Zanella-Beguelin wrote: > Deprecating non-safe DH primes and having clients test primality of p and (p-1)/2 goes a long way. It doesn't rule out all weak groups or trapdoors. I need something which prevents MITM attacks and can be applied as a software update without configuration changes, and without extensive testing because it is relatively risk-free. Rejecting handshakes in clients without additional measures risks that (a) additional handshakes fail, leading to service outages and (b) clients will fall back no encryption at all (after manual intervention, or automatically in case of SMTP with STARTTLS and opportunistic encryption). I'm not sure if it is feasible to produce a risk-free software update for this issue. But, say, rejecting DH primes smaller than 1024 bits is not, at least not along with other compensating measures. -- Florian Weimer / Red Hat Product Security From nobody Thu May 21 04:51:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A9B1AD0C0 for ; Thu, 21 May 2015 04:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiwDtiKlHyXl for ; Thu, 21 May 2015 04:51:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08101AD0BF for ; Thu, 21 May 2015 04:51:48 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 6D599A10D2; Thu, 21 May 2015 11:51:48 +0000 (UTC) Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4LBpjCf030245 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 07:51:47 -0400 Message-ID: <1432209104.3243.65.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Florian Weimer Date: Thu, 21 May 2015 13:51:44 +0200 In-Reply-To: <555DC498.2000109@redhat.com> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> ,<555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 11:51:50 -0000 On Thu, 2015-05-21 at 13:42 +0200, Florian Weimer wrote: > On 05/21/2015 01:31 PM, Santiago Zanella-Beguelin wrote: > > > Deprecating non-safe DH primes and having clients test primality of p and (p-1)/2 goes a long way. It doesn't rule out all weak groups or trapdoors. > > I need something which prevents MITM attacks and can be applied as a > software update without configuration changes, and without extensive > testing because it is relatively risk-free. Well, you assume that the so-called "safe primes" are universally used, which is not really the case. Expecting all servers sending these parameters wouldn't really work. In addition the check you have isn't complete, you'll also need to calculate the order of the generator and verify it is sufficient. I don't think that approach is close to being reasonable to be done on every connection. > Rejecting handshakes in clients without additional measures risks that > (a) additional handshakes fail, leading to service outages and (b) > clients will fall back no encryption at all (after manual intervention, > or automatically in case of SMTP with STARTTLS and opportunistic > encryption). The way I tackled the issue in gnutls is to prioritize the ciphersuites of the client in that order: ECDHE, RSA, DHE, and perform a size check on the DHE ones. regards, Nikos From nobody Thu May 21 05:07:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5367E1AD0D0 for ; Thu, 21 May 2015 05:07:06 -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 fERG_t62y7Gz for ; Thu, 21 May 2015 05:07:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CAFD1AD0CE for ; Thu, 21 May 2015 05:07:04 -0700 (PDT) Received: from BY2PR03CA048.namprd03.prod.outlook.com (10.141.249.21) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 12:07:02 +0000 Received: from BN1AFFO11FD020.protection.gbl (2a01:111:f400:7c10::126) by BY2PR03CA048.outlook.office365.com (2a01:111:e400:2c5d::21) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Thu, 21 May 2015 12:07:02 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1AFFO11FD020.mail.protection.outlook.com (10.58.52.80) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Thu, 21 May 2015 12:07:00 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB031.064d.mgd.msft.net (141.251.50.211) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 21 May 2015 12:06:59 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Thu, 21 May 2015 12:06:59 +0000 From: Santiago Zanella-Beguelin To: Peter Gutmann , Nikos Mavrogiannopoulos Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2FE+rTgAD1qgCAAClNNoAAAYSAgAARVRI= Date: Thu, 21 May 2015 12:06:59 +0000 Message-ID: <1432210017980.16807@microsoft.com> References: <1432141085848.37685@microsoft.com>, <1432193344.3243.2.camel@redhat.com>, <1432202373093.34978@microsoft.com>, <9A043F3CF02CD34C8E74AC1594475C73AB028124@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB028124@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.151.241.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD020; 1:RfJLYO9e8BtPhsmw5UKG4i8ZdOQtEy/1wJN1IWXqJ3+O4KNf+7Q83cA8eVw8JvIjWy2klVodEYfcUcPGub7orFh4WSBpaO1+IRztLuQBnjrVDOcEcJa9+Mzc+iLOKVe5Olf7pgOnruRHcpK1g0XQv6Mf9xlOlyhq9GBlB/gDbu2hZyHNTIteU07imVS6J6QDuC8iu4amCKF2VJoxQyylrPMu2eoGXLnO0630MhqmuHbLh0Jl/P1xqKNn/IwNKA5kNmSZSbyz2fOsIui1CH1xoWRqAK2BFRyy6MqYtFjPmG+SWBGytN8rVZiUUcqmNsI4 X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(189002)(377454003)(16796002)(36756003)(69596002)(2900100001)(19580395003)(19580405001)(6806004)(81156007)(86362001)(2950100001)(86612001)(97736004)(4001540100001)(5001830100001)(5001770100001)(92566002)(5001860100001)(46102003)(93886004)(64706001)(106466001)(117636001)(50466002)(62966003)(77156002)(23756003)(86146001)(189998001)(68736005)(102836002)(5001960100002)(87936001)(2656002)(66066001)(106116001)(47776003)(76176999)(54356999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0842; 2:SszP4CUVFaEL2AYkyCEjVqOm+/UGH/Xb7CQ7chKXUOBKpZ63re+gvoeRwhEcG5r8; 2:M8Wyn+5ttWCKB/eXbKudYvxqmodkWggUYE2FLkarDz7OJxBdem8oIOhUK8sXex9KdrhyUnosXnOJYiVYELV3xC/hHWa3cyGeWWuqLLHn+V/ccSjGgp1aEg8qMflBtuXz/e4YaO8N/fiyjbV8stLhz+umX8MgiqKwOoPkce5/NN5pWPTA6qanqtg+Kx9OFoQ0umgUzFIiFfGhHCLvyMkvUQRDt3L5mPrTAtvAplvSrT9P1uYJFUjFdF2ASgbU4O91; 6:R3UllqyHqI7je+obJyRPa/qa1Ny0qy0jv3tt8a4K9w1OJltVpWGawHKHIwnqLsUpW9Qi6oa7ch7CcbCp57iRjBlPbNWVchmVcBPAMLhCWNY6WT4zGXwi3cekhP9djIm7fyoF1RTeAZQyHRU1RSN7VYg+xFm2ggCG1Zcq4F9i5Bskn32JPZem7P8SScx1Nc2+WpetXlAGVUCZTvnz7rzAWOJuenyksWvRzAAcHqZxhBWU9+Hw+aTx/NvWjPZDie8/yv2uVY09j0e3bbb3RrUIYkA77r9269qQSIiefIDv9ln6HSh3vaSEUsrvUVxB2VI1/6YEV8J3dhE0tKrh5Grqtap3a95lt1QT4CQ8UUY/XpnupIYl657vSEfPV+o+tx5Ks3I9qtCbNA1XL3MxBDs3ZvpGr8gfIkUMrydX+ViSSiM01K0OrA3oJiDHC0/+aQNdOF2JDULxeV5TIPCAH7YzkIhAM41yeySkzCOcx+cLlm8k5exkn0QdwHBFMr0r3e+b X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0842; 3:+RVxdpxKcnkHKqLdH/xsNr/kiU87ykO1vVei4/+7JxeLcGoH2XOG//R9eQP6mwoU6l6E2hDhF1Etywi5mmk163XNZcOCOHNyEPDdpw4KOWYdDgwdIG9Te2S3lj6WnOBKiKdprfh7+DMDPWx2w/2A6L8qkbMJJsT3oPpQeHbECRdjU0ZeaOPq/uQxYsAIyFdNDQX3IeauKGhgmInU8Y2zwlNW+xbiHTxoL6uKcb7NSpIlYOTaBv5HE5L4AQMSUpC8raMNlV+D6uHLXTKfgLhtubu8KgR2b3Nb2KpLUGxw7oaVnLcjgUcTu/8ld/YqpA+O X-Forefront-PRVS: 0583A86C08 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; CY1PR0301MB0842; 9:TtinCIfE8rD9Y0ayoR796mqN3PZl8hZx0e9BK/?= =?iso-8859-1?Q?Uj6/zcI1+5MCQ4u9HvJg7m6k/xGe9/4BSmWFno69ryOm0iJD1mLeV4YkWT?= =?iso-8859-1?Q?azwSvzi4BBu0QFVddlJfvTdGM1TlpUaCAaCtZkOJW3EVGjpwqD53SiyiTo?= =?iso-8859-1?Q?ZB1ljk1fZiXrUz18L1rJ3oSLkWoP+9Q2K+lvfUOxpBFi+VWjLi04G8ngto?= =?iso-8859-1?Q?2pNSIu8RxmUc6PicLz67caf5Umo72oWCvbCVzk3gKD+pY66uxDeN1Zy5JQ?= =?iso-8859-1?Q?k1o9nYJQkGxEjXo8xBHX9EL4B3W4sub9b2T+OoJ0d/yPiKOXS43MYKECwU?= =?iso-8859-1?Q?Au8ctgrRAYPX+o6kkTTdeVIIZpj5Vxv448M5nXxpTazkEu9dEBmID1YChZ?= =?iso-8859-1?Q?DP8TlwSIVD7Oz0AeQOWwThHNjEkqLUtkJVYRmzkSId4S170rEVgmGy20Bb?= =?iso-8859-1?Q?tjNJ7i59b1Zg1mSQq4Xgqp/+qHTMcmOEw4//RrzQ8EALAmWL8fo8ggPL0G?= =?iso-8859-1?Q?VHErzq6N5ymK8Xmyr5nCPA6TxV87RyAYZC6cUV7vlWIaQpna25Tz3RxCn7?= =?iso-8859-1?Q?QViGlPB0PgDYlWqDUfdVjsENgH9v5DVMEAf96mc9QWSRLi3TFdXDwk6ol5?= =?iso-8859-1?Q?Kv4d98F2mRgYBrCQBMbpRRRGb3pQDV2qdQHYT11t6zXcPCovhVdCQKqy0g?= =?iso-8859-1?Q?t6w8Z2Sghj4QK7UixJLvHHsBt5dS4vVjOogMSvv4GxqpHpkEvCQUkeyy/w?= =?iso-8859-1?Q?V0F3vr29MmjAdB+t2K7/OUXKt2WsN4zKVsicozCiMaqQseCiDIwGy1RQFF?= =?iso-8859-1?Q?N+I4ZF1/hVEMCdYK4GFVRg6PiHXNPuAyNJfLjm8vqG104diy+eyxUvBnjZ?= =?iso-8859-1?Q?VU21kfwlxwREF9EM2iYFyEJqBl1plvPjZPjfZhB61G92LKNRDfFy0uXyJX?= =?iso-8859-1?Q?D4p11ezvrqxiXDZrA7uAxJ+AEpd2992RMp2wq2jby/KevQEloGvFFGMRAn?= =?iso-8859-1?Q?iaahhDdfuWhz1jkzNhb5cvQe4rRdnbqSrc8PpDMbXNULLSt1pOP0D6gYHe?= =?iso-8859-1?Q?ymL1d5OJRE3PP1snHRlr8rI16pcKW6zVYxsjysT/POSu+LtXrSJ6v8ZaCU?= =?iso-8859-1?Q?Z4MKgtt2u17gd56uUV/2qTvF4jShh8TkY81zBcl6FrgwMkJIgQW+QhwJRr?= =?iso-8859-1?Q?+YZdg1HTtRhiovFrGhWgrrPQlLMB9MZrFA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0842; 3:TbRhNDiRyKgG0IBQo/f6uEjEepSXYerCLbtUH/Earfnf/+ymqjHwxqsmQljz5b+WfoL7OM1MOhLZGz193xZoQS3Ed9uXjqazB1DDCeyF9fpp1jIgQyL4RdyiGgnIp/ALW8K8hqI+nMXRqIvjEO3e5g==; 10:GiASH5twXCNvThXPqwtpwsynYBhH4UHqtohWcppR7ESn0p8tImvTqTl5z/Ju2ZfU11WZsT84rNYSwrZ1sHa324WNGT3Eze7aCzJuEvbA/MI=; 6:HDPdYeThKhaXHq7FSfjntnGirzQbYeOd114iiqyIsta1wbudo0nl79WOR9I6GVCB X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 12:07:00.7186 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 12:07:06 -0000 No typo. Yngve's numbers are in line with ours: 44k for Alexa top 1M websit= es, and 1.75M for full IPv4 on port 443. That ciphersuite won't be negotiated by any modern client, but one can down= grade the handshake to use the weak DHE parameters that the server selects = with it. --Santiago ________________________________________ From: Peter Gutmann Sent: Thursday, May 21, 2015 11:02 AM To: Santiago Zanella-Beguelin; Nikos Mavrogiannopoulos Cc: tls@ietf.org Subject: RE: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin writes: >We did find many HTTPS servers supporting TLS_DHE_RSA_EXPORT_WITH_DES40_CB= C_SHA. Just to make sure that's not a typo, you're saying you *did* (not didn't) f= ind many servers supporting 40-bit DES as a cipher? Wow. How many approximate= ly, are we talking tens, thousands, millions? Peter. From nobody Thu May 21 05:27:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49E61AD289 for ; Thu, 21 May 2015 05:27: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, 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 VnSld5mN3iID for ; Thu, 21 May 2015 05:27:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2E21AD272 for ; Thu, 21 May 2015 05:27:15 -0700 (PDT) Received: from DM2PR03CA0002.namprd03.prod.outlook.com (10.141.96.12) by BY1PR0301MB0837.namprd03.prod.outlook.com (10.160.193.143) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 12:27:11 +0000 Received: from BN1BFFO11FD024.protection.gbl (2a01:111:f400:7c10::1:197) by DM2PR03CA0002.outlook.office365.com (2a01:111:e400:2428::12) with Microsoft SMTP Server (TLS) id 15.1.166.22 via Frontend Transport; Thu, 21 May 2015 12:27:11 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1BFFO11FD024.mail.protection.outlook.com (10.58.144.87) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Thu, 21 May 2015 12:27:10 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB030.064d.mgd.msft.net (141.251.50.210) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 21 May 2015 12:27:07 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Thu, 21 May 2015 12:27:07 +0000 From: Santiago Zanella-Beguelin To: Nikos Mavrogiannopoulos , Florian Weimer Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAJjSI= Date: Thu, 21 May 2015 12:27:07 +0000 Message-ID: <1432211226723.39265@microsoft.com> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> ,<555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>,<1432209104.3243.65.camel@redhat.com> In-Reply-To: <1432209104.3243.65.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.151.241.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD024; 1:R7xRTiWl8C0QmlOksIoYgJ4fyLdEjPxsQBxv5YCnp/rZkDEay7dPiEoSsEv4yOLtjX7OaHnRpmWRjtgio9p8lfdXtiDufE+4NS55dydPp2p2PJvfo1A7rhiIQvdZF3VJev5838PHYwumidjOeVtW8bnWKjB5zGjkZHMPObxOrEUS4DqsurIXiVXxoZ7lqmmWSgPbZ4JQJqG3g0lrC+7lCruTuyDVinH4TemPoQZQceikukbGT0112m46NxeQ6XsZnXhKrOc7d1Q+MVun0Z1X3giLRT7c7Je+N9nmvIlwtg+2MfPzI5FXBcKlgJ46tYVT X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(24454002)(189002)(199003)(377454003)(479174004)(377424004)(51704005)(36756003)(4001540100001)(46102003)(97736004)(92566002)(23756003)(86146001)(2656002)(87936001)(93886004)(117636001)(2900100001)(81156007)(19580405001)(106116001)(16796002)(102836002)(106466001)(86362001)(189998001)(5001830100001)(54356999)(76176999)(5001960100002)(5001920100001)(50986999)(5001860100001)(86612001)(64706001)(5001770100001)(2950100001)(6806004)(19580395003)(68736005)(47776003)(77156002)(66066001)(69596002)(62966003)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0837; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0301MB0837; 2:wT58P3rC1AQocNMqH2IsHKD5SFEVh06WTzbwyTrLcxUi0TPKa2fVOMUK28X79yCc; 2:ccPMRX8TKE8mKTOVfzBR/HP+wrFI/lYFphQVTaYdeBOCGVtN+8yHSopkiRYvTNw3yyNiUi5pnYijZ5S1QlpU6LgFw8IvNyg0c1G1C/XMVhwTM58mNUsMkhneSgQKtVogWWCpM4+fbfBiyPbZ8/XqDYw+eQgiY+11hQatRCpzR1UnVyg/dbGj6Zw2Gxyvm21XR37rFwyVBIHikkdUbqcTgDRCmjieLA7aAMfVbcT+YAt9BHFjhBCYAPOVniFrov97; 6:cQ9Rm1VV6crrTNYYnG9vXS8dwHe7254VOzEFHM7eXrcJ0SXV1pM6l8jQgJKitqJHJ+QaC/z85ahidjhoy+ELi3w82B3GRcYqD23PN0DINdwZkQr3WPKLdqWs6ckxFx+09Mr90HetDUb3FlvOpnr1RB1UnkZNeouedLJF1vk7FLygKTianWOXIUjOpS3Mqh3zdXITvd4UCuts92txviSM08c4XgofdGqLvvnpZsV7FqxoLUshbvUDEvsrtiSg+DqwV9KsRGbRWLiYBirZLTtd5Bcy7hIO1yatXdVMl3c9HXgJzjfhmj4GBD+91mU+hsL22PHoD8Z0WTchVo3K6e4u/4znyqpSTAbGtCkPZIn1gCje06CBM73iHpq6rtNKyMG0kkLKUlGRcFT++ip/FTYyW/NRmEQDX+hOAGxKRHUVTsvEFui02zE4XWbAnwpiG6lpsXQFBUmED1oRDLXoAyqNV2VarGRdNpasXddGguFTsFzgvf03LGOqk73WjtE3KVR3 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0837; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY1PR0301MB0837; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0837; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0301MB0837; 3:JTb0IMQuq4Zvir/GNk8RI+FZfSKbIxgTKv1RLzoSw2UIWL1/KtsQNEWk+ZLxbN19tlRzZoer/sX5cPGfF2tzmSAfj70Bn4W/uVXCqRmqYmTmGkPNf32H4UNpJhNZ3T8xIa68D1sgv1q2daGeUALcSa9LurzXaxVcOnQeAHtNW2M+HPn0BE68NeJKpdQ3lUGck9Q8blGAZXO+D1kqv4S88STvHkUF1Dy9QfVj1m/aTlFbJIHr8RzbND2PHsh0j7xUznu74O4CX2NsRQdXu6gQJ/2b27ZfbA6vshhcGQ+p1GSwklKyc1v1H1F/9F4e22dg X-Forefront-PRVS: 0583A86C08 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BY1PR0301MB0837; 9:B9mrxLd8QUo4aQ3ZQvpDQNgFIPb/l6GZdWDsmk?= =?iso-8859-1?Q?+D1x8SqzfECkonBBjT2udzRLNyQhbpm7sPo80ff4vZPk1ybYc3Vy6N/Zz8?= =?iso-8859-1?Q?IgF5SA74KkQnWFeRCRDSeQtFNxKGfhwFmZHJ/bbGiMUq/vCsr4/AQBV2q6?= =?iso-8859-1?Q?zuq013DUADloTxHeZpoQyz3Aojp7IF3Zhd2OQ8q2durPcGfgiUdxTALSKt?= =?iso-8859-1?Q?uUdmJUnQVot0nsicxe2eywJ7AOxdwWfOxEQzYLeEo2W6BKhPSdZj0vesJQ?= =?iso-8859-1?Q?zAWwOTw2m08f9xd9CfdH36Srl8/1O1iZu07h782qiMf1CKUELStDdXbMr7?= =?iso-8859-1?Q?impTNOjA/E5aR7VnGJJRlrxLtoGkGbCH4y0OPLqnI21wQK8c4UydYFxaOw?= =?iso-8859-1?Q?B0KTw0db0BLQLppuh3z94qrjuuQsocxMGexwcpCKLMnjgg3CGL+eRzrHbu?= =?iso-8859-1?Q?ZWkrVErDq52l/u3SxmutONo1NQacBdm1i9RlXk1H9SCskqqVhXgtSzZ+8u?= =?iso-8859-1?Q?1R9pu1jSs5f4VrBRfPrl1dJ+H7SoJ8wlHhfQP0T7KZVWKNv/UsBWWcLtq4?= =?iso-8859-1?Q?XV12rJH1AOA8Qhy4HFt1XMgzvCJm7vv6wNieiE9KP4yfUYs2BWpMv3QIIv?= =?iso-8859-1?Q?clIdbZ5uPbwcHtvM2JYBbI9+X6c2F+21C/78yi4P2CXsrJjbhQaV9km9VC?= =?iso-8859-1?Q?/xIvppIL+K1OjsmbClJLePA6IwAsiY2xla1/AAQQcjtwhZzcztsb2WCAxk?= =?iso-8859-1?Q?hyVIEpJgEXdhlGyJG2TitzOo1HzfmVL2kCzZ9tVkmsVeOBk7KG1BrC+ehS?= =?iso-8859-1?Q?50IK/JMBrct/2QLK6bp1sui7ENM9rnW9byS+4deJJ6x5d2rILrjSnKzdMi?= =?iso-8859-1?Q?X1q7KgyeNKxZQ5G1ebPApizSTUMYx9AZ3C3L8d1b9fnKBC/Bo+Uf7qqPx1?= =?iso-8859-1?Q?yPVDf3Y8H1imYxNXpBd+sK6tPS3qebOPxlbeyhRst1ML+bT6Yki2piIiOM?= =?iso-8859-1?Q?628bFWwpqW3TncEqStXOqz5U1U38T++K7U7UYrTRBt+2QvA6qojOSG1SyY?= =?iso-8859-1?Q?ZxeO6qfvLMEh4wdZl5aJijLzVW/7IwxHKUDC5d6ztpBWeb6Q1hedf/BeTu?= =?iso-8859-1?Q?HaLNT0JdI3vLatFvgrE21Dm8VOg5xdFRXr2qVF5zvlmPnr9Hf+DHjcSJvH?= =?iso-8859-1?Q?fSSy9kjiDHNlBJ5fPJ8GIuBvZfVaJcy85JIawHGYWzRTpX1CDYKakeKBzM?= =?iso-8859-1?Q?V+nJiFbUXws37s7nMScyuOmTNmRnK8pu81NGee93xYe19X34SE00XMJEVw?= =?iso-8859-1?Q?RD/onjuCEffUoVdk2hGuvri0?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0301MB0837; 3:SlwQp12b1NoDksA+eld8+3GdU+MymBMrd9RwnghDCaj2MyAJJ1LyP29uNk6AYht95dVrMN8z+PLTocE5kPpyZsmyJrPW0DihGIrVqcwuPY3sIygjsDWi1K8cxka5kFoZi4iqVHH7dxZnfG5lIc30Mg==; 10:jEU9ikztGsx2F2L1YnJlo3MZaU5JTOHB5LZgxPT7qwqzUHikD7HSAgPLbt75Ul6Ar4kJ7VEUMAbd6ZFb22+xtEQA+KK04pADyV8k/o2KF/g=; 6:g6CLktmAFm2XUoEDRbsnf7SJWO/Ve5hLN3ztuoQd2llfT1vEqeTu7TDfRUmSwWxr X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 12:27:10.5932 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0837 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 12:27:18 -0000 > Well, you assume that the so-called "safe primes" are universally > used, which is not really the case. Expecting all servers sending > these parameters wouldn't really work. Yes, non-safe primes should be first deprecated. > In addition the check you have isn't complete, you'll also need to > calculate the order of the generator and verify it is sufficient. I > don't think that approach is close to being reasonable to be done on > every connection. Checking the order of the generator for safe primes is ridiculously cheap: just an interval check. That's not the case for non-safe primes, where it would cost you a fixed-base exponentiation. This assuming you somehow know the subgroup order, which is not sent in the TLS handshake.=20 I think it would be reasonable for clients to test if a DH prime is safe by running a few rounds of primality tests. ________________________________________ From: Nikos Mavrogiannopoulos Sent: Thursday, May 21, 2015 12:51 PM To: Florian Weimer Cc: Santiago Zanella-Beguelin; tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS On Thu, 2015-05-21 at 13:42 +0200, Florian Weimer wrote: > On 05/21/2015 01:31 PM, Santiago Zanella-Beguelin wrote: > > > Deprecating non-safe DH primes and having clients test primality of p a= nd (p-1)/2 goes a long way. It doesn't rule out all weak groups or trapdoor= s. > > I need something which prevents MITM attacks and can be applied as a > software update without configuration changes, and without extensive > testing because it is relatively risk-free. Well, you assume that the so-called "safe primes" are universally used, which is not really the case. Expecting all servers sending these parameters wouldn't really work. In addition the check you have isn't complete, you'll also need to calculate the order of the generator and verify it is sufficient. I don't think that approach is close to being reasonable to be done on every connection. > Rejecting handshakes in clients without additional measures risks that > (a) additional handshakes fail, leading to service outages and (b) > clients will fall back no encryption at all (after manual intervention, > or automatically in case of SMTP with STARTTLS and opportunistic > encryption). The way I tackled the issue in gnutls is to prioritize the ciphersuites of the client in that order: ECDHE, RSA, DHE, and perform a size check on the DHE ones. regards, Nikos From nobody Thu May 21 06:27:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6260D1A1BA5 for ; Thu, 21 May 2015 06:27:48 -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 SEnSyDC3nELj for ; Thu, 21 May 2015 06:27:43 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (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 8C21C1A1BA2 for ; Thu, 21 May 2015 06:27:43 -0700 (PDT) Received: by wghq2 with SMTP id q2so85712091wgh.1 for ; Thu, 21 May 2015 06:27:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=INtcGd/AeJcyNgFVbG8AP2nmkH0MJ6UGy/KFjXsU2BU=; b=VXJrutLk0SDN9eaC7LutPMn8FWU5LwtL3ZjKQNVwa9OjUYCdR7Ljp4X2a6d2enDczm OiqWvuT91lDd/rH7p08LRIPQCzchU8sK+PLQXeTbV5h2a5WBzj8omeymdfwA5bCNOg+z 04Qy28+cfEjbEWLrk0C+2EnsJlRMuuAbZnDHCR4En2p8Ck9yOpUn8Bwvx6Xa5BIKogdC R+SzVRSAlMRQVUjG/IZKlX2OqnTfxy8wK+o6DZxRKZ/3ig6IPUpamnn+Bu5wK0mipTUu TsERfr/RSpyRGYqnTMFkieX5QmifYObGBpnf/oz/oqeeWqtPJkoHm2UnN+xW7LVTe3kh YSRw== X-Gm-Message-State: ALoCoQm7NYJZT+HJ7rMz39O5yyiRIz9PHJBrK6NJxAEkLbGeVBA7hu5F3LKGNNoAKXpxO5cZ6qFi X-Received: by 10.194.60.164 with SMTP id i4mr5350716wjr.133.1432214862156; Thu, 21 May 2015 06:27:42 -0700 (PDT) Received: from [10.60.20.24] ([193.170.94.190]) by mx.google.com with ESMTPSA id x10sm1596146wjw.39.2015.05.21.06.27.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 06:27:41 -0700 (PDT) Message-ID: <555DDD4A.4040206@azet.org> Date: Thu, 21 May 2015 15:27:38 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Santiago Zanella-Beguelin References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> , <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>, <1432209104.3243.65.camel@redhat.com> <1432211226723.39265@microsoft.com> In-Reply-To: <1432211226723.39265@microsoft.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1125E80655211DB5672830A7" Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:27:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1125E80655211DB5672830A7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Santiago Zanella-Beguelin wrote: >> Well, you assume that the so-called "safe primes" are universally >> used, which is not really the case. Expecting all servers sending >> these parameters wouldn't really work. >=20 > Yes, non-safe primes should be first deprecated. >=20 I'm curious: what are instances where unsafe primes are still used, generated and distributed for use in TLS? Hence where do we need to deprecate? Thanks, Aaron --------------enig1125E80655211DB5672830A7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVXd1KAAoJEOTbZJL9ubXVxucQAKsldQg8doV3uykYnpewuOfa qBH6KLed27ZDml6MoT9wlrfhRkS5/jBwPpySdvWPeXvCfYupd4NIooEC6KMIJjE2 PsGcJIPHSei1GizR2SVFOiBXCtddnUfD0ZnqiIXZTZ674f00V2XlBW2MpEprkYT7 uLmL2tGjLn53bOyxwZnY8NB3lsFcwUpWKRJMLBSGPIaXoJZnnxlC9AMiorsg5bnF 4b4wUF7CwJiryW8dn9xek/ShY9CeEO3MKrK8IykCoNO9SOfDNTL/V8iHltUBcWSg vTvTvhBHBq8NMTBLo9xJJpPrxtqus7ss8mIZyWevcmioSC/fsVSTgpkFr8oy0DJ4 bOilwBIg3bg2CLmP+zjb23iHJ5ptLy27t68LQBWvYFZcKotYbPOJvGwx8O+5Iage u2RAfzwQZj4JnGKqaXyKBqKiIWzmyy53xVQivNVUi7/uDC9eSzV+7UIzAl7kg00U gAfvvtXc3UniX0RURvzPdi8gWbq/0K+LG0gVgjz5omrR7LG/lLEzaL+bngtfPxII B+gohsYvlFJqIQ7TKcKozl5rrxQsFmv1ET6eICUA0FxwsW25fjxq4auaO9vvNIcP rXtjwUwdh63yVs8ehiZMAkyXY4zpRs9lEkSTVTLK55LFEjCxaWZywCMQV9RBAW6A 19MIGtNrZWnkXQcYAN/i =cmO3 -----END PGP SIGNATURE----- --------------enig1125E80655211DB5672830A7-- From nobody Thu May 21 06:42:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FA11AC3E8 for ; Thu, 21 May 2015 06:42:15 -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 VRAvjSSkqyFU for ; Thu, 21 May 2015 06:42:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2700C1B29A3 for ; Thu, 21 May 2015 06:42:13 -0700 (PDT) Received: from CH1PR03CA006.namprd03.prod.outlook.com (10.255.156.151) by CY1PR0301MB0697.namprd03.prod.outlook.com (10.160.159.139) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 13:42:10 +0000 Received: from BN1BFFO11FD050.protection.gbl (10.255.156.132) by CH1PR03CA006.outlook.office365.com (10.255.156.151) with Microsoft SMTP Server (TLS) id 15.1.154.19 via Frontend Transport; Thu, 21 May 2015 13:42:10 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; redhat.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1BFFO11FD050.mail.protection.outlook.com (10.58.145.5) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Thu, 21 May 2015 13:42:08 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 21 May 2015 13:42:07 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Thu, 21 May 2015 13:42:07 +0000 From: Santiago Zanella-Beguelin To: Aaron Zauner Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAJjSKAABE/AIAAAhIs Date: Thu, 21 May 2015 13:42:07 +0000 Message-ID: <1432215726134.67809@microsoft.com> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> ,<555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>,<1432209104.3243.65.camel@redhat.com> <1432211226723.39265@microsoft.com>,<555DDD4A.4040206@azet.org> In-Reply-To: <555DDD4A.4040206@azet.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.151.241.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD050; 1:mfDWaAd7xJtJfZ6kedzFee3zb+DnROuy/9Y9AxNZeEr/P3RspQmIR6lvPsCcdnnovdG9AYp42Z7WxjWqh+g7Jj38cZvFo2vNJ5Eq1+0Hdpup+VEbropJPfxe/w9U8SlgFiMsOte+a0Kvy4PQDcUij7+iTxmOXEGWB+KGv9dMs1xaqaLyz8d7UW/Ihw2nJVWJXChBY92+sbjWdvmAYPpVDCwB8ewH8iMCiL9Nekl98O60EO7N92yw013up8F05X3Omi/VH61Bd7AVXy79DyTNC7Hr1IQwrp1I3rftTzdWHnd8Q7woa2urn0kleacBktYf X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(164054003)(51704005)(57704003)(189002)(24454002)(199003)(62966003)(77156002)(46102003)(189998001)(4001540100001)(36756003)(68736005)(97736004)(16796002)(47776003)(81156007)(66066001)(5001830100001)(86612001)(64706001)(86146001)(50986999)(19580395003)(19580405001)(69596002)(117636001)(5001920100001)(2656002)(50466002)(86362001)(2950100001)(5001960100002)(106466001)(92566002)(2900100001)(5001860100001)(110136002)(6806004)(106116001)(87936001)(76176999)(93886004)(54356999)(102836002)(23756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0697; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0697; 2:NQ/pphafGhARWFM2kKrxesOsvHLrz1UpW+K9taHGTmhVRHxI4dHQ5URHKmfN7aKc; 2:I7CMrznzz7824e7LUDhuaqzOPNq7TgtLNywNkjHltTkq8qtFV3Zatz/fyFBpdNJLwTikKhu/nM3iYg9e9H/ttkURpSykmHyfCjnGtvVayf0XMzT0Q3HJJwwOQmKZdcvc+aVpYanpQQPgLvfdVdkXT5iKaROBu+L7AIE0D7X6FntSLVamjDV/19T9oBziRBgGmeT8bfKRNGmVebEZR8iCrresi2jZUFY/ngmXC7fU8svWzq+var/fWZXpPdiu9NJB; 6:66SzqIpnqlEzuQ8NGZXH9WOJcZBnYCz46YgCj6g6wQXBmG8iaeaNxsPKNGsrGZNMGRmqJLmOYQkSTtci0plTSn1KgF36oiFa5uzQ20jXgD7M/u3pT21QjpYO/YShml5/jjolgbthUYfl0bTSyUQH/WtYLnMtsusjMJD/GqoP3dlrl+HVQ6iNYMbZUaPcgf1YanaaCbJ3hl0lOtHzPwWf9Wocq2oDqd3PE5VNHe/CC0zn57E1mzvezbiCUp3TxBBtFGIiBNLu04F2LoWbKlPm2bsPubcQ08bAQnZLqUiaPhgVGQsmJwADSw33DRkxdV1BGDzWsIo7+tVO4i9XNZ7wQY4JYgR5RyK/cwMi3E9edG6ndrGrF1sOnbvFx83lkjKV6lboEXxhO1yM5M3sF2RV9oqb0wo4q1xMC3uP5ppLdtLJvsr5wpxGJAN/zmGlxokzxPAYijz1NQgK3BNXLgzfjtz5fXrkF210js/PpWqE+uqdxcb8ysbMqJqyVUzhV6Yj X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0697; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:CY1PR0301MB0697; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0697; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0697; 3:ok2c+ykftOJFALaC8dqVWHgfUxY8m8AZonFtdKGme0wc9bS8T+2wgzq+vvlzsCV1Z4imvAhLPJzGsyJyl5WQH1wQMOo4s+uISPRIrPdDyehkeodeqhBG4xglF5WRtIHHAmM3YopKs9CwOQJbE5ZZ2JKQxDR1QzbQvYIik3DQB6mPPLsspsqAzy8SwCE1vjeXtCx8ynEuS8/AKVqWFkvqlWQLH28obZMShC44Qwt8CdIE+ZtzIlSfWTBA49ObIPvxDvAEPg7QL+VInVH9ipZr4NNj1xyuytgQ9/+yTDE/vhouEDuV5G7GQopk7vZ4C7fF X-Forefront-PRVS: 0583A86C08 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; CY1PR0301MB0697; 9:3E4USLo3l76Z4BnWi48uFJYPrfrwQtTJdceTC5?= =?iso-8859-1?Q?myELelgLNIVFrcHYv80T1Y7XtKaTNvQkLP6P60Tfg1EqgNyvkpsCV92yaR?= =?iso-8859-1?Q?nNUTMtj1D9hcrVo44WE4JIycoBLADqq/Ech/867iBtLIBrH+mWJQiubUQA?= =?iso-8859-1?Q?zxhlpMpKuzH19iq1iN3kqwMEHAgfzvM0E18NjQy2reXHO9Mjssiyl3hDFI?= =?iso-8859-1?Q?CHVDb45rrnFikLAVhC68VpFr+WOcTyQ0wtD9rcyJMit7cieuquwbj7jYsp?= =?iso-8859-1?Q?1YIXRuqwlrQRpEgGPgz8ajyYX5As1+YC4cUwnnOHUlMkq2nFqLzobF9ndX?= =?iso-8859-1?Q?WOecflhOHLsg8pLDbzjCZWVna7/+Zu/UxwAoDpvm6HFDLjhNeEUUUtBOmG?= =?iso-8859-1?Q?40FC3LGjKGkjMQj72RKXhchx+39JZhWQffwNhWa834EJ1ZDoqfaTU/lPrw?= =?iso-8859-1?Q?4ipKLIu1VwlWN9oOxliDG17XVzFApzg04AMc/vvsHg46g/3nafc34sMayo?= =?iso-8859-1?Q?k/YhhXczsRxHLZiWzh/Vlw1/UcJoqpM846eRId7M8zSRW14aa30YtxtTOz?= =?iso-8859-1?Q?9kscfNQ5zEZdzswoaPEKAx1QC8DGuoTj5upN3oy7QfbwMR/wWGNXejD8Ds?= =?iso-8859-1?Q?KjvOM7Zk1eKS+xPrEsdLVJ76T5fEelYxlNCMXArCo69XYJrWQyB8YcREBa?= =?iso-8859-1?Q?YJvzPYMEgv4DyTKVCNbo0os47t4Hd8h0JmEzhEfVwqvQKkWEG6MmZz3a5c?= =?iso-8859-1?Q?dl8DSPZGLROE25qa/JNNkFd3+NdXxjZlv5uia5d8jyyFfCXmf3QL8jCRmx?= =?iso-8859-1?Q?MJ4saFN4pET9+fygD8UjBa76Orep2QnTX5H+kJEjzvQlO77OIwS4GK4U1V?= =?iso-8859-1?Q?kFVZuLbM9ISEKvoYBQngp9dQdkuaXa6JTTXOhviQsvHkdVE886jdYN3ot3?= =?iso-8859-1?Q?XDqM6OuxyfcAka+LtZOIZtFnyMgAuzUf7dUOX/CCjE6v8N9fObibl7Gn3T?= =?iso-8859-1?Q?Rw5EIC6Us74zaTrwA8ZABSH4hUnJqGGNU1cV4a6BHn/hWNZwPi/VpYcCHA?= =?iso-8859-1?Q?wNtZGzz2V0CddRsbQ5BPSQAXL5wNktabc+URF6FbADMuuQcEVEWwaF3V5Y?= =?iso-8859-1?Q?+upyG64LSLcl4kQZwrwTNqNWoowiZB2QpE3/8UqOQJ2cQKqsfr9p7KW7cL?= =?iso-8859-1?Q?7pC8/6pF2+K6dZF31NGrO4w9WrzAgSdwQ82vVbek0qb8UnKPzbaHuZJm+d?= =?iso-8859-1?Q?NO/IpeL5DPqO5rwPcLaqS8M2tp4MIbsqEK9lsJBFdwz6FZOzuB6jRpYgSb?= =?iso-8859-1?Q?7T0M0BZHeW/rswvOLgHmunwA?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0697; 3:mOzw9RQxc/cDPQpIy+ua8ogLpLJ3u2eIO1JCLMsTmyV1KriCRaDx72SmqKt9oEFWER21JBqThubkXzn1g4GUCq5PozeGzN2pUXbgWJkeNSHbVu+pb4oecY5CoUEaBBOmOLY7jXzXZOuBDY5e/RCT+w==; 10:idySUB8UoAMkfgi0BoSFL6TCmNLCPmyfVgOgDmXf6EkMfLCbF9+iKx8M35kvkA6/Z3xMPR/QoCw45DOLA/kjpRq2w3GO8XCdzy2jywzEIoY=; 6:Z+bEdcP/ApQadCQBDgd76cxRysZuU0xE6T499WUV8yPgFt8UUkZzI4hfKNHuNLi/ X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 13:42:08.3003 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0697 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:42:15 -0000 Non-safe primes can be generated using OpenSSL dhparam with the -dsaparam f= lag, e.g. openssl dhparam -dsaparam 2048 They are still very common. In a recent full IPv4 scan on port 443, we foun= d 1.7M hosts using non-safe primes against 8.42M using safe primes. By far, the most common non-safe prime appears to come from hosts using Ama= zon EC2; around 321K hosts authenticating with browser-trusted certificates= use it. ________________________________________ From: Aaron Zauner Sent: Thursday, May 21, 2015 2:27 PM To: Santiago Zanella-Beguelin Cc: Nikos Mavrogiannopoulos; Florian Weimer; tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS Hi, Santiago Zanella-Beguelin wrote: >> Well, you assume that the so-called "safe primes" are universally >> used, which is not really the case. Expecting all servers sending >> these parameters wouldn't really work. > > Yes, non-safe primes should be first deprecated. > I'm curious: what are instances where unsafe primes are still used, generated and distributed for use in TLS? Hence where do we need to deprecate? Thanks, Aaron From nobody Thu May 21 06:49:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883E21A014D for ; Thu, 21 May 2015 06:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp8JkSo3-5Gt for ; Thu, 21 May 2015 06:49:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF731A0127 for ; Thu, 21 May 2015 06:48:18 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 2749F8EA43; Thu, 21 May 2015 13:48:18 +0000 (UTC) Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4LDmFa7010978 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 09:48:17 -0400 Message-ID: <1432216095.3243.70.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Aaron Zauner Date: Thu, 21 May 2015 15:48:15 +0200 In-Reply-To: <555DDD4A.4040206@azet.org> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> ,<555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>,<1432209104.3243.65.camel@redhat.com> <1432211226723.39265@microsoft.com> <555DDD4A.4040206@azet.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:49:27 -0000 On Thu, 2015-05-21 at 15:27 +0200, Aaron Zauner wrote: > I'm curious: what are instances where unsafe primes are still used, > generated and distributed for use in TLS? Hence where do we need to > deprecate? The "safe primes" is only a name. There are safe primes for DH that are not in the "safe primes" category. The primes used in DSA are such ones. regards, Nikos From nobody Thu May 21 06:54:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57CD1A0173 for ; Thu, 21 May 2015 06:54: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 5gb9CwVu1llo for ; Thu, 21 May 2015 06:54:15 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.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 6DC4A1A0163 for ; Thu, 21 May 2015 06:54:15 -0700 (PDT) Received: by wichy4 with SMTP id hy4so14833549wic.1 for ; Thu, 21 May 2015 06:54:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=X6H/IQ5RxwK/rUgxO5PzJ8vppjk1RnYe0I0pxRd7mbA=; b=Lte8Qw5SMi8OI6J54+24oNYTyp+2Q9vqCGgNSh71bInNgngb/usMNB01Xv39yhdgSh TeS0mrBHCtU4WNGdzDiFuX1r3GMOZ4pDYpM/t1bBE4AvunvlmpF5VDq6+efeNia0Elmh ZDvMs5PDqxGdJf6mxWKY/af1GDZJFDaq/HHXxMINZMfUw+FPMc+ZZqVIlPNmW87B4q8x AHXyKA1XCdfDaRk1eODmP4QX1U7+MSJ7468ifkSO11rpV63CLXBIFA2mCmzGmvGeppvg nOJOLzzFt8euEA8RYYHfkUsvrGdWe7YF1f8SQ5OLTalq6bTMV4mXkiv9L+iUuURCrJGj z6/A== X-Gm-Message-State: ALoCoQl0NDCNgaFdtHmKdkEDv9FZgFLI0BYW5XQ6c71bHtJ3hojRJrDW6NKumeROPElMRW+FZH0a X-Received: by 10.180.73.236 with SMTP id o12mr52593796wiv.56.1432216454190; Thu, 21 May 2015 06:54:14 -0700 (PDT) Received: from [10.60.20.24] ([193.170.94.190]) by mx.google.com with ESMTPSA id fb3sm2977485wib.21.2015.05.21.06.54.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 06:54:11 -0700 (PDT) Message-ID: <555DE380.1020906@azet.org> Date: Thu, 21 May 2015 15:54:08 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> , <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>, <1432209104.3243.65.camel@redhat.com> <1432211226723.39265@microsoft.com> <555DDD4A.4040206@azet.org> <1432216095.3243.70.camel@redhat.com> In-Reply-To: <1432216095.3243.70.camel@redhat.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig760B637B1CB2DA8A19A820E9" Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:54:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig760B637B1CB2DA8A19A820E9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nikos Mavrogiannopoulos wrote: > The "safe primes" is only a name. There are safe primes for DH that are= > not in the "safe primes" category. The primes used in DSA are such ones= =2E >=20 Ok, let's assume "safe primes" means sophie germain primes in this thread. :) Aaron --------------enig760B637B1CB2DA8A19A820E9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVXeOBAAoJEOTbZJL9ubXVK4IQAIfvSXhw+uPDOQHfYBK/ecf+ Gr+XWFfh1KtMOJMhlVa2KZ9W5x5ntT3t/poPWE/HgTY4rgqI/LXui2DI4YigsJ4l v3ZSvRhJrcIkoNScMYMO2MegwWJyJ34bfYaTU6xtEHoTTKmlEWq4YfkSuEUvE+CI Xr/D5lcJH5IvKMFe8dRJ2uC5s06+THR9hvb2n/H8OulrlWgwc879bCv4WRIJxaU4 Rcljwz+oy8KPIjc1OdszokMArY4BQGAEZpfSUAJ3GrGZYvC9VfV/10jEevwgVpXp Va/qZgUvsDiZxkaECp9ZVHs4B6MVFaQY/bHh6qRDDQN6u4euwwfebWYg8Dccsjr2 eXeEfEBOhOUHifuJIgr697YpaV0cL8s0g4kgocznetgLvluvyh61dKCJ/9Wv5RKb C6bklU24Tkbm5PFStS/C1704rA5HMo1sm7/ClBNcItxzgSLDq7Sp2op4n6Qec9mv +XNPwlNXPaPHP6e/pVOuH9VOp3vRfECtY1rROI8LvX8c+b9IJUo7AUITLd7YzMUs bcKH5Z+BLsxxFy5eTxsDo0dgIR+AsFGHA1TqmxXNF7+BaBBDmV9pQmMcJIZGSeOn /2v7mGW9iFrzK7R5YGVXI9ZDuJazu5sdgZFEJZTb1B15y+SjltrI6VIWo0zmJtRx ilhYtHu7/bz9bCijCeHa =wfxg -----END PGP SIGNATURE----- --------------enig760B637B1CB2DA8A19A820E9-- From nobody Thu May 21 06:56:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863851A0163 for ; Thu, 21 May 2015 06:56:33 -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 049neywck-hr for ; Thu, 21 May 2015 06:56:32 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.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 028A41A0141 for ; Thu, 21 May 2015 06:56:31 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so15781622wic.0 for ; Thu, 21 May 2015 06:56:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=U+T2UjKX3Loh2AiaSCsbkJaUWnXcDt4sZ00BI+Tffko=; b=WKPsFHM0VCvMy/MIsUv7FH8Dzhl0F5b7SLTVSAdYPMwYTNW6V3bGCZDP+SSFwccl6N wKwMRjPNAX6oMoCZBvcIpzC9HiCNseE51NvkNsUuyCJL5fCJEcmy6KfaO7g9NSZIR2rV STtnJ/IOQiO9BDQUGehsgRbe85p20JRJpc8QEKSTZbHleQ/Z8Ceb9ZxYAhebYmXB8XFD nRYs8P2ND5loi+krxKhQ6BoFT8EMFXakLkkSGaR7c19lzIO9KFRbRtxfmnn/nGfwXC1u Wl7lOjA22ArCsZBAUbq0vnBbIvlwpz399o7iC7PB+K71nBF3ydyrYEieVznM8bcWx+7Z nZvA== X-Gm-Message-State: ALoCoQnWr41tZzlgQNpEzXDQyfYb32ywrSIzOsV/w5B3bV+md7rU5GGXC/2HduwlWblI2g3oRXJE X-Received: by 10.195.11.168 with SMTP id ej8mr5705332wjd.150.1432216590699; Thu, 21 May 2015 06:56:30 -0700 (PDT) Received: from [10.60.20.24] ([193.170.94.190]) by mx.google.com with ESMTPSA id fb3sm2986493wib.21.2015.05.21.06.56.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 06:56:29 -0700 (PDT) Message-ID: <555DE40B.5050008@azet.org> Date: Thu, 21 May 2015 15:56:27 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Santiago Zanella-Beguelin References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> , <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>, <1432209104.3243.65.camel@redhat.com> <1432211226723.39265@microsoft.com>, <555DDD4A.4040206@azet.org> <1432215726134.67809@microsoft.com> In-Reply-To: <1432215726134.67809@microsoft.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC0B49A9997BA485021C1951F" Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:56:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0B49A9997BA485021C1951F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Santiago Zanella-Beguelin wrote: > Non-safe primes can be generated using OpenSSL dhparam with the -dsapar= am flag, e.g. openssl dhparam -dsaparam 2048 >=20 > They are still very common. In a recent full IPv4 scan on port 443, we = found 1.7M hosts using non-safe primes against 8.42M using safe primes. >=20 > By far, the most common non-safe prime appears to come from hosts using= Amazon EC2; around 321K hosts authenticating with browser-trusted certif= icates use it. >=20 I'm not sure these are all due to people using openssl(1) with the "-dsaparam" option, that's a huge number. My question was actually if people are aware that implementations produce these primes per default. Aaron --------------enigC0B49A9997BA485021C1951F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVXeQLAAoJEOTbZJL9ubXV6y0QAMI/2PvW8ZhbVIwPrYrxLMmW kSsJfrMjs5JuAfaFFyQ6dKUB5MBUVq+jA5267lzaHKSWN4afdYntrrI+jRPglYar hblDHSVk7QuLIzT71+RxUdnEzDMSunH5VCUKy3hGmp/koL2B3AbQXHsS7x6hYTR1 9OTqNGlYAZ2FOUn9zBSByzigfAxY7U4YT+Cm6uHJHr8/b2hiE42rMLAe8cOnenKM JhHSQUfMgQp2XpcGV8i1pdvQ7fd9cG1g5V/qZzpryN31r3cTu+eN0a5fQ0ofeSxc 7JnA5Ob9qrVRttOs0aQKTv/G/+P0493ZZuPy1ZWxCEsbEo4cpakgWD9wxBuGlUyl hml1M2iGlKWMDLDDX/NAz1DrBaD1j1kxMegr+u6CNJ7ElyGbRPzo/PPjh7eNQsJZ l3xBfa0bKp79X3823XuA4TA7CusG/6wYt8A5vB8/rxppHU1CBI8YF+BneITEQjvD rU8W9zZklpx0Rigmfqmf7J59Pnpf0UpMhJIXR6hWTctoydJqGPsKs3197wmdlIXt qiKFDEtCEDOn1hQhUIT7fZnfNlgvTwhsIEk26yuYjYyo/n0CW23VDRkgGBtraYqO tstkmzUcs3Ofgrlwhu8ynOPrb4GMotE7q+mX0RLPJqlF+r59TfnzzUmkRnXrVmYM YQJUG6LYibhp8wcZ7VQ4 =WJcW -----END PGP SIGNATURE----- --------------enigC0B49A9997BA485021C1951F-- From nobody Thu May 21 06:59:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5641A0248 for ; Thu, 21 May 2015 06:59: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 iqdKAyDflPLH for ; Thu, 21 May 2015 06:59:48 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 D78FE1A011B for ; Thu, 21 May 2015 06:59:47 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so86735220wgb.3 for ; Thu, 21 May 2015 06:59:46 -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=oqcm2w7lfqRgUGI4B4h3J4/SN4e1DtYdybgYp96QGvM=; b=U2csXPxrVZOjn77r5Udsp7ghCRvwuUcxoQCq3McRcoFllLwS0ylxK9+iEwrtAhstc0 vJcVjx2APngF7Lua2PJq467KdralUIQWEYr9R4BOZgniGeO3l9Z2tYN/dg4toTuunpDN sC1Sp8WtjcmpsT37Xb7Pfy2yj+A3jwFZ5pRreRDQ52Vzot8gxf/uJEhS6GQDds9ly5I2 dkOh0XmSP7ghfnI70EQ4MS6oE6rV40gMfElPeJLQTgD4VQ4LfSlu/2WcClcFvGhPTOAE 9whIpICiEOz9Y1Z2wD8/yVaAIFZCqDDsl2I0h48SSfxOFaGcvIN/XyHMSIzDZ7o5yGnP OoCg== MIME-Version: 1.0 X-Received: by 10.194.248.227 with SMTP id yp3mr5586954wjc.32.1432216786642; Thu, 21 May 2015 06:59:46 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Thu, 21 May 2015 06:59:46 -0700 (PDT) In-Reply-To: <1432216095.3243.70.camel@redhat.com> References: <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432211226723.39265@microsoft.com> <555DDD4A.4040206@azet.org> <1432216095.3243.70.camel@redhat.com> Date: Thu, 21 May 2015 09:59:46 -0400 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:59:50 -0000 On Thu, May 21, 2015 at 9:48 AM, Nikos Mavrogiannopoulos wrote: > On Thu, 2015-05-21 at 15:27 +0200, Aaron Zauner wrote: > >> I'm curious: what are instances where unsafe primes are still used, >> generated and distributed for use in TLS? Hence where do we need to >> deprecate? > > The "safe primes" is only a name. There are safe primes for DH that are > not in the "safe primes" category. The primes used in DSA are such ones. Why does it even matter? If everyone disabled ciphersuites that never should have been used in the first place, we wouldn't be having this conversation. Instead we're planning yet another patch. We've decided that when responding to security issues, we'll throw on more options, even when other alternatives exist, with the goal of never scheduling depreciation. This increases implementation burden, slows adoption, and ultimately harms security. Notice how we've kept CBC mode alive by adopting RFC whatever it was, instead of instructing everyone to move to AES-GCM, which has been out for 7 or so years. At the same time we've not fixed known problems: logjam is only the nastiest variation of problems caused by the signature on DH parameters not indicating the ciphersuite. Our thinking needs to be geared towards ending these problems. > > regards, > Nikos > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu May 21 07:29:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEC31A03A2 for ; Thu, 21 May 2015 07:29:24 -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 teNfsjTv29w9 for ; Thu, 21 May 2015 07:29:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A671A0395 for ; Thu, 21 May 2015 07:29:22 -0700 (PDT) Received: from BN3PR0301CA0023.namprd03.prod.outlook.com (10.160.180.161) by BY1PR03MB1356.namprd03.prod.outlook.com (10.162.109.26) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 21 May 2015 14:29:19 +0000 Received: from BY2FFO11FD040.protection.gbl (2a01:111:f400:7c0c::129) by BN3PR0301CA0023.outlook.office365.com (2a01:111:e400:4000::33) with Microsoft SMTP Server (TLS) id 15.1.166.22 via Frontend Transport; Thu, 21 May 2015 14:29:19 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; redhat.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BY2FFO11FD040.mail.protection.outlook.com (10.1.14.225) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Thu, 21 May 2015 14:29:16 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB030.064d.mgd.msft.net (141.251.50.210) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 21 May 2015 14:29:12 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Thu, 21 May 2015 14:29:13 +0000 From: Santiago Zanella-Beguelin To: Aaron Zauner , Nikos Mavrogiannopoulos Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAJjSKAABE/AIAABcKAgAABpQCAAAkSNg== Date: Thu, 21 May 2015 14:29:13 +0000 Message-ID: <1432218552047.85642@microsoft.com> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> ,<555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>,<1432209104.3243.65.camel@redhat.com> <1432211226723.39265@microsoft.com> <555DDD4A.4040206@azet.org> <1432216095.3243.70.camel@redhat.com>,<555DE380.1020906@azet.org> In-Reply-To: <555DE380.1020906@azet.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.151.241.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD040; 1:F/dsQ6LRq9YfQ1+xP2ASTGIwVaBIVeQMbRz29EqaERGlPYTOcldmWnAR9eQFA0L2E7j/vsU5JkhfQGW1iJHIzGfkPe55wqfF62+JuwC26EIDAHTNGJqHVpZFNWRWmB7r9LkC/9WlqBGbRTY1mrlYxPvuyoyLxzmbFB5RnisuhXW8rkIOBmAnrLAfECXYDGfguvxfoKtyYAd2eXtHnEYqov0SQGoBqy7HuOyGVeaMSM3mIvD8RI+0FHg+HbYd1ZEJ/MfzTpTOFbsONCxaoZkVm/56AF9wYN4UebUHJJThMfSXctxkdoK2qpMfhDbCOXc7 X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(24454002)(199003)(377454003)(36756003)(2900100001)(2950100001)(106116001)(86146001)(23756003)(106466001)(189998001)(68736005)(46102003)(16796002)(5001960100002)(93886004)(102836002)(54356999)(76176999)(117636001)(4001540100001)(81156007)(92566002)(87936001)(5001830100001)(97736004)(5001770100001)(66066001)(77156002)(62966003)(5001860100001)(50986999)(2656002)(19580405001)(19580395003)(64706001)(86362001)(86612001)(47776003)(50466002)(6806004)(69596002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1356; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY1PR03MB1356; 2:2ujj6RBaZbkyLwI20TU4ut9x4dPEcJB6dXCvnul26glLgpXRHXPLI50NqNKzWmlD; 2:lPrngTREY9mHaoB8LmUBScDsgwm4+brKmlSk+iYXeTFg4SBmhZkq6hfWJ8D19Q1GZ/e2d9IRM0LTQTdGFcIj6aPYqXxEH+effXdi74dwyFxHnK07dTAs88ahp5cxWJcieRudXDlJXX91ffMFABiKciMY3iirwVyjktslBFc+hXnU7dCtzvtRLgkPH0IIWxRfOzWDMJvk2dhBoxA1s7DNKU6RC950DIiLrohyU9R9MUxJoTAQuHS2sjKkE/EJ1KQm; 6:9hAva8LMLbxYnNWYKyHKSg4YD4kDo3nkzZGRc5pZqY1bFWMUd9t8iS+y8Y+VZiOZIqvTs21UvpcOhnHXh5Ji0JTwipX103CDEgtixMW9vh+8+1Hq9BauHpkTb+/TphlEysAa7wOtllL4f8ZuLJhJJMJdXLXRro/EJ4Yr1IN6epBmvsTsUPnqoA7Z48MmJMvAqCnFTZHoFi7d2WcUJPQR7BplFnCwQvasgs+hIM3pcsNnaapLx4COVs6Uyvp1iSYkM3ISI9n8v3Vbzd/GlgJV9wSAfJmgH5qUOT8vPkXRTR5pKHtWbOYjJOMM09jtrmONw0rU0iNKwAVHOTzmTXMkmpZQEavCFF54PAqWIFo61jrSr85yQmmrFu91S/cY3i5usBtuMJMq0WCJ++JwyLNggyIxrvMCNRJkWj7WUvb/JKljEKn1r8IyW7JIhskzA4Q3xH7OYZqX/bdlZHXpPAlr/gkLd+Tj/K8uFtN+4G8OmVWzXfP2AUknry2SJQp4A34k X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1356; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY1PR03MB1356; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1356; X-Microsoft-Exchange-Diagnostics: 1; BY1PR03MB1356; 3:a3Pxs7QG0szaKV8EVx1fIK8oBbl9vrVpABCgRi3hVHtSL2/mK2kUv4nmj/pe6bl3keqxFA7yuLa0mmUbQisXL/2WYpTmWKaA7u1pZCNC9bHHhTn0aQdiqCZmrgcxBWSuU3nwLx2nkajMm92w6IL+gFs+NPc5nm1sz4nH8SibgacC+E+GY5HqREGB0ohOvqPIc+rZpBIeE0QinLkAqwq59mgUuoO5XBy8m/yv5gL+zmft+l03wOIoHnoCfrhZUcNQI44BkXXY4T9shJx1drq8A9wLQv+5oiL93uC1omIjycHh9IM+7rIxQh9r88yTc5Cu X-Forefront-PRVS: 0583A86C08 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BY1PR03MB1356; 9:ogz7pvhoweu5LwB+2qboxmzyE46eVJJeGhKKRD4m?= =?iso-8859-1?Q?010+91f5zkKxFdbu22vY9M90Fb8LXaDqlV2qYu2aPQASt5ieJ0Zju/iGse?= =?iso-8859-1?Q?DqASrCcYCF6X6SRxp/MEJ0eUw2SuvO2WEZf2wg+7I847/f/QppespYmmlY?= =?iso-8859-1?Q?yqysel09WCrSY/k37HK5yEJIyM45cSkSLEvsD/VXOiMhNI2d3gSo0kdVDC?= =?iso-8859-1?Q?e5miwnL19w5GQ5RFenuKWiKSmpXT1y7LCRdOxQKNbNDSBnyNs4Jgi5V+Lm?= =?iso-8859-1?Q?iVLqyrichE8gg+ElOrVLQMFlqBZwnKreg4125l/Zy0/jZtcifd0oBTwVqR?= =?iso-8859-1?Q?L7/eJhL05cB85sGgfMzE/pfOQac8o8vg+zPdbbxK5oJe8hpOYPxgzxLhn3?= =?iso-8859-1?Q?A+XVuyL9lxW8hrTUdecoqWheob0zwj/QrjiMlCmQOHdls9DGN3xU/+VUmL?= =?iso-8859-1?Q?UnsjXVJR6wMvAgbhE92KNHc5qXqg/YBfOAhM6q/uH8HcQ113HVkcjSvxsa?= =?iso-8859-1?Q?l1+OYKyJ72vbzItYNo6Y600sphv79r22e84md5EAsFdhnFrnHA9sekPeVs?= =?iso-8859-1?Q?qEawd0EIdxHisTlsH1tppHSgN7EP0OibWJgqdcwSlURrRdOiBvrMOz3b0Z?= =?iso-8859-1?Q?vum+eKQgt8aIFt9FfFU0HEDi0jlA2GYqq2btqlM4hgbfAGSVMMs4XUwQNR?= =?iso-8859-1?Q?v3rMz+cvOEhN/vVMWApLqZ/upcF3OCQV+HPXthELBPU1ebnbVqx3iIoFM5?= =?iso-8859-1?Q?6EXRuq3CAVrEA6H4BmF3KuhIzSbI8Mpa5LaGTwRFFtlUQI7gVW1Y9DCRq/?= =?iso-8859-1?Q?L/KEJ62LBNc9rxe10KMWiDDKSwV9vEAnB5+/DB7Avro8J753j/FWlp4ACr?= =?iso-8859-1?Q?U1ktQ4DQiiUScuJ+/LvWsLP4yoRlllHmcCkC94EkBypXGJDhvcB2OrYK1E?= =?iso-8859-1?Q?lGQKuzu7gMoVezzRoHNG81wCOHqcPUePXNpKxNNPLN8/DM6tuGu9ARkbC/?= =?iso-8859-1?Q?k2ndAdhutZqMDZeVvym1ZKJqZf1jnIlyxFAFhrpkYF0OPT38jVwEMn6WUt?= =?iso-8859-1?Q?UkAsHzEdKNg4BSeiYMUSPwAHGyggecesokK3ppZQkBVCYphUvIL8z+cB/5?= =?iso-8859-1?Q?j66BCHeJbJ6XI0RJBzB7TQPbYfFeDnLeALUJSPKD4pbXfH/DASkv5TlmKR?= =?iso-8859-1?Q?mrLQTWMgBQ4Ubb6ojmH4UF5zmZc+ikhrC6u+xS9njKej31FeJYR7Q=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR03MB1356; 3:L4JVktiQHuqpBjuxnUbLSsByeMfmRRwYe04M/fnFBib7uGfYF1cO3yECRi1ZTzTNuKeI80QS6WyYONHw87QepCGVCpvsFE2F+KoDA6fx5ga1/kOs4TzAiMhh6PfzzipQyA0RijyPPl+jI8ozpwEAUQ==; 10:cx7GjMOS/spuHr5V9Et1umxlTnJow95UMqbN/Vo+z/c36AMoC2Av5X8zG5c1FBX19SG7ZmJCZAFftSv0//FKjDTj3yC1LVDBSrt3+9WAPCg=; 6:NCL93eSo/dxbqMPjN5nZHVRBRr7wSScx67GA+nJSaV3mvKIusciFY/W5COSL1Lmp X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 14:29:16.7732 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1356 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:29:24 -0000 Nitpicking: the Sophie Germain prime is (p-1)/2. We're stuck with the somew= hat misleading name "safe prime" for p.=20 ________________________________________ From: Aaron Zauner Sent: Thursday, May 21, 2015 2:54 PM To: Nikos Mavrogiannopoulos Cc: Santiago Zanella-Beguelin; Florian Weimer; tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS Nikos Mavrogiannopoulos wrote: > The "safe primes" is only a name. There are safe primes for DH that are > not in the "safe primes" category. The primes used in DSA are such ones. > Ok, let's assume "safe primes" means sophie germain primes in this thread. :) Aaron From nobody Thu May 21 07:36:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBDF1A1BA4 for ; Thu, 21 May 2015 07:36:35 -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 7jJTsj1PEHsk for ; Thu, 21 May 2015 07:36:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465A21A1B7F for ; Thu, 21 May 2015 07:36:33 -0700 (PDT) Received: from BN3PR0301CA0065.namprd03.prod.outlook.com (10.160.152.161) by BN3PR03MB1351.namprd03.prod.outlook.com (10.163.34.15) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 14:36:11 +0000 Received: from BY2FFO11FD011.protection.gbl (2a01:111:f400:7c0c::130) by BN3PR0301CA0065.outlook.office365.com (2a01:111:e400:401e::33) with Microsoft SMTP Server (TLS) id 15.1.166.22 via Frontend Transport; Thu, 21 May 2015 14:36:12 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; redhat.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Thu, 21 May 2015 14:36:09 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB030.064d.mgd.msft.net (141.251.50.210) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 21 May 2015 14:36:08 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Thu, 21 May 2015 14:36:08 +0000 From: Santiago Zanella-Beguelin To: Aaron Zauner Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAJjSKAABE/AIAAAhIsgAAF+4CAAAlp2w== Date: Thu, 21 May 2015 14:36:08 +0000 Message-ID: <1432218967414.742@microsoft.com> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> ,<555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>,<1432209104.3243.65.camel@redhat.com> <1432211226723.39265@microsoft.com>,<555DDD4A.4040206@azet.org> <1432215726134.67809@microsoft.com>,<555DE40B.5050008@azet.org> In-Reply-To: <555DE40B.5050008@azet.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.151.241.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD011; 1:7EPxbWOzjJNfoeyPEu71DV6Wi+FM9QYizL3/9OOpAb7U6p4DbIzksh7QnNiAIeeWt3yHgh1HupfUS89gUOZ5+d/JJL4zLpxUBOhtUVj3RFt3y0xaEzPcjdGZhE5JHNfOBjGT94qCntS/bnjCDIuvowyadH4XCsXqHZRqxtns0xQjGL5/lryMGOYxJxriP8TPA0yavPsWQ12XcUTgOybJaOu5wK8T2rMkLnkzNMSQ0MdocU0HtHepVYcvAPxDsyUnsTtBygFboIiN0d0oipD1GFaVb6DPZAJJWDovv/4H0JM2psxPXNYAWM0LnUSFGaA7 X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(24454002)(189002)(377454003)(199003)(51704005)(106466001)(47776003)(2900100001)(2950100001)(68736005)(64706001)(15975445007)(102836002)(23756003)(16796002)(46102003)(77156002)(106116001)(62966003)(5001920100001)(5001860100001)(110136002)(5001960100002)(5001830100001)(66066001)(36756003)(6806004)(4001540100001)(97736004)(81156007)(87936001)(2656002)(69596002)(54356999)(76176999)(19580405001)(86612001)(50986999)(50466002)(19580395003)(93886004)(86146001)(189998001)(86362001)(92566002)(117636001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1351; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3PR03MB1351; 2:osfs1Kc7KK28YhKZM9GXwRzMd6PLJFEUz+mg2lvqhmRtsKZ5LBv+5BQuPqxsVlbd; 2:tlOOpYsaDO+QJnP1USiWAYkisICJADpp14oEN8UE4GS+KzOPnSO0XLZN6zlNNORlT1f14E9iL6iZxHqUc+UxfCuauudXKQRPqIo/Wbyx1LXKiIfkEAdPn/lKZyh1aDwRH7s2dmiChmqY7AwYmNqIBZmpUA0quFSarV+2U1Ey3yVSsGqU8fUQ/fU9TdDXEdMY4/gQEcML0h/0FS8vwigYI2M/FdQZaVCWPVt5kTRqkXi9SsYxyg2lX8aPV22wyl87; 6:VSbd0FzhnigHgiIKwOrhcuMh9d7CCgyRFDBTllF6wZHzvqb1rLGxjgxBo/JjBOy6rrr0pwjxUd84ix64tQ573sFhPDkKRLI5kcw2b8sPeQ3iYO1WMvcWzo+HoAImzwrxNTalXlTUmAtadWjbx702y0aK8mUgzhTZRzEa9yn7kFHAUqIvT/bR56exYDg1dUDTNq6LQ72fzRhwx7xIwgAT0nH2+N2hBeUaxX24vRyKFERTzx24O6RmUULZkLvN01RFzLZmdouh/U5QAUTuidgLyrB/IwlKcko/GKtgAsmdjEtbEYraLWM9sEIeH7xmxih9l/cxchm9fjWwFogkkG7Lmi6JJqS5Tdm8aBZVAdm9QzGDeb7JY4zfYXm89wbiCKwuJ1c5CnJR3GtHXk3G4gSaftY2Exg1UFlhBpawUyCO+xUyHmbWw0ZPYQiFKr7USJoIY3sjCwvOxKLwd9aLnpqFJWxtm7PyNIXyWsKxQxbD5q+8X5kjzZmkK8sqS+Wbeo3A X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1351; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN3PR03MB1351; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1351; X-Microsoft-Exchange-Diagnostics: 1; BN3PR03MB1351; 3:ks0AvdyvJ8jdLL5mqxvoTufaMM7yiq96J6p/tTdMVacj1ofKt2ku9SoYULtBx1r20AJLmyg8nvNHTHKxCOuUcS61ZO4vHJxyOBj61giECV+iWN8gbQxXda8oNyhnctNV0I1W4Wr7HgciycIi3WJp0qwGprEkp09aUug+V8uc6pDNfMOVoMoI/tjD8eyTV9I2XjlVF09cJV2MKUeYgtf7auuSvkBvZePooKYjCSnsLcrBjOZ2E9N+uUbNCcumL/zt3pHmvqD1yk6kmL5VL16lpXZ2FVn8QieBIP62FylKKm1bhw4OuZWScGcWDkwE0t+j X-Forefront-PRVS: 0583A86C08 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN3PR03MB1351; 9:rx7xvCAohQWVQkXDQkj9mqMgGRGNcy63xA141Dgl?= =?iso-8859-1?Q?8gyC8kHSvEW9DO2V+aP9PSZf6+AD9Ac/tNdaor2UQ4OsIm4bo+x5lyORcM?= =?iso-8859-1?Q?eNQzhvf9Ue8+eoj+55kRvpNnZ46V9Rin3qVyZn0ZTrEn0Ci1oOMcEDljsr?= =?iso-8859-1?Q?jTWwaSorFRzdstbPkvgKvoNQAdDznS45kXuvjkurx5SB3rtKKg0CWal4Fk?= =?iso-8859-1?Q?tup9NWI8Sg7z3wHsvB7MeVLbL2A5AnBWwONEY6jy+pmcFO2AtmI7zqzSZ/?= =?iso-8859-1?Q?9QunuxDPtPwA+4G6BKkb1Xt5gG+7kOC8hgDfdkAwQbiU8BG0LMSdkW9KQm?= =?iso-8859-1?Q?6U26gT+k/XUxuZ8zQOfbZYeUK7a2wbXAZzhwxXGc+ZynwTOUNp6ic3Xv+i?= =?iso-8859-1?Q?C3bbt4CwLWC8Is9LRBZZIMoww52c4ExAlIxBeqEeCs//0d6dWRcM5zcHWq?= =?iso-8859-1?Q?lg6z7PKfjj17Z9sJdWoF2TwvH7Vd15Ct3kw4/dbX4oLlB765AaHISSoWNc?= =?iso-8859-1?Q?qoDtMkrVJemx2Onnj2F8D4W7w4lD8ZIjLpab0QvvFbaVhN+ykx4vjDTes0?= =?iso-8859-1?Q?gipXjPJ35HPVttgNFKefk6J95a14XPQKToIXkVHGfWBcWi7Q9dyW6ZS5Ec?= =?iso-8859-1?Q?PZgifCFqn9i38/e8xR0SoNoIYH075gOFJ1QK7ragsOCPIJhDu1bYNzSKE+?= =?iso-8859-1?Q?4S0I4RRD7TGBqv1goZgAOWa3Tu5/Pd0uK1fzTe6y3KqGypRMRZkBcizmGY?= =?iso-8859-1?Q?Ds5AlqAjxeo5oyz/+NNIM0jBZ2t/T9unpDnqonDUxIoZENgJp5hfi2aS7G?= =?iso-8859-1?Q?ILgqMBy58lsC2Sk1gj2uNEIfy8Blt+wtVQQ/AplgIevRSOuzcw4RDs2/FW?= =?iso-8859-1?Q?8nz7EDn5jIND1GONaKvIfe8pE6llR0GyVLRXtPyOKWi8aF1hE6Jnrhpufp?= =?iso-8859-1?Q?kzeeRWlfaU9AXewcMHqnVkG7tZ2xcBSMAOFMG+Bf2hH88C/hqWdM/kXv8g?= =?iso-8859-1?Q?U+tnPnHERIBhfIXmYUvbJ4tZ8NomaBOoCAHH7NSH2FZUphvddzPJCvpDA4?= =?iso-8859-1?Q?0Rl2i3Tf8knvEtr1c5y1sFi7AbwL3+vXEJvBx8sCD9z9oSkYbnMaK/Zxn7?= =?iso-8859-1?Q?gdFh3lsHx7KJIYotsy93MKd3GjEUdh23G26ZMMJ93K6L64rmIqOXVh4Hyz?= =?iso-8859-1?Q?L6xXL9UWZfEunoXzcmsEZwPufag0yT52GLJ7m3/Z+AN08GfGSRadoxUtB+?= =?iso-8859-1?Q?L7iNE7bt8BUFb5Bse5tYUOubYDI4yvXxnxtws4F8bFYmlmXAK6NaltJyLc?= =?iso-8859-1?Q?o=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR03MB1351; 3:QYvvr+47r0ZcEqLU9hV7YyJATt1Kp+h+NE6PoXIslhX/0MFR0UA2x0QERnO2wtDCqEehuC9pfQTDh8R4lsGnTsLBpqaUxtGA0BW8ypU5nG1sASOO8DcrWsW2N83Ryq+chipWiFig3pvshmyPBSHqHQ==; 10:fS5V7EpURVi+pVK8QsNG2KqvZKTaeEMliF0rHMz9khyNUZGT64nSdMj20dadjY74zoASXpKvDEVcunXie6AOCGNXp5/mi4wusLkT7uRQIDQ=; 6:sVd8DaNC9npt+gIpwMPn5e14pBhIOCjpAO/gISXqCCExippWPqyL0Ajj/nU7/fz9 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 14:36:09.6716 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1351 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:36:35 -0000 > I'm not sure these are all due to people using openssl(1) with the > "-dsaparam" option, that's a huge number.=20 I'm sure they are not all using OpenSSL.=20 Other popular groups with a non-safe prime come from RFC 5114 (http://tools= .ietf.org/html/rfc5114#section-2). > My question was actually if people are aware that implementations > produce these primes per default. Java does: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/4fcbddfd97f0/src/s= hare/classes/sun/security/provider/ParameterCache.java Cheers, --Santiago ________________________________________ From: Aaron Zauner Sent: Thursday, May 21, 2015 2:56 PM To: Santiago Zanella-Beguelin Cc: Nikos Mavrogiannopoulos; Florian Weimer; tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin wrote: > Non-safe primes can be generated using OpenSSL dhparam with the -dsaparam= flag, e.g. openssl dhparam -dsaparam 2048 > > They are still very common. In a recent full IPv4 scan on port 443, we fo= und 1.7M hosts using non-safe primes against 8.42M using safe primes. > > By far, the most common non-safe prime appears to come from hosts using A= mazon EC2; around 321K hosts authenticating with browser-trusted certificat= es use it. > I'm not sure these are all due to people using openssl(1) with the "-dsaparam" option, that's a huge number. My question was actually if people are aware that implementations produce these primes per default. Aaron From nobody Thu May 21 07:37:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DEB1A1BBB for ; Thu, 21 May 2015 07:37:04 -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 1vSo8OwYMuUd for ; Thu, 21 May 2015 07:37:03 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 83DA71A1BB5 for ; Thu, 21 May 2015 07:36:59 -0700 (PDT) Received: by qget53 with SMTP id t53so40883518qge.3 for ; Thu, 21 May 2015 07:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=NZHQj8nC/Q4d6X2cQ9P/pCWEcKkJMeZaZkBx6UKqjNo=; b=dXcemFrD9tbz7fBkR7NG7pO/J4i/cM6ZiO50QaVeMd0ewoHHPcDDoIImwtXN7SUXvZ J872sOc9zH2C7QoqSuySsB2mHaalkAAs8ymRIyfzb8yx56HNHZ1YNjFvnopxIaC4lEgm jBskol87pF1H5Nv3UZ1f+vO3WsteE1dvkXSWcJbjDC+CLl2upxZJJ0rnN12KmyUisazn CvQR0g01WVM43BbIJgIB1iUJ3p92yYMykNlNlSuom+5eXLzl5MR/C+ifkKFOLVZf69Pm B9StBouFAo5d0yyL2Pu8mw0j0fumpU4OBjsXDoIOQaKGcfmsHqp0vmugecYZkWsHXiME GNMA== X-Received: by 10.55.48.134 with SMTP id w128mr6793800qkw.38.1432219018665; Thu, 21 May 2015 07:36:58 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id h49sm2848209qgd.24.2015.05.21.07.36.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 07:36:57 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Thu, 21 May 2015 10:36:56 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> In-Reply-To: <555DC498.2000109@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505211036.56692.davemgarrett@gmail.com> Archived-At: Cc: Florian Weimer Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:37:05 -0000 On Thursday, May 21, 2015 07:42:16 am Florian Weimer wrote: > I need something which prevents MITM attacks and can be applied as a > software update without configuration changes, and without extensive > testing because it is relatively risk-free. I also want a pony. From nobody Thu May 21 07:52:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AB51A1C04 for ; Thu, 21 May 2015 07:52:58 -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 gwdhwdVUvAjX for ; Thu, 21 May 2015 07:52:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149F51A1BD2 for ; Thu, 21 May 2015 07:52:54 -0700 (PDT) Received: from BN3PR0301MB0833.namprd03.prod.outlook.com (10.160.154.143) by BN3PR0301MB1201.namprd03.prod.outlook.com (10.161.207.154) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 14:52:52 +0000 Received: from BN3PR0301CA0008.namprd03.prod.outlook.com (10.160.180.146) by BN3PR0301MB0833.namprd03.prod.outlook.com (10.160.154.143) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 14:52:50 +0000 Received: from BN1BFFO11FD003.protection.gbl (2a01:111:f400:7c10::1:120) by BN3PR0301CA0008.outlook.office365.com (2a01:111:e400:4000::18) with Microsoft SMTP Server (TLS) id 15.1.166.22 via Frontend Transport; Thu, 21 May 2015 14:52:50 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1BFFO11FD003.mail.protection.outlook.com (10.58.144.66) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Thu, 21 May 2015 14:52:49 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 21 May 2015 14:52:48 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Thu, 21 May 2015 14:52:48 +0000 From: Santiago Zanella-Beguelin To: Nikos Mavrogiannopoulos , Florian Weimer Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAvugQ= Date: Thu, 21 May 2015 14:52:47 +0000 Message-ID: <1432219967072.32353@microsoft.com> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> ,<555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>,<1432209104.3243.65.camel@redhat.com> In-Reply-To: <1432209104.3243.65.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.151.241.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD003; 1:JJs0oSgPFkiTvqphjxsGc4Ls5JYgJhv1jNtxVQtP60F/jEQW+kVOq9PGEnIB8/S5PWPr+IBSyazux+lU4ob/2HtjWq+Lg2guRnS9yG1pVtxFejmcKw0NSak6ed0NbahH2Dlq5hE+CO0D8Kq4sueBRlsBa4kAaHMxQC6guKIAyXyIroq6vXZm5BMpUOiAx0yp2UszW1SL+XAdsjzncQyRwpdcDl4te3G8/xm7UtsjnQfC/g8mll8rv2hmrjE8LyL9o3LF+42Yt++9eDpPAJwTWlRoBHeeKFb7MOYpfx3VCzhi9R7muBKTOUFvWBYqbR9R X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(24454002)(51704005)(199003)(377454003)(189002)(479174004)(377424004)(86146001)(4001540100001)(2656002)(93886004)(102836002)(92566002)(68736005)(50986999)(46102003)(86612001)(15975445007)(81156007)(76176999)(86362001)(77156002)(16796002)(54356999)(87936001)(5001960100002)(2900100001)(66066001)(97736004)(62966003)(2950100001)(117636001)(64706001)(5001770100001)(5001830100001)(5001860100001)(23756003)(50466002)(6806004)(106466001)(106116001)(69596002)(47776003)(189998001)(19580405001)(19580395003)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0833; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB0833; 2:mfGAOEMeKoXNWIXDBt8j+mhss0qohZLuCxy35fvsyFtlBpa3Ol5cijiwJ8B7NB6a; 2:6+uWm+eloNvEHsJ64dSxrE4JJ6nr3Md/tyKZVtm2kuqnqinxbomNrfafrNoRA4OSCFfWnbDoxy4Obgi+V+gT+Qf5z93vFicl6Fv6end67Tq4izlP7pON8zBxMfuteiPZwJKobYmlM9gJ9WLyhvrvJFHFy/fn5l5U76MHTUwmmDBrWfLuqlADgJkQ+GXqKmBZJkMyarHpbyonzzirGTobEFPBdZj5VzfYiLQe72G9Fl6PcguGR7iJ6XZiwIYBIYI/; 6:XC7f1iZoKYnXBgNBDEilCHsZtkTN6RczlhkYwwqJQ03kTBX78nIwuhcIGMo5QVldpU0+QZUMjxcfivYwvwQSUPq1pVm7jvrA89S2Ic2RMeNN2IJpVYVGWaCZPYwHyRx05uaZUa6ZGu0wcOLIYwFlyAFW/5oDniWH43A7tQrVBOzTw7UVmDiYH/qAMaLiYLeKcXojMS+pR9ATFy6sQYdHraM5vYLLIjdqNqA0RN22Bgb175FZbDPU5PddcigC4HooGgDuhak+gfTn6CT0hLBfDDqrowst6RwmelXzUuxEFRC0wUxAZaTXXiejVumyx/549eZY30a6m+GIinS2soH/Fipi5v9UoXqD2tfRbkpWj06gLsY24G9TR5bz1MSDg1lUn4o+8/do6v3cpNKAPTc52XkAXwakLlQaUeS2w6yAkLobeLNJ26DGpW9bRfGVNaPxD7Ye2mwkGZZM8/McXD9T+j3qPPu9bYi60ZByo9TAUF1GPe39OQbzdbPu68G6N/4y X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0833; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1201; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN3PR0301MB0833; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0833; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB0833; 3:BYBct1vdwRUQW8muthQiCWpw5jz5wYAafRVMiT7tYjFCNvxF76UaN/qLHV40Yg1A/diVa9a25KgrjE2e4DMCQU29Yay6+wnlp86EJHiqnVNLfh8rdqXrerWc1p+RsWC+unXil0PI+TFYegpApvbexUS9mmUL1m6xU0GQGj2KwOqNFi/urMcujioaUMdjEkFlSS4NZGsaoGTlLgdBSl7qX4I6/6XvXh53IW3HYaOE5SoMBTWaPo4KZ+vN8mApwy4KnWcx/69mZGb/DYlN7MbBFrqryW0HT7J+AQnuzRbi+T6rLY4Afas3wuUhMRpJsvZu X-Forefront-PRVS: 0583A86C08 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN3PR0301MB0833; 9:77suTGtu3MOigzTChTImtTwgwxGU7SSBHwENfv?= =?iso-8859-1?Q?wExqwA/GindXc2BUhSrpptuxiLq3qFVMGF02xbPTmdKVLXKbxzlBlcaQRN?= =?iso-8859-1?Q?rSkK7Fu1IImCI64LJR7AqqvyhT1ickgUNdD3GQVCSCJjPfjDTk6xP0c9/+?= =?iso-8859-1?Q?b3rpzu5yXuHCOGlB+JsY6+1WJPHXYyOsCksfCvnuK9TmQm5pY7ctNlX6tj?= =?iso-8859-1?Q?qVz8y9TCAKPj213PLdPqw0dTPIPpxkqXKsSxbt608md9htacpquog6jC6R?= =?iso-8859-1?Q?+geynzDqV5bLQHKEo/KAEckQtuGRlpHHSzyg7qRWefTXDasnYWXA6jmsBH?= =?iso-8859-1?Q?kQko5qRLSh7lTkW7Hj43uSulaYKcswu/4/tA0gaMVrXpO/9oBo6PfgJd/7?= =?iso-8859-1?Q?jf8Nxa+2cluOwll4Os9bZeLJTyufSP//5Df5zGkE+CGO8hMKIeKbQ/qDNe?= =?iso-8859-1?Q?K6kdCEvjQeLVYcPsSdMqFNXaU1a2EctSWTRuSUI+d6mvSDqZhlZzfJcTXk?= =?iso-8859-1?Q?oYzAo2XZb8Dv/vP2J7kdqZ/8mG7K2+y8z5KAN1jsmYrQJ22Tfw/po+ONi/?= =?iso-8859-1?Q?3Jd7wJNBs0QDwdea62peaKMPbQXOeI7E+aOgmOAR3TAUsXSkFeEUMD7Nuc?= =?iso-8859-1?Q?bbxkEPhuA8S9NhTD47DUYu6j++LQjSuWIXMRV4yHxigw8QAbHCfTOSpmJP?= =?iso-8859-1?Q?4+H9pLtBo/krN5yxnYPMxV1PaEiRsoBt8mUtUabW11nh5RN1Fa1eWqruhA?= =?iso-8859-1?Q?ARuHf7sZKbZeWHUJoXP2uvk5lSj5gw3MQzJs7T/7yyJZAaGMA2akVBZg6c?= =?iso-8859-1?Q?wWQLu4nOAhqvPNi9X6o3RFAbnwdttb5R/XNbu3ujA+iYU/m/vsopI+FUaI?= =?iso-8859-1?Q?TivbadZ3gCH9F0VPmz6b1rlSAm/l3fhM6PjoRHZFKFfOkwfd1WgOyzyfy8?= =?iso-8859-1?Q?jnp3QcdH+PLN3SQO7ITwTIEQUUX2HGpcR0GZveGEJScM2GfnfSxbHu6on4?= =?iso-8859-1?Q?nWIurEf5uUEp/OrZ9J8cNXgCTxAzXjxkbPtzGv5MHvXNJs5HK6//9IPhl+?= =?iso-8859-1?Q?1oLxeD3LET6FCGtugOYBnW6n3SpLxoBpUjZ3+uV9uoRpgpN7jmhbqifaSO?= =?iso-8859-1?Q?i3hxhInd370tyD6jDNdHBy6R44zUuifBds1sjljAZ5/x1E315kwKjWCUd7?= =?iso-8859-1?Q?8ZOuCBHEc6/usr6qenLEfmSXuXC8YeF0SQnggyp+7LTb6nUgMBvcuhp66t?= =?iso-8859-1?Q?bMMD856lvxyWk6ALDQc5/FoxaLJ3IQpLWYp5+psOJVirxTKc+vLVp/fQcV?= =?iso-8859-1?Q?+3FkFcxbIQYUoNR/7XTJiD4g?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB0833; 3:GvOj0YN5zA2illPw8lUMx/Lkfw23Z0MohEj8iDf9BLBHit+ZQ+5wJPSX1z5TkfWBzFkLeR0TQa6ioWaA4b7ZBEf9itaOUtRU9ORncyclTz8zDa/ViIU9KKhA+U0QQVLpOecWAowSZRXznOhdtmv4Gw==; 10:nFo2v0ru4xQBdQw6/DZ0HltAS15i2kCNRjUwd5xDSayHkk/kZuUigQwA9q7QrSo74NZTMAVFJXgijyEowZbABY/UV3RzFbTjRVbucI0wWYM=; 6:WwIPaj0vk7g3b1UR4D3uluQfXjv5B71LeDkDOF1vmITd/wvTty4nWEAHltICr2AA X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 14:52:49.4692 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0833 X-Microsoft-Exchange-Diagnostics: 1; BN3PR0301MB1201; 2:ChLcWRiqxBHRfXQzoPmLNbn0Va7x4unXPBX39V3VOZ9XPcYEBxtpCXnmfeFqz89J; 2:ExWIiwKJ81h/v9r7ROSK+3wYXdP4OUkYhA9WI6rnGBHJMHpKbdA9+rXQ+frhaDz34sG7hwJ5hBYDpeuGGCnWCUfpp7XFk3WzH4cF/9aX1Jw7E0ZS+UVbKUT8mWn3FgXn/B26HszwJt5r8VK8mWfw1zCD2pKnj38tg9wYaU1Q1e2MGNhEhixYNxzW7T65tpHGo1MAPxuYhA4DlbtxDJSVJldrvdngxqT1QN63OwGg6egWlYTV7huET8sshOMpUJ0I; 9:rJtNOKatQSyKXzpagdhznGMeuJkLOAzHCbBP3AKhg3M13VfGDFMBD0H9dxsFE98DoIxpNCpo0aRPTcoPmK4VBs/EipprvqYq6nlV9+MePH84yKIb5vT0jTV6koNqzYU7+FwLTdw4LZ8ISFMYS7nR7A== X-OriginatorOrg: microsoft.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:52:59 -0000 Regarding validation of DHE parameters and how reasonable it is in practice, I wanted to make some publicity for miTLS (http://www.mitls.org/). A miTLS client maintains a table of known trusted parameters, including the subgroup order for parameters with non-safe primes. When receiving unknown parameters from a server, it tests the primality of p and (p-1)/2 to check if p is a safe prime (and caches a positive result in the table). If the modulus is prime but not safe, miTLS checks if it is in the table of trusted parameters and otherwise rejects it. We distribute miTLS with a pre-populated table of parameters which we tested thoroughly (and we welcome people to test further). Most of the time we hit an entry in the table.=20 I think a table lookup per key exchange is about as reasonable as it gets. Cheers, --Santiago ________________________________________ From: Nikos Mavrogiannopoulos Sent: Thursday, May 21, 2015 12:51 PM To: Florian Weimer Cc: Santiago Zanella-Beguelin; tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS On Thu, 2015-05-21 at 13:42 +0200, Florian Weimer wrote: > On 05/21/2015 01:31 PM, Santiago Zanella-Beguelin wrote: > > > Deprecating non-safe DH primes and having clients test primality of p a= nd (p-1)/2 goes a long way. It doesn't rule out all weak groups or trapdoor= s. > > I need something which prevents MITM attacks and can be applied as a > software update without configuration changes, and without extensive > testing because it is relatively risk-free. Well, you assume that the so-called "safe primes" are universally used, which is not really the case. Expecting all servers sending these parameters wouldn't really work. In addition the check you have isn't complete, you'll also need to calculate the order of the generator and verify it is sufficient. I don't think that approach is close to being reasonable to be done on every connection. > Rejecting handshakes in clients without additional measures risks that > (a) additional handshakes fail, leading to service outages and (b) > clients will fall back no encryption at all (after manual intervention, > or automatically in case of SMTP with STARTTLS and opportunistic > encryption). The way I tackled the issue in gnutls is to prioritize the ciphersuites of the client in that order: ECDHE, RSA, DHE, and perform a size check on the DHE ones. regards, Nikos From nobody Thu May 21 09:10:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625531A8885 for ; Thu, 21 May 2015 09:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 XXVdUdKbyaJc for ; Thu, 21 May 2015 09:10:45 -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 922E01A8874 for ; Thu, 21 May 2015 09:10:45 -0700 (PDT) Received: by qkgx75 with SMTP id x75so58751882qkg.1 for ; Thu, 21 May 2015 09:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:user-agent:mime-version:to:content-type :content-transfer-encoding:message-id; bh=hjXyn4oVup7iH5iFXu0N6mz1LTtG3sBUPZ+zsOp1wzs=; b=xHZJB91w6PQgIF0v/Fv+RNwbPQvJ0fVv9yp8Mlwk8L/PvD1Mq21jGd0uZl1jt5sdxT LMh4NUjDWdoU+UjueudcoRvzlxjsIZdb+lRa8zp2Zr2232EUlECsz0qiU2flAWPLYM2A vETWxpunYsgBwB1hwAFX3cfkxLnMKF+0AcxWFTO7EeCleBsG88muxp8HHBWS0USGFrGs EN3ggREka94NSv8CQL4xT+W/sRpni5hSWNt02+E87Yf4/QjsLNOuuiqdnC1QuTObaIzO GY/mRc25gaIF0QvoEEH5pNj2JF9xeXOCvzGvo6FCe8TlCRlLyMfa4LAQ1MVD1mX+/uF/ iKOQ== X-Received: by 10.55.25.134 with SMTP id 6mr7957814qkz.13.1432224644796; Thu, 21 May 2015 09:10:44 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id u95sm13524516qge.16.2015.05.21.09.10.43 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 09:10:43 -0700 (PDT) From: Dave Garrett Date: Thu, 21 May 2015 12:10:42 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 To: tls@ietf.org Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201505211210.43060.davemgarrett@gmail.com> Archived-At: Subject: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:10:47 -0000 I was going to hold off on suggesting this due to other topics dominating the list, but we might be in a kill-the-old-junk mood due to the latest old-junk vulnerability, so... Old versions of TLS need to be phased out at some point (even the one we're designing now), however the current modus operandi is generally to wait until a catastrophic breakage forces everyone into a panic disable. I'd like to at least try to do better prior to the next time. I'd like to propose giving servers & clients different expectations as a transitional measure: 1) No general change to current TLS other than pointing to the UTA BCP from time to time. https://tools.ietf.org/html/rfc7525 2) For TLS 1.3, add a blurb to the effect of: "Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiate TLS 1.0 or TLS 1.1 for any reason. Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible." The reasoning here is that major server updates are unfortunately uncommon, but client updates are routine. Server implementations get updated, but deployments don't/can't keep up. There are no legitimate clients that do not support TLS 1.2, and even plenty of old ones can support it if actually enabled (and those vendors should get their act together and push updates to flip that on for all old versions, regardless of EOL status). The current strategy is basically to support everything forever and that has been shown to be quite detrimental, especially over the past year. Note that this is not just about dropping support for versions X & Y. It's about giving implementations a chance to drop all the baggage that comes with those old versions and focus only on reasonably modern standards instead. For those that would disagree with mandating servers drop support for the protocol from 1999, I think it's reasonable to just require you to have to ignore the RFCs if you really want to keep doing this sort of thing in 2015. Everyone else should have servers that have at least vaguely reasonable minimum standards out-of-the-box. Allowing obsolete security to be considered legitimate is a public hazard, and I don't want to wait around for more exploits to deal with it. Security is only as strong as the weakest link; we need to start baking this into new specifications Dave PS I am aware some vendors irresponsibly abandoned lots of mobile users on obsolete OS versions. They should be treated like WinXP+IE6: useless until you download a better browser yourself. If that's not possible, complain to the hardware vendor that didn't provide updates. From nobody Thu May 21 09:45:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C964A1A8953 for ; Thu, 21 May 2015 09:45:27 -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 x9BW0e_USoBo for ; Thu, 21 May 2015 09:45:26 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA5E1A893F for ; Thu, 21 May 2015 09:45:26 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so15133712igb.0 for ; Thu, 21 May 2015 09:45: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:content-transfer-encoding; bh=Ta86wAgmcvG7SVbTtmsPDoTY77BHmG05EO7XS6KCxYM=; b=i98giNwvK3C4YDf/YrjLkESxu0ya47HkE7q2TjyQ9/clmvigtOxbaKoejg7rkeOQu8 GLdzy8k1Bhbj1BbS52b/tff/Ee9hETNAMZxjnMnY0Xqs5/t52mUU4WTKbiz7FZxEitUP WZZWf3K9BP5IHHa5/BurgRMFIFEBndpeKlul9y5rwnSZweKVutglF+1XQiTtdum6eilh 6pp8tX7Qo2Q0tBeCvgRzM1hIrHCPIRAePV2AlPLbzY49VIwnpE1KgypKMb0Cz/myutxu Ui1CwROWz/qRo1sqKbEVXk6xJlX2iH7hQttOvu8rFwt1yw+d/O735UiWMVD5QIbBCuXF 0/yQ== MIME-Version: 1.0 X-Received: by 10.50.8.68 with SMTP id p4mr5269988iga.4.1432226725554; Thu, 21 May 2015 09:45:25 -0700 (PDT) Received: by 10.50.25.231 with HTTP; Thu, 21 May 2015 09:45:25 -0700 (PDT) In-Reply-To: <201505211210.43060.davemgarrett@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> Date: Thu, 21 May 2015 16:45:25 +0000 Message-ID: From: Loganaden Velvindron To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:45:28 -0000 On Thu, May 21, 2015 at 4:10 PM, Dave Garrett wrot= e: > I was going to hold off on suggesting this due to other topics dominating= the list, but we might be in a kill-the-old-junk mood due to the latest ol= d-junk vulnerability, so... > > Old versions of TLS need to be phased out at some point (even the one we'= re designing now), however the current modus operandi is generally to wait = until a catastrophic breakage forces everyone into a panic disable. I'd lik= e to at least try to do better prior to the next time. I'd like to propose = giving servers & clients different expectations as a transitional measure: > > 1) No general change to current TLS other than pointing to the UTA BCP fr= om time to time. > https://tools.ietf.org/html/rfc7525 > > 2) For TLS 1.3, add a blurb to the effect of: > "Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiat= e TLS 1.0 or TLS 1.1 for any reason. > Client TLS implementations are RECOMMENDED to not support old TLS version= s, where possible." > In Implementations like OpenBSD, this is already happening. For example. libtls supports 1.2 by default. > The reasoning here is that major server updates are unfortunately uncommo= n, but client updates are routine. Server implementations get updated, but = deployments don't/can't keep up. There are no legitimate clients that do no= t support TLS 1.2, and even plenty of old ones can support it if actually e= nabled (and those vendors should get their act together and push updates to= flip that on for all old versions, regardless of EOL status). The current = strategy is basically to support everything forever and that has been shown= to be quite detrimental, especially over the past year. > > Note that this is not just about dropping support for versions X & Y. It'= s about giving implementations a chance to drop all the baggage that comes = with those old versions and focus only on reasonably modern standards inste= ad. > > For those that would disagree with mandating servers drop support for the= protocol from 1999, I think it's reasonable to just require you to have to= ignore the RFCs if you really want to keep doing this sort of thing in 201= 5. Everyone else should have servers that have at least vaguely reasonable = minimum standards out-of-the-box. Allowing obsolete security to be consider= ed legitimate is a public hazard, and I don't want to wait around for more = exploits to deal with it. Security is only as strong as the weakest link; w= e need to start baking this into new specifications > > > Dave > > > PS > I am aware some vendors irresponsibly abandoned lots of mobile users on o= bsolete OS versions. They should be treated like WinXP+IE6: useless until y= ou download a better browser yourself. If that's not possible, complain to = the hardware vendor that didn't provide updates. > With Android One label, Things are slightly less worse now. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu May 21 09:51:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC261AC3B6 for ; Thu, 21 May 2015 09:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43ChRMPG-ASV for ; Thu, 21 May 2015 09:51:31 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 851FE1A895E for ; Thu, 21 May 2015 09:51:26 -0700 (PDT) Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 21 May 2015 12:51:19 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0210.002; Thu, 21 May 2015 12:51:19 -0400 From: Dan Brown To: "'santiago@microsoft.com'" , "'nmav@redhat.com'" , "'fweimer@redhat.com'" Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYrGMmex37dc0iNG+rWIQqT5p2FORUAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX8AgAAC8wCAAAMhAIAAAqYAgAAylYD//8puMA== Date: Thu, 21 May 2015 16:51:18 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> References: , <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> ,<555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com>,<1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> In-Reply-To: <1432219967072.32353@microsoft.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0015_01D093C4.D488C2B0" MIME-Version: 1.0 Archived-At: Cc: "'tls@ietf.org'" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:51:33 -0000 ------=_NextPart_000_0015_01D093C4.D488C2B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the Imperfect Forward Secrecy paper, Section 5 Recommendations, the medium term recommendation to avoid fixed-prime DHE groups seems to conflict with the current direction TLS is taking towards named only groups. I gather that TLS is still planning keep DHE around (as a supplement to ECDHE). So, should TLS stick to its current approach of using named DHE groups, just with larger key sizes, or should it follow the recommendation above of allowing custom DHE groups? Maybe this is question for CFRG, since it can pertain to multiple WGs? If TLS opts for the latter, to bring back custom DHE parameters per the recommendation above, then it seems that TLS should expand on the simple TLS 1.2 ServerDHParams, by including the order of the generator, and probably including some kind of seed to a PRF (making them similar to the old custom ECDHE parameters). Note that ECDHE and DHE largely share the issue of fixed parameters are affected by a pre-computation across multiple keys. Choosing a larger key size is the most efficient and simple remedy against these pre-computations. Allowing custom groups provides a second defense against the such pre-computation, but supporting custom groups creates other problems. Peers need to verify the custom groups, and the groups need to be generated. The computation and communication spent on verifying custom groups could perhaps be better spent on using larger fixed groups. My preference is to recommend larger, vetted, fixed groups (e.g. at least 2048-bit DH and 256-ish-bit ECDHE) just as TLS and CFRG are currently doing, but to still keep custom groups (of similar size) as an option, perhaps to be added later after some further discussion about the best way to specify custom groups. I understand that TLS currently has the means to support an escape valve for custom groups, but it leaves the syntax entirely up to the peers to decide upon. I think a more specific support for custom groups might be a more useful escape valve, at least in the medium term. > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Santiago Zanella- > Beguelin > Sent: Thursday, May 21, 2015 10:53 AM > To: Nikos Mavrogiannopoulos; Florian Weimer > Cc: tls@ietf.org > Subject: Re: [TLS] Another IRINA bug in TLS > > Regarding validation of DHE parameters and how reasonable it is in practice, I > wanted to make some publicity for miTLS (http://www.mitls.org/). > > A miTLS client maintains a table of known trusted parameters, including the > subgroup order for parameters with non-safe primes. When receiving > unknown parameters from a server, it tests the primality of p and (p-1)/2 to > check if p is a safe prime (and caches a positive result in the table). If the > modulus is prime but not safe, miTLS checks if it is in the table of trusted > parameters and otherwise rejects it. We distribute miTLS with a pre-populated > table of parameters which we tested thoroughly (and we welcome people to > test further). Most of the time we hit an entry in the table. > > I think a table lookup per key exchange is about as reasonable as it gets. > > Cheers, > --Santiago > > ________________________________________ > From: Nikos Mavrogiannopoulos > Sent: Thursday, May 21, 2015 12:51 PM > To: Florian Weimer > Cc: Santiago Zanella-Beguelin; tls@ietf.org > Subject: Re: [TLS] Another IRINA bug in TLS > > On Thu, 2015-05-21 at 13:42 +0200, Florian Weimer wrote: > > On 05/21/2015 01:31 PM, Santiago Zanella-Beguelin wrote: > > > > > Deprecating non-safe DH primes and having clients test primality of p and > (p-1)/2 goes a long way. It doesn't rule out all weak groups or trapdoors. > > > > I need something which prevents MITM attacks and can be applied as a > > software update without configuration changes, and without extensive > > testing because it is relatively risk-free. > > Well, you assume that the so-called "safe primes" are universally used, which is > not really the case. Expecting all servers sending these parameters wouldn't > really work. In addition the check you have isn't complete, you'll also need to > calculate the order of the generator and verify it is sufficient. I don't think that > approach is close to being reasonable to be done on every connection. > > > Rejecting handshakes in clients without additional measures risks that > > (a) additional handshakes fail, leading to service outages and (b) > > clients will fall back no encryption at all (after manual > > intervention, or automatically in case of SMTP with STARTTLS and > > opportunistic encryption). > > The way I tackled the issue in gnutls is to prioritize the ciphersuites of the client > in that order: ECDHE, RSA, DHE, and perform a size check on the DHE ones. > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_0015_01D093C4.D488C2B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICClvwCZYABAA8faIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTE1MDQxMDIxMjgwNFoXDTE2MDQwMjAxMTEwNVowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAnqyPpiXJ8uIKCHaqpEmU2q/9KYQJi6yizaJruUGAoUstFzjV7XymMDqnaZqLR/QQoR3Qojm2 pjb3luP0P+37tro+PlKEgODyauhfaT78GLlJHq3GZxI6N27UHyYHWGFglAh6uCaHcGBitBZCyEFr n+FDG5cYb89jhPuiZWu48ocCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFHxbvAxpbwEMJEmG6lwbqKCLBREQMB8GA1Ud IwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAJmZR wd1UREUFudy4RWbVn/3YgfoH3WC5GElyoNzatY6Cm8B+1NLUeHwH2NMtoekwC2H+l+xH3Dt2mAuE n7kpR8rou2aafkauVYZpkD5DsZd8etdx/3dZ/sA66Urieyd2O4KdIhBLvk1jp8TklI5ktJ0pb8In tTNXjhN/T0yACoymL8YUbMZ130B1ksYe+OuU/KvHcQepQLxTuTNcGhToCP/HXpOiNuUkyLo6YahX gKcCJk/myNi3GY4FbqMTJvuOSf645cbY2Q+3esguzO1MBSVwYv5Qh/aIY+JJHUHab10IM7tAtFbO w0E695QEBEaSMQ7VY7oX3UNBpoDqpyHZTDCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJ3m4YAAAAAAiwwDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDEwMTA1WhcNMTYwNDAyMDExMTA1WjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDH8YxcxLmGv6nenV7uByC7QXR9/gYMM97kGpA3 Mb63938lUAcuvShTkvP4eURHum4rd7aecLEEL/5xVZplyv46vcw+9s5d47+t1M2YDlgvdPOOlMU0 5pjRMh86NTOeAdy65xOi9kOkGxGTAJ6yferlfKTdl2bJ+Y/jL3yOWoxbvuqD2x3mM0I2Qdxg47u7 BC5u3AHK9GGF98Xi0wdqy1FGRejcsnNG7Q+ewEWBGvfQPuibJTvFXMbZYEXXcdezQeoLbTY8JiRU 95d1FXCuTuflFUlqVtc0G2UAb5dIj+4F3KyVuA79KdN+oh4PZYA1dakAoYvTQoscJu8mLQhy6vWp AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBS4MBdub2eV/oWMaDul4Rez P/glOjALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFMOXm3j5 YZ17uL9jpaOoQQnTuW3kMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQAfapyc7N66k5yLTjRPqBC6kIbHPPxDLVP6 +td2LQh2gUBskJO2xbscb3Se5kIo6TYON4jdWBmkCQ4PEoFLOMUE511QKfulKIRVX0QzU0ELEhKL SeyIByM47XV5aOEwy9bfZ3H8fV5/WkDBV5Tx3wuCNPGV+a2H4ujQxKCFTp6i9aBBxyHKI9jkaJtD vjO9np84HzarnURNJfR1jRiXDk2Asw0lZuX/Ur9+uGfp0NfoU91MINRCMhg7gPKWLXUY1oLoh1CB r/UD99FVnzCmV5dCjUy0Ie0+tHgxYRUnq49r8FnA0dy4v8RNXjiYelKbAYgq2vAg+OtT5FNoEhD1 vk4uKwjzXoKtpxlfuDQ9KYOTXORwKlGw2zL5vHJUgfCKJj5Js9jUf8aPeDIQN5fXuyAzLutrpYBG dPr5/mwR+mxeU8Bk66E0rlu0bNd2bK0s9bL2h6cosA+VTBUfK3Dp8GomyWWfzEXxG3I1C4PK9Qkt YLJHUqN/YrqnDIia8xVl7/vDscLOwByBtfaf0yuQS7SYZ//Emhd7eEFzKhvAIPMYzqlEG65tv6d9 ng8LrTZ/Vvrl3pHZiO50OQ5KP20qC3ZBszs2Y8cFgA9hO8R9zi44qnumXkoy4lxw8JlZfo9A3Vul xXR5cLkNdL/wnGkZxekwzX+jrAdaCpYoACKnJP3MqDGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAzWUtGAgpb8AmWAAQAPH2iMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUyMTE2NTExOFowIwYJKoZIhvcNAQkEMRYEFGtR 6jHpDrfZBxOsRV5Q7fJQDQMoMG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGAgpb8AmWAAQAPH2iMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZ S0YCClvwCZYABAA8faIwgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYBrVbDhyRR9utljJYVrAKje6qQ8pRAE LalBWvfsxSVmmfFkWXTwhCyI80B1UR74yeWxuYj6d8QtD8fLC4YW6IAgfyetsBRUgUDDRnDbvjOW V2+sEQbkNX5BlUN2UMEr9zDuMC598S3+vKPzz1yFA+CK4falsnJ78+LVAye0o8n3nAAAAAAAAA== ------=_NextPart_000_0015_01D093C4.D488C2B0-- From nobody Thu May 21 10:47:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C89A1A0199 for ; Thu, 21 May 2015 10:47:36 -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 0JhPNvqDonkX for ; Thu, 21 May 2015 10:47:35 -0700 (PDT) Received: from mail-wi0-x243.google.com (mail-wi0-x243.google.com [IPv6:2a00:1450:400c:c05::243]) (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 101131A0194 for ; Thu, 21 May 2015 10:47:35 -0700 (PDT) Received: by wivz2 with SMTP id z2so2386457wiv.0 for ; Thu, 21 May 2015 10:47:33 -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=EybbphnqA09pUGM0fzgsqUWNeYaFSrHcOgAjqKpr+9M=; b=XBAWqoDizJMoyWOhaMjNAFPnF9/gw7fbQrhnHXBTaleIoFGb7Lv3mhW6jOAgEse0+M skXzqereGqo6e9n71h3gbzWIgoWSXeT9m9uGHwtI2kukfu2Y6wgkL1vPnB51jUIc3GJS YF6/K+snaWm+PgfokdnJwDCQe/QdwEyyqYGNAgsXRHFVLqHkm+m+IfXyXxIVuFwy32v2 rjTXOvPgIUQao+9uuMIDcexAvgMOx879rp3nGJondhFOg1Dzud3+ph/QfADw4X/owZFI g+uuTa14+IA/v+54+5afWSzWitNHPb8MrrUJbxI7XNxQtKrMh+GgHfFJWfI1Yr6tVBpw jYig== X-Received: by 10.180.77.195 with SMTP id u3mr8587419wiw.30.1432230453801; Thu, 21 May 2015 10:47:33 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id um5sm33162857wjc.1.2015.05.21.10.47.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 10:47:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <201505211210.43060.davemgarrett@gmail.com> Date: Thu, 21 May 2015 20:47:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <38D583BF-DFD0-4EFF-83D7-33FB3E2507D7@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:47:36 -0000 > On May 21, 2015, at 7:10 PM, Dave Garrett = wrote: >=20 > I was going to hold off on suggesting this due to other topics = dominating the list, but we might be in a kill-the-old-junk mood due to = the latest old-junk vulnerability, so... >=20 > Old versions of TLS need to be phased out at some point (even the one = we're designing now), however the current modus operandi is generally to = wait until a catastrophic breakage forces everyone into a panic disable. = I'd like to at least try to do better prior to the next time. I'd like = to propose giving servers & clients different expectations as a = transitional measure: >=20 > 1) No general change to current TLS other than pointing to the UTA BCP = from time to time. > https://tools.ietf.org/html/rfc7525 >=20 > 2) For TLS 1.3, add a blurb to the effect of: > "Server TLS implementations supporting TLS 1.3 or later MUST NOT = negotiate TLS 1.0 or TLS 1.1 for any reason. Is this needed for interoperability, or is this just a good idea that = you want to slap a MUST on? It=E2=80=99s the latter. It belongs in a BCP, not in the protocol = document, and that is where it already is. It=E2=80=99s not the IETF=E2=80= =99s job to make deployment decisions like that. Yoav From nobody Thu May 21 10:58:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FECE1A00D6 for ; Thu, 21 May 2015 10:57:59 -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 ec1PDg2LrNmB for ; Thu, 21 May 2015 10:57:56 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652F01A007F for ; Thu, 21 May 2015 10:57:56 -0700 (PDT) Received: by wizk4 with SMTP id k4so23400655wiz.1 for ; Thu, 21 May 2015 10:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4iz2erPytb3zU0muYZ+28+RgkAtr96VWL6PHt0cYg6w=; b=y8zi4KRHZwSojLNTuBwdTXKlvLhvqBKN30sJey3xLmiJY1WhtK8MnW3MmqvtLgNIiC CWjzNThM7phh79wD/svRpbihUH7G3+Fb+jkYjuuVNIuyaqhgn0xRr2lCSTwNsj4NXM1g qIVs5t6NerQ/czj70BcxOZ/soxowYL0nLp9hfZ1qObQlRAWDU/WEZT1y9rWTXwsOwAWX DtXgSn8xlISMADgr4igXcQjQQrPgpokq425HHnKCJtHUXKF0L4ecRKzgD0A+Rx4S78UT gtmmTfCSuehXg0MnMjepvjBlfCSXIxlhvfM74VBCwu14ShImBRbj8B2XqlKgxAvaawJF 44uQ== MIME-Version: 1.0 X-Received: by 10.180.103.231 with SMTP id fz7mr8567072wib.35.1432231075149; Thu, 21 May 2015 10:57:55 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Thu, 21 May 2015 10:57:54 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> References: <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> Date: Thu, 21 May 2015 13:57:54 -0400 Message-ID: From: Watson Ladd To: Dan Brown Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "fweimer@redhat.com" , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:57:59 -0000 On Thu, May 21, 2015 at 12:51 PM, Dan Brown wrote: > In the Imperfect Forward Secrecy paper, Section 5 Recommendations, the > medium term recommendation to avoid fixed-prime DHE groups seems to conflict > with the current direction TLS is taking towards named only groups. Is that *really* what the recommendation says? It's true that using the same group repeatedly enables an attacker who does an L(1/3) calculation to quickly compute all discrete logarithms together. But instead of making countermeasures to this, it's far easier to ensure that the price this precomputation is large, by using larger groups. > > I gather that TLS is still planning keep DHE around (as a supplement to > ECDHE). So, should TLS stick to its current approach of using named DHE > groups, just with larger key sizes, or should it follow the recommendation > above of allowing custom DHE groups? > > Maybe this is question for CFRG, since it can pertain to multiple WGs? > > If TLS opts for the latter, to bring back custom DHE parameters per the > recommendation above, then it seems that TLS should expand on the simple TLS > 1.2 ServerDHParams, by including the order of the generator, and probably > including some kind of seed to a PRF (making them similar to the old custom > ECDHE parameters). > > Note that ECDHE and DHE largely share the issue of fixed parameters are > affected by a pre-computation across multiple keys. > > Choosing a larger key size is the most efficient and simple remedy against > these pre-computations. Exactly. No need to proceed further. > > Allowing custom groups provides a second defense against the such > pre-computation, but supporting custom groups creates other problems. Peers > need to verify the custom groups, and the groups need to be generated. The > computation and communication spent on verifying custom groups could perhaps > be better spent on using larger fixed groups. You've just explained why I'm against it, better than I could. So what actually is the reason you support it? > > My preference is to recommend larger, vetted, fixed groups (e.g. at least > 2048-bit DH and 256-ish-bit ECDHE) just as TLS and CFRG are currently doing, > but to still keep custom groups (of similar size) as an option, perhaps to > be added later after some further discussion about the best way to specify > custom groups. Why do custom groups help? We've seen how they can hurt, by complicating implementations, making possible cross-protocol attacks, and other kinds of nastiness. You're asking that we adopt them so that an attacker who does a massive calculation gets only one useful result, instead of having to repeat a calculation they already did a few times. How many months of extra time does this get us? > > I understand that TLS currently has the means to support an escape valve for > custom groups, but it leaves the syntax entirely up to the peers to decide > upon. I think a more specific support for custom groups might be a more > useful escape valve, at least in the medium term. > > >> -----Original Message----- >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Santiago Zanella- >> Beguelin >> Sent: Thursday, May 21, 2015 10:53 AM >> To: Nikos Mavrogiannopoulos; Florian Weimer >> Cc: tls@ietf.org >> Subject: Re: [TLS] Another IRINA bug in TLS >> >> Regarding validation of DHE parameters and how reasonable it is in > practice, I >> wanted to make some publicity for miTLS (http://www.mitls.org/). >> >> A miTLS client maintains a table of known trusted parameters, including > the >> subgroup order for parameters with non-safe primes. When receiving >> unknown parameters from a server, it tests the primality of p and (p-1)/2 > to >> check if p is a safe prime (and caches a positive result in the table). If > the >> modulus is prime but not safe, miTLS checks if it is in the table of > trusted >> parameters and otherwise rejects it. We distribute miTLS with a > pre-populated >> table of parameters which we tested thoroughly (and we welcome people to >> test further). Most of the time we hit an entry in the table. >> >> I think a table lookup per key exchange is about as reasonable as it gets. >> >> Cheers, >> --Santiago >> >> ________________________________________ >> From: Nikos Mavrogiannopoulos >> Sent: Thursday, May 21, 2015 12:51 PM >> To: Florian Weimer >> Cc: Santiago Zanella-Beguelin; tls@ietf.org >> Subject: Re: [TLS] Another IRINA bug in TLS >> >> On Thu, 2015-05-21 at 13:42 +0200, Florian Weimer wrote: >> > On 05/21/2015 01:31 PM, Santiago Zanella-Beguelin wrote: >> > >> > > Deprecating non-safe DH primes and having clients test primality of p > and >> (p-1)/2 goes a long way. It doesn't rule out all weak groups or trapdoors. >> > >> > I need something which prevents MITM attacks and can be applied as a >> > software update without configuration changes, and without extensive >> > testing because it is relatively risk-free. >> >> Well, you assume that the so-called "safe primes" are universally used, > which is >> not really the case. Expecting all servers sending these parameters > wouldn't >> really work. In addition the check you have isn't complete, you'll also > need to >> calculate the order of the generator and verify it is sufficient. I don't > think that >> approach is close to being reasonable to be done on every connection. >> >> > Rejecting handshakes in clients without additional measures risks that >> > (a) additional handshakes fail, leading to service outages and (b) >> > clients will fall back no encryption at all (after manual >> > intervention, or automatically in case of SMTP with STARTTLS and >> > opportunistic encryption). >> >> The way I tackled the issue in gnutls is to prioritize the ciphersuites of > the client >> in that order: ECDHE, RSA, DHE, and perform a size check on the DHE ones. >> >> regards, >> Nikos >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu May 21 11:51:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A191A87C2 for ; Thu, 21 May 2015 11:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 YJKw4xwcm-lN for ; Thu, 21 May 2015 11:51:35 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 47A111A87B8 for ; Thu, 21 May 2015 11:51:35 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so18119029igb.0 for ; Thu, 21 May 2015 11:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=MWeILi++/Glej8UN4mjNnr1z413S1yC/uvAmeqmHHmM=; b=eA6hiQx1a/Wfaqw8siC8UZizicCXWHpJNR7ozbvyCmByFNXPx6Nys5n7SN6beT3HUu a0FgF1UpZdEfju/wCaBRF5KgXYN2zkcTlDc+HE83NbSRRxmmRSlAmQuadXssXyeytL5E C8YD1SPge5Wzp2K+qT9KPxGEyhDD7x/UnOA8rNik43uM3ibcay29S1Fa3GpI/2UFy2vj KsqyvLBEtQbizIqvywig/iWpBWc3X/avCFuLpAZ/4L5HHYpKXaAACoqMXKTr9AOKuQCl f0JXD7oyXIV2HSTCSwI1DW2U6HucVGMaGqC3gLP8z/Xw7M+AUVjQeT5CydkQt3W0/zWW P3bw== MIME-Version: 1.0 X-Received: by 10.107.157.130 with SMTP id g124mr5435536ioe.11.1432234294695; Thu, 21 May 2015 11:51:34 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Thu, 21 May 2015 11:51:34 -0700 (PDT) Date: Thu, 21 May 2015 14:51:34 -0400 Message-ID: From: Jeffrey Walton To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Using Warning Alerts to Accommodate Offline Attacks? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:51:36 -0000 The logjam paper is available at https://weakdh.org/imperfect-forward-secrecy.pdf. Note that the authors were successful in exploiting some user agents because they could send an alert warning to reset the handshake timer. The timer reset accommodated the offline portion of the attack. Cf., page 5. Is this desired behavior? Or is it a security bug? Jeff From nobody Thu May 21 12:07:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B661A8896 for ; Thu, 21 May 2015 12:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.988 X-Spam-Level: * X-Spam-Status: No, score=1.988 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 B9ApqT6YChAV for ; Thu, 21 May 2015 12:07:27 -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 EC4E91A88C7 for ; Thu, 21 May 2015 12:07:24 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so25168740wic.0 for ; Thu, 21 May 2015 12:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inurbanus.nl; s=google-inurb; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZSytv7mmOBckRgDswMhfOdu4AFNvvqT142NjUxtNGsw=; b=G3Lr43xGSoECsxkEy7NCZ8oyBBdtQ/KX3IF37cgc/oqu0M0VCVJUj4+OzUC7A5xMg1 L2LV96e3Oqtkk5ffb7Je8vWnzfISQxYPrOCfMEzPiGKgaajvzkXzQxmfAhk0uT0m1oSp 6ylfbEpk7G9TyIvkt6ftwvUJsA00fRoKUM4QY= 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=ZSytv7mmOBckRgDswMhfOdu4AFNvvqT142NjUxtNGsw=; b=d+i0XSDrcfvgeFLKxhIDwd5qxf9dioM8YfSRfQ6NRAI+p+Gzsjt0Xl9RSg/WrWzIA+ cblt5msfP0/M7wLQK6mvRfAPoToBrTFecz6abmFhQYbulsr6iHWOx2v7TlLgQq3Shcja cZvYUfNmUfjAY8rPBEOXAA/A6y2m9edYekfUCyUb+o1N/mC+Pe9vNoe/HKRBX8nsiYB3 mHUchZL8qH4idU88Qitaxdu8cnd9OYXUcORR+5K8WFVzz8EEo4/0x5+HCyLJcgVglVoW nX031K9wGUpbWcfx7CkkDwQENH6g8KuUtQYm2djUT4mH1QyB+gF2j/aeMsYUEosVK/lt jsTw== X-Gm-Message-State: ALoCoQnsoFuYd1jNvo5HNPZIs2hVBR/qDhcXj7SNxkgAjDfMwy82dKY7F7zueQOV/KhD4E4BkoiH MIME-Version: 1.0 X-Received: by 10.180.95.10 with SMTP id dg10mr314187wib.41.1432235243481; Thu, 21 May 2015 12:07:23 -0700 (PDT) Received: by 10.28.214.206 with HTTP; Thu, 21 May 2015 12:07:23 -0700 (PDT) In-Reply-To: <201505211210.43060.davemgarrett@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> Date: Thu, 21 May 2015 21:07:23 +0200 Message-ID: From: Thijs van Dijk To: Dave Garrett Content-Type: multipart/alternative; boundary=f46d04447f83ec3f5d05169c4010 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 19:07:29 -0000 --f46d04447f83ec3f5d05169c4010 Content-Type: text/plain; charset=UTF-8 On 21 May 2015 at 18:10, Dave Garrett wrote: > Old versions of TLS need to be phased out at some point (even the one > we're designing now), however the current modus operandi is generally to > wait until a catastrophic breakage forces everyone into a panic disable. > I'd like to at least try to do better prior to the next time. I'd like to > propose giving servers & clients different expectations as a transitional > measure: > > 1) No general change to current TLS other than pointing to the UTA BCP > from time to time. > https://tools.ietf.org/html/rfc7525 > > 2) For TLS 1.3, add a blurb to the effect of: > "Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiate > TLS 1.0 or TLS 1.1 for any reason. > Client TLS implementations are RECOMMENDED to not support old TLS > versions, where possible." In an ideal world I'd be all for it, but in reality I think this would do more harm than good in the sense that it would postpone deployment of TLS1.3 rather than speed up the deprecation of 1.1 and 1.0. Case in point: as of last month, 15-20% of my employer's revenue still comes from clients using IE6-8. (Mostly law firms and government branches who don't care so much about security as they do about liability - if at all. And barring the n'th catastrophic breakage, TLS1.1 is not a liability yet.) My boss isn't going to forfeit that amount of cash simply because his IT guy says the BCP says he should. Nor should he! If it's an exclusive choice between either supporting 1.0 and 1.1 but not the newest 1.3, OR having 1.3 but having to make do without one-sixth of his revenue, this is a no-brainer. Users and site operators alike would benefit the most from a having-your-cake-and-eating-it-too scenario, where users with a modern browser can enjoy the newest security features, while the soft-touch deployment will make adopting the newer version more palatable for the managers of this world, even if it does mean the odd panicky removal every other month. -Thijs --f46d04447f83ec3f5d05169c4010 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 1 May 2015 at 18:10, Dave Garrett wrote:
Old versions of TLS need to be phased out at= some point (even the one we're designing now), however the current mod= us operandi is generally to wait until a catastrophic breakage forces every= one into a panic disable. I'd like to at least try to do better prior t= o the next time. I'd like to propose giving servers & clients diffe= rent expectations as a transitional measure:

1) No general change to current TLS other= than pointing to the UTA BCP from time to time.
https://tools.ietf.org= /html/rfc7525

2)= For TLS 1.3, add a blurb to the effect of:
"Server= TLS implementations supporting TLS 1.3 or later MUST NOT negotiate TLS 1.0= or TLS 1.1 for any reason.
Client TLS implementations a= re RECOMMENDED to not support old TLS versions, where possible."

In an ideal world I'd be all for it, = but in reality I think this would do more harm than good in the sense that = it would postpone deployment of TLS1.3 rather than speed up the deprecation= of 1.1 and 1.0.

Case in point: as of last month, = 15-20% of my employer's revenue still comes from clients using IE6-8. (= Mostly law firms and government branches who don't care so much about s= ecurity as they do about liability=C2=A0- if at all. And barring the n'= th catastrophic breakage, TLS1.1 is not a liability=C2=A0yet.)
My= boss isn't going to forfeit that amount of cash simply because his IT = guy says the BCP says he should. Nor should he! If it's an exclusive ch= oice between either supporting 1.0 and 1.1 but not the newest 1.3, OR havin= g 1.3 but having to make do without one-sixth of his revenue, this is a no-= brainer.

Users and site operators alike would bene= fit the most from a having-your-cake-and-eating-it-too scenario, where user= s with a modern browser can enjoy the newest security features, while the s= oft-touch deployment will make adopting the newer version more palatable fo= r the managers of this world, even if it does mean the odd panicky removal = every other month.

-Thijs
--f46d04447f83ec3f5d05169c4010-- From nobody Thu May 21 12:23:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87B81A8912 for ; Thu, 21 May 2015 12:22:58 -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 Q_kNL6GBADQc for ; Thu, 21 May 2015 12:22:57 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6D41A8903 for ; Thu, 21 May 2015 12:22:57 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so18360575igb.1 for ; Thu, 21 May 2015 12:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=dB+dxpnxzJfzsUHhygWOt7nOH2Bp39uE7jLSaEPnz0o=; b=M2WSvmu4Ox3wTR7pV0Jr5K2C/rNKHYJ+4oD2sQ2+JMHosC0btI2oNeh+YtIF+srXAZ f2LWCk04iPlCEjei3mLFw2DkROVHQ2BsNHg0aJ1uOBKvh6m2y3jQReyM+ELg9o4+9qdm INr+Kke6NQ89l9J/i2iGE1VSAAU8Vqc11d7ALgMDKSpqZddaXn2X6JKwVzJzcNCFutFv QhZFcK4l4XKSjKqF9OjirFeYPSHINBhMtGGDTEp0Uarq61DeR1QR3V7/QCgD4YLH4XOL R4D7Up9KCOS387dBHL1dWo/fkYuUaTy6rdzH2E1Rx+/d0QhphLvsvehZ4WWbV8F7ke2Z qa/Q== MIME-Version: 1.0 X-Received: by 10.107.40.144 with SMTP id o138mr5602314ioo.66.1432236176689; Thu, 21 May 2015 12:22:56 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Thu, 21 May 2015 12:22:56 -0700 (PDT) In-Reply-To: <201505211210.43060.davemgarrett@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> Date: Thu, 21 May 2015 15:22:56 -0400 Message-ID: From: Jeffrey Walton To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 19:22:58 -0000 On Thu, May 21, 2015 at 12:10 PM, Dave Garrett wro= te: > I was going to hold off on suggesting this due to other topics dominating= the list, but we might be in a kill-the-old-junk mood due to the latest ol= d-junk vulnerability, so... > > Old versions of TLS need to be phased out at some point (even the one we'= re designing now), however the current modus operandi is generally to wait = until a catastrophic breakage forces everyone into a panic disable. I'd lik= e to at least try to do better prior to the next time. I'd like to propose = giving servers & clients different expectations as a transitional measure: > > 1) No general change to current TLS other than pointing to the UTA BCP fr= om time to time. > https://tools.ietf.org/html/rfc7525 > > 2) For TLS 1.3, add a blurb to the effect of: > "Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiat= e TLS 1.0 or TLS 1.1 for any reason. > Client TLS implementations are RECOMMENDED to not support old TLS version= s, where possible." > Now might be a good time to add a (3) for TLS 1.3: have a client specify both the least TLS version they are willing to use, and the greatest TLS they desire to use. And MAC or derive from it it so it can't be tampered or downgraded. You can still provide the the TLS record layer version, and you can keep it un-MAC'd so it can be tampered with to cause a disclosure or crash :) Effectively, that's how the versions in the record layer and client protocol are being used. It stops those silly dances the browsers and other user agents perform without the need for TLS Fallback SCSV. Jeff From nobody Thu May 21 12:55:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B8B1A8993 for ; Thu, 21 May 2015 12:55:15 -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 HZA1dMvQCkR7 for ; Thu, 21 May 2015 12:55:13 -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 8451D1A88D2 for ; Thu, 21 May 2015 12:55:13 -0700 (PDT) Received: by qkgv12 with SMTP id v12so64793489qkg.0 for ; Thu, 21 May 2015 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=6neTbUpVGs/sQ5h/Z1chnvESgOOt5O+rraIFBNcTQ1E=; b=PM2naoqH/Rfeq36QCdlgvxoL7TQReLtyDRowO+d+p8BdLKsXEfX9M8TIMrdxU6vk4w urIZobgaAkjm4k48ujg8ixcSZQLQJXGXE7HrWijgHaAnneQ6zv/YTj3TKE5BloD7E6yx qdj2SpN6yrsihcxgMUWkYQ3O/mCEnpP3ZxT2x2Bg7m2ewk2d8u6AdtAyM07br8OkwDrJ YZcP2RpbrLcgXKwilCzK15ue+dyPk7YGoTBnY8L6nIBSzrObmxSlkXdSyr/yzPn2/kuJ Hpgdx6byG0Sz+oh8WtfmHg8QjABGZHM+egljhAvTXUcZWNbNfldbHD0sDDx/GCtPxw2r /4HQ== X-Received: by 10.140.233.14 with SMTP id e14mr4636268qhc.90.1432238112854; Thu, 21 May 2015 12:55:12 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id o106sm13890963qgd.23.2015.05.21.12.55.12 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 12:55:12 -0700 (PDT) From: Dave Garrett To: noloader@gmail.com Date: Thu, 21 May 2015 15:55:11 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505211555.11542.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 19:55:15 -0000 On Thursday, May 21, 2015 03:22:56 pm Jeffrey Walton wrote: > Now might be a good time to add a (3) for TLS 1.3: have a client > specify both the least TLS version they are willing to use, and the > greatest TLS they desire to use. The new version negotiation proposal I was working on has that capability. https://github.com/tlswg/tls13-spec/compare/master...davegarrett:EVN The similar system I proposed before that was exactly (3), but this one just does a simple list. I greatly prefer the list based approach because it's a total replacement and mistake resistant. (this was discussed quite a bit a while ago on list) If people keep screwing up the old system, tweaking it a bit doesn't seem like enough to deal with the problem, and this new route has other benefits. (there's no reason why TLS 1.2 servers couldn't use it too, if desired) Ditching TLS 1.0/1.1 support from the list-based approach would be fine and simplify things slightly (I could drop one paragraph), but it doesn't address the fact that servers will still have the code loitering around for a downgrade attack of some unknown kind. The fact that technically clients didn't support EXPORT ciphers did not stop the FREAK attack. TLS implementations have a fairly sloppy track record in this area, as of late. I don't want negotiations to avoid old junk, or signaling suites to check for junk, or config options, or build options. The obsolete code needs to be stripped from the codebase. Nuke it from orbit. It's the only way to be sure. Dave From nobody Thu May 21 13:45:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5EB1A8AC2 for ; Thu, 21 May 2015 13:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WURZkV8G_10q for ; Thu, 21 May 2015 13:45:07 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id E05FB1A8AA4 for ; Thu, 21 May 2015 13:45:06 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 21 May 2015 16:45:05 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0210.002; Thu, 21 May 2015 16:45:04 -0400 From: Dan Brown To: "'watsonbladd@gmail.com'" Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYrGMmex37dc0iNG+rWIQqT5p2FORUAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX8AgAAC8wCAAAMhAIAAAqYAgAAylYD//8puMIAAaUsA///RelA= Date: Thu, 21 May 2015 20:45:04 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5DDF130@XMB116CNC.rim.net> References: <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002E_01D093E5.7D3232A0" MIME-Version: 1.0 Archived-At: Cc: "'fweimer@redhat.com'" , "'tls@ietf.org'" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 20:45:09 -0000 ------=_NextPart_000_002E_01D093E5.7D3232A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Watson Ladd [mailto:watsonbladd@gmail.com] > > On Thu, May 21, 2015 at 12:51 PM, Dan Brown > wrote: > > In the Imperfect Forward Secrecy paper, Section 5 Recommendations, the > > medium term recommendation to avoid fixed-prime DHE groups seems to > > conflict with the current direction TLS is taking towards named only > > groups. > > Is that *really* what the recommendation says? It's true that using the same > group repeatedly enables an attacker who does an L(1/3) calculation to > quickly > compute all discrete logarithms together. But instead of making > countermeasures to this, it's far easier to ensure that the price this > precomputation is large, by using larger groups. [DB] That's how I read their medium term recommendation. I agree with them, and you, that larger groups should be the first defense (they call it short term). I guess that by "medium term", they mean to apply it in addition to the short term, perhaps at a later date. I think such countermeasures should be optional. It probably does make sense to postpone this discussion, with other priorities taking precedence. This paper seems to demonstrate that this well-known fact of pre-computation, which perhaps should have been anticipated, could potentially have real-world consequences. Past deployments of 1024-bit DH (and smaller) seem not to have anticipated this risk adequately. So, it does illustrate this issue here well. > > > > > Choosing a larger key size is the most efficient and simple remedy > > against these pre-computations. > > Exactly. No need to proceed further. [DB] The imperfect forward secrecy paper cites Semaev's example of DHE groups with easier-than-average discrete logs as a reason to not rely entirely fixed-prime groups. The current I-D FFDHE uses e to provide a nothing-up-my-sleeve NUMS property, so it seems like a concern that has been considered already. It seems to me almost certain that the current I-D does indeed achieve NUMS property, much like the Brainpool curves do for ECC. So, this particular risk seems minute, but it can be hard to shake off suspicions. > > > > > Allowing custom groups provides a second defense against the such > > pre-computation, but supporting custom groups creates other problems. > > Peers need to verify the custom groups, and the groups need to be > > generated. The computation and communication spent on verifying > > custom groups could perhaps be better spent on using larger fixed groups. > > You've just explained why I'm against it, better than I could. So what > actually is > the reason you support it? > [DB] Well, as I said it's only a second line of defense. I would only support it as an option for those who can afford the extra cost: the reasons to use this are not enough to mandate this countermeasure. Here's an unlikely situation in which it may help thwart mass surveillance (rather than help a targeted individual or session). The trend in factoring and FFDLP algorithms is that new algorithms are only faster than old algorithms above some key size. In other words, a plot of the new FFDLP algorithm's runtime against keysize rises sharply then flattens out, eventually undercutting the older algorithms. If this trend continues, then a future (or secret) attack may be flatter than the current best known FFDLP algorithms, in which case the gain from larger keysize is not as much as expected by looking at the published FFDLP algorithms. (Of course, the best countermeasure to this small risk would be ECDHE!) If all goes well, this flatter attack will never (has never) happen(ed). But if it does happen, and everybody used the same larger group, their extra effort may not have helped a non-targeted user as much as if everybody used smaller different groups. The risk mitigations provided by increased group size versus diversification of groups are rather different in quality, and are thus hard to compare. But for users more interested in avoiding mass-surveillance rather than targeted attacks, might prefer to spend their spare computational power accordingly. > > > > My preference is to recommend larger, vetted, fixed groups (e.g. at > > least 2048-bit DH and 256-ish-bit ECDHE) just as TLS and CFRG are > > currently doing, but to still keep custom groups (of similar size) as > > an option, perhaps to be added later after some further discussion > > about the best way to specify custom groups. > > Why do custom groups help? We've seen how they can hurt, by complicating > implementations, making possible cross-protocol attacks, and other kinds of > nastiness. [DB] Yes, custom groups have led to attacks, but that seems to be more due to some fumbles about ambiguously encoding them. I hope that once the dust settles a bit, and TLS puts more effort into *DHE, instead of RSA key exchange, such ambiguity can be resolved. In other words, any proposal for custom groups should be done quite carefully. > You're asking that we adopt them so that an attacker who does a > massive calculation gets only one useful result, instead of having to repeat > a > calculation they already did a few times. How many months of extra time does > this get us? > [DB] Everybody sharing a group creates a large incentive and single target for an attacker. If the computational power of the attacker tops out at some value (i.e. at some max bit-op per dollar), and we've chosen a group size just below this top power attack, then the difference is whether that attacker can compromise a small targeted set of users of one group, versus a mass-surveilance of nearly all users. To make it concrete, for a group whose size tops out the attack at two months, then it buys a non-targeted (mass-surveiled) user a number of months equal to the number of groups that have been used. Again, I emphasize, that this would only be a second line of defense: the first line is choosing the right size of group. ------=_NextPart_000_002E_01D093E5.7D3232A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICClvwCZYABAA8faIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTE1MDQxMDIxMjgwNFoXDTE2MDQwMjAxMTEwNVowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAnqyPpiXJ8uIKCHaqpEmU2q/9KYQJi6yizaJruUGAoUstFzjV7XymMDqnaZqLR/QQoR3Qojm2 pjb3luP0P+37tro+PlKEgODyauhfaT78GLlJHq3GZxI6N27UHyYHWGFglAh6uCaHcGBitBZCyEFr n+FDG5cYb89jhPuiZWu48ocCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFHxbvAxpbwEMJEmG6lwbqKCLBREQMB8GA1Ud IwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAJmZR wd1UREUFudy4RWbVn/3YgfoH3WC5GElyoNzatY6Cm8B+1NLUeHwH2NMtoekwC2H+l+xH3Dt2mAuE n7kpR8rou2aafkauVYZpkD5DsZd8etdx/3dZ/sA66Urieyd2O4KdIhBLvk1jp8TklI5ktJ0pb8In tTNXjhN/T0yACoymL8YUbMZ130B1ksYe+OuU/KvHcQepQLxTuTNcGhToCP/HXpOiNuUkyLo6YahX gKcCJk/myNi3GY4FbqMTJvuOSf645cbY2Q+3esguzO1MBSVwYv5Qh/aIY+JJHUHab10IM7tAtFbO w0E695QEBEaSMQ7VY7oX3UNBpoDqpyHZTDCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJ3m4YAAAAAAiwwDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDEwMTA1WhcNMTYwNDAyMDExMTA1WjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDH8YxcxLmGv6nenV7uByC7QXR9/gYMM97kGpA3 Mb63938lUAcuvShTkvP4eURHum4rd7aecLEEL/5xVZplyv46vcw+9s5d47+t1M2YDlgvdPOOlMU0 5pjRMh86NTOeAdy65xOi9kOkGxGTAJ6yferlfKTdl2bJ+Y/jL3yOWoxbvuqD2x3mM0I2Qdxg47u7 BC5u3AHK9GGF98Xi0wdqy1FGRejcsnNG7Q+ewEWBGvfQPuibJTvFXMbZYEXXcdezQeoLbTY8JiRU 95d1FXCuTuflFUlqVtc0G2UAb5dIj+4F3KyVuA79KdN+oh4PZYA1dakAoYvTQoscJu8mLQhy6vWp AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBS4MBdub2eV/oWMaDul4Rez P/glOjALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFMOXm3j5 YZ17uL9jpaOoQQnTuW3kMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQAfapyc7N66k5yLTjRPqBC6kIbHPPxDLVP6 +td2LQh2gUBskJO2xbscb3Se5kIo6TYON4jdWBmkCQ4PEoFLOMUE511QKfulKIRVX0QzU0ELEhKL SeyIByM47XV5aOEwy9bfZ3H8fV5/WkDBV5Tx3wuCNPGV+a2H4ujQxKCFTp6i9aBBxyHKI9jkaJtD vjO9np84HzarnURNJfR1jRiXDk2Asw0lZuX/Ur9+uGfp0NfoU91MINRCMhg7gPKWLXUY1oLoh1CB r/UD99FVnzCmV5dCjUy0Ie0+tHgxYRUnq49r8FnA0dy4v8RNXjiYelKbAYgq2vAg+OtT5FNoEhD1 vk4uKwjzXoKtpxlfuDQ9KYOTXORwKlGw2zL5vHJUgfCKJj5Js9jUf8aPeDIQN5fXuyAzLutrpYBG dPr5/mwR+mxeU8Bk66E0rlu0bNd2bK0s9bL2h6cosA+VTBUfK3Dp8GomyWWfzEXxG3I1C4PK9Qkt YLJHUqN/YrqnDIia8xVl7/vDscLOwByBtfaf0yuQS7SYZ//Emhd7eEFzKhvAIPMYzqlEG65tv6d9 ng8LrTZ/Vvrl3pHZiO50OQ5KP20qC3ZBszs2Y8cFgA9hO8R9zi44qnumXkoy4lxw8JlZfo9A3Vul xXR5cLkNdL/wnGkZxekwzX+jrAdaCpYoACKnJP3MqDGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAzWUtGAgpb8AmWAAQAPH2iMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUyMTIwNDUwNVowIwYJKoZIhvcNAQkEMRYEFIPb 83kt2H+CVHu5J2wAmDKT8d4LMG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGAgpb8AmWAAQAPH2iMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZ S0YCClvwCZYABAA8faIwgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYBoc/NBbnNz0ujMztJgU/rpetE9EpF4 niXsMz1HgwVj7fqKpGg6BxzNMWZaSneZEDJdUDIlNv4xoTpcjC/SG8QcT1za/bC8l+4rxVDbaIi9 NTVUKHHCJAECHT72LGNVz0kGT9rCMP3blR2GUobw788S3Q4Hrv/2mZxmlhLF4bNpwwAAAAAAAA== ------=_NextPart_000_002E_01D093E5.7D3232A0-- From nobody Thu May 21 14:03:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201961A9031 for ; Thu, 21 May 2015 14:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 e7uOzihP4vSj for ; Thu, 21 May 2015 14:03:20 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 516721A8ADA for ; Thu, 21 May 2015 14:03:20 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 1E4745AA002; Thu, 21 May 2015 23:03:18 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id ECF7D1FE014F; Thu, 21 May 2015 23:03:17 +0200 (CEST) Date: Thu, 21 May 2015 23:03:17 +0200 From: Kurt Roeckx To: Dave Garrett Message-ID: <20150521210317.GA23925@roeckx.be> References: <201505211210.43060.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201505211210.43060.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:03:22 -0000 On Thu, May 21, 2015 at 12:10:42PM -0400, Dave Garrett wrote: > > The reasoning here is that major server updates are unfortunately uncommon, but client updates are routine. So everybody can already disable TLS 1.0 and 1.1 now, right? All clients have already been updated. Kurt From nobody Thu May 21 14:13:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0661A905A for ; Thu, 21 May 2015 14:12:59 -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 2tBLgRqZ9G6v for ; Thu, 21 May 2015 14:12:58 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 F31C31A904F for ; Thu, 21 May 2015 14:12:57 -0700 (PDT) Received: by qkx62 with SMTP id 62so19518465qkx.3 for ; Thu, 21 May 2015 14:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=DTMdqT/ysb+eaVgjLI4mgxipz9NW5YCrR7EK4rfDaNk=; b=Q4OBe4o15x5Jy/gYbndOn9c6QF6HfsmCP5JNsDkwDLveLHgYVPHx/883j1YvIGEYY/ hpoR0sgcMR+bSBI8cAwVGOtAj2TF1MuTtyiez8nym9oOo8ZA1+DqK8AS8AOwfwYcet59 ERR1/uLfsFk06jDBtFc4fnKjk1WeqlHlHSOdQfXbdB/w8lR4kqWTMfISICsH4sHElXiO OxKBTinbQAGig0dChiuWcfmkEcYB2Z5v2p5Ea30dd7DdbgX1pLelIKe1qgzG6Sw2XIlA aJ8mZOTgTRQat59VFYqiKLkMdArxadhgveXrwZVKQfXpSfHrr6Ag0s6nKYV27/OWHOFI qc6A== X-Received: by 10.55.20.141 with SMTP id 13mr11142920qku.30.1432242777298; Thu, 21 May 2015 14:12:57 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 6sm20698qks.37.2015.05.21.14.12.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 14:12:56 -0700 (PDT) From: Dave Garrett To: Kurt Roeckx Date: Thu, 21 May 2015 17:12:54 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> <20150521210317.GA23925@roeckx.be> In-Reply-To: <20150521210317.GA23925@roeckx.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505211712.55279.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:12:59 -0000 On Thursday, May 21, 2015 05:03:17 pm Kurt Roeckx wrote: > On Thu, May 21, 2015 at 12:10:42PM -0400, Dave Garrett wrote: > > The reasoning here is that major server updates are unfortunately uncommon, but client updates are routine. > > So everybody can already disable TLS 1.0 and 1.1 now, right? All > clients have already been updated. More than enough, as far as I'm concerned. Once servers start rejecting the stragglers on EOL clients, people will be forced to update. This coercion does not work well in the other direction. Many server operators don't even care, or possibly even know anything about the topic. They do know that major upgrades of servers are a big deal, and something that does not get done frequently. Client upgrades, on the other hand, are easier to install and it's easier to switch to competitors if needed. Dave From nobody Thu May 21 14:30:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F326E1ACE70 for ; Thu, 21 May 2015 14:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7Rmv13b0xk8 for ; Thu, 21 May 2015 14:30:54 -0700 (PDT) Received: from BLU004-OMC3S23.hotmail.com (blu004-omc3s23.hotmail.com [65.55.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3103E1ACDE8 for ; Thu, 21 May 2015 14:30:53 -0700 (PDT) Received: from BLU177-W4 ([65.55.116.73]) by BLU004-OMC3S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 21 May 2015 14:30:52 -0700 X-TMN: [XEu/yNkdAlu8CrMYrNZ2MwSKWEd6Y5Bc] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Thijs van Dijk , Dave Garrett , "andrei.popov@microsoft.com" , "maray@microsoft.com" Date: Thu, 21 May 2015 14:30:52 -0700 Importance: Normal In-Reply-To: References: <201505211210.43060.davemgarrett@gmail.com>, Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 May 2015 21:30:52.0943 (UTC) FILETIME=[6A1BB1F0:01D0940D] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:30:56 -0000 > On 21 May 2015 at 18:10=2C Dave Garrett wrote: =0A= > Old versions of TLS need to be phased out at some point (even the one =0A= > we're designing now)=2C however the current modus operandi is generally = =0A= > to wait until a catastrophic breakage forces everyone into a panic =0A= > disable. I'd like to at least try to do better prior to the next time. = =0A= > I'd like to propose giving servers & clients different expectations as = =0A= > a transitional measure: =0A= > =0A= > 1) No general change to current TLS other than pointing to the UTA BCP = =0A= > from time to time. =0A= > https://tools.ietf.org/html/rfc7525 =0A= > =0A= > 2) For TLS 1.3=2C add a blurb to the effect of: =0A= > "Server TLS implementations supporting TLS 1.3 or later MUST NOT =0A= > negotiate TLS 1.0 or TLS 1.1 for any reason. =0A= > Client TLS implementations are RECOMMENDED to not support old TLS =0A= > versions=2C where possible." =0A= > =0A= > In an ideal world I'd be all for it=2C but in reality I think this would = =0A= > do more harm than good in the sense that it would postpone deployment =0A= > of TLS1.3 rather than speed up the deprecation of 1.1 and 1.0. =0A= > =0A= > Case in point: as of last month=2C 15-20% of my employer's revenue still = =0A= > comes from clients using IE6-8. (Mostly law firms and government =0A= > branches who don't care so much about security as they do about =0A= > liability - if at all. And barring the n'th catastrophic breakage=2C =0A= > TLS1.1 is not a liability yet.) =0A= > My boss isn't going to forfeit that amount of cash simply because his =0A= > IT guy says the BCP says he should. Nor should he! If it's an exclusive = =0A= > choice between either supporting 1.0 and 1.1 but not the newest 1.3=2C OR= =0A= > having 1.3 but having to make do without one-sixth of his revenue=2C this= =0A= > is a no-brainer. =0A= > =0A= > Users and site operators alike would benefit the most from a =0A= > having-your-cake-and-eating-it-too scenario=2C where users with a modern = =0A= > browser can enjoy the newest security features=2C while the soft-touch = =0A= > deployment will make adopting the newer version more palatable for the = =0A= > managers of this world=2C even if it does mean the odd panicky removal = =0A= > every other month. =0A= > =0A= > -Thijs =0A= =0A= Andrei Popov: I think it would be trivial to release an update for IE8-10 f= or Win7 to enable TLS 1.1 and 1.2 by default=2C right? = From nobody Thu May 21 14:34:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56731AD248 for ; Thu, 21 May 2015 14:34:11 -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 XKGRSXCsZ42N for ; Thu, 21 May 2015 14:34:10 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id ACD6E1A905A for ; Thu, 21 May 2015 14:33:35 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 3EDEDF984 for ; Thu, 21 May 2015 17:33:33 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B52682003D; Thu, 21 May 2015 17:33:20 -0400 (EDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.20~rc1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 21 May 2015 17:33:19 -0400 Message-ID: <87ioblr4yo.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:34:12 -0000 --=-=-= Content-Type: text/plain On Wed 2015-05-20 11:47:55 -0400, Joseph Salowey wrote: > This is the WG call for adoption of: > > https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt I'm in favor of TLS WG adoption of this draft. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJVXk8gXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcUMoP/AoIjcWHyccgi6Hx2lghddfP UotvRf3KurnIYCU/Hx7gs9qmNYgOfS6nZcp5+lsImjUUqyd0fD50v02KvhRS/JFR J+ztgL6ETAysq8BcyVlFFAI0/j89bKylnIUbT7QtexCUblgUcXOh8fsXZ35uMPNW To/0f/5tL2zChRuffu/3wHDKsg78D2XoZgrnYVrkeMvezhoMW38B+ujx4W9m+tRc SVLeIDZ+EbwUJnrIh8xzM92q7jrF/yjh+3MTTpKe18CivjDXloM6uJhtuEHLhzJC idz0TKBtn0WZO5CQvtS+kb4rf8ew9VMvSDvrwYHJ8IKzu19sDJGQnILdYcVOUnSE uN7wyqzhq7eT8Paj1CTorOvytn54eVfA8go90CEMA9Y9+Vzy4Ln5PBQf82hA09UO X6lDjggowKx/dCQHUasuWdBbNj2QuCWcuO32uRYK62ZJUztWWP5nY5hWsnw9J6Ni pM8GMeCv+fw9mD3ZNlEOoPI4OyBVP6EXQyc8KlASCAz5XQCbuU7DknGSQ/MU862v Ks+w+trtk7OT05i86yqMzCot9k9cNdKEsN+MKY25s3dItAjhqkIQeYhb4WB7b3YO GFojULzYgobG3Kx7zuddI11S9MGBwlNF3XAc31D0bAnQJ3uNlk0u8fIPaLxFmHr/ SzpIKXoSdDVpD5yqv7Q6 =2qYs -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 21 14:50:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D921A90CE for ; Thu, 21 May 2015 14:50:33 -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 I11s_DpNW_X2 for ; Thu, 21 May 2015 14:50:31 -0700 (PDT) Received: from mail-wi0-x243.google.com (mail-wi0-x243.google.com [IPv6:2a00:1450:400c:c05::243]) (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 647BC1A908C for ; Thu, 21 May 2015 14:50:31 -0700 (PDT) Received: by wibbw19 with SMTP id bw19so3075764wib.2 for ; Thu, 21 May 2015 14:50:30 -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=tr9vIJ1sMFTPDO+C/322yrlT/MliulFl9y4gmii6meI=; b=0TDw5qnCTVTnKpAatua2gvPl5FrVdGjPDwleixaCHjc2fP2lzC01nY6mzHqDZpEQRz K9kREwlFlIiEUg57IRpoTKqENVoZ+qrKIwx84/bmEBatrzo/TXAw61783X6VvvX65Fag 1s12x5LBzEdg8GK+1a4BidFlzXb1nFKSxlIl1O5HKgHHd6RT6EVjOZFdXej7HVeLBe9O iMu3ViFYsIMF0TNZYCaYcyZ69Ce1qwnX4wQ+i9nB3Q4HWURViaT3AtGEn6fs7Z1wfRYE qhiejQtqjpVTIj4po7OO0yPSjKiF7DXuGUAiLmimVd3lTtl9kzn0kxzEPIif3BNLLhzE M8Sg== X-Received: by 10.194.57.11 with SMTP id e11mr8561724wjq.19.1432245030213; Thu, 21 May 2015 14:50:30 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id ex2sm166006wjd.28.2015.05.21.14.50.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 14:50:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Fri, 22 May 2015 00:50:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <08521CEE-F00B-40B5-9A91-D290ED56EE67@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> To: Yuhong Bao X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "maray@microsoft.com" , "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:50:33 -0000 > On May 22, 2015, at 12:30 AM, Yuhong Bao = wrote: >>=20 > Andrei Popov: I think it would be trivial to release an update for = IE8-10 for Win7 to enable TLS 1.1 and 1.2 by default, right?=20 Trivial or not, whether Microsoft does this is not our decision. = Probably not even Andrei=E2=80=99s decision. And these are not the 90s. = People keep using computers for 5, even seven years.=20 According to netmarketshare.com Windows XP is still 16% of = desktops/laptops (as measured by web traffic). Add some older mac OS X = versions and you reach 17%. Even mobile has some older versions. What = this is proposing is to require servers to cut all of those off as a = pre-requisite to supporting TLS 1.3. Yoav= From nobody Thu May 21 14:55:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528F31A8AA4 for ; Thu, 21 May 2015 14:55:01 -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 oBN7ncRaAEer for ; Thu, 21 May 2015 14:54:59 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001: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 805671A89A7 for ; Thu, 21 May 2015 14:54:59 -0700 (PDT) Received: by iepj10 with SMTP id j10so18587166iep.3 for ; Thu, 21 May 2015 14:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gE07isbtZ36tkQYI90YBo4nRKOkQg+DIa4sSx0KalPw=; b=b8a9YYAuLJWHMqX2tmSaQWDELnCtt026GJ3jJOSobNK/SywV7NiBk02JbwsSJ3MaVP 0vGsQA00Ih9FxMIqLdgAfbR0KZ6GbgPrWUhi+73uPwtkbS4J+UDJwb+SjhXucx8cRPtJ HRgvmYq6PK1VRIB18fxR71QRyaXPNtugU0y797SXutt9b5r33IvAde9yNmDQ0f1A4ov4 QcGMOFdFKZKVuPom6CdAFu2uasCD0/cf5xHJNj0HW8DqXT8abzs0btFHyQfU92A0VIOA ltyMnuahvLiQn6NF1Jnm7jRNPCu3dDHOMjEX7LCxh9jSDrXabdLOIZ8Uo1Aqa0MlQFV2 2Qiw== MIME-Version: 1.0 X-Received: by 10.50.78.100 with SMTP id a4mr1188590igx.34.1432245299009; Thu, 21 May 2015 14:54:59 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Thu, 21 May 2015 14:54:58 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5DDF130@XMB116CNC.rim.net> References: <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5DDF130@XMB116CNC.rim.net> Date: Thu, 21 May 2015 17:54:58 -0400 Message-ID: From: Jeffrey Walton To: Dan Brown Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:55:01 -0000 On Thu, May 21, 2015 at 4:45 PM, Dan Brown wrote: >> -----Original Message----- >> From: Watson Ladd [mailto:watsonbladd@gmail.com] >> >> On Thu, May 21, 2015 at 12:51 PM, Dan Brown >> wrote: >> > In the Imperfect Forward Secrecy paper, Section 5 Recommendations, the >> > medium term recommendation to avoid fixed-prime DHE groups seems to >> > conflict with the current direction TLS is taking towards named only >> > groups. >> >> Is that *really* what the recommendation says? It's true that using the same >> group repeatedly enables an attacker who does an L(1/3) calculation to >> quickly >> compute all discrete logarithms together. But instead of making >> countermeasures to this, it's far easier to ensure that the price this >> precomputation is large, by using larger groups. > > [DB] That's how I read their medium term recommendation. I agree with them, > and you, that larger groups should be the first defense (they call it short > term). I guess that by "medium term", they mean to apply it in addition to > the short term, perhaps at a later date. I think such countermeasures should > be optional. I think the authors felt the same. But in Section 4 of the paper, they said: In this section we address the following question: how secure is Diffie-Hellman in broader practice, as used in other protocols that do not suffer from downgrade, and when applied with stronger groups? To answer this question we must first examine how the number field sieve for discrete log scales to 768- and 1024-bit... Unfortunately, our measurements also indicate that it may be very difficult to sunset the use of fixed 1024-bit Diffie- Hellman groups that have long been embedded in standards and implementations. I think they are politely saying standard groups should do away with anything at 1024-bits or below. From nobody Thu May 21 15:07:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1A01A90A5 for ; Thu, 21 May 2015 15:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 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_NONE=-0.0001] 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 jDon7w2MyqVi for ; Thu, 21 May 2015 15:06:59 -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 BDF551A0056 for ; Thu, 21 May 2015 15:06:59 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id CC3022005E61B; Thu, 21 May 2015 15:06:58 -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=Tylz1c/uL2WRrq Npo9WJPV73sIc=; b=iAfVBC3Ek0TQ6P0mqBULHNFcsyIFm83hf0dUEd9fxjP6wq jNVsg5krg+zm6SNloii6lT4Ci3fDoPtJfl2oBy4vdT+i4i6VzwwFcXaW1hBXI2W4 VrmsynthQtPHWD0WNFsxOdb0l0ZVvks93w19sTt3iHcG/3JDEsxue6eGTmq44= 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 483612005E619; Thu, 21 May 2015 15:06:58 -0700 (PDT) Date: Thu, 21 May 2015 17:06:57 -0500 From: Nico Williams To: Jeffrey Walton Message-ID: <20150521220656.GC3791@localhost> References: <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5DDF130@XMB116CNC.rim.net> 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: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:07:01 -0000 On Thu, May 21, 2015 at 05:54:58PM -0400, Jeffrey Walton wrote: > I think they are politely saying standard groups should do away with > anything at 1024-bits or below. I think that's right. ECC here, so we should respond by moving to ECC. From nobody Thu May 21 15:21:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26EE1A90DC for ; Thu, 21 May 2015 15:21: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 JgpFnbh7olLj for ; Thu, 21 May 2015 15:21:34 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211211A90CE for ; Thu, 21 May 2015 15:21:34 -0700 (PDT) Received: by qgez61 with SMTP id z61so675309qge.1 for ; Thu, 21 May 2015 15:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=0pcj7kkOeBpPuPcavizuFphGPnDYXRpbSGKIMesuGJY=; b=KzlQz9w4lQgVV1+OBkVF3SHl8O2tLsIYJOWREMk994IG7e9yiUuAEx5VFlg8IA/Mqg 35k2fP5NpY+ooJ8csec47qAs/nhIq0ObfZG7IzvF4bzCCJa7EkzDy1eVoSjxlybv4J0R Jc0pB0bVJ4iZnH0RNiwxhTAM8cIbjW1rUQV30ppams+iZsm0+msJRFSH+8rwlX8aI2jz hJSmiFrK0sZ/cGZ8yNpKM0qSL4qHdqAHpvA9SOUmZv2cXG0Lw+xor0MwaoI4uXRWKISn S0Hf159tOcnR0B6JcBcJx5yTffpXROLzwEqa+OHiG+aarmtBMjvFlkiOQ/r/ZR8QFMmv KMcA== X-Received: by 10.140.100.164 with SMTP id s33mr6961098qge.36.1432246893389; Thu, 21 May 2015 15:21:33 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id q74sm151979qha.4.2015.05.21.15.21.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 15:21:32 -0700 (PDT) From: Dave Garrett To: Yoav Nir Date: Thu, 21 May 2015 18:16:41 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> <08521CEE-F00B-40B5-9A91-D290ED56EE67@gmail.com> In-Reply-To: <08521CEE-F00B-40B5-9A91-D290ED56EE67@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505211816.42606.davemgarrett@gmail.com> Archived-At: Cc: "maray@microsoft.com" , "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:21:35 -0000 On Thursday, May 21, 2015 05:50:26 pm Yoav Nir wrote: > According to netmarketshare.com Windows XP is still 16% of desktops/laptops (as measured by web traffic). Add some older mac OS X versions and you reach 17%. Even mobile has some older versions. What this is proposing is to require servers to cut all of those off as a pre-requisite to supporting TLS 1.3. Windows XP & old Mac OS X users can install Mozilla Firefox or Google Chrome (or one of the browsers based on one). It's just the built in browser that won't work because the vendor dropped support. From nobody Thu May 21 15:34:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774411A0191 for ; Thu, 21 May 2015 15:34:14 -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 l2lDHOogZH18 for ; Thu, 21 May 2015 15:34:13 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03DF1A001D for ; Thu, 21 May 2015 15:34:12 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so29868908wic.0 for ; Thu, 21 May 2015 15:34:11 -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=3CZw/7Sg3emuV5N5A6wuloRBCpQW7EctA4cr1FVxyZ4=; b=dWeHXobn3SVvXoyKY69NFEHnIoDQraHZWW0gy9U/CBRVg5nCr9BWkbd27gua8t12CU 5c8YgJfP5AnMSqs1AAEDFZ2WvwGQWhnIgRYpLvld/8+QTCxyCcgxvYzX88obSh7BPRX0 LbdsY9Ab2lLrt3vrdSHLr8626LLUgycF7TUchaJYEgsd0I/uCjeD/DhwrAgnQ+zey0oB vJq9DIvr8y3VVFuMY5JYrSi5fxjhH/IB44UruGg41qJ8C+IR/ewAitW71V05po7EJkat Cr+yYLyMJpPIBDkj86NaToohtdFRrJ7ETg0+iCiMNkBprTrE1FyOMwG3ay1sLfNqFDo6 ke7A== X-Received: by 10.180.107.70 with SMTP id ha6mr1692331wib.20.1432247651691; Thu, 21 May 2015 15:34:11 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id g11sm300781wjr.25.2015.05.21.15.34.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 15:34:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <201505211816.42606.davemgarrett@gmail.com> Date: Fri, 22 May 2015 01:34:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9ED694CA-2271-42DD-B094-55B560B9C76B@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> <08521CEE-F00B-40B5-9A91-D290ED56EE67@gmail.com> <201505211816.42606.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "maray@microsoft.com" , "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:34:14 -0000 > On May 22, 2015, at 1:16 AM, Dave Garrett = wrote: >=20 > On Thursday, May 21, 2015 05:50:26 pm Yoav Nir wrote: >> According to netmarketshare.com Windows XP is still 16% of = desktops/laptops (as measured by web traffic). Add some older mac OS X = versions and you reach 17%. Even mobile has some older versions. What = this is proposing is to require servers to cut all of those off as a = pre-requisite to supporting TLS 1.3. >=20 > Windows XP & old Mac OS X users can install Mozilla Firefox or Google = Chrome (or one of the browsers based on one). It's just the built in = browser that won't work because the vendor dropped support. And you are proposing that we force them to do this? Worse, you are = proposing that we deputize all server operators in forcing them to = replace their browser? From nobody Thu May 21 15:41:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444E01A87B1 for ; Thu, 21 May 2015 15:41:51 -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 741HVELzxWi8 for ; Thu, 21 May 2015 15:41:49 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 748A41A0191 for ; Thu, 21 May 2015 15:41:49 -0700 (PDT) Received: by wgez8 with SMTP id z8so1545249wge.0 for ; Thu, 21 May 2015 15:41: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:content-transfer-encoding; bh=PTdhrTxYRi+E3aKevYRdDOPQb8ZnQCFXs9bzWhZO2ZM=; b=wQvjirWxfrKzqk5UXTqNN9e5CvKvGokSmjwAh5AV2U4B8up/XLLbKFgX63ruuIXpyl cx/qwbR+ZMSXfAHWyjRTPNRzxd4WhYdKByLgxSv0a9HOPR7Ih3yoNd6fr816U5/haTXy gDFxSsUDnH4g1Rgmkc8Ej/li/n5sbC2LQQgYujWNpqK8hN+R8Qu1vxNRifXe4ij0xhaw FdiW5lr0IC667TCttbs4Va5VgaoWHXpqAhckQEPYPF0wjhinDQmVtF4yYe7/wRINA6Gm I6h9wQf2x2+BpdLjpoAeQsEB26scVe7XAPiUwoHC/iNq8tmooGeC+N6l+BQ7MAZYbHKQ e7ig== MIME-Version: 1.0 X-Received: by 10.194.248.227 with SMTP id yp3mr9225951wjc.32.1432248108166; Thu, 21 May 2015 15:41:48 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Thu, 21 May 2015 15:41:48 -0700 (PDT) In-Reply-To: <9ED694CA-2271-42DD-B094-55B560B9C76B@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> <08521CEE-F00B-40B5-9A91-D290ED56EE67@gmail.com> <201505211816.42606.davemgarrett@gmail.com> <9ED694CA-2271-42DD-B094-55B560B9C76B@gmail.com> Date: Thu, 21 May 2015 18:41:48 -0400 Message-ID: From: Watson Ladd To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "maray@microsoft.com" , "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:41:51 -0000 On Thu, May 21, 2015 at 6:34 PM, Yoav Nir wrote: > >> On May 22, 2015, at 1:16 AM, Dave Garrett wrote= : >> >> On Thursday, May 21, 2015 05:50:26 pm Yoav Nir wrote: >>> According to netmarketshare.com Windows XP is still 16% of desktops/lap= tops (as measured by web traffic). Add some older mac OS X versions and you= reach 17%. Even mobile has some older versions. What this is proposing is = to require servers to cut all of those off as a pre-requisite to supporting= TLS 1.3. >> >> Windows XP & old Mac OS X users can install Mozilla Firefox or Google Ch= rome (or one of the browsers based on one). It's just the built in browser = that won't work because the vendor dropped support. > > And you are proposing that we force them to do this? Worse, you are propo= sing that we deputize all server operators in forcing them to replace their= browser? If not now, then when? > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu May 21 15:42:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B2F1A90F3 for ; Thu, 21 May 2015 15:42:58 -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 rQzDMbJrOyHb for ; Thu, 21 May 2015 15:42:56 -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 061491A8784 for ; Thu, 21 May 2015 15:42:56 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so30011324wic.0 for ; Thu, 21 May 2015 15:42:54 -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=ERePXHcfGJEJNpYNECIcI5U3aqv5QhPX/30ARIBdJDY=; b=DCYpxlXGR2d7pmKbFjVDdcHxIEy0vUE6mfhjIeDwkuj17AsxXPjZlENtJimOXnPVz6 QeyP12qvypZZ4oi05uu7XGuiDWgGH3sz6kIeT+qoZGl5yO1WfgTETLn5hNYi01OkwH4d 0VXIt4uhIhtgDrHsIX9V2aSalNqtGXIm+F2nWqJ+RfrUfchDUfvwZNaE8FeoeC3iHRC4 mLueahwBqttn/b1DPymXjnnz08ZcBqTcjd5btNy2i6V+/hmNLu8oCa7eEjatI0jm12Ji Pi9TgEuz6/xCGivVREKf9wfR5T2nhIXhxhv3LRL1zqQPEd7lm7WEO/sKkfmGPofGcn2S 1irw== MIME-Version: 1.0 X-Received: by 10.180.8.41 with SMTP id o9mr1645206wia.83.1432248174823; Thu, 21 May 2015 15:42:54 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Thu, 21 May 2015 15:42:54 -0700 (PDT) In-Reply-To: <20150521002223.27E1F1B317@ld9781.wdf.sap.corp> References: <20150521002223.27E1F1B317@ld9781.wdf.sap.corp> Date: Thu, 21 May 2015 18:42:54 -0400 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)) I wonder if anyone is reading the full subject line or does it just get truncated at some poi X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:42:58 -0000 On Wed, May 20, 2015 at 8:22 PM, Martin Rex wrote: > Andrei Popov wrote: >> >> This isn't about a specific TLS implementation. As Ryan explained >> (http://www.ietf.org/mail-archive/web/tls/current/msg16238.html), >> servers today have to deviate from the certificate_list ordering >> requirements for a variety of practical reasons. Clients can't take >> advantage of these requirements, because servers violate them. >> So if neither clients nor servers can in practice implement this >> RFC language, why don't we drop it? > > Not adhering to the requirements will cause *REAL* interoperability > problems in the installed base, because there are implementations > that will fail if TLS peers start sending junk. For 13 years, > our implementation was very strict and tolerated not even duplicates > nor incorrect order of path certificates What about junk following the chain, as needed in the case of updates to signature algorithms? > > Currently, the amount of TLS servers and TLS clients that are sending > junk seems to either negigible small, or limited to pure Web-Browser to > third-party Web-Server scenarios, i.e. pretty much none of our customers > are trying to make our software interoperate with such clients or servers. So none of your clients are dealing with bridge CAs, CAs that are handling migrations in the way that Ryan Sleevi indicated some are, or are dealing across organizational boundaries? > > I get to see most non-trivial SSL interop problems that our customers > report for usage scenarios, and what I've seen looks like a _very_low_ > number of misconfigured Apaches with OpenSSL with these three kinds > of problems: > - missing path CA certificates > (e.g. yesterday, after a service provider for invoicing has switched > from a verisign-issued server certificate, where it properly sent > all path certificates to a GeoTrust-issued server certificate, > where the server is sending only the server certificate) > > - duplicate certificate in the chain > > - garbled certificate chain (wrong oder of path certificates) > > For the handful of customers who had that interop problem, contacting > the server admin and having them fix their server configuration was > possible every time, and I could point to the spec after analyzing > the problem to pass the blame. > > > So what "flexibility" there is in some implementations is much > less relevant than with how much actual abuse there currently > is in the installed base. And to me, the visible level of abuse > is low, so the resulting amount of de-facto interop problems is low. As you admitted above, you don't see any of the problems in the wild the web browser people do. > > > The only motivation that has been given for changing the requirements > is that folks consider it necessary to promote the amount of abuse > in the installed base -- which is going to create interoperability > problems and headaches as a result. Or is it going to warn the implementor that all sorts of junk will be expected to work, and of some of the dragons that may exist? Documenting the *actual* problems in the world is far more useful than ignoring them entirely. > > > For those who have been and still are ignoring the requirements in > the specification today, why do you need these requirements changed? > You seemed to not have a problem ignoring the reasonable guidance > (that greatly simplifies implementations) all the time anyway -- you > evidently do not need this change. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu May 21 15:59:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3331A0382 for ; Thu, 21 May 2015 15:59: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 e35kB0AETgrQ for ; Thu, 21 May 2015 15:59:22 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1CB1A1BF2 for ; Thu, 21 May 2015 15:59:21 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so26177142wic.1 for ; Thu, 21 May 2015 15:59: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=kSgGnEOzoWJXkhKVSHkCI6FY4sznldGbvNg7v0nWnes=; b=hDJYuqUgri4s6zE5Cn3UVuWs3QRpDYIpiosHkCxmbkDKU6FVxF/DtxBbxKTpBvQ61c T66x7ONJKyPDEP5Q3ZRt3CQP53WTdajKmJErWNy9RMbZXeIjiKtX1A5L4dZTG+aTrclL RbH/VdHCRj+3AO8pgcVs8n04EIGNhdJWtw/4gOav8SGyRujJ5sOpgB35Y/VlSeUgVkqK FbVyB33HK5Fbw2hBvcc+GA5m6GuFlbyDknIg3LlV6kAM7GyeWrlxP34OxQOsJsCaosgL 85Hu84n1iLR8GKJ/R1+XVGILGKHmt5AnSnQ/mQliYIlQE/ysSnFfy2+CXWH2IGgCLL9o eRng== X-Received: by 10.180.109.6 with SMTP id ho6mr1814977wib.58.1432249160576; Thu, 21 May 2015 15:59:20 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id wv3sm408702wjc.0.2015.05.21.15.59.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 15:59:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Fri, 22 May 2015 01:59:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <943DD5B5-DD98-4AB5-80AF-EB56D2EABC86@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> <08521CEE-F00B-40B5-9A91-D290ED56EE67@gmail.com> <201505211816.42606.davemgarrett@gmail.com> <9ED694CA-2271-42DD-B094-55B560B9C76B@gmail.com> To: Watson Ladd X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "maray@microsoft.com" , "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:59:23 -0000 > On May 22, 2015, at 1:41 AM, Watson Ladd = wrote: >=20 > On Thu, May 21, 2015 at 6:34 PM, Yoav Nir wrote: >>=20 >>> On May 22, 2015, at 1:16 AM, Dave Garrett = wrote: >>>=20 >>> On Thursday, May 21, 2015 05:50:26 pm Yoav Nir wrote: >>>> According to netmarketshare.com Windows XP is still 16% of = desktops/laptops (as measured by web traffic). Add some older mac OS X = versions and you reach 17%. Even mobile has some older versions. What = this is proposing is to require servers to cut all of those off as a = pre-requisite to supporting TLS 1.3. >>>=20 >>> Windows XP & old Mac OS X users can install Mozilla Firefox or = Google Chrome (or one of the browsers based on one). It's just the built = in browser that won't work because the vendor dropped support. >>=20 >> And you are proposing that we force them to do this? Worse, you are = proposing that we deputize all server operators in forcing them to = replace their browser? >=20 > If not now, then when? When those machines rust away, or when their owners decide to buy shiny = new ones. Ultimately, it=E2=80=99s up to the server administrators to decide when = to drop support for something. I don=E2=80=99t see where it=E2=80=99s = our job to require them to do so as a pre-condition to deploying TLS = 1.3. Server implementers will ignore this even if we make it a MUST.= From nobody Thu May 21 16:04:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7031A8902 for ; Thu, 21 May 2015 16:04:06 -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 ZJTtCZd1P6co for ; Thu, 21 May 2015 16:04:05 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::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 3CC641A897F for ; Thu, 21 May 2015 16:03:06 -0700 (PDT) Received: by qcblr10 with SMTP id lr10so1038808qcb.0 for ; Thu, 21 May 2015 16:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=C4t12ofM2Y43ZsUAfqumuY0XA5OcUIcpPUSkzaWr+JE=; b=bK290giu0Hosp98gaGl2R6xkDsbReV2zQSEdKyHzfPEv2+xRud1vPnbsllDLo9GtAH IkGVYVhRYMgW5wfPAzPMX/CTk4zBORC8oXWKkHC5/dd3Ce9mWrSIrg5smz/64BUqXzWK xxtWjHrmQUuzBQrn4aPf1gko/090sldTPr2/z9UgqsmcGoxpzLOranfqqo7c4w6Swisv RMVTH2RL9Uyedchya8/J8DlSJYVZFBZfHXO4v1n5vYtNTyiMBSC+AGJNzzu5H9z2Gmys LMdiMyGidAbzX4lFlOZPirUICbgQcsZVMOEEBVyFSCng09nsd/svgO618+MRlkb0gLjR UPTw== X-Received: by 10.140.236.147 with SMTP id h141mr7587704qhc.77.1432249385448; Thu, 21 May 2015 16:03:05 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id c20sm202679qka.21.2015.05.21.16.03.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 16:03:04 -0700 (PDT) From: Dave Garrett To: Yoav Nir Date: Thu, 21 May 2015 19:03:03 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> <201505211816.42606.davemgarrett@gmail.com> <9ED694CA-2271-42DD-B094-55B560B9C76B@gmail.com> In-Reply-To: <9ED694CA-2271-42DD-B094-55B560B9C76B@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505211903.03845.davemgarrett@gmail.com> Archived-At: Cc: "maray@microsoft.com" , "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 23:04:06 -0000 On Thursday, May 21, 2015 06:34:08 pm Yoav Nir wrote: > > On May 22, 2015, at 1:16 AM, Dave Garrett wrote: > > On Thursday, May 21, 2015 05:50:26 pm Yoav Nir wrote: > >> According to netmarketshare.com Windows XP is still 16% of desktops/laptops (as measured by web traffic). Add some older mac OS X versions and you reach 17%. Even mobile has some older versions. What this is proposing is to require servers to cut all of those off as a pre-requisite to supporting TLS 1.3. > > > > Windows XP & old Mac OS X users can install Mozilla Firefox or Google Chrome (or one of the browsers based on one). It's just the built in browser that won't work because the vendor dropped support. > > And you are proposing that we force them to do this? Worse, you are proposing that we deputize all server operators in forcing them to replace their browser? Force them to not use IE8? Oh, the humanity. I'm saying it's a joke to say a server is secure when it still knowingly supports a security protocol from 16 years ago that has been replaced 3 times over. (2, prior to 1.3) At minimum, I'm saying a server that actually does that shouldn't be allowed to pretend it's compliant with modern security standards. Every time there's some new catastrophic vulnerability that's discovered (but of course, always existed) that involves some decade plus old junk, people feign surprise and slowly get around to dealing with the issue. This latest weak DH issue has been known to exist in some form for years, yet now, all of a sudden, we're bothering to deal with it because someone found out it was worse. There are trivial measures that, whilst having massive consequences, can be done proactively with real effect. Agreeing to disable protocols leftover from the '90s is a start. We know TLS 1.0 and 1.1 are not as secure as they should be, that's why TLS 1.2 exists and why TLS 1.3 is being designed. It's not some secret; they were replaced for legitimate reasons that we should stop ignoring if we want this protocol to have legitimacy. I'd like to be able to point to the TLS 1.3 spec and tell people that servers implementing it are as secure as we currently know how to make them, which is just not true unless their weakest link isn't obsolete crap. Dave From nobody Thu May 21 16:09:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6511A87DF for ; Thu, 21 May 2015 16:09:48 -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 c9COWwBHOsz3 for ; Thu, 21 May 2015 16:09:47 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9003D1A1AFB for ; Thu, 21 May 2015 16:09:47 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so26319923wic.1 for ; Thu, 21 May 2015 16:09:46 -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=sHHIKzjodREm4ekSqkHrpOqy88FBzTi86T1epm3jB9A=; b=wjFor3TbPlOqxNeIA3+7ZexvccvGTBLfNImlXejqahYUUM7o7ZkSAzzjeIepOYUlM8 ESZS/Ik0Z7pxA6xSdAfhesRJdIqlqrKOW9ijJmoshFIoO89bY0trenJyS8OEtj0eEs2a W585K82KvFAr6/SlD70VIg6B8qV8YP5U5f0yPLRSUvlrWh/euM2+lqvgM5oqarwR2/YN gyHxqRkWP0mH1Ug/0t1EMYmWHuvH7TE1Y8gPwvHMQUgnsKbuuQfUaFgWEQiz1vTM2Lt0 vK8IBXfazuQRDpRl5VVo4JwizyZGDy8X3+AvZpIjQSMYev5kgvLWdwFBaeTET9+k+Z0u XKSg== X-Received: by 10.180.218.195 with SMTP id pi3mr1801453wic.71.1432249786155; Thu, 21 May 2015 16:09:46 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id ex5sm4774635wib.2.2015.05.21.16.09.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 16:09:45 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <201505211903.03845.davemgarrett@gmail.com> Date: Fri, 22 May 2015 02:09:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6748CFBB-A1FB-4D3C-9E5F-5DFD4F7A7EBD@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> <201505211816.42606.davemgarrett@gmail.com> <9ED694CA-2271-42DD-B094-55B560B9C76B@gmail.com> <201505211903.03845.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "maray@microsoft.com" , "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 23:09:49 -0000 > On May 22, 2015, at 2:03 AM, Dave Garrett = wrote: >=20 > I'd like to be able to point to the TLS 1.3 spec and tell people that = servers implementing it are as secure as we currently know how to make = them, which is just not true unless their weakest link isn't obsolete = crap. Then point at the BCP. Only problem is that it doesn=92t say what you = want it to say (it allows TLS 1.0 when the client does not support = anything else)= From nobody Thu May 21 16:20:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A579B1A90CE for ; Thu, 21 May 2015 16:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.135 X-Spam-Level: X-Spam-Status: No, score=-0.135 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, FRT_LOLITA1=1.865, 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 YOWgGD4mhhKq for ; Thu, 21 May 2015 16:20:24 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 806BF1A8931 for ; Thu, 21 May 2015 16:20:24 -0700 (PDT) Received: by qkgv12 with SMTP id v12so1622187qkg.0 for ; Thu, 21 May 2015 16:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=NbYZ5HPjgHjq7li3K9Rh0tAltNt/za1g1Xagv0L/LTE=; b=papf91lqp+Mon6Q1F+Gcx2/A9gNKSkcsAI9zYRu+j6RfiQI3ipXGP9U/HMwwXo1nRu liqYx1SS3Wot/7KIu//VCgzEvERkpiXFWG5eNhUnHFB0b3QR3Uw9uoGuq5Ghbp/xetdJ /NII93CCIJ6WtaF2td9IP5VG51X/NHh55N0tsQr0T+patISccXzGN+TnO3W5M/1+ktFz bsGdMHxH/Rx/17BHCIJehFR++l8CD0QY4vIskCX9msCd0aVA1sBe+oTIWldJdnvN/C2k ahYKX5plyfQNBtI/pgT745rm90hlEMKJ+vPoKPM3dlcUnXVzpaQ7tyJv7bTvb2/qpfLt u6PA== X-Received: by 10.55.18.155 with SMTP id 27mr11148265qks.36.1432250423858; Thu, 21 May 2015 16:20:23 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 18sm212165qgh.40.2015.05.21.16.20.23 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 16:20:23 -0700 (PDT) From: Dave Garrett To: Yoav Nir Date: Thu, 21 May 2015 19:20:21 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> <943DD5B5-DD98-4AB5-80AF-EB56D2EABC86@gmail.com> In-Reply-To: <943DD5B5-DD98-4AB5-80AF-EB56D2EABC86@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201505211920.22236.davemgarrett@gmail.com> Archived-At: Cc: "maray@microsoft.com" , "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 23:20:25 -0000 On Thursday, May 21, 2015 06:59:17 pm Yoav Nir wrote: > Server implementers will ignore this even if we make it a MUST. So be it. As said before, there are no IETF police. Responsible server impl= ementations will follow the spec and the ones who want to trade security fo= r compatibility will not. Certainly not ideal, but it'd be a big improvemen= t over everyone ignoring things until they explode. At bare minimum, when t= he inevitable new vuln is published, the organizations running compliant im= plementations will be able to show they took things seriously and everyone = else did not. I'd at least like to write down the fact that everyone should= be aware that it should be obvious that continuing to use an obsolete secu= rity protocol for over a decade and a half is not wise. It would help upgra= de security more than ignoring the issue. On Thursday, May 21, 2015 07:09:42 pm Yoav Nir wrote: > Then point at the BCP. Only problem is that it doesn=E2=80=99t say what y= ou want it to say (it allows TLS 1.0 when the client does not support anyth= ing else) In my first post I said that I don't propose changing anything for existing= deployments. The BCP is currently a "SHOULD NOT" for current TLS. I'm prop= osing a "MUST NOT" for TLS 1.3+ implementations only. The BCP is also not directly part of the TLS spec. What I'm suggesting is c= onsidering 1.0/1.1 to be not legitimate forever, not just not "best". Dave From nobody Thu May 21 16:28:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9187D1A9041 for ; Thu, 21 May 2015 16:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 9qUz4LkzIbQk for ; Thu, 21 May 2015 16:28:38 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D001A8ADC for ; Thu, 21 May 2015 16:28:38 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 782D43E0C3; Fri, 22 May 2015 01:28:36 +0200 (CEST) X-purgate-ID: 152705::1432250916-00005316-02B3AE09/0/0 X-purgate-size: 1005 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 6664041209; Fri, 22 May 2015 01:28:36 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5AB841B31E; Fri, 22 May 2015 01:28:36 +0200 (CEST) In-Reply-To: <201505211210.43060.davemgarrett@gmail.com> To: Dave Garrett Date: Fri, 22 May 2015 01:28:36 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150521232836.5AB841B31E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 23:28:40 -0000 Dave Garrett wrote: > > https://tools.ietf.org/html/rfc7525 > > 2) For TLS 1.3, add a blurb to the effect of: > "Server TLS implementations supporting TLS 1.3 or later > MUST NOT negotiate TLS 1.0 or TLS 1.1 for any reason. You have just been passionately fighting _for_ ignoring a requirement in TLSv1.0->v1.2 that is extremely reasonable an interop-enhancing requirement. Now you're asking for addition of an obviously stupid requirement that will obviously impair interop. Such obviously bogus requirements are going to be entirely ignored by a number of implementors, and they will get away with it with ease just as the offenders of current requirements keep offending. The bottom line result will be that you're in conflict with rfc2119 and driving the quality of the document into the ground, because it will become more and more difficult to recognize which of the requirements are really important for interoperability, and which are just political junk. -Martin From nobody Thu May 21 16:29:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530F01A90AD for ; Thu, 21 May 2015 16:29:17 -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_20=-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 061ExjCdAOBC for ; Thu, 21 May 2015 16:29:16 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5AE1A88F0 for ; Thu, 21 May 2015 16:29:16 -0700 (PDT) Received: by ykfr66 with SMTP id r66so857831ykf.0 for ; Thu, 21 May 2015 16:29: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=FJL5gPG4vf34L3J3t72TSzPH0N081Mo8Nnr8BVtRsQ4=; b=MMQeV1Pr/YfCsRXQli4kgKJ26OV6OHVi4pM9MOuT1FGSvVLWqaoluC83Nw2WNgnjDA EVnotKfpIM1BHR104klam7CUNY3rWpBCXM5uZfwa3FroTS+IhhOpc+xwWce9Nlq3bkZS DOmCRWu2CLJFLAMYBa3GMdz6anCnHKkZKJC67GyxANXhHMTfzARMAEdLWF+qiCsBA+bw 2NM7HrPZv4svkIaXoQXRBNjJ3gPWF56JlciSGMCjO4dsclI6nKBEG544mqYPZGgq47u3 unThC/U0DfwDyHB3TEF58pa5s7RqpBuw96sok8E3mSroBltmrL8rFJx+xNNGs5SCfxe4 ZnzQ== MIME-Version: 1.0 X-Received: by 10.236.13.16 with SMTP id a16mr5222676yha.93.1432250955489; Thu, 21 May 2015 16:29:15 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Thu, 21 May 2015 16:29:15 -0700 (PDT) In-Reply-To: <201505211210.43060.davemgarrett@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> Date: Thu, 21 May 2015 16:29:15 -0700 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 23:29:17 -0000 On 21 May 2015 at 09:10, Dave Garrett wrote: > > 2) For TLS 1.3, add a blurb to the effect of: > "Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiate TLS 1.0 or TLS 1.1 for any reason. > Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible." I don't think that this is the right way to do this. I'm happy to be the one wielding the stick when the time is right, but I probably won't come here to do it. Implementations and operators of those implementations will make that determination on their own, based on their own needs. For example, we support crappy crypto on the Firefox download site - including SSL3 - on the basis that it makes more sense to allow clients who only support SSL3 to download our software. That way, they might get an approximation of good crypto rather than being left with the rubbish they have. We have a very different policy for our accounts servers, of course. From nobody Thu May 21 16:54:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE101A90DD for ; Thu, 21 May 2015 16:54: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 MT71nbffzC6A for ; Thu, 21 May 2015 16:54:26 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::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 28BFF1A908D for ; Thu, 21 May 2015 16:54:26 -0700 (PDT) Received: by qcblr10 with SMTP id lr10so1411592qcb.0 for ; Thu, 21 May 2015 16:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=RFgVr0CHY/4/bKgQ5aS6nE+iI8FIYQr48lvJgCZFT5M=; b=AJY2q1iBmTkrXu9yirJxgJ8nyGj7j6K/FjdhX7DGqqHC1RpWHznUI0/uATWHbEhUTA LJErAJHMivA9UmA4XzBbiTlfvkvLYdPkrAmHWuExz7UkrUdjGIJY0/JHwPAlzMge4qNJ qwb/9CDbNDzxgk0GV4aZ440uYhEWaQw1HlayrNV5lt+FImQrWs6HtzbmrgO15h3Gn/YZ dQwxCFTkx1sHCY7LKdzzOgKSge0T+jCIyjQRx/rTTeet8gCG3Z+3wfGdY+N59lM6fm/V RLpQHM8WWZGehSuLuy7LjCpHEAf6Py8k8+2jq8jHmZM5VYct3nYtwPHFuCYc7zRKanTe mGXw== X-Received: by 10.55.53.143 with SMTP id c137mr12189318qka.15.1432252465448; Thu, 21 May 2015 16:54:25 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id j60sm262977qge.38.2015.05.21.16.54.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 16:54:25 -0700 (PDT) From: Dave Garrett To: mrex@sap.com, tls@ietf.org Date: Thu, 21 May 2015 19:54:23 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150521232836.5AB841B31E@ld9781.wdf.sap.corp> In-Reply-To: <20150521232836.5AB841B31E@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505211954.24162.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 23:54:28 -0000 I'll make my reply to your previous email brief and simple. Replying with quoting would not be productive. My stance is not particularly complex. I want the best interop that's possible without compromising security in any meaningful way. Continued acceptance of 16 year old security protocol: Bad Different ordering of certificates on the wire: I don't care Ignoring the predictability of future vulnerabilities in known-obsolete stuff: Bad Writing down what's needed to actually be secure in the new security spec: Good From nobody Thu May 21 18:53:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD711A8A65 for ; Thu, 21 May 2015 18:53:20 -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 Gx7whCP8EeiP for ; Thu, 21 May 2015 18:53:18 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 97B7C1A8A5F for ; Thu, 21 May 2015 18:53:18 -0700 (PDT) Received: by qkdn188 with SMTP id n188so3263958qkd.2 for ; Thu, 21 May 2015 18:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=moiUA74/25p4Lr9xPqOLJHLDl5o5+MYFtppvrC2llJc=; b=HO+EyF7u0NM7+Y3nQm2aGqs5Vbfxw+GZwGGq/qOw/bz2b1A2JWtG96nEp0nV7C7xgK dYDX3fvc9E4PdrXLt7Y8RRpyZUt6m3RwY+LPOFouIF4f4aA3WWnyAVKFlb547i7Z9VBA ILDHSuCmeVyA10X5PjrhTiVD4GaJ7rFdYVeIAw/URzVlYAEBJcyWqHqFUd0HsPiOukcH hm4tQ6iCVyH+hS1EovlBZPJuxYmrSWJsQyBfa6cJ2fo4oELNISxhivWbjpJxXqCB+vuE fvbx6ZO1EKdYc3bJXRMCL8DvXfXLIgEQQZMdghEmFPeE2dYGHpxv04UPNEhOQqF70Oap UoSw== X-Received: by 10.140.151.15 with SMTP id 15mr7988207qhx.104.1432259597967; Thu, 21 May 2015 18:53:17 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b7sm441276qkb.33.2015.05.21.18.53.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 18:53:17 -0700 (PDT) From: Dave Garrett To: Martin Thomson Date: Thu, 21 May 2015 21:53:14 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505212153.14813.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 01:53:20 -0000 On Thursday, May 21, 2015 07:29:15 pm Martin Thomson wrote: > On 21 May 2015 at 09:10, Dave Garrett wrote: > > 2) For TLS 1.3, add a blurb to the effect of: > > "Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiate TLS 1.0 or TLS 1.1 for any reason. > > Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible." > > I don't think that this is the right way to do this. I think it's probably the only way to set up a deprecation plan rather than rely on panic disables. I do agree that it's not looking viable. > I'm happy to be the one wielding the stick when the time is right, but > I probably won't come here to do it. This standardization process is ill-equipped to deal with the issue, but it's the best place to try, near as I can tell. :/ > we support crappy crypto on the Firefox download site - including SSL3 - > on the basis that it makes more sense to allow clients who only > support SSL3 to download our software. That way, they might get an > approximation of good crypto rather than being left with the rubbish > they have. Yeah, browser download servers are the notable edge case. Pretty much everyone would agree that anything is better than nothing there. Ideally SSL3 could be dealt with via a separate server, but I certainly agree with their assessment that the complexity of actually doing that isn't worth it. Dave From nobody Thu May 21 19:42:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07271A8FD2 for ; Thu, 21 May 2015 19:42: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 r9RspwJc8tXA for ; Thu, 21 May 2015 19:42:53 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::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 7ABE21A8F51 for ; Thu, 21 May 2015 19:42:53 -0700 (PDT) Received: by pdfh10 with SMTP id h10so7309862pdf.3 for ; Thu, 21 May 2015 19:42: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=qecRWDc9LBlMuzFTCu+tGvmA6wuFaO17RmGS76B+nhw=; b=UTLuD6/WrVTIPvD4EeQ/0vy8cdIfUQssxZjm4fTSDw04UEfr4kFtMv/96CS3t8cCce 3KvIO1gK8nGAy6QHGDxxxSItX6wPWPSbvEBDCLaWEedFW9eskCv3YdyGBNJ9P2EqZTBb 8sBhNVy6wjmPgcR1Wg3Cy7IeTtx5wxB/xBTy7/ZHv4or7t4Zi0skfh7oFSrF0c8mfidV frnkiWd7icBJg7RlMSHIaGjD6P1JjcgDM1uUV+BirLscLRKD3svBFGH/wYjD4UXwj/Dp LVmb+rwjanWOaABKX26D//7cJ790uTjVGe9M4V4lFnwfy4vyvkXIvD5TYlKBZDBQKhok V47g== MIME-Version: 1.0 X-Received: by 10.70.128.68 with SMTP id nm4mr11377412pdb.74.1432262573066; Thu, 21 May 2015 19:42:53 -0700 (PDT) Received: by 10.70.66.5 with HTTP; Thu, 21 May 2015 19:42:53 -0700 (PDT) In-Reply-To: <20150520190727.GD19183@localhost> References: <1432142087.2946.11.camel@josefsson.org> <20150520190727.GD19183@localhost> Date: Thu, 21 May 2015 19:42:53 -0700 Message-ID: From: Peter Bowen To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 02:42:54 -0000 On Wed, May 20, 2015 at 12:07 PM, Nico Williams wrote: > On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote: >> Support for EdDSA/Ed25519 in TLS has been suggested a couple of times. > > I'm in favor. > >> One aspect I'm aware of is that there is no OID allocated nor >> specification of PKIX certificates with EdDSA/Ed25519 public keys. I'm >> not sure the above document is the right place for doing that though, >> and more thinking around this topic is especially appreciated. > > It's an OID. You can get your own OID arc and then allocate an OID. > > Is it important to separate the addition of a PKIX algorithm OID from > the TLS bits? Well, it is neater that way. I'll donate a short OID to the cause if that will help move things forward. We have the 1.3.187 arc which is only three bytes DER. If someone has a smaller arc (third node would be 127 or lower) and would offer an OID from their arc we can shave off another couple of bytes. From nobody Thu May 21 19:46:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE601A8F51 for ; Thu, 21 May 2015 19:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 TGkWZA7TGg9n for ; Thu, 21 May 2015 19:46:34 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::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 E86731A8F43 for ; Thu, 21 May 2015 19:46:33 -0700 (PDT) Received: by iesa3 with SMTP id a3so22414133ies.2 for ; Thu, 21 May 2015 19:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=upZkqkW19nu+kW/81qbEw9fXBPaym4UUqxweZievn0s=; b=exZC3QybpjWdnWp+wAKB+Do3d36+lQKGWHHmUwdXMYGRdslxjrV/x3MBVlj3kMfwfz vomQE8ErQdFSehllRnJjvknwiyXpi3US99ZcktihFg5y6dDYZbQW3nAR4t8t1y97j+85 5FWYhce53+uxagrbWbWPi+q7N5N9oP+P1vLhltbUXEtT3pGWAan65rxaV7fxxlZB2nL7 leDRSSwUptob+0IpARLGqXGi/q3TEXjdCrwFPVexo5tx68t85/6DAx6Fl5z7FgE/Jpwb 1Nv24uxZhSrgF/W2zg5bZcbqWcZP549YzHqqbFdlHn4X4Vy2pWzWSmeSFYxXu2ctqefQ 16rw== MIME-Version: 1.0 X-Received: by 10.107.157.130 with SMTP id g124mr7828041ioe.11.1432262793275; Thu, 21 May 2015 19:46:33 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Thu, 21 May 2015 19:46:33 -0700 (PDT) Date: Thu, 21 May 2015 22:46:33 -0400 Message-ID: From: Jeffrey Walton To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] TLS 1.3 and vendor strings? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 02:46:35 -0000 Are there any plans to support free form vendor strings? The use case is similar to Apple's buggy ECDHE-ECDSA SecureTransport for OS X 10.8 and iOS 7. In this case, OpenSSL had to jump through a number of hoops to identify the potentially affected clients via fingerprinting. Fingerprinting was not precise, and it potentially captured unaffected clients when Apple patched at OS X 10.8.4 and iOS 7.0.3. That is, an OS X 10.8.5 or iOS 7.0.4 client would potentially be identified as buggy even though it was patched. Or is there another way to handle the occasional implementation bug like this? (And to be clear: patching is not always an option. Apple is not like Microsoft or Linux. Rather, they left a number of hosts unpatched for the ECDHE-ECDSA bug; and did the same with CVE-2015-1130 (Goto Fail); and did the same with CVE-2015-1130 (Hidden Backdoor)). From nobody Thu May 21 19:52:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3598E1A8FD2 for ; Thu, 21 May 2015 19:52:17 -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 zYvnvosMVE8y for ; Thu, 21 May 2015 19:52:16 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 A9D5A1A8F51 for ; Thu, 21 May 2015 19:52:15 -0700 (PDT) Received: by wibt6 with SMTP id t6so33035749wib.0 for ; Thu, 21 May 2015 19:52:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Xq5WzDvuXDmv8ykKyIn0v0kWW0WQigcxQF23vXJxX+M=; b=i8mRSqdz2F2i+2sEJ8IM6G2s75gcy7bvprAb3yWx7/z7Lymn7bL+qzhZiqVjXsTywA KA6dRV6cX4giQjW5f65LYh0B8F9DyqANCF5ElzgeBWce8jw2mJX4xAQQk4AKRwBf9gsm /+4XvXeY4ukeBkQYVAsN0cdBBow9uDeV4cJRPYNOY2EL1rFIUDOGQGsyk2NWbndNBDxs N1D74+7VlywCR1kWpoy2cug2LHECfYD/IFUU3ACUg7lA67TVdSO6kv8gxwW8NeLMU7EY hJ3jkKNsceFNtyK64JVGCK3HMCSXOZw9ddAUI1qRAX6FD7FV6Kho/KyQVtEwkjI2IQ18 ohFA== X-Gm-Message-State: ALoCoQmtPPCNjudR99uAg6h/X6cvVUMFI02he1awMpLxkkBI03gxQgEnPcMRcTEz8EYwmmYOG+ms X-Received: by 10.180.86.234 with SMTP id s10mr2987491wiz.50.1432263134516; Thu, 21 May 2015 19:52:14 -0700 (PDT) Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id d14sm977231wjn.30.2015.05.21.19.52.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 19:52:13 -0700 (PDT) Date: Fri, 22 May 2015 04:52:16 +0200 From: Aaron Zauner To: Martin Thomson Message-ID: <20150522025214.GA21141@typhoon.azet.org> References: <201505211210.43060.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 02:52:17 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hi, * Martin Thomson [22/05/2015 01:29:19] wrote: > I don't think that this is the right way to do this. I agree. While this is a noble effort, it's the wrong approach to the problem at hand in my opinion. We do have a BCP from UTA which a lot of work was put into. It basically tells people to deprecate everything that's not TLS 1.2 with an AEAD. > I'm happy to be the one wielding the stick when the time is right, but > I probably won't come here to do it. So how about that TLSv1-diediedie document? :) Aaron --SUOF0GtieIMvvwua Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVXpneAAoJEOTbZJL9ubXV+qUP+gPjNmojyUZs03xTPvNHcvG1 rpOoclqy3ntEtKnqiwwD4HqrfbXBvFDjnMJRpab6bN6sqN2No8BTrzM4WTvQICRo 8X8grozlGpgWgfRDRfN4nNbcRNj3k4jexy67vGHd8rv1bIFlEGvjlljt4VWSSvw9 iOTShvmLBjPSMqAcnDMwTck04IXayBL+keR6GQXpr2eQu+TTeK2BSRx3iP0npZju ym8a4NkzJfZY9a9uIFGS8quG6zMbd8vJMgLeFMpaIEw6eG8+Zt4CM7plUF5k35Hk nl8M7AeG3/o26L7rYpbCgDi89WZvF+k5mEMLsortZI27NCvORihyyitvBkOUiw4k f++3TRuR8nmMgytbjTvsn69hUGLD7a6vvXemH8+CPAebSlsp9Py9p6Qy/Uf6lyLd +d8/st+sumFfemsoEXHEePS06C3SAWmZY/F93Utmqx9e80TpQLtpAtAkAgeFvrEd DOar6JACgpbRHuaGWFZo/hX9Yhw4tnHyfVkSjCLiJQxaEYA170VphEAdNxkoTkZ8 /UUoADcb6MDW+ETK8YBFUjvEp1Jz+61BHiIt4RqoWwfJLgDe09TqNmPPG+FJQjDl j+m3BVFIgL9/eNj6OlD8X5zwYkJQn7uHgirYpWeQgKXcWgluOPjLygSsYh8UoI0G xXuv4c86/mZHYy1otKLo =cJat -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From nobody Thu May 21 19:56:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B402E1A8F51 for ; Thu, 21 May 2015 19:56:45 -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 lTfJ6tEBtxAQ for ; Thu, 21 May 2015 19:56:44 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5011A8F43 for ; Thu, 21 May 2015 19:56:44 -0700 (PDT) Received: by obcus9 with SMTP id us9so4263189obc.2 for ; Thu, 21 May 2015 19:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=14QzR9K3Hk99Ch7nqm9+3ooqxtikwQp3b2xklpmNS04=; b=CAmzlZOqWzfNARWEc+8FG7Fa69azK2Ii5vgRHfzxfwbgCUPg9MXP/Vb61gDlc5cKTG hrONUDWZfl73nBjY2e3+udpu64UMpMiMUx4OEZRDzs27Ox0sikKy2pd4g2Q0e4aMEcJN gG0Bssb3QPaU+1Mcnbcshaa9n3As9RR6WUjqcqx95xjH+mI+Ssfbk+Wjr2i3kxfyMUrg WKEACj83S8OIxkWxOlJc3AEVpvtCz0m2/e3rL1tOXia0aYOLvJRFhBrSKMk64XVbfD/D J810OCKGc9LRbUSc4DZnaKgqgWUbK/K2FIWZinsEf5WBZtw/+abS3mzzvjjqfv6LCCvo Nqyw== X-Received: by 10.60.144.201 with SMTP id so9mr4855995oeb.3.1432263403486; Thu, 21 May 2015 19:56:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.25.198 with HTTP; Thu, 21 May 2015 19:56:22 -0700 (PDT) In-Reply-To: <20150522025214.GA21141@typhoon.azet.org> References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> From: Tony Arcieri Date: Thu, 21 May 2015 19:56:22 -0700 Message-ID: To: Aaron Zauner Content-Type: multipart/alternative; boundary=047d7b3a970863c6340516a2cf2d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 02:56:45 -0000 --047d7b3a970863c6340516a2cf2d Content-Type: text/plain; charset=UTF-8 On Thu, May 21, 2015 at 7:52 PM, Aaron Zauner wrote: > So how about that TLSv1-diediedie document? :) I am very much +1 for more diediedie documents ;) -- Tony Arcieri --047d7b3a970863c6340516a2cf2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 21, 2015 at 7:52 PM, Aaron Zauner <= azet@azet.org> wrote:
So ho= w about that TLSv1-diediedie document? :)

I= am very much +1 for more diediedie documents ;)=C2=A0

=
--
Tony Arcieri
--047d7b3a970863c6340516a2cf2d-- From nobody Thu May 21 20:04:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465621A903A for ; Thu, 21 May 2015 20:04:15 -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 0ykusE9sdBmX for ; Thu, 21 May 2015 20:04:13 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 B13D21A9039 for ; Thu, 21 May 2015 20:04:13 -0700 (PDT) Received: by qgez61 with SMTP id z61so2899359qge.1 for ; Thu, 21 May 2015 20:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=Jb7CM0iN2/RpHCKu1gtPPHEgn/zbje4xil73wU2b6gs=; b=EkFHss3aN9sEOfs80E2mGDe6GE1PNOBYxbtWNkxF2ErXq8nfZo/gMvVx6T/jwCzzLr bu0nKEztT/ChgHvAwv+tkwqrzbtx2FTlmYbwBtip0c/kz6f10+jBUW1dVr1wpsBPqtDB gGy5Tzw8+SE6RqDB7DOVitTRGodJG5b5MJQGE+zamlW2YfX6pGeFsfVn0ZOazdByx8/P 9mvQ2QrXJSoAOS8HWTSjTghMXkvDrIYt5fdoZMpiKfKuulyMt7aJ+Cq2iHm0LMSGbfNC x/9brThULsE7S+Pajzk6UeN8oZHEVI6cybssSg4Ymc2GN2pfnWEuAJyVbzq0x6EsG17n ditg== X-Received: by 10.140.150.209 with SMTP id 200mr8606337qhw.31.1432263852941; Thu, 21 May 2015 20:04:12 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id d69sm549185qhc.3.2015.05.21.20.04.12 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 20:04:12 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Thu, 21 May 2015 23:04:11 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505212304.11513.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 03:04:15 -0000 On Thursday, May 21, 2015 10:56:22 pm Tony Arcieri wrote: > On Thu, May 21, 2015 at 7:52 PM, Aaron Zauner wrote: > > So how about that TLSv1-diediedie document? :) > > I am very much +1 for more diediedie documents ;) I'm certainly not going to argue against that. ;) That said, the RC4 diediedie is getting largely ignored. To actually kill something like this off, it seems to need to be done as a panic response or as a requirement of something new that everyone starts together. (e.g. SSL3 diediedie or old TLS with HTTP/2) Thus was my reasoning for at least attempting to suggest it here. :| Dave From nobody Thu May 21 20:06:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C681A903C for ; Thu, 21 May 2015 20:06:37 -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 SOucemmC7XDw for ; Thu, 21 May 2015 20:06:37 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D064A1A903B for ; Thu, 21 May 2015 20:06:36 -0700 (PDT) Received: by ykft189 with SMTP id t189so2187010ykf.1 for ; Thu, 21 May 2015 20:06:36 -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=/cheRQ58Eu19EHh8GeKW5L2betLs0cVLDjZBYFBCVt4=; b=p7KN+RVlFYul1vEtLcHwPaw6ZgYUW6RQy0J7KRyNPXlpuJoJ9DNFAii5IGqbsz+TM9 P9NC9CU5OMsh9JtDkJiYYJ16wCJRNEUrtQZMEa3MesvNaPTqyo2jU9I5F6UwaIW9EPbL 67sGnqXyUwTCCBTAmR4r0YRjQIRFOmrNzofP8qxc825yEIiYTDI+fbxLxUuXL5vwosAy l+THnleqauqzYjZbQLOi85NR7aQCMt3BZ7v31y/Ad7DVoheZ+bvdsvgByO0+nSyda0ny A5lnN0sIFDg+tcY6YWKM8CiddExePmwAlGkyPVPD/0YxFs4/As2JCBgfrJCW219deLjO 1iBg== MIME-Version: 1.0 X-Received: by 10.236.20.230 with SMTP id p66mr5900535yhp.181.1432263996270; Thu, 21 May 2015 20:06:36 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Thu, 21 May 2015 20:06:36 -0700 (PDT) In-Reply-To: <201505212304.11513.davemgarrett@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> Date: Thu, 21 May 2015 20:06:36 -0700 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 03:06:38 -0000 On 21 May 2015 at 20:04, Dave Garrett wrote: > That said, the RC4 diediedie is getting largely ignored. That's not true. I think that you expect something as large as the Internet to move on timescales that just aren't feasible. There's an entire supply chain that has to move here. From nobody Thu May 21 20:15:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58731A9090 for ; Thu, 21 May 2015 20:15:00 -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 xPZHUW5T-KlL for ; Thu, 21 May 2015 20:14:59 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 9454D1A908F for ; Thu, 21 May 2015 20:14:59 -0700 (PDT) Received: by qkx62 with SMTP id 62so4091081qkx.3 for ; Thu, 21 May 2015 20:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=ce1FxXIzIzyVfZmAj4wrFqTziiUhv92bonLFaUf2KwA=; b=wZY8iVxnP2qQSeSv96KNvqt92pB7mrLYMRuJj+DKnBuspMplv/jrDfiyMwjNemMYri QxcKDcR3Jq+sGj/dtF+ETiLXRLBPDo9fky8d6bvR+8NlGq2X2R972XAo/+/kxlSpkkpa ibxLi1boaJkxwB53O7XNRPleG7BIjyY+YacK+ZDpofShCveMbub6ojg461a+hBEWyKT7 qkZtwMMhXHCjC82KBhcg/jvx5uW237dpuzt1VMNvxNFu0Tqg2c+7O6xL6Gsn33Cz9Pzm SDdXInrabPS2o1JQEK3ohJa9H5sCWmM23gN7oK/0/kt0owD1LG8fcAQo1H5yk/M4Yqva 3qSQ== X-Received: by 10.140.108.195 with SMTP id j61mr8212266qgf.83.1432264498869; Thu, 21 May 2015 20:14:58 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id j60sm537385qge.38.2015.05.21.20.14.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 20:14:58 -0700 (PDT) From: Dave Garrett To: Martin Thomson Date: Thu, 21 May 2015 23:14:57 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> <201505212304.11513.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505212314.57525.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 03:15:01 -0000 On Thursday, May 21, 2015 11:06:36 pm Martin Thomson wrote: > On 21 May 2015 at 20:04, Dave Garrett wrote: > > That said, the RC4 diediedie is getting largely ignored. > > That's not true. I think that you expect something as large as the > Internet to move on timescales that just aren't feasible. There's an > entire supply chain that has to move here. Fair enough; ignored is not the right word. I should say instead that I have not seen a change nearly on the scale of the SSL3 RFC. Those who were in the process of phasing out RC4 are still doing so at a comparable pace. Browsers were willing to accept breakage for SSL3, but they're not yet ready for RC4. In comparison it appears to have had less effect, at least so far. This will, of course, hopefully change. From nobody Thu May 21 20:17:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AFE1A909C for ; Thu, 21 May 2015 20:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdR1Z_HT3oo1 for ; Thu, 21 May 2015 20:17:46 -0700 (PDT) Received: from BLU004-OMC1S9.hotmail.com (blu004-omc1s9.hotmail.com [65.55.116.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5FE81A9096 for ; Thu, 21 May 2015 20:17:45 -0700 (PDT) Received: from BLU177-W50 ([65.55.116.9]) by BLU004-OMC1S9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 21 May 2015 20:17:44 -0700 X-TMN: [odrM5G/6nAGt32EGT5fEuXO6rWDPzYtC] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: "noloader@gmail.com" , "tls@ietf.org" Date: Thu, 21 May 2015 20:17:44 -0700 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 May 2015 03:17:44.0732 (UTC) FILETIME=[DEE6ADC0:01D0943D] Archived-At: Subject: Re: [TLS] TLS 1.3 and vendor strings? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 03:17:47 -0000 In this case=2C the pre-10.8.4 versions of OS X lost marketshare pretty qui= ckly=2C I think by now it is less than 0.1% now.=0A= =0A= ----------------------------------------=0A= > Date: Thu=2C 21 May 2015 22:46:33 -0400=0A= > From: noloader@gmail.com=0A= > To: tls@ietf.org=0A= > Subject: [TLS] TLS 1.3 and vendor strings?=0A= >=0A= > Are there any plans to support free form vendor strings?=0A= >=0A= > The use case is similar to Apple's buggy ECDHE-ECDSA SecureTransport=0A= > for OS X 10.8 and iOS 7.=0A= >=0A= > In this case=2C OpenSSL had to jump through a number of hoops to=0A= > identify the potentially affected clients via fingerprinting.=0A= > Fingerprinting was not precise=2C and it potentially captured unaffected= =0A= > clients when Apple patched at OS X 10.8.4 and iOS 7.0.3. That is=2C an=0A= > OS X 10.8.5 or iOS 7.0.4 client would potentially be identified as=0A= > buggy even though it was patched.=0A= >=0A= > Or is there another way to handle the occasional implementation bug like = this?=0A= >=0A= > (And to be clear: patching is not always an option. Apple is not like=0A= > Microsoft or Linux. Rather=2C they left a number of hosts unpatched for= =0A= > the ECDHE-ECDSA bug=3B and did the same with CVE-2015-1130 (Goto Fail)=3B= =0A= > and did the same with CVE-2015-1130 (Hidden Backdoor)).=0A= >=0A= > _______________________________________________=0A= > TLS mailing list=0A= > TLS@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tls=0A= = From nobody Thu May 21 20:20:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF1C1A909C for ; Thu, 21 May 2015 20:20:32 -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 zhWfQsnsvyOn for ; Thu, 21 May 2015 20:20:31 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (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 BCE0A1A9096 for ; Thu, 21 May 2015 20:20:30 -0700 (PDT) Received: by wgfl8 with SMTP id l8so5263376wgf.2 for ; Thu, 21 May 2015 20:20:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=X3qsWGwns2Hy3/OxvcISwA0/F/USBU9RncujUOqx2M4=; b=lO5b6XPjgZrAwcuN23MdbrZI4c/EDh5y4fIKGphdxvUer8aKRH4DGwbfrADrDp3eLG QWHJd8AyFqldb/kHYa/rn3KKKPvbvjFdcaKUlQx8EquGh1WvExeTU/FwJGFE6BhrLsRU HnF2JSAwUDm64+eUGqZhewNs0gf8SoCaRVPYmilg3/tZ1a5KvLA7CtS33ol3Ip8SQYQJ vb0lRIRz0hYrXeiXSlBHyjmaSNmlfb8Yid2C3xvAZrKIqpE4EvUd3MolIJSIBT4Lq4XS S09IyG7D+ZkjW9fYHy/WLMXM+whIMegc1lye0zSPJNVMTufhyUWng+JZhMW+x+MMEQ7z fkPw== X-Gm-Message-State: ALoCoQkoBoxO6unv9w0Wgs2Xeomzg3yd5cS1RWJf0N5GMcem/QiyzZMQNDcMTkbMFjPr825KJTFx X-Received: by 10.180.83.40 with SMTP id n8mr3138590wiy.57.1432264829508; Thu, 21 May 2015 20:20:29 -0700 (PDT) Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id b2sm1034399wje.40.2015.05.21.20.20.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 20:20:28 -0700 (PDT) Date: Fri, 22 May 2015 05:20:30 +0200 From: Aaron Zauner To: Dave Garrett Message-ID: <20150522032029.GA24064@typhoon.azet.org> References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <201505212304.11513.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 03:20:32 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline * Dave Garrett [22/05/2015 05:04:13] wrote: > That said, the RC4 diediedie is getting largely ignored. To actually kill something like this off, it seems to need to be done as a panic response or as a requirement of something new that everyone starts together. (e.g. SSL3 diediedie or old TLS with HTTP/2) Thus was my reasoning for at least attempting to suggest it here. :| I don't have that impression at all. The RC4 and SSLv3 deprecation documents even got (some) media attention, which is quite rare for IETF documents. Same with the UTA BCP on TLS and attacks. As suggested in the starting post this would effectively mean that an implementation that does support 1.3 MUST NOT support anything lower than that. Which -- of course -- means you're locking users out that only have poor/bad crypto at hand. Somewhat refering to the opportunistic debate; it's again bad crypto vs. no crypto at all. :/ Aaron --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVXqB9AAoJEOTbZJL9ubXVBUQQAMwb/FijtaiIhlfaiMTtVMhI VD+yQncBkihvymzHtVKJb2LwaEV4quOjzrc+rqIaV0D67fuO0RJwrtEtt8a8z/d8 +u6wRO3sHXd4UzcfnDaz3giKNpYt3FIDKxUdIoj+Zu5gvoBldFImdCm7wT9xogdx XR0mtqKQw6MWkAJ2RTFsrdS0AIk12MjWQPH1PqWGpz5H0OlXKpX+hLDIlIMUuQ2s 7wnEsFTgF2NUR0xj2ZWh8WsOzjM69kW8l5T8QP4DX9QZFaW3mJ7SEahNX12SuDka b6RbGiNIsU94D/wtLtH1wk7perWcN9rbkIz41nPL5MJeClmxYze3jGcb3dOWD/0p FWAo7EVgQ2ndYhIztOGNgMOYCJrrQ1JDDzdG7FlhKWuF7WZTWuO0m6Di1TvPjdTx qLivEqecTW5jNkJO5dXVDOoZWE4V1STVgS4IzdSKpQXZrLOIsnFY+UP6wElVJO1q +AsY75+RsjcBBMcBZFKOrX/cD0VlrxmET89xOkY+poNrzbGhKuVkuKoje/UMj6kL wVsWhXcypM9qA14jLWTHcJBJwouU1XIBG3mBL4tQmoiwv7dLvF8W/lC/gVFRpxCd jmeFjtOLCTjKvJSPizgQt4M3Z9XzNl0ZobqfINPETn6FMLr56xK7LThbiWlnWx+P WeWquh7U0B6ff6rxaMVZ =KgrE -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From nobody Thu May 21 20:30:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4D51A9094 for ; Thu, 21 May 2015 20:30:33 -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 HfpKwyU6b2_o for ; Thu, 21 May 2015 20:30:31 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::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 02D171A9092 for ; Thu, 21 May 2015 20:30:31 -0700 (PDT) Received: by qctt3 with SMTP id t3so3063772qct.1 for ; Thu, 21 May 2015 20:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qJ2ShR9oyiSXNU4WWVWYvN88oam6aMTqDQyWtRgaDMs=; b=xIv+ZZs5a1AWJlmwrI/pmQ9R4ZaoxGQ2xTzPlckzXN70Af+1PH01SQ5Chu3bnkf7u0 RDWwIB92+2dNpx0FcJv6e0B4YvlYaGs2ZL0Zt6eQenoJoLYYe+rsN9oPNuLGMDGRdH9B SUDaN1TxGwm2Z/TOHCCVSNCeTHICb9oeUNwFDnwGCWO6Cxv/PAY8CEACLh1r/pMtdGu6 K2al35Cbp6TzZ9LpYunU/3vw6Zr4PHhvYSfiQsaTkrov7ux9Qtfyhx30pKdHqhTgWnwR FPXhPepwyq4Sp53qkY8M1RGnc6SNySH0HwzNU9ymdIwlg3qLwE3qbIPN1G4BMy0OxNl1 KvAQ== MIME-Version: 1.0 X-Received: by 10.140.43.228 with SMTP id e91mr8062955qga.80.1432265430177; Thu, 21 May 2015 20:30:30 -0700 (PDT) Received: by 10.229.105.8 with HTTP; Thu, 21 May 2015 20:30:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 May 2015 23:30:30 -0400 Message-ID: From: Jeffrey Walton To: Yuhong Bao Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 and vendor strings? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 03:30:33 -0000 On Thu, May 21, 2015 at 11:17 PM, Yuhong Bao wrote: > In this case, the pre-10.8.4 versions of OS X lost marketshare pretty quickly, I think by now it is less than 0.1% now. > Unfortunately, I have two OS X machines that are still in the 10.8 series. That's because of Xcode/iOS support. I still need to support older version of iOS; and for that, I need an older version of Xcode; and for that, I need an older version of OS X. ... and the worst part is, its for dumb reasons, like Apple changed UI scheme to light blue text on white background. I literally cannot read the text, and had to hold back on upgrades so I could see it. Jeff >> Date: Thu, 21 May 2015 22:46:33 -0400 >> From: noloader@gmail.com >> To: tls@ietf.org >> Subject: [TLS] TLS 1.3 and vendor strings? >> >> Are there any plans to support free form vendor strings? >> >> The use case is similar to Apple's buggy ECDHE-ECDSA SecureTransport >> for OS X 10.8 and iOS 7. >> >> In this case, OpenSSL had to jump through a number of hoops to >> identify the potentially affected clients via fingerprinting. >> Fingerprinting was not precise, and it potentially captured unaffected >> clients when Apple patched at OS X 10.8.4 and iOS 7.0.3. That is, an >> OS X 10.8.5 or iOS 7.0.4 client would potentially be identified as >> buggy even though it was patched. >> >> Or is there another way to handle the occasional implementation bug like this? >> >> (And to be clear: patching is not always an option. Apple is not like >> Microsoft or Linux. Rather, they left a number of hosts unpatched for >> the ECDHE-ECDSA bug; and did the same with CVE-2015-1130 (Goto Fail); >> and did the same with CVE-2015-1130 (Hidden Backdoor)). >> From nobody Thu May 21 20:39:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594EE1A90BC for ; Thu, 21 May 2015 20:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO-1UuWnfgxW for ; Thu, 21 May 2015 20:39:06 -0700 (PDT) Received: from BLU004-OMC1S38.hotmail.com (blu004-omc1s38.hotmail.com [65.55.116.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4F51A90B7 for ; Thu, 21 May 2015 20:39:06 -0700 (PDT) Received: from BLU177-W31 ([65.55.116.7]) by BLU004-OMC1S38.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 21 May 2015 20:39:06 -0700 X-TMN: [fI9QR0VEZRF3wDmjeNt7O4IfBswIXy7I] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: "noloader@gmail.com" Date: Thu, 21 May 2015 20:39:05 -0700 Importance: Normal In-Reply-To: References: , , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 May 2015 03:39:06.0032 (UTC) FILETIME=[DA9D8B00:01D09440] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 and vendor strings? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 03:39:08 -0000 I know=2C but they released an update to the 10.8 series to fix the problem= and most users has installed it by now.=0A= =0A= ----------------------------------------=0A= > Date: Thu=2C 21 May 2015 23:30:30 -0400=0A= > Subject: Re: [TLS] TLS 1.3 and vendor strings?=0A= > From: noloader@gmail.com=0A= > To: yuhongbao_386@hotmail.com=0A= > CC: tls@ietf.org=0A= >=0A= > On Thu=2C May 21=2C 2015 at 11:17 PM=2C Yuhong Bao wrote:=0A= >> In this case=2C the pre-10.8.4 versions of OS X lost marketshare pretty = quickly=2C I think by now it is less than 0.1% now.=0A= >>=0A= > Unfortunately=2C I have two OS X machines that are still in the 10.8=0A= > series. That's because of Xcode/iOS support. I still need to support=0A= > older version of iOS=3B and for that=2C I need an older version of Xcode= =3B=0A= > and for that=2C I need an older version of OS X.=0A= >=0A= > ... and the worst part is=2C its for dumb reasons=2C like Apple changed U= I=0A= > scheme to light blue text on white background. I literally cannot read=0A= > the text=2C and had to hold back on upgrades so I could see it.=0A= >=0A= > Jeff=0A= >=0A= >>> Date: Thu=2C 21 May 2015 22:46:33 -0400=0A= >>> From: noloader@gmail.com=0A= >>> To: tls@ietf.org=0A= >>> Subject: [TLS] TLS 1.3 and vendor strings?=0A= >>>=0A= >>> Are there any plans to support free form vendor strings?=0A= >>>=0A= >>> The use case is similar to Apple's buggy ECDHE-ECDSA SecureTransport=0A= >>> for OS X 10.8 and iOS 7.=0A= >>>=0A= >>> In this case=2C OpenSSL had to jump through a number of hoops to=0A= >>> identify the potentially affected clients via fingerprinting.=0A= >>> Fingerprinting was not precise=2C and it potentially captured unaffecte= d=0A= >>> clients when Apple patched at OS X 10.8.4 and iOS 7.0.3. That is=2C an= =0A= >>> OS X 10.8.5 or iOS 7.0.4 client would potentially be identified as=0A= >>> buggy even though it was patched.=0A= >>>=0A= >>> Or is there another way to handle the occasional implementation bug lik= e this?=0A= >>>=0A= >>> (And to be clear: patching is not always an option. Apple is not like= =0A= >>> Microsoft or Linux. Rather=2C they left a number of hosts unpatched for= =0A= >>> the ECDHE-ECDSA bug=3B and did the same with CVE-2015-1130 (Goto Fail)= =3B=0A= >>> and did the same with CVE-2015-1130 (Hidden Backdoor)).=0A= >>>=0A= = From nobody Thu May 21 20:42:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E220D1A90BD for ; Thu, 21 May 2015 20:42:17 -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 lQCnPewXNcTc for ; Thu, 21 May 2015 20:42:16 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (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 20AFE1A90B7 for ; Thu, 21 May 2015 20:42:16 -0700 (PDT) Received: by yhda23 with SMTP id a23so1624837yhd.2 for ; Thu, 21 May 2015 20:42: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:content-transfer-encoding; bh=iVTKARmKcmKcm5NrdGKdqywcP3+wBuxhvWuIKgZJ4eA=; b=Gj0PO7oS58YoGKIK5WcxBdOWJV8lF9OgUVYx7JcqUTqXa4tyxj6Ja3nkqdS+XRXUN6 NAEdJzlWvFGp0QtgiTED0O0x77t2Mv70lvsyL5J9+105SZ4pcFBEemqgGoc/p9hMlMNu Z+2MbJhFCIGCb8Hzdf69UURkAcpGUZz8P/wlKZIFWwFt7kbsT5D8JhGblJYTBlh++/jM VDqnCIxTwLAX2/1n/Deegv/wrJK4FOq1CgyNHINPFI3GonJDSn8F6ECykfMINQFlJloY 3lIN3KZbekWKMBM+ydRv6V8YOSKDxXED2pSVxea2/KTz+hOKK0LsSqpJWQlChVYw8pz7 eG4w== MIME-Version: 1.0 X-Received: by 10.170.112.18 with SMTP id e18mr2211069ykb.101.1432266135468; Thu, 21 May 2015 20:42:15 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Thu, 21 May 2015 20:42:15 -0700 (PDT) In-Reply-To: <201505212314.57525.davemgarrett@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> <201505212304.11513.davemgarrett@gmail.com> <201505212314.57525.davemgarrett@gmail.com> Date: Thu, 21 May 2015 20:42:15 -0700 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 03:42:18 -0000 On 21 May 2015 at 20:14, Dave Garrett wrote: > I should say instead that I have not seen a change nearly on the scale of= the SSL3 RFC. Those who were in the process of phasing out RC4 are still d= oing so at a comparable pace. Browsers were willing to accept breakage for = SSL3, but they're not yet ready for RC4. In comparison it appears to have h= ad less effect, at least so far. This will, of course, hopefully change. There is a big difference in the baseline in both cases. RC4 was about half of all TLS on the web before we decided to start killing it. You can't shift something like that quickly. From nobody Thu May 21 20:49:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5774F1A90BB for ; Thu, 21 May 2015 20:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 ESTcVeclpN_m for ; Thu, 21 May 2015 20:49:36 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61BB1A9096 for ; Thu, 21 May 2015 20:49:36 -0700 (PDT) Received: by oige141 with SMTP id e141so5210915oig.1 for ; Thu, 21 May 2015 20:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FRY4NnXJdl7FuCJtuQLzlMjjQ1efUFJ1hANlr7LblOU=; b=qhn5kPIg+XS+BlUo8kNoLahFUi3B4e/z+FJrHkSGORKkMM0/hRjPS0oLyCq7MAdiSS DyW7ndcLRR6zW/wFDEHcFq+KMOoyF8IrN9o9IUDzlfxb0EWks24zxKsl1/fP9Z+u4F9Y Qrw3dYMG0bnECmzeT9pxMaTZWmo7dZUsNRJlb+PmBoDUY1vYPPD3pp+u4m+kbz/qs5YL jl6Wf+rssonSu6zijVrvvr/um/FhEw9Lf5r0dODh5fTz81CI6rE2cMQi4ySleA+LwjB0 T3nLjSCfcFn954aT+5Q6mT3h1ifqaUFmb4iN72O+5/gVqEtQOSPRHhdOqeBYPtFZI+Sa 7xVQ== X-Received: by 10.60.157.202 with SMTP id wo10mr5075130oeb.20.1432266576217; Thu, 21 May 2015 20:49:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.25.198 with HTTP; Thu, 21 May 2015 20:49:15 -0700 (PDT) In-Reply-To: <201505212304.11513.davemgarrett@gmail.com> References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> From: Tony Arcieri Date: Thu, 21 May 2015 20:49:15 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7bd6c5e87fcdd50516a38cfa Archived-At: Cc: "" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 03:49:38 -0000 --047d7bd6c5e87fcdd50516a38cfa Content-Type: text/plain; charset=UTF-8 On Thu, May 21, 2015 at 8:04 PM, Dave Garrett wrote: > That said, the RC4 diediedie is getting largely ignored. To actually kill > something like this off, it seems to need to be done as a panic response or > as a requirement of something new that everyone starts together. (e.g. SSL3 > diediedie or old TLS with HTTP/2) Thus was my reasoning for at least > attempting to suggest it here. :| > I managed to get RC4 shut off at Square. The only real point of contention was Windows XP, which doesn't run a version of IE we support, so in the end it wasn't that much of an issue. SSL Labs overall statistics paint a pretty dismal picture for the Internet as a whole, but I think a lot of high profile sites have A or A+ ratings (i.e. they've disabled RC4) these days which is nice -- Tony Arcieri --047d7bd6c5e87fcdd50516a38cfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 21, 2015 at 8:04 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
That said, the RC4 diediedie is getting largely ignore= d. To actually kill something like this off, it seems to need to be done as= a panic response or as a requirement of something new that everyone starts= together. (e.g. SSL3 diediedie or old TLS with HTTP/2) Thus was my reasoni= ng for at least attempting to suggest it here. :|

I managed to get RC4 shut off at Square. The only= real point of contention was Windows XP, which doesn't run a version o= f IE we support, so in the end it wasn't that much of an issue.=C2=A0

SSL Labs overall statistics paint a pretty di= smal picture for the Internet as a whole, but I think a lot of high profile= sites have A or A+ ratings (i.e. they've disabled RC4) these days whic= h is nice

--
Tony Ar= cieri
--047d7bd6c5e87fcdd50516a38cfa-- From nobody Thu May 21 22:00:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E381A9116 for ; Thu, 21 May 2015 22:00:01 -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 RNCY4ynIcKNn for ; Thu, 21 May 2015 22:00:00 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDDD1A9100 for ; Thu, 21 May 2015 22:00:00 -0700 (PDT) Received: by qctt3 with SMTP id t3so3610148qct.1 for ; Thu, 21 May 2015 21:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=MIvJ+m8hgb9GCKkKt1vRSRcxuE3dcwfXIQ4Agj6tJC8=; b=GLZwbMiz7hIB2hpIbOfbGJDju14gDrSicpHiye/q5tL/+5sfoh/j6UBJrLPmMZVj95 sILM0KzHcFM4x78ySKuoalgipQ9RWb4HvGjzGlF2U5qFqDPAaTGUXir2LoVUiSW2kCw+ wWQ/beNeWivUP3hdRBdDkzPSUNcIFNzF1tqqL+pbz4QvUBcNRg/y1VXmr9MZu2kO2GvZ hYCKyyUb08RVMMfRez70mCPVsmjpO1zplkgZ2e5/ft/yk14fq34/x9v6atWWKCdJZFqk h3fEIc9miNhBADlSGCkQkXUYTNYimvML1Rck1NLNRpJ9Rx8BX+TTiTGcvCYNjZcLG9VC pqag== X-Received: by 10.229.224.202 with SMTP id ip10mr8989958qcb.14.1432270799416; Thu, 21 May 2015 21:59:59 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 67sm651683qhw.43.2015.05.21.21.59.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 21:59:58 -0700 (PDT) From: Dave Garrett To: Martin Thomson Date: Fri, 22 May 2015 00:59:57 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> <201505212314.57525.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505220059.57320.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 05:00:01 -0000 On Thursday, May 21, 2015 11:42:15 pm Martin Thomson wrote: > There is a big difference in the baseline in both cases. RC4 was > about half of all TLS on the web before we decided to start killing > it. You can't shift something like that quickly. I'm not disputing that change is hard and slow. I'm saying it's a lot more effective if heavily coordinated, which in this case means high-profile panic or baseline expectations of a new standard. I like the latter a lot more. ;) From nobody Thu May 21 22:25:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA651A9121 for ; Thu, 21 May 2015 22:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.802 X-Spam-Level: * X-Spam-Status: No, score=1.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 sNVP7WqP1Atm for ; Thu, 21 May 2015 22:25:42 -0700 (PDT) Received: from BAY004-OMC2S18.hotmail.com (bay004-omc2s18.hotmail.com [65.54.190.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599AA1A9120 for ; Thu, 21 May 2015 22:25:42 -0700 (PDT) Received: from BAY180-W75 ([65.54.190.123]) by BAY004-OMC2S18.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 21 May 2015 22:25:42 -0700 X-TMN: [gG61hqwFTjNpVUanVF2PIasW9L2v+ZwP] X-Originating-Email: [xiaoyin.l@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_aa565fa2-068e-4367-8096-bec5cfd1356b_" From: Xiaoyin Liu To: Aaron Zauner , Dave Garrett Date: Fri, 22 May 2015 01:25:41 -0400 Importance: Normal In-Reply-To: <20150522032029.GA24064@typhoon.azet.org> References: <201505211210.43060.davemgarrett@gmail.com>, <20150522025214.GA21141@typhoon.azet.org>, , <201505212304.11513.davemgarrett@gmail.com>, <20150522032029.GA24064@typhoon.azet.org> MIME-Version: 1.0 X-OriginalArrivalTime: 22 May 2015 05:25:42.0510 (UTC) FILETIME=[BF36A0E0:01D0944F] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 05:25:44 -0000 --_aa565fa2-068e-4367-8096-bec5cfd1356b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= Hi=2C Instead of prohibiting bad crypto on the server side=2C I would like to pro= pose a BCP which prohibits TLS 1.1- on the clients=2C but allows servers to= keep supporting TLS 1.0+. The simple reason is that we should allow normal= users to gradually upgrade their old browsers/operating systems=2C but sho= uld encourage (or require) webmasters to upgrade their servers as soon as p= ossible in order to protect their users' security and privacy. I believe ph= asing out insecure web technology should be promoted by browsers. Microsoft= 's plan to phase out SHA-1 certificates has been quite effective so far=2C = and I suggest we do the same for old TLS protocols and old cipher suites. =20 I do understand that=2C as many have pointed out=2C upgrading servers is no= t an easy task for some companies. But if not now=2C they have to be upgrad= ed sometime. Is 2-3 years enough for all servers to be upgraded? So what ab= out specifying the following in tls1-diediedie doc: 1) (Already required in RFC 7525) TLS servers MUST support TLS 1.3 (if TLS = 1.3 RFC has been published=2C otherwise TLS 1.2). 2) (Already required in RFC 7525) If ClientHello.client_version is 0x0303 (= TLS 1.2) or above=2C then TLS servers MUST negotiate that version.3) TLS se= rvers MAY support TLS 1.0 and TLS 1.1 to support old TLS clients. 4) (New requirement!) Starting from January 1=2C 2018=2C TLS clients MUST t= erminate the handshake if serverHello.server_version is 0x0302 (TLS 1.1) or= below.5) (New requirement!) Starting from January 1=2C 2018=2C TLS clients= MUST NOT include cipher suites that do not provide forward secrecy in the = ClientHello message.6) (Same as RFC 7525) The requirements above do not app= ly to opportunistic encryptions=2C like STARTTLS. The date specified in 4) = and 5) can be discussed later. It is important that all major browser vendo= rs agree to enforce 4) and 5) after this specific date=2C and that this dat= e is widely known by website operators. The goal of my proposal is to elimi= nate TLS 1.0-only and non-PFS TLS servers before the next decade. Best=2CXiaoyin=0A= = --_aa565fa2-068e-4367-8096-bec5cfd1356b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=0A= =0A= =0A=
Hi=2C

Instead of prohibiting bad crypto on the serv= er side=2C =3BI would like to propose a BCP which prohibits TLS 1.1- on= the clients=2C but allows servers to keep supporting TLS 1.0+. The simple = reason is that we should allow normal users to gradually upgrade their old = browsers/operating systems=2C but should encourage (or require) =3Bwebm= asters to upgrade their servers as soon as possible in order to protect the= ir users' security and privacy. =3BI believe phasing out =3Binsecur= e web technology should be =3Bpromoted by browsers. Microsoft's plan to= phase out SHA-1 certificates =3Bhas been quite effective so far=2C and= I suggest =3Bwe do the same =3Bfor =3Bold TLS protocols and ol= d cipher suites.
 =3B
I do understand that=2C as many have pointe= d out=2C upgrading servers is not an easy task for some companies. But if n= ot now=2C they have to be upgraded sometime. Is 2-3 years enough for all se= rvers to be upgraded? So what about specifying the following in tls1-diedie= die doc:

1) =3B(Already required in RFC 7525) TLS servers MUST s= upport TLS 1.3 (if TLS 1.3 RFC has been published=2C otherwise TLS 1.2).2) =3B(Already required in RFC 7525) If ClientHello.client_version is = 0x0303 (TLS 1.2) =3Bor above=2C then TLS servers MUST negotiate that ve= rsion.
3) =3BTLS servers MAY support TLS 1.0 and = TLS 1.1 to support old TLS clients.
4) (New requirement!) =3BStartin= g from =3BJanuary 1=2C 2018=2C TLS clients MUST terminate the handshake= if serverHello.server_version is =3B0x0302 (TLS 1.1) or below.
5) =3B(New requirement!) =3BStarting from =3BJan= uary 1=2C 2018=2C TLS clients MUST NOT include cipher suites that do not pr= ovide forward secrecy in the ClientHello message.
6)&= nbsp=3B(Same as RFC 7525) The =3Brequirements above do not apply to opp= ortunistic encryptions=2C like STARTTLS.
 =3B
The date specified in 4) and 5) can be discussed later. = It is important =3Bthat all major browser vendors agree to enforce 4) a= nd 5) after =3Bthis specific date=2C and that this date is widely known= by website operators. =3BThe goal of my proposal is to eliminate TLS 1= .0-only and =3Bnon-PFS TLS servers before the next decade.

Best= =2C
Xiaoyin
=0A=
= --_aa565fa2-068e-4367-8096-bec5cfd1356b_-- From nobody Thu May 21 23:18:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF38E1A9150 for ; Thu, 21 May 2015 23:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.802 X-Spam-Level: * X-Spam-Status: No, score=1.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 X6K96NFF3Njs for ; Thu, 21 May 2015 23:18:44 -0700 (PDT) Received: from BAY004-OMC4S24.hotmail.com (bay004-omc4s24.hotmail.com [65.54.190.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3CD1A00FA for ; Thu, 21 May 2015 23:18:44 -0700 (PDT) Received: from BAY180-W87 ([65.54.190.200]) by BAY004-OMC4S24.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 21 May 2015 23:18:44 -0700 X-TMN: [mtYknSGW1EMoX3TlxcNheBHVv8IV+0Uk] X-Originating-Email: [xiaoyin.l@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_e0c6f85e-baba-4e5c-940f-4f3954d7cdad_" From: Xiaoyin Liu To: Stephen Farrell , Roland Zink , "tls@ietf.org" Date: Fri, 22 May 2015 02:18:43 -0400 Importance: Normal In-Reply-To: <5542330A.3060605@cs.tcd.ie> References: <201504292035.21721.davemgarrett@gmail.com>, <5541E286.2090001@cs.tcd.ie> <5542303D.2080604@zinks.de>,<5542330A.3060605@cs.tcd.ie> MIME-Version: 1.0 X-OriginalArrivalTime: 22 May 2015 06:18:44.0611 (UTC) FILETIME=[27E4B530:01D09457] Archived-At: Subject: Re: [TLS] who do I poke to fix the URLs in the header? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 06:18:46 -0000 --_e0c6f85e-baba-4e5c-940f-4f3954d7cdad_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > On 30.04.2015 10:06=2C Stephen Farrell wrote: > >> Hi Dave=2C > >> > >> That brings in a bunch of things including tools=2C boilerplate > >> issues and policy stuff ("do we want an https-everything like > >> thing for the IETF?"). Good questions to ask though so I'll put > >> that on the IESG's agenda for some meetings we're having next > >> week. Please hassle me in 2-3 weeks if you don't hear something > >> back. > >> > >> Cheers=2C > >> S. > >> =20 Hi Stephen=2C =20 What's the result of the discussion in IESG on using HTTPS? =20 Best=2C Xiaoyin = --_e0c6f85e-baba-4e5c-940f-4f3954d7cdad_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B >=3B On 30.04.2015 10:0= 6=2C Stephen Farrell wrote:
>=3B >=3B>=3B Hi Dave=2C
>=3B >= =3B>=3B
>=3B >=3B>=3B That brings in a bunch of things including= tools=2C boilerplate
>=3B >=3B>=3B issues and policy stuff ("do w= e want an https-everything like
>=3B >=3B>=3B thing for the IETF?"= ). Good questions to ask though so I'll put
>=3B >=3B>=3B that on = the IESG's agenda for some meetings we're having next
>=3B >=3B>= =3B week. Please hassle me in 2-3 weeks if you don't hear something
>= =3B >=3B>=3B back.
>=3B >=3B>=3B
>=3B >=3B>=3B Cheers= =2C
>=3B >=3B>=3B S.
>=3B >=3B>=3B
 =3B
Hi Step= hen=2C
 =3B
What's the result of the discussion in IESG on using = HTTPS?
 =3B
Best=2C
Xiaoyin

= --_e0c6f85e-baba-4e5c-940f-4f3954d7cdad_-- From nobody Thu May 21 23:28:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0981A9172 for ; Thu, 21 May 2015 23:28:06 -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 K0fs68VuF-VL for ; Thu, 21 May 2015 23:28:05 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4371A0155 for ; Thu, 21 May 2015 23:28:04 -0700 (PDT) Received: by qcir1 with SMTP id r1so4095185qci.3 for ; Thu, 21 May 2015 23:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=QXklN0+yV1GIMjg+nPONHepEegF3vyQxGxG01LBkeUE=; b=WYtfRftQxJE3mSKFvDZwQJIL8/ay613FqINsqD3AvtFZYMa7fRzBxGyansqHEhldBZ /e2mE7ZbB1ffmt5x4Ecet4NVftVCKVBj0P7CsHYUkVSElADkMfEGfsR7u5WR0nAVP/lh 4gqWtQNsf3DagpfbMTtyFgA6SojF23qArtPYjv82brUfsDg5r6uQP/JLhEXi6dBi4bNH tXzw8CmirY5VoniGBo0CzaEHVrhQojWHAz53D4CTjQvzLuNv6d40D66IV5cmvL2rXZHa yEj/egC7ZCJSa82VAHPVFMrbMd03RyxghAfQtDeWW9IeHM9tzU0x5w8duHzaG9NA5F+9 syFg== X-Received: by 10.55.50.198 with SMTP id y189mr7639937qky.52.1432276082989; Thu, 21 May 2015 23:28:02 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id w73sm768155qkw.16.2015.05.21.23.28.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 23:28:02 -0700 (PDT) From: Dave Garrett To: Xiaoyin Liu Date: Fri, 22 May 2015 02:26:04 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> <20150522032029.GA24064@typhoon.azet.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505220226.04828.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 06:28:06 -0000 On Friday, May 22, 2015 01:25:41 am Xiaoyin Liu wrote: > 4) (New requirement!) Starting from January 1, 2018, TLS clients MUST terminate the handshake if serverHello.server_version is 0x0302 (TLS 1.1) or below. [snip] > The date specified in 4) and 5) can be discussed later. It is important that all major browser vendors agree to enforce 4) and 5) after this specific date, and that this date is widely known by website operators. The goal of my proposal is to eliminate TLS 1.0-only and non-PFS TLS servers before the next decade. I'd knock a year off that if possible, but yes, this is the other route that I would support... if it could actually be agreed to and enforced with a hardcoded time-check, not a human-flipped switch on the date. (humans are weak and squishy and liable to hesitate) (out of order quoting) > 5) (New requirement!) Starting from January 1, 2018, TLS clients MUST NOT include cipher suites that do not provide forward secrecy in the ClientHello message. I know the push back against dropping TLS 1.0 via the TLS 1.3 spec is strong, but just dropping non-FS might actually be relatively easy (in comparison). FS is available in TLS 1.0 and is relatively commonly supported overall (~65% of TLS servers & increasing at 1-2%/mo [0]). By the time TLS 1.3 is ready for final release, making FS totally mandatory might actually affect relatively few users. Giving servers a few months lead to reject before clients stopping to offer might make things go more smoothly. Dave [0] https://www.trustworthyinternet.org/ssl-pulse/ From nobody Fri May 22 00:42:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1671ACE4B for ; Fri, 22 May 2015 00:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.086 X-Spam-Level: X-Spam-Status: No, score=-4.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, HELO_EQ_DE=0.35, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-5, 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 TrcJq-vFzqa0 for ; Fri, 22 May 2015 00:42:43 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB411ACE46 for ; Fri, 22 May 2015 00:42:42 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 1B0462A674; Fri, 22 May 2015 09:42:41 +0200 (CEST) X-purgate-ID: 152705::1432280561-00000B48-200E14DA/0/0 X-purgate-size: 1453 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 0651F413CE; Fri, 22 May 2015 09:42:41 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id EF4501B31B; Fri, 22 May 2015 09:42:40 +0200 (CEST) In-Reply-To: <201505211920.22236.davemgarrett@gmail.com> To: Dave Garrett Date: Fri, 22 May 2015 09:42:40 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150522074240.EF4501B31B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "maray@microsoft.com" , "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 07:42:45 -0000 Dave Garrett wrote: > On Thursday, May 21, 2015 07:09:42 pm Yoav Nir wrote: >> Then point at the BCP. Only problem is that it doesn?t say what you want >> it to say (it allows TLS 1.0 when the client does not support anything else) > > In my first post I said that I don't propose changing anything for existing > deployments. The BCP is currently a "SHOULD NOT" for current TLS. > I'm proposing a "MUST NOT" for TLS 1.3+ implementations only. > > The BCP is also not directly part of the TLS spec. What I'm suggesting is > considering 1.0/1.1 to be not legitimate forever, not just not "best". All current "recommendations" against TLSv1.0 and TLSv1.1 are well-known FUD. The difference between TLSv1.0 with 1/(n-1) record splitting and TLSv1.1 is cryptographically insignificant and the security of TLSv1.2 is lower than both of its precedessors (e.g. throug the botched TLS signature extension and the dumb idea to replace the md5+sha1 signatures with sha1-only signatures for RSA certificates. For the mandatory to implement TLSv1.2 cipher suite, TLSv1.0 and TLSv1.1 are just fine. AEAD cipher suites are not part of TLSv1.2, they're a mere optional add-on that is artificially limited to TLSv1.2, and a number of TLSv1.2 implementations do not support AEAD cipher suites. Same for Elliptic Curve. It's optional, and to date, it is not even standards track. Many TLS implementations do implement EC. -Martin From nobody Fri May 22 01:29:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93BD1ACE9A for ; Fri, 22 May 2015 01:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdDrTjWzDYJn for ; Fri, 22 May 2015 01:29:07 -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 1618A1ACEFB for ; Fri, 22 May 2015 01:29:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 456A0BEF6; Fri, 22 May 2015 09:29:05 +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 0rlm9I20bfA3; Fri, 22 May 2015 09:29:04 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.24.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2E358BEEB; Fri, 22 May 2015 09:29:04 +0100 (IST) Message-ID: <555EE8CF.3020900@cs.tcd.ie> Date: Fri, 22 May 2015 09:29:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Xiaoyin Liu , Roland Zink , "tls@ietf.org" References: <201504292035.21721.davemgarrett@gmail.com>, <5541E286.2090001@cs.tcd.ie> <5542303D.2080604@zinks.de>, <5542330A.3060605@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] who do I poke to fix the URLs in the header? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 08:29:09 -0000 On 22/05/15 07:18, Xiaoyin Liu wrote: >>> On 30.04.2015 10:06, Stephen Farrell wrote: >>>> Hi Dave, >>>> >>>> That brings in a bunch of things including tools, boilerplate >>>> issues and policy stuff ("do we want an https-everything like >>>> thing for the IETF?"). Good questions to ask though so I'll put >>>> that on the IESG's agenda for some meetings we're having next >>>> week. Please hassle me in 2-3 weeks if you don't hear something >>>> back. >>>> >>>> Cheers, >>>> S. >>>> > > Hi Stephen, > > What's the result of the discussion in IESG on using HTTPS? Nearly done, hopefully done in a week or two - just wordsmithing needed but I hope folks on here will be happy with what the IESG will suggest. (And will be patient in the meantime, pretty please:-) S. > > Best, > Xiaoyin > > > From nobody Fri May 22 03:44:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4062D1ACCC7 for ; Fri, 22 May 2015 03:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.446 X-Spam-Level: X-Spam-Status: No, score=-4.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX2MxCtqmRqk for ; Fri, 22 May 2015 03:44:19 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FA81AC44D for ; Fri, 22 May 2015 03:44:19 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 2D6348EAFB; Fri, 22 May 2015 10:44:19 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-78.ams2.redhat.com [10.36.112.78]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4MAiEAZ020098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2015 06:44:18 -0400 From: Hubert Kario To: tls@ietf.org, mrex@sap.com Date: Fri, 22 May 2015 12:44:07 +0200 Message-ID: <2753681.QX1IYUOEOG@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/3.19.7-200.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <20150522074240.EF4501B31B@ld9781.wdf.sap.corp> References: <20150522074240.EF4501B31B@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2246019.jq7YIAUCfe"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "maray@microsoft.com" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 10:44:21 -0000 --nextPart2246019.jq7YIAUCfe Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 22 May 2015 09:42:40 Martin Rex wrote: > Dave Garrett wrote: > > On Thursday, May 21, 2015 07:09:42 pm Yoav Nir wrote: > >> Then point at the BCP. Only problem is that it doesn?t say what yo= u want > >> it to say (it allows TLS 1.0 when the client does not support anyt= hing > >> else)>=20 > > In my first post I said that I don't propose changing anything for > > existing > > deployments. The BCP is currently a "SHOULD NOT" for current TLS. > > I'm proposing a "MUST NOT" for TLS 1.3+ implementations only. > >=20 > > The BCP is also not directly part of the TLS spec. What I'm suggest= ing is > > considering 1.0/1.1 to be not legitimate forever, not just not "bes= t". >=20 > All current "recommendations" against TLSv1.0 and TLSv1.1 are well-kn= own > FUD. >=20 > The difference between TLSv1.0 with 1/(n-1) record splitting and > TLSv1.1 is cryptographically insignificant and the security of > TLSv1.2 is lower than both of its precedessors (e.g. throug the > botched TLS signature extension and the dumb idea to replace > the md5+sha1 signatures with sha1-only signatures for RSA certificate= s. schannel, OpenSSL, NSS and GnuTLS will use at least sha256 if only give= n=20 chance yes, clients should not be advertising support for sha-1, but it's not = an end=20 of the world scenario just yet =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2246019.jq7YIAUCfe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVXwh9AAoJEJKo0bgB0vX1CRUP+wazM2Y9M6boP8jOqatUFrQH gUYbog6JeI3x975e13V62m+sTNdffZuqQGxP43VNLCPpyk7ysjSwJdJS5aqTcI/i yVmfwY/DyuaNUkxNpoA/ExmqG5QLgWiVrnD/seGCYLkphC8fijORyZf6fo2JvSbb VaMKWdzsOaDhBZq3OWxU8M8Aaq7Ao4X+cuvAHRstVpgBvB3zanmAALaB7GlMoU1c n9dD05VGJs3ary/+9DOpK9BjOew+MccG0vNsaxOKiD7kfSKo4noUeBIwKcCo5Fkb OGaThsidVBaRP2546bMsPK0rDkHZr5ygZQK8kXQVVwHHCuPgH4kmjrIvbXzSBeQy igYs4bgJhNtBCKssvf+V14tt6Z85YbBCL8j1N2JiaAn+v5/uTUDOGOdLKZiGC6ne 1Sf281cEmHWIIwWp11eKG2MYl8CVLnnNfj0Imb63V42yx0p70tnc6V+0ANU2tUb8 ncuRbAJpXAdwRZqdUgmavVAK0ABfnkVR7TuVU2G7fy6nvLvdelHfJ03r0JRbQtbk 1rzQ9rZ62w8qSwPeyq6odgy1wdMA5Z5RHk729Vrsijf3Qdh0wASz7B4iRbM/YYRr GU37Q7yi/0nwd3JH2Deul5hwVKNO8MEa5IB8Jjo3SnhikqIp/jLDG6AacrOJ3ntw tOmopqui8FvU9HwqbgK0 =A/IL -----END PGP SIGNATURE----- --nextPart2246019.jq7YIAUCfe-- From nobody Fri May 22 05:31:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675231AD0B9 for ; Fri, 22 May 2015 05:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5NAROhebkNz for ; Fri, 22 May 2015 05:31:13 -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 833FB1A8841 for ; Fri, 22 May 2015 05:31:12 -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=1432297873; x=1463833873; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oenYCDu9YUTpD18P8XLJaYMofoeLS4ybZ1uk1XJMPZI=; b=RgU5bawBKCpiDJEGpQ7PvBpANsjxEU4vK3O99Q2RBPDc2XtvVMPnP3S9 +9tpgfrA8sToXF0wZo/84ZFI4X3R8Zf1y3+FkiTBRv4d8XE7XHEeZtdE9 BLYeXUXfXuAOH10n7JZRJ1lZk/jFJEHGv3YMe4SqQY+W+2Z2Nd3nBuE6j Yxsdcv5ev45t0IXR9maIQjhChtLkrmVmJKV+ov8EBCAtK26zgdItWtUjR v/CbeLN5WMveWsm3PR+XdhJ7blry4j5qIjb63dNXodSeXkFxtUgwIxuYd 7B3ppfNeoCuKqqWG2YLcEyqww/x1N1nw48244nu7YFgNkKirnFlsnWuhX w==; X-IronPort-AV: E=Sophos; i="5.13,475,1427713200"; d="scan'208,217"; a="17631896" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 23 May 2015 00:30:50 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sat, 23 May 2015 00:30:50 +1200 From: Peter Gutmann To: Xiaoyin Liu , Aaron Zauner , "Dave Garrett" Thread-Topic: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) Thread-Index: AQHQlE/GnDxRvcYJ+0+XbJbLEeqxK52H7UxQ Date: Fri, 22 May 2015 12:30:49 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz> References: <201505211210.43060.davemgarrett@gmail.com>, <20150522025214.GA21141@typhoon.azet.org>, , <201505212304.11513.davemgarrett@gmail.com>, <20150522032029.GA24064@typhoon.azet.org>, In-Reply-To: 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: multipart/alternative; boundary="_000_9A043F3CF02CD34C8E74AC1594475C73AB029584uxcn10tdc05UoAa_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 12:31:18 -0000 --_000_9A043F3CF02CD34C8E74AC1594475C73AB029584uxcn10tdc05UoAa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Xiaoyin Liu writes: >The simple reason is that we should allow normal users to gradually upgrad= e >their old browsers/operating systems, but should encourage (or require) >webmasters to upgrade their servers as soon as possible in order to protec= t >their users' security and privacy. This comment again shows the rather myopic browser-centered view of TLS tha= t I've complained about in the past. For most of the users of TLS that I wor= k with, there is no browser, no OS upgrade, and no web. TLS is used for machine-to-machine communications, with no human intervention. You know th= e PLC I used as an example in an earlier message, the one that rejects any attempt at connecting with a version number set to greater than TLS 1.0? T= he "upgrade" procedure for that is to replace it when the hardware dies, with = a minimum (minimum, not maximum) lifetime of around ten years (I've seen refridgerator-sized PLCs dating from the 1960s still in active use today, b= ut that's because they're practically indestructible compared to modern versions). So if some sort of BCP is published, it should explicitly target browsers a= nd web servers where this kind of upgrade/change is possible. Telling people = to throw away their PLCs and replace them with new ones isn't going to fly. Peter. --_000_9A043F3CF02CD34C8E74AC1594475C73AB029584uxcn10tdc05UoAa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Xiaoyin Liu <xiaoyin.l@outlook.com> writes:

>The simple reason is that w= e should allow normal users to gradually upgrade
>their old browsers/operating systems, but should encourage (or require)=
>webmasters to upgrade their servers as soon as possible in order to pro= tect
>their users' security and privacy.

This comment again shows the rather myopic browser-centered view of TLS tha= t
I've complained about in the past.  For most of the users of TLS that = I work
with, there is no browser, no OS upgrade, and no web.  TLS is used for=
machine-to-machine communications, with no human intervention.  You kn= ow the
PLC I used as an example in an earlier message, the one that rejects any attempt at connecting with a version number set to greater than TLS 1.0?&nb= sp; The
"upgrade" procedure for that is to replace it when the hardware d= ies, with a
minimum (minimum, not maximum) lifetime of around ten years (I've seen
refridgerator-sized PLCs dating from the 1960s still in active use today, b= ut
that's because they're practically indestructible compared to modern
versions).

So if some sort of BCP is published, it should explicitly target browsers a= nd
web servers where this kind of upgrade/change is possible.  Telling pe= ople to
throw away their PLCs and replace them with new ones isn't going to fly.
Peter.

--_000_9A043F3CF02CD34C8E74AC1594475C73AB029584uxcn10tdc05UoAa_-- From nobody Fri May 22 06:16:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079D91B2BC2 for ; Fri, 22 May 2015 06:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wQ02-o0BeiXK for ; Fri, 22 May 2015 06:16:37 -0700 (PDT) Received: from BAY004-OMC3S28.hotmail.com (bay004-omc3s28.hotmail.com [65.54.190.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB9F1B2BB8 for ; Fri, 22 May 2015 06:16:37 -0700 (PDT) Received: from BAY180-W65 ([65.54.190.187]) by BAY004-OMC3S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 22 May 2015 06:16:37 -0700 X-TMN: [WPVmCGVcSC723X4e6Z6nodpS6flWNFQ3] X-Originating-Email: [xiaoyin.l@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_4d660015-7d32-4216-918a-2d76a3135080_" From: Xiaoyin Liu To: "tls@ietf.org" Date: Fri, 22 May 2015 09:16:37 -0400 Importance: Normal In-Reply-To: References: <201505211210.43060.davemgarrett@gmail.com>, , <20150522025214.GA21141@typhoon.azet.org>, , , , <201505212304.11513.davemgarrett@gmail.com>, , <20150522032029.GA24064@typhoon.azet.org>, , <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz>, MIME-Version: 1.0 X-OriginalArrivalTime: 22 May 2015 13:16:37.0759 (UTC) FILETIME=[88A778F0:01D09491] Archived-At: Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 13:16:39 -0000 --_4d660015-7d32-4216-918a-2d76a3135080_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: pgut001@cs.auckland.ac.nz To: xiaoyin.l@outlook.com=3B azet@azet.org=3B davemgarrett@gmail.com CC: tls@ietf.org Subject: RE: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohi= bit <1.2 support on 1.3+ servers (but allow clients)) Date: Fri=2C 22 May 2015 12:30:49 +0000 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= >So if some sort of BCP is published=2C it should explicitly target browser= s and =0A= >web servers where this kind of upgrade/change is possible. Telling people= to =0A= >throw away their PLCs and replace them with new ones isn't going to fly. =0A= Agreed! Xiaoyin=0A= = --_4d660015-7d32-4216-918a-2d76a3135080_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
From: pgut001@cs.auckland.ac.nz
To: xiaoyin.l@outlook.com=3B = azet@azet.org=3B davemgarrett@gmail.com
CC: tls@ietf.org
Subject: RE:= [TLS] prohibit <=3B1.2 on clients (but allow servers) (was: prohibit <= =3B1.2 support on 1.3+ servers (but allow clients))
Date: Fri=2C 22 May = 2015 12:30:49 +0000
=0A= =0A= =0A=

=0A= =0A= =0A=
=0A= =0A= >=3BSo if some sort of BCP is published=2C it should explicitly target br= owsers and
=0A= >=3Bweb servers where this kind of upgrade/change is possible. =3B Te= lling people to
=0A= >=3Bthrow away their PLCs and replace them with new ones isn't going to f= ly.
=0A=
 =3B
Agreed!
 =3B
Xiaoyin
=0A=
= --_4d660015-7d32-4216-918a-2d76a3135080_-- From nobody Fri May 22 07:55:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9199D1A070E for ; Fri, 22 May 2015 07:55:00 -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 6S2HLpjCgwoe for ; Fri, 22 May 2015 07:54:59 -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 A0A411A039D for ; Fri, 22 May 2015 07:54:58 -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=1432306498; x=1463842498; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=YzdvMPqOh0zXT50Enw4tP0+OS/0+FW3XCSZUt9ky3ik=; b=HuUWYIIg82GLUzfq3kJoFrS6sgAq59FtdqFtDM0Kg186K/1ckG8xHd7L waPKbnGewK3BiI2woRX1BC2gnYEL7HsjX0Dz0TMH8Pgl70+9UwolHZGD7 2qUlviCZ6IU2vKrhpXrJG65pn8ClRBoeV9UmFqtkDzhch6HmnHvaawMAY oKtC6HcgmdlX2n9LvaUAJahup5jAr6FLc+JxD10yR3F8WRn3AlzjToIMa YsgHhAy2WnP3A2rMk8WxfhV9JPtOP8mXuOy9G9RYsSKqVGRDJzvFjp2fL EhCvuKCyM7+Qen7tlcq99Eg0mrRzeIag+LeX9HA1XuOLtuxv8tgcqZDVg Q==; X-IronPort-AV: E=Sophos;i="5.13,475,1427713200"; d="scan'208";a="17643881" 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; 23 May 2015 02:54:54 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sat, 23 May 2015 02:54:54 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AdCUn0KvC4ozoUHOQIKcwi120/Yv8A== Date: Fri, 22 May 2015 14:54:53 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> 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: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:55:00 -0000 Santiago Zanella-Beguelin writes:=0A= =0A= >Regarding validation of DHE parameters and how reasonable it is in practic= e,=0A= >I wanted to make some publicity for miTLS (http://www.mitls.org/).=0A= >=0A= >A miTLS client maintains a table of known trusted parameters, including th= e=0A= >subgroup order for parameters with non-safe primes. When receiving unknown= =0A= >parameters from a server, it tests the primality of p and (p-1)/2 to check= if=0A= >p is a safe prime (and caches a positive result in the table). =0A= =0A= So you do a full primality test (Miller-Rabin or whatever) for each connect= ?=0A= Doesn't that make it awfully slow?=0A= =0A= >If the modulus is prime but not safe, miTLS checks if it is in the table o= f=0A= >trusted parameters and otherwise rejects it. We distribute miTLS with a pr= e-=0A= >populated table of parameters which we tested thoroughly (and we welcome= =0A= >people to test further). Most of the time we hit an entry in the table.=0A= =0A= What testing do you do on unsafe primes?=0A= =0A= Peter.=0A= From nobody Fri May 22 08:18:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4741A005B for ; Fri, 22 May 2015 08:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_20=-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 RWHBMf8P94Kd for ; Fri, 22 May 2015 08:18:26 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6E58D1A002F for ; Fri, 22 May 2015 08:18:26 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BBA661662BE; Fri, 22 May 2015 15:18:25 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id B08E91662BD; Fri, 22 May 2015 15:18:25 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id AD54D1E07C; Fri, 22 May 2015 15:18: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; Fri, 22 May 2015 10:18:25 -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; Fri, 22 May 2015 10:18:25 -0500 From: "Salz, Rich" To: Yoav Nir , Dave Garrett Thread-Topic: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) Thread-Index: AQHQk+496B6kvrhzHU2GmzOhMDXH0Z2HjG8w Date: Fri, 22 May 2015 15:18:24 +0000 Message-ID: <48400b36b52047fa90740696889f76a6@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <201505211210.43060.davemgarrett@gmail.com> <38D583BF-DFD0-4EFF-83D7-33FB3E2507D7@gmail.com> In-Reply-To: <38D583BF-DFD0-4EFF-83D7-33FB3E2507D7@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.153.219] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 15:18:28 -0000 PiBJdCBiZWxvbmdzIGluIGEgQkNQLCBub3QgaW4gdGhlIHByb3RvY29sIGRvY3VtZW50DQoNClll YWgsIGFuZCBub3QgZXZlbiB0aGVyZS4NCg0KVW5sZXNzIHlvdSBhcmVhIHJlYWxseSBzYXlpbmcg dGhhdCBpZiBJIGhhdmUgYSBzZXJ2ZXIgdGhhdCBkb2VzIFRMUyAxLjMsIGl0IGNhbm5vdCB0YWxr IHRvIGFueSBjdXJyZW50bHktZGVwbG95ZWQgY2xpZW50PyAgWXVrLg0K From nobody Fri May 22 08:38:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907BE1A0276 for ; Fri, 22 May 2015 08:38:18 -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 iKOTS0OflR4r for ; Fri, 22 May 2015 08:38:17 -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 6F9871A00B5 for ; Fri, 22 May 2015 08:38:17 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 934C548E0E; Fri, 22 May 2015 15:38:16 +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 87F0648E09; Fri, 22 May 2015 15:38:16 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 84D0F9803E; Fri, 22 May 2015 15:38:16 +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; Fri, 22 May 2015 10:38:16 -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; Fri, 22 May 2015 10:38:15 -0500 From: "Salz, Rich" To: Dave Garrett Thread-Topic: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) Thread-Index: AQHQlAmVsLT2vbjz/0+qbN8DwEJEc52HQYwAgADgbGA= Date: Fri, 22 May 2015 15:38:14 +0000 Message-ID: References: <201505211210.43060.davemgarrett@gmail.com> <20150521210317.GA23925@roeckx.be> <201505211712.55279.davemgarrett@gmail.com> In-Reply-To: <201505211712.55279.davemgarrett@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.153.219] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 15:38:18 -0000 > > So everybody can already disable TLS 1.0 and 1.1 now, right? All > > clients have already been updated. >=20 > More than enough, as far as I'm concerned. Really? 10% of the traffic we see doesn't have SNI. Most of the net doe= sn't support IPv6. /r$ From nobody Fri May 22 09:03:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D701A1BB4 for ; Fri, 22 May 2015 09:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 EnfY27izmW7c for ; Fri, 22 May 2015 09:03:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0171D1A1B6A for ; Fri, 22 May 2015 09:03:09 -0700 (PDT) Received: from BN1AFFO11FD029.protection.gbl (10.58.52.31) by BN1AFFO11HUB025.protection.gbl (10.58.52.135) with Microsoft SMTP Server (TLS) id 15.1.172.14; Fri, 22 May 2015 16:02:50 +0000 Authentication-Results: spf=pass (sender IP is 198.105.204.3) smtp.mailfrom=five9.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of five9.com designates 198.105.204.3 as permitted sender) receiver=protection.outlook.com; client-ip=198.105.204.3; helo=mx02.five9.com; Received: from mx02.five9.com (198.105.204.3) by BN1AFFO11FD029.mail.protection.outlook.com (10.58.52.184) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Fri, 22 May 2015 16:02:49 +0000 Received: from MB01.five9.com (10.7.8.141) by mx02.five9.com (10.7.15.112) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 May 2015 09:02:13 -0700 Received: from MB03.five9.com ([fe80::4d18:3a9c:2936:eea8]) by mb01.five9.com ([fe80::ddc6:159a:f53:8ee7%15]) with mapi id 14.03.0158.001; Fri, 22 May 2015 09:02:48 -0700 From: Ronald del Rosario To: Dave Garrett , "tls@ietf.org" Thread-Topic: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) Thread-Index: AQHQlB34iwHhmYkn6E+VKKHqxEVpQp2HwbwAgAABJQCAAAIvgIAAZCqA Date: Fri, 22 May 2015 16:02:46 +0000 Message-ID: References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> In-Reply-To: <201505212304.11513.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 x-originating-ip: [10.7.8.130] Content-Type: multipart/alternative; boundary="_000_D184A0B122B7Frrosariofive9com_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD029; 1:P79x3PFEnVViM4e45Irf4GMPFLTr7FMW8mT+7hZ9qjZCe59u1j16lay4Yd/oLAiDfZxYb4lV6XuFy91kP+yFYPUqzRuSbaQYNGYuyoXTedZE3GjTyv7oEkdDOicIZjuDtZQllMEfm4U1p2sR7c18B3n/a2XQXFYOYVk+EmFdceILcLOuKjfjcGQHEFo8W3iN1Gkh88o8FMpO/EjAThh8sxPzrjBA4wnXMo+gb/EUNCKgUSTdKfSAk3537w2oNoZwx2VAgwJjxmaGasb84r8GDgnk4TS/QELtsfJW+xxxMO+WCou2dn9ZLvrVTkQWJMVh X-Forefront-Antispam-Report: CIP:198.105.204.3; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(189002)(377454003)(199003)(24454002)(2950100001)(102836002)(2900100001)(15975445007)(86362001)(50986999)(54356999)(76176999)(16236675004)(512944002)(5890100001)(2501003)(5250100002)(93886004)(19617315012)(53416004)(36756003)(64706001)(5001860100001)(5001830100001)(5001770100001)(106466001)(106116001)(30436002)(189998001)(19580395003)(19580405001)(62966003)(77156002)(107886002)(5001970100001)(4001540100001)(4001350100001)(84326002)(83506001)(92566002)(46102003)(6806004)(2656002)(4546004)(87936001)(7099028)(85436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB025; H:mx02.five9.com; FPR:; SPF:Pass; PTR:mx02.five9.com; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB025; 2:60tAEJBAYg0b4z7kk4YggLXEraolgxVWmyjItFP4zYQrv9SeZTcMY1oQDLZwBkDh; 2:hpdmjX8CpBzh/Pg20Y7m8QuPgW5uE/ovF5XedIckvIHLpMinvNpJTAGUP5+2gB4R1jBb0YGE1CuH0jeLVLCYZyBy2YlD/E5yPmMXqhn/2MSopFU/ZTGd9noHDfvwtclkCkI0koOkErz403wuov/X17noaina4uQCfkYRuBw+Z7t1BQbtHlM37l0ZrQdIRoWw3Zw0UKtF/dP1vFeXvcSz2d7qJJPRtuRqW5IzgnG9aZ8=; 6:1pp/XpyXjM0n3SttqdSY9y3SZTMR0xoGCaPhb/rfjsROQPOQ7gVfKbFk5rgzefoiR2vJci3/vo4feNa3UWS2LIuZi9+nuKTH59bZAVLoUBgfGQCUub7NbdUrrbvs+Stqs9qcwz24vfX8PdmgutmNwdAFyYgD9wuzQSxYP/5Ximpvu8zrmdGZBaAwS8BKXFyqQOIMiPfDZbLey243f4OQfaTmFSUw+SgZ5QXl52ZxxVQCfEP/d0l1Qd0CO0W+Y7rwJaNmG+pkHXadn6nTWjZTZnhklG5HAVWn1n1oDx4bz6oEZuxFCdQn1trLQnrUi1aMFJG6ssl+mpFCf3pdr69rQA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB025; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520002)(5005006)(3002001); SRVR:BN1AFFO11HUB025; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB025; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB025; 3:nOUXSe1GmJXxRBgvLr9F8XUnwnqL87j/z5xRYtfxIU8YcAc9NdftswDDeqK0nBSIg2kKf9g6decTAVj2Kinxa6NxSOAPjK5sUUpqnTUlTEhi5245oSMPQGQe4Hs0fA5IICKPMlemtOw1Gm+g83BV4C8JjL9N9OMEvPjwW84mIJx0nKCO0c6E8Eci50P8kp+Ne/S+gpYQj5q8J0KkDhA+N8StZuYa1TsIYm9m1+qsN5hflqCJodiEdtQraGmRM4/YhFXMKZAldX8m/x71dsLq4UZzTS5xEz2mDsWb/JVjJS3ugbYHtUYMbQOpqJ+MkL72 X-Forefront-PRVS: 058441C12A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB025; 9:IPSFYremtAhXQjeQD4UuCtALDPD88WAKqsg4IqER?= =?us-ascii?Q?L8PUbsOiYeiEPPLlKWEYi6VG9hPIMaBJIW6FBl5VUhgurJNQS9+JgtlxKnoS?= =?us-ascii?Q?fxf9b7+UcoPhMIdFYMC/IkP0BRk6tSXmDFIk/hVa0gulkdsO58lRjNQmMX7c?= =?us-ascii?Q?76ks0jgqmKsTuCdNR/p6kMPSxjhZbXXy0QXl08KlvETNBhhl8rFVKqv4A1fK?= =?us-ascii?Q?ksmcVOq5t++IA+dwy63tkZ01zDIcRMXbE3vpQLFxuzdTEDNzXXXwjHD2vRfo?= =?us-ascii?Q?y5zB0tToO6Ua3upXWZy+uS0TMX53HnMLIQe8+XouECM+bLx+yPeyrTnDjv3n?= =?us-ascii?Q?JYkowQVvW/dic+L1ik3TBZCxNnqmRGK2+WAQhSpWDbs3sVYV4Ce4a5VAwABY?= =?us-ascii?Q?d1eGuMzmJeHLG2MvDTHBIl1tlYo5Q9kMOyuJ21bJUZPn+mJMXHqe88tSyfeS?= =?us-ascii?Q?ENF94y5cqvT9X8JiqG6IfOWyRj4ys8igY92yvJSnPQdhcVWR5jEJmmd6vBf4?= =?us-ascii?Q?6FFA8vQuK4+64kwLUt6PZs6PQEzwAwNiySnPfex2n3jLi4cMKCVgT4CyAmr6?= =?us-ascii?Q?tDgV3jKNkUPk2LCxJbOc9SneE15QGsHFF4jKd7AHr9oXuYUPUI+idOKVFMlO?= =?us-ascii?Q?EVuy+0Ond9hmaT7dyvIpJufr8Zfy+gYtS5qQo7B5EC5FNADbSLaHLTX+Kb6x?= =?us-ascii?Q?1y2UViIi2QLGL8rg2aKI2mnTb8HAgv7o82lR+iUJbsj0QapfxwsWWnUQgw+z?= =?us-ascii?Q?BhiB9iob5EGqidu/faOA0XxFY0aFvnK8DYAZmkR1ampi2g2WkFexv65hOUjP?= =?us-ascii?Q?Bybv1KVLsyPzNHMm1P0c/UHftf0FN4q1+aGOhwkmXsEmKhz87iBzO3QWcnNq?= =?us-ascii?Q?4W6dBUtOZZTx02xLkmGDE+WlHy44ohBBLTCzpGkAHkUc9sqFK7Yde8Rl1iGu?= =?us-ascii?Q?99wO6anSPyGc8XRQX16J73d/OHRwLONMLasjEpPiZQzHGcsUdNyU+EBWg7Ik?= =?us-ascii?Q?6v1acMhvf4g3mvVLX4DTmSPnqUtgEGYAvXZz6hx9g4kXUsMspvqHaKtX+BIx?= =?us-ascii?Q?Zf2w+IOKT/Q1gEI+kG6gt+FNx44IpkxCv/ZFqqtfqZMEqG6KJTAuavkBDvaV?= =?us-ascii?Q?LAFdfKXYJHIfKUicyI5//ffgAKQlHASk8I1uXu/3IWyOQMXqY25EPEuvuk9r?= =?us-ascii?Q?dX30xQftVsxJzZymUR/S91TQWdPlTZLX4+1XZoHU9Np3JSOk1fGEiH+NNuow?= =?us-ascii?Q?aJPQ4HVOc+6xME5nmAO1GLTtZegPcg0JNicrvtCm?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB025; 3:z4TcWxJpnTsr7ugdMbdEgdszgGPI19vs9wRLnw9SE7Cm1lTr25vHuK3YRuXCa8RUS6FTHVfIHa5dfmURGXmD54Fje43Jmdu1bHecGj9m/yaCv/v6yT+jOO8bnd6d+5B/0+1wTNhfG3AHXhCQXNYa+Q==; 10:++3+u4JYx1wuK6qfRGauxAfiAX9nz9WzrDsOwDLvc7qFW1Ay+zDZJ/gVdUvStf0P6gWZbzj6R8Neou4rJgXrep7JgZURep4yhQyTfNa1dtU= X-OriginatorOrg: five9.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2015 16:02:49.5542 (UTC) X-MS-Exchange-CrossTenant-Id: 91df0123-f1fa-4e71-852c-e6bdacd1a9a1 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=91df0123-f1fa-4e71-852c-e6bdacd1a9a1; Ip=[198.105.204.3]; Helo=[mx02.five9.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB025 Archived-At: Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 16:03:12 -0000 --_000_D184A0B122B7Frrosariofive9com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 on diediedocuments Maybe it needs a =93dedicated website + cool logo=94 ala heartbleed, FREAK,= etc. to get noticed :-) Ron del Rosario | @guerilla7 From: Dave Garrett > Date: Thursday, May 21, 2015 at 8:04 PM To: "tls@ietf.org" > Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients= ) On Thursday, May 21, 2015 10:56:22 pm Tony Arcieri wrote: On Thu, May 21, 2015 at 7:52 PM, Aaron Zauner > wrote: > So how about that TLSv1-diediedie document? :) I am very much +1 for more diediedie documents ;) I'm certainly not going to argue against that. ;) That said, the RC4 diediedie is getting largely ignored. To actually kill s= omething like this off, it seems to need to be done as a panic response or = as a requirement of something new that everyone starts together. (e.g. SSL3= diediedie or old TLS with HTTP/2) Thus was my reasoning for at least attem= pting to suggest it here. :| Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . --_000_D184A0B122B7Frrosariofive9com_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
+1 on diediedocuments

Maybe it needs a =93dedicated website + cool logo=94 ala heartblee= d, FREAK, etc. to get noticed :-)

Ron del Rosario | @guerilla7

From: Dave Garrett <davemgarrett@gmail.com>
Date: Thursday, May 21, 2015 at 8:0= 4 PM
To: "tls@ietf.org" <tls@ietf.= org>
Subject: Re: [TLS] prohibit <1.2= support on 1.3+ servers (but allow clients)

On Thursday, May 21, 2015 10:56:22 pm Tony Arcieri wrote:
On Thu, May 21, 2015 at 7:52 PM, Aaron Zauner <azet@azet.org> wrote:
> So how about that TLSv1-diediedie document? :)
I am very much +1 for more diediedie documents ;)

I'm certainly not going to argue against that. ;)

That said, the RC4 diediedie is getting largely ignored. To actually k= ill something like this off, it seems to need to be done as a panic respons= e or as a requirement of something new that everyone starts together. (e.g.= SSL3 diediedie or old TLS with HTTP/2) Thus was my reasoning for at least attempting to suggest it here. = :|


Dave

_______________________________________________
TLS mailing list



CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are= not the intended recipient, please notify the sender immediately, destroy = the original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the information in any medium. Copyright= in this e-mail and any attachments belongs to Five9 and/or its affiliated = entities.
--_000_D184A0B122B7Frrosariofive9com_-- From nobody Fri May 22 09:36:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6536A1A1B4B for ; Fri, 22 May 2015 09:36:38 -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 4YDvs99JPG5R for ; Fri, 22 May 2015 09:36:37 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF071A1B7C for ; Fri, 22 May 2015 09:36:36 -0700 (PDT) Received: by qgfa63 with SMTP id a63so11437372qgf.0 for ; Fri, 22 May 2015 09:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=yJnnuw4bt+WWS6jqoBDotOuAdx940BprfGUONtLR6Fk=; b=n60+FHj/PUbNFdeq29LNyRiyYF6s4RX99sZ0uIYjHtOM2Z19OutC5qdqm133g3tK1F WWVjH5nC+/CbrXQtH6o7VH0lnIlwoprGSrtNLSK4AnbGkAwGW9ofJSlxc4BGd5H9afv1 nWjj89tWgcaTQ0wVzL+bZft7TXxwv0oye+ZLHVVyolD1dI79lNOT1tyVzFAWoWrSstLi m0QOgZTMBT7M9irt2Dzm1ecjxaWL8cfo07wXZEw4CX/n+yJ4fGfpizzRSFlFb4cgyBF2 ka4wRT3FRz1E+AuGEzWKzx2paoaPd7jpBANEkZo372zDZDdeLDVrKFxmy7Q1po5/rL+F hEog== X-Received: by 10.55.15.129 with SMTP id 1mr20201061qkp.29.1432312596069; Fri, 22 May 2015 09:36:36 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b5sm1602669qkh.36.2015.05.22.09.36.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 22 May 2015 09:36:35 -0700 (PDT) From: Dave Garrett To: "Salz, Rich" Date: Fri, 22 May 2015 12:36:33 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> <201505211712.55279.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201505221236.34122.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 16:36:38 -0000 On Friday, May 22, 2015 11:38:14 am Salz, Rich wrote: > Most of the net doesn't support IPv6. This is an ISP issue. Plenty of clients support it, but their network won't route it. From nobody Fri May 22 10:05:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8716E1A01E2 for ; Fri, 22 May 2015 10:05:34 -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 Tt7AJ6qjNMGY for ; Fri, 22 May 2015 10:05:32 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45EE1A6EE9 for ; Fri, 22 May 2015 10:05:31 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so40559881igb.1 for ; Fri, 22 May 2015 10:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rPO+lreq1XySYE9r0DP3By3gcmPgehhUZLRri1aF1gY=; b=lqSYe7V+RnwAODY4hY9OyWdEN4UeMC7ZqZK3/uKWJCJLxDD97EuNZeJjVf2MhRErsK cpgwr8lXKEe4uyMri7NF8P4vQKd5DBooA5O0jORjWbxnQ9YZtKgdIs9hffEsp7iJuwy4 TlQuUDqW2jI3GUsOW9X7+lbeKJBtcq9CEzg3cUtDfIwIIAX04MdCudggoTRN+8Txh0mv gXVSMx1hWJXfA2ZkchGBPl/RtDqz3xQEdFboMDmkeNQ+YwYSNhg4Nz2Wm1JXtwFOxZQ+ dU9GTkqxcCxwEfno7ZD+OHrslMj8M8uhr4W72n1VS21//0fyEP8gkU7zXKrG4YeQK+p9 w4nA== MIME-Version: 1.0 X-Received: by 10.42.176.8 with SMTP id bc8mr10588389icb.22.1432314331382; Fri, 22 May 2015 10:05:31 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Fri, 22 May 2015 10:05:31 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Fri, 22 May 2015 13:05:31 -0400 Message-ID: From: Jeffrey Walton To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:05:34 -0000 On Fri, May 22, 2015 at 10:54 AM, Peter Gutmann wrote: > Santiago Zanella-Beguelin writes: > >>Regarding validation of DHE parameters and how reasonable it is in practice, >>I wanted to make some publicity for miTLS (http://www.mitls.org/). >> >>A miTLS client maintains a table of known trusted parameters, including the >>subgroup order for parameters with non-safe primes. When receiving unknown >>parameters from a server, it tests the primality of p and (p-1)/2 to check if >>p is a safe prime (and caches a positive result in the table). > > So you do a full primality test (Miller-Rabin or whatever) for each connect? > Doesn't that make it awfully slow? The software under my purview does. I don't allow the developers to use any parameters without validation. That includes crypto parameters. But its for a systems that handles medium and high value data; and not low value data where web browsers and their use of TLS would be appropriate. I don't think browsers will ever be able to handle anything other than low value data, so I probably won't have to worry about web browsers and what do (or don't) validate before use. >>If the modulus is prime but not safe, miTLS checks if it is in the table of >>trusted parameters and otherwise rejects it. We distribute miTLS with a pre- >>populated table of parameters which we tested thoroughly (and we welcome >>people to test further). Most of the time we hit an entry in the table. > > What testing do you do on unsafe primes? GnuTLS with its Lim-Lee primes causes me a lot of problems because they cannot be validated. If we encounter them, then developers are *not* allowed to apply a secret to them. The user has to generate a new, verifiable key and then add that key to their keyring. Jeff From nobody Fri May 22 10:13:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7001A7011 for ; Fri, 22 May 2015 10:13:06 -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 nXO49tf_gnDf for ; Fri, 22 May 2015 10:13:05 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 016311A6EE9 for ; Fri, 22 May 2015 10:13:04 -0700 (PDT) Received: by qkgv12 with SMTP id v12so16652635qkg.0 for ; Fri, 22 May 2015 10:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=VoOLyLzRe7ci6fqaImkac0Nr5zgpJ0+lmyYYTLDFKhs=; b=WQ9XzW/PWQUH/gUkp1RlRYv75kj2GyDKP3o7tgd/g+EBes63mcWR02nAj4/Fa3or5s vPID9kzZ0bfbA3R+jSEPrsekcvXpMY2PHvK/nDtr3T2cfgrV9CQ1HyTnGAJ7VJzUQCxr zFXRbFlh/v29Rhoj1ZypqvdCk9W6IJElRdmVe54S9SWqyHl8bX9qP2+I3Mx07BlOTJvY e2HJsB1O/8XHe0gwLBdHRGI5Oj9Nam27/ehcSZjWQwXIR6j9sRzUlocF6p2honqKJzVz Bcd6C7IY70JUdYx0i0l+PsdYTL5tnlHvaqWcCL5iGpKQqJGcgRhJ2IM9XS5+Z9fVNDBk +7wg== X-Received: by 10.140.40.39 with SMTP id w36mr11965144qgw.65.1432314784256; Fri, 22 May 2015 10:13:04 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id j66sm1680402qgj.8.2015.05.22.10.13.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 22 May 2015 10:13:03 -0700 (PDT) From: Dave Garrett To: Peter Gutmann Date: Fri, 22 May 2015 13:13:01 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505211210.43060.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201505221313.02262.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:13:06 -0000 On Friday, May 22, 2015 08:30:49 am Peter Gutmann wrote: > So if some sort of BCP is published, it should explicitly target browsers and > web servers where this kind of upgrade/change is possible. Telling people to > throw away their PLCs and replace them with new ones isn't going to fly. To be clear, in case it was lost the noise, I did not propose mandating this in the TLS 1.3 spec. If you're going to be sticking with TLS 1.0 until the wheels fall off, you'll be sticking with other TLS 1.0 software to connect to it. (which might entail forking software into TLS 1.0-1.2 & TLS 1.2-1.3 variations, if you really have to) The proposals for the TLS 1.3 spec are intended to apply only to things that are actually updating. The idea is to drag the whole ecosystem kicking and screaming into the 21st century. If the ecosystem isn't moving at all, there's nothing we can do about that here. :( Dave From nobody Fri May 22 10:22:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDE61A871A for ; Fri, 22 May 2015 10:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 UU-1383yiluW for ; Fri, 22 May 2015 10:22:08 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C951A8714 for ; Fri, 22 May 2015 10:22:08 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 0369933D19F; Fri, 22 May 2015 17:22:06 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Peter Gutmann References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> <20150522032029.GA24064@typhoon.azet.org> <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz> From: Geoffrey Keating Date: 22 May 2015 10:22:06 -0700 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz> Message-ID: Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:22:12 -0000 Peter Gutmann writes: > You know the PLC I used as an example in an earlier message, the one > that rejects any attempt at connecting with a version number set to > greater than TLS 1.0? The "upgrade" procedure for that is to > replace it when the hardware dies, with a minimum (minimum, not > maximum) lifetime of around ten years (I've seen refridgerator-sized > PLCs dating from the 1960s still in active use today, but that's > because they're practically indestructible compared to modern > versions). > > So if some sort of BCP is published, it should explicitly target > browsers and web servers where this kind of upgrade/change is > possible. Telling people to throw away their PLCs and replace them > with new ones isn't going to fly. Telling people that these PLCs are secure and everything is fine and they don't need to worry won't fly either. The owners of these devices are going to have to find a solution, whether it's an early hardware upgrade, firmware replacement, or a front-end translator/firewall. From nobody Fri May 22 10:24:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F0E1A8728 for ; Fri, 22 May 2015 10:24:20 -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 Tqgey8nd_uMc for ; Fri, 22 May 2015 10:24:19 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AC31A8714 for ; Fri, 22 May 2015 10:24:19 -0700 (PDT) Received: by oihd6 with SMTP id d6so18864851oih.2 for ; Fri, 22 May 2015 10:24: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:from:date:message-id:subject:to :cc:content-type; bh=an0J4OGPAX6iYmnhUcOAkEzj4/lxLhRp7w9Jb3OhRJQ=; b=GMpK4A6tVcLU+O989rkDJa1B65qBgSR66aGiTvVM4CEDQcP6bsnrXqq/lh7zbD6qSK AlKEqn0r7N+vxw0VPDsWLcRLGM8EmQDBWfOgE/gh9pZLzoRmA/92HJhpWZRjcE6sjEPR Bcx/yeZqxzJFzrRgz51GoZXsXKQeaxEAy+dx8F9i3QtHMCGH3Hvat5dwjNCOFdI7YXdY oE3WowzdtnSgZg9xVJD5AbyXR3jrh4j7esdvT/gryvKcncLay/sEO0HQbIIG74xGh3L7 IHXSDIosU0rzoyAKHH5ttjMaHCUctPcGd2d8EAuNWgnsogVh+V9Q7NNOs2mSe/JpLMkG z6EA== X-Received: by 10.202.222.215 with SMTP id v206mr6594788oig.50.1432315458677; Fri, 22 May 2015 10:24:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.25.198 with HTTP; Fri, 22 May 2015 10:23:58 -0700 (PDT) In-Reply-To: References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> From: Tony Arcieri Date: Fri, 22 May 2015 10:23:58 -0700 Message-ID: To: Ronald del Rosario Content-Type: multipart/alternative; boundary=001a113d3fcc1ef4f40516aeee7e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:24:20 -0000 --001a113d3fcc1ef4f40516aeee7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 22, 2015 at 9:02 AM, Ronald del Rosario wrote: > Maybe it needs a =E2=80=9Cdedicated website + cool logo=E2=80=9D ala hea= rtbleed, FREAK, > etc. to get noticed :-) > diediedie.ietf.org? ;) --=20 Tony Arcieri --001a113d3fcc1ef4f40516aeee7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, May 22, 2015 at 9:02 AM, Ronald del Rosario <rrosario@five9.com&g= t; wrote:
Maybe it needs a =E2=80=9Cdedicated website + cool logo=E2=80=9D ala h= eartbleed, FREAK, etc. to get noticed :-)

--
To= ny Arcieri
--001a113d3fcc1ef4f40516aeee7e-- From nobody Fri May 22 10:52:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2B41A87BC for ; Fri, 22 May 2015 10:52:55 -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 2alVBg8gbTb1 for ; Fri, 22 May 2015 10:52:52 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AD11A87E7 for ; Fri, 22 May 2015 10:52:36 -0700 (PDT) Received: from CO2PR03CA0038.namprd03.prod.outlook.com (10.141.194.165) by BL2PR03MB289.namprd03.prod.outlook.com (10.141.68.12) with Microsoft SMTP Server (TLS) id 15.1.166.22; Fri, 22 May 2015 17:52:34 +0000 Received: from BN1AFFO11FD045.protection.gbl (2a01:111:f400:7c10::179) by CO2PR03CA0038.outlook.office365.com (2a01:111:e400:1414::37) with Microsoft SMTP Server (TLS) id 15.1.160.16 via Frontend Transport; Fri, 22 May 2015 17:52:33 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; cs.auckland.ac.nz; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1AFFO11FD045.mail.protection.outlook.com (10.58.53.60) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Fri, 22 May 2015 17:52:31 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB030.064d.mgd.msft.net (141.251.50.210) with Microsoft SMTP Server (TLS) id 15.1.112.16; Fri, 22 May 2015 17:52:29 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Fri, 22 May 2015 17:52:29 +0000 From: Santiago Zanella-Beguelin To: Peter Gutmann , "" Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AdCUn0KvDdHZ+lmQNUW54l67jurcrQAGEh4F Date: Fri, 22 May 2015 17:52:29 +0000 Message-ID: <1432317148442.5357@microsoft.com> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.216.4.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD045; 1:ApJaUoG98TN0ZjBNcBm1q6WLQGwQT/+aKGjH60els6+veFcKevxiQT3mxGEmUEmR90dvTRgKjRjpLATq37XYj+YOYRdF/1KmeXljjKsT/KloiSWvSjGf60gx3FJ5kHGnj56klp+DnudNFIOJAoHaoFUGI0aen3Pn4mmR2akT3+y8OVnm/gpmAXf5EjSfmi8dgaR63qPO0Scmvx6cJTPy7sFXeLL35ul7YUlnlSJEFSGMiAG4tJZYr1P7sZM+dFOXs59+SQ1la0WqcL4X5sufYg== X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(189002)(199003)(51704005)(107886002)(5001830100001)(5001960100002)(117636001)(62966003)(69596002)(5001770100001)(5001860100001)(189998001)(19580395003)(36756003)(16796002)(2900100001)(19580405001)(86362001)(50466002)(64706001)(23756003)(54356999)(76176999)(86146001)(2656002)(86612001)(6806004)(66066001)(87936001)(92566002)(97736004)(2950100001)(81156007)(15975445007)(77156002)(4001540100001)(47776003)(106466001)(50986999)(46102003)(68736005)(102836002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB289; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB289; 2:2WWgm8iGwXcP7OzxMK5bTGeb4ZVhlkuQfHQ2FwXmr7TENWdfTKU4UIaYPIpuuuTz; 2:h9LUFi4n+i7rHPs9w65Fs1lA2OpmZRJlc5vnlqZptxBBccgdrPrhTF3DOYAnEpIoX7cHTryOWL2cZ3Wb2XXigPVgt5P67MjvBa39QfA/SPim8cgUKCxZ3I0H7xxZzQejoIZsD11zytBJ3WoKR5+O//ey9jhulefQ3fQy0v0x/2GtushS0uEPtNlmrBPGGlgR76yIeK1GpdS2Yj17Z8YfZI/ZL/4slufLsQCVJ3fvUNUpS7jq1ToHR0z2kD5EHNS9; 6:ZIWy4Xnx+nY8HxsLFz+I+fbhIdpyKr0b8nQfsEeTaAux6Rkklpr5K3S65QMi2BvlbMqJIPiLjJqdiXNutGqXNc/JNwbphdoAuM59csjxf10CZlrcUuNZ6Wo40ton6St6Rk3k3spYH2+HwER6y0RGN+uUuzLWyisyM+ZWJlBm8q2vtRteqoDm934GOdh2WmtkUHvOAZV9PPTNLo6UDqEVJuH07JqED0xPDrNmkTgZXVbEkAxVTVcmsS7RoF92qHi+KsNbbZTLGAgZmu/0LcloG+YlXgYQ5FQTzEtcSGzZ+M893qT7uOwGJWjesK9ry4h6Y4vaw+1TXZxU033534Zw+/2EdnPm0h5q+5EmBm3xRibtdelfrhiMKraXT5QmwL2uRL1jSEx06XZO5TBYJjRt4AGDXaQXYe3MxzUquHR3lD5eyIUuyb755IMzVlSg/49NN9nWu+cpzI+6rII/ofRaY4v5FEuogkJi5fREyFypSQlGSxm08Qof5JTWWTQWhfRu X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB289; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(520002)(5005006)(3002001); SRVR:BL2PR03MB289; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB289; X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB289; 3:97S/PNauGmtxuK5GF9fK/1hDA4KbHWxoSSP9ZPHWTyBEAZgxko6B6ZtvJcWhlN9T6SyKbrl+Ld1fl3P4EoNQq8Y6TZXcIoyHC+LqmvuzamCB7xCIgVyAU70MDU8WvQMiynufu2AzLeX+Lc2+DsIZLgTH/pi4Hh5Sh1TGqlJ86wyZLnKZcJ8/Rs8CKqhiJdGlMDYuV7yYdSc8NZL3tl6fbKd5hNqRwmEO0rkA/ToB6mgxYQ6HpBg8/jm1sD440O/q/UdBROxbdE+y2v1K2cUqVLMkfIcs7CA0eadVd/xgz9TzN/p1Ixot1+mjdxCq77E9SBD/HOjPd3TllTVT/BoyYA== X-Forefront-PRVS: 058441C12A X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BL2PR03MB289; 9:WIRlegqhlRfyBdXEE2UgeQwc4PSZV9sUd4napgZlf?= =?iso-8859-1?Q?vLFJwdn5eUllyeKO1zPcbbk8qariK23tLT6HCYysY/V+SoqAmLmwVd+5KE?= =?iso-8859-1?Q?ybUb6Inc+tkvWtmxZXD7N9KiW/LmRQhNdZNxXwizJJsaXGsYd4p041gyCb?= =?iso-8859-1?Q?kr5i3rSqfhyPtob4NFiaOKiVNZu7iprhhN4zetXFHTQO8ZvL8/gRUdhr+u?= =?iso-8859-1?Q?EPFF3VCVg1Ph9F7ubjhERDW5jkt+f8BFh05Jt3eTPGpX94mdqL1jBGvawW?= =?iso-8859-1?Q?+QWOY6n+ZF6OaTxQi8+JpWBTyJVbPZg1CpY0crt5A1NPHVakvj2F1YEI4v?= =?iso-8859-1?Q?Lv3AHWWJ8iJ2Dpxuba1k+KgN9/M3GZe8Ubp5eR+4R0BwIMJ99nfv91FEBt?= =?iso-8859-1?Q?mVw9chb4/X+rlvLJAwtx48e3IS/hrDemupFBPTOiGd5NO2U5D3a1hGjifa?= =?iso-8859-1?Q?aYaIkjnhyszGlkgZ31myWby3USUD93tqLDm4D8YgF7XX+kpY8sr7FhXTCr?= =?iso-8859-1?Q?KHfDTwIWkKHQrMxzZzf2RCf0Jdzejaiqc5hUOSXAPnO/sUrirnfm9JUOJV?= =?iso-8859-1?Q?rGrWJhNaMERrZV5MQeEcb3IX3zq+l/xDofwfXQkFY5B+WDT5eJfTwnn1f4?= =?iso-8859-1?Q?5i25aAOJ56rJ/+W/QPanhxKSs2rhhmXUG3+CaOSwXBEt/b5K0OSericG08?= =?iso-8859-1?Q?h4sfUZVQ7JxjnlkFQU88rP9A2xXAPaDiyy4BzIc5hyaOOc13aRhnK0Tf2Q?= =?iso-8859-1?Q?qG7jKH5Z/znVKYLF1tBJ9ZC5r8Zvpg7WpDrZ//X7z8L/J/taEmwnadLgDN?= =?iso-8859-1?Q?mnBEdeNr+NmpOMgUTA7kBfNW269ptQEe+JMfP9f49XIfCYTGVSqXeiYV4d?= =?iso-8859-1?Q?hbN/4egtTbJB/g1KA0J4/8PuCNgPahE5TAj7WZ0jSC5o/TxvhVunxtjRQX?= =?iso-8859-1?Q?kNq9WDbThvsd2CJrgyMEXy+oM4OodbbY2pfzRBfED93RXRL+1op18Yn1Cx?= =?iso-8859-1?Q?slpHzfhDCmtZFwdWmlkh88NUQilOcTxO2H/4UYa6LfA7UNwRK0LDc5IAam?= =?iso-8859-1?Q?FET7m4gDSysI63eK8y69XUgZFn0wKF6FVvER2m8CVku3VoBUkXyjxzSMPM?= =?iso-8859-1?Q?K4b7PHkwe7rAeGLioMCugEgXPiSyYy7LBJfoW76XLO7byHnjTmmjGeACfD?= =?iso-8859-1?Q?C134mQmIX/jlaEHSe2nrkVm1uqzovwDTX/XOmEkKXolZpY41f/4iUHoYAB?= =?iso-8859-1?Q?q2C4hRn4UJP2eDO?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB289; 3:tAuoUNE09VC+pP//VKbUWyjVeYNxZ0RXBqtwf57U5yH5v4nDbepwfwIT2QdAGmm+oFtwviB5MsGeNkzvmfNGTsk04beTV8uOX7BafhIwIlbCLiW0R1wUefHJq5DYUPhqoaB2rFhUjnDAeZVPMfLFNw==; 10:u2If6VOy561Lfv1HPQWA9ITMlcZV0UGCP07aj7ZZEeuB8VZShjwLZ78TyDwQHA4Y3Y86St4/puqMasfi086quzzE1M0ATvy+MSiYlWYaf8U=; 6:QmsODSYFPTn35N8tcJrn1ZaK2dHv/LUz4LnFaru/IMkI7sU2vVRGPKVQaB83WalI X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2015 17:52:31.0118 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB289 Archived-At: Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:52:55 -0000 >>A miTLS client maintains a table of known trusted parameters, including t= he >>subgroup order for parameters with non-safe primes. When receiving unknow= n >>parameters from a server, it tests the primality of p and (p-1)/2 to chec= k if >>p is a safe prime (and caches a positive result in the table). >=20 >So you do a full primality test (Miller-Rabin or whatever) for each connec= t? No. We do primality tests only if the prime isn't in the cache. That happen= s the first time the client connects to a server, or when the server refreshes it= s parameters. That, assuming the parameters aren't already in the pre-populat= ed cache. >Doesn't that make it awfully slow? No. The typical cost of validation is just one table lookup. This works extremely well when people use just a few thousand parameters and don't cha= nge them often. Even if that changes in light of Logjam (I hope it does!), onli= ne primality tests for every connection are not prohibitive. I did a quick tes= t using Sage and the stock is_pseudoprime: testing if a 2048-bit prime is saf= e takes ~180ms in a laptop, while computing two DH operations (exponentiation= s) takes ~17ms. The amortized cost using a cache is of course much lower. > What testing do you do on unsafe primes? We accept them if they're in the pre-populated cache. If not, we reject the= m because we can't check the order of the generator and validate ephemeral ke= ys. Unsafe primes have other problems too, e.g. NFS pre-computation is a bit ea= sier than for safe primes. --Santiago ________________________________________ From: TLS on behalf of Peter Gutmann Sent: Friday, May 22, 2015 3:54 PM To: Subject: Re: [TLS] Another IRINA bug in TLS Santiago Zanella-Beguelin writes: >Regarding validation of DHE parameters and how reasonable it is in practic= e, >I wanted to make some publicity for miTLS (http://www.mitls.org/). > >A miTLS client maintains a table of known trusted parameters, including th= e >subgroup order for parameters with non-safe primes. When receiving unknown >parameters from a server, it tests the primality of p and (p-1)/2 to check= if >p is a safe prime (and caches a positive result in the table). So you do a full primality test (Miller-Rabin or whatever) for each connect= ? Doesn't that make it awfully slow? >If the modulus is prime but not safe, miTLS checks if it is in the table o= f >trusted parameters and otherwise rejects it. We distribute miTLS with a pr= e- >populated table of parameters which we tested thoroughly (and we welcome >people to test further). Most of the time we hit an entry in the table. What testing do you do on unsafe primes? Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri May 22 10:56:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BA61A87DB for ; Fri, 22 May 2015 10:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 6Id0orOXo5Eq for ; Fri, 22 May 2015 10:56:21 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 A9ED11A87D0 for ; Fri, 22 May 2015 10:56:21 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 3FEA11C20DF; Fri, 22 May 2015 19:56:19 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 1BCB71FE05FD; Fri, 22 May 2015 19:56:19 +0200 (CEST) Date: Fri, 22 May 2015 19:56:19 +0200 From: Kurt Roeckx To: Santiago Zanella-Beguelin Message-ID: <20150522175618.GA10423@roeckx.be> References: <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432219967072.32353@microsoft.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:56:24 -0000 On Thu, May 21, 2015 at 02:52:47PM +0000, Santiago Zanella-Beguelin wrote: > Regarding validation of DHE parameters and how reasonable it is in > practice, I wanted to make some publicity for miTLS > (http://www.mitls.org/). I was unable to get it to build (using free software). > A miTLS client maintains a table of known trusted parameters, > including the subgroup order for parameters with non-safe primes. When > receiving unknown parameters from a server, it tests the primality of > p and (p-1)/2 to check if p is a safe prime (and caches a positive > result in the table). If the modulus is prime but not safe, miTLS > checks if it is in the table of trusted parameters and otherwise > rejects it. When is it non-safe but trusted? > We distribute miTLS with a pre-populated table of > parameters which we tested thoroughly (and we welcome people to test > further). Most of the time we hit an entry in the table. > > I think a table lookup per key exchange is about as reasonable as it > gets. I assume that's a table lookup in case it hasn't seen that prime yet? But I understand that they're recommending everybody to generate their own prime. Kurt From nobody Fri May 22 10:57:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5771A8838 for ; Fri, 22 May 2015 10:56:59 -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_20=-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 HPBvgFdSm1I2 for ; Fri, 22 May 2015 10:56:58 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9C81A87E4 for ; Fri, 22 May 2015 10:56:46 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so41736469igb.0 for ; Fri, 22 May 2015 10:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qI8sd9jr3hDSsg3X9+qKeSK2I6pHjxaUBKrcGznvi+o=; b=hCRSdO8PFmWP0LvCOcTe4HM/zAZhNc1aVNEaP/zux0JChYLV7Dnf3fZ9ZEzimaMpxE 9+eddrjKFepiCl+smtXbYBje+EiD9MEQYI71pBh4+kEhKp+Fz//fX1HTvnXd39Z0QP2z DzgctmimZcfSEloCLGbhgfw5cTfy2ep0YwDx2IvF3E51ELyBJpSihG81VGKmhWgmilKG o9XdJh3oRn6DGsKKMlt4D2LTlK1WW7gdK6i9xI+uGorzwXliZxZUtM30lKgr5lteIj8y p2LoWCtJVVm8HEwl5KHfxcuc5zeZ/727aOfkgC+j0Xhuk/sKT5QAZNYiOT3p9kNUBscF 2WZw== MIME-Version: 1.0 X-Received: by 10.107.157.130 with SMTP id g124mr12610783ioe.11.1432317405843; Fri, 22 May 2015 10:56:45 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Fri, 22 May 2015 10:56:45 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz> References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> <20150522032029.GA24064@typhoon.azet.org> <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Fri, 22 May 2015 13:56:45 -0400 Message-ID: From: Jeffrey Walton To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:56:59 -0000 On Fri, May 22, 2015 at 8:30 AM, Peter Gutmann wrote: > Xiaoyin Liu writes: > >>The simple reason is that we should allow normal users to gradually upgrade >>their old browsers/operating systems, but should encourage (or require) >>webmasters to upgrade their servers as soon as possible in order to protect >>their users' security and privacy. > > This comment again shows the rather myopic browser-centered view of TLS that > I've complained about in the past. For most of the users of TLS that I work > with, there is no browser, no OS upgrade, and no web. TLS is used for > machine-to-machine communications, with no human intervention. You know the > PLC I used as an example in an earlier message, the one that rejects any > attempt at connecting with a version number set to greater than TLS 1.0? > The > "upgrade" procedure for that is to replace it when the hardware dies, with a > minimum (minimum, not maximum) lifetime of around ten years (I've seen > refridgerator-sized PLCs dating from the 1960s still in active use today, > but > that's because they're practically indestructible compared to modern > versions). +1. That toxic browser thinking and its polluted security model is making its way into non-browser areas, too. For example, browsers apparently embrace user phishing, claiming "there's nothing we can do when a user make a configuration change like adding a CA to the trust store." Then, in a life-is-stranger-than-fiction moment, we get a standard like Public Key Pinning with Overrides, where adversaries are allowed to break known good pinsets because a user was phished. Jeff From nobody Fri May 22 13:37:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFDD1A87E9 for ; Fri, 22 May 2015 13:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.083 X-Spam-Level: X-Spam-Status: No, score=-3.083 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 5hnUkRoAFWYU for ; Fri, 22 May 2015 13:37:01 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6541A87E2 for ; Fri, 22 May 2015 13:37:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,478,1427752800"; d="scan'208,217";a="126026593" Received: from 178.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.178]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 22 May 2015 22:36:58 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_0F3568DF-C86D-458A-BA1E-845B7E46C118" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Fri, 22 May 2015 22:36:57 +0200 Message-Id: References: <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5DDF130@XMB116CNC.rim.net> To: noloader@gmail.com X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 20:37:04 -0000 --Apple-Mail=_0F3568DF-C86D-458A-BA1E-845B7E46C118 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > I think the authors felt the same. But in Section 4 of the paper, they = said: As one of the authors of the paper, let me try to clarify our = recommendations a little bit. First, we only know what is broken, and can only make precise = recommendations for avoiding the attacks in the paper. Figuring out what=92s a good long-term alternative is for a community = forum like this to decide.=20 If we were to make a recommendation for TLS, at least as it is used on = the web, it would be as follows,=20 in decreasing order of preference: 1) Switch to ECDHE.=20 It is faster, and the kinds of attacks discussed in our paper have = not (yet) been shown to be effective for the common curves. As usual, we need to be wary of weak curves (160-bit) or curves that = may have been generated maliciously. We leave it to the EC folks to tell us what are good curves to use. 2) Switch to stronger (>=3D2048-bit) DHE groups. If ECDHE is unavailable, we are happy (today) with >=3D 2048 groups = as suggested in the FF-DHE draft. As usual, we have to be wary of how these groups are generated, = since there is the possibility of trapdoors being built in. Using well known constants such as pi or e as the basis for prime = generation (e is used in FF-DHE) is, as far as we know,=20 a safe technique for generating a group with a low probability of a = trapdoor. 3) Do not use fixed 1024-bit groups. If ECDHE or 2048-bit groups are both infeasible and 1024-bit groups = need to be used for legacy reasons,=20 we recommend that servers generate fresh 1024-bit groups regularly = to increase the computational cost of an attack. When a particular group size becomes computationally reachable, the = clock starts ticking on all groups of that size. After that point, the use of fixed groups begins to bite, because = the cost of breaking each group can be amortised across its users. We (and others) believe that 1024-bit groups may have become = breakable, but the cost of precomputation for each group is still quite = high. Let=92s make things harder for the adversaries by changing groups so = that their precomputations are wasted. As usual, we need to take care when generating new groups: e.g. use = randomly-generated safe primes. 4) In all cases, do not use groups of size < 1024. Groups of size 512- and 768- are broken today. We can do it with = academic processing power. Get rid of these groups, especially the popular Oakley Group 1 and = the 768-bit groups in Java and older versions of IIS. Of course, disable *_EXPORT_* immediately. We don=92t know which of the above apply to non-web uses of TLS, but = since all major web browsers support ECDHE with p-256 and higher, the first recommendation should, in our view, already be adequate for = the web. I=92d be curious to know if it isn=92t and why? =20 =20 Best regards, Karthik >=20 > In this section we address the following > question: how secure is Diffie-Hellman in broader practice, > as used in other protocols that do not suffer from downgrade, > and when applied with stronger groups? >=20 > To answer this question we must first examine how the > number field sieve for discrete log scales to 768- and 1024-bit... >=20 > Unfortunately, our measurements also indicate that it > may be very difficult to sunset the use of fixed 1024-bit Diffie- > Hellman groups that have long been embedded in standards > and implementations. >=20 > I think they are politely saying standard groups should do away with > anything at 1024-bits or below. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_0F3568DF-C86D-458A-BA1E-845B7E46C118 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

I think the authors felt the same. But = in Section 4 of the paper, they = said:

As one of the authors of = the paper, let me try to clarify our recommendations a little = bit.
First, we only know what is broken, and can only make = precise recommendations for avoiding the attacks in the = paper.
Figuring out what=92s a good long-term alternative is = for a community forum like this to = decide. 

If we were to make a = recommendation for TLS, at least as it is used on the web, it would be = as follows, 
in decreasing order of = preference:

1) Switch to = ECDHE. 
    It is faster, and the kinds of = attacks discussed in our paper have not (yet) been shown to be effective = for the common curves.
    As usual, we need to be = wary of weak curves (160-bit) or curves that may have been generated = maliciously.
    We leave it to the EC folks to tell = us what are good curves to use.

2) Switch to = stronger (>=3D2048-bit) DHE groups.
    If ECDHE = is unavailable, we are happy (today) with >=3D 2048 groups as = suggested in the FF-DHE draft.
    As usual, we have = to be wary of how these groups are generated, since there is the = possibility of trapdoors being built in.
    Using = well known constants such as pi or e as the basis for prime generation = (e is used in FF-DHE) is, as far as we know, 
  =   a safe technique for generating a group with a low probability of = a trapdoor.

3) Do not use fixed 1024-bit = groups.
    If ECDHE or 2048-bit groups are both = infeasible and 1024-bit groups need to be used for legacy = reasons, 
    we recommend that servers = generate fresh 1024-bit groups regularly to increase the computational = cost of an attack.
    When a particular group size = becomes computationally reachable, the clock starts ticking on all = groups of that size.
    After that point, the use = of fixed groups begins to bite, because the cost of breaking each group = can be amortised across its users.
    We (and = others) believe that 1024-bit groups may have become breakable, but the = cost of precomputation for each group is still quite = high.
    Let=92s make things harder for the = adversaries by changing groups so that their precomputations are = wasted.
    As usual, we need to take care when = generating new groups: e.g. use randomly-generated safe = primes.

4) In all cases, do not use groups of = size < 1024.
    Groups of size 512- and 768- are = broken today. We can do it with academic processing = power.
    Get rid of these groups, especially the = popular Oakley Group 1 and the 768-bit groups in Java and older versions = of IIS.
    Of course, disable *_EXPORT_* = immediately.

We don=92t know which of the above = apply to non-web uses of TLS, but since all major web browsers support = ECDHE with p-256 and higher,
the first recommendation should, = in our view, already be adequate for the web. I=92d be curious to know = if it isn=92t and why?    
  =   
Best = regards,
Karthik



   In this = section we address the following
   question: how = secure is Diffie-Hellman in broader practice,
   as = used in other protocols that do not suffer from = downgrade,
   and when applied with stronger = groups?

   To answer this question we must first = examine how the
   number field sieve for discrete log = scales to 768- and 1024-bit...

   Unfortunately, = our measurements also indicate that it
   may be very = difficult to sunset the use of fixed 1024-bit = Diffie-
   Hellman groups that have long been embedded = in standards
   and implementations.

I think = they are politely saying standard groups should do away with
anything = at 1024-bits or = below.

_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tls

= --Apple-Mail=_0F3568DF-C86D-458A-BA1E-845B7E46C118-- From nobody Fri May 22 13:56:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE611A8879 for ; Fri, 22 May 2015 13:55:59 -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 SJlPQ02S_RLv for ; Fri, 22 May 2015 13:55:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E8EDD1A8863 for ; Fri, 22 May 2015 13:55:56 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 99D6EF984 for ; Fri, 22 May 2015 16:55:54 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5466C20040; Fri, 22 May 2015 16:55:32 -0400 (EDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: <1432317148442.5357@microsoft.com> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> User-Agent: Notmuch/0.20~rc1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 22 May 2015 16:55:29 -0400 Message-ID: <87pp5snxha.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 20:55:59 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [ i fixed typo in the Subject line because it bothered me; sorry if that kills threading in anyone's MUA ] On Fri 2015-05-22 13:52:29 -0400, Santiago Zanella-Beguelin wrote: >>>A miTLS client maintains a table of known trusted parameters, including = the >>>subgroup order for parameters with non-safe primes. When receiving unkno= wn >>>parameters from a server, it tests the primality of p and (p-1)/2 to che= ck if >>>p is a safe prime (and caches a positive result in the table). >>=20 >>So you do a full primality test (Miller-Rabin or whatever) for each conne= ct? > > No. We do primality tests only if the prime isn't in the cache. That happ= ens the > first time the client connects to a server, or when the server refreshes = its > parameters. That, assuming the parameters aren't already in the pre-popul= ated > cache. > >>Doesn't that make it awfully slow? > > No. The typical cost of validation is just one table lookup. This works > extremely well when people use just a few thousand parameters and don't c= hange > them often. Even if that changes in light of Logjam (I hope it does!), on= line > primality tests for every connection are not prohibitive. I did a quick t= est > using Sage and the stock is_pseudoprime: testing if a 2048-bit prime is s= afe > takes ~180ms in a laptop, while computing two DH operations (exponentiati= ons) > takes ~17ms. The amortized cost using a cache is of course much lower. I'm considering adding a Miller-Rabin primality check for the group modulus to negotiated-ff-dhe's "Local Policy for Custom Groups" section: https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09#section-3.1 I'm also considering adding a suggestion for checking that the modulus is a safe prime, if it is not already known to the client to be an acceptable modulus. What do others think about either of these additions? =2D--- I see how the idea of every server choosing their own groups makes sense From=20a crypto theory point of view, and if everyone does it right, it would indeed probably be the best situation. I have concerns about it from a practical perspective, though. A client encountering a novel group now has to make a choice about whether to perform some tests on the group (as suggested above) or to proceed without testing (hoping that the server picked the right parameters). Since TLS clients are in tension between the demands of efficiency (make connections faster and cheaper for your user) and security (ensure the integrity and confidentiality of your user's communications), many will be tempted to skip the extra checks, since if the remote servers are well-configured, the check should be unnecessary. Furthermore, generating a large safe prime group is expensive and slow, which puts it out of reach of many devices that act as TLS servers, which practically might mean we're delegating the job of prime selection to implementors or software distributors. As a case in point, the SSH protocol provides custom moduli, but i believe most SSH servers ship with a set of default moduli (e.g. the OpenSSH project ships a default set of moduli), and everyone just uses those. In the OpenSSH case, the upstream moduli appear to be generated, tested and found to be safe primes on the basis of 100 rounds of Miller-Rabin (see moduli(5) and /etc/ssh/moduli on a debian system, for example), instead of generating proofs of primality (which are significantly more expensive). Yesterday, OpenSSH updated the set of moduli they'll be distributing for the first time in 3 years [0] (this is better than the oakley groups, which haven't been updated!). The new ones were also tested on the basis of 100 rounds of Miller-Rabin. There is also discussion on the openssh-unix-dev mailing list that different distributions might consider shipping different sets of moduli, though this could potentially introduce a distro-fingerprinting attack in places where such an attack might not already exist. We need protocol designs that simplify things for implementators and deployers, and that remove the need for expensive security checks that might be skipped for efficiency reasons. sufficiently large known-groups seem to solve that problem, as long as we deprecate smaller groups promptly. I'm not sure that encouraging custom groups does, even though it sounds like it would be the safer option when everyone is playing by the best practice guidelines. --dkg [0] https://anongit.mindrot.org/openssh.git/commit/?id=3D8b02481143d75e91c4= 9d1bfae0876ac1fbf9511a --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJVX5fBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcmJcQAKPaWyyf7czXyvFx+Gq5YOS0 kNl/WUv80e/SgQSpSlylETwGbIwkrbSoU7i5tarNwfK2XxW+HigK34vp6S8ulw68 98DPZGrJ/mfGO5nks/vAmkEIqDjw3movK5Zaj6k+MtFBzwJZAZsFSQH+3P7+sisJ yb0GAJMuJsd8yvHCZmaQWloXzd61yCIuWEuKTxcUdC3B4tE1goH9lygNrhW9RjUu zVPIbPwjQHJGXHBVZIR027SoCv6+zQn4YBA7dCZAQCXFuCvTXkwPXCgHn/kqEZjB bj+lFZ2udm9eU6kdJXccetr3qWctdG8Qq9qPbG7s1JzwZTuRAH4AkyqLFiNiZ12v Ne8H7atIg9Mh98iKhwiL78qPMD2waWxh5avNQKyknKPdtsDOf/M4F3EenN9A63Ui BZ5IMiIo3M2Ipx3WLuiLZQPWsx3mqHFMbuQ+ohov7ew8byHWW/Fb/tAVGAalDMPZ kSFZTyCdMrqsZaHSpX5jYQ7f7eX8W7yV/ufr5sMmiA/Jz/NzKVJPe3jRD2gOfk/z O3/ov0uRAiDtVzEwzfABz7ORgTd43hYJ/HyUTfhZ2ToYYJJNO9Duqownv/h9nCYo qyVYCK0XxT1xozDO8RPkA8Nu4tYLGJ+ECeGiyV/1Qnv93GLD0MKPgGM2ZUJlvHDQ bxr2UFmlo5d+CV1fMF9J =hYRd -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 22 14:09:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE20F1A8889 for ; Fri, 22 May 2015 14:09:33 -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 17eTKhvrXRaT for ; Fri, 22 May 2015 14:09:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8081A8892 for ; Fri, 22 May 2015 14:09:29 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.166.22; Fri, 22 May 2015 21:09:27 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0166.017; Fri, 22 May 2015 21:09:27 +0000 From: Andrei Popov To: Daniel Kahn Gillmor , "tls@ietf.org" Thread-Topic: [TLS] Another INRIA bug in TLS Thread-Index: AQHQlNG6+AHsQvXpsUGOwpc7u3GouZ2IekhA Date: Fri, 22 May 2015 21:09:26 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> In-Reply-To: <87pp5snxha.fsf@alice.fifthhorseman.net> 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=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 3:TlstlRw7hZFPIARrqEXz++iz1E8XZjpskqLvm8XGvLj07fHwsF2Oom/MhnAzceutNoNApipAxkpOOgCnBcDw77Vxt+sFfN0IdqJ9A/iD6P6/YG1yqq5XB1bYltWBeIuhhXkchn1K2BQ9KmKuHBeiew==; 10:TDwM7aCwK4DAoapJPu3up4yvMkijtrSDLGQD8X6yNA4LyXmJIXr/HIy69SYKaspsdJLjIx1+8r58wAy6PIafljBl5MG25VfUR7feFIbl+EU=; 6:6xYmYfidt1syU5Zx+pMvwFnKC8jRbrgCR28jcoO4Z/57e2zLe8Nz3YXeCNIvPcwb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377424004)(51704005)(377454003)(189002)(199003)(87936001)(33656002)(19580405001)(46102003)(81156007)(74316001)(107886002)(77156002)(62966003)(189998001)(40100003)(122556002)(19580395003)(4001540100001)(97736004)(101416001)(2656002)(105586002)(5001960100002)(92566002)(86362001)(15975445007)(77096005)(102836002)(2950100001)(2900100001)(68736005)(50986999)(54356999)(76176999)(5001830100001)(64706001)(5001860100001)(99286002)(106356001)(5001770100001)(2501003)(86612001)(106116001)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2015 21:09:26.2867 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 21:09:33 -0000 I agree that sufficiently large known groups make precomputation infeasible= , and also simplify both client and server implementation. So the immediate mitigation could be for clients to stop accepting small DH= groups, and for servers to send larger DH groups (this will of course crea= te interop issues, esp. initially). In the long term, it may become possible to only allow DHE cipher suites wh= en a known group has been negotiated using draft-ietf-tls-negotiated-ff-dhe= . Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor Sent: Friday, May 22, 2015 1:55 PM To: tls@ietf.org Subject: Re: [TLS] Another INRIA bug in TLS [ i fixed typo in the Subject line because it bothered me; sorry if that kills threading in anyone's MUA ] On Fri 2015-05-22 13:52:29 -0400, Santiago Zanella-Beguelin wrote: >>>A miTLS client maintains a table of known trusted parameters,=20 >>>including the subgroup order for parameters with non-safe primes.=20 >>>When receiving unknown parameters from a server, it tests the=20 >>>primality of p and (p-1)/2 to check if p is a safe prime (and caches a p= ositive result in the table). >>=20 >>So you do a full primality test (Miller-Rabin or whatever) for each conne= ct? > > No. We do primality tests only if the prime isn't in the cache. That=20 > happens the first time the client connects to a server, or when the=20 > server refreshes its parameters. That, assuming the parameters aren't=20 > already in the pre-populated cache. > >>Doesn't that make it awfully slow? > > No. The typical cost of validation is just one table lookup. This=20 > works extremely well when people use just a few thousand parameters=20 > and don't change them often. Even if that changes in light of Logjam=20 > (I hope it does!), online primality tests for every connection are not=20 > prohibitive. I did a quick test using Sage and the stock=20 > is_pseudoprime: testing if a 2048-bit prime is safe takes ~180ms in a=20 > laptop, while computing two DH operations (exponentiations) takes ~17ms. = The amortized cost using a cache is of course much lower. I'm considering adding a Miller-Rabin primality check for the group modulus= to negotiated-ff-dhe's "Local Policy for Custom Groups" section: https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09#section-3.= 1 I'm also considering adding a suggestion for checking that the modulus is a= safe prime, if it is not already known to the client to be an acceptable m= odulus. What do others think about either of these additions? ---- I see how the idea of every server choosing their own groups makes sense Fr= om a crypto theory point of view, and if everyone does it right, it would i= ndeed probably be the best situation. I have concerns about it from a practical perspective, though. A client encountering a novel group now has to make a choice about whether = to perform some tests on the group (as suggested above) or to proceed witho= ut testing (hoping that the server picked the right parameters). Since TLS= clients are in tension between the demands of efficiency (make connections= faster and cheaper for your user) and security (ensure the integrity and c= onfidentiality of your user's communications), many will be tempted to skip= the extra checks, since if the remote servers are well-configured, the che= ck should be unnecessary. Furthermore, generating a large safe prime group is expensive and slow, whi= ch puts it out of reach of many devices that act as TLS servers, which prac= tically might mean we're delegating the job of prime selection to implement= ors or software distributors. As a case in point, the SSH protocol provides custom moduli, but i believe = most SSH servers ship with a set of default moduli (e.g. the OpenSSH projec= t ships a default set of moduli), and everyone just uses those. In the Ope= nSSH case, the upstream moduli appear to be generated, tested and found to = be safe primes on the basis of 100 rounds of Miller-Rabin (see moduli(5) an= d /etc/ssh/moduli on a debian system, for example), instead of generating p= roofs of primality (which are significantly more expensive). Yesterday, OpenSSH updated the set of moduli they'll be distributing for th= e first time in 3 years [0] (this is better than the oakley groups, which h= aven't been updated!). The new ones were also tested on the basis of 100 r= ounds of Miller-Rabin. There is also discussion on the openssh-unix-dev ma= iling list that different distributions might consider shipping different s= ets of moduli, though this could potentially introduce a distro-fingerprint= ing attack in places where such an attack might not already exist. We need protocol designs that simplify things for implementators and deploy= ers, and that remove the need for expensive security checks that might be s= kipped for efficiency reasons. sufficiently large known-groups seem to solv= e that problem, as long as we deprecate smaller groups promptly. I'm not s= ure that encouraging custom groups does, even though it sounds like it woul= d be the safer option when everyone is playing by the best practice guideli= nes. --dkg [0] https://anongit.mindrot.org/openssh.git/commit/?id=3D8b02481143d75e91c4= 9d1bfae0876ac1fbf9511a From nobody Fri May 22 14:10:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E171A889D for ; Fri, 22 May 2015 14:10:52 -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 R5ign9zifeMw for ; Fri, 22 May 2015 14:10: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 9EF411A8892 for ; Fri, 22 May 2015 14:10:39 -0700 (PDT) Received: by ykfr66 with SMTP id r66so9591960ykf.0 for ; Fri, 22 May 2015 14:10:39 -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=BkNvZg9HgxM5Mq0rDwBzSXckH/66hJf9EBdvgHUXIVQ=; b=UuIxBLhw5a9anEXeFg7pIYlTuZ5vD246Q6eNewy1mApI0C4xYNBaFReyKXzpDfhHWl K8dCxFWpPD1/A4OZJrycyVDzso8/2IgNF8QpXqtZzj0/4FjYI8px6BjC26eoCk/pkQm/ nRkx2b2oecYww8rvkhHxY5Pjhv/RJPOm9ZrlMVYA87ytbpmPho/h8gZ9FE3fSh0cKix8 hrIMS4t3bixlmvT8a8jx5pn5i/V7/eNdcpnIkxuXKEQaVprTxoqt4PJtqjbhkT6WD5AM onlH4PeyLqAGlSoTMSfq9NxZ/AC6BaqStv09qpYtrPRMoUoFIgbYp+VsJDHjNCagtuTD ymIQ== MIME-Version: 1.0 X-Received: by 10.236.28.79 with SMTP id f55mr9933189yha.151.1432329039095; Fri, 22 May 2015 14:10:39 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 22 May 2015 14:10:39 -0700 (PDT) In-Reply-To: <87pp5snxha.fsf@alice.fifthhorseman.net> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> Date: Fri, 22 May 2015 14:10:39 -0700 Message-ID: From: Martin Thomson To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 21:10:52 -0000 On 22 May 2015 at 13:55, Daniel Kahn Gillmor wrote: > I'm considering adding a Miller-Rabin primality check for the group > modulus to negotiated-ff-dhe's "Local Policy for Custom Groups" section: Please don't. I like the statement you have already: Compatible clients that are willing to accept FFDHE ciphersuites from non-compatible servers may have local policy about what custom FFDHE groups they are willing to accept. This local policy presents a risk to clients, who may accept weakly-protected communications from misconfigured servers. More words aren't going to change that. In fact, I can see only harm in going further. I would even go so far as to remove the two paragraphs that follow this. SHOULD >= 1024 isn't really advice that I'm comfortable with. From nobody Fri May 22 14:13:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D491A88A0 for ; Fri, 22 May 2015 14:13:02 -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 nLMwshqudDIV for ; Fri, 22 May 2015 14:13:00 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 9DA361A889D for ; Fri, 22 May 2015 14:13:00 -0700 (PDT) Received: by ykft189 with SMTP id t189so9632086ykf.1 for ; Fri, 22 May 2015 14:13:00 -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=8x5PaGU9NgiXlXOa+e0BGQNSNi8LJrUKIbvBUKIWRZg=; b=CIjnedq7veaBwBOopuKOZLboSpw6gW2fGDrFf+49tYR6Kz7Lpe6eJQdeZERv3kzyLm Nb9rlUWOc07wmfJJhv/N1nVgLSqyAVWYYzMaxXbBPT96UWfZuiTqXq5RXmK+kFoo1AoZ 5btgrrPwwRv42jltVCG/vJFNJEU84V50nDzyn9HFA7BR+KSlqyurwUrXeBUoAeUaV2dP S6SSqSw0cE6YLD0Dw4z9pjW0cCSrhcqBuWkS9o+nilz+RxvltkLrxWN5nvFdrPNbH9Jj MnjCWmxHf188gh08TfmmtGIvD4jm67CBqUDVlfwDEUCg5B9Z/671LLEEe1peIlMy3mC8 83rQ== MIME-Version: 1.0 X-Received: by 10.236.20.230 with SMTP id p66mr10153993yhp.181.1432329180006; Fri, 22 May 2015 14:13:00 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 22 May 2015 14:12:59 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> Date: Fri, 22 May 2015 14:12:59 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 21:13:02 -0000 On 22 May 2015 at 14:09, Andrei Popov wrote: > In the long term, it may become possible to only allow DHE cipher suites when a known group has been negotiated using draft-ietf-tls-negotiated-ff-dhe. That time might have come sooner, if it weren't for the misapprehension people have been given regarding custom groups off the logjam mitigation advice. I think that Karthik's clarification [1] is much clearer than the message that has been propagated. [1] http://www.ietf.org/mail-archive/web/tls/current/msg16496.html From nobody Fri May 22 14:13:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065EC1A88A0 for ; Fri, 22 May 2015 14:13:14 -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 ZUG7JPstypcz for ; Fri, 22 May 2015 14:13:12 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 5F3D81A889D for ; Fri, 22 May 2015 14:13:12 -0700 (PDT) Received: by oihb142 with SMTP id b142so22895304oih.3 for ; Fri, 22 May 2015 14:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4JQ86JPHRt3et8NyF9ZagW60for/hRWjAy14D9X6/0g=; b=JPn9bm2EjevpvmJ6Cw7wlTzxHacDTVl8UsMWsOmS8DxxY1YUOgOZCxrm5MmPznUbAo GU9eXr4dcRUjISBjvTTwzFLxncmWjrXU/1ppPyuw5DdRAhshCETlMlnJDB7Akx9VQPZB FoSPvq4apTpTCMXESrYkGxVqFBbzDvsiZx6aZqGFMZbcScPLY96CG9o+fCj0gLPFJ1H4 an5hgMU+lPxLPkzzOdas7holW9JN7VfSD1oirHK0brYgQIkBLlF1sFkzInZNLgLipTog 7svXtJwevslVcFBuGWvOJZGGP9Yzgy+u/jo5KNbAOK62nXJfgQQICyDoOuMtksYMR5sS Q80g== X-Received: by 10.60.47.34 with SMTP id a2mr8139982oen.48.1432329191795; Fri, 22 May 2015 14:13:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.25.198 with HTTP; Fri, 22 May 2015 14:12:51 -0700 (PDT) In-Reply-To: References: <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5DDF130@XMB116CNC.rim.net> From: Tony Arcieri Date: Fri, 22 May 2015 14:12:51 -0700 Message-ID: To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=047d7b5d45d2adb1460516b22009 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 21:13:14 -0000 --047d7b5d45d2adb1460516b22009 Content-Type: text/plain; charset=UTF-8 On Fri, May 22, 2015 at 1:36 PM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > 1) Switch to ECDHE. > It is faster, and the kinds of attacks discussed in our paper have not > (yet) been shown to be effective for the common curves. > As usual, we need to be wary of weak curves (160-bit) or curves that > may have been generated maliciously. > We leave it to the EC folks to tell us what are good curves to use. > +1 on this. The CFRG has already specified Curve25519 and Ed448-Goldilocks for use in this case: https://tools.ietf.org/html/draft-irtf-cfrg-curves-02 Finite field D-H is slower and more problematic. I know people want it as a fallback in the event there's some sort of terrible breakage in ECC, but if that does happen, why not temporarily abandon forward secrecy until the problem can be addressed instead of switching to finite field D-H? Otherwise, all it's doing is making TLS more complicated and vulnerable to these sorts of downgrade attacks. -- Tony Arcieri --047d7b5d45d2adb1460516b22009 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, May 22, 2015 at 1:36 PM, Karthikeyan Bhargavan <karthik.bhar= gavan@gmail.com> wrote:
1) Switch to ECDHE.=C2=A0
=C2=A0 =C2= =A0 It is faster, and the kinds of attacks discussed in our paper have not = (yet) been shown to be effective for the common curves.
=C2=A0 = =C2=A0 As usual, we need to be wary of weak curves (160-bit) or curves that= may have been generated maliciously.
=C2=A0 =C2=A0 We leave it t= o the EC folks to tell us what are good curves to use.

+1 on this. The CFRG has already specified Cu= rve25519 and Ed448-Goldilocks for use in this case:

https:/= /tools.ietf.org/html/draft-irtf-cfrg-curves-02

=
Finite field D-H is slower and more problematic. I know people want it= as a fallback in the event there's some sort of terrible breakage in E= CC, but if that does happen, why not temporarily abandon forward secrecy un= til the problem can be addressed instead of switching to finite field D-H?<= br>

Otherwise, all it's doing is making TLS mo= re complicated and vulnerable to these sorts of downgrade attacks.

--
Tony Arcieri
--047d7b5d45d2adb1460516b22009-- From nobody Fri May 22 14:18:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB9D1A88A3 for ; Fri, 22 May 2015 14:18:45 -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 s9OoYQVAEtPg for ; Fri, 22 May 2015 14:18:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1AA1A889F for ; Fri, 22 May 2015 14:18:43 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.166.22; Fri, 22 May 2015 21:18:42 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0172.012; Fri, 22 May 2015 21:18:42 +0000 From: Christian Huitema To: Tony Arcieri , Karthikeyan Bhargavan Thread-Topic: [TLS] Another INRIA bug in TLS Thread-Index: AdCU1Fppy/lp4UD200y+7Blw1U1EMA== Date: Fri, 22 May 2015 21:18:41 +0000 Message-ID: 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: [2001:4898:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 3:BBeKHwIRIQpQ09LW0QpoDqItfHGMWUn9Pt3M9Ob2Qi+kSQHzFEy8gtk/47WyA7tt7DitIUWBUx9wi/BaAksRddCaVJVKVtfg2xEX/VXZOBI/RakEWXYVlo39HavihVva6V0sWYMKujl8Vfttz7gIHQ==; 10:ArDDdurZVy8369MtpHXQZXD9+YpdpatAX56TI2gMkqdrIm+hGIkAR0Q6KejOSeX6xaCAbovmOiYmlS+A5CL0JcSmEs/83qLyKEajo+Voh9Y=; 6:LF3Z12zBf2HX2JOR76m+YehIpWcOqIoeTaDghpQtfIe2F2UEaPQp0XHpCZoRl1of x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(189998001)(86612001)(122556002)(77096005)(101416001)(19580395003)(92566002)(97736004)(558084003)(5001960100002)(74316001)(4001540100001)(81156007)(5001770100001)(102836002)(5001860100001)(5001830100001)(68736005)(46102003)(40100003)(86362001)(2900100001)(2656002)(87936001)(64706001)(33656002)(105586002)(106356001)(77156002)(76576001)(54356999)(50986999)(99286002)(62966003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2015 21:18:41.4734 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 21:18:45 -0000 Q291bGQgd2UgcGxlYXNlIGNoYW5nZSB0aGUgc3ViamVjdCB0ZXh0IG9mIHRoYXQgdGhyZWFkPyBJ IHVzZWQgdG8gd29yayBhdCBJTlJJQSAod3d3LmlucmlhLmZyKSBhbmQgSSBhbSBhIGJpdCBzdXJw cmlzZWQgdG8gc2VlIGl0IGNhbGxlZCBJUklOQS4uLg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0K DQoNCg== From nobody Fri May 22 14:52:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5938C1A8934 for ; Fri, 22 May 2015 14:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w621n1RinwW2 for ; Fri, 22 May 2015 14:52:49 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id BDABF1A8928 for ; Fri, 22 May 2015 14:52:49 -0700 (PDT) Received: from [173.75.83.233] (helo=Williams-MacBook-Pro.local) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Yvus3-0001U2-1p; Fri, 22 May 2015 17:52:47 -0400 Date: Fri, 22 May 2015 14:52:46 -0700 From: Bill Frantz To: Dave Garrett X-Priority: 3 In-Reply-To: <201505221236.34122.davemgarrett@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7910c54baf8bd12562343f088928da1b39350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.233 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 21:52:51 -0000 On 5/22/15 at 9:36 AM, davemgarrett@gmail.com (Dave Garrett) wrote: >On Friday, May 22, 2015 11:38:14 am Salz, Rich wrote: >>Most of the net doesn't support IPv6. > >This is an ISP issue. Plenty of clients support it, but their network won'= t route it. Here is another case where revenue models have a significant=20 impact on security. (Another is the CA system.) ISPs charge=20 extra for IP addresses that can run servers. If every device has=20 its own IPv6 address, then every device can run a server. ISPs=20 like IPv4 and NAT. If you want earlier versions of TLS to die, figure out a revenue=20 model for someone which will cause them to help make that=20 happen. (No, I can't think of one immediately either.) In the case of Peter's "living forever" devices, there may be a=20 revenue model in replacing them. But that kind of replacement=20 sounds like 1950s US auto makers planned obsolescence. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | "The only thing we have to | Periwinkle (408)356-8506 | fear is fear itself." - FDR | 16345=20 Englewood Ave www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos,=20 CA 95032 From nobody Fri May 22 15:37:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38F31A898A for ; Fri, 22 May 2015 15:37: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 vVsLJwzgNrEt for ; Fri, 22 May 2015 15:37:55 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::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 156FB1A896A for ; Fri, 22 May 2015 15:37:55 -0700 (PDT) Received: by ieczm2 with SMTP id zm2so41112396iec.1 for ; Fri, 22 May 2015 15:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3uKyOIHKKH0KvKcqiZP+DA2ZDB/GwBCQwGjh9kQudqg=; b=TFx27jXKZCB5g/uN2wmrWQ9RQ8LMbrBCHuA+pydxjxtKAx110VzcCeBuX4LTIGNxi7 5/9yjAIgQuyOCqgO4RPTGHJL92qYcTTkZXrrjOh+N/+6Os+tkC99dkKrpSpEp+DidHEC oJx3l305LFrE/hKy8b34QyM7n99rGR1bmD3BIlkrlZu7BUVDkAcE7gcC09jgkRYOiHFk Psh2f7KLKagmkmXMD5rN0OGUpyF7CgF7pFh8hgneW2KLYwkP0klh9Bs0BdcRFa2nIQOH tl7BVQcO42vjRqB0G1+igAhT7wV1tTtAVH9iNWskTw/NObLeICZrZ5NOUMkbzgzNaSRM EggQ== MIME-Version: 1.0 X-Received: by 10.43.58.206 with SMTP id wl14mr440869icb.36.1432334274633; Fri, 22 May 2015 15:37:54 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Fri, 22 May 2015 15:37:54 -0700 (PDT) In-Reply-To: <87pp5snxha.fsf@alice.fifthhorseman.net> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> Date: Fri, 22 May 2015 18:37:54 -0400 Message-ID: From: Jeffrey Walton To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 22:37:57 -0000 On Fri, May 22, 2015 at 4:55 PM, Daniel Kahn Gillmor wrote: > [ i fixed typo in the Subject line because it bothered me; sorry if that > kills threading in anyone's MUA ] > > On Fri 2015-05-22 13:52:29 -0400, Santiago Zanella-Beguelin wrote: >>>>A miTLS client maintains a table of known trusted parameters, including the >>>>subgroup order for parameters with non-safe primes. When receiving unknown >>>>parameters from a server, it tests the primality of p and (p-1)/2 to check if >>>>p is a safe prime (and caches a positive result in the table). >>> >>>So you do a full primality test (Miller-Rabin or whatever) for each connect? >> >> No. We do primality tests only if the prime isn't in the cache. That happens the >> first time the client connects to a server, or when the server refreshes its >> parameters. That, assuming the parameters aren't already in the pre-populated >> cache. >> >>>Doesn't that make it awfully slow? >> >> No. The typical cost of validation is just one table lookup. This works >> extremely well when people use just a few thousand parameters and don't change >> them often. Even if that changes in light of Logjam (I hope it does!), online >> primality tests for every connection are not prohibitive. I did a quick test >> using Sage and the stock is_pseudoprime: testing if a 2048-bit prime is safe >> takes ~180ms in a laptop, while computing two DH operations (exponentiations) >> takes ~17ms. The amortized cost using a cache is of course much lower. > > I'm considering adding a Miller-Rabin primality check for the group > modulus to negotiated-ff-dhe's "Local Policy for Custom Groups" section: > > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09#section-3.1 > M-R is one check, but there are others. For example, trial division and the choice of g in a group (g may not necessarily be a generator). As a practical example from a guy who regularly validates all parameters, see http://crypto.stackexchange.com/questions/17707/trial-divisions-before-miller-rabin-checks and http://crypto.stackexchange.com/questions/12961/diffie-hellman-parameter-check-when-g-2-must-p-mod-24-11. What I found in the past that the IETF's choice of g = 2 meant that various DH_param_check(...) would fail. Jeff From nobody Fri May 22 15:52:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A3F1A896E for ; Fri, 22 May 2015 15:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 n4Kz4I3nd0s8 for ; Fri, 22 May 2015 15:52:42 -0700 (PDT) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id D2F2F1A8969 for ; Fri, 22 May 2015 15:52:41 -0700 (PDT) Received: (qmail 22296 invoked from network); 22 May 2015 22:53:01 -0000 Received: from pcdhz005.win.tue.nl (HELO hyperelliptic.org) (131.155.71.33) by calvin.win.tue.nl with SMTP; 22 May 2015 22:53:01 -0000 Received: (qmail 29422 invoked by uid 1000); 22 May 2015 22:52:51 -0000 Date: Sat, 23 May 2015 00:52:51 +0200 From: Tanja Lange To: Jeffrey Walton Message-ID: <20150522225251.GG20757@cph.win.tue.nl> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 22:52:43 -0000 > M-R is one check, but there are others. For example, trial division > and the choice of g in a group (g may not necessarily be a generator). > You want g to generate a large prime-order subgroup. > As a practical example from a guy who regularly validates all > parameters, see > http://crypto.stackexchange.com/questions/17707/trial-divisions-before-miller-rabin-checks > and http://crypto.stackexchange.com/questions/12961/diffie-hellman-parameter-check-when-g-2-must-p-mod-24-11. > > What I found in the past that the IETF's choice of g = 2 meant that > various DH_param_check(...) would fail. > The choice of g=2 is appropriate for the Oakley primes because 2 generates the group of squares, which is exactly the group of size (p-1)/2. Unfortunately some programs decide to check whether g generates the entire group of size p-1, i.e. is a primitive element. I say 'unfortunately' because if this is taken together with the recommendation of using relatively short intervals for the secret key (p-1)/2 being composite you're likely to get a powerful break using Pohlig-Hellman. All the best Tanja From nobody Fri May 22 15:54:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A260C1A891B for ; Fri, 22 May 2015 15:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 kzoj8u0YbwZy for ; Fri, 22 May 2015 15:54:50 -0700 (PDT) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id 5263B1A0029 for ; Fri, 22 May 2015 15:54:50 -0700 (PDT) Received: (qmail 22474 invoked from network); 22 May 2015 22:55:10 -0000 Received: from pcdhz005.win.tue.nl (HELO hyperelliptic.org) (131.155.71.33) by calvin.win.tue.nl with SMTP; 22 May 2015 22:55:10 -0000 Received: (qmail 29458 invoked by uid 1000); 22 May 2015 22:55:00 -0000 Date: Sat, 23 May 2015 00:55:00 +0200 From: Tanja Lange To: Santiago Zanella-Beguelin Message-ID: <20150522225500.GH20757@cph.win.tue.nl> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432317148442.5357@microsoft.com> User-Agent: Mutt/1.5.11 Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 22:54:54 -0000 Hi, > > What testing do you do on unsafe primes? > > We accept them if they're in the pre-populated cache. If not, we reject them > because we can't check the order of the generator and validate ephemeral keys. > Unsafe primes have other problems too, e.g. NFS pre-computation is a bit easier > than for safe primes. > What algorithm do you refer to here when you say that the NFS precomputation gets easier. The only thing I know is that you can solve the matrix modulo the group oder (or using fewer moduli when using CRT), but that's a very small speedup. Tanja From nobody Fri May 22 16:27:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F281A0382 for ; Fri, 22 May 2015 16:27:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ELiBZhz3Ms78 for ; Fri, 22 May 2015 16:27:41 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E001A0318 for ; Fri, 22 May 2015 16:27:40 -0700 (PDT) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-02v.sys.comcast.net with comcast id XBTQ1q0074vw8ds01BTgdm; Fri, 22 May 2015 23:27:40 +0000 Received: from [IPv6:::1] ([71.202.164.227]) by resomta-po-04v.sys.comcast.net with comcast id XBTe1q00K4uhcbK01BTeCG; Fri, 22 May 2015 23:27:39 +0000 Message-ID: <555FBB6A.7040508@brainhub.org> Date: Fri, 22 May 2015 16:27:38 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1432337260; bh=cLOFmmr/Ztg7fFvxOkegt65gXFSYLbOR8X8CXPQLlvE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bYt18lkTciLc7LZ+oZ+XNFtrAGpKxoUF9B3bbcOQGB8If/QKIKmAVO6wnyNbK3pic KXcWbgmVjjOGxXIz7Qma4kSbhfWqHJHJae3MVRZkLzk/EbeanhTgFznleccYs/sMgD GGWYrxS68JlJMxi69Gz4sOyrRNGW4ZiKBZGsoo2E80AFWqr3pbroEC7u2XZZy1i1wd q33B4czbpYF1hlZnrlKi6dCPEbmhRB7RSq5P1FWV+zE/pNt2jgpC1JJ+KGCk7erOp3 NzuihuFubkgkndddPxhHSUcthksxeouG045wZBNzFK9E5IP8ze1Q0UpTekZ8boK4cr E4bYxV9ir+3Sw== Archived-At: Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:27:45 -0000 On 05/22/2015 02:09 PM, Andrei Popov wrote: > I agree that sufficiently large known groups make precomputation infeasible, and also simplify both client and server implementation. > > So the immediate mitigation could be for clients to stop accepting small DH groups, and for servers to send larger DH groups (this will of course create interop issues, esp. initially). > > In the long term, it may become possible to only allow DHE cipher suites when a known group has been negotiated using draft-ietf-tls-negotiated-ff-dhe. > ( Correct me if I am wrong, but I thought that IE only offered DHE with DSS until the last year, when a security update added DHE support with RSA. Last time I checked the IE's ClientHello this year, there were no DHE+RSA in IE 11, supposedly without that security update. ) What I wonder here about is the support for DHE 2048 by the (legacy) clients on the Internet. If the server will start sending DHE 2048 in the ServerKeyExchange, the DHE handshakes with older clients will fail, with a fallback to even less secure ciphersuites. The only way I see these old clients not failing is when these clients don't offer DHE in the ClientHello, but then there is no clear benefit to upgrade the server to send DHE 2048. If ECDHE P-256 cannot be used, and absent any DHE size negotiation/signaling mechanism, fixing TLS clients not to accept short groups with non-export ciphersuites, which enabled the TS-specific attack, and perhaps switching to periodically regenerated DHE 1024 groups looks like the safest plan. To rephrase, what's the slice of the Internet that cannot do DHE P-256 but can do DHE 2048? > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor > Sent: Friday, May 22, 2015 1:55 PM > To: tls@ietf.org > Subject: Re: [TLS] Another INRIA bug in TLS > > [ i fixed typo in the Subject line because it bothered me; sorry if that > kills threading in anyone's MUA ] > > On Fri 2015-05-22 13:52:29 -0400, Santiago Zanella-Beguelin wrote: >>>> A miTLS client maintains a table of known trusted parameters, >>>> including the subgroup order for parameters with non-safe primes. >>>> When receiving unknown parameters from a server, it tests the >>>> primality of p and (p-1)/2 to check if p is a safe prime (and caches a positive result in the table). >>> >>> So you do a full primality test (Miller-Rabin or whatever) for each connect? >> >> No. We do primality tests only if the prime isn't in the cache. That >> happens the first time the client connects to a server, or when the >> server refreshes its parameters. That, assuming the parameters aren't >> already in the pre-populated cache. >> >>> Doesn't that make it awfully slow? >> >> No. The typical cost of validation is just one table lookup. This >> works extremely well when people use just a few thousand parameters >> and don't change them often. Even if that changes in light of Logjam >> (I hope it does!), online primality tests for every connection are not >> prohibitive. I did a quick test using Sage and the stock >> is_pseudoprime: testing if a 2048-bit prime is safe takes ~180ms in a >> laptop, while computing two DH operations (exponentiations) takes ~17ms. The amortized cost using a cache is of course much lower. > > I'm considering adding a Miller-Rabin primality check for the group modulus to negotiated-ff-dhe's "Local Policy for Custom Groups" section: > > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09#section-3.1 > > I'm also considering adding a suggestion for checking that the modulus is a safe prime, if it is not already known to the client to be an acceptable modulus. What do others think about either of these additions? > > ---- > > I see how the idea of every server choosing their own groups makes sense From a crypto theory point of view, and if everyone does it right, it would indeed probably be the best situation. > > I have concerns about it from a practical perspective, though. > > A client encountering a novel group now has to make a choice about whether to perform some tests on the group (as suggested above) or to proceed without testing (hoping that the server picked the right parameters). Since TLS clients are in tension between the demands of efficiency (make connections faster and cheaper for your user) and security (ensure the integrity and confidentiality of your user's communications), many will be tempted to skip the extra checks, since if the remote servers are well-configured, the check should be unnecessary. > > Furthermore, generating a large safe prime group is expensive and slow, which puts it out of reach of many devices that act as TLS servers, which practically might mean we're delegating the job of prime selection to implementors or software distributors. > > As a case in point, the SSH protocol provides custom moduli, but i believe most SSH servers ship with a set of default moduli (e.g. the OpenSSH project ships a default set of moduli), and everyone just uses those. In the OpenSSH case, the upstream moduli appear to be generated, tested and found to be safe primes on the basis of 100 rounds of Miller-Rabin (see moduli(5) and /etc/ssh/moduli on a debian system, for example), instead of generating proofs of primality (which are significantly more expensive). > > Yesterday, OpenSSH updated the set of moduli they'll be distributing for the first time in 3 years [0] (this is better than the oakley groups, which haven't been updated!). The new ones were also tested on the basis of 100 rounds of Miller-Rabin. There is also discussion on the openssh-unix-dev mailing list that different distributions might consider shipping different sets of moduli, though this could potentially introduce a distro-fingerprinting attack in places where such an attack might not already exist. > > We need protocol designs that simplify things for implementators and deployers, and that remove the need for expensive security checks that might be skipped for efficiency reasons. sufficiently large known-groups seem to solve that problem, as long as we deprecate smaller groups promptly. I'm not sure that encouraging custom groups does, even though it sounds like it would be the safer option when everyone is playing by the best practice guidelines. > > --dkg > > [0] https://anongit.mindrot.org/openssh.git/commit/?id=8b02481143d75e91c49d1bfae0876ac1fbf9511a > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri May 22 16:36:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3591A8849 for ; Fri, 22 May 2015 16:36:26 -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 NDHzmSSPvPRh for ; Fri, 22 May 2015 16:36:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5006D1A871E for ; Fri, 22 May 2015 16:36:24 -0700 (PDT) Received: from BY2PR03CA039.namprd03.prod.outlook.com (10.141.249.12) by BL2PR03MB353.namprd03.prod.outlook.com (10.141.89.16) with Microsoft SMTP Server (TLS) id 15.1.172.17; Fri, 22 May 2015 23:36:01 +0000 Received: from BN1AFFO11FD046.protection.gbl (2a01:111:f400:7c10::180) by BY2PR03CA039.outlook.office365.com (2a01:111:e400:2c5d::12) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Fri, 22 May 2015 23:36:01 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; redhat.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1AFFO11FD046.mail.protection.outlook.com (10.58.53.61) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Fri, 22 May 2015 23:35:59 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB031.064d.mgd.msft.net (141.251.50.211) with Microsoft SMTP Server (TLS) id 15.1.112.16; Fri, 22 May 2015 23:35:57 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Fri, 22 May 2015 23:35:51 +0000 From: Santiago Zanella-Beguelin To: Kurt Roeckx Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAvugSAAch4gIAAUHiS Date: Fri, 22 May 2015 23:35:51 +0000 Message-ID: <1432337750554.95436@microsoft.com> References: <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com>,<20150522175618.GA10423@roeckx.be> In-Reply-To: <20150522175618.GA10423@roeckx.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.216.4.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD046; 1:w1AN/3E9vaA6C2ts7l4etTPXneuHeENSy862+7aGsdae3Y+qzxsW8B1tdQHbUpwKVzageBT4TqZUw3sreZr/b6zgQMLMieusnOGrLoHPmoXq1p+plvprABlWvlXCGdip7kv5eiCC8OJCkJ5lRhyKcVaw4c1aYkhQznri/UWymv/MTpt5Nmk5WeGVE678BdRN8tKvThAB/b6LwMC8v8yl+o5hTTyBFnlrOJeOLh75fWkWeGa02SPwl08B6cKEkKcjaDC7PV+M6+w34lJYezJRYmCg+NDmgtYUY3+X/8YOnC6ymuth3fOjUkbgrVOquTy6 X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(189002)(199003)(24454002)(377454003)(16796002)(19580395003)(76176999)(19580405001)(69596002)(102836002)(2900100001)(15975445007)(68736005)(2950100001)(86146001)(54356999)(86362001)(50986999)(36756003)(86612001)(46102003)(81156007)(4001540100001)(93886004)(50466002)(87936001)(2656002)(64706001)(47776003)(66066001)(23756003)(106466001)(5001920100001)(106116001)(92566002)(110136002)(97736004)(5001960100002)(117636001)(5001860100001)(77156002)(6806004)(62966003)(5001830100001)(189998001)(2004002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB353; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB353; 2:V6mVVACpikg5lZ+MHKeYYN1/ujpxtFjjdBwK/6dcq+xiXu0TSazI5niTxM+bNoql; 2:CHkByA7K8b/GTu99z3E1Nkn4lTN1ZdXDl4n4+ZshX8UCOxRlMzhtc4fR4QQZZcYmpfaQ008Xl0hNkdC5DzvsPl/uwF2d7ZDnpMS3AJHHbMYFaIE3PyXyaRhBSYTAVzS/ef4ut38e9p62N8WUwDSKYTlewqgKaRPsppWT14t+CfJsft30dZg9E68BT+KVNkzVYv35YYu+xCm2yDhYhZ1IXvEPa52QrBR3M10Ad261j6WKXIohSn62NXRszKZH8aaG; 6:k8eGIPPHEDrLUbfRm1Xk+IG6NWsm3MhqmUoCoNKXbOQOgpmkidAlK5LfBvzIsOK/gVOfUtROR6tIp4qf8GlscQg1TidN2JWfmGmSGlGfbQjN2W4pohSRANmK3KPqAIsumAuKqOwfdnw+6f6kI93YDgiETyMXMFQeXiC0o2ba2/YPrZfhwqYMUaGMA0ixGpF1Um5IBZAmdir3+alStQkzAusq8BIBhscUUOonOJoPuEXCmNX4oUVCa9EMTasut6J6JYvLHtoUMLhlT3juw1V4qNly8xIvZULyUG2qnoAK75i99G9RIUT13/DBx3u+2RKFiekDj7GaTrO4kbJtGwatN73uhcV2fJssS/sq9eBdbDLoH+jlvTin+cD45ea0XHpyPGBjcwz5sE+NZNAkMxQXBd/cY2ra00nT1dSG2Yvhr37nUiTlmo5TnXqge0zmVQSYMbxFR3sR7UEcgvesr3aW1GeWIFlPoROgm/G9hvIWEJfXww8XUA9JcAaqlhfp1e4B X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB353; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:BL2PR03MB353; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB353; X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB353; 3:Qq/fjcrpZNcI/ZVN82XIyLA1hrHT2jFpT2Lwx73tmB+mOjFpMuQCBWAlHW6rykVL2QHmHKMGq2f51QlzCURqXaodbgn3BT7acVUpzwb1emufPwRAuvzRY0+vMRXdZX2uHMIOKfI/9INDWIU03wbYYqqhpQO3PGBRWkmJlEphxFXay+YPcedgr8JbQdZy2vtgmWsXBBEa1pjYsi9Yi+8iRrFfGY/N7mMLULjUVbl7UoKCzqjGpZX09QWRvZSqxPHdHS0MRtp1heee0NJJukm5z29zz3U9wVmz1mDwuXXEXG673ud3DUj2pfzlXoQV4RIaRvtC8XjwEQ1CMGiTyLvXRg== X-Forefront-PRVS: 058441C12A X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BL2PR03MB353; 9:MQPrEk8dVerVbRGhm+Kp/JpQEb39rgNIjzBvIpRL9?= =?iso-8859-1?Q?ZSE+pJmXR2jV1awhnEXdS6PIex6dykDnJsBfzsRxIL9ukJ6X4CCeT8kS6U?= =?iso-8859-1?Q?6HyS2pRgWViJr/BKm6qZym+j6PyKS2v4Yg59ZgyTc87ZO8o6K2h04cuo4q?= =?iso-8859-1?Q?7J3IRwdi3oYI5ue2xiwST3WbWmilCgsa5pYe7/rnl5Y+1O9ImrRo8rHdRN?= =?iso-8859-1?Q?jGlSGhspOrQpOHNgH5BugjnR2anJkp3n1tK+pOqL3mIFEZ2sFK7wTO7szI?= =?iso-8859-1?Q?Zjgv5aiutkCSnvikvuRTxV8IVJOkmiBkCVlFxKamo5capp7sY3DjHbzIBV?= =?iso-8859-1?Q?HXs2hPrVKMU93U2O4fH3qRHtw+Cmy0p0NvWDCUsquDp3SMZXOt6J83+IzD?= =?iso-8859-1?Q?GGI6wAjKSLgLSP6qx1xq4PvN+9s5CI43h9AGYm5KWqmmXbRB6rSqeMmWny?= =?iso-8859-1?Q?Nn8U9x+cK1NLtQf6I3POHHCfQa47Fxv/FwQaRNOPSmQhAKCuguUQ/HvuY5?= =?iso-8859-1?Q?kxcn3xOr7mUIhQWb4h3ldV8vQ8Zc5hfWNFVjvJwUbVjOByXuIOwd3zpj6+?= =?iso-8859-1?Q?Rt+Sf/zU+VlThvhxxeDG4jIX2PkFskdEWDl/Z4QeoAzQVCTW7h7xCO+9W1?= =?iso-8859-1?Q?K0uFtKQQAjl735QmbMahtBS657BsCZUAVPFPUlpL9a1n3sgcYBkpWhPfLD?= =?iso-8859-1?Q?B+n8ICC2BKWW2gA0JsXRiuOBmpdDWv9l3NBY1z125KecirzOGCEhcSX8Tf?= =?iso-8859-1?Q?dnSD3lsgZ4xvm5k0G8XfvMgOOTQzj+BSF2pMmlWTZm0C1mmKU1OL9KUCu5?= =?iso-8859-1?Q?1liax6A2jIVpkk5516grHLjdK22yinwcfG2fXuqhjar1HQ3N4Lvr96fPDF?= =?iso-8859-1?Q?TgvP9Yoa96il7gBy6qspF0uEhMXqvtGqKNWIzbVC2YfVDsXLH3ZmRDobwd?= =?iso-8859-1?Q?sV9MChV9AwQPK8hGMUaHebS6jYJubtlgNlYGJJukkg6nczIJFtoJjARD5n?= =?iso-8859-1?Q?TgTXVWMpVc3CTxiqFn18iCLjlPhPwROvl1jDd28VxWpoE3H3lNgrmGJpT2?= =?iso-8859-1?Q?bLG6zCv8uz6KzuxKP1T5y83pyaQLm+LiptrdXbmPweOlLkt8/lwFstSkWd?= =?iso-8859-1?Q?sapjLiVSUxJua+F9DDb8/H6nAZtMSyhBcWAtOB8ukHHILa8qY4Q3mY+xrS?= =?iso-8859-1?Q?dI+lnnKakRmyUXQ5Qq6UrlYLz8VCxFqLRc/Bqbu8dDhweIrEdkGkuAvddM?= =?iso-8859-1?Q?T7uIbT/bSx1V5wdGDVta5QHGIaew7ubwIR9d68BukGi9/+boJq4qB2wMcD?= =?iso-8859-1?Q?M+Zi8YrgT4saGd3K8fJt4?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB353; 3:9tuDe248Whd8iGgQ0DMhMg1hxNCax5yJSvI0eOON2Urm1oKS4/McW7sgS9VA+pORy2HMbhyUgTLlGGxfr5DpTShX+57gJfOwruvGMiHfJ0RVUmwocEm3nptXpXikxuUYLWCy7CN1iYOMRSGJNwI7mg==; 10:KXRNkxcSR0Jx6a8IFB7x1EfQL3pIamafR27xMaNvG/+gTxx6XCOzVEEBEF59Ngkd9zc/LJ3GHZq6iwIYjcCECkVW2YyDoNVp0mvi7tUWQv8=; 6:/Z0Mgl7YPVuuWifuABkuQNqi+5w/bUhi6WpuF8j+0aBnzLNM3DLi68Vri16up+NZ X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2015 23:35:59.3679 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB353 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:36:26 -0000 Hi Kurt, > > (http://www.mitls.org/). > > I was unable to get it to build (using free software). I've just succeeded building mTLS-0.8.1 using Mono 3.10.0.0. I haven't trie= d Mono 4 or .NET core (MIT license). You can send me a private mail if you wa= nt me to help you troubleshoot. > > If the modulus is prime but not safe, miTLS > > checks if it is in the table of trusted parameters and otherwise > > rejects it. > =20 > When is it non-safe but trusted? When it is in the table of trusted parameters, and hence we know the subgro= up order (the prime q in DSA terminology). Just to avoid misunderstandings, we clari= fied the formal meaning of "non-safe" earlier in this thread. > > I think a table lookup per key exchange is about as reasonable as it > > gets. > =20 > I assume that's a table lookup in case it hasn't seen that prime > yet? =20 It's a table lookup when it *has* seen the prime before. > But I understand that they're recommending everybody to generate their ow= n > prime. I believe large >=3D2048 bits fixed primes, like the ones proposed in the negotiated-ff-dhe draft, are fine for the time being. See Karthik's message= on this same thread which better clarifies what our recommendations are. --Santiago ________________________________________ From: Kurt Roeckx Sent: Friday, May 22, 2015 6:56 PM To: Santiago Zanella-Beguelin Cc: Nikos Mavrogiannopoulos; Florian Weimer; tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS On Thu, May 21, 2015 at 02:52:47PM +0000, Santiago Zanella-Beguelin wrote: > Regarding validation of DHE parameters and how reasonable it is in > practice, I wanted to make some publicity for miTLS > (http://www.mitls.org/). I was unable to get it to build (using free software). > A miTLS client maintains a table of known trusted parameters, > including the subgroup order for parameters with non-safe primes. When > receiving unknown parameters from a server, it tests the primality of > p and (p-1)/2 to check if p is a safe prime (and caches a positive > result in the table). If the modulus is prime but not safe, miTLS > checks if it is in the table of trusted parameters and otherwise > rejects it. When is it non-safe but trusted? > We distribute miTLS with a pre-populated table of > parameters which we tested thoroughly (and we welcome people to test > further). Most of the time we hit an entry in the table. > > I think a table lookup per key exchange is about as reasonable as it > gets. I assume that's a table lookup in case it hasn't seen that prime yet? But I understand that they're recommending everybody to generate their own prime. Kurt From nobody Fri May 22 16:45:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577AD1A87C9 for ; Fri, 22 May 2015 16:45:14 -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 juW9q298nPTt for ; Fri, 22 May 2015 16:45:12 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::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 A27351A8784 for ; Fri, 22 May 2015 16:45:12 -0700 (PDT) Received: by yhcb70 with SMTP id b70so8014590yhc.0 for ; Fri, 22 May 2015 16:45:12 -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=/9wPGUx9Dx2D0umkwaY6x6Y2YoQaFfiTVphcw5cdI2I=; b=oLrd4794PnsVB43lmzew3I2wXqIjE+LqdI0tM/exIbnsbAScD/oqAsYSQorIDM1YqZ c4G8UTQP26G52jMO5QAGQUS2IIXgHF2tTYZ1IyMQO37cf9/O0NpomVdjagmPwox+Vp/R DJ6OkBkJQ5ArJFHOtXgAK+5WtJF352soZYQZFVbt+DrQ5uuCC0L0I3gNWkqgQznVINNU GQVgKrkHMehMFXUSDDJjQAElbEHOa1s5fmewLGgvI2ZNLn95Y90w79V3GOEVXSJNihZQ xSvzMBUtBc69UyZXD8WnhjkOsP2/iM52wcHTE7b/nX6oIXGOlBsQwWErXRRqV3jKpHaX pWFQ== MIME-Version: 1.0 X-Received: by 10.236.106.74 with SMTP id l50mr10594291yhg.143.1432338312047; Fri, 22 May 2015 16:45:12 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 22 May 2015 16:45:11 -0700 (PDT) In-Reply-To: <555FBB6A.7040508@brainhub.org> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> <555FBB6A.7040508@brainhub.org> Date: Fri, 22 May 2015 16:45:11 -0700 Message-ID: From: Martin Thomson To: Andrey Jivsov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:45:14 -0000 On 22 May 2015 at 16:27, Andrey Jivsov wrote: > To rephrase, what's the slice of the Internet that cannot do DHE P-256 but > can do DHE 2048? I can only answer for the slice that I see, which is mostly server behavior. Are you asking about clients? >From the client end, we see 4-5% of connections on DHE[1]. Most of those servers choose 1024-bit groups [2]. [1] Values in the 20s: http://telemetry.mozilla.org/#filter=release%2F37%2FSSL_CIPHER_SUITE_FULL%2Fsaved_session%2FFirefox&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph [2] Guess what means what here: http://telemetry.mozilla.org/#filter=release%2F37%2FSSL_KEA_DHE_KEY_SIZE_FULL%2Fsaved_session%2FFirefox&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph From nobody Fri May 22 16:47:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAB31A88D0 for ; Fri, 22 May 2015 16:47:37 -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 rENlDcnewZuO for ; Fri, 22 May 2015 16:47:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F7E1A87C8 for ; Fri, 22 May 2015 16:47:35 -0700 (PDT) Received: from BN3PR0301CA0047.namprd03.prod.outlook.com (10.160.152.143) by BY2PR03MB364.namprd03.prod.outlook.com (10.242.237.17) with Microsoft SMTP Server (TLS) id 15.1.172.17; Fri, 22 May 2015 23:47:14 +0000 Received: from BN1AFFO11FD009.protection.gbl (2a01:111:f400:7c10::187) by BN3PR0301CA0047.outlook.office365.com (2a01:111:e400:401e::15) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Fri, 22 May 2015 23:47:14 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; cs.auckland.ac.nz; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1AFFO11FD009.mail.protection.outlook.com (10.58.52.69) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Fri, 22 May 2015 23:47:12 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) with Microsoft SMTP Server (TLS) id 15.1.112.16; Fri, 22 May 2015 23:47:09 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Fri, 22 May 2015 23:47:09 +0000 From: Santiago Zanella-Beguelin To: Tanja Lange Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AdCUn0KvDdHZ+lmQNUW54l67jurcrQAGEh4FAAqyaQAAAcVhKQ== Date: Fri, 22 May 2015 23:47:09 +0000 Message-ID: <1432338428908.4667@microsoft.com> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com>,<20150522225500.GH20757@cph.win.tue.nl> In-Reply-To: <20150522225500.GH20757@cph.win.tue.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.216.4.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD009; 1:49/kLaTjv5WAofS6+lO3beR73k4DAH29eNXu6ChkeaU+0saR4i5lx5Mj7EzdZuGR67pPo22zhO90f2sRTLqYYpjb63oB7azB84g7O9NX9ipaBFeKK1xC0HRb39V/14UQ17Jh11j0/NyZASUp1+AlGd4ngPv4+AunlKYUrJ5kEQ/30uEkuzSLQQEZtAwrInUgRMSToZK1HoBynkH7vsnIHPSD2m5PvGUDciFwH2LyLZqYlpyHo2UP+UiUvSuUpqeXcIqzJ74/r6SjsyNNrpaISKKaf2REeMw4XP1WHQL/1ZIFjbTTfCk0NwGWZFd7Sgr9 X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(189002)(51704005)(377454003)(62966003)(36756003)(5001860100001)(5001830100001)(106466001)(97736004)(86146001)(5001960100002)(81156007)(77156002)(64706001)(19580405001)(69596002)(50466002)(19580395003)(86362001)(189998001)(47776003)(4001540100001)(110136002)(68736005)(23756003)(2656002)(102836002)(87936001)(76176999)(16796002)(54356999)(92566002)(50986999)(15975445007)(66066001)(46102003)(2950100001)(2900100001)(86612001)(6806004)(117636001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB364; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB364; 2:KzUj05mzNVaKdEfOJupN0ZjxNGd/jxsja2CnnDHdPp8Vf5cGQHZjTurE22HRzNfi; 2:kykaXskx/bv2Vxm3s22NXlD8OxPYZqx10l8QoEX6Yfac99XN64ku+IaOPf1O6sCU4JvZVJj9Zp8ktp38kmRbqTVQih44fcdQwN6ZJT2vKK7cbNsX8xnuvgbig3vvw/vPWaB0w+hykU3AmYItC4jrX6L21fBR7m4xgpD/j8P8jRpeFfH5DB8NkbDCpAbWJTq/LrlDD/hqnhxw9mt4YS5WGrg4UZJOQ3GgPv8gPdxtcaSJdLzf7KckviOQmvMeFrNw; 6:Wltk+sPld/JTN8qx7fT8vaVODTLnNNYISMCIHXDBpKBpk0zwi7cFDnOmDfS9aoAt69Q89ikEwaV/b44K4FTHXoC3+0UoNGRm81wsoQ3SIGXttAtrzF3F1eqRUktUljguwEsFGJo1SR+pc3cdTL3K7Qxj1D1PmmJ3oQykZv40Qsvq7ojE2mxTxabprK+EmYeHwLmfAYfemnOORu1naK6FrYEcEl0YgLKrPJe9Qf1zj7qjTZJ5jVSb1XPRN6HfxbHahlW7xCBsDk7OwIHoDOGnhDlFOXvAkvU3dMPmsQhCkXyKw5VfraG2lHehozvH/31vbxvd+x6jX6k0mb5gTzxEf2zPcwyswmgqAx7BfgWc/eM7GxxsLsB8g6tkNqHBLZZHmo5pHuJc8C2WdDTXE/1w//9pbJ9m17lXLVDvBlEOPJkxq1EYzJEn5tihz0ia5LbXjxl4Zfy9UHLMA9Y90Isi6apjfBuG+RqWkFwLsrZ7kXfJyuQtESGUoDXUPqeDw88F X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB364; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:BY2PR03MB364; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB364; X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB364; 3:Z57MxWuq1ooGHXfrdEzWrQoJW0bc+0f3KJdrYtR31MmOd3GstSeFeL4BG63ep7ipfYeriBk1DEbALtLyDRJprL8Xw7s/9Kp84fd6ZIoT6MjXv9DaxGpWlLrqi/0PDfc4E2Yn7vkKqHhx/62DEiH5DGZrXP7hv/iy1Twe65FrgNFcSoFNUrzQSLM8qSNAC089QOHYfe4x+KUux9EJdJ9xr3/kzuv40nmoOwTpRKEYMkzSUTs2H0WsodAG9AwVE+SQh1J1X1B95PaNRb/djZyCYaJcFD5nZNVoAZGbRRUymjZhbUBjWx0pt6Eh7qkfcz70SA7rizvn2hwpO9CoY16sBw== X-Forefront-PRVS: 058441C12A X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BY2PR03MB364; 9:uGPdEqvIeY4iSX8BcGu7sTvaTvN62D/vS9tSk1z6h?= =?iso-8859-1?Q?ONQNjDGxYyEwBxAonf7wtSIwKF1ffBiZcIwlxPBCOH0KwnWYNctdunv/7n?= =?iso-8859-1?Q?GxXPDOAf7MYPecn4jnNUDa0Dux6ET/Vc4NxMhVGqzABmF71U2c6GgXwvRV?= =?iso-8859-1?Q?6pp5DWW3Pm8CoT0zAWcecVBbOc9CxIlUingarrJJz1D6Xju1MbCShQWyWz?= =?iso-8859-1?Q?kTAjky2/UUzLgya48GQFTG48tRfx+dRzTeeHQQBNbj2KEAD3UasC7cTTSg?= =?iso-8859-1?Q?p+qCMGRSUFaimFGcyJo2XHGGteEV1oS2u6OcdTV3Q8dL0sF50DUB6v833I?= =?iso-8859-1?Q?1KK2cULYcfYQki/gDwOECGUw7Wq79w+pvE9gGWZBRYJ7rU5BZWBXOVdZVR?= =?iso-8859-1?Q?6iunWSPoqgXsWX5BMWLWxf+GoMokaeFCzwdDvwIQObsgSWhv6wbKk6TmW1?= =?iso-8859-1?Q?iivcW9E1J52Sv118pmwY8fYJF7M+i86os45Oci6ymQQ0HsRfINiHLDN/js?= =?iso-8859-1?Q?foaiO9QxuyyDJypsPvgRyKahKWbCYYLCEWNotkw2ZYtm4K6zBNUYOOTlnI?= =?iso-8859-1?Q?yO3Wgd0mFQnZEGbR/bEYRKcMsi8oP8EWqbTzOVepnUVpgzPWefZBLPT/c4?= =?iso-8859-1?Q?XeAGxOscG/gYZk+egiUOV4+7WNDJ4mpx78j2ulMB1vsJ6wZiVONXCWrwDF?= =?iso-8859-1?Q?PAG/KxBJlgNaw2EuInzZwQyDSDoB8z8jyfg06lhqGQYwUOk6DMFEiaVC2U?= =?iso-8859-1?Q?7T5/90ckzA6VDPFcYxJPxe5knM/V9Squ7aqBJkI9U/FEbv451qgRTveym1?= =?iso-8859-1?Q?f3pG/IM7AP/vPzNXu8gnAdgostKKVUIgpcI59vGd2MIArDFiAsA70rrj+Q?= =?iso-8859-1?Q?0v6WEZdlR3wehfQwmILs37rBGE4rf5p4at1T3iWITxEa+j55XWvw6Yhq09?= =?iso-8859-1?Q?AQlcbaeK+7UCj61GqYjpXYKhF9hL0QOm3SdoQFO62siPA2G6rP85laDCkO?= =?iso-8859-1?Q?oUBuJRfkRbHi2P16vPyILfsxqUJtmWV4VYBj4qMD8VfZEq69nSyfMZE2+l?= =?iso-8859-1?Q?LF3R3D0kEn9VYTab+snhYDRHcg7XQ2WmkLwdZX2A5hwyxBHPbKiplP3tkD?= =?iso-8859-1?Q?7G+gI4iAnnkWag0oUTiEo5bjUADJHRkEUdbt86VfxGfa6ZDlY1vl2TpOT4?= =?iso-8859-1?Q?fXgshj9dH?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB364; 3:fAIk8epjDCanCrZ5wY1otaq+5wsxK7QGMkPxZVWDuMCtGEUktWFPQs8R7KnGMoZ3QShCWb9wL4vxm5p5431O6Q5MolpBtbPoyF1TyjNEBADqil13gINy6roHiCjPDc54nPd84Lnq8f/hoSROEg8VNQ==; 10:x8Kt2ayp1Lu33ClMflXKpsgjubdJ94IHyG8W9Td47WvDeeFaArU+bgiq4pJ6n4bgyD3cgo/hQtN/eZidDXTAO1id+v7vj/JpFWPl4bAifqc=; 6:q5726xs6JOZrxjevVesOHshT8ElVlJkxN58od37/csBeEFDWB2uFAvRCNgxes1WE X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2015 23:47:12.9863 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB364 Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:47:38 -0000 Hi Tanja, > What algorithm do you refer to here when you say that the NFS > precomputation gets easier. The only thing I know is that you > can solve the matrix modulo the group oder (or using fewer > moduli when using CRT), but that's a very small speedup. That's the only speedup I'm aware of, and it's indeed a small one. (Table 2 in https://weakdh.org/imperfect-forward-secrecy.pdf has=20 some estimates.) --Santiago ________________________________________ From: Tanja Lange Sent: Friday, May 22, 2015 11:55 PM To: Santiago Zanella-Beguelin Cc: Peter Gutmann; Subject: Re: [TLS] Another IRINA bug in TLS Hi, > > What testing do you do on unsafe primes? > > We accept them if they're in the pre-populated cache. If not, we reject t= hem > because we can't check the order of the generator and validate ephemeral = keys. > Unsafe primes have other problems too, e.g. NFS pre-computation is a bit = easier > than for safe primes. > What algorithm do you refer to here when you say that the NFS precomputation gets easier. The only thing I know is that you can solve the matrix modulo the group oder (or using fewer moduli when using CRT), but that's a very small speedup. Tanja From nobody Fri May 22 23:22:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A911B1A90EE for ; Fri, 22 May 2015 23:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf9Dy0hWkhHr for ; Fri, 22 May 2015 23:22:00 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29621A90EA for ; Fri, 22 May 2015 23:21:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,480,1427752800"; d="asc'?scan'208";a="126054587" Received: from 178.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.178]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 May 2015 08:21:57 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B3873D66-92A7-42DC-A9E1-A238439E6D50"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Karthikeyan Bhargavan In-Reply-To: Date: Sat, 23 May 2015 08:21:56 +0200 Message-Id: <578DE2AF-A139-4CDC-B71C-C67C28267FCB@inria.fr> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 06:22:04 -0000 --Apple-Mail=_B3873D66-92A7-42DC-A9E1-A238439E6D50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 22 May 2015 at 14:09, Andrei Popov = wrote: >> In the long term, it may become possible to only allow DHE cipher = suites when a known group has been negotiated using = draft-ietf-tls-negotiated-ff-dhe. >=20 > That time might have come sooner, if it weren't for the > misapprehension people have been given regarding custom groups off the > logjam mitigation advice. I think that Karthik's clarification [1] is > much clearer than the message that has been propagated. Apologies if the paper led to any confusion on this, we were summarising = lessons for all DH-based protocols, not just TLS. Yes, we *DO* support wide deployment of the FF-DHE draft, because (a) 2048-bit groups are believed to be currently out of reach of the = NFS-based technique considered in our paper, (b) generating safe primes based on a public value like =93e=94 is = believed to avoid trapdoors (with high probability). The =93avoid fixed groups=94 recommendation applies to 1024 bits (and = any other group-size for which precomputation becomes feasible.) Having said that, it would be good to set up a rigorous mechanism for = =93retiring=94 DH groups and EC curves as their expiry date gets closer. DHE_EXPORT has survived 15 years after = deprecation. Cryptographers have recommended against using 1024-bit DH groups for a few years now. = We=92re going to hit the same problem with curves at some point. One option is to periodically obsolete drafts like FF-DHE, but would = that just make a mess for implementations? >=20 > [1] http://www.ietf.org/mail-archive/web/tls/current/msg16496.html >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_B3873D66-92A7-42DC-A9E1-A238439E6D50 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVYByEAAoJEB/WSo9veuUK4vAH/27BLGkInWmo+S+cZOEfZbvC xAqzoAnkj+TjsExIabCa/RpZqQjIcWvGQFk4JGwpHDyXJ6WuSLzLMfIXq+SfEovA l3o2ip91Mkli2YH0EzZerqptIwr3Xl9N0gKqdhLRUqGXcQdUfc5chwlaTvVPUG07 SNJ/Z2Ng/Pq05Rcipr9XaFDqvDX8Lrfe/qnSLAs32Cj7Ww7R5vRn7v8RTEpWO2DE qwPy3pKfAitSWlbOfZTJFtT2BgElLyjeC9gpidCKIxB4pZIvh8yZFEQualiOm0w4 KWBtA3e3XvVtlHoG05eU/2a4zjNSTK4aSBzuMJ6augUzf1ME6eM8OOpGNmPyFZA= =yss7 -----END PGP SIGNATURE----- --Apple-Mail=_B3873D66-92A7-42DC-A9E1-A238439E6D50-- From nobody Sat May 23 03:16:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B001ACD46 for ; Sat, 23 May 2015 03:16:16 -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 rn8sqWtISMza for ; Sat, 23 May 2015 03:16:12 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 01DF01ACD44 for ; Sat, 23 May 2015 03:16:11 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 8B42F1C21B7; Sat, 23 May 2015 12:16:09 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 688B91FE014F; Sat, 23 May 2015 12:16:09 +0200 (CEST) Date: Sat, 23 May 2015 12:16:09 +0200 From: Kurt Roeckx To: "Yngve N. Pettersen" Message-ID: <20150523101609.GA9409@roeckx.be> References: <1432141085848.37685@microsoft.com> <1432193344.3243.2.camel@redhat.com> <1432202373093.34978@microsoft.com> <9A043F3CF02CD34C8E74AC1594475C73AB028124@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 10:16:16 -0000 On Thu, May 21, 2015 at 12:10:07PM +0200, Yngve N. Pettersen wrote: > On Thu, 21 May 2015 12:02:19 +0200, Peter Gutmann > wrote: > > >Santiago Zanella-Beguelin writes: > > > >>We did find many HTTPS servers supporting > >>TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA. > > > >Just to make sure that's not a typo, you're saying you *did* (not didn't) > >find > >many servers supporting 40-bit DES as a cipher? Wow. How many > >approximately, > >are we talking tens, thousands, millions? > > For reference, in my 530K sample (Biased towards Alexa top million sites) > there are 60000 servers (11.38%) that have that specific cipher suite > enabled, as of Monday this week. Hubert Kario's latest results on https://securitypitfalls.wordpress.com/2015/03/29/march-2015-scan-results/ show: EXP-EDH-RSA-DES-CBC-SHA 22110 4.5043% Kurt From nobody Sat May 23 05:12:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4251A1A4E for ; Sat, 23 May 2015 05:11:58 -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 GndVn_8OPDTU for ; Sat, 23 May 2015 05:11:54 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 203961A1A42 for ; Sat, 23 May 2015 05:11:54 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 467AC1C21B7; Sat, 23 May 2015 14:11:52 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 152E61FE014F; Sat, 23 May 2015 14:11:52 +0200 (CEST) Date: Sat, 23 May 2015 14:11:52 +0200 From: Kurt Roeckx To: Karthikeyan Bhargavan Message-ID: <20150523121151.GA18846@roeckx.be> References: <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5DDF130@XMB116CNC.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 12:11:58 -0000 On Fri, May 22, 2015 at 10:36:57PM +0200, Karthikeyan Bhargavan wrote: > > > I think the authors felt the same. But in Section 4 of the paper, they said: > > As one of the authors of the paper, let me try to clarify our recommendations a little bit. > First, we only know what is broken, and can only make precise recommendations for avoiding the attacks in the paper. > Figuring out what's a good long-term alternative is for a community forum like this to decide. > > If we were to make a recommendation for TLS, at least as it is used on the web, it would be as follows, > in decreasing order of preference: > > 1) Switch to ECDHE. > It is faster, and the kinds of attacks discussed in our paper have not (yet) been shown to be effective for the common curves. > As usual, we need to be wary of weak curves (160-bit) or curves that may have been generated maliciously. > We leave it to the EC folks to tell us what are good curves to use. > > 2) Switch to stronger (>=2048-bit) DHE groups. > If ECDHE is unavailable, we are happy (today) with >= 2048 groups as suggested in the FF-DHE draft. > As usual, we have to be wary of how these groups are generated, since there is the possibility of trapdoors being built in. > Using well known constants such as pi or e as the basis for prime generation (e is used in FF-DHE) is, as far as we know, > a safe technique for generating a group with a low probability of a trapdoor. The weakdh.org site currently says: | If you run a server... | | If you have a web or mail server, you should disable support for | export cipher suites and generate a unique 2048-bit Diffie-Hellman | group. Should that be changed to "and use a 2048-bit Diffie-Hellman group"? Kurt From nobody Sat May 23 05:30:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84361ACDC4 for ; Sat, 23 May 2015 05:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYoCD3KNwlyD for ; Sat, 23 May 2015 05:30:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D218F1ACDC7 for ; Sat, 23 May 2015 05:29:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E2699BEEB; Sat, 23 May 2015 13:29:56 +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 wLZDAh_jvszj; Sat, 23 May 2015 13:29:55 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.24.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D41F7BED8; Sat, 23 May 2015 13:29:55 +0100 (IST) Message-ID: <556072C3.9010808@cs.tcd.ie> Date: Sat, 23 May 2015 13:29:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Karthikeyan Bhargavan , Martin Thomson References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> <578DE2AF-A139-4CDC-B71C-C67C28267FCB@inria.fr> In-Reply-To: <578DE2AF-A139-4CDC-B71C-C67C28267FCB@inria.fr> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MfMmRonVkEkqgs4rHtJ3LxWRD9t9rK0bS" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 12:30:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MfMmRonVkEkqgs4rHtJ3LxWRD9t9rK0bS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 23/05/15 07:21, Karthikeyan Bhargavan wrote: > The =E2=80=9Cavoid fixed groups=E2=80=9D recommendation applies to 1024= bits (and any > other group-size for which precomputation becomes feasible.) It's a really good paper, but if you have the chance I think adding the above clarification would be very good. Cheers, S. --MfMmRonVkEkqgs4rHtJ3LxWRD9t9rK0bS 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 iQEcBAEBCAAGBQJVYHLDAAoJEC88hzaAX42in84H/imRLCOk32TpKikRyXoRbLSE JRRUBBAesHUmT0L9xb0NAxSytNVE5LC6FGOLNrSql+Wtugjh1GuMKYv60hRC5/78 WQcReuMTEWm8f1hBPq0SWwIrFTwi6kHhsGVmFdLGD1bR5Ikt6PUp5QhSPzjqfAZb A0/AS5qwZo81Bs0l4qUugeF589a5KjOnCG+F2QX2F9phunn4GN/bCKCDmgjzDfRE JpUWg4N5JI4zLM4bwabYvdxdN9d24TI9C+RW4c02UQ6eaTGu15ha4ZAtAZbvtORD aCs6yxTforYyZu/DrVaAk2pDk0VQV3wDblB5QxgSjuMFJwOTYaPU6yfudrYQSME= =OAD8 -----END PGP SIGNATURE----- --MfMmRonVkEkqgs4rHtJ3LxWRD9t9rK0bS-- From nobody Sat May 23 06:11:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5971A1ACDF6 for ; Sat, 23 May 2015 06:11:03 -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 h0-Kp9glQMrf for ; Sat, 23 May 2015 06:10:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE2A1ACDFB for ; Sat, 23 May 2015 06:10:58 -0700 (PDT) Received: from CO2PR03CA0013.namprd03.prod.outlook.com (10.141.194.140) by DM2PR03MB302.namprd03.prod.outlook.com (10.141.54.13) with Microsoft SMTP Server (TLS) id 15.1.166.22; Sat, 23 May 2015 13:10:54 +0000 Received: from BY2FFO11FD019.protection.gbl (2a01:111:f400:7c0c::132) by CO2PR03CA0013.outlook.office365.com (2a01:111:e400:1414::12) with Microsoft SMTP Server (TLS) id 15.1.166.22 via Frontend Transport; Sat, 23 May 2015 13:10:53 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BY2FFO11FD019.mail.protection.outlook.com (10.1.14.107) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Sat, 23 May 2015 13:10:50 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) with Microsoft SMTP Server (TLS) id 15.1.112.16; Sat, 23 May 2015 13:10:48 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Sat, 23 May 2015 13:10:48 +0000 From: Santiago Zanella-Beguelin To: Kurt Roeckx , Karthikeyan Bhargavan Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAvugSAACP5AIAAEpwAgAAutACAABOIAIABfImAgAEFNgCAAA/ZBw== Date: Sat, 23 May 2015 13:10:47 +0000 Message-ID: <1432386647254.97150@microsoft.com> References: <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5DDF130@XMB116CNC.rim.net> , <20150523121151.GA18846@roeckx.be> In-Reply-To: <20150523121151.GA18846@roeckx.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.216.4.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD019; 1:DBY1kumyq/MgZNWRbU40Xd4nAlJgihY8oANPTamFwwUq1dizZXilvk7MsoctpO6f2OfzCYcTOVihlgvyU+jXW9rEozLGHcpqBFLI7nPNCxWX+v73tVTfuh9N7b0HPL0b+QhVZrB1yxjvmZDXnVkq0B+cGpuru/c4LjGxEl9FIr/V7+CJAWI2JeNsH8CuPd+Dy7nD5LgRsycXaVUGoEUDGSPAXmixpTfkLGtF3wXOutzSGHd1Te+vhxVDNvq2kv0+FMJh6mVEUIwkP562YUVKEMtwYuNlnoVfyzmpxKuGmb0eHTe6IV7p+cHSLl+RBQzK X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(24454002)(51704005)(199003)(189002)(102836002)(15975445007)(46102003)(2950100001)(19580405001)(2900100001)(86146001)(6806004)(117636001)(68736005)(86612001)(5001770100001)(5001960100002)(5001830100001)(92566002)(77156002)(62966003)(5001860100001)(76176999)(69596002)(54356999)(50986999)(189998001)(4001540100001)(97736004)(81156007)(16796002)(93886004)(86362001)(2656002)(19580395003)(87936001)(106116001)(106466001)(23756003)(64706001)(36756003)(50466002)(66066001)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB302; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM2PR03MB302; 2:6EV8oaOv3fu0LuQubCkCLjARQEtK9mcBN/mJo+I9wB54vuf7WV35xuRDofXTV353; 2:LTDjczdkDxJSzzhAOo4HsPQSZ6Qctn5hC2NjVCkNBnl7lNXxhMwOBTc9ga184G3W0TntfwK09k4FsGQYrc7cE3AIyFmXhH9/FL9z9nsKAb4uGoD4JZ0Dfo9rLFBuQNO08OXJ/lx0Zn04AzM+vxmnp/AFXRPejBDht6onYUSzkas6DBSHvGhpydE3vrAGoo18ZJqGF5O/OK5dgGZztwwXi7SyGCQlfwoPxhNHy+FYY44edCNg9DmFRePabyTSU7bD; 6:BOWDeQ0dgjziP+WjW1GJ9QAdkzyYCW0Iv8jUqtWCwIHC7Nc97Y33HlygWzfNiX4FZaMotGnSLXRDTOn3UJ8wdHP2oyteZH7oO/BCb6feLWYyLcPLNx8t4/59c+HJLy4b5jM9XehMGccDIx+XwBQuBBIjpZawJYJ09I7Pu8W9Doy1f5ReJn6Rm5oFUpXU0lSRfXcYC5b1Yb8HtM1d2m0Q/0HyYg3TR9o/QjzknUWXFjqkt1EMZPJ5H+n/dv1Bweqt6ZxkwM60r8svCzNb0mzIA9JphOAOL9PkxVjSFJoB/sN2O0OrinJ/FxPUE7nGt2kDKVE4b9WWVKgIQ71R1unmli1I8R77ApwIWikngcbEjTXIy7W1ahZryW0WecRZtSAeCUY2JIG3HKq8ZU8P/xvD494qD5IDrtpyO+Isq/eE779qsAsJ1zZex9Yuvps0JU7G5gFU6lo3vAaofU0ZtAwBG5Usatu3x0I2pT0mVOL4Tm6dJGsHD6Gf6Zrhp5NmDhM4 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB302; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:DM2PR03MB302; BCL:0; PCL:0; RULEID:; SRVR:DM2PR03MB302; X-Microsoft-Exchange-Diagnostics: 1; DM2PR03MB302; 3:n/f1ltz4/LbWdpJqCsSM7odu9D686gtTui5Y+nFuWWXajRp9w4oO5IT1jsseErWUWUoGREebiY8od/a2Wze72/cWPkgCshatdimWS6C5vo04UaYHDLixSoe5I1Aozce0CLC+fNlBm8wSeYTjsokQVwN21ia2hMdnR7YT77eCoKhelUlIpwD322QGp43BJSMM1o8BcUeqRzBZ3RnxAkBeq9b3Ig/PTkgBHYb1q5kVnMsbwROVGeqlLMDbdFj5p1UsW7y30RY5FdxktD9MYA3MoEpgVc+COxSE7YQDLvgBezNqniicZEoG/KKqKd3BNpMvMy4hdPLL5En/t07TNyMwuA== X-Forefront-PRVS: 0585417D7B X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DM2PR03MB302; 9:81/+wR42unKzovkJw8zv30Sgp38IdSpt8+xEELw1l?= =?iso-8859-1?Q?OkmrGYOhZ6f4mrDZH4GyFvUELZ8F21EggkNgya5FnZnNWu7c5RLVeQhwKY?= =?iso-8859-1?Q?vgdVcS7U38odtQKhw9CTBRAyYy5FnJlg4otcIzFo+chBoS+uETDQbQuOJt?= =?iso-8859-1?Q?PTcp5Lpdl0S9kGjHOgFl9UkgAIKUw4ORQDWG2aQg/UysHOAWatx2zyxjeO?= =?iso-8859-1?Q?k6B6jeeIinXs73bUui/b2y5/Y3T9jx3WYqOeMINMJWT1VaJH73tLlCejEg?= =?iso-8859-1?Q?FQGBZD7XEvROjv2id/VlEVT6GLrvh9FHyrTrh5SJ6e3Tq4ppq//WY3T8Bb?= =?iso-8859-1?Q?cu6WIt1HnCrc93Xiz1A5N2aVhKVjxUkMU7+5XqZVua5pVR12/58f0UMOL9?= =?iso-8859-1?Q?6R15PWN6dYGqUrrx0gLOS+xAuv2h/dpQWLU8Rhodx7mOZvvU9IQzNpwJvf?= =?iso-8859-1?Q?xulvb9Mt2R5FAIZuGRi2DGiu4EwfRg0QpceXQSjA0gtZAbmZn/nsLoIfU2?= =?iso-8859-1?Q?8nOrbl/KmsyWcZgNou7T9w2UwYSG3sfj41gm/TSz3DxNn/Oh5mym7gt4CF?= =?iso-8859-1?Q?DETiPSguoTQ8s9LDsXM3lsmysJYzViKxmWYLIvlZo/V5mIGrYWTgOwt3CH?= =?iso-8859-1?Q?lhOodlX63aWqOwXTvKohPnL7DkbDmbzVr6Sm1FqNnqgjMdc8XQjfl1H9LH?= =?iso-8859-1?Q?l2sCYQCzw9PWv4UtPjxUbxgA28Cf1ySdsSnestWsHIUyBFWEXxfcmZUsS1?= =?iso-8859-1?Q?OjSuAnLzcTn5Z7xh4z4NC+vlyZn8cTLSBySm/Nb6+7xeNLsxHQlWVqMQhi?= =?iso-8859-1?Q?+7x+5nD4sR/aG5/kY4GHQqP5WRgIaXRYl+wYxKj9SyfAzPMIjjmzEeYl/e?= =?iso-8859-1?Q?wOId3VieFUzQwQO2FV9pUa5Jen7pLqyBw+G9RhVpzI9CfL/VUjXbyYJoIl?= =?iso-8859-1?Q?iVX7nW2UfE0au5QOOXqBmStzwVjLCwBwa4TxHUg7xg909BZLjctvbzR5Eu?= =?iso-8859-1?Q?pFlEPFX48MQM5qMYHnPalN3wkWa9aQ0/Px9WugXkL3HVQlYKUuAau8npzr?= =?iso-8859-1?Q?kYk30vQ4U3nlcMLu4cNJLJ72+Oqr3epgaRsCto977ikI31ppeJJJmOXZ7K?= =?iso-8859-1?Q?LLexbjRGB1pSKmUJbYfvtstBiAOj9kOFL8sMwxoqQvRmF3eEFwAHaNRa/F?= =?iso-8859-1?Q?M9LB9mUU3mVNajhr4btZbIk/yXcrtDe5jMu3yodkEbXGzyG91AEaVBs3iG?= =?iso-8859-1?Q?QcFQimx6viuXlnL6daULsfJXKyOoAILGHlasQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR03MB302; 3:mOnDGkqcqy5dLmT+1xchBdXSVE1wp3ENOFUGgF+tIzE2+KwkSWCOZEGV7utPD5a9NnrxEtnm4v6PwQAqN5PidpOhNHpcTDbi5u7V2zU0HyooRrDN2k0Hp9PFtZx5vZjQcdAbF4H6vj3toHAHUolgKw==; 10:kdRzN3lZIHFSxQC6+l5Vy4C90ixnJfL+tovGHUE5Toxo4lBLp2Da8/VlpLf7ScK9l31CquJGeHHFuwOh6XkFKBUOvf41FIafT73CjXpE6e4=; 6:OXmSNJuyNWOv+OjBmYxgOzj0m49eNViI9SMkXc+50bY3iJdI3imViaQECdXEo+um X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2015 13:10:50.9264 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR03MB302 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 13:11:03 -0000 > Should that be changed to "and use a 2048-bit Diffie-Hellman > group"? It should. We'll soon update the website and the report to clarify this. ________________________________________ From: TLS on behalf of Kurt Roeckx Sent: Saturday, May 23, 2015 1:11 PM To: Karthikeyan Bhargavan Cc: tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS On Fri, May 22, 2015 at 10:36:57PM +0200, Karthikeyan Bhargavan wrote: > > > I think the authors felt the same. But in Section 4 of the paper, they = said: > > As one of the authors of the paper, let me try to clarify our recommendat= ions a little bit. > First, we only know what is broken, and can only make precise recommendat= ions for avoiding the attacks in the paper. > Figuring out what's a good long-term alternative is for a community forum= like this to decide. > > If we were to make a recommendation for TLS, at least as it is used on th= e web, it would be as follows, > in decreasing order of preference: > > 1) Switch to ECDHE. > It is faster, and the kinds of attacks discussed in our paper have no= t (yet) been shown to be effective for the common curves. > As usual, we need to be wary of weak curves (160-bit) or curves that = may have been generated maliciously. > We leave it to the EC folks to tell us what are good curves to use. > > 2) Switch to stronger (>=3D2048-bit) DHE groups. > If ECDHE is unavailable, we are happy (today) with >=3D 2048 groups a= s suggested in the FF-DHE draft. > As usual, we have to be wary of how these groups are generated, since= there is the possibility of trapdoors being built in. > Using well known constants such as pi or e as the basis for prime gen= eration (e is used in FF-DHE) is, as far as we know, > a safe technique for generating a group with a low probability of a t= rapdoor. The weakdh.org site currently says: | If you run a server... | | If you have a web or mail server, you should disable support for | export cipher suites and generate a unique 2048-bit Diffie-Hellman | group. Should that be changed to "and use a 2048-bit Diffie-Hellman group"? Kurt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Sat May 23 06:13:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E65F1A7014 for ; Sat, 23 May 2015 06:13:05 -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 N89ARJ7I0Vnx for ; Sat, 23 May 2015 06:13:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7C91ACDFB for ; Sat, 23 May 2015 06:13:00 -0700 (PDT) Received: from DM2PR03CA0041.namprd03.prod.outlook.com (10.141.96.40) by BL2PR03MB356.namprd03.prod.outlook.com (10.141.89.27) with Microsoft SMTP Server (TLS) id 15.1.172.17; Sat, 23 May 2015 13:12:58 +0000 Received: from BN1AFFO11FD052.protection.gbl (2a01:111:f400:7c10::189) by DM2PR03CA0041.outlook.office365.com (2a01:111:e400:2428::40) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Sat, 23 May 2015 13:12:58 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BN1AFFO11FD052.mail.protection.outlook.com (10.58.53.67) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Sat, 23 May 2015 13:12:56 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB030.064d.mgd.msft.net (141.251.50.210) with Microsoft SMTP Server (TLS) id 15.1.112.16; Sat, 23 May 2015 13:12:54 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Sat, 23 May 2015 13:12:53 +0000 From: Santiago Zanella-Beguelin To: Stephen Farrell , Karthikeyan Bhargavan , Martin Thomson Thread-Topic: [TLS] Another INRIA bug in TLS Thread-Index: AQHQlNG8iqjabwu2AE6CYL35dnd4IZ2IfYcAgAAA/oCAAJlgAIAAZtCAgAALe4M= Date: Sat, 23 May 2015 13:12:53 +0000 Message-ID: <1432386773128.94453@microsoft.com> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> <578DE2AF-A139-4CDC-B71C-C67C28267FCB@inria.fr>,<556072C3.9010808@cs.tcd.ie> In-Reply-To: <556072C3.9010808@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.216.4.228] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD052; 1:7m6GCCDXfRlpotEr9vVgX0q9pSvUZG+sIY7XRGFzoaKf84iXJ5+QEZqxhlrZg7KTIhKIO2z0qoOIv2/3KzvBJwIlqeBNtEtC9Q48plb5Bl96YXSajPON6qLYAc6iQZbdvsmOt2zR+puEeNXKybsY8SWa1AOzck/9NfoZeXXWR3lJSINoVw3S6o4/KNfEB4fYtJes0XLIBW9/gZvcNZxDnYRPecldXWsLss7kfXm3CA4p6Nm4kB1noL/RuDJkq7ALGp685SkuyuWeCg/904IBQCA60tx+Wm2H29QyLkMUx6kG6QSVlLn8hS5Li08q09b4QDnGGv+scAOBIny6mNf1Og== X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(24454002)(189002)(479174004)(199003)(19580405001)(69596002)(19580395003)(47776003)(86362001)(62966003)(92566002)(81156007)(93886004)(50466002)(117636001)(97736004)(189998001)(5001830100001)(2950100001)(5001960100002)(4001540100001)(86146001)(106116001)(77156002)(102836002)(106466001)(5001860100001)(5001770100001)(68736005)(2900100001)(6806004)(50986999)(46102003)(2656002)(87936001)(16796002)(76176999)(66066001)(54356999)(86612001)(64706001)(36756003)(23746002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB356; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB356; 2:8XzzuXxMkCuJN0W2N0+318XVFCS+KrIC7mWVbahGWytZ21Mjj7ZXYRnWJGSruFpi; 2:rUP4/MKu2bZfPe8ML6FLX4VG4fdsV3zwYCzpY82JPXY07ZYk1QxWA83tBIa5HMvuqCejZW9/49vWySJeuYvEZhDTgYgocodB2FvG8KW8EGHXQEPd+EQZTTs74glg8+AD7CAJFIXJfp4VrPJNFWDrlxMFrihcT32vMhzUchMW9TDTE9ttw2UCWTb84yrV2fqDwjg9cgyA+Ev4/IYtz+9ZGPhOmmkAnLQEWFEX8UaBeJ8sc1DSOU0RHqaVArTp8X/Y; 6:DzL94Kb/SHKbsRzT2BKR639Y5yfFCoR+8rSeMocGpNP2o6FqLixf09kBYrsDX+9ahLbt1ShvVzx217os7qoKJ9l5mJ/y9kZkwY6HX9aYW+OllRLDOQ3X0tylPSJikWOYlXocV+wsGEmVp2Hi1JZ7+Tak0wnPn4A7y3vOrGVAkuagdOS0YZ8eP6RmACbns0ZeUmXBKczdwmjvsgAsxLgIpjR2ce0qRBoIrgUprSuG6xyrGKQXlRoCElKg1//U8GUnD2wuyEwG2/Szu5GvDc7X2Vj80kXLikQjtlepAjEulgC1mpL4UUn3MaWeDzonuv8I1ycCaXi2GyfpKooioSGZBtQci8M5g5Wzzixdu0mL25k7TOfS6d4CylEWb0XrhboGhbwgVldzUx/gjpd9hNYoM7kWZSxX9WpiN9Xq//99akupghDvdmg40UnsMAu9n9qUejNR1ogxsZiQsJfjfYIe5yYBjkRamali9uqhAeZiPFqUfRvEtPk0AaF2FQZasl/D X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB356; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:BL2PR03MB356; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB356; X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB356; 3:O1MY/dNwAAGlC4QTwsvL30dG2y/kMHGCuJ2tlO/qfS6yYSS7xNXlvkUGeUIIBSsd0n1bzSV1LrRpro8oF/Ojou195ObLiWFtDaaPfWkxdqc3KXPBPp0nkfl/cJw72MSRCregoKajhV04vLny5PztvKdK5Nn1j7rHFghbbProoiKbLYiNiwcTy6Eth8ALEQ4SWOAt4qoWvzPBsbbwa4Flos+q1xLwYptzI31pbNBAFYKvtLrmlMxgCL3S2odeY0I05slA4e7mX8w+a2toM16VXTJJknebCXssPoEq37rcP5UPoFcDEMszWUdHHV7fIVEwkSxWlGyR2UIkbETwQfsheg== X-Forefront-PRVS: 0585417D7B X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BL2PR03MB356; 9:n3KIje/LXZ/QDxhXvpcF04VvIZbwLtwIb/+fjgc?= =?Windows-1252?Q?Up1dImMnRk81DtS+zD6PFeZAGHCgidJ67mxdmLnlW0ETGSgHMZ6M8CMJ?= =?Windows-1252?Q?FllmbOwKWZkjLY4gtnlphbytT267e2CYIYd3krX/HMe7t23HPXtnyq0U?= =?Windows-1252?Q?kGfC8uvrfnFShSaqiHmpY2IwuxJs6tkTWno+ClqfcEA3zGe9NftoTyWF?= =?Windows-1252?Q?s/ME9oyJUcVTE6llqUJVW5xaA/RSCPjungVnQLiVQOvvF0mKmxJ78VR1?= =?Windows-1252?Q?+Kp8KSVKXBZj3cZlj4ZxgQNqMGd/s1cz+zY7RtCR2//xwp3vN04IB1RL?= =?Windows-1252?Q?dxVOpFK6wzZDloWRg6fi4WNPaPQL8HIVIQJZEil3r5wOaqNnNvMnnO3w?= =?Windows-1252?Q?29vYYNNcMQSItZXVM7cgIyxitTZeJ8/53bmg20lkaPjPXQWkYF4L9tRY?= =?Windows-1252?Q?yJg6TNKSxLAaIu3X+h2SNPY3njvPEHlhAgU0dqE1CGcRPlrhQ4B3SYOm?= =?Windows-1252?Q?9k5uvstsntO5RAuBLIH9HpHffNIbBK6FPRHrFX/BfW/LhpNdkOEulUCW?= =?Windows-1252?Q?jWTexeAwBNx1pcTA+/waWvOlCPDEkEgq2sWMkibKdJSdOe+V0FLxwr+4?= =?Windows-1252?Q?OcVh9j3Pd35bBBB3cF+6caNQ2Oiwo6ltOehx+SGCQOif1eFFbwdAImwU?= =?Windows-1252?Q?2IfGkrFTDuNEpePPuDjDcrobkyyR2e00REPxOsLTBeKbmgS5AIrFudna?= =?Windows-1252?Q?DjPL8i2P5L4FbB92ruicHr5Wv5WQD7vSlqHOEJzBpROMzriU/2nNOL7v?= =?Windows-1252?Q?qMgwa11Dil63hpce37b41gY+Km25ka9ojq7oUqeuEeMhfCNXAxslmk0g?= =?Windows-1252?Q?g/TldQQ9lSQd5hrZhRcO6S+Xq6/2sO8Npm7pmWEkUsd4+OmT37n+YsRO?= =?Windows-1252?Q?yiD2Y3kQt3iiPOPezhuvT8em1XiKwoyeGZGw6Xy19Z+Tm8TTKE+O/IVp?= =?Windows-1252?Q?LVK1rtSX5oji+QkHoCYr9RFB49fgTQ1cUu9sr7R4OIBHQ5/wO70dyvhm?= =?Windows-1252?Q?aSjf1JDm2d2vrNI8UwT3j5s1//FvNQaUAd9VDkJxs0UykobApTBC8eTt?= =?Windows-1252?Q?jqKpiYKrtHuDb3jzR8BY1p7Dh6VBpI1xwiKoSP2V25pYaT7BUZVh5PT4?= =?Windows-1252?Q?qQjE7ofjQExUOVkeOkTVW/nCuY05QAy7PSE/irSJ0nTgeRyHhRrtBrc5?= =?Windows-1252?Q?CgkdGrOvKanifVmPraKos+EDLdUW18COE1MFyMmtnGZmE4BJ4zI9xuWK?= =?Windows-1252?Q?i?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB356; 3:ixhn8n+84ZQcmPi5tzkvCjYKrKGmShw7klErOPAwF6b70W5facNZJD6n3sp8fBP1pnZxluRZhPx/a4WpPCtEzLtDALLJKtzw+HG76eb3F+regNvJNvqxKgC+/TbBo3h5sI0KeVHvpi3ZcV+QcnY2Mw==; 10:RSrCNUrlg2gJmiM4N5/QXXjKfAWHxVgyttssvCxiLaaZ2o75AwvcOzOxn+rqSEl9fNm4ZLCR8B77i5zVhDD96oCmF/EdoCtQrWJumDHDn4E=; 6:3D7OZM0IX4ymRRehs+Js9VGtFz2rXWqlEwTQJLiZgKOSuxIloWQC4lJKuzlV6b/Q X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2015 13:12:56.5126 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB356 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 13:13:05 -0000 Hi Stephen, > It's a really good paper, but if you have the chance I=20 > think adding the above clarification would be very good. Thanks!=20 We're working on that. ________________________________________ From: TLS on behalf of Stephen Farrell Sent: Saturday, May 23, 2015 1:29 PM To: Karthikeyan Bhargavan; Martin Thomson Cc: tls@ietf.org Subject: Re: [TLS] Another INRIA bug in TLS Hiya, On 23/05/15 07:21, Karthikeyan Bhargavan wrote: > The =93avoid fixed groups=94 recommendation applies to 1024 bits (and any > other group-size for which precomputation becomes feasible.) It's a really good paper, but if you have the chance I think adding the above clarification would be very good. Cheers, S. From nobody Sat May 23 17:36:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565DF1A0013 for ; Sat, 23 May 2015 17:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 sCP9wg_3uTo0 for ; Sat, 23 May 2015 17:36:50 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 6C1F31A000F for ; Sat, 23 May 2015 17:36:50 -0700 (PDT) Received: by wizk4 with SMTP id k4so19499588wiz.1 for ; Sat, 23 May 2015 17:36:49 -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=emmUIqov1oCzmNPfsshgaBsqhw1w5q2ww+6ePloSfr0=; b=haClirk388zozSuO834Wb6PMGGhS2HgMlzMcISkGomVXJbx1ijPDYQf+JvlF+uJ0cR mRY5cKtIvXaf+pUnw7U6d5nXmdVF37sG4eS5sqIWHGwR51ob7A2OHZ8vidoIsOlElckC jn7rp2h9NF1hlFXAtEG/+3q0EbkeJNUOA7JVQFSjEVl5dI6mMYrRYISE5AiVA5rGsbUy ER9qArdLCqq54PwBrEdJmei+/mLZNsAa4DHOXqXrHDtPBkC8Hv6+htAK32klXyjnYDgH ayhl6z6onwRdmAbeWPu2QbqqfVy00PxzvMM23AsquK9BDOIAUvbhjPPQEwF+mJ6bZkMy WCKw== MIME-Version: 1.0 X-Received: by 10.194.248.227 with SMTP id yp3mr26930758wjc.32.1432427809257; Sat, 23 May 2015 17:36:49 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Sat, 23 May 2015 17:36:49 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sat, 23 May 2015 20:36:49 -0400 Message-ID: From: Watson Ladd To: noloader@gmail.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 00:36:52 -0000 On Fri, May 22, 2015 at 1:05 PM, Jeffrey Walton wrote: > On Fri, May 22, 2015 at 10:54 AM, Peter Gutmann > wrote: >> Santiago Zanella-Beguelin writes: >> >>>Regarding validation of DHE parameters and how reasonable it is in practice, >>>I wanted to make some publicity for miTLS (http://www.mitls.org/). >>> >>>A miTLS client maintains a table of known trusted parameters, including the >>>subgroup order for parameters with non-safe primes. When receiving unknown >>>parameters from a server, it tests the primality of p and (p-1)/2 to check if >>>p is a safe prime (and caches a positive result in the table). >> >> So you do a full primality test (Miller-Rabin or whatever) for each connect? >> Doesn't that make it awfully slow? > > The software under my purview does. And that software would be? Of course, once software is designed and written it doesn't cost more to use. The whole rationale of protecting some information less than others ignores the zero marginal cost of software. > > I don't allow the developers to use any parameters without validation. > That includes crypto parameters. But its for a systems that handles > medium and high value data; and not low value data where web browsers > and their use of TLS would be appropriate. But that use is what TLS was originally designed for. We have to be very clear on this point: TLS lacks properties other protocols, like SSH have, that would defend against these attacks. Some of these attacks are made worse by implementation complexity and bugs, assisted by the use of informal descriptions of protocols instead of formal methods. > > I don't think browsers will ever be able to handle anything other than > low value data, so I probably won't have to worry about web browsers > and what do (or don't) validate before use. Web browsers handle bank account information, tax returns, user accounts, etc for billions of people. Hard to think of a more high-importance target. > >>>If the modulus is prime but not safe, miTLS checks if it is in the table of >>>trusted parameters and otherwise rejects it. We distribute miTLS with a pre- >>>populated table of parameters which we tested thoroughly (and we welcome >>>people to test further). Most of the time we hit an entry in the table. >> >> What testing do you do on unsafe primes? > > GnuTLS with its Lim-Lee primes causes me a lot of problems because > they cannot be validated. > > If we encounter them, then developers are *not* allowed to apply a > secret to them. The user has to generate a new, verifiable key and > then add that key to their keyring. > > Jeff > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat May 23 18:35:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AC71A009B for ; Sat, 23 May 2015 18:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 Btk8ZyXjUQQF for ; Sat, 23 May 2015 18:35:30 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C071A0099 for ; Sat, 23 May 2015 18:35:30 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so16779357igb.1 for ; Sat, 23 May 2015 18:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0oJ3JfRRnDWjrloFI3Lmtz/hMydUEDjY4yRdnSYRFJY=; b=jIQgbP9rMt3YrTxwAwlR4vYjvfdRobXVCphtpE2hAZ/3v+6dOlppTyp7QRz1F7Hmem LGttUh9Y0z0SeGDnCcSMtzyDYbiZpw0jI4cOqr+uOHvEhpgbNRrImxMD9mFN+jkk93pW FXc7QP2WINtqqNYFCD7fxu1ovtd4dcG8LmNswAg2F+mT9bTrk0gbRfOo/vcyLFsu1+Ue Vb6bc4Wpf2F/GvU3jBhL3W5ox0WjWJayH/YTY8ZxK5aV693v+0IASjHYVnlu5iEqL3wL usx2pBMwTNweZt/lLD9yZbB7alez2gSRulnveS2orvHJjGN2VT9c/du5QOmS9lmVGKpB pZfQ== MIME-Version: 1.0 X-Received: by 10.50.61.130 with SMTP id p2mr6882138igr.9.1432431328997; Sat, 23 May 2015 18:35:28 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Sat, 23 May 2015 18:35:28 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sat, 23 May 2015 21:35:28 -0400 Message-ID: From: Jeffrey Walton To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 01:35:32 -0000 On Sat, May 23, 2015 at 8:36 PM, Watson Ladd wrote: > On Fri, May 22, 2015 at 1:05 PM, Jeffrey Walton wrote: >> ... >> I don't think browsers will ever be able to handle anything other than >> low value data, so I probably won't have to worry about web browsers >> and what do (or don't) validate before use. > > Web browsers handle bank account information, tax returns, user > accounts, etc for billions of people. Hard to think of a more > high-importance target. Ah, this is a very good point. I just call it "drinking the koolaide". SSL was originally designed for ecommerce transactions. In ecommerce, risk is offloaded onto merchants and share holders. When something goes wrong, its the merchants and share holders who pay. After inception, SSL/TLS was repurposed for additional uses, but the risk model was not the same. For example, someone in Iran may use SSL/TLS to access their Gmail account, and that account may have email threads with views that are not popular with the current regime. But the risk was not offloaded, and lots of people were likely tortured and killed because of Diginotar. >From my time in US Financial, we were well aware of the problems with browser based web applications and underlying technologies like PKIX. We would regularly decline browser based applications for use in the firm. The application would then be sent into risk acceptance *if* a director or VP really wanted to use it. If the system handled low value data, like online banking, then the firm would accept the risk because they did not want to lose customers. That is, they chose to accept the risk. If it was high value data, like pending litigation, mergers and acquisitions, executive compensation, then the risk committee would not overrule us. That is, they would not accept the risk. By the way, the "... did not want to lose customers" is one of the reasons we lack 2FA in so many US banks. They don't want to make it inconvenient on their existing customers. And its one of the reason US Financial suffers loses at 25x to 600x than their European counterparts. Jeff From nobody Sun May 24 00:12:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0851A87AD for ; Sun, 24 May 2015 00:12:08 -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 HM5tYYPh2DTA for ; Sun, 24 May 2015 00:12:03 -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 A8DD31A879A for ; Sun, 24 May 2015 00:12:02 -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=1432451522; x=1463987522; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+rj/CRoSt/DzC9PpHHTBVKUfuTKdWUqjmIvVFzFxNA8=; b=oCE1aRUX790rTC87/B+OevIFEsKuck9J8Ut9Pg+se2F2dNTDQ5H99ugn MkSg90U8osy2aGKj89uPLpYr02+hOKTZ83Rs/80QQadqQYdcWGmToQcV7 JMlTiNu7koigaICIno4hM8j1gl2rOuI6+dZqFPkO+O4hLIyOlRoBIpT/r fQ2QVM+1hmRPDJKVeBdvjruQ7qxtyLw3MyUYqYYDx6UZAO2W/Qs390Pez xPot9S8qcT4n5kRHuniBit8gBZ/Yz2POJcQX81gNKnDa0uoCNtFk3Vfo6 iSTbVDwtPPcp6a3+O0BvGIzTFMg9jF7Sw38MdQrWKvJau1IX0mZSrfHVO w==; X-IronPort-AV: E=Sophos;i="5.13,485,1427713200"; d="scan'208";a="17936067" 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; 24 May 2015 19:12:01 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sun, 24 May 2015 19:12:01 +1200 From: Peter Gutmann To: "noloader@gmail.com" Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AdCUn0KvC4ozoUHOQIKcwi120/Yv8P//W1SAgANHxkA= Date: Sun, 24 May 2015 07:12:00 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: 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: Cc: "" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 07:12:08 -0000 Jeffrey Walton writes:=0A= =0A= >GnuTLS with its Lim-Lee primes causes me a lot of problems because they=0A= >cannot be validated.=0A= =0A= Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as well!), it'= s=0A= the fact that TLS uses the PKCS #3 format rather than the DSA format, so=0A= you've got nice verifiable values for which you have to throw away the=0A= parameter used to verify them and send them in an unverifiable format. Hav= ing=0A= said that, there's a pretty simple fix, define an extension that acts like = the=0A= existing propose/accept extensions that signals a change in DH values to th= e=0A= DSA form (p, q, g) rather than PKCS #3 form (p, g). And for TLS 1.3, use t= he=0A= DSA form by default, not the PKCS #3 form.=0A= =0A= Peter.=0A= From nobody Sun May 24 00:24:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EE81A87E7 for ; Sun, 24 May 2015 00:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LMDvOQzilIB for ; Sun, 24 May 2015 00:24:00 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61EF1A8758 for ; Sun, 24 May 2015 00:23:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,485,1427752800"; d="asc'?scan'208";a="126136892" Received: from 178.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.178]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 24 May 2015 09:23:53 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_363A8CCD-3549-41D0-A0D3-6FCF2912A78E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Karthikeyan Bhargavan In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sun, 24 May 2015 09:23:52 +0200 Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 07:24:04 -0000 --Apple-Mail=_363A8CCD-3549-41D0-A0D3-6FCF2912A78E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The confusion between DSA and PKCS#3 has other unexpected consequences. As we describe in 3.5 of our Imperfect Forward Secrecy paper, some = server implementations take a DSA group (p,q,g) and, when fitting it to TLS, = confuse the =93q=94 with the generator =93g=94. This bug leads to a rather nasty = attack. (Yeah, you=92d probably want to add this to the WTF category.) On 24 May 2015, at 09:12, Peter Gutmann = wrote: > Jeffrey Walton writes: >=20 >> GnuTLS with its Lim-Lee primes causes me a lot of problems because = they >> cannot be validated. >=20 > Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as = well!), it's > the fact that TLS uses the PKCS #3 format rather than the DSA format, = so > you've got nice verifiable values for which you have to throw away the > parameter used to verify them and send them in an unverifiable format. = Having > said that, there's a pretty simple fix, define an extension that acts = like the > existing propose/accept extensions that signals a change in DH values = to the > DSA form (p, q, g) rather than PKCS #3 form (p, g). And for TLS 1.3, = use the > DSA form by default, not the PKCS #3 form. >=20 > Peter. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_363A8CCD-3549-41D0-A0D3-6FCF2912A78E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVYXyIAAoJEB/WSo9veuUKoxEH/RQAaXJ8yjdahVe/HyFgLk/g C5ihJQRu3gZLKuRtr8aDv7axvTWA8QoxHMt4li2AYIk7F7usmO3HG7mdEzO0fcir GWqOz9Oy51f+5ltJ+dMOUWw7xhzZPTr9bX8HWRTIsgx28R3hOQw6ou+8Xw097RCN n7WN/tNd58ZHb3hPaRVAlsaTXU2SfZDaAndmlpWwbszKPy2PPWa3RTxp/A4Tq3A7 vYD2Prv87+RKly0NmQXIA5G4Avw/sdqtnauyZeiRPBTWM7y2bU7fTsA+OPth7PVV p15a6ya5CqCBIdfMqHObYKT4rlJkZDgLSJzm9TEvWLBS9hOPk+mX3Y/0fV5/+/4= =QXX5 -----END PGP SIGNATURE----- --Apple-Mail=_363A8CCD-3549-41D0-A0D3-6FCF2912A78E-- From nobody Sun May 24 02:55:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3331A89B9 for ; Sun, 24 May 2015 02:55:34 -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 5P3RPIU6mtzi for ; Sun, 24 May 2015 02:55:30 -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 5634B1A89D3 for ; Sun, 24 May 2015 02:55:29 -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=1432461330; x=1463997330; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=scsmZv8nD2MotyYiLwZ4SdbXMDCQgtID4ERj+CbH+9I=; b=e71fIl16vLQPu/1FkVx0CbUMsf9ccJR1SnbVOxwRwkDVDt03EyhyjcNW oVwvRFj8+JTvmLb+hWRXcvmkfQ3glkhV3hcEu8dk8KijIBuI5R3ImPsu6 GIbpNqRZlFWDjlNhF13Cx/mHdIh5C/Pdorhu8TozV4MjJPHNj+VeCsHUb wzyvgsJONS3kdQbDI6kayp2y/8ofx4B03M70+ceoDCFjR4+/VUw8pYo1O k3eN3GflFKAetRR5js3adVNIeD0ODx+xOvfgz9iLojxdTjy+dytCgh973 O9krTbTMjQzALt0rYryyyxCacqsIS0yEgZzFLSfB0CN+uH2eacE3ax88v w==; X-IronPort-AV: E=Sophos;i="5.13,485,1427713200"; d="scan'208";a="17973073" 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; 24 May 2015 21:55:25 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 24 May 2015 21:55:24 +1200 From: Peter Gutmann To: Karthikeyan Bhargavan Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AdCUn0KvC4ozoUHOQIKcwi120/Yv8P//W1SAgANHxkD//zphAIAA8y8g Date: Sun, 24 May 2015 09:55:24 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB02AB87@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73AB02AA8F@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 09:55:34 -0000 Karthikeyan Bhargavan writes:=0A= =0A= >The confusion between DSA and PKCS#3 has other unexpected consequences. As= we=0A= >describe in 3.5 of our Imperfect Forward Secrecy paper, some server=0A= >implementations take a DSA group (p,q,g) and, when fitting it to TLS, conf= use=0A= >the =93q=94 with the generator =93g=94. This bug leads to a rather nasty a= ttack.=0A= >=0A= >(Yeah, you=92d probably want to add this to the WTF category.)=0A= =0A= It's a WTF, but it's the IETF's, not the implementers':=0A= =0A= /* [...]=0A= =0A= For peculiar historical reasons (copying errors and the use of obsolete= =0A= drafts as reference material) the X9.42 interpretation used in PKIX =0A= reverses the second two parameters from FIPS 186 (so it uses p, g, q =0A= instead of p, q, g), so when we read/write the parameter information we = =0A= have to switch the order in which we read the values if the algorithm = =0A= isn't DSA */=0A= =0A= Peter.= From nobody Sun May 24 04:20:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1311A8A7A for ; Sun, 24 May 2015 04:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.094 X-Spam-Level: ** X-Spam-Status: No, score=2.094 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 IzT4nYG-139q for ; Sun, 24 May 2015 04:20:31 -0700 (PDT) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id A11B11A8A79 for ; Sun, 24 May 2015 04:20:30 -0700 (PDT) Received: (qmail 345 invoked from network); 24 May 2015 11:20:50 -0000 Received: from pcdhz005.win.tue.nl (HELO hyperelliptic.org) (131.155.71.33) by calvin.win.tue.nl with SMTP; 24 May 2015 11:20:50 -0000 Received: (qmail 3777 invoked by uid 1000); 24 May 2015 11:20:39 -0000 Date: Sun, 24 May 2015 13:20:39 +0200 From: Tanja Lange To: Santiago Zanella-Beguelin Message-ID: <20150524112039.GU20757@cph.win.tue.nl> References: <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432337750554.95436@microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432337750554.95436@microsoft.com> User-Agent: Mutt/1.5.11 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 11:20:35 -0000 Hi, > > When is it non-safe but trusted? > > When it is in the table of trusted parameters, and hence we know the subgroup order > (the prime q in DSA terminology). Just to avoid misunderstandings, we clarified > the formal meaning of "non-safe" earlier in this thread. > Do you have an easy pointer to the table? I've poked around a bit in the online interface but couldn't get to it. Where did you get the DSA parameters from? RFC 5114? Thanks Tanja From nobody Sun May 24 04:27:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9D51A8A81 for ; Sun, 24 May 2015 04:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dgCQrEZyNos for ; Sun, 24 May 2015 04:27:48 -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 35D3A1A8A80 for ; Sun, 24 May 2015 04:27:48 -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=1432466868; x=1464002868; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L5LfCAv2aIMCWjsvDAa+FUoe8PeM9DRHO+3Zi54uFZo=; b=4ddtN5EVoaSTTyocyArOhD/iPiVIyfQcXSf4Yfl5/88K0uFHCBwSBZa8 3QwCXexT0/6YihYY/zAF+SCVx2f8wwrUcU2NG4/ZGNHx2GrSkAludcdNk taXmTLulBAFqo6wDu401UU9U+t97VVU2d7m1f/QRe2yuaCz7vBmjp8EuF 4KfjaoZXkxKekU8GYv0sCrLLHr04sr+L/vgMrQAZcR3dwnHfoC0vsdw0Z eoIKzeHSg1rvwFQOj4rXPxQ5Lm26tQcd/ki8HW3X2f/NBQrrbBjUEmGfv 86+Rysr+oV0LbDPruZbcDma9660ZN5nkVVI5+PoTOkV35rtOJGe00eaL1 Q==; X-IronPort-AV: E=Sophos;i="5.13,486,1427713200"; d="scan'208";a="17994047" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 24 May 2015 23:27:46 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sun, 24 May 2015 23:27:46 +1200 From: Peter Gutmann To: Geoffrey Keating Thread-Topic: prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) Thread-Index: AQHQlLPWR1x4OtJapki4aa+G2J1L4Z2K/VwA Date: Sun, 24 May 2015 11:27:46 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB02AC04@uxcn10-tdc05.UoA.auckland.ac.nz> References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> <20150522032029.GA24064@typhoon.azet.org> <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: 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: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 11:27:52 -0000 Geoffrey Keating writes:=0A= =0A= >Telling people that these PLCs are secure and everything is fine and they= =0A= >don't need to worry won't fly either. The owners of these devices are goi= ng=0A= >to have to find a solution, whether it's an early hardware upgrade, =0A= =0A= Will never happen.=0A= =0A= >firmware replacement, =0A= =0A= Typically can't be done.=0A= =0A= >or a front-end translator/firewall.=0A= =0A= As above.=0A= =0A= For people who have never worked with these kinds of devices before, here's= an=0A= overview:=0A= =0A= -- Snip --=0A= =0A= [...]=0A= =0A= SCADA devices often resort to all manner of exotic designs in order to prov= ide=0A= this high level of availability. One such technique involves the use of=0A= differential switching on all circuits, in which a value of |||false||| is= =0A= represented by a 0 signal on one line and a 1 on the other and a value of= =0A= |||true||| with signal values of 1 and 0. If both lines are unpowered (due= to=0A= a loss of power) or powered (due to a short circuit) or the signal is prese= nt=0A= statically (due to latch-up in a circuit) rather than dynamically (driven b= y a=0A= clock pulse) then it's regarded as an error condition.=0A= =0A= The clock pulse isn't necessarily a standard CPU clock but merely a=0A= capacitively-coupled AC signal (so that applying standard DC power to the= =0A= circuit won't produce an output signal) that acts as an additional gating= =0A= signal that has to be present in order for things to work. Even basic pass= ive=0A= components like resistors are mounted in such a way that they can't easily = be=0A= bypassed by a short circuit, for example by having the circuit traces that = the=0A= two ends of the resistor are soldered to on opposite sides of a double-side= d=0A= circuit board.=0A= =0A= That's just the lowest level of the system. Once you get above the basic= =0A= switching circuits you get into redundant buses, self-checking logic,=0A= heterogeneous designs (for example an AND gate can be implemented as both |= ||a=0A= AND b||| and |||NOT a OR NOT b|||, with the two circuits checking each othe= r),=0A= majority-logic decoding, and in general entire books full of exotic design= =0A= principles that would never be used in a standard system.=0A= =0A= [Further discussion]=0A= =0A= The overall rationale for not thinking too much about security is that ther= e's=0A= a higher risk created when a critical device isn't working due to a particu= lar=0A= security measure than through having some possible, often rather theoretica= l,=0A= security flaw present.=0A= =0A= -- Snip --=0A= =0A= So when given a choice of availability/reliability over security, availabil= ity=0A= wins every time (and quite rightly so). The only time you can fiddle with = it=0A= once it's in place, ever, is when there's a clear and present issue that=0A= affects availability. "Race condition when reading vibration sensors is=0A= causing the rotor-imbalance safety cutout to trip and take turbine #3 offli= ne"=0A= is a clear and present issue. "Haxors might 0wn us" is not, so it'll be=0A= addressed in the 2018-2023 product cycle.=0A= =0A= Peter.=0A= From nobody Sun May 24 05:20:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9071A1AC9 for ; Sun, 24 May 2015 05:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 9dfJkenUzFYH for ; Sun, 24 May 2015 05:20:38 -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 AA6751A8AB8 for ; Sun, 24 May 2015 05:19:14 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so22093592wic.0 for ; Sun, 24 May 2015 05:19:13 -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=nBRYLclOyny5Y1JZG269rzRnN/VFuB1dKhU/l8mtHMA=; b=EfdEC4mcA2MEecbqBjXior27v5fExhz6EeUPpTse0DvOMhrrgMio+1N+5fC10By/U5 Q+j6L9qCZOVI0OC7juaETv7I5IDOgyvDPXT6T9/ZjW89cXtAqMdIS8Mlw1jy89Kg7SoH OPy2b37qIOzbdyLWXrlF11Yh8IBEQBeCtKwE47U8L8SkqAgWGcAfRZtUiQuO26mQSa8z S4wOHI9Mac3Zq0nQvdOFaakRY5CeFNZudecf3FISR1dZ7RAZyAupeK9SpJP4kO7cz8hs 3ftkLCWgES/GBbD8sW29shXYXhaLw44C8uQM3MeLbOy7Q3IFcbplN9ZreFeL6pcofcWl F3Qg== MIME-Version: 1.0 X-Received: by 10.194.248.227 with SMTP id yp3mr30576817wjc.32.1432469953451; Sun, 24 May 2015 05:19:13 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Sun, 24 May 2015 05:19:13 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sun, 24 May 2015 08:19:13 -0400 Message-ID: From: Watson Ladd To: noloader@gmail.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 12:20:43 -0000 On Sat, May 23, 2015 at 9:35 PM, Jeffrey Walton wrote: > On Sat, May 23, 2015 at 8:36 PM, Watson Ladd wrote: >> On Fri, May 22, 2015 at 1:05 PM, Jeffrey Walton wrote: >>> ... >>> I don't think browsers will ever be able to handle anything other than >>> low value data, so I probably won't have to worry about web browsers >>> and what do (or don't) validate before use. >> >> Web browsers handle bank account information, tax returns, user >> accounts, etc for billions of people. Hard to think of a more >> high-importance target. > > Ah, this is a very good point. I just call it "drinking the koolaide". > > SSL was originally designed for ecommerce transactions. In ecommerce, > risk is offloaded onto merchants and share holders. When something > goes wrong, its the merchants and share holders who pay. > > After inception, SSL/TLS was repurposed for additional uses, but the > risk model was not the same. For example, someone in Iran may use > SSL/TLS to access their Gmail account, and that account may have email > threads with views that are not popular with the current regime. But > the risk was not offloaded, and lots of people were likely tortured > and killed because of Diginotar. Are we talking about phishing? No, we're not. Are we talking about CA compromise? No, we're not. The bugs we are discussing involve core security claims: that knowing the private key associated to one end of a TLS connection is required to know what data is sent. It's a problem that every single use of cryptography faces. And it's trivially solvable: SSH has far fewer of these problems. (It has other problems: check what your hostkeys are people! If you generated them two decades ago, time to rotate) So what exactly are you proposing as the solution, if you want to protect all data? Or is this working group just not worth it: we would need the Very Serious Security Protocol for you to actually think that it's worth fixing this problems and sharing your infinite wisdom? I'm well aware of how TLS got designed: SSH v1 also had tons of problems, but SSH v2 fixed them all. IKEv1 had problems, IKEv2 fixed them all. That's the point of having these new versions. Of course, once you actually have the VSSP, you can just use it for *all* your data, and replace TLS, SSH, etc. with it. Maybe instead of quietly fixing holes, you should let all of us know about them, and we should fix them. Sincerely, Watson Ladd -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun May 24 05:27:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB331A8ABD for ; Sun, 24 May 2015 05:27:13 -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 1unS26dcDcPN for ; Sun, 24 May 2015 05:27:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0147.outbound.protection.outlook.com [65.55.169.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00BC1A8ABC for ; Sun, 24 May 2015 05:27:08 -0700 (PDT) Received: from BY2PR03CA009.namprd03.prod.outlook.com (10.255.93.26) by BY2PR0301MB0744.namprd03.prod.outlook.com (10.160.63.22) with Microsoft SMTP Server (TLS) id 15.1.166.22; Sun, 24 May 2015 12:27:04 +0000 Received: from BY2FFO11FD040.protection.gbl (10.255.93.4) by BY2PR03CA009.outlook.office365.com (10.255.93.26) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Sun, 24 May 2015 12:27:04 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BY2FFO11FD040.mail.protection.outlook.com (10.1.14.225) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Sun, 24 May 2015 12:27:02 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB030.064d.mgd.msft.net (141.251.50.210) with Microsoft SMTP Server (TLS) id 15.1.112.16; Sun, 24 May 2015 12:27:01 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Sun, 24 May 2015 12:27:00 +0000 From: Santiago Zanella-Beguelin To: Tanja Lange Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AQHQkwYvDdHZ+lmQNUW54l67jurcrZ2E9gcAgAD9fwCAAB8/AIAAAj6AgAAyIwCAAAGZgIAAAX4AgAACGWGAAAP8AIAAAqUAgAAvugSAAch4gIAAUHiSgAJlpoCAABBL7A== Date: Sun, 24 May 2015 12:27:00 +0000 Message-ID: <1432470419547.99826@microsoft.com> References: <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432337750554.95436@microsoft.com>,<20150524112039.GU20757@cph.win.tue.nl> In-Reply-To: <20150524112039.GU20757@cph.win.tue.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.216.4.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD040; 1:YMTCBprXY0iJaQ2GRiVT5XAVaGX9sScKPmnvHzuxXxWDHdgd+ADSm36BeUCS+uZPcRe2nu0OnkC05tFnH7eM26XlZqkE8Ks13NzVPtcTWe7TH0Y/woBCkBxJe4MmilQ2oe54ZVCTBE34xmwHgvQLJ0CgjzIka9DSRjYpg+tvrURC4d5ucDwYUyJELzXXedEiBbZwYzgoiHHmjadp3lxA++egIfb3P6F8XSH/u7xnTyv3r4s1LV2cAs8Ho3abnbIXjjwBhNMFgrMuSZ4ZQLpVz8Gwyj7/YByVCIwet72rDsQIvbeX9zkTij0Tuuejx+CD X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(51704005)(377454003)(189002)(77156002)(102836002)(87936001)(110136002)(5001860100001)(50986999)(5001830100001)(50466002)(62966003)(86146001)(47776003)(15975445007)(6806004)(106466001)(106116001)(69596002)(2950100001)(66066001)(19580395003)(54356999)(86612001)(36756003)(46102003)(16796002)(92566002)(86362001)(68736005)(97736004)(76176999)(93886004)(5001960100002)(64706001)(117636001)(19580405001)(2900100001)(189998001)(81156007)(2656002)(23756003)(4001540100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0744; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0744; 2:18pySzqGDu0R3KYb7Pjyn8bKNPiRB19sFqFJh5HR9YjMgroLnQVjZHTgojL4Fp3d; 2:fmooUxkzGTwV2yWeb8tnwTnB7cT+q6S9Bvz3Expv8r2V0SZORkx/Ilob0tprVivq57l2aN6FAqOaX0vi8fuAmnLsFHxg449S9h1M0tzOjZ+PEoHiwLG8nZOfY5GHT6a5uEKp8cc05xQtGvgUjbVtT/Oq+m0zowvJFllRRmP9sQQd0dyPmP1pQVSGBJCly2YV5x+HxHQlvoK5fXzxpE3TUKaW9RsRt26fydakXhLrcv5xnFrsoPgTWu4kwMUWYzGq; 6:GVPtmMMqHjsZPBRIMY6UnK3CjteQJsC2q4z6LUnUCPMx8D8KctWSUbx6EjExubTUKrSwxjy/yPpP2kWa92At4gUprO28F+dLdve1vz/i+BrXOTR/6q1M+rmijG2Ea6ouiDJHC0f69030Cwejz5IRMWQSrd76mbLwkOqujjEwaJVoFpa91dM6kP7tptRRGV49eIlZhCtHh7gkkeeMaWFZoA5xqst9YW/0LNzE6zoXWQkHYVyT/+do/ReY8v4EbJnQu2nr6qsT+H/JLqwNcn2qMSkSa7wUcSLm798mCLtMIqvQ7eV7yxYcmcoxXqucGg9OD9zxTAnB+YP57n1ifLihFTV/gHYyh23Hu/WtTlJrzbeDSb2fU1WOchUSdl82yeqe/NyeybhaIhz4X/jKIsaxGR6GaLCEc0qAdFAjildvhtFWqcClss5OvBago6cARjyt0EDq5f4q+Igcbt4Vvk7m7uKPM5urJlfHl8o72gfxGKPcXrq2q6eIJZJGAtGsyQ4L X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0744; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:BY2PR0301MB0744; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0744; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0744; 3:h+/F2quPEA0lyAwGDNF01J5wIh7QNgoaoF2BBK5tKKepPd+epT8bcKvRqNHnd1llSuRzrBsbzxTQtfVVy8M9EzegTFzuCyKYsjhPs7gSzhgB8AjYrKq8US1huffvwoonDHWNJp2pmr9JCF574Nx+6ha0KybnDRQrB4khizIeCfcYCn/wVbYGEGWbX4T3KmWnL1qtwRRDwOIZpW4ndOJPUhQKcegOcqj8DXPwWFHPvYGAtiY5o2k/G+3y68W4Y2B4xXIa2dy4rbFKIw6IbOm/96CLvn9xK0nYBRQ0R94wzMTcZfWnpdu74/NSkJ7coQ03XejqZs8JNBDnhSE+aWAm1w== X-Forefront-PRVS: 058637CA05 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BY2PR0301MB0744; 9:TVnO5NsrGnWMWwXDuLyV7aGYr6zYU0nl+VwW92?= =?iso-8859-1?Q?Sb+zV/CodvVuoNHRr1FHWsOuhOkA4cXhVGdnzm/aFjuQJEsdq8YNl3UmT9?= =?iso-8859-1?Q?0EM6976cmDAwiSpCqhf8GGNqyDgorlESEj4wzTQDAto4P+1xLzh3J6uVC3?= =?iso-8859-1?Q?raCa0ZhkRWrFyr8eSX+gtMgPNOraZvO53aWm+7vxCJJ/PhTK9QBxt4qwb3?= =?iso-8859-1?Q?S7ir+C7XFxwClvNjO29blfHJBWeSBJL3kJYBI9iwUnNybMYvszy+IFhUTB?= =?iso-8859-1?Q?4Hx5O3OPLW38AARI5XmTGEnpCxBkfU6aLDiqnv4KMz5Pmbx/1DtJSuU3NQ?= =?iso-8859-1?Q?rKvJv1BC5Q19PU+X07bhtaswK1QcaonEPrwASCP8idYEqAV+c61ByMy9Gp?= =?iso-8859-1?Q?xjIznT2bY+CuSV4HuiikT39xl0C79/0FzGMwIh0I/ctTDvXT3CopduFGWE?= =?iso-8859-1?Q?vTPhdxz2m3/LEwQvd0No9qTFWI5Die53/QDWLGkVTeuOqon9M2iDIrRVIx?= =?iso-8859-1?Q?04sQkhU84aWIxq8gZpsMkbNYi0OpfSbQDjAAB4+UG2bpw2GHofQu4KLFar?= =?iso-8859-1?Q?9iFZe8MOfVJPWL7D5XzE8k21OT2xk7yW1QNlAJvaAu/9a7K2AAuCqXCDaX?= =?iso-8859-1?Q?lsfx/WNQGA++qn3crGTsLBH1h8oz6GhGKPgGK7WZXfS4cudqM6ewVstzL5?= =?iso-8859-1?Q?bLN41VhpNu2hLV+5ArHQBVRV8RuZgZ1UULJgv6Qmnx/lfaU8K7DjD1WDJx?= =?iso-8859-1?Q?KVYp5FrNTMgfQkj65Fm5Ynmx8JN2WiOSxZbGbQLW5SV5J0peg37rZkTtQu?= =?iso-8859-1?Q?eYmS4fFNSlRGIwQQ8fMrKQvrkX7ZBJ0utL/x6gfnqudnEMcKsOYiPxgIh3?= =?iso-8859-1?Q?/TDV6SdJknwWjJlid9DIgC8ym3Lks5vb4UPYR4tRny0aTkTU+s7AqBQlOi?= =?iso-8859-1?Q?w9wIDeJ0ybFTgGJARqXZjBeKz3c8P82YoahE/+ZRbT3Dkh7KyjkIPQLmsP?= =?iso-8859-1?Q?7kLMNWnPZ64/1OzSiMiHumTGG52xviHt/ObcPm18x34CL81jCEN0U7iuKM?= =?iso-8859-1?Q?SglbzCHW5qZ/MAgM4DNVVyz8dta7QPIRkYRNroFjaoPzFPmcKPYt6X2eSM?= =?iso-8859-1?Q?KKRZOL1lWHLnqAQhdtm+zNcrKRzw3MCLS/FixmV08ylVLzR1EllVkbx38c?= =?iso-8859-1?Q?9DoxwpnYsWNBUf4tk10gS3KFs43/4Jn/sZvnDVWY+2tN2D6jv69bD9w=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0744; 3:ugonG0rEv0tFfK/EEue62RZZ+dTktGm6ytTqaYPWAW+2+gQqRfActfpVbh7clQV3isT8WyNiyMJih5SI84tXTqKZ7fTWGgOlKQe0iWBYm2B0oQubvF+brAWt3cUXb8BZXdLVxEUue60HdlMAR6cO9Q==; 10:q9uxchLq79y6R1fKvuKcWxIYhTYMB0XoWkfVHcquMFQWHS58v1bAJ3/M+r4g6v4ZM0hWnY6qtOSnHkcuFP+M89kJw2Lxf1LpGMc1Ii0O1FA=; 6:7ArrDVCzTPNf8ZOzjANgcQZWzgkrp9UstsOzMZJPjU78dXN9tQP69LdnAl5MAOpm X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2015 12:27:02.5912 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0744 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 12:27:13 -0000 Hi Tanja, miTLS-0.8.1 (http://www.mitls.org/downloads/miTLS-0.8.1.tgz) comes with a t= able (data/dh/dhparams-db.bin) with just one entry for the 2432-bit group u= sed by default. In case you wonder, that group comes from an early version = of the negotiated-ff-dhe draft and uses a safe prime. We have a larger table that includes several common DSA parameters. We got = the q values from many sources, including RFCs and factorization with GMP-E= CM and CADO-NFS. Our plan is to include that table and utilities to maintai= n it in the next release of miTLS, but I'm also working on making it availa= ble independently. ________________________________________ From: Tanja Lange Sent: Sunday, May 24, 2015 12:20 PM To: Santiago Zanella-Beguelin Cc: Kurt Roeckx; Florian Weimer; tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS Hi, > > When is it non-safe but trusted? > > When it is in the table of trusted parameters, and hence we know the subg= roup order > (the prime q in DSA terminology). Just to avoid misunderstandings, we cla= rified > the formal meaning of "non-safe" earlier in this thread. > Do you have an easy pointer to the table? I've poked around a bit in the online interface but couldn't get to it. Where did you get the DSA parameters from? RFC 5114? Thanks Tanja= From nobody Sun May 24 05:37:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3026D1A8ACA for ; Sun, 24 May 2015 05:37:12 -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_18=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 SmauNdoyifP1 for ; Sun, 24 May 2015 05:37:08 -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 E2D131A8ACB for ; Sun, 24 May 2015 05:37:07 -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=1432471027; x=1464007027; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IJQLao/fNfOswD5qJI3W67VcXUQOFuII7rQDuQ1Q/ss=; b=2MbfTV9ZKmFfh41Kx3iOPIdysYx27VpGvAEmx3C/4e76gF6aT7U/YEL4 xmOc/b5Rw27MkCHHRWOrursiQotYhJQiOcBFaStGNjTLG6ABFrFeCSypv OhAKPYGRiPaGl3PKPKxCoc4wa0HwaXzDchDkGSB6gg3WJMQYmsaO6kQ9S HHoFSs1zIMKrY6DSJg/DQ/2phGSRXpKoXF+sAuqYmc8U7Hs1zY9c49E1P jTGomCWORedlLksWrZjXIca8YVad5u2A5MF3zMOniP3af964vs0N9Bnpg Dhea4Wm9P1RMgBgUMc5EZpBuDT7IAcIBk9nx1kJIEsBHeocGYDrlkqFu7 w==; X-IronPort-AV: E=Sophos;i="5.13,486,1427713200"; d="scan'208";a="18010978" 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; 25 May 2015 00:37:06 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Mon, 25 May 2015 00:37:06 +1200 From: Peter Gutmann To: Santiago Zanella-Beguelin , "" Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AdCUn0KvC4ozoUHOQIKcwi120/Yv8P//aHSAgAOVT2A= Date: Sun, 24 May 2015 12:37:06 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB02AC90@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>, <1432317148442.5357@microsoft.com> In-Reply-To: <1432317148442.5357@microsoft.com> 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: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 12:37:12 -0000 Santiago Zanella-Beguelin writes:=0A= =0A= >We accept them if they're in the pre-populated cache. If not, we reject th= em=0A= >because we can't check the order of the generator and validate ephemeral k= eys.=0A= =0A= Just out of interest and if you have any sort of figures, what sort of=0A= rejection rate do you get, and what sort of distribution do you see for g= =3D2=0A= vs. g=3Danything else? I've seen a lot of g=3D2, then some g <=3D 8 bits, = and a=0A= very few sizeof( g ) =3D=3D sizeof( p ) which I suspect is the q vs. g conf= usion=0A= mentioned elsewhere (looking at dh_check.c, I see that it comments out the= =0A= check for g=3D3, implying perhaps that it's not seen in the wild?). Howeve= r=0A= because I typically don't have direct contact with, or control over, end=0A= users, only developers building end-user products, in my case any check wit= h a=0A= FP rate greater than zero is going to cause headaches. Even something as= =0A= simple as rejecting obviously bogus g values (which is what the broken PLC= =0A= I've mentioned previously does, among assorted other bugs) causes problems= =0A= because what matters is availability, not correct use of DH values (or corr= ect=0A= implementation of the TLS protocol).=0A= =0A= Peter.=0A= From nobody Sun May 24 05:59:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC3D1A8AE0 for ; Sun, 24 May 2015 05:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSTRHeSDVgfq for ; Sun, 24 May 2015 05:59:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1864D1A8AE3 for ; Sun, 24 May 2015 05:59:39 -0700 (PDT) Received: from CY1PR0301MB1257.namprd03.prod.outlook.com (10.161.212.155) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (TLS) id 15.1.166.22; Sun, 24 May 2015 12:59:20 +0000 Received: from BY2PR03CA002.namprd03.prod.outlook.com (10.255.93.19) by CY1PR0301MB1257.namprd03.prod.outlook.com (10.161.212.155) with Microsoft SMTP Server (TLS) id 15.1.166.22; Sun, 24 May 2015 12:59:18 +0000 Received: from BL2FFO11FD054.protection.gbl (10.255.93.4) by BY2PR03CA002.outlook.office365.com (10.255.93.19) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Sun, 24 May 2015 12:59:18 +0000 Authentication-Results: spf=pass (sender IP is 206.191.250.196) smtp.mailfrom=microsoft.com; cs.auckland.ac.nz; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.250.196 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.250.196; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.250.196) by BL2FFO11FD054.mail.protection.outlook.com (10.173.161.182) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Sun, 24 May 2015 12:59:16 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) by DB4PR30MB032.064d.mgd.msft.net (141.251.50.216) with Microsoft SMTP Server (TLS) id 15.1.112.16; Sun, 24 May 2015 12:59:15 +0000 Received: from DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) by DB4PR30MB032.064d.mgd.msft.net ([141.251.50.216]) with mapi id 15.01.0112.000; Sun, 24 May 2015 12:59:14 +0000 From: Santiago Zanella-Beguelin To: Peter Gutmann , "" Thread-Topic: [TLS] Another IRINA bug in TLS Thread-Index: AdCUn0KvDdHZ+lmQNUW54l67jurcrQAGEh4FAFmzKQAAABp43w== Date: Sun, 24 May 2015 12:59:14 +0000 Message-ID: <1432472352214.2674@microsoft.com> References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>, <1432317148442.5357@microsoft.com>, <9A043F3CF02CD34C8E74AC1594475C73AB02AC90@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB02AC90@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.216.4.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD054; 1:wajfz4BEd/2GjHik4loItzi38toICJVQkEdccJsckfUNjnwvMdSz7wrPr+T5KhY/PucHVJQgTGXKL0aBXi2THvdyzfDxeS8UJiNnh+2/M/+Umryu99FIn5P5lGvz6cYyTT6uoex9qLFZeC3LZVFFyYmkQg4TNl8W0N+23IsoZ18XpU1RyyP7bAJnDiK/d2sD/rI952Ndqrbx/EnZ7R06NcskMLNZKWaVjiIkmM9aym5DV6eXR9+19gUSStKZ4IIAgkFQmWcBu4AYRgNVsBHGog== X-Forefront-Antispam-Report: CIP:206.191.250.196; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(189002)(106466001)(68736005)(4001540100001)(5001860100001)(2900100001)(62966003)(16796002)(77156002)(2950100001)(54356999)(76176999)(50986999)(50466002)(102836002)(92566002)(36756003)(81156007)(97736004)(86612001)(64706001)(86362001)(5001770100001)(5001960100002)(47776003)(107886002)(189998001)(5001830100001)(23756003)(6806004)(46102003)(87936001)(86146001)(2656002)(69596002)(117636001)(66066001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1257; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB1257; 2:4NXVjx/P1k4crUxvYpx1stEluU8q6110pbrFgT6UGV7woJVpT3QcDxEnMODHe1cP; 2:elPaPEbGdHiUvwwzkSIqPvuGVQ734SlYryQAcszwmr+2/huQt8ZF0Ah6HO0GBJm71+AjQL6hr0+YC2y/p1t0wh5lxb+1tUJfRRfCGB5iYE5TKeUY2Cwf4lMYtkhkbKemD/64dmWeHRocsZtvQE9o0K6vlDezlTEMwHb3Tp+ltY+M2bkNAOM/hwgvjG3lA5zwP8cFUt3zyIvOzci9/0GcU8XIugxYVqe9FQfrT1zR3tClrbZT3KY95UcYpedcWRur; 6:YFkRDa8zeghM9ORVmNVJq+SUBezxWqylXFhDYIVRTMwyax+t6hZH3WnPJitHvpIzENHh+D+/B7OWPFFAasrvu8Vg3kGVfce8ov4f/CwVVvpLIOkq29NfFveMs7U41h1jrIK+hN4mhK5aQ46JHCLo3O1SjEdkT8YnfC5tGLMoomeULMiMtshhR0Lm8psbANcjTzgXb4FanVZ4P9qN6pn8jmpSY7DWxfjMOo52k6CslKaFHaEayt0q4H8rYvaVRU3Du6KV1sW4kJAGChjp43h58lRuPxBGIWapmHwyZ8ub4wWVVE/rr7ysxZKVGu5WAp0+bRdFMLfibTgfXiqAmkJzoENcC+VjTt5/xl8MAc3NauVG1MqfEhKlQXsHL9FQkqEqL1FKDyH3ZGqnQ+pO3GAHQ1op0eF3QPuiNLGSY5gaRurt/BNJDG1NRQnzD55B565xfS4dbkXeXvR8+FxUlcCrcd1n2AtVmHkGmPwsEYamFdQy128hNC5AK846/lnDu0/j X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB1257; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:CY1PR0301MB1257; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB1257; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB1257; 3:M+jrljAFS9j0mjwSuza5czK7teM45XUG9Wi0+3SwcYv0fA1e0g8YDDYyQf2dnmmnGkn/20mGg6H7dMWQy+8uZZx+r4mQHCnvNvNQEBfsFkWolBQKriTHbkMUKCmgPw1xkvP8UEcTpmYjBRBcnHCDMi7q0R45rm+LUwlwqaF+lCm1qQZm0wF5i71k2OHpJ9Ophs3IB4qbO4DNCk5Ge0PVZ+9+B+v2PD2w0G9l2K7Ju3fnwKwbb3dcXeyH/kQgvrTHvZZXi11Kxi44ZAjzlFiX9LfKdVhOIPQX6gBas+EuVeV/FomyvbF5PatY5VCyqiFiEKjJuBGoc015EcKKfoLaiQ== X-Forefront-PRVS: 058637CA05 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; CY1PR0301MB1257; 9:sRo2usngLPUKO22O8zthh+yVipRqoYEf4Oiq5U?= =?iso-8859-1?Q?3oFXOPcv2HaysOfH4NoEOm/sGhpjZuNmx96t0GCAm0aJaQPxRtGrmfGRCX?= =?iso-8859-1?Q?r7WQcyJwieB+U1leFz90Mg2qYF0LbM0zDEUh16lDiJtBGzylXi+Z2osMg3?= =?iso-8859-1?Q?x5qdyZn4KjY7mD+XmETsve4hftuzIDsG12B8PvAO4m8lrPGD5MDpm028vM?= =?iso-8859-1?Q?0HvLYl0oSSgpsTiTloLsBcAT/1g0yrc2LPOUpFsQuxmOPNlAL2uHyjJmNq?= =?iso-8859-1?Q?JOPPjW22tECxI8N9UwU4pj9lvRM1dE92NdZNAcavTiMC3OXC6yCxRBki8W?= =?iso-8859-1?Q?1rPvILOreyWgJWzJk95m6tC6NFHwVXRddBGs9txqXC2JvodjxJdIC4Dkfk?= =?iso-8859-1?Q?XWqK2dhnTGTvR+aNYE3Om87zAEo9SD5f5YbUknjtNbMBzvhQD0Z5GltzjG?= =?iso-8859-1?Q?ajKZYTC/D/kcg8j3I1Nm74CPwrLZhHUGUpU8ub95wso/SBOZsZ5S+vQpN0?= =?iso-8859-1?Q?rYyGHlVGSwnnMRZ27xkNWj+Rxg8wKMgntXsE+o8lt4mPvMF0tYoO5UFuy6?= =?iso-8859-1?Q?kMXp3KEvPa9Gcjk2E3fYx01tfhhmQ+NpeoMYoyhmdU3F27TliWdzC81167?= =?iso-8859-1?Q?hNPBWLQY5G61DKF/ghSJ6yJNMv0+YV8FHaDWREdcEfNqTaPQGLV7FCAhYl?= =?iso-8859-1?Q?laCVzCkjYgykfiahq1EY86+IqJXon6oA6AVMrXCqDoSCyr67wLRuFAk3e7?= =?iso-8859-1?Q?ui8QHPyPsS/QxWhfdvsuxdjAKdZLMBUsh6M3tSE0r++ayCeyN08g0HhOpy?= =?iso-8859-1?Q?pbZ9JscI81m1J/awzfvwL/QkW+ZKJd0YTVa2q47fqQHtOV+8oufM1XL3ad?= =?iso-8859-1?Q?sB3dMZiBfROis8dlKuRnx3NadvMppdD1cn9Z1oLb2MGIOH5KAPCJS8XEFD?= =?iso-8859-1?Q?Nly13YO6ty9YYluFWJ4KBznhTnT77Y/i4QCAbsLX6jsQaE1u3eN+IrRFvq?= =?iso-8859-1?Q?IBr9tbeelr43ym8HGGSZXQsdM9wH2M9fgOKRU1K9iD5gzZDZA0H+h/1dfs?= =?iso-8859-1?Q?f2eVRAA1fAn8rZQ053rs1QKiBABOUpFVswFT1+hEE2apvU+NjJGJCfUU64?= =?iso-8859-1?Q?t4kU1v?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB1257; 3:gLJEh2nOnK5ft9HGH6c5bQW4z0ISevjD8ONAN3kTx3UdCDrk9o4wws72bIz/5GFcmZYJUbo5I752uomRLLENWieZgyLO9WjGHUdnPElV8+YUsLtLK1KsuSc+vt4CeAl4gxya/X4xtgiP7QxwdpQIjg==; 10:mj6PAewkAWPGDOlZo+h8zuGTZ/NAIVwnZpEiWUZPArrNHWIqS47JMYvc1trw2ZYLgJWlqIgKASHQhFS52ufTbQ9D/qtS+SZ9Lu89+Uc9EBg=; 6:xjrWig1bOAH5+qszkQwxpHHZTYwy/bQC+zlyy31oFajF6NXnZNMcdKd1SQX4rpIm X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2015 12:59:16.9823 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.250.196]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB1257 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0841; 2:fB5Kwky8omZytMfbg87MNIAEMuuEfiiUW0IuAtqlXKg4giJV4aRk7xfW5YMX36zB; 2:RKzfAFsmm8xByG7IYsLNt9/XBSP2SDJ5XOH7ivuGbcEP8cEEq2mGyfKtRWLUfWpqKHZHVqDrpBlfYbD8myDYLStAQmjgDbviS9TDnS9zWxu5bl8EbMVUcJq5TdRXuhNPVh9H8aGcdMyG50STgngfsFx5qa2Hw5lLnm4/D1nEPp829H5uny7WUIuFzdFmupCr6MRdQ3qy9Qs58xpOw27H+OJEnkdqlRLcaS8FrTZnQ+XFeovIutbDpupGYXmSLzs4; 9:DPCm4HzV5bZNQnSIbN/G/PIketTRG6wUPbS27n/2VsSej/K8Wk4Rj4DzIk6Bei9akzwf9Boo1+NhCPc/YswLWAenmJugliFgK8w0E9O44DGwDBwlC5RKF1pewSaX1VnNXUQ0/AMCV+OX4qD0Wd0d4w== X-OriginatorOrg: microsoft.com Archived-At: Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 12:59:41 -0000 > Just out of interest and if you have any sort of figures, what sort of > rejection rate do you get, and what sort of distribution do you see for g= =3D2 > vs. g=3Danything else? =20 Sorry, we don't have that sort of telemetry. > I've seen a lot of g=3D2, then some g <=3D 8 bits, and a > very few sizeof( g ) =3D=3D sizeof( p ) which I suspect is the q vs. g co= nfusion > mentioned elsewhere=20 For DSA parameters, sizeof(g) =3D=3D sizeof(p) is what's expected. Rather, sizeof(g) =3D=3D sizeof(q) would be very suspicious. > (looking at dh_check.c, I see that it comments out the > check for g=3D3, implying perhaps that it's not seen in the wild?). =20 Are you talking about OpenSSL? I don't know what it checks. > However because I typically don't have direct contact with, or control ov= er, end > users, only developers building end-user products, in my case any check w= ith a > FP rate greater than zero is going to cause headaches. Even something as > simple as rejecting obviously bogus g values (which is what the broken PL= C > I've mentioned previously does, among assorted other bugs) causes problem= s > because what matters is availability, not correct use of DH values (or co= rrect > implementation of the TLS protocol). Then I'm afraid I cannot help you. What matters to me the most is security, not being able to interoperate with servers using buggy parameters or insecure implementations of TLS. From nobody Sun May 24 10:21:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74621AC412 for ; Sun, 24 May 2015 10:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_18=0.6, 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 EadB3UnvjJVX for ; Sun, 24 May 2015 10:21:49 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EFF81AC402 for ; Sun, 24 May 2015 10:21:49 -0700 (PDT) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-09v.sys.comcast.net with comcast id XtMm1q00254zqzk01tMooM; Sun, 24 May 2015 17:21:48 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-11v.sys.comcast.net with comcast id XtMn1q00L4uhcbK01tMnbg; Sun, 24 May 2015 17:21:48 +0000 Message-ID: <556208AB.2040009@brainhub.org> Date: Sun, 24 May 2015 10:21:47 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz>, <1432317148442.5357@microsoft.com>, <9A043F3CF02CD34C8E74AC1594475C73AB02AC90@uxcn10-tdc05.UoA.auckland.ac.nz> <1432472352214.2674@microsoft.com> In-Reply-To: <1432472352214.2674@microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1432488108; bh=OD/4VGvGyhqin9MCVk8J8FqPjZ9tBHxMtdZ7jUucQOk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=h5aJbrhBTsb1oM2XBCf9rR18h0GnviQkMV2zyleNHJlhBQlzelI/njdk1d+fP6UDj 7N7RbMFwBounmD5ZK9BRejuxYLSz60VcQLh7dRtt4CJ0TPSfOjDuLBz8J+/59aP6/e JSt/i1HDA2IauEWdlSZBQj9RME0zgLWFjzsSQ+C1yOguZlLAZpGLMfv4aikp4zve93 RW3yBOp1X+KZjg0liy5IFaBZsN548py97+j1JAF5i0s6+JOFj9d7GGhgmMM2VpNeTf sE8wlZmqGiGQp2bqoJK3diYiYxGiMjJqjYN/6ttmhoRRucQTSKgvHEWqb+LtVYrJym LyPt3A1BzNylw== Archived-At: Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 17:21:51 -0000 On 05/24/2015 05:59 AM, Santiago Zanella-Beguelin wrote: >> Just out of interest and if you have any sort of figures, what sort of >> rejection rate do you get, and what sort of distribution do you see for g=2 >> vs. g=anything else? > Sorry, we don't have that sort of telemetry. > >> I've seen a lot of g=2, then some g <= 8 bits, and a >> very few sizeof( g ) == sizeof( p ) which I suspect is the q vs. g confusion >> mentioned elsewhere > For DSA parameters, sizeof(g) == sizeof(p) is what's expected. Rather, > sizeof(g) == sizeof(q) would be very suspicious. sizeof(g) ~= sizeof(p) would be expected if one to follow the DSA spec. There are two methods specified, including deterministic/verifiable generation, both resulting in this outcome. See http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf, sec A.2.1, A.2.3 Interestingly, the g validity check in sec A.2.2 may allow small g (except in the case of a verifiable g). You probably didn't mean strict size checking, but let me note it anyway. Strict checking sizeof( g ) == sizeof( p ) for DSA will result in hard-to-reproduce interoperability failures, which are bugs. Given how the FIPS 186-4 is specified, it's unreasonable to demand ==. > >> (looking at dh_check.c, I see that it comments out the >> check for g=3, implying perhaps that it's not seen in the wild?). > Are you talking about OpenSSL? I don't know what it checks. > >> However because I typically don't have direct contact with, or control over, end >> users, only developers building end-user products, in my case any check with a >> FP rate greater than zero is going to cause headaches. Even something as >> simple as rejecting obviously bogus g values (which is what the broken PLC >> I've mentioned previously does, among assorted other bugs) causes problems >> because what matters is availability, not correct use of DH values (or correct >> implementation of the TLS protocol). > Then I'm afraid I cannot help you. What matters to me the most is > security, not being able to interoperate with servers using buggy > parameters or insecure implementations of TLS. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun May 24 12:42:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5991ACE6E for ; Sun, 24 May 2015 12:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, 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 sQsVY82nT4t2 for ; Sun, 24 May 2015 12:42:24 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12ED41ACE6C for ; Sun, 24 May 2015 12:42:23 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) id 1Ywbmq-0001sy-Va; Sun, 24 May 2015 21:42:17 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.84) (envelope-from ) id 1Ywbmq-0007ba-Pc; Sun, 24 May 2015 21:42:16 +0200 From: Florian Weimer To: Christian Huitema References: Date: Sun, 24 May 2015 21:42:16 +0200 In-Reply-To: (Christian Huitema's message of "Fri, 22 May 2015 21:18:41 +0000") Message-ID: <878ucdzrs7.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Another INRIA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 19:42:28 -0000 * Christian Huitema: > Could we please change the subject text of that thread? I used to work > at INRIA (www.inria.fr) and I am a bit surprised to see it called > IRINA... Oh. I thought IRINA referred to some government program this bug allegedly supports/feeds into. From nobody Sun May 24 14:08:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2821A1B5A for ; Sun, 24 May 2015 14:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-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 5zR8qLzK7rEq for ; Sun, 24 May 2015 14:08:09 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E07F1AD0BA for ; Sun, 24 May 2015 14:05:37 -0700 (PDT) Received: from [10.0.69.63] (athyra.geoffk.org [198.0.208.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dragaera.releasedominatrix.com (Postfix) with ESMTP id 4289C33D061; Sun, 24 May 2015 21:05:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Geoff Keating In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB02AC04@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sun, 24 May 2015 14:05:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201505211210.43060.davemgarrett@gmail.com> <20150522025214.GA21141@typhoon.azet.org> <201505212304.11513.davemgarrett@gmail.com> <20150522032029.GA24064@typhoon.azet.org> <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB02AC04@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 21:08:13 -0000 > On 24 May 2015, at 4:27 am, Peter Gutmann = wrote: > The overall rationale for not thinking too much about security is that = there's > a higher risk created when a critical device isn't working due to a = particular > security measure than through having some possible, often rather = theoretical, > security flaw present. >=20 > -- Snip -- >=20 > So when given a choice of availability/reliability over security, = availability > wins every time (and quite rightly so). The only time you can fiddle = with it > once it's in place, ever, is when there's a clear and present issue = that > affects availability. "Race condition when reading vibration sensors = is > causing the rotor-imbalance safety cutout to trip and take turbine #3 = offline" > is a clear and present issue. "Haxors might 0wn us" is not, so it'll = be > addressed in the 2018-2023 product cycle. I guess there are two ways to interpret this. One is that owners of some systems have carefully considered the = relative danger of certain upgrades, decided that the necessary = mitigation (testing, staged deployment, backup systems) for that danger = is uneconomic, and have accepted the resulting risk. Perhaps even = computed the danger to the world as a whole and not just to them? Another is that owners of some systems are reflexively against change = without a clear and present danger and don=E2=80=99t care what the = medium-term consequences might be. I=E2=80=99m sure there are some of both, hopefully there are more of the = first. For both of these, it=E2=80=99s better to make a clear recommendation = that early TLS versions are past their expiry date and are not to be = used. For the first kind of owner the costs of supporting the old = versions will fall on them and not on the rest of the Internet, which = will make their economic computation more accurate. The second kind = will discover that off-the-shelf products no longer talk to their = ancient systems and will, slowly and painfully, eventually upgrade.= From nobody Sun May 24 16:24:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B8A1A01F0 for ; Sun, 24 May 2015 16:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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, FREEMAIL_REPLYTO=1, 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 Pp4ue1qxb6Bq for ; Sun, 24 May 2015 16:24:14 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::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 CA0B81A01A8 for ; Sun, 24 May 2015 16:24:14 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so26700902igb.1 for ; Sun, 24 May 2015 16:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yu/TPfFhpaL/rqAoDX9s638J6+IEGjT6/iOjd5qr8FI=; b=FPfI2IyYZQz7piSzmmv3nl+fdbt5LjZ4y1FiarMHu90PLCaF6vqWXuQcLIe5R+MuAB H+TQSoL7GaSmvLnSWXeGCnuXOTRr/HT02V7LKxiibC0/BTjqhVdN63BENr4FVmVM5aCS /TO7ee/HRBgALRNDmiMYvHF6vOZoFGvBApgcfMf7+YhovOegZ3ATq/x51SLiQk+/YnPU Hah1jA3ioV8kgaf/hWwM45AjVkokylq8C7pET072HqQSPBAR80JIIT8bZh7DZoq1SBll NA/ViiJoeXvxiTRRfn9lRMdmDx5yCPBB+IqWaYX9YtCH69FW22xh9MpdGI0TVbsKuI3h yqBg== MIME-Version: 1.0 X-Received: by 10.107.29.148 with SMTP id d142mr25963600iod.9.1432509854203; Sun, 24 May 2015 16:24:14 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Sun, 24 May 2015 16:24:14 -0700 (PDT) In-Reply-To: References: <201505221236.34122.davemgarrett@gmail.com> Date: Sun, 24 May 2015 19:24:14 -0400 Message-ID: From: Jeffrey Walton To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 23:24:16 -0000 On Fri, May 22, 2015 at 5:52 PM, Bill Frantz wrote: > On 5/22/15 at 9:36 AM, davemgarrett@gmail.com (Dave Garrett) wrote: > >> On Friday, May 22, 2015 11:38:14 am Salz, Rich wrote: >>> >>> Most of the net doesn't support IPv6. >> >> This is an ISP issue. Plenty of clients support it, but their network >> won't route it. > > Here is another case where revenue models have a significant impact on > security. (Another is the CA system.) ISPs charge extra for IP addresses > that can run servers. If every device has its own IPv6 address, then every > device can run a server. ISPs like IPv4 and NAT. Some of the latest standards are removing IP addresses from X.509 certificates. It appears to be doing so without consideration for the revenue model. I think its more influence from the browsers because it shows up in HTTP Strict Transport Security (HSTS), Appendix A; and the upcoming Public Key Pinning with Overrides (HPKP). Because its being influenced by the browsers, I'm guessing the only revenue model being considered is the third party ad model, where a client is told to fetch a resource and possibly execute code from a third party server so the origin can get paid. I don't know what the IETF's official policy is on DNS names versus IP addresses. Jeff From nobody Mon May 25 04:19:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE89A1B2BE4 for ; Mon, 25 May 2015 04:19:30 -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_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGDJwyZgJYj8 for ; Mon, 25 May 2015 04:19:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 8D1CC1B2BE5 for ; Mon, 25 May 2015 04:19:26 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4PBJOuJ020341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 25 May 2015 07:19:24 -0400 Received: from pintsize.usersys.redhat.com (dhcp-0-197.brq.redhat.com [10.34.0.197]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4PBJMT7015037 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 25 May 2015 07:19:24 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 25 May 2015 13:19:16 +0200 Message-ID: <1741939.XqFprS2C0B@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/3.19.7-200.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1758984.OKhEygvoUU"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: Karthikeyan Bhargavan Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 11:19:31 -0000 --nextPart1758984.OKhEygvoUU Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 22 May 2015 14:12:51 Tony Arcieri wrote: > On Fri, May 22, 2015 at 1:36 PM, Karthikeyan Bhargavan < >=20 > karthik.bhargavan@gmail.com> wrote: > > 1) Switch to ECDHE. > >=20 > > It is faster, and the kinds of attacks discussed in our paper h= ave not > >=20 > > (yet) been shown to be effective for the common curves. > >=20 > > As usual, we need to be wary of weak curves (160-bit) or curves= that > >=20 > > may have been generated maliciously. > >=20 > > We leave it to the EC folks to tell us what are good curves to = use. >=20 > +1 on this. The CFRG has already specified Curve25519 and Ed448-Goldi= locks > for use in this case: >=20 > https://tools.ietf.org/html/draft-irtf-cfrg-curves-02 >=20 > Finite field D-H is slower and more problematic. I know people want i= t as a > fallback in the event there's some sort of terrible breakage in ECC, = but if > that does happen, why not temporarily abandon forward secrecy until t= he > problem can be addressed instead of switching to finite field D-H? There is a second side to this coin. Implementing ECDH (just like most ECC), is much harder that DH or RSA. As such, for old software that receives just minimal maintenance it is = easier=20 to add support for advertising support for (big) FF-DHE than to add ECD= HE. =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1758984.OKhEygvoUU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVYwU6AAoJEJKo0bgB0vX1KfAP/iTVguidgcEcul0WqUW/R/eF weIovnRYspDdJFSC4Hnyu/5KhBoWdzcmw0yyZQJ99FZCReDZ2UyyM0RHMTVU0J4L t9SrpmEZ2nGw6rfihVtznugHgGGULgfs85W0DYAof1JpeGcssQoLMY+ESDv97Xa0 26TV3nP/m7wzkyLT5N104Er/C/hzcojzJ4zITdYlf7PoViPwaGeFApTM8vSup/p+ T4iGq2xuzboVCQjL/WM0oUYiL7VgWLlRL8wcC7p5HH93E/yHFxQsd32q6E8apHvK Im3pKkjvkNBKtLeyYX6FQzJ3qXwW4MHcnrFofLeR6jhemqG47egAucA68D20pfL8 V7Yvr1tUdxD731RyeJr1eGWTe3LkQedAvic92hAauabl/jxbiA72xzjLBF5YQtU6 4MNwCD0hD0qaahhhxvFBioNTdbgTQzw4H583Hr0mfCBh6GlrQecRBV5XbNMCFZ1Z OUYAHSssFQTt8jUykqk1fWq8trr7v1ccxp0PGHhxV7GxIzDBEG1HhrjSURWPi0tQ Ot6TtvRrMaG5g9BSgwP3JL2hMNAKcr3hmZgMi1EA1xi9khJm5cMydGWxnNoiKmGX 8BNJhBov8Lznf5PkqxNy/oQ5UpbWf0C3/z/rpLhVOYdRnbU8x9cfLd++nCNRX0u2 DhaJxv6NoJ9mqczAUlXB =SvR9 -----END PGP SIGNATURE----- --nextPart1758984.OKhEygvoUU-- From nobody Mon May 25 05:02:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF76A1B2C51 for ; Mon, 25 May 2015 05:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqavNSA49CDn for ; Mon, 25 May 2015 05:02:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD071B2C4F for ; Mon, 25 May 2015 05:02:48 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 3376F8E3E4; Mon, 25 May 2015 12:02:47 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-197.brq.redhat.com [10.34.0.197]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4PC2jUu014581 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 25 May 2015 08:02:46 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 25 May 2015 14:02:40 +0200 Message-ID: <2255850.hidEDnQLjj@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/3.19.7-200.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <20150523101609.GA9409@roeckx.be> References: <20150523101609.GA9409@roeckx.be> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2676082.N3PFI2CNMp"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 12:02:53 -0000 --nextPart2676082.N3PFI2CNMp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Saturday 23 May 2015 12:16:09 Kurt Roeckx wrote: > On Thu, May 21, 2015 at 12:10:07PM +0200, Yngve N. Pettersen wrote: > > On Thu, 21 May 2015 12:02:19 +0200, Peter Gutmann > >=20 > > wrote: > > >Santiago Zanella-Beguelin writes: > > >>We did find many HTTPS servers supporting > > >>TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA. > > > > > >Just to make sure that's not a typo, you're saying you *did* (not = didn't) > > >find > > >many servers supporting 40-bit DES as a cipher? Wow. How many > > >approximately, > > >are we talking tens, thousands, millions? > >=20 > > For reference, in my 530K sample (Biased towards Alexa top million = sites) > > there are 60000 servers (11.38%) that have that specific cipher sui= te > > enabled, as of Monday this week. >=20 > Hubert Kario's latest results on > https://securitypitfalls.wordpress.com/2015/03/29/march-2015-scan-res= ults/ > show: > EXP-EDH-RSA-DES-CBC-SHA 22110 4.5043% hmm, that is a bit big difference... If I ignore the "trust" bit in results I'm still getting just: EXP-EDH-RSA-DES-CBC-SHA 41804 6.2565 From=20668168 sample. But then there is something which matches rather well the percentage: EDH-RSA-DES-CBC-SHA 75939 11.3653 (note the lack of "EXP-") =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2676082.N3PFI2CNMp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVYw9kAAoJEJKo0bgB0vX1HxsP/1XrwpbdtJgvy/yW/KDyStS0 Ro0n3QaeDr+XwT8GbXx+ycQf7tvAQNLY4Z+IkQJbv1nrX/mD7C94rcBol+kQh+YO N/OS102GlcJIzH3jrnIwGBdpb1s7fJ0mnJSEPUtilCBnZJjxsNViAxloxTm79tkD yLLMeWO2+bmODqhK7iu7PgUTWVN9xKnp17HNEdDKHZ4CsS2j0Nxgi8NM9rP8DanM Y9WJRM/Q3pB/gvfN5EcesYM8ShLyjeJzdzx8hTEL5IfL4ps4pTl49VTVp+s3knZ+ HhHBhtRtT+TtvYKkdgsJVmBObH/rgjy6W2Rygu/BldVizXSN/c78qvfCYuqs7phx Pb+clf+bBlHMWe5jMo9h+MK7PuTQdBk0RKGkFNxgWaIihnQfr8sVulxoXo2fTLWu dufRs/Ov1fF5YuUYyCSLOP5EO6w6xoUWG2/jd1FG6CKFtP3ybFbc/62JGgyQG9ll hYm6hR5OT2QsalheCGurUKqGpW02EPM6Tp8urT2fvFZ6wrqFfV8fb0mkLp0drMI1 3MZQP0uyKhi+wsN0DCJikQYeZ40yGN9OCUMQicqegIsQr42X54Mqcty3Mng+m1kJ B6H2lqljaYml5sCvmJi8ih1YWqpC1f6MKIsfJ3YFfONYQIDfZNWvaxHrZdeqA3oi zJKBWlM40X/irJUeW+sP =/e4W -----END PGP SIGNATURE----- --nextPart2676082.N3PFI2CNMp-- From nobody Mon May 25 05:27:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D191A8969 for ; Mon, 25 May 2015 05:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 hQ3VJ8N0x_my for ; Mon, 25 May 2015 05:26:55 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFB81A8965 for ; Mon, 25 May 2015 05:26:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,491,1427752800"; d="scan'208,217";a="154006478" Received: from wifi-auth-191208.inria.fr ([128.93.191.208]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 25 May 2015 14:26:53 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_A48218A6-32F3-40BA-9BD0-89D7F0A8A0C1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: <2255850.hidEDnQLjj@pintsize.usersys.redhat.com> Date: Mon, 25 May 2015 14:26:52 +0200 Message-Id: <61EBC3C9-0C0E-499E-9108-2432D9201FDB@gmail.com> References: <20150523101609.GA9409@roeckx.be> <2255850.hidEDnQLjj@pintsize.usersys.redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 12:26:59 -0000 --Apple-Mail=_A48218A6-32F3-40BA-9BD0-89D7F0A8A0C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 25 May 2015, at 14:02, Hubert Kario wrote: >> Hubert Kario's latest results on >> = https://securitypitfalls.wordpress.com/2015/03/29/march-2015-scan-results/= >> show: >> EXP-EDH-RSA-DES-CBC-SHA 22110 4.5043% >=20 > hmm, that is a bit big difference... >=20 > If I ignore the "trust" bit in results I'm still getting just: > EXP-EDH-RSA-DES-CBC-SHA 41804 6.2565 At weakdh.org, we use numbers from the ZMap scans (https://scans.io/) In March 2015, the number of servers supporting for TLS_DHE_*_EXPORT_* = were: Alexa Top 1M: 45 K hosts out of 539K HTTPS hosts (4.9%) Browser-trusted : 706K hosts out of 14.3M HTTPS hosts with browser = trusted certs (8.4%) We think the numbers should have gone down some, partly due to servers = turning off *_EXPORT_* in the wake of FREAK (but sadly, not nearly enough servers reacted to = FREAK). Best, Karthik >=20 > =46rom 668168 sample. >=20 > But then there is something which matches rather well the percentage: > EDH-RSA-DES-CBC-SHA 75939 11.3653 > (note the lack of "EXP-") > --=20 > Regards, > Hubert Kario > Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech = Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_A48218A6-32F3-40BA-9BD0-89D7F0A8A0C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 25 May 2015, at 14:02, Hubert Kario = <hkario@redhat.com> = wrote:

Hubert= Kario's latest results on
https://securitypitfalls.wordpress.com/2015/03/29/march-2015-sca= n-results/
show:
EXP-EDH-RSA-DES-CBC-SHA 22110 =     4.5043%

hmm, that is a bit = big difference...

If I ignore the "trust" bit in results I'm = still getting just:
EXP-EDH-RSA-DES-CBC-SHA 41804 =     6.2565

At weakdh.org, we use numbers from the ZMap = scans (https://scans.io/)

In March 2015, the number of servers supporting for TLS_DHE_*_EXPORT_* = were:

Alexa Top 1M:      45 K = hosts out of 539K HTTPS hosts (4.9%)
Browser-trusted : 706K = hosts out of 14.3M HTTPS hosts with browser trusted certs = (8.4%)

We think the numbers should have gone = down some, partly due to servers turning off *_EXPORT_*
in the = wake of FREAK (but sadly, not nearly enough servers reacted to = FREAK).

Best,
Karthik







=46rom 668168 sample.

But then there is = something which matches rather well the = percentage:
EDH-RSA-DES-CBC-SHA     75939 =     11.3653
(note the lack of "EXP-")
-- =
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security = team
Web: www.cz.redhat.com
Red Hat Czech = s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech = Republic_______________________________________________
TLS mailing = list
TLS@ietf.org
https://www.ietf.org/mail= man/listinfo/tls

= --Apple-Mail=_A48218A6-32F3-40BA-9BD0-89D7F0A8A0C1-- From nobody Mon May 25 05:28:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58B61A8955 for ; Mon, 25 May 2015 05:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 HPQPN_MCihB3 for ; Mon, 25 May 2015 05:27:57 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5565D1A896C for ; Mon, 25 May 2015 05:27:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,491,1427752800"; d="scan'208,217";a="154008358" Received: from wifi-auth-191208.inria.fr ([128.93.191.208]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 25 May 2015 14:27:55 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_A06D62C0-63C1-41EA-AE00-EBDED33A797E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: <61EBC3C9-0C0E-499E-9108-2432D9201FDB@gmail.com> Date: Mon, 25 May 2015 14:27:55 +0200 Message-Id: <3B25BA9D-BC3C-4F7E-9C39-341738CF8BE3@gmail.com> References: <20150523101609.GA9409@roeckx.be> <2255850.hidEDnQLjj@pintsize.usersys.redhat.com> <61EBC3C9-0C0E-499E-9108-2432D9201FDB@gmail.com> To: Karthikeyan Bhargavan X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 12:28:02 -0000 --Apple-Mail=_A06D62C0-63C1-41EA-AE00-EBDED33A797E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Argh, percentages revesed: Alexa Top 1M: 45 K hosts out of 539K HTTPS hosts (8.4%) Browser-trusted : 706K hosts out of 14.3M HTTPS hosts with browser = trusted certs (4.9%) On 25 May 2015, at 14:26, Karthikeyan Bhargavan = wrote: >=20 > On 25 May 2015, at 14:02, Hubert Kario wrote: >=20 >>> Hubert Kario's latest results on >>> = https://securitypitfalls.wordpress.com/2015/03/29/march-2015-scan-results/= >>> show: >>> EXP-EDH-RSA-DES-CBC-SHA 22110 4.5043% >>=20 >> hmm, that is a bit big difference... >>=20 >> If I ignore the "trust" bit in results I'm still getting just: >> EXP-EDH-RSA-DES-CBC-SHA 41804 6.2565 >=20 > At weakdh.org, we use numbers from the ZMap scans (https://scans.io/) >=20 > In March 2015, the number of servers supporting for TLS_DHE_*_EXPORT_* = were: >=20 > Alexa Top 1M: 45 K hosts out of 539K HTTPS hosts (4.9%) > Browser-trusted : 706K hosts out of 14.3M HTTPS hosts with browser = trusted certs (8.4%) >=20 > We think the numbers should have gone down some, partly due to servers = turning off *_EXPORT_* > in the wake of FREAK (but sadly, not nearly enough servers reacted to = FREAK). >=20 > Best, > Karthik >=20 >=20 >=20 >=20 >=20 >=20 >>=20 >> =46rom 668168 sample. >>=20 >> But then there is something which matches rather well the percentage: >> EDH-RSA-DES-CBC-SHA 75939 11.3653 >> (note the lack of "EXP-") >> --=20 >> Regards, >> Hubert Kario >> Quality Engineer, QE BaseOS Security team >> Web: www.cz.redhat.com >> Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech = Republic_______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_A06D62C0-63C1-41EA-AE00-EBDED33A797E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Argh, = percentages revesed:

Alexa Top 1M:     =  45 K hosts out of 539K HTTPS hosts = (8.4%)
Browser-trusted : 706K hosts out of 14.3M HTTPS hosts = with browser trusted certs (4.9%)

On 25 = May 2015, at 14:26, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:


Hubert= Kario's latest results on
https://securitypitfalls.wordpress.com/2015/03/29/march-2015-sca= n-results/
show:
EXP-EDH-RSA-DES-CBC-SHA 22110 =     4.5043%

hmm, that is a bit = big difference...

If I ignore the "trust" bit in results I'm = still getting just:
EXP-EDH-RSA-DES-CBC-SHA 41804 =     6.2565

At weakdh.org, we use numbers from the ZMap = scans (https://scans.io/)

In March 2015, the number of servers supporting for TLS_DHE_*_EXPORT_* = were:

Alexa Top 1M:      45 K = hosts out of 539K HTTPS hosts (4.9%)
Browser-trusted : 706K = hosts out of 14.3M HTTPS hosts with browser trusted certs = (8.4%)

We think the numbers should have gone = down some, partly due to servers turning off *_EXPORT_*
in the = wake of FREAK (but sadly, not nearly enough servers reacted to = FREAK).

Best,
Karthik







=46rom 668168 sample.

But then there is = something which matches rather well the = percentage:
EDH-RSA-DES-CBC-SHA     75939 =     11.3653
(note the lack of "EXP-")
-- 
Regards,
Hubert = Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat = Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech = Republic_______________________________________________
TLS mailing = list
TLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tls

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

= = --Apple-Mail=_A06D62C0-63C1-41EA-AE00-EBDED33A797E-- From nobody Mon May 25 05:54:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD461A898D for ; Mon, 25 May 2015 05:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3XWLTl8Jrdz for ; Mon, 25 May 2015 05:54:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 809861A899D for ; Mon, 25 May 2015 05:54:50 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4PCsmFJ015119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 25 May 2015 08:54:48 -0400 Received: from pintsize.usersys.redhat.com (dhcp-0-197.brq.redhat.com [10.34.0.197]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4PCsl4G026068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 25 May 2015 08:54:48 -0400 From: Hubert Kario To: Karthikeyan Bhargavan Date: Mon, 25 May 2015 14:54:39 +0200 Message-ID: <1854255.99pv4gbKBC@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.7 (Linux/3.19.7-200.fc21.x86_64; KDE/4.14.7; x86_64; ; ) In-Reply-To: <3B25BA9D-BC3C-4F7E-9C39-341738CF8BE3@gmail.com> References: <61EBC3C9-0C0E-499E-9108-2432D9201FDB@gmail.com> <3B25BA9D-BC3C-4F7E-9C39-341738CF8BE3@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2721732.I0YJ9b1Wxd"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Another IRINA bug in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 12:54:54 -0000 --nextPart2721732.I0YJ9b1Wxd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 25 May 2015 14:27:55 Karthikeyan Bhargavan wrote: > Argh, percentages revesed: >=20 > Alexa Top 1M: 45 K hosts out of 539K HTTPS hosts (8.4%) which would align with the "ignored trust bit" (3k difference), as ciph= erscan=20 is using a scanning method which will under-report servers with broken = cipher=20 selection (intolerance to big client hello's, RC4 ciphers low in order,= etc.). Those broken servers can account for up to 11k or 8.8k hosts (when igno= ring=20 trust) depending on how you count. Anyway, I've started a new scan yesterday, we'll see how quickly=20 administrators reacted. My scans are also on https://scans.io (look for Fedora Project), if you= 're=20 interested in raw data. But AFAIK, Yngve's aren't and those are the ones we were commenting abo= ut. > Browser-trusted : 706K hosts out of 14.3M HTTPS hosts with browser tr= usted > certs (4.9%) > On 25 May 2015, at 14:26, Karthikeyan Bhargavan=20 wrote: > > On 25 May 2015, at 14:02, Hubert Kario wrote: > >>> Hubert Kario's latest results on > >>> https://securitypitfalls.wordpress.com/2015/03/29/march-2015-scan= =2Dresult > >>> s/ > >>> show: > >>> EXP-EDH-RSA-DES-CBC-SHA 22110 4.5043% > >>=20 > >> hmm, that is a bit big difference... > >>=20 > >> If I ignore the "trust" bit in results I'm still getting just: > >> EXP-EDH-RSA-DES-CBC-SHA 41804 6.2565 > >=20 > > At weakdh.org, we use numbers from the ZMap scans (https://scans.io= /) > >=20 > > In March 2015, the number of servers supporting for TLS_DHE_*_EXPOR= T_* > > were: > >=20 > > Alexa Top 1M: 45 K hosts out of 539K HTTPS hosts (4.9%) > > Browser-trusted : 706K hosts out of 14.3M HTTPS hosts with browser = trusted > > certs (8.4%) > >=20 > > We think the numbers should have gone down some, partly due to serv= ers > > turning off *_EXPORT_* in the wake of FREAK (but sadly, not nearly = enough > > servers reacted to FREAK). > >=20 > > Best, > > Karthik > >=20 > >> From 668168 sample. > >>=20 > >> But then there is something which matches rather well the percenta= ge: > >> EDH-RSA-DES-CBC-SHA 75939 11.3653 > >> (note the lack of "EXP-") > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2721732.I0YJ9b1Wxd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVYxuWAAoJEJKo0bgB0vX10cgP/idFdHF9Hpp02RkhJXbRaQVZ dC+7uCvEzog2r/uxt/ZwWLbha5Ns00xpPRwz8/piwyIn/mIxydg8oNwGoYB/WSOR kRwtSa38hO1njx5Bu6rXJRoztg91CEt/hlQZwTWfQLJrsTPI03wV22+OhxhQuq9g RdA/voeNong6qqK8nwdsCIPeiW4wMuq/r8aHCrv21sBww+3YsMHf2CwHeYTJiCKM kR4ZqLBQ7E8uwp5DMfxajP5EZm2DEAT4003kP5MGk2LbgrKD9CNcy5W2NVSI6Dda 2sTub9k2f7u4S27dDJUqKTSrU70W+DyGYvDGCnVvUFkG2Gse6n7qYINwID93OqQU cb5R1VrEw4scDlrCTp7uC2/GwALJZBVRelXVwjaKCo3d0cxTzgHkC9MIbQ6YEdEu 91fJqysNnHXEgvKj4jMGdfCE5IQw5LlmQR4NBuUnu1tujq8xGBYDulcLkO0ImZve Sp2pMQmpr2tcgSfl6/sURfP75lcVLzj2v6Bi4zEa6lvF2W6Gdt/wxTsufhD5bdU4 kQyFuulOKAqqUT0SageifOAdQLkM1fhXLq7hetZw6Zc/sIjo+KmJVycsQz2AAyQv 6ZKGckP1yaNnnm2hQIF0FOI4nLBoEK8GIhngOY/C6xQlBpZCIyd1nNl7F7UszSAq XOYlYk0rEU5Gv/mitC2w =AUjl -----END PGP SIGNATURE----- --nextPart2721732.I0YJ9b1Wxd-- From nobody Mon May 25 10:36:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5CE1ACD7C for ; Mon, 25 May 2015 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 LxjD_nb8I7EX for ; Mon, 25 May 2015 10:36:12 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.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 DD8D01ACD63 for ; Mon, 25 May 2015 10:36:11 -0700 (PDT) Received: by wifw1 with SMTP id w1so4212580wif.0 for ; Mon, 25 May 2015 10:36:10 -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:from:date:message-id:subject:to :content-type; bh=jxJBFLDL3+426ahx6M6lPk82LSQa7OpvKm6+95YnISo=; b=S6prA7ZIaD/tpVaYxrZZfhcEYTbgFQq/5EsJVxXyjCv7LeSCy6ceyI3n6xlEBz2xqk UTqSxxkR054p+gwstnJreM4Lc5JwYnk1Sgo6OUtIjF/yH0X+4+m4yvrcfccaBKK6zuPB h8s2Xk6hmbP1MBJ8jLUXyg2fzRF/8yvkc8r/btxC/sAJ33S76l6XIqr9a6Xb9CS4HsPP teuXcV5aQo5w57weA7dY04+4e0nqa/1o6IdiDDhWU6oxDum/e3QZG/R6Lu1IXLDxfHGV x6ulISV7lK3yTisnvnWPNskBtxvx5brRQci4fkfuxfHYJAME/ZaPuy5VSlvnJdgX/Y7h OwzQ== X-Gm-Message-State: ALoCoQlzmyjTbwrf82IDhf017VGk3kk4NY444VFomlP8FEjCRV4Lh1clqa7qXBhcKDlUi+bk1Kyo X-Received: by 10.194.59.79 with SMTP id x15mr24257494wjq.81.1432575370643; Mon, 25 May 2015 10:36:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Mon, 25 May 2015 10:35:30 -0700 (PDT) From: Eric Rescorla Date: Mon, 25 May 2015 10:35:30 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b8737ae14f6340516eb7252 Archived-At: Subject: [TLS] More clarity on resumption and session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 17:36:14 -0000 --047d7b8737ae14f6340516eb7252 Content-Type: text/plain; charset=UTF-8 I'm updating the NSS session hash implementation to conform to the new spec and I see that it's very clear on what happens when you have a resumption where the original handshake did not include the extension and the new one does (thanks David and Martin) o If the original session did not use an extended master secret but the new ClientHello does contain the "extended_master_secret" extension, the server MUST NOT perform the abbreviated handshake. Instead, it SHOULD continue with a full handshake to negotiate a new session. However, it's less clear on what happens when the original handshake included the extension and the new one does not: o If the new ClientHello does not contain the "extended_master_secret" extension, the server SHOULD abort the handshake. If it continues with an abbreviated handshake in order to interoperate with legacy peers, then the considerations in Section 5.4 apply. This doesn't seem to distinguish between the two cases (original session did and did not use the extension), but they seem different, since the original session not using session hash is a common case (legacy) whereas an extension->no extension transition is an anomaly. Note that the client *is* required to send it, so I think there's a reasonably strong argument that the server should require it. The two main options appear to be: 1. Fall back to a full handshake. 2. Abort the connection The argument for the first appears to be interop. The argument for the second appears to be that it's likely there is an error or a mid-flight reconfiguration on the client (which seems not good). My mild preference is for abort but I think it's important in any case that the draft be clear. Similarly, the text about the client side doesn't seem to draw this distinction: If the new ServerHello does not contain the "extended_master_secret" extension, the client SHOULD abort the handshake. If it continues with an abbreviated handshake in order to interoperate with legacy peers, then the considerations in Section 5.4 apply. Because above the server is required to provide the extension when resuming a session where the extension was negotiated, it seems like we should require the client to fail in that case (that's the sense of the MUST). I see there was some discussion on the list 3/10 but it was inconclusive. -Ekr --047d7b8737ae14f6340516eb7252 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 


<=
/div>


I'm updating the NSS sessi=
on hash implementation to conform to the new spec
and I see that =
it's very clear on what happens when you have a resumption
wh=
ere the original handshake did not include the extension and the new one
does (thanks David and Martin)

=C2=A0 o =
=C2=A0If the original session did not use an extended master secret but
=C2=A0 =C2=A0 =C2=A0 the new ClientHello does contain the "exte=
nded_master_secret"
=C2=A0 =C2=A0 =C2=A0 extension, the serv=
er MUST NOT perform the abbreviated handshake.
=C2=A0 =C2=A0 =C2=
=A0 Instead, it SHOULD continue with a full handshake to negotiate a
<=
div>=C2=A0 =C2=A0 =C2=A0 new session.

However, it&=
#39;s less clear on what happens when the original handshake included
=

the extension and the new one does not:

=C2=
=A0 =C2=A0o =C2=A0If the new ClientHello does not contain the
=C2=
=A0 =C2=A0 =C2=A0 "extended_master_secret" extension, the server =
SHOULD abort the
=C2=A0 =C2=A0 =C2=A0 handshake.=C2=A0 If it cont=
inues with an abbreviated handshake in order
=C2=A0 =C2=A0 =C2=A0=
 to interoperate with legacy peers, then the considerations in
=
=C2=A0 =C2=A0 =C2=A0 Section 5.4 apply.

This doesn=
't seem to distinguish between the two cases (original session
did and did not use the extension), but they seem different, since the
original session not using session hash is a common case (legacy) w=
hereas
an extension->no extension transition is an anomaly. No=
te that the client
*is* required to send it, so I think there'=
;s a reasonably strong
argument that the server should require it=
.

The two main options appear to be:
=C2=A0 =C2=A0 1. Fall back to a full handshake.
=C2=
=A0 =C2=A0 2. Abort the connection

The argument fo=
r the first appears to be interop. The argument for the
second ap=
pears to be that it's likely there is an error or a mid-flight
reconfiguration on the client (which seems not good). My mild preference<=
/div>
is for abort but I think it's important in any case that the =
draft be
clear.


Similarly=
, the text about the client side doesn't seem to draw this
di=
stinction:

=C2=A0 =C2=A0 =C2=A0 If the new ServerH=
ello does not contain the
=C2=A0 =C2=A0 =C2=A0 "extended_mas=
ter_secret" extension, the client SHOULD abort the
=C2=A0 =
=C2=A0 =C2=A0 handshake.=C2=A0 If it continues with an abbreviated handshak=
e in order
=C2=A0 =C2=A0 =C2=A0 to interoperate with legacy peers=
, then the considerations in
=C2=A0 =C2=A0 =C2=A0 Section 5.4 app=
ly.

Because above the server is required to provid=
e the extension when
resuming a session where the extension was n=
egotiated, it seems like
we should require the client to fail in =
that case (that's the sense
of the MUST).

I see there was some discussion on the list 3/10 but it was inconclus=
ive.

-Ekr



--047d7b8737ae14f6340516eb7252--


From nobody Mon May 25 10:45:13 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABD51A1A13 for ; Mon, 25 May 2015 10:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level: 
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8l-todogAKW for ; Mon, 25 May 2015 10:45:10 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED181A036B for ; Mon, 25 May 2015 10:45:09 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,493,1427752800";  d="asc'?scan'208";a="154369643"
Received: from 178.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.178]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 25 May 2015 19:45:07 +0200
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_2CAEE669-3137-4279-9F4E-695B9011C4A1"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Karthikeyan Bhargavan 
In-Reply-To: 
Date: Mon, 25 May 2015 19:45:05 +0200
Message-Id: <66ECB7D5-19B1-429F-8FE2-464671672310@inria.fr>
References: 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2015 17:45:12 -0000

--Apple-Mail=_2CAEE669-3137-4279-9F4E-695B9011C4A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Right, there was discussion on this and here=92s the current rationale.

If the original handshake used the extended master secret,
then even if the resumption handshake does not, it is still protected
by the key derivation in the original handshake.

The only situation when I can see this happening is when the resumption =
handshake goes to different
endpoints than the original handshake (e.g. in WPA), but maybe someone =
on the list knows better whether the following is a reasonable use case.

The client connects to an access point which forwards the (EAP-TLS) =
connection to the (Radius) server.
The server speaks TLS + extended master secret and the client and server =
agree upon a master secret.
The server installs the master secret at the access point, which itself =
does not support extended master secret.
The client can now communicate directly with the access point,  and also =
resume (EAP fast reauth) connections directly with access points without =
the need to recontact the Radius server

A similar scenario can perhaps be envisioned in cases where a server =
farm of front-ends directs initial connections to a powerful server that =
supports extended master secret, but resumption handshakes (via session =
tickets) can be handled by any (legacy) server.

Far fetched?
-K.


On 25 May 2015, at 19:35, Eric Rescorla  wrote:

>=20
>=20
>=20
>=20
> I'm updating the NSS session hash implementation to conform to the new =
spec
> and I see that it's very clear on what happens when you have a =
resumption
> where the original handshake did not include the extension and the new =
one
> does (thanks David and Martin)
>=20
>   o  If the original session did not use an extended master secret but
>       the new ClientHello does contain the "extended_master_secret"
>       extension, the server MUST NOT perform the abbreviated =
handshake.
>       Instead, it SHOULD continue with a full handshake to negotiate a
>       new session.
>=20
> However, it's less clear on what happens when the original handshake =
included
> the extension and the new one does not:
>=20
>    o  If the new ClientHello does not contain the
>       "extended_master_secret" extension, the server SHOULD abort the
>       handshake.  If it continues with an abbreviated handshake in =
order
>       to interoperate with legacy peers, then the considerations in
>       Section 5.4 apply.
>=20
> This doesn't seem to distinguish between the two cases (original =
session
> did and did not use the extension), but they seem different, since the
> original session not using session hash is a common case (legacy) =
whereas
> an extension->no extension transition is an anomaly. Note that the =
client
> *is* required to send it, so I think there's a reasonably strong
> argument that the server should require it.
>=20
> The two main options appear to be:
>=20
>     1. Fall back to a full handshake.
>     2. Abort the connection
>=20
> The argument for the first appears to be interop. The argument for the
> second appears to be that it's likely there is an error or a =
mid-flight
> reconfiguration on the client (which seems not good). My mild =
preference
> is for abort but I think it's important in any case that the draft be
> clear.
>=20
>=20
> Similarly, the text about the client side doesn't seem to draw this
> distinction:
>=20
>       If the new ServerHello does not contain the
>       "extended_master_secret" extension, the client SHOULD abort the
>       handshake.  If it continues with an abbreviated handshake in =
order
>       to interoperate with legacy peers, then the considerations in
>       Section 5.4 apply.
>=20
> Because above the server is required to provide the extension when
> resuming a session where the extension was negotiated, it seems like
> we should require the client to fail in that case (that's the sense
> of the MUST).
>=20
> I see there was some discussion on the list 3/10 but it was =
inconclusive.
>=20
> -Ekr
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--Apple-Mail=_2CAEE669-3137-4279-9F4E-695B9011C4A1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVY1+iAAoJEB/WSo9veuUK0vsH/Rp+HivLJUTDQtlBch4xsR60
Z7OyAW7621Rg3GCf8Z0N73f1mHYkUWgK7qrzDiKhzjK73KXP0621hPK+iA8yiOtN
xw+ZEi75dpv6gn7dd6cX302syDnYuHM0yr60Rwihut843ztNkb01c9DbaUlUQnLN
YsPjduX4gLD4TmbOv/A9fsXFKseG9OkvUhbgsZqeA+E8jva/iwoZwuQH5yLh1v2a
JQlVRZlj86UTtq4YQWHgdcKJFaVu9Rw0kWfyOlP/tmPKkru9nqWPlzGQ4QwvXrHK
nWHKcefUkS6ADhk/UdGcY5cfMExgVb+Zv2puJIoITNpbT0K2/20E1xyijdQRkOY=
=aGGS
-----END PGP SIGNATURE-----

--Apple-Mail=_2CAEE669-3137-4279-9F4E-695B9011C4A1--


From nobody Mon May 25 10:53:37 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09691A8A95 for ; Mon, 25 May 2015 10:53:35 -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 sY1nzPoPRGsA for ; Mon, 25 May 2015 10:53:33 -0700 (PDT)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.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 316BE1A8A10 for ; Mon, 25 May 2015 10:53:33 -0700 (PDT)
Received: by wichy4 with SMTP id hy4so55609402wic.1 for ; Mon, 25 May 2015 10:53: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:from:date :message-id:subject:to:cc:content-type; bh=/E6cFa+zDnwgaDJn7a4a/bmKPZuUspf035H11Lic7gE=; b=ZU1mLLtSe5l4afRZ7Wv11xi2yjJdNszgQ9Zu2TCyGbKm1gUUzGWjk1TfXAGPI4VLC1 8S6NHdvQUCB4ju8pxTJBbA7Rn5o7bsvOdyu7EgIkLlLJxyjG+JBOSQ7bnlfAuitN/ju0 cVWaXgv0feQp2w8X6UhMP794ia2bGhUo2kIQEXmZvsXSV6aXCCx/7zhZUFY8e/PLxZXR oWEQc5KuzxORB1+DBLWMi+dFA8wpoVcVMHIor6JW7knctsRR82iMomaDHj5AySwmwjTd HUGL/N2ySIt//zAxsNZq/Hy0onjstizMoxY931Sx4FGKVRdd36R8YMKGnDCnvvRtR3gj /HjA==
X-Gm-Message-State: ALoCoQlmq/GrFrHeAzrSWtFek8aQakTOKPUuXkJzLfRiIjZNwoqf+wbEIx/LkxWFTvk8QYJUjhmK
X-Received: by 10.194.59.79 with SMTP id x15mr24365177wjq.81.1432576411912; Mon, 25 May 2015 10:53:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.225.14 with HTTP; Mon, 25 May 2015 10:52:51 -0700 (PDT)
In-Reply-To: <66ECB7D5-19B1-429F-8FE2-464671672310@inria.fr>
References:  <66ECB7D5-19B1-429F-8FE2-464671672310@inria.fr>
From: Eric Rescorla 
Date: Mon, 25 May 2015 10:52:51 -0700
Message-ID: 
To: Karthikeyan Bhargavan 
Content-Type: multipart/alternative; boundary=047d7b8737ae2558670516ebb0f9
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 May 2015 17:53:36 -0000

--047d7b8737ae2558670516ebb0f9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This does seem pretty far-fetched... And note that if we just required a
complete handshake
at this point, that wouldn't create a total failure.

My vote would be that unless someone speaks up relatively soon, we should
require one
of the two options listed in my message (at MUST).

-Ekr


On Mon, May 25, 2015 at 10:45 AM, Karthikeyan Bhargavan <
karthikeyan.bhargavan@inria.fr> wrote:

> Right, there was discussion on this and here=E2=80=99s the current ration=
ale.
>
> If the original handshake used the extended master secret,
> then even if the resumption handshake does not, it is still protected
> by the key derivation in the original handshake.
>
> The only situation when I can see this happening is when the resumption
> handshake goes to different
> endpoints than the original handshake (e.g. in WPA), but maybe someone on
> the list knows better whether the following is a reasonable use case.
>
> The client connects to an access point which forwards the (EAP-TLS)
> connection to the (Radius) server.
> The server speaks TLS + extended master secret and the client and server
> agree upon a master secret.
> The server installs the master secret at the access point, which itself
> does not support extended master secret.
> The client can now communicate directly with the access point,  and also
> resume (EAP fast reauth) connections directly with access points without
> the need to recontact the Radius server
>
> A similar scenario can perhaps be envisioned in cases where a server farm
> of front-ends directs initial connections to a powerful server that
> supports extended master secret, but resumption handshakes (via session
> tickets) can be handled by any (legacy) server.
>
> Far fetched?
> -K.
>
>
> On 25 May 2015, at 19:35, Eric Rescorla  wrote:
>
> >
> >
> >
> >
> > I'm updating the NSS session hash implementation to conform to the new
> spec
> > and I see that it's very clear on what happens when you have a resumpti=
on
> > where the original handshake did not include the extension and the new
> one
> > does (thanks David and Martin)
> >
> >   o  If the original session did not use an extended master secret but
> >       the new ClientHello does contain the "extended_master_secret"
> >       extension, the server MUST NOT perform the abbreviated handshake.
> >       Instead, it SHOULD continue with a full handshake to negotiate a
> >       new session.
> >
> > However, it's less clear on what happens when the original handshake
> included
> > the extension and the new one does not:
> >
> >    o  If the new ClientHello does not contain the
> >       "extended_master_secret" extension, the server SHOULD abort the
> >       handshake.  If it continues with an abbreviated handshake in orde=
r
> >       to interoperate with legacy peers, then the considerations in
> >       Section 5.4 apply.
> >
> > This doesn't seem to distinguish between the two cases (original sessio=
n
> > did and did not use the extension), but they seem different, since the
> > original session not using session hash is a common case (legacy) where=
as
> > an extension->no extension transition is an anomaly. Note that the clie=
nt
> > *is* required to send it, so I think there's a reasonably strong
> > argument that the server should require it.
> >
> > The two main options appear to be:
> >
> >     1. Fall back to a full handshake.
> >     2. Abort the connection
> >
> > The argument for the first appears to be interop. The argument for the
> > second appears to be that it's likely there is an error or a mid-flight
> > reconfiguration on the client (which seems not good). My mild preferenc=
e
> > is for abort but I think it's important in any case that the draft be
> > clear.
> >
> >
> > Similarly, the text about the client side doesn't seem to draw this
> > distinction:
> >
> >       If the new ServerHello does not contain the
> >       "extended_master_secret" extension, the client SHOULD abort the
> >       handshake.  If it continues with an abbreviated handshake in orde=
r
> >       to interoperate with legacy peers, then the considerations in
> >       Section 5.4 apply.
> >
> > Because above the server is required to provide the extension when
> > resuming a session where the extension was negotiated, it seems like
> > we should require the client to fail in that case (that's the sense
> > of the MUST).
> >
> > I see there was some discussion on the list 3/10 but it was inconclusiv=
e.
> >
> > -Ekr
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>

--047d7b8737ae2558670516ebb0f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This does seem pretty far-fetched... And note that if we j=
ust required a complete handshake
at this point, that wouldn't crea=
te a total failure.

My vote would be that unless s=
omeone speaks up relatively soon, we should require one
of the tw=
o options listed in my message (at MUST).

-Ekr


On Mon, May 25, 2015 at 10:45 AM, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr> wrote:
Right, there was discussion on this and here=E2=80=99s the cu=
rrent rationale.



If the original handshake used the extended master secret,

then even if the resumption handshake does not, it is still protected

by the key derivation in the original handshake.



The only situation when I can see this happening is when the resumption han=
dshake goes to different

endpoints than the original handshake (e.g. in WPA), but maybe someone on t=
he list knows better whether the following is a reasonable use case.



The client connects to an access point which forwards the (EAP-TLS) connect=
ion to the (Radius) server.

The server speaks TLS + extended master secret and the client and server ag=
ree upon a master secret.

The server installs the master secret at the access point, which itself doe=
s not support extended master secret.

The client can now communicate directly with the access point,=C2=A0 and al=
so resume (EAP fast reauth) connections directly with access points without=
 the need to recontact the Radius server



A similar scenario can perhaps be envisioned in cases where a server farm o=
f front-ends directs initial connections to a powerful server that supports=
 extended master secret, but resumption handshakes (via session tickets) ca=
n be handled by any (legacy) server.



Far fetched?

-K.






On 25 May 2015, at 19:35, Eric Rescorla <ekr@rtfm.com> wrote:



>

>

>

>

> I'm updating the NSS session hash implementation to conform to the=
 new spec

> and I see that it's very clear on what happens when you have a res=
umption

> where the original handshake did not include the extension and the new=
 one

> does (thanks David and Martin)

>

>=C2=A0 =C2=A0o=C2=A0 If the original session did not use an extended ma=
ster secret but

>=C2=A0 =C2=A0 =C2=A0 =C2=A0the new ClientHello does contain the "e=
xtended_master_secret"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0extension, the server MUST NOT perform the a=
bbreviated handshake.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Instead, it SHOULD continue with a full hand=
shake to negotiate a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0new session.

>

> However, it's less clear on what happens when the original handsha=
ke included

> the extension and the new one does not:

>

>=C2=A0 =C2=A0 o=C2=A0 If the new ClientHello does not contain the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0"extended_master_secret" extension=
, the server SHOULD abort the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0handshake.=C2=A0 If it continues with an abb=
reviated handshake in order

>=C2=A0 =C2=A0 =C2=A0 =C2=A0to interoperate with legacy peers, then the =
considerations in

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.4 apply.

>

> This doesn't seem to distinguish between the two cases (original s=
ession

> did and did not use the extension), but they seem different, since the=


> original session not using session hash is a common case (legacy) wher=
eas

> an extension->no extension transition is an anomaly. Note that the =
client

> *is* required to send it, so I think there's a reasonably strong
> argument that the server should require it.

>

> The two main options appear to be:

>

>=C2=A0 =C2=A0 =C2=A01. Fall back to a full handshake.

>=C2=A0 =C2=A0 =C2=A02. Abort the connection

>

> The argument for the first appears to be interop. The argument for the=


> second appears to be that it's likely there is an error or a mid-f=
light

> reconfiguration on the client (which seems not good). My mild preferen=
ce

> is for abort but I think it's important in any case that the draft=
 be

> clear.

>

>

> Similarly, the text about the client side doesn't seem to draw thi=
s

> distinction:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0If the new ServerHello does not contain the<=
br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"extended_master_secret" extension=
, the client SHOULD abort the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0handshake.=C2=A0 If it continues with an abb=
reviated handshake in order

>=C2=A0 =C2=A0 =C2=A0 =C2=A0to interoperate with legacy peers, then the =
considerations in

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.4 apply.

>

> Because above the server is required to provide the extension when

> resuming a session where the extension was negotiated, it seems like
> we should require the client to fail in that case (that's the sens=
e

> of the MUST).

>

> I see there was some discussion on the list 3/10 but it was inconclusi=
ve.

>

> -Ekr

>


> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls







--047d7b8737ae2558670516ebb0f9--


From nobody Mon May 25 22:03:10 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743D71A1B24 for ; Mon, 25 May 2015 22:03:08 -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 QM4BNEZs-GsY for ; Mon, 25 May 2015 22:03:07 -0700 (PDT)
Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F5E1A1B1C for ; Mon, 25 May 2015 22:03:07 -0700 (PDT)
Received: by yhrr66 with SMTP id r66so27567826yhr.3 for ; Mon, 25 May 2015 22:03:05 -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=CmabUHo9RWQg61UQeLa2hj9bn1jj/p9g6EqaAPCcEWE=; b=CDg2n09S71O8P+LxOzkN/WIcN+EstCChnqX93+DL36uwPoJYXJcUfFAS8GbRETpGDr 42dXJqB7b6g/Xx0F9Fusatw34YG+yDVgttHIa5UHrN9mUFtrAmiDahNnN0PPfoJLcb5B 42wiB9n376nQy2FyNZ+OJ7y0CnNLxXXVLnYTW7t+xJzrBfCeNlbomVAwl46cfTeIwOkm xYOdMfq0nuEVHogjUEJD/00/XmswOBuOb0pOkHmZOcgZhm3dm2dhx0yBjanEOmlwxTKC DK8R8EhCimrhe08j+TEIJ6DNP0DigDKIls1xZA+JGPTm9APEjaWlircrdyZnkziA+Xgn 3c0g==
MIME-Version: 1.0
X-Received: by 10.236.106.74 with SMTP id l50mr22495804yhg.143.1432616585652;  Mon, 25 May 2015 22:03:05 -0700 (PDT)
Received: by 10.129.110.138 with HTTP; Mon, 25 May 2015 22:03:05 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 25 May 2015 22:03:05 -0700
Message-ID: 
From: Martin Thomson 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 05:03:08 -0000

On 25 May 2015 at 10:35, Eric Rescorla  wrote:
> The two main options appear to be:
>
>     1. Fall back to a full handshake.
>     2. Abort the connection
>
> The argument for the first appears to be interop. The argument for the
> second appears to be that it's likely there is an error or a mid-flight
> reconfiguration on the client (which seems not good). My mild preference
> is for abort but I think it's important in any case that the draft be
> clear.


I'd prefer the second two.  That is, unless someone can come up with a
legitimate scenario where the former is needed.


From nobody Mon May 25 23:17:22 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFF21A8912 for ; Mon, 25 May 2015 23:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level: 
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf_wurpSrHiR for ; Mon, 25 May 2015 23:17:19 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5F11A88E1 for ; Mon, 25 May 2015 23:17:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,496,1427752800";  d="asc'?scan'208";a="127769763"
Received: from 14.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.14]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 26 May 2015 08:17:16 +0200
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_28C16D35-3565-4FBA-A3AF-63C3A174AD05"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Karthikeyan Bhargavan 
In-Reply-To: 
Date: Tue, 26 May 2015 08:17:15 +0200
Message-Id: <065E8B97-8EA0-4C6B-84B4-955648C329BE@inria.fr>
References:  
To: Martin Thomson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 06:17:21 -0000

--Apple-Mail=_28C16D35-3565-4FBA-A3AF-63C3A174AD05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

The feedback we=92ve been getting on the draft has been to try and =
preserve interoperability
with legacy clients and servers (even more than the current draft.)
Considering this goal, aborting seems harsh.

Best,
Karthik

On 26 May 2015, at 07:03, Martin Thomson  =
wrote:

> On 25 May 2015 at 10:35, Eric Rescorla  wrote:
>> The two main options appear to be:
>>=20
>>    1. Fall back to a full handshake.
>>    2. Abort the connection
>>=20
>> The argument for the first appears to be interop. The argument for =
the
>> second appears to be that it's likely there is an error or a =
mid-flight
>> reconfiguration on the client (which seems not good). My mild =
preference
>> is for abort but I think it's important in any case that the draft be
>> clear.
>=20
>=20
> I'd prefer the second two.  That is, unless someone can come up with a
> legitimate scenario where the former is needed.
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--Apple-Mail=_28C16D35-3565-4FBA-A3AF-63C3A174AD05
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVZA/sAAoJEB/WSo9veuUKlVQIAK9BuIHnXsdTPhbNu0O4WKLq
hn9KmJJ7JzGrZ5PJCW5UcS89lXIASfhLGzfd0/XVJiK8xyXK4mGZgaK0koIKjU58
vUwH8+vjMieTFVkawYxTkG9T7CoqSQSelxPtkfsOIapSt3cffE1ZKcjE+XANE0Vz
F/QJt4cQeU4hvNJCP2jP4Wy9RoQXeSw4/xGIvcc5cG4FWTX3hGhkbGL0AbBVoT5V
/6QiW/d62EjUmvmwqv6LderUw3YQggyqGFXW6I/j/HXRgAz0pCbd944gqut6COmn
2dKpGUYEUgpgORV07dXGhNRlH4Vo8dcVE4a/lyskZD2R4oobiccAU8viRJ/jkdU=
=pQzZ
-----END PGP SIGNATURE-----

--Apple-Mail=_28C16D35-3565-4FBA-A3AF-63C3A174AD05--


From nobody Tue May 26 00:27:30 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABD81B29CC for ; Tue, 26 May 2015 00:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 UDyAgqA3So8U for ; Tue, 26 May 2015 00:27:27 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2103F1B29CD for ; Tue, 26 May 2015 00:27:26 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id C113210C013; Tue, 26 May 2015 10:27:24 +0300 (EEST)
Date: Tue, 26 May 2015 10:27:24 +0300
From: Ilari Liusvaara 
To: Karthikeyan Bhargavan 
Message-ID: <20150526072724.GA9576@LK-Perkele-VII>
References:   <065E8B97-8EA0-4C6B-84B4-955648C329BE@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <065E8B97-8EA0-4C6B-84B4-955648C329BE@inria.fr>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 07:27:29 -0000

On Tue, May 26, 2015 at 08:17:15AM +0200, Karthikeyan Bhargavan wrote:
> On 26 May 2015, at 07:03, Martin Thomson  wrote:
> 
> > On 25 May 2015 at 10:35, Eric Rescorla  wrote:
> >> The two main options appear to be:
> >> 
> >>    1. Fall back to a full handshake.
> >>    2. Abort the connection
> >> 
> >> The argument for the first appears to be interop. The argument for the
> >> second appears to be that it's likely there is an error or a mid-flight
> >> reconfiguration on the client (which seems not good). My mild preference
> >> is for abort but I think it's important in any case that the draft be
> >> clear.
> > 
> > I'd prefer the second two.  That is, unless someone can come up with a
> > legitimate scenario where the former is needed.
> 
> The feedback we’ve been getting on the draft has been to try and preserve interoperability
> with legacy clients and servers (even more than the current draft.)
> Considering this goal, aborting seems harsh.

Also, there are two dangerous scenarios:
- You have non-session_hash session and resume that.
- You try to use TLS-Exporter in non-session_hase session for authentication.

Based on this, it would seem to be the safest to:
- Not offer any non-session_hash sessions for resumption.
- Deny resumption (full handshake) of any non-session_hash sessions, regardless
  of client session_hash support.
- Disable TLS-Exporter in non-session_hash sessions.


The following are odd edge cases (assuming both ends are due endpoints, these
are safe):
- Resume session_hash-enabled session wihout session_hash extension
- Resume session_hash-enabled session with non-session_hash server.


I was thinking latter of those odd behaviours could occur if one performs
rolling security fix of server farm:
- Client is security fixed
- Server A is security fixed
- Client connects to A
- Client gets session_hash-enabled session.
- Client connects to B, attempting to resume.
- Servers share session DB/key, so resumption succeeds.
- Client gets resumption without session_hash extension.


-Ilari



From nobody Tue May 26 01:05:10 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D5A1B2A34 for ; Tue, 26 May 2015 01:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level: 
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq8DlFgWiB25 for ; Tue, 26 May 2015 01:05:07 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905BD1B2A33 for ; Tue, 26 May 2015 01:05:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,497,1427752800";  d="asc'?scan'208";a="155045492"
Received: from wifi-auth-191208.inria.fr ([128.93.191.208]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 26 May 2015 10:05:05 +0200
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9935C8F3-05CC-4C37-974A-3C4D5C2B886C"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Karthikeyan Bhargavan 
In-Reply-To: <20150526072724.GA9576@LK-Perkele-VII>
Date: Tue, 26 May 2015 10:05:04 +0200
Message-Id: <30048D6E-80C0-4E3C-9336-DDA7C9121ABF@inria.fr>
References:   <065E8B97-8EA0-4C6B-84B4-955648C329BE@inria.fr> <20150526072724.GA9576@LK-Perkele-VII>
To: Ilari Liusvaara 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 08:05:09 -0000

--Apple-Mail=_9935C8F3-05CC-4C37-974A-3C4D5C2B886C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

> Also, there are two dangerous scenarios:
> - You have non-session_hash session and resume that.
> - You try to use TLS-Exporter in non-session_hase session for =
authentication.
>=20
> Based on this, it would seem to be the safest to:
> - Not offer any non-session_hash sessions for resumption.
> - Deny resumption (full handshake) of any non-session_hash sessions, =
regardless
>  of client session_hash support.
> - Disable TLS-Exporter in non-session_hash sessions.


It=92s worth checking, but I believe these cases are covered in the =
spec.
We use SHOULD NOT for these cases; after being advised that MUST NOT is =
too strong for legacy interop.

> The following are odd edge cases (assuming both ends are due =
endpoints, these
> are safe):
> - Resume session_hash-enabled session wihout session_hash extension
> - Resume session_hash-enabled session with non-session_hash server.

Indeed these are the cases that Ekr is objecting to.
In the current draft we say SHOULD NOT for these, and Ekr suggests it =
should be MUST NOT.
Formally, these cases are =93safe=94 in the sense that they are =
protected by the extended master secret on the first handshake.
In practice, they are a bit weird because it looks like the connection =
security degraded between the two handshakes.

The question is whether these could happen in practice, and I would =
welcome more thought son that.
-K.


> I was thinking latter of those odd behaviours could occur if one =
performs
> rolling security fix of server farm:
> - Client is security fixed
> - Server A is security fixed
> - Client connects to A
> - Client gets session_hash-enabled session.
> - Client connects to B, attempting to resume.
> - Servers share session DB/key, so resumption succeeds.
> - Client gets resumption without session_hash extension.
>=20
>=20
> -Ilari
>=20


--Apple-Mail=_9935C8F3-05CC-4C37-974A-3C4D5C2B886C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVZCkwAAoJEB/WSo9veuUKCaoIAJOxNxkoLMzbY/sGakihL/hq
2L23p+lgsKkVY8NCfCkXReudi2y9mD9E5Z4ODitkLanluymw0TsOOE/4C6Tz/lbX
h/QVrwtQK0UcT/VeqMvFbsNPPqPnpqWy+8ZGWvgxocBWfNDVUGksp5/AmkdPWEpF
K/Ju2bQLg/DZ206wCHWBhfTJ2Z2bGvekwyz1sjFT7Jprwl/wp8xNF4SjvFaJ/VKj
wECJXSS15Pme8XPX8mAy06JnsBIdyOOf74hNoSjAjwn9rfJrn+gJ/LOVj9OIRbd5
aeSyFxICpH7uXSoENVoCVEyjDEFLrjerke8DNoCN0+z8097Trdt4lhkljW+DH7w=
=zqRh
-----END PGP SIGNATURE-----

--Apple-Mail=_9935C8F3-05CC-4C37-974A-3C4D5C2B886C--


From nobody Tue May 26 01:42:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3436B1A1ACC for ; Tue, 26 May 2015 01:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 n3cbK2ckncGK for ; Tue, 26 May 2015 01:42:19 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E1A1A1AA9 for ; Tue, 26 May 2015 01:42:19 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 27AD4188830; Tue, 26 May 2015 11:42:17 +0300 (EEST)
Date: Tue, 26 May 2015 11:42:16 +0300
From: Ilari Liusvaara 
To: Karthikeyan Bhargavan 
Message-ID: <20150526084216.GA10009@LK-Perkele-VII>
References:   <065E8B97-8EA0-4C6B-84B4-955648C329BE@inria.fr> <20150526072724.GA9576@LK-Perkele-VII> <30048D6E-80C0-4E3C-9336-DDA7C9121ABF@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <30048D6E-80C0-4E3C-9336-DDA7C9121ABF@inria.fr>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 08:42:22 -0000

On Tue, May 26, 2015 at 10:05:04AM +0200, Karthikeyan Bhargavan wrote:
> > Also, there are two dangerous scenarios:
> > - You have non-session_hash session and resume that.
> > - You try to use TLS-Exporter in non-session_hase session for authentication.
> > 
> > Based on this, it would seem to be the safest to:
> > - Not offer any non-session_hash sessions for resumption.
> > - Deny resumption (full handshake) of any non-session_hash sessions, regardless
> >  of client session_hash support.
> > - Disable TLS-Exporter in non-session_hash sessions.
> 
> 
> It’s worth checking, but I believe these cases are covered in the spec.

The current spec seems to say:
- F->F: SHOULD abort
- F->T: MUST NOT resume (server), SHOULD NOT attempt resume (client)
- T->F: SHOULD abort (this is a weird case)
- T->T: (nothing)

> We use SHOULD NOT for these cases; after being advised that MUST NOT is too strong for legacy interop.

AFAICT, the first two still give interop, just with reduced performance
(full handshakes instead of resumptions).

The third breaks protocols that use TLS-Exporter, including just for keying,
which is seemingly not affected by THS unless one resumes (one can't expect
any security from bad connection).

> > The following are odd edge cases (assuming both ends are due endpoints, these
> > are safe):
> > - Resume session_hash-enabled session wihout session_hash extension
> > - Resume session_hash-enabled session with non-session_hash server.
> 
> Indeed these are the cases that Ekr is objecting to.
> In the current draft we say SHOULD NOT for these, and Ekr suggests it should be MUST NOT.
> Formally, these cases are “safe” in the sense that they are protected by the extended master secret on the first handshake.
> In practice, they are a bit weird because it looks like the connection security degraded between the two handshakes.

AFAICT, if these can actually happen in practice, aborting does create
interop problems.

> The question is whether these could happen in practice, and I would welcome more thought son that.

Could the scenario I gave (quoted below) happen in practice (it causes
resumption of session_hash-enabled session with non-session_hash server)?

> > I was thinking latter of those odd behaviours could occur if one performs
> > rolling security fix of server farm:
> > - Client is security fixed
> > - Server A is security fixed
> > - Client connects to A
> > - Client gets session_hash-enabled session.
> > - Client connects to B, attempting to resume.
> > - Servers share session DB/key, so resumption succeeds.
> > - Client gets resumption without session_hash extension.


-Ilari


From nobody Tue May 26 02:51:07 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C1B1A8855; Tue, 26 May 2015 02:51:04 -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 1xhSFGj6HkRB; Tue, 26 May 2015 02:51:02 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B691A87DF; Tue, 26 May 2015 02:51:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "Benoit Claise" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150526095102.11765.53827.idtracker@ietfa.amsl.com>
Date: Tue, 26 May 2015 02:51:02 -0700
Archived-At: 
Cc: tls@ietf.org, linda.dunbar@huawei.com, draft-ietf-tls-negotiated-ff-dhe.ad@ietf.org, tls-chairs@ietf.org, draft-ietf-tls-negotiated-ff-dhe.shepherd@ietf.org, draft-ietf-tls-negotiated-ff-dhe@ietf.org
Subject: [TLS] Benoit Claise's No Objection on draft-ietf-tls-negotiated-ff-dhe-09: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 09:51:04 -0000

Benoit Claise has entered the following ballot position for
draft-ietf-tls-negotiated-ff-dhe-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Not issue on the technical content and the publication of this document,
but https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/
and the write-up mention "Standard Track" while the draft status is
Informational, as spotted by Linda in her OPS-DIR review below:

This document is on the Informational Track to specify ways for client
and server to establish common finite-field DH parameters with known
structure and a mechanism for
peers to negotiate support for these groups.
The document is well written and very clear.
A couple questions:
1)    Why this document is not standard track?
2)    Several sections requests range in reference of p, e.g.  “p-1” or p
(Section 5). But there are so many numbers that can be “p” (page 17).
What is the significance of the range?



From nobody Tue May 26 04:10:28 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBEA1B2D00 for ; Tue, 26 May 2015 04:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.012
X-Spam-Level: 
X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SolrmZnztkS for ; Tue, 26 May 2015 04:10:25 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3A31B2CE7 for ; Tue, 26 May 2015 04:10:25 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 116D98E4E6; Tue, 26 May 2015 11:10:25 +0000 (UTC)
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4QBANnb031509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2015 07:10:24 -0400
Message-ID: <5564549F.4080609@redhat.com>
Date: Tue, 26 May 2015 13:10:23 +0200
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Dave Garrett , tls@ietf.org
References: <201505211210.43060.davemgarrett@gmail.com>
In-Reply-To: <201505211210.43060.davemgarrett@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: 
Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 11:10:27 -0000

On 05/21/2015 06:10 PM, Dave Garrett wrote:

> 2) For TLS 1.3, add a blurb to the effect of:
> "Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiate TLS 1.0 or TLS 1.1 for any reason.
> Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible."

How is this different from TLS 1.1 and 1.2?  Both RFCs obsoleted its
successor, so from an IETF perspective, there is just a single version
right now, TLS 1.2, and everything else is non-conforming.

-- 
Florian Weimer / Red Hat Product Security


From nobody Tue May 26 09:36:08 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60CE1B2FB9; Tue, 26 May 2015 09:36:04 -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 3oFZHfWu7QSH; Tue, 26 May 2015 09:36:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 119B31B2F9E; Tue, 26 May 2015 09:35:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Barry Leiba" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150526163531.16574.67543.idtracker@ietfa.amsl.com>
Date: Tue, 26 May 2015 09:35:31 -0700
Archived-At: 
Cc: tls@ietf.org, draft-ietf-tls-negotiated-ff-dhe.ad@ietf.org, tls-chairs@ietf.org, draft-ietf-tls-negotiated-ff-dhe.shepherd@ietf.org, draft-ietf-tls-negotiated-ff-dhe@ietf.org
Subject: [TLS] Barry Leiba's No Objection on draft-ietf-tls-negotiated-ff-dhe-09: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 16:36:05 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-tls-negotiated-ff-dhe-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The intended status in the document text does, indeed, need to be changed
to "Standards Track".  The last call was issued as "Proposed Standard",
and the IESG ballot is set up for that, so I think we're OK -- please
just fix the text in the next document rev.



From nobody Tue May 26 09:56:08 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31BC1B2C7A for ; Tue, 26 May 2015 09:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 jbhBcqB2sset for ; Tue, 26 May 2015 09:56:05 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5791AC3C1 for ; Tue, 26 May 2015 09:56:05 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id DDF363FE3; Tue, 26 May 2015 19:56:02 +0300 (EEST)
Date: Tue, 26 May 2015 19:56:02 +0300
From: Ilari Liusvaara 
To: David Benjamin 
Message-ID: <20150526165602.GA5805@LK-Perkele-VII>
References:   <065E8B97-8EA0-4C6B-84B4-955648C329BE@inria.fr> <20150526072724.GA9576@LK-Perkele-VII> <30048D6E-80C0-4E3C-9336-DDA7C9121ABF@inria.fr> <20150526084216.GA10009@LK-Perkele-VII> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 16:56:08 -0000

On Tue, May 26, 2015 at 04:41:37PM +0000, David Benjamin wrote:
> On Tue, May 26, 2015 at 4:42 AM Ilari Liusvaara 
> wrote:
> 
> > Could the scenario I gave (quoted below) happen in practice (it causes
> > resumption of session_hash-enabled session with non-session_hash server)?
> >
> > > > I was thinking latter of those odd behaviours could occur if one
> > performs
> > > > rolling security fix of server farm:
> > > > - Client is security fixed
> > > > - Server A is security fixed
> > > > - Client connects to A
> > > > - Client gets session_hash-enabled session.
> > > > - Client connects to B, attempting to resume.
> > > > - Servers share session DB/key, so resumption succeeds.
> > > > - Client gets resumption without session_hash extension.
> >
> 
> This could certainly happen with a server farm, yeah. Hopefully such a
> situation would be rather transient, and it can be mitigated by sharding
> the session cache between EMS-less and EMS-ful halves of the rollout. But
> relying on it always happening seems unrealistic, so honoring the SHOULD is
> a little risky.

IIRC, this hits MUST. That is, the client is REQUIRED to abort in this
case.
 
> I would think tls-unique and friends are still fine in this case? Though if
> we're worried about it (maybe we introduce some new extension later and
> would rather it be incorporated into the key derivation?), we could just
> say that the client should still disable tls-unique and whatnot. I.e.
> IsTLSUniqueSecure() requires that BOTH the connection and the original
> session, if any, are EMS-ful. That seems appropriately conservative and
> without risk of (transient) interop failures. Client with require interop
> need to account for that returning false anyway.

AFAIK:

If you don't resume, TLS-Unique is fine. TLS-Extractor is not.

If the original connection had EMS, then both TLS-Unique and TLS-Extractor
are fine, regardless of if resumptions do.


-Ilari


From nobody Wed May 27 02:10:11 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BE31A90AD for ; Wed, 27 May 2015 02:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 1ldWQAgKuZbX for ; Wed, 27 May 2015 02:10:07 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80191A90AE for ; Wed, 27 May 2015 02:10:07 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 4D6CC1A267F; Wed, 27 May 2015 12:10:05 +0300 (EEST)
Date: Wed, 27 May 2015 12:10:05 +0300
From: Ilari Liusvaara 
To: Sean Turner 
Message-ID: <20150527091005.GA3569@LK-Perkele-VII>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: 
Cc: IETF TLS Working Group 
Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2015 09:10:10 -0000

On Tue, May 19, 2015 at 05:31:59PM -0400, Sean Turner wrote:
> All,
> 
> This message serves two purposes:
> 
> 1) It is the WG call for adoption of:
> 
> http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-chacha-tls/
> 
> This draft specifies the use of the ChaCha stream cipher with Poly1305
> in the TLS and DTLS protocols.  The WG needs this draft to specify code
> points in support of the recent MTI consensus call (see 
> http://www.ietf.org/mail-archive/web/tls/current/msg16343.html).
> If you object to the adoption of this draft as a WG item, please respond
> to the list indicating why by 20150602.

Adopt.

> 2) It is a request for an early code point assignment:
> 
> We have a request for an early code point assignment for the cipher
> suites listed in the draft.  If you have a concern with an early code
> point assignment for the ciphers listed in this draft, please respond
> to the list indicating why by 20150602.  

I agree that the list of codepoints is bit broad for initial assignment.
Thomson's list (DHE_RSA, ECDHE_RSA, ECDHE_ECDSA, PSK, ECDHE_PSK) looks
reasonable. No concerns on early assignment on those.

Reading the Editor's Copy, the spec looks deployable. No concerns there.

Regarding nonce generation method, I did some programming experiments
with that, and I have no cocerns there.


-Ilari


From nobody Wed May 27 05:31:44 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B711A92BB for ; Tue, 26 May 2015 09:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv-6lWD7VqdJ for ; Tue, 26 May 2015 09:41:38 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA6D1A92B4 for ; Tue, 26 May 2015 09:41:38 -0700 (PDT)
Received: by igbsb11 with SMTP id sb11so57940224igb.0 for ; Tue, 26 May 2015 09:41:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Joz2zb25K66Xp1onqAaNrNeYQS5fpERCo4PqsEe89Cw=; b=DcPfok8+p3p27kXfgLbiDL5TipoJ3s5eNW4dVc8tdVTdMS6oUtdYW8E9bxumeupdRM uVW/fWf5XfqLw+fghkZyIHayUGhkN+BNMbbTPeucxpqf6jKAXz3ZSJpH+boD5wXPLC6L 9u055jtZWfM5zcP0zDgmuaHjV50tLgt4SedevPoE5qEvd5Mi2vTJ0GhDen0TYho0Vv1E J5kqTfJabT67APBUwlCpE3xivLxAmuO8u5BELAEGl4hrdi0tyxuVhxqXt8I40RiDyahA oaHwfuQ/Khdj86pzCxreNmOXCG+2pDKnNp5/dokdEMqfpJLheyiCUBzjIqkK1r1YjiwO UoWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=Joz2zb25K66Xp1onqAaNrNeYQS5fpERCo4PqsEe89Cw=; b=f4T2I151BMjtoMrj+XK8wfCJECj7nr9lFvH7DRk10JTHz7om66Rjl5mW7gSG1oPABX ogNqA3t0R2fRsNBIJooAzn4X8OWyYCU7l/6IRe1gtTf3b+8xpK1FAVgiriGqlcNHRTW+ Uinb1f8FrfdBmjJdYAj4zzm5oaKFKaWkTht8wdovGZj+ks3xbbPeqXaf8df/Tlr9Jz0x bQj54PATYUWpPxzN3SpV4xcw/NsjorzkgRU5L9O312UGxeD6sGAtpj64V6ZjUFBB1pcY X2oCTPuLt1+DH4bgOPfKAhfJbrz/V6Rg6Q6HmvOdmazmsFdspDaupGVMei2CVuwuylcC 44hQ==
X-Gm-Message-State: ALoCoQm1ddm+DVY5/mN4mLDPCNpP5akFOKghSYZE+LLL/MxSIAobITHCWcvL5QsYJmMgLjXj2wwn
X-Received: by 10.43.59.80 with SMTP id wn16mr30518150icb.40.1432658498127; Tue, 26 May 2015 09:41:38 -0700 (PDT)
MIME-Version: 1.0
References:   <065E8B97-8EA0-4C6B-84B4-955648C329BE@inria.fr> <20150526072724.GA9576@LK-Perkele-VII> <30048D6E-80C0-4E3C-9336-DDA7C9121ABF@inria.fr> <20150526084216.GA10009@LK-Perkele-VII>
In-Reply-To: <20150526084216.GA10009@LK-Perkele-VII>
From: David Benjamin 
Date: Tue, 26 May 2015 16:41:37 +0000
Message-ID: 
To: Ilari Liusvaara ,  Karthikeyan Bhargavan 
Content-Type: multipart/alternative; boundary=bcaec51dd23bddb02d0516feccd3
Archived-At: 
X-Mailman-Approved-At: Wed, 27 May 2015 05:31:43 -0700
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 16:41:40 -0000

--bcaec51dd23bddb02d0516feccd3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 26, 2015 at 4:42 AM Ilari Liusvaara 
wrote:

> > > The following are odd edge cases (assuming both ends are due
> endpoints, these
> > > are safe):
> > > - Resume session_hash-enabled session wihout session_hash extension
> > > - Resume session_hash-enabled session with non-session_hash server.
> >
> > Indeed these are the cases that Ekr is objecting to.
> > In the current draft we say SHOULD NOT for these, and Ekr suggests it
> should be MUST NOT.
> > Formally, these cases are =E2=80=9Csafe=E2=80=9D in the sense that they=
 are protected by
> the extended master secret on the first handshake.
> > In practice, they are a bit weird because it looks like the connection
> security degraded between the two handshakes.
>
> AFAICT, if these can actually happen in practice, aborting does create
> interop problems.
>
> > The question is whether these could happen in practice, and I would
> welcome more thought son that.
>
> Could the scenario I gave (quoted below) happen in practice (it causes
> resumption of session_hash-enabled session with non-session_hash server)?
>
> > > I was thinking latter of those odd behaviours could occur if one
> performs
> > > rolling security fix of server farm:
> > > - Client is security fixed
> > > - Server A is security fixed
> > > - Client connects to A
> > > - Client gets session_hash-enabled session.
> > > - Client connects to B, attempting to resume.
> > > - Servers share session DB/key, so resumption succeeds.
> > > - Client gets resumption without session_hash extension.
>

This could certainly happen with a server farm, yeah. Hopefully such a
situation would be rather transient, and it can be mitigated by sharding
the session cache between EMS-less and EMS-ful halves of the rollout. But
relying on it always happening seems unrealistic, so honoring the SHOULD is
a little risky.

I would think tls-unique and friends are still fine in this case? Though if
we're worried about it (maybe we introduce some new extension later and
would rather it be incorporated into the key derivation?), we could just
say that the client should still disable tls-unique and whatnot. I.e.
IsTLSUniqueSecure() requires that BOTH the connection and the original
session, if any, are EMS-ful. That seems appropriately conservative and
without risk of (transient) interop failures. Client with require interop
need to account for that returning false anyway.

For the converse case (client offers an EMS-ful session on an EMS-less
connection, draft says server SHOULD abort), I can't think of a deployment
where this could happen in practice. The analogous "server farm" case seems
less likely for a client, so aborting seems fine. Still, I don't see a need
for the abort, so I would marginally prefer either "fall back to a full
handshake" (unlike the client, the server has this option) or "just behave
as you otherwise would and inherit whatever EMS-ful =3D> EMS-less tls-uniqu=
e
considerations we adopt above".

It's slightly confusing that the text tries to specify everything with a
single menu of SHOULDs to pick and choose. It's seems there's only two
profiles to worry about: "EMS required" and "EMS optional due to interop
needs". In fact, the two SHOULDs we're talking about don't even explicitly
talk about the EMS-ful session =3D> EMS-less resumption case. They just say
to abort period, which is mostly for the "EMS required" profile.

David

--bcaec51dd23bddb02d0516feccd3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Tue, May 26, 2015 at 4:42 AM=
 Ilari Liusvaara <ilari.l=
iusvaara@elisanet.fi> wrote:
> =
> The following are odd edge cases (assuming both ends are due endpoints=
, these

> > are safe):

> > - Resume session_hash-enabled session wihout session_hash extensi=
on

> > - Resume session_hash-enabled session with non-session_hash serve=
r.

>

> Indeed these are the cases that Ekr is objecting to.

> In the current draft we say SHOULD NOT for these, and Ekr suggests it =
should be MUST NOT.

> Formally, these cases are =E2=80=9Csafe=E2=80=9D in the sense that the=
y are protected by the extended master secret on the first handshake.

> In practice, they are a bit weird because it looks like the connection=
 security degraded between the two handshakes.



AFAICT, if these can actually happen in practice, aborting does create

interop problems.



> The question is whether these could happen in practice, and I would we=
lcome more thought son that.



Could the scenario I gave (quoted below) happen in practice (it causes

resumption of session_hash-enabled session with non-session_hash server)?


> > I was thinking latter of those odd behaviours could occur if one =
performs

> > rolling security fix of server farm:

> > - Client is security fixed

> > - Server A is security fixed

> > - Client connects to A

> > - Client gets session_hash-enabled session.

> > - Client connects to B, attempting to resume.

> > - Servers share session DB/key, so resumption succeeds.

> > - Client gets resumption without session_hash extension.

This could certainly happen with a server farm, yeah. Hope=
fully such a situation would be rather transient, and it can be mitigated b=
y sharding the session cache between EMS-less and EMS-ful halves of the rol=
lout. But relying on it always happening seems unrealistic, so honoring the=
 SHOULD is a little risky.

I would think tls-unique and friends are =
still fine in this case? Though if we're worried about it (maybe we int=
roduce some new extension later and would rather it be incorporated into th=
e key derivation?), we could just say that the client should still disable =
tls-unique and whatnot. I.e. IsTLSUniqueSecure() requires that BOTH the con=
nection and the original session, if any, are EMS-ful. That seems appropria=
tely conservative and without risk of (transient) interop failures. Client =
with require interop need to account for that returning false anyway.
For the converse case (client offers an EMS-ful session on an EMS-less co=
nnection, draft says server SHOULD abort), I can't think of a deploymen=
t where this could happen in practice. The analogous "server farm"=
; case seems less likely for a client, so aborting seems fine. Still, I don=
't see a need for the abort, so I would marginally prefer either "=
fall back to a full handshake" (unlike the client, the server has this=
 option) or "just behave as you otherwise would and inherit whatever E=
MS-ful =3D> EMS-less tls-unique considerations we adopt above".
=

It's slightly confusing that the text tries to specify everything w=
ith a single menu of SHOULDs to pick and choose. It's seems there's=
 only two profiles to worry about: "EMS required" and "EMS o=
ptional due to interop needs". In fact, the two SHOULDs we're talk=
ing about don't even explicitly talk about the EMS-ful session =3D> =
EMS-less resumption case. They just say to abort period, which is mostly fo=
r the "EMS required" profile.

David


--bcaec51dd23bddb02d0516feccd3--


From nobody Wed May 27 05:31:57 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069201ACD8E for ; Tue, 26 May 2015 10:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W5MfW3mxIP5 for ; Tue, 26 May 2015 10:31:38 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 F19AF1ACD74 for ; Tue, 26 May 2015 10:31:34 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so64132418igb.1 for ; Tue, 26 May 2015 10:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=OGuan3fZXxCEycfH1wFzzMdzfCZNAhV22XXga9nSqmA=; b=jgU31vT06aKk2fkQi+WcylXJNPdpP9RS+YUPyITqXMwcRrtCFQgTm2I8mw4Hl7o7qV nETj+eZLXEHGfEEgQC3wO0fDZ7FcREUl09XhT8dD8ZVCJHkNK820fdyg4SgJ6abj3xFs rD50N93RRmzn4hL2qGGiv6duSyYZPy4znUbDb08b6JIHkpQUj50xoIyni+34Sjs0dkND w/ii1LG4OUc5RMD5sanhCp75k5/vwwIicBsIkyblJsm/KfySW4bmECYUtNe/qSp+zQDr gDu0Mazh8nuDBgtsFy47v2Du0FkCA1BIpA4Be+xJE71090s9PMnwrDn0A+0/XT8BccP3 Lrjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=OGuan3fZXxCEycfH1wFzzMdzfCZNAhV22XXga9nSqmA=; b=JxLLOowHX5Icu8puS3P3tGyfP0A+qUkcDixD7Mi/EOWXcHEZz58T3TwcujgH9Lbtk1 /tRGmumC1FSgBXPjROq0aWnQrmP352azQJzKm1ethPpxYa6zIFBXzL+lljpA8Dg++JS9 aXqMMvKRDFpcXXssLFI40m6emJ767Zo6Yp2H+KDGwtdhuQThIv9fMYjoH0pzw0Rww2FN lu7RkCA0By8gWE/eSGNq0NO3+TLSF/RXGTlNHeuOxtRs1MM4WPjQT50WB+4JrU16tpKD qngdf1WTytL5bRE4YpGTrtz85zy1kNcJVizSS5HEcSZPtMLMsIwAw5OuJuA4X0PFDd90 sfHw==
X-Gm-Message-State: ALoCoQmkICZAQ654Zc2/diL7gheXzIa0oTIBomyWu/s27Wt/mLeZpKe3veSAdQ36jmIFGg7y+K1e
X-Received: by 10.107.136.197 with SMTP id s66mr37275769ioi.65.1432661493287;  Tue, 26 May 2015 10:31:33 -0700 (PDT)
MIME-Version: 1.0
References:   <065E8B97-8EA0-4C6B-84B4-955648C329BE@inria.fr> <20150526072724.GA9576@LK-Perkele-VII> <30048D6E-80C0-4E3C-9336-DDA7C9121ABF@inria.fr> <20150526084216.GA10009@LK-Perkele-VII>  <20150526165602.GA5805@LK-Perkele-VII>
In-Reply-To: <20150526165602.GA5805@LK-Perkele-VII>
From: David Benjamin 
Date: Tue, 26 May 2015 17:31:32 +0000
Message-ID: 
To: Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=001a113ec878643b850516ff7ff8
Archived-At: 
X-Mailman-Approved-At: Wed, 27 May 2015 05:31:49 -0700
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 May 2015 17:31:40 -0000

--001a113ec878643b850516ff7ff8
Content-Type: text/plain; charset=UTF-8

On Tue, May 26, 2015 at 12:56 PM Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Tue, May 26, 2015 at 04:41:37PM +0000, David Benjamin wrote:
> > On Tue, May 26, 2015 at 4:42 AM Ilari Liusvaara <
> ilari.liusvaara@elisanet.fi>
> > wrote:
> >
> > > Could the scenario I gave (quoted below) happen in practice (it causes
> > > resumption of session_hash-enabled session with non-session_hash
> server)?
> > >
> > > > > I was thinking latter of those odd behaviours could occur if one
> > > performs
> > > > > rolling security fix of server farm:
> > > > > - Client is security fixed
> > > > > - Server A is security fixed
> > > > > - Client connects to A
> > > > > - Client gets session_hash-enabled session.
> > > > > - Client connects to B, attempting to resume.
> > > > > - Servers share session DB/key, so resumption succeeds.
> > > > > - Client gets resumption without session_hash extension.
> > >
> >
> > This could certainly happen with a server farm, yeah. Hopefully such a
> > situation would be rather transient, and it can be mitigated by sharding
> > the session cache between EMS-less and EMS-ful halves of the rollout. But
> > relying on it always happening seems unrealistic, so honoring the SHOULD
> is
> > a little risky.
>
> IIRC, this hits MUST. That is, the client is REQUIRED to abort in this
> case.
>

I don't think it does. The text is:

   o  If the original session did not use an extended master secret but
      the new ServerHello does contain the "extended_master_secret"
      extension, the client MUST abort the handshake.

   o  If the new ServerHello does not contain the
      "extended_master_secret" extension, the client SHOULD abort the
      handshake.  If it continues with an abbreviated handshake in order
      to interoperate with legacy peers, then the considerations in
      Section 5.4 apply.

The latter applies if an EMS-less server resumes an EMS-full session. This
is what you described. The former applies if an EMS-full server resumes an
EMS-less session. That one shouldn't cause interop problems assuming all
EMS-full servers honor this MUST:

   o  If the original session did not use an extended master secret but
      the new ClientHello does contain the "extended_master_secret"
      extension, the server MUST NOT perform the abbreviated handshake.
      Instead, it SHOULD continue with a full handshake to negotiate a
      new session.

Whereas an EMS-less server may be able to parse a serialized EMS-full
session and attempt to resume it. (In the case of OpenSSL, even if the
structure version gets bumped, d2i_SSL_SESSION kindly ignores the version
field because why not[*]? Though I suppose the structure's syntax could
just get changed incompatibly to break the parse.)

David

[*] I believe the rewrite of that code in the master branch will actually
check it, but 1.0.2 and before don't.

--001a113ec878643b850516ff7ff8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Tue, May 26, 2015 at 12:56 P=
M Ilari Liusvaara <ilari.=
liusvaara@elisanet.fi> wrote:
On T=
ue, May 26, 2015 at 04:41:37PM +0000, David Benjamin wrote:

> On Tue, May 26, 2015 at 4:42 AM Ilari Liusvaara <ilari.liusvaara@elisanet.fi<=
/a>>

> wrote:

>

> > Could the scenario I gave (quoted below) happen in practice (it c=
auses

> > resumption of session_hash-enabled session with non-session_hash =
server)?

> >

> > > > I was thinking latter of those odd behaviours could occ=
ur if one

> > performs

> > > > rolling security fix of server farm:

> > > > - Client is security fixed

> > > > - Server A is security fixed

> > > > - Client connects to A

> > > > - Client gets session_hash-enabled session.

> > > > - Client connects to B, attempting to resume.

> > > > - Servers share session DB/key, so resumption succeeds.=


> > > > - Client gets resumption without session_hash extension=
.

> >

>

> This could certainly happen with a server farm, yeah. Hopefully such a=


> situation would be rather transient, and it can be mitigated by shardi=
ng

> the session cache between EMS-less and EMS-ful halves of the rollout. =
But

> relying on it always happening seems unrealistic, so honoring the SHOU=
LD is

> a little risky.



IIRC, this hits MUST. That is, the client is REQUIRED to abort in this

case.

I don't think it does. The text is:
<=
br>
=C2=A0 =C2=A0o =C2=A0If the original session did not use an extende=
d master secret but
=C2=A0 =C2=A0 =C2=A0 the new ServerHello does=
 contain the "extended_master_secret"
=C2=A0 =C2=A0 =C2=
=A0 extension, the client MUST abort the handshake.

=C2=A0 =C2=
=A0o =C2=A0If the new ServerHello does not contain the
=C2=A0 =C2=
=A0 =C2=A0 "extended_master_secret" extension, the client SHOULD =
abort the
=C2=A0 =C2=A0 =C2=A0 handshake.=C2=A0 If it continues w=
ith an abbreviated handshake in order
=C2=A0 =C2=A0 =C2=A0 to int=
eroperate with legacy peers, then the considerations in
=C2=A0 =
=C2=A0 =C2=A0 Section 5.4 apply.

The latter applies if an EMS-less=
 server resumes an EMS-full session. This is what you described. The former=
 applies if an EMS-full server resumes an EMS-less session. That one should=
n't cause interop problems assuming all EMS-full servers honor this MUS=
T:

=C2=A0 =C2=A0o =C2=A0If the original session did not use an =
extended master secret but
=C2=A0 =C2=A0 =C2=A0 the new ClientHel=
lo does contain the "extended_master_secret"
=C2=A0 =C2=
=A0 =C2=A0 extension, the server MUST NOT perform the abbreviated handshake=
.
=C2=A0 =C2=A0 =C2=A0 Instead, it SHOULD continue with a full ha=
ndshake to negotiate a
=C2=A0 =C2=A0 =C2=A0 new session.

W=
hereas an EMS-less server may be able to parse a serialized EMS-full sessio=
n and attempt to resume it. (In the case of OpenSSL, even if the structure =
version gets bumped, d2i_SSL_SESSION kindly ignores the version field becau=
se why not[*]? Though I suppose the structure's syntax could just get c=
hanged incompatibly to break the parse.)

David

[*] I believe the rewrite of that code in the master branch=
 will actually check it, but 1.0.2 and before don't.


--001a113ec878643b850516ff7ff8--


From nobody Wed May 27 10:23:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25931A883C for ; Wed, 27 May 2015 10:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Level: 
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 iCgyw5zXM67T for ; Wed, 27 May 2015 10:23:35 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E819C1A883B for ; Wed, 27 May 2015 10:23:34 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 49B4F6B0082; Wed, 27 May 2015 10:23:34 -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=B3+h3ACLBMCcIb u8pyFmK3xF5vc=; b=wv26bJkV3bMBqhzpx24ir7JEWpa7CqUc4nUwZZ0m1Aao8A cyR//E96FNkz6iKVdh1wgBlDIZJeK6oEzc5NxlYfezUdR1tPrbVCFhbTqWPWQ4C5 GJs1dPPFGNYiYnpbMua3J9cfk/jHSZ3ut470YD1BofUpeD2baOZv0CFaiu6og=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id AC6956B0070; Wed, 27 May 2015 10:23:32 -0700 (PDT)
Date: Wed, 27 May 2015 12:23:30 -0500
From: Nico Williams 
To: Eric Rescorla 
Message-ID: <20150527172329.GI27628@localhost>
References: 
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: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2015 17:23:35 -0000

On Mon, May 25, 2015 at 10:35:30AM -0700, Eric Rescorla wrote:
> This doesn't seem to distinguish between the two cases (original session
> did and did not use the extension), but they seem different, since the
> original session not using session hash is a common case (legacy) whereas
> an extension->no extension transition is an anomaly. Note that the client
> *is* required to send it, so I think there's a reasonably strong
> argument that the server should require it.
> 
> The two main options appear to be:
> 
>     1. Fall back to a full handshake.
>     2. Abort the connection
> 
> The argument for the first appears to be interop. The argument for the
> second appears to be that it's likely there is an error or a mid-flight
> reconfiguration on the client (which seems not good). My mild preference
> is for abort but I think it's important in any case that the draft be
> clear.

Is a mid-flight reconfiguration of the client while reusing an old
session cache likely?

Anyways, my preference would be to fallback, since I don't see the harm.
Correct me if I'm wrong.

Nico
-- 


From nobody Wed May 27 10:43:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851F91A8847 for ; Wed, 27 May 2015 10:43:18 -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 dX_1c2_iT8fO for ; Wed, 27 May 2015 10:43:17 -0700 (PDT)
Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 67E911A883B for ; Wed, 27 May 2015 10:43:17 -0700 (PDT)
Received: by ykfl8 with SMTP id l8so5053926ykf.1 for ; Wed, 27 May 2015 10:43: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 :cc:content-type; bh=MAzLUDigdwtdPYMzQkdO94ZONqmDvK5/yE1of/lkYGY=; b=SOe2fFLKu8RErT9AhVYKDvCaBlbB4W3R4uQYDyK2Gg90+KMfpwoCKvnYWX5QEFiX7P 8VI7ifFqmBQYwhAZ88GBQKaAwxs0lW6fp8DFv7py8CYSfposE2fbrPCvdO0lyDhGXLhC 9PQqS2PDYPiJfg6pECeh5ZlSpAecNoLet9GxWfluyPTBIwoCU2hYxOd9Ketv7iybpcZr yCLE3bemLSpwIZdUSoD3xTFvywaGgTIQO+rJ16fX6QCfrZknvrFNWzhi9OJxhZAfWNem JvevcC35DVGJeVKwEI54h8yEunxA0+f9n6mpQdx8gz1YXnWO9ypXUiQawiZvgxne22Q/ Gpog==
MIME-Version: 1.0
X-Received: by 10.236.28.75 with SMTP id f51mr9273395yha.93.1432748596845; Wed, 27 May 2015 10:43:16 -0700 (PDT)
Received: by 10.129.110.138 with HTTP; Wed, 27 May 2015 10:43:16 -0700 (PDT)
In-Reply-To: <20150527172329.GI27628@localhost>
References:  <20150527172329.GI27628@localhost>
Date: Wed, 27 May 2015 10:43:16 -0700
Message-ID: 
From: Martin Thomson 
To: Nico Williams 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 May 2015 17:43:18 -0000

On 27 May 2015 at 10:23, Nico Williams  wrote:
> Is a mid-flight reconfiguration of the client while reusing an old
> session cache likely?

Some clients persist session caches to disk.  That means completely
new software could load old sessions.


From nobody Thu May 28 16:24:32 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ADB1A8BAF for ; Thu, 28 May 2015 16:24:31 -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 XT2nETcWfcAl for ; Thu, 28 May 2015 16:24:29 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 6C02A1A893A for ; Thu, 28 May 2015 16:24:29 -0700 (PDT)
Received: by wifw1 with SMTP id w1so2590367wif.0 for ; Thu, 28 May 2015 16:24:28 -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:from:date :message-id:subject:to:cc:content-type; bh=POB3sqtds/WboNyR6IJJoxwWvfnc62FBa72a3dKBwqU=; b=ggFsalxJ/tyJYySR//t4DvCYZPJUE4tkeXArAliDWuRB0SlLzWZ/KQWTqW7L/YccU1 psrEMBA6IXLTNS22tYrC5YBIkoQ5BkiXUwgQrxcDKtwXc4HUVGLBAiy3ccHAruOeXyXc IrshC4NDfJMan4F4lTzp7Lw2pVpoZ7cjFXWhIwNb/beMBoN9zMoo0Lw07WhCpZWGgrs7 /JnfEC/QVZ4OlNTmNyOEN23VPmjORhpqB+uupqmQQO4xPnX/u0nZapPz6GhE/R59d0CZ xfwX62yVaraOALczKn8mjy/hFBSUjRwwqFqdaaEa9kcJ4G9h6/q7T/aHV7NvijgqsOT2 5BYA==
X-Gm-Message-State: ALoCoQm11lKT4fVEWJLf8Fp17Bo9gaZbpBP8IVJZqoySwb9SRs/djO1sSh1euuGkROLuGvIuQ8n8
X-Received: by 10.180.73.176 with SMTP id m16mr728696wiv.68.1432855468193; Thu, 28 May 2015 16:24:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.225.14 with HTTP; Thu, 28 May 2015 16:23:47 -0700 (PDT)
In-Reply-To: 
References:  <20150527172329.GI27628@localhost> 
From: Eric Rescorla 
Date: Thu, 28 May 2015 16:23:47 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=f46d043c7e58324ae805172ca9fa
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 May 2015 23:24:31 -0000

--f46d043c7e58324ae805172ca9fa
Content-Type: text/plain; charset=UTF-8

I'd like to close the loop on this, since I think it would be better if
implementations
behaved identically.

It seems to me that there are two cases here:

- Interoperating with non-EMS-enabled devices, in which case we want to
  encourage refusal to resume, but we know we can't require it (hence
  SHOULD.

- Mid-flight reconfigurations/changes, etc. in which case we should be able
  to come down on one definite interpretation.

Since this second case should rarely happen, but people seem sad about
abort, I would suggest that we say MUST NOT resume and SHOULD
do a new full handshake.

-Ekr








On Wed, May 27, 2015 at 10:43 AM, Martin Thomson 
wrote:

> On 27 May 2015 at 10:23, Nico Williams  wrote:
> > Is a mid-flight reconfiguration of the client while reusing an old
> > session cache likely?
>
> Some clients persist session caches to disk.  That means completely
> new software could load old sessions.
>

--f46d043c7e58324ae805172ca9fa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'd like to close the loop on this, since I think it w=
ould be better if implementations
behaved identically.

It seems to me that there are two cases here:

=

- Interoperating with non-EMS-enabled devices, in which case we want t=
o
=C2=A0 encourage refusal to resume, but we know we can't re=
quire it (hence
=C2=A0 SHOULD.

- Mid-fli=
ght reconfigurations/changes, etc. in which case we should be able
=C2=A0 to come down on one definite interpretation.

<=
div>Since this second case should rarely happen, but people seem sad about<=
/div>
abort, I would suggest that we say MUST NOT resume and SHOULD
do a new full handshake.

-Ekr







On Wed, May 27, 2015 at 10:43 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 27 May 2015 at 10:23, Nico Williams <nico@cryptonector.com> wrote:
> Is a mid-flight reconfiguration of the client while reusing an old

> session cache likely?



Some clients persist session caches to disk.=C2=A0 That means comple=
tely

new software could load old sessions.





--f46d043c7e58324ae805172ca9fa--


From nobody Fri May 29 04:41:46 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D811A0218 for ; Fri, 29 May 2015 04:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level: 
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 jOokuRfeH1mT for ; Fri, 29 May 2015 04:41:43 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFAA1A0222 for ; Fri, 29 May 2015 04:41:43 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 97453180204; Fri, 29 May 2015 04:39:32 -0700 (PDT)
To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, joe@salowey.net
X-PHP-Originating-Script: 6000:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20150529113932.97453180204@rfc-editor.org>
Date: Fri, 29 May 2015 04:39:32 -0700 (PDT)
Archived-At: 
Cc: lscorco@nsa.gov, tls@ietf.org, rfc-editor@rfc-editor.org
Subject: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 11:41:45 -0000

The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4382

--------------------------------------
Type: Technical
Reported by: Laura Corcoran 

Section: 4.3

Original Text
-------------
In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

      opaque Datum[3];      /* three uninterpreted bytes */
      Datum Data[9];        /* 3 consecutive 3 byte vectors */


Corrected Text
--------------
In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

      opaque Datum[3];      /* three uninterpreted bytes */
      Datum Data[3];        /* 3 consecutive 3 byte vectors */


Notes
-----
The 9 in "Datum Data[9]" should be a 3 because Datum is a data type that consumes 3 bytes, so as written the Data vector is 27 bytes long. To make it a 9 byte vector the 9 must change to a 3.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--------------------------------------
Title               : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date    : August 2008
Author(s)           : T. Dierks, E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Fri May 29 05:39:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4431A8850 for ; Fri, 29 May 2015 05:39:35 -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 oX2jSlIwnLHK for ; Fri, 29 May 2015 05:39:33 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.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 B19991A884E for ; Fri, 29 May 2015 05:39:32 -0700 (PDT)
Received: by wizo1 with SMTP id o1so22088560wiz.1 for ; Fri, 29 May 2015 05:39:31 -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:from:date :message-id:subject:to:cc:content-type; bh=+fjy51MjL+TtBo0gMg63lBvFI1GgNqiyfG8G7Ce/dDg=; b=XkPHkdxGMpQyZzWM4QRpbjFZH1cyzFPPJmC20nNOjneTyH/ba09UStFmAxMf97e/dp M7d8QEdyNQl+/pX30/mOKStjMlnzM/ajVY/+uSlBJIAtuo9Jl781HKrfeCfkCy+yOejd 6EZXFm1YSM4l2fU8wTa5xJKdmRmJ5W+dkx1cOMXszhNWM+VLmQt2rdzKxtYns/W9omO/ Em1AomimjEGiGIF7vNfniYl+T7EEAb8Oiz7OfXOH/cOMUWTtys6ZAm03hi6ZlqvCUH/8 QeiYsTvWBFjWuAN3touYg/Va6JgJtxEKGlP58MJj+Emb/OeB5k025ZQclHBG4LnoPdP6 7Ppw==
X-Gm-Message-State: ALoCoQmo0izrclRMtiDn86EgmBMt82f6bHyWbELpLxlWQR5UXNSMS8FElMS9e4qjQapzDC2H+awf
X-Received: by 10.180.99.39 with SMTP id en7mr6087548wib.31.1432903171421; Fri, 29 May 2015 05:39:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.225.14 with HTTP; Fri, 29 May 2015 05:38:51 -0700 (PDT)
In-Reply-To: <20150529113932.97453180204@rfc-editor.org>
References: <20150529113932.97453180204@rfc-editor.org>
From: Eric Rescorla 
Date: Fri, 29 May 2015 05:38:51 -0700
Message-ID: 
To: RFC Errata System 
Content-Type: multipart/alternative; boundary=f46d0418280887cbe3051737c484
Archived-At: 
Cc: Kathleen Moriarty , "tls@ietf.org" , lscorco@nsa.gov
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 12:39:35 -0000

--f46d0418280887cbe3051737c484
Content-Type: text/plain; charset=UTF-8

I do not believe that this report is correct:

"A vector (single-dimensioned array) is a stream of homogeneous data
elements.
The size of the vector may be specified at documentation time or left
unspecified until runtime. In either case, the length declares the number of
bytes, not the number of elements, in the vector."





On Fri, May 29, 2015 at 4:39 AM, RFC Errata System <
rfc-editor@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC5246,
> "The Transport Layer Security (TLS) Protocol Version 1.2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4382
>
> --------------------------------------
> Type: Technical
> Reported by: Laura Corcoran 
>
> Section: 4.3
>
> Original Text
> -------------
> In the following example, Datum is defined to be three consecutive
>    bytes that the protocol does not interpret, while Data is three
>    consecutive Datum, consuming a total of nine bytes.
>
>       opaque Datum[3];      /* three uninterpreted bytes */
>       Datum Data[9];        /* 3 consecutive 3 byte vectors */
>
>
> Corrected Text
> --------------
> In the following example, Datum is defined to be three consecutive
>    bytes that the protocol does not interpret, while Data is three
>    consecutive Datum, consuming a total of nine bytes.
>
>       opaque Datum[3];      /* three uninterpreted bytes */
>       Datum Data[3];        /* 3 consecutive 3 byte vectors */
>
>
> Notes
> -----
> The 9 in "Datum Data[9]" should be a 3 because Datum is a data type that
> consumes 3 bytes, so as written the Data vector is 27 bytes long. To make
> it a 9 byte vector the 9 must change to a 3.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5246 (draft-ietf-tls-rfc4346-bis-10)
> --------------------------------------
> Title               : The Transport Layer Security (TLS) Protocol Version
> 1.2
> Publication Date    : August 2008
> Author(s)           : T. Dierks, E. Rescorla
> Category            : PROPOSED STANDARD
> Source              : Transport Layer Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>
>

--f46d0418280887cbe3051737c484
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I do not believe that this report is correct:

"A vector (single-dimensioned array) is a stream of homogeneous=
 data elements.
The size of the vector may be specified at documentatio=
n time or left
unspecified until runtime. In either case, the len=
gth declares the number of
bytes, not the number of elements, in =
the vector."




On Fri, May 29, 2015 at 4:39 AM, RFC Errata System <=
;rfc-editor@=
rfc-editor.org> wrote:
The =
following errata report has been submitted for RFC5246,

"The Transport Layer Security (TLS) Protocol Version 1.2".



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

You may review the report below and at:

http://www.rfc-editor.org/errata_search.php?rfc=
=3D5246&eid=3D4382



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

Type: Technical

Reported by: Laura Corcoran <lscorco@=
nsa.gov>



Section: 4.3



Original Text

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

In the following example, Datum is defined to be three consecutive

=C2=A0 =C2=A0bytes that the protocol does not interpret, while Data is thre=
e

=C2=A0 =C2=A0consecutive Datum, consuming a total of nine bytes.



=C2=A0 =C2=A0 =C2=A0 opaque Datum[3];=C2=A0 =C2=A0 =C2=A0 /* three uninterp=
reted bytes */

=C2=A0 =C2=A0 =C2=A0 Datum Data[9];=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 3 consecu=
tive 3 byte vectors */





Corrected Text

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

In the following example, Datum is defined to be three consecutive

=C2=A0 =C2=A0bytes that the protocol does not interpret, while Data is thre=
e

=C2=A0 =C2=A0consecutive Datum, consuming a total of nine bytes.



=C2=A0 =C2=A0 =C2=A0 opaque Datum[3];=C2=A0 =C2=A0 =C2=A0 /* three uninterp=
reted bytes */

=C2=A0 =C2=A0 =C2=A0 Datum Data[3];=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 3 consecu=
tive 3 byte vectors */





Notes

-----

The 9 in "Datum Data[9]" should be a 3 because Datum is a data ty=
pe that consumes 3 bytes, so as written the Data vector is 27 bytes long. T=
o make it a 9 byte vector the 9 must change to a 3.



Instructions:

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

This erratum is currently posted as "Reported". If necessary, ple=
ase

use "Reply All" to discuss whether it should be verified or

rejected. When a decision is reached, the verifying party (IESG)

can log in to change the status and edit the report, if necessary.



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

RFC5246 (draft-ietf-tls-rfc4346-bis-10)

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

Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Transport=
 Layer Security (TLS) Protocol Version 1.2

Publication Date=C2=A0 =C2=A0 : August 2008

Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: T. Dierks, E. Rescorla<=
br>
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD

Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Layer Se=
curity

Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security

Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF

Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG







--f46d0418280887cbe3051737c484--


From lscorco@nsa.gov  Fri May 29 06:36:06 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562F71A88FD for ; Fri, 29 May 2015 06:36:06 -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 bnlyU8S6Wp9Q for ; Fri, 29 May 2015 06:36:04 -0700 (PDT)
Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 181CA1A88A6 for ; Fri, 29 May 2015 06:36:03 -0700 (PDT)
X-TM-IMSS-Message-ID: <65780b89000c2172@nsa.gov>
Received: from MSHT-GH1-UEA02.corp.nsa.gov (msht-gh1-uea02.corp.nsa.gov [10.215.227.181]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 65780b89000c2172 ; Fri, 29 May 2015 09:35:40 -0400
Received: from MSMR-GH1-UEA03.corp.nsa.gov (10.215.224.3) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 29 May 2015 09:35:54 -0400
Received: from MSMR-GH1-UEA07.corp.nsa.gov ([10.215.224.5]) by MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) with mapi id 14.02.0347.000; Fri, 29 May 2015 09:35:54 -0400
From: "Corcoran, Laura S" 
To: 'Eric Rescorla' , RFC Errata System 
Thread-Topic: [Technical Errata Reported] RFC5246 (4382)
Thread-Index: AQHQmgRwYI7xbef1Ck2tS2Wch4/olp2TJ9qA///MsZA=
Date: Fri, 29 May 2015 13:35:52 +0000
Message-ID: <2439617C1657A5409F21F022353D2DB9015908A8@MSMR-GH1-UEA07.corp.nsa.gov>
References: <20150529113932.97453180204@rfc-editor.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.215.225.46]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Fri, 29 May 2015 08:20:54 -0700
Cc: Kathleen Moriarty , "tls@ietf.org" 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 13:37:31 -0000

SXQgc2VlbXMgdGhhdCBEYXRhIGlzIG5vdCBhIHZlY3RvciwgYnV0IGFuIGFycmF5IG9mIHZlY3Rv
cnMuIFdvdWxkbid0IHRoYXQgbWFrZSBhIGRpZmZlcmVuY2UgaGVyZT8NCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21d
IA0KU2VudDogRnJpZGF5LCBNYXkgMjksIDIwMTUgODozOSBBTQ0KVG86IFJGQyBFcnJhdGEgU3lz
dGVtDQpDYzogVGltIERpZXJrczsgU3RlcGhlbiBGYXJyZWxsOyBLYXRobGVlbiBNb3JpYXJ0eTsg
U2VhbiBUdXJuZXI7IEpvc2VwaCBTYWxvd2V5OyBDb3Jjb3JhbiwgTGF1cmEgUzsgdGxzQGlldGYu
b3JnDQpTdWJqZWN0OiBSZTogW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzUyNDYgKDQz
ODIpDQoNCkkgZG8gbm90IGJlbGlldmUgdGhhdCB0aGlzIHJlcG9ydCBpcyBjb3JyZWN0Og0KDQoi
QSB2ZWN0b3IgKHNpbmdsZS1kaW1lbnNpb25lZCBhcnJheSkgaXMgYSBzdHJlYW0gb2YgaG9tb2dl
bmVvdXMgZGF0YSBlbGVtZW50cy4NClRoZSBzaXplIG9mIHRoZSB2ZWN0b3IgbWF5IGJlIHNwZWNp
ZmllZCBhdCBkb2N1bWVudGF0aW9uIHRpbWUgb3IgbGVmdCB1bnNwZWNpZmllZCB1bnRpbCBydW50
aW1lLiBJbiBlaXRoZXIgY2FzZSwgdGhlIGxlbmd0aCBkZWNsYXJlcyB0aGUgbnVtYmVyIG9mIGJ5
dGVzLCBub3QgdGhlIG51bWJlciBvZiBlbGVtZW50cywgaW4gdGhlIHZlY3Rvci4iDQoNCg0KDQoN
Cg0KT24gRnJpLCBNYXkgMjksIDIwMTUgYXQgNDozOSBBTSwgUkZDIEVycmF0YSBTeXN0ZW0gPHJm
Yy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+IHdyb3RlOg0KDQoNCglUaGUgZm9sbG93aW5nIGVycmF0
YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM1MjQ2LA0KCSJUaGUgVHJhbnNwb3J0
IExheWVyIFNlY3VyaXR5IChUTFMpIFByb3RvY29sIFZlcnNpb24gMS4yIi4NCgkNCgktLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVlvdSBtYXkgcmV2aWV3IHRoZSByZXBv
cnQgYmVsb3cgYW5kIGF0Og0KCWh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJj
aC5waHA/cmZjPTUyNDYmZWlkPTQzODINCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KCVR5cGU6IFRlY2huaWNhbA0KCVJlcG9ydGVkIGJ5OiBMYXVyYSBDb3Jjb3Jh
biA8bHNjb3Jjb0Buc2EuZ292Pg0KCQ0KCVNlY3Rpb246IDQuMw0KCQ0KCU9yaWdpbmFsIFRleHQN
CgktLS0tLS0tLS0tLS0tDQoJSW4gdGhlIGZvbGxvd2luZyBleGFtcGxlLCBEYXR1bSBpcyBkZWZp
bmVkIHRvIGJlIHRocmVlIGNvbnNlY3V0aXZlDQoJICAgYnl0ZXMgdGhhdCB0aGUgcHJvdG9jb2wg
ZG9lcyBub3QgaW50ZXJwcmV0LCB3aGlsZSBEYXRhIGlzIHRocmVlDQoJICAgY29uc2VjdXRpdmUg
RGF0dW0sIGNvbnN1bWluZyBhIHRvdGFsIG9mIG5pbmUgYnl0ZXMuDQoJDQoJICAgICAgb3BhcXVl
IERhdHVtWzNdOyAgICAgIC8qIHRocmVlIHVuaW50ZXJwcmV0ZWQgYnl0ZXMgKi8NCgkgICAgICBE
YXR1bSBEYXRhWzldOyAgICAgICAgLyogMyBjb25zZWN1dGl2ZSAzIGJ5dGUgdmVjdG9ycyAqLw0K
CQ0KCQ0KCUNvcnJlY3RlZCBUZXh0DQoJLS0tLS0tLS0tLS0tLS0NCglJbiB0aGUgZm9sbG93aW5n
IGV4YW1wbGUsIERhdHVtIGlzIGRlZmluZWQgdG8gYmUgdGhyZWUgY29uc2VjdXRpdmUNCgkgICBi
eXRlcyB0aGF0IHRoZSBwcm90b2NvbCBkb2VzIG5vdCBpbnRlcnByZXQsIHdoaWxlIERhdGEgaXMg
dGhyZWUNCgkgICBjb25zZWN1dGl2ZSBEYXR1bSwgY29uc3VtaW5nIGEgdG90YWwgb2YgbmluZSBi
eXRlcy4NCgkNCgkgICAgICBvcGFxdWUgRGF0dW1bM107ICAgICAgLyogdGhyZWUgdW5pbnRlcnBy
ZXRlZCBieXRlcyAqLw0KCSAgICAgIERhdHVtIERhdGFbM107ICAgICAgICAvKiAzIGNvbnNlY3V0
aXZlIDMgYnl0ZSB2ZWN0b3JzICovDQoJDQoJDQoJTm90ZXMNCgktLS0tLQ0KCVRoZSA5IGluICJE
YXR1bSBEYXRhWzldIiBzaG91bGQgYmUgYSAzIGJlY2F1c2UgRGF0dW0gaXMgYSBkYXRhIHR5cGUg
dGhhdCBjb25zdW1lcyAzIGJ5dGVzLCBzbyBhcyB3cml0dGVuIHRoZSBEYXRhIHZlY3RvciBpcyAy
NyBieXRlcyBsb25nLiBUbyBtYWtlIGl0IGEgOSBieXRlIHZlY3RvciB0aGUgOSBtdXN0IGNoYW5n
ZSB0byBhIDMuDQoJDQoJSW5zdHJ1Y3Rpb25zOg0KCS0tLS0tLS0tLS0tLS0NCglUaGlzIGVycmF0
dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFz
ZQ0KCXVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlm
aWVkIG9yDQoJcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5
aW5nIHBhcnR5IChJRVNHKQ0KCWNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVk
aXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5Lg0KCQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQoJUkZDNTI0NiAoZHJhZnQtaWV0Zi10bHMtcmZjNDM0Ni1iaXMtMTAp
DQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaXRsZSAgICAgICAg
ICAgICAgIDogVGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBQcm90b2NvbCBWZXJz
aW9uIDEuMg0KCVB1YmxpY2F0aW9uIERhdGUgICAgOiBBdWd1c3QgMjAwOA0KCUF1dGhvcihzKSAg
ICAgICAgICAgOiBULiBEaWVya3MsIEUuIFJlc2NvcmxhDQoJQ2F0ZWdvcnkgICAgICAgICAgICA6
IFBST1BPU0VEIFNUQU5EQVJEDQoJU291cmNlICAgICAgICAgICAgICA6IFRyYW5zcG9ydCBMYXll
ciBTZWN1cml0eQ0KCUFyZWEgICAgICAgICAgICAgICAgOiBTZWN1cml0eQ0KCVN0cmVhbSAgICAg
ICAgICAgICAgOiBJRVRGDQoJVmVyaWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCgkNCgkNCg0KDQo=


From nobody Fri May 29 09:10:18 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0350B1A6F3A for ; Fri, 29 May 2015 09:10:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level: 
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvcevYM2Jagi for ; Fri, 29 May 2015 09:10:14 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABC81A1B91 for ; Fri, 29 May 2015 09:10:14 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,517,1427752800"; d="scan'208";a="128456574"
Received: from 131.106.31.93.rev.sfr.net (HELO [192.168.1.76]) ([93.31.106.131]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 May 2015 18:10:12 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Benjamin Beurdouche 
In-Reply-To: <2439617C1657A5409F21F022353D2DB9015908A8@MSMR-GH1-UEA07.corp.nsa.gov>
Date: Fri, 29 May 2015 18:10:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8568E626-4121-4276-AB02-EB6ED584B2E5@inria.fr>
References: <20150529113932.97453180204@rfc-editor.org>  <2439617C1657A5409F21F022353D2DB9015908A8@MSMR-GH1-UEA07.corp.nsa.gov>
To: Laura Corcoran , Eric Rescorla 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: Kathleen Moriarty , ML IETF TLS , RFC Errata System 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 16:10:17 -0000

If the value is the number of bytes it is 9.
But I agree it is unclear at first read, maybe we should fix it ?

B.

> On 29 May 2015, at 15:35, Corcoran, Laura S  wrote:
>=20
> It seems that Data is not a vector, but an array of vectors. Wouldn't =
that make a difference here?
>=20
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]=20
> Sent: Friday, May 29, 2015 8:39 AM
> To: RFC Errata System
> Cc: Tim Dierks; Stephen Farrell; Kathleen Moriarty; Sean Turner; =
Joseph Salowey; Corcoran, Laura S; tls@ietf.org
> Subject: Re: [Technical Errata Reported] RFC5246 (4382)
>=20
> I do not believe that this report is correct:
>=20
> "A vector (single-dimensioned array) is a stream of homogeneous data =
elements.
> The size of the vector may be specified at documentation time or left =
unspecified until runtime. In either case, the length declares the =
number of bytes, not the number of elements, in the vector."
>=20
>=20
>=20
>=20
>=20
> On Fri, May 29, 2015 at 4:39 AM, RFC Errata System =
 wrote:
>=20
>=20
> 	The following errata report has been submitted for RFC5246,
> 	"The Transport Layer Security (TLS) Protocol Version 1.2".
> =09
> 	--------------------------------------
> 	You may review the report below and at:
> 	http://www.rfc-editor.org/errata_search.php?rfc=3D5246&eid=3D4382
> =09
> 	--------------------------------------
> 	Type: Technical
> 	Reported by: Laura Corcoran 
> =09
> 	Section: 4.3
> =09
> 	Original Text
> 	-------------
> 	In the following example, Datum is defined to be three =
consecutive
> 	   bytes that the protocol does not interpret, while Data is =
three
> 	   consecutive Datum, consuming a total of nine bytes.
> =09
> 	      opaque Datum[3];      /* three uninterpreted bytes */
> 	      Datum Data[9];        /* 3 consecutive 3 byte vectors */
> =09
> =09
> 	Corrected Text
> 	--------------
> 	In the following example, Datum is defined to be three =
consecutive
> 	   bytes that the protocol does not interpret, while Data is =
three
> 	   consecutive Datum, consuming a total of nine bytes.
> =09
> 	      opaque Datum[3];      /* three uninterpreted bytes */
> 	      Datum Data[3];        /* 3 consecutive 3 byte vectors */
> =09
> =09
> 	Notes
> 	-----
> 	The 9 in "Datum Data[9]" should be a 3 because Datum is a data =
type that consumes 3 bytes, so as written the Data vector is 27 bytes =
long. To make it a 9 byte vector the 9 must change to a 3.
> =09
> 	Instructions:
> 	-------------
> 	This erratum is currently posted as "Reported". If necessary, =
please
> 	use "Reply All" to discuss whether it should be verified or
> 	rejected. When a decision is reached, the verifying party (IESG)
> 	can log in to change the status and edit the report, if =
necessary.
> =09
> 	--------------------------------------
> 	RFC5246 (draft-ietf-tls-rfc4346-bis-10)
> 	--------------------------------------
> 	Title               : The Transport Layer Security (TLS) =
Protocol Version 1.2
> 	Publication Date    : August 2008
> 	Author(s)           : T. Dierks, E. Rescorla
> 	Category            : PROPOSED STANDARD
> 	Source              : Transport Layer Security
> 	Area                : Security
> 	Stream              : IETF
> 	Verifying Party     : IESG
> =09
> =09
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Fri May 29 09:11:24 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CE91A8798 for ; Fri, 29 May 2015 09:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level: 
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir9_CF6Eq8wd for ; Fri, 29 May 2015 09:11:22 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240E21A6F3A for ; Fri, 29 May 2015 09:11:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,517,1427752800"; d="scan'208";a="128456705"
Received: from 131.106.31.93.rev.sfr.net (HELO [192.168.1.76]) ([93.31.106.131]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 May 2015 18:11:11 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Benjamin Beurdouche 
In-Reply-To: <8568E626-4121-4276-AB02-EB6ED584B2E5@inria.fr>
Date: Fri, 29 May 2015 18:11:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20150529113932.97453180204@rfc-editor.org>  <2439617C1657A5409F21F022353D2DB9015908A8@MSMR-GH1-UEA07.corp.nsa.gov> <8568E626-4121-4276-AB02-EB6ED584B2E5@inria.fr>
To: Laura Corcoran , Eric Rescorla 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: Kathleen Moriarty , ML IETF TLS , RFC Errata System 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 16:11:24 -0000

I meant, fix it in the TLS 1.3 spec=E2=80=A6

> On 29 May 2015, at 18:10, Benjamin Beurdouche =
 wrote:
>=20
> If the value is the number of bytes it is 9.
> But I agree it is unclear at first read, maybe we should fix it ?
>=20
> B.
>=20
>> On 29 May 2015, at 15:35, Corcoran, Laura S  wrote:
>>=20
>> It seems that Data is not a vector, but an array of vectors. Wouldn't =
that make a difference here?
>>=20
>> -----Original Message-----
>> From: Eric Rescorla [mailto:ekr@rtfm.com]=20
>> Sent: Friday, May 29, 2015 8:39 AM
>> To: RFC Errata System
>> Cc: Tim Dierks; Stephen Farrell; Kathleen Moriarty; Sean Turner; =
Joseph Salowey; Corcoran, Laura S; tls@ietf.org
>> Subject: Re: [Technical Errata Reported] RFC5246 (4382)
>>=20
>> I do not believe that this report is correct:
>>=20
>> "A vector (single-dimensioned array) is a stream of homogeneous data =
elements.
>> The size of the vector may be specified at documentation time or left =
unspecified until runtime. In either case, the length declares the =
number of bytes, not the number of elements, in the vector."
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Fri, May 29, 2015 at 4:39 AM, RFC Errata System =
 wrote:
>>=20
>>=20
>> 	The following errata report has been submitted for RFC5246,
>> 	"The Transport Layer Security (TLS) Protocol Version 1.2".
>> =09
>> 	--------------------------------------
>> 	You may review the report below and at:
>> 	http://www.rfc-editor.org/errata_search.php?rfc=3D5246&eid=3D4382
>> =09
>> 	--------------------------------------
>> 	Type: Technical
>> 	Reported by: Laura Corcoran 
>> =09
>> 	Section: 4.3
>> =09
>> 	Original Text
>> 	-------------
>> 	In the following example, Datum is defined to be three =
consecutive
>> 	   bytes that the protocol does not interpret, while Data is =
three
>> 	   consecutive Datum, consuming a total of nine bytes.
>> =09
>> 	      opaque Datum[3];      /* three uninterpreted bytes */
>> 	      Datum Data[9];        /* 3 consecutive 3 byte vectors */
>> =09
>> =09
>> 	Corrected Text
>> 	--------------
>> 	In the following example, Datum is defined to be three =
consecutive
>> 	   bytes that the protocol does not interpret, while Data is =
three
>> 	   consecutive Datum, consuming a total of nine bytes.
>> =09
>> 	      opaque Datum[3];      /* three uninterpreted bytes */
>> 	      Datum Data[3];        /* 3 consecutive 3 byte vectors */
>> =09
>> =09
>> 	Notes
>> 	-----
>> 	The 9 in "Datum Data[9]" should be a 3 because Datum is a data =
type that consumes 3 bytes, so as written the Data vector is 27 bytes =
long. To make it a 9 byte vector the 9 must change to a 3.
>> =09
>> 	Instructions:
>> 	-------------
>> 	This erratum is currently posted as "Reported". If necessary, =
please
>> 	use "Reply All" to discuss whether it should be verified or
>> 	rejected. When a decision is reached, the verifying party (IESG)
>> 	can log in to change the status and edit the report, if =
necessary.
>> =09
>> 	--------------------------------------
>> 	RFC5246 (draft-ietf-tls-rfc4346-bis-10)
>> 	--------------------------------------
>> 	Title               : The Transport Layer Security (TLS) =
Protocol Version 1.2
>> 	Publication Date    : August 2008
>> 	Author(s)           : T. Dierks, E. Rescorla
>> 	Category            : PROPOSED STANDARD
>> 	Source              : Transport Layer Security
>> 	Area                : Security
>> 	Stream              : IETF
>> 	Verifying Party     : IESG
>> =09
>> =09
>>=20
>>=20
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Fri May 29 09:12:18 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D1F1A87CB for ; Fri, 29 May 2015 09:12:16 -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 s0ZnpCmUdJLa for ; Fri, 29 May 2015 09:12:15 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 D15851A87AA for ; Fri, 29 May 2015 09:12:14 -0700 (PDT)
Received: by qkx62 with SMTP id 62so47520415qkx.3 for ; Fri, 29 May 2015 09:12:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=Mu63ZEtzKYzzyHXyHtuVDki5t882xu/ka/zzjjGU6pg=; b=titv1Vz1Q5+mQqkeVZLW+EliNiLgqfi1GrFtyLv/Oo2yqS0jUOfv+m5FrXqNy7ABJF t8Q0KBIFOalkQ97MQHGXVmgjsaVxUdPAx2qVAXXe3+jsPve4lAoRdHZ5Y7MJJ7RGNsXf g0tL1XsKcf6I9U7UEoJH8veS7EEHk9j7okKTIBeJXRZoFlrzYrmM8T4CSIoz+T47mUHP HlxGm2eioeGszcV8kJeRBTivJ8QmYATXKF2SvNdyggcVXkWC/FjESXNvI763OnlK9lhE nqUTYrG/qs51u2U60kLyAsii2ieVPtKHRCvh/vD8pesqA9SanIKG4HJLsy2BnYEO9Mo3 G2Jg==
X-Received: by 10.140.25.208 with SMTP id 74mr10245908qgt.104.1432915934088; Fri, 29 May 2015 09:12:14 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id e104sm2866422qgd.29.2015.05.29.09.12.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 29 May 2015 09:12:13 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Fri, 29 May 2015 12:12:11 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20150529113932.97453180204@rfc-editor.org> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201505291212.12413.davemgarrett@gmail.com>
Archived-At: 
Cc: lscorco@nsa.gov, Kathleen Moriarty , RFC Errata System 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 16:12:16 -0000

Based on the definition, the current text is correct. I think the definition is confusing and not particularly helpful, but it's correct.

opaque Datum[3];  // 3 bytes
Datum Data[9];      // 9 bytes
Datum Data<3>;   // 9 bytes

The second notation is only used in RFC5246 in the specification of the SSL2 CLIENT-HELLO for "cipher_specs". Relevant lines quoted:

>      uint8 V2CipherSpec[3];
[...]
>          V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
[...]
>
>   cipher_spec_length
>      This field is the total length of the field cipher_specs.  It
>      cannot be zero and MUST be a multiple of the V2CipherSpec length
>      (3).

The length definition does say it's the total length of the array, not number of elements, so it appears to be using the notation correctly.


Dave


On Friday, May 29, 2015 08:38:51 am Eric Rescorla wrote:
> I do not believe that this report is correct:
> 
> "A vector (single-dimensioned array) is a stream of homogeneous data
> elements.
> The size of the vector may be specified at documentation time or left
> unspecified until runtime. In either case, the length declares the number of
> bytes, not the number of elements, in the vector."
> 
> 
> On Fri, May 29, 2015 at 4:39 AM, RFC Errata System <
> rfc-editor@rfc-editor.org> wrote:
> 
> > The following errata report has been submitted for RFC5246,
> > "The Transport Layer Security (TLS) Protocol Version 1.2".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4382
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Laura Corcoran 
> >
> > Section: 4.3
> >
> > Original Text
> > -------------
> > In the following example, Datum is defined to be three consecutive
> >    bytes that the protocol does not interpret, while Data is three
> >    consecutive Datum, consuming a total of nine bytes.
> >
> >       opaque Datum[3];      /* three uninterpreted bytes */
> >       Datum Data[9];        /* 3 consecutive 3 byte vectors */
> >
> >
> > Corrected Text
> > --------------
> > In the following example, Datum is defined to be three consecutive
> >    bytes that the protocol does not interpret, while Data is three
> >    consecutive Datum, consuming a total of nine bytes.
> >
> >       opaque Datum[3];      /* three uninterpreted bytes */
> >       Datum Data[3];        /* 3 consecutive 3 byte vectors */
> >
> >
> > Notes
> > -----
> > The 9 in "Datum Data[9]" should be a 3 because Datum is a data type that
> > consumes 3 bytes, so as written the Data vector is 27 bytes long. To make
> > it a 9 byte vector the 9 must change to a 3.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party (IESG)
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC5246 (draft-ietf-tls-rfc4346-bis-10)
> > --------------------------------------
> > Title               : The Transport Layer Security (TLS) Protocol Version
> > 1.2
> > Publication Date    : August 2008
> > Author(s)           : T. Dierks, E. Rescorla
> > Category            : PROPOSED STANDARD
> > Source              : Transport Layer Security
> > Area                : Security
> > Stream              : IETF
> > Verifying Party     : IESG


From nobody Fri May 29 09:18:32 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8941A9170 for ; Fri, 29 May 2015 09:18:30 -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 fi5Tn-4nEMLF for ; Fri, 29 May 2015 09:18:29 -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 8F7BF1A88ED for ; Fri, 29 May 2015 09:18:29 -0700 (PDT)
Received: by qgdy38 with SMTP id y38so6143515qgd.1 for ; Fri, 29 May 2015 09:18:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=upgjs7kqwri9jPWqD4/Y5lGgYbCokgCytzE9LdZ7050=; b=Yqx0UVSHhskRrZjIL4xgBYDuWq4YCepwlYVIdRs5XzwGOWC88QW8ejoKG+RssbdIWm jifbwhUeqIHqg8EaraRBETh5gQXmsYHOeepeM560k5HVhfsiMSDJdVHDQpJH6ebWra1t sXc9RXUhlJW/C8cotKh6H0qLURTqauLuL7KyLEwU7jHLBdS2SiH4nojW4EW25y+5viua bgVSxYAq6mcUmZn/r3nM5acFBv/FN/xPC4VNgJEvbnhwTsSklKvfjsn/8FpitEbbKI5S 80VJLxLMnCfuxaJop+xcmqZHEsAbGBbxgaXIzL+QTZUxFsOku9UpG8tbMSFjpbw3+H28 2TJw==
X-Received: by 10.55.42.130 with SMTP id q2mr17522186qkq.20.1432916308849; Fri, 29 May 2015 09:18:28 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id c80sm2866815qge.49.2015.05.29.09.18.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 29 May 2015 09:18:28 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Fri, 29 May 2015 12:18:27 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20150529113932.97453180204@rfc-editor.org>  <201505291212.12413.davemgarrett@gmail.com>
In-Reply-To: <201505291212.12413.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201505291218.27607.davemgarrett@gmail.com>
Archived-At: 
Cc: lscorco@nsa.gov, Kathleen Moriarty , RFC Errata System 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 16:18:31 -0000

Bah. Confusing, yes... Correcting myself:

opaque Datum[3];  // 3 bytes
Datum Data[9];      // 9 bytes
Datum Data<9>;   // 9 bytes

The variable length uses the same notation. Quoting the example from the spec:

>      uint16 longer<0..800>;
>            /* zero to 400 16-bit unsigned integers */

I would not be against throwing around some warnings that the length is always the sizeof and not the array length. It's not wrong, though.

On Friday, May 29, 2015 12:12:11 pm Dave Garrett wrote:
> Based on the definition, the current text is correct. I think the definition is confusing and not particularly helpful, but it's correct.
> 
> opaque Datum[3];  // 3 bytes
> Datum Data[9];      // 9 bytes
> Datum Data<3>;   // 9 bytes
> 
> The second notation is only used in RFC5246 in the specification of the SSL2 CLIENT-HELLO for "cipher_specs". Relevant lines quoted:


From nobody Fri May 29 09:53:30 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60741ACD8F for ; Fri, 29 May 2015 09:53:29 -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 7WSR7dc_GNhf for ; Fri, 29 May 2015 09:53:28 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 AB5411A8A81 for ; Fri, 29 May 2015 09:53:28 -0700 (PDT)
Received: by ykfr66 with SMTP id r66so24052539ykf.0 for ; Fri, 29 May 2015 09:53: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 :cc:content-type; bh=CS+EnuG8k28bHeW6RC18flszXFtwY1yDiwpY72OJHbA=; b=xZ6/aZI2McG+kjUJ7b3AaY2spAobKP3ELrQTMgJccCADXtB5fDktXDFAqRGBAJK2QU Gj9g0egdJNZZRs1HIm0LWnKwDlmAb5woWb/t9NVLj9tOd9CvvCDLsHLYqSTRhBH3XOZE GWKDWAIIHCFwmqFSMdWcKW6XuBF9qVUYuiIUJx9c6xGR3bVppcVUF/wEkFJAAoj6XdXN ki3wo8gE98EX8Uwjgqf1CXxWmWkFCkDjzsjAsBv6ir4a7uPdGRJfBEv9rUvPFy9Q4rZM 0sR8ul4aBc6xqbMCXrctLw14UiDxGK6qs4QYxCA9mvd51MjzD68T6QoxIMNiNGHrx4bL iKUg==
MIME-Version: 1.0
X-Received: by 10.170.158.10 with SMTP id z10mr10679578ykc.1.1432918408038; Fri, 29 May 2015 09:53:28 -0700 (PDT)
Received: by 10.129.110.138 with HTTP; Fri, 29 May 2015 09:53:27 -0700 (PDT)
In-Reply-To: <201505291218.27607.davemgarrett@gmail.com>
References: <20150529113932.97453180204@rfc-editor.org>  <201505291212.12413.davemgarrett@gmail.com> <201505291218.27607.davemgarrett@gmail.com>
Date: Fri, 29 May 2015 09:53:27 -0700
Message-ID: 
From: Martin Thomson 
To: Dave Garrett 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: lscorco@nsa.gov, Kathleen Moriarty , "tls@ietf.org" , RFC Errata System 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 16:53:30 -0000

On 29 May 2015 at 09:18, Dave Garrett  wrote:
>
> I would not be against throwing around some warnings that the length is always the sizeof and not the array length. It's not wrong, though.

ASN.1 doesn't suffer from this problem.  I wonder if it's worth
translating the spec to ASN.1 and (probably) PER?


From nobody Fri May 29 10:05:51 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E7B1ACDDB for ; Fri, 29 May 2015 10:05: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 ezh0fFBmN50Y for ; Fri, 29 May 2015 10:05:48 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB6B1ACDD0 for ; Fri, 29 May 2015 10:05:48 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 68B1548479; Fri, 29 May 2015 17:05:47 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5C09448478; Fri, 29 May 2015 17:05:47 +0000 (GMT)
Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 0DD0A8008A; Fri, 29 May 2015 17:05:47 +0000 (GMT)
Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 29 May 2015 12:05:46 -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; Fri, 29 May 2015 12:05:46 -0500
From: "Salz, Rich" 
To: Martin Thomson 
Thread-Topic: [TLS] [Technical Errata Reported] RFC5246 (4382)
Thread-Index: AQHQmgR1E6WzfKxWqESlUdCwcd4zK52TOJ2AgAA7m4CAAAHAgIAACciA//+tJVA=
Date: Fri, 29 May 2015 17:05:46 +0000
Message-ID: <4ca01a6d90924c668750e74796c73ed8@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <20150529113932.97453180204@rfc-editor.org>  <201505291212.12413.davemgarrett@gmail.com> <201505291218.27607.davemgarrett@gmail.com> 
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.127]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 17:05:50 -0000

> ASN.1 doesn't suffer from this problem.  I wonder if it's worth translati=
ng the
> spec to ASN.1 and (probably) PER?

ASN.1 would be interesting, but I don't believe PER is the right thing as w=
e'd end up defining a completely new on-the-wire protocol for TLS 1.3.  Ins=
tead you'd have to define something like TER, the TLS Encoding Rules.

FWIW, about a year ago I wrote a parser for the TLS-RFC grammar: https://gi=
thub.com/richsalz/tlsparser


From nobody Fri May 29 10:15:46 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C351A0263 for ; Fri, 29 May 2015 10:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTz8jUGLQ_Bn for ; Fri, 29 May 2015 10:15:43 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4C34C1A0461 for ; Fri, 29 May 2015 10:15:42 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t4THFZHN026605; Fri, 29 May 2015 13:15:40 -0400
From: "Blumenthal, Uri - 0553 - MITLL" 
To: "'rsalz@akamai.com'" , "'martin.thomson@gmail.com'" 
Thread-Topic: [TLS] [Technical Errata Reported] RFC5246 (4382)
Thread-Index: AQHQmgR7QQMN3SEuJUSMqH+znUN04Z2TJ9qAgAA7moCAAAHBgIAACceAgAADcQD//7+y2g==
Date: Fri, 29 May 2015 17:15:36 +0000
Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC271EB7E4@LLE2K10-MBX01.mitll.ad.local>
In-Reply-To: <4ca01a6d90924c668750e74796c73ed8@ustx2ex-dag1mb2.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [155.34.14.22]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,  0.0.0000 definitions=2015-05-29_02:2015-05-29,2015-05-28,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505290007
Archived-At: 
Cc: "'tls@ietf.org'" 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 17:15:45 -0000

ASN.1 would be good - as long as there's a reasonably debugged parser/encod=
er, and a language subset is agreed upon. I'm for it, based on my prior exp=
erience with ASN.1 (including implementing it).
=20


----- Original Message -----
From: Salz, Rich [mailto:rsalz@akamai.com]
Sent: Friday, May 29, 2015 01:05 PM=0A=
To: Martin Thomson 
Cc: tls@ietf.org 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)

> ASN.1 doesn't suffer from this problem.  I wonder if it's worth translati=
ng the
> spec to ASN.1 and (probably) PER?

ASN.1 would be interesting, but I don't believe PER is the right thing as w=
e'd end up defining a completely new on-the-wire protocol for TLS 1.3.  Ins=
tead you'd have to define something like TER, the TLS Encoding Rules.

FWIW, about a year ago I wrote a parser for the TLS-RFC grammar: https://gi=
thub.com/richsalz/tlsparser

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


From nobody Fri May 29 10:16:09 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717251A1A5A for ; Fri, 29 May 2015 10:16:08 -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 R0v7xizjbdWg for ; Fri, 29 May 2015 10:16:07 -0700 (PDT)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268EB1A7022 for ; Fri, 29 May 2015 10:15:58 -0700 (PDT)
Received: by yhda23 with SMTP id a23so21072221yhd.2 for ; Fri, 29 May 2015 10:15:57 -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=QgJi3fswdn34AjxAybyS/QYv8ErP3W/E2TAJR6xesNo=; b=UvCehXsqVoCs8vf1KwOyHfBwrHX26uTcFY7/IdwNwaYb/5giDdXFg2Tygd8e2iKrRQ 5NJlImgP8wDoCcTh1i5GDi9ykIqM+vjVOrTDZEPRB+sxvp2/oJaabcxokpTtERHA1lC3 RX7G2e4L22d63fzO0GubNKcesiA94NCnOOLd5o23c8ocmZN93o/qgVJ3lZju1esBtbou b5QtX5c2g1YLggAPKJ0pMHrtCuO1zB/lzH2ksHKJCzMxkclKmdHUnEQGHa3lgVwFyfV+ yMtgIoglloYCzbyskezGXc23bYga7Y172fSTWRBKbnIzi/uD1rIODD2st2V/lNtSIkpL IKAg==
MIME-Version: 1.0
X-Received: by 10.170.120.86 with SMTP id m83mr10715832ykb.110.1432919757501;  Fri, 29 May 2015 10:15:57 -0700 (PDT)
Received: by 10.129.110.138 with HTTP; Fri, 29 May 2015 10:15:57 -0700 (PDT)
In-Reply-To: <4ca01a6d90924c668750e74796c73ed8@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <20150529113932.97453180204@rfc-editor.org>  <201505291212.12413.davemgarrett@gmail.com> <201505291218.27607.davemgarrett@gmail.com>  <4ca01a6d90924c668750e74796c73ed8@ustx2ex-dag1mb2.msg.corp.akamai.com>
Date: Fri, 29 May 2015 10:15:57 -0700
Message-ID: 
From: Martin Thomson 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 17:16:08 -0000

On 29 May 2015 at 10:05, Salz, Rich  wrote:
> ASN.1 would be interesting, but I don't believe PER is the right thing as we'd end up defining a completely new on-the-wire protocol for TLS 1.3.  Instead you'd have to define something like TER, the TLS Encoding Rules.

I'm not certain about that.


From nobody Fri May 29 10:30:43 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62FC1A888F for ; Fri, 29 May 2015 10:30:41 -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 J0zTBkVfHx3U for ; Fri, 29 May 2015 10:30:40 -0700 (PDT)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 96E421ACEBB for ; Fri, 29 May 2015 10:24:08 -0700 (PDT)
Received: by wivl4 with SMTP id l4so24018318wiv.1 for ; Fri, 29 May 2015 10:24: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:from:date :message-id:subject:to:cc:content-type; bh=L4jI+ernyex7PC14s1ZjTzV8QUL8lAzNbEtn75jm2Mc=; b=MmHFGq19rWRA0XcXewogitPUp9X90beAf1EwZU82vMnI3SQ4UIoCYq8omTPuCW2Y2q pZ1ocED/LRsy0eMKXqeWSK31dsC/3JrhIj+ymWFJhOTSrXjHWT6n/GtVhiuJAxiOC/oK HAtthJ3x0+LFC2MXAdMDr3oAXa4c/3mwxn28fMlnZG8jDY07rLia24ELs7mySpto8cHw /dLFIoynh2lP7E1w54vIlyAtOzMPFCMCd6nohmkDWrxmPu5oq4CxbobO2Czrfwr3grti HdVI6QBkmXO2VsytRMFhHAClkm9c2xg4E5uItbcn2rd13LB81d9qpL0+o5prPHq4ahdn WOTg==
X-Gm-Message-State: ALoCoQnvOac2imAtlbgHiWR0LKsUCgCB5ovhSZl9lb1PJtsyIBhovqn1LYUvxbJLcoo3eVyyDj3I
X-Received: by 10.194.79.225 with SMTP id m1mr17453343wjx.8.1432920247401; Fri, 29 May 2015 10:24:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.225.14 with HTTP; Fri, 29 May 2015 10:23:26 -0700 (PDT)
In-Reply-To: 
References: <20150529113932.97453180204@rfc-editor.org>  <201505291212.12413.davemgarrett@gmail.com> <201505291218.27607.davemgarrett@gmail.com>  <4ca01a6d90924c668750e74796c73ed8@ustx2ex-dag1mb2.msg.corp.akamai.com> 
From: Eric Rescorla 
Date: Fri, 29 May 2015 10:23:26 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=047d7b10c90356917905173bbe74
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 17:30:41 -0000

--047d7b10c90356917905173bbe74
Content-Type: text/plain; charset=UTF-8

I wouldn't be excited about making this change at this time.

I agree that the spec could be clearer about the syntax.
Also, a cursory look suggests that we never use fixed-size arrays
of fixed-size objects, so maybe we can just remove this example.

-Ekr


On Fri, May 29, 2015 at 10:15 AM, Martin Thomson 
wrote:

> On 29 May 2015 at 10:05, Salz, Rich  wrote:
> > ASN.1 would be interesting, but I don't believe PER is the right thing
> as we'd end up defining a completely new on-the-wire protocol for TLS 1.3.
> Instead you'd have to define something like TER, the TLS Encoding Rules.
>
> I'm not certain about that.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7b10c90356917905173bbe74
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I wouldn't be excited about making this change at this=
 time.

I agree that the spec could be clearer about the =
syntax.
Also, a cursory look suggests that we never use fixed-siz=
e arrays
of fixed-size objects, so maybe we can just remove this =
example.

-Ekr


O=
n Fri, May 29, 2015 at 10:15 AM, Martin Thomson <martin.thomson@gma=
il.com> wrote:
On 29 May 2015 at 10:05, Salz, Rich <rsalz@akamai.com> wrote:

> ASN.1 would be interesting, but I don't believe PER is the right t=
hing as we'd end up defining a completely new on-the-wire protocol for =
TLS 1.3.=C2=A0 Instead you'd have to define something like TER, the TLS=
 Encoding Rules.



I'm not certain about that.




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--047d7b10c90356917905173bbe74--


From nobody Fri May 29 10:39:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8EF1ACE9F for ; Fri, 29 May 2015 10:39: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 SDuXJ36VGybE for ; Fri, 29 May 2015 10:39:15 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BAE1AD0BA for ; Fri, 29 May 2015 10:28:27 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 29 May 2015 17:28:09 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0172.012; Fri, 29 May 2015 17:28:08 +0000
From: Andrei Popov 
To: Martin Thomson , "Salz, Rich" 
Thread-Topic: [TLS] [Technical Errata Reported] RFC5246 (4382)
Thread-Index: AQHQmgR4foR/rNZB60aZnaIGtAShF52S5MuAgAA7m4CAAAHAgIAACciAgAADcQCAAALYgIAAAECw
Date: Fri, 29 May 2015 17:28:08 +0000
Message-ID: 
References: <20150529113932.97453180204@rfc-editor.org>  <201505291212.12413.davemgarrett@gmail.com> <201505291218.27607.davemgarrett@gmail.com>  <4ca01a6d90924c668750e74796c73ed8@ustx2ex-dag1mb2.msg.corp.akamai.com> 
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=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 3:2LkHZMvm0x2zdNfkgK1NrnatfBXGVsz5onMxP49NAA0dJ5O2NwRvUxm/1GkAH/uCyzAtlN/H9jcdzfwVdCTdtLwEahmpBECXsaqxcukiJca3yQBKcyBGL59gRYDy5as0RrWJggOj6DNtTQEJu+/KFQ==; 10:Rp0qvFCZgV1/2uQ7pijsTCO6+XbOLOLs0cpuQ6PSzVq2QsMj6IJ88hURWYnoAtlxFrHDWVPriKrju81iiux3y16SXL18gnf5QqxgbZXx0xE=; 6:TuLltMf0mjlFLSq+oEGTezHGv/KqW9lfaKQ5NlZVhoGGZcQdb4vVvbRq7roq4yDx
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(520003)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0;  PCL:0; RULEID:; SRVR:BLUPR03MB1396; 
x-forefront-prvs: 059185FE08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(13464003)(24454002)(19580405001)(99286002)(33656002)(76576001)(86362001)(2950100001)(54356999)(87936001)(106356001)(2656002)(2900100001)(105586002)(93886004)(86612001)(15975445007)(102836002)(50986999)(76176999)(5001960100002)(19580395003)(106116001)(101416001)(77096005)(189998001)(5001860100001)(46102003)(68736005)(4001540100001)(81156007)(97736004)(62966003)(5002640100001)(74316001)(122556002)(5001830100001)(40100003)(92566002)(5001770100001)(5001920100001)(64706001)(77156002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:3; A:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2015 17:28:08.8404 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 17:39:17 -0000

If we change the "presentation language" used by TLS specs, then we'll end =
up with two different, inconsistent notations. Anyone implementing TLS 1.3 =
will then need to understand the new "presentation language", and also be w=
ell-versed in the old one (e.g. so that they can implement existing extensi=
ons described using the old notation). This seems more confusing than what =
we have now.

But if we do end up selecting a new notation, let's at least make sure corr=
ect parsing code can be auto-generated from it.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Friday, May 29, 2015 10:16 AM
To: Salz, Rich
Cc: tls@ietf.org
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)

On 29 May 2015 at 10:05, Salz, Rich  wrote:
> ASN.1 would be interesting, but I don't believe PER is the right thing as=
 we'd end up defining a completely new on-the-wire protocol for TLS 1.3.  I=
nstead you'd have to define something like TER, the TLS Encoding Rules.

I'm not certain about that.

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


From nobody Fri May 29 10:45:48 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168351A702D for ; Fri, 29 May 2015 10:45:47 -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 0w4GwfZsEJ9Q for ; Fri, 29 May 2015 10:45:45 -0700 (PDT)
Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AF21B2C02 for ; Fri, 29 May 2015 10:38:42 -0700 (PDT)
Received: by qczw4 with SMTP id w4so4417066qcz.2 for ; Fri, 29 May 2015 10:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=X2dxIjeH5rHg5QrO92HBKoruLT48NxVkktpgM5Xqe7g=; b=Zz4DqeIauTc9OxF5BR1kZTQNoRBZhE4K85NDhhiDfEPL6SIUKZbKZHd4tlmKXd2tVL Tj4xpTd9SMbC+6Q+dNE+EYwdcypQomu5iD71bH1MgB8IpOXbLLQIFDmNA/ceTKNh1cYA o0I1ILsb2hUAC764awHYMR2pKNqk92B9DnUec0Ts3Gi2iYZjjxYEpL1sc0A/GBwp3FED Qr71EARhjNLJhRXmE2xq8/OkJI+gH97l537mItkXa2vF4cCd9s4pzI9jj7kmNyjEJTXr 1fEXZqTmdfZbSocecv2nfmJcZ8ELdYia1mh0rujJNhGmbS61EmUQek2Nmllfl1IVcNP6 sV9w==
X-Received: by 10.55.17.95 with SMTP id b92mr18098086qkh.16.1432921121446; Fri, 29 May 2015 10:38:41 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id m134sm2956801qhb.30.2015.05.29.10.38.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 29 May 2015 10:38:40 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Fri, 29 May 2015 13:38:39 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20150529113932.97453180204@rfc-editor.org>  
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201505291338.40091.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 17:45:47 -0000

Agreed. Redoing the whole thing in a new syntax could be mistake prone for both the spec and implementations. The simplest route would be to remove unhelpful examples and narrow the syntax on what is actually needed.


Dave


On Friday, May 29, 2015 01:23:26 pm Eric Rescorla wrote:
> I wouldn't be excited about making this change at this time.
> 
> I agree that the spec could be clearer about the syntax.
> Also, a cursory look suggests that we never use fixed-size arrays
> of fixed-size objects, so maybe we can just remove this example.
> 
> -Ekr
> 
> 
> On Fri, May 29, 2015 at 10:15 AM, Martin Thomson 
> wrote:
> 
> > On 29 May 2015 at 10:05, Salz, Rich  wrote:
> > > ASN.1 would be interesting, but I don't believe PER is the right thing
> > as we'd end up defining a completely new on-the-wire protocol for TLS 1.3.
> > Instead you'd have to define something like TER, the TLS Encoding Rules.
> >
> > I'm not certain about that.
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
> 


From nobody Fri May 29 10:53:50 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882F11ACE4C for ; Fri, 29 May 2015 10:53:48 -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 VmoQIH008cI7 for ; Fri, 29 May 2015 10:53:47 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id AD4571ACED2 for ; Fri, 29 May 2015 10:52:08 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CF8041665EA; Fri, 29 May 2015 17:52:07 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id C4AF81665E8; Fri, 29 May 2015 17:52:07 +0000 (GMT)
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 C13E19803E; Fri, 29 May 2015 17:52:07 +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; Fri, 29 May 2015 12:52:07 -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; Fri, 29 May 2015 12:52:07 -0500
From: "Salz, Rich" 
To: Martin Thomson 
Thread-Topic: [TLS] [Technical Errata Reported] RFC5246 (4382)
Thread-Index: AQHQmgR1E6WzfKxWqESlUdCwcd4zK52TOJ2AgAA7m4CAAAHAgIAACciA//+tJVCAAFkkgP//tePA
Date: Fri, 29 May 2015 17:52:07 +0000
Message-ID: <9579df63c8e14995b80ea3e01fb6d41f@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <20150529113932.97453180204@rfc-editor.org>  <201505291212.12413.davemgarrett@gmail.com> <201505291218.27607.davemgarrett@gmail.com>  <4ca01a6d90924c668750e74796c73ed8@ustx2ex-dag1mb2.msg.corp.akamai.com> 
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.127]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (4382)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 17:53:48 -0000

PiBJJ20gbm90IGNlcnRhaW4gYWJvdXQgdGhhdC4NCg0KRm9yIGV4YW1wbGUsIGVudW1lcmF0aW9u
cyBhcmUgc2VyaWFsaXplZCBieSBzZW5kaW5nIHRoZWlyICJpbmRleCB2YWx1ZSIsIG5vdCB0aGVp
ciB0cnVlIHZhbHVlLg0K


From nobody Fri May 29 11:06:53 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB571ACEA0 for ; Fri, 29 May 2015 11:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEoyy30LeH7X for ; Fri, 29 May 2015 11:06:50 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234C21ACE8E for ; Fri, 29 May 2015 11:06:49 -0700 (PDT)
Received: by igbsb11 with SMTP id sb11so20638021igb.0 for ; Fri, 29 May 2015 11:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Z1ANcV4N12sAL8dPIHcztAASeVxpwpK5bmaluRwmAU8=; b=mW7lzbfKmXkSdhOFFpV1IDrLH3x21KOBq+2mPS24UIHSgU+vRO3WQYbF5hlTT0zoBD muZ08YQ/VQzcgirt55RZRAnKMrcRGEAPXBPI086xK3hdPYIN3VDopheKnjn87kVWfKI1 upUjunsTyaygIi6heg+NXWkZRKAgk1h29e83Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=Z1ANcV4N12sAL8dPIHcztAASeVxpwpK5bmaluRwmAU8=; b=j6yE4ijvEE3FISgMEc2GwZBgajJVwycy/3yo4tldEn9BpCam5vBmQTTYFL7Sw3ZQ2e ea5mxG7peentFV5hpnF6/48VuvMR09R7+sIcFRyiOG+Dkc6LyA1XY13uK3ropoYqj/Ba e+RLIgqyXeoqc7XW3rAcXgpJPDN9WD+eZc/LnJqKdHo6UZqAUQOMn8u53cgpY2TNgn/g +VCIxDBhODVIS64pc7iAqW+P97q3yMiZVmfyv/zW6Dh92x6UFy7hK7uffcnsZ47PJDGt nChJCO5h3rqk5Eq2d7BTtQriRRwByIrGJdsiPNVoAhcS/aOX98o1egeCkg342YC6uP+p wIvA==
X-Gm-Message-State: ALoCoQkR70/FUoi4kPKFDBkzadQSB/Sa88MMsNWwiP+gewNwxFMR0DhJ4z+Pl15DJje4EXuueeOP
X-Received: by 10.42.131.202 with SMTP id a10mr16575187ict.49.1432922809424; Fri, 29 May 2015 11:06:49 -0700 (PDT)
MIME-Version: 1.0
References:  <20150527172329.GI27628@localhost>  
In-Reply-To: 
From: David Benjamin 
Date: Fri, 29 May 2015 18:06:38 +0000
Message-ID: 
To: Eric Rescorla , Martin Thomson 
Content-Type: multipart/alternative; boundary=bcaec55237800bfcd205173c576a
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 18:06:52 -0000

--bcaec55237800bfcd205173c576a
Content-Type: text/plain; charset=UTF-8

I poked a bit more and I was mistaken about OpenSSL's d2i_SSL_SESSION
behavior: Although it does ignore the structure version, it will fail the
parse if it sees elements at the end of the structure it doesn't
understand. Presuming any EMS implementation adds an optional boolean to
the end of the serialized session, pre-EMS servers derived from OpenSSL
should simply not recognize any sessions created by post-EMS servers in any
shared session cache + rolling upgrade situation. So, at least against
those servers, having the client abort when the peer resumes an EMS-full
server without EMS should not cause issues. I don't know about other
implementations though.

If we do specify that the client MUST or even SHOULD abort in that case, I
think we should also explicitly call out that servers without EMS support
MUST NOT resume sessions created with EMS support. This is slightly weird
because EMS-less servers will necessarily predate this specification.

A client has no option to fall back to a full handshake at ServerHello, so
any cases where we want clients to abort, we need to be sure are illegal
for the server to produce. (E.g. EMS-ful resume of EMS-less session is okay
to abort because we can reasonably require that servers fall back to a full
handshake.)

David

On Thu, May 28, 2015 at 7:24 PM Eric Rescorla  wrote:

> I'd like to close the loop on this, since I think it would be better if
> implementations
> behaved identically.
>
> It seems to me that there are two cases here:
>
> - Interoperating with non-EMS-enabled devices, in which case we want to
>   encourage refusal to resume, but we know we can't require it (hence
>   SHOULD.
>
> - Mid-flight reconfigurations/changes, etc. in which case we should be able
>   to come down on one definite interpretation.
>
> Since this second case should rarely happen, but people seem sad about
> abort, I would suggest that we say MUST NOT resume and SHOULD
> do a new full handshake.
>
> -Ekr
>
>
>
>
>
>
>
>
> On Wed, May 27, 2015 at 10:43 AM, Martin Thomson  > wrote:
>
>> On 27 May 2015 at 10:23, Nico Williams  wrote:
>> > Is a mid-flight reconfiguration of the client while reusing an old
>> > session cache likely?
>>
>> Some clients persist session caches to disk.  That means completely
>> new software could load old sessions.
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--bcaec55237800bfcd205173c576a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I poked a bit more and I was mistaken about OpenSSL's =
d2i_SSL_SESSION behavior: Although it does ignore the structure version, it=
 will fail the parse if it sees elements at the end of the structure it doe=
sn't understand. Presuming any EMS implementation adds an optional bool=
ean to the end of the serialized session, pre-EMS servers derived from Open=
SSL should simply not recognize any sessions created by post-EMS servers in=
 any shared session cache + rolling upgrade situation. So, at least against=
 those servers, having the client abort when the peer resumes an EMS-full s=
erver without EMS should not cause issues.=C2=A0I don't know about othe=
r implementations though.

If we do specify that the client MUST or e=
ven SHOULD abort in that case, I think we should also explicitly call out t=
hat servers without EMS support MUST NOT resume sessions created with EMS s=
upport. This is slightly weird because EMS-less servers will necessarily pr=
edate this specification.

A client has no option to fall back to a f=
ull handshake at ServerHello, so any cases where we want clients to abort, =
we need to be sure are illegal for the server to produce. (E.g. EMS-ful res=
ume of EMS-less session is okay to abort because we can reasonably require =
that servers fall back to a full handshake.)

David

On Thu, May 28, 2015 at 7:24 PM Eric Resc=
orla <ekr@rtfm.com> wrote:
I'd like to close th=
e loop on this, since I think it would be better if implementations
beh=
aved identically.

It seems to me that there are tw=
o cases here:

- Interoperating with non-EMS-enable=
d devices, in which case we want to
=C2=A0 encourage refusal to r=
esume, but we know we can't require it (hence
=C2=A0 SHOULD.<=
/div>

- Mid-flight reconfigurations/changes, etc. in whi=
ch case we should be able
=C2=A0 to come down on one definite int=
erpretation.

Since this second case should rarely =
happen, but people seem sad about
abort, I would suggest that we =
say MUST NOT resume and SHOULD
do a new full handshake.

-Ekr








On Wed, May 27, 201=
5 at 10:43 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 27 May 2015 at 10:23,=
 Nico Williams <nico@cryptonector.com> wrote:

> Is a mid-flight reconfiguration of the client while reusing an old

> session cache likely?



Some clients persist session caches to disk.=C2=A0 That means comple=
tely

new software could load old sessions.




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls




--bcaec55237800bfcd205173c576a--


From nobody Fri May 29 11:09:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836E01B2AF2 for ; Fri, 29 May 2015 11:09:10 -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 vlx4zHNI0PpN for ; Fri, 29 May 2015 11:09:09 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id E74791B2AE4 for ; Fri, 29 May 2015 11:09:08 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6FD271665FA; Fri, 29 May 2015 18:09:08 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 644B21665EA; Fri, 29 May 2015 18:09:08 +0000 (GMT)
Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 5ED681E07C; Fri, 29 May 2015 18:09:08 +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; Fri, 29 May 2015 13:09:07 -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; Fri, 29 May 2015 13:09:07 -0500
From: "Salz, Rich" 
To: David Benjamin , Eric Rescorla , Martin Thomson 
Thread-Topic: [TLS] More clarity on resumption and session hash
Thread-Index: AQHQlxFQdGX8niFqsUOL72AZUFwucZ2QaWIAgAAFhQCAAfF5gIABObgA//+sfcA=
Date: Fri, 29 May 2015 18:09:07 +0000
Message-ID: 
References:  <20150527172329.GI27628@localhost>   
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.127]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 18:09:10 -0000

PiBJIHBva2VkIGEgYml0IG1vcmUgYW5kIEkgd2FzIG1pc3Rha2VuIGFib3V0IE9wZW5TU0wncyBk
MmlfU1NMX1NFU1NJT04gYmVoYXZpb3I6IEFsdGhvdWdoIGl0IGRvZXMgaWdub3JlIHRoZSBzdHJ1
Y3R1cmUgdmVyc2lvbiwgaXQgd2lsbCBmYWlsIHRoZSBwYXJzZSBpZiBpdCBzZWVzIGVsZW1lbnRz
IGF0IHRoZSBlbmQgb2YgdGhlIHN0cnVjdHVyZSBpdCBkb2Vzbid0IHVuZGVyc3RhbmQuDQoNCldl
J2QgbGlrZSB0byBjaGFuZ2UgdGhpcy4gIEFsbG93IGFwcGxpY2F0aW9ucyB0byBhcHBlbmQgdGhl
aXIgb3duIGRhdGEgdG8gYSBzZXNzaW9uIGlzIHZlcnkgdXNlZnVsLg0KDQooV2UgaXMgcHJvYmFi
bHkgbXkgZW1wbG95ZXIgc3VibWl0dGluZyBwYXRjaGVzIHRvIE9wZW5TU0wgd2hpY2ggc29tZW9u
ZSBvbiB0aGUgZGV2IHRlYW0gbGlrZSBtZSB3aWxsIHJldmlldy4oKQ0KDQoJL3IkDQo=


From nobody Fri May 29 11:14:42 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811801B2BAA for ; Fri, 29 May 2015 11:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3cK_ga2oh6t for ; Fri, 29 May 2015 11:14:40 -0700 (PDT)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 4A2981B2BA8 for ; Fri, 29 May 2015 11:14:40 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so21058145igb.0 for ; Fri, 29 May 2015 11:14:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=nXEyYfGc5PJ3EeCVOUiNchK2Z6S8UU0uUpeOtNhM9Fo=; b=jL3Thc1NYU9cisBpqjYDP5lqpAWKs0/zemFMtpg+dhgJKGt7mOo+4GArbXqzAkoLzM llVuDcIBMdISAEyqZ9nM1KfsZrMUyqc0VNr67ruPoPTgZVngYQULDteUgwKdiOh5VHm3 PSoTe6/S+O9VGe4B7D8Kvi7tjUynTVzRg3q1o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=nXEyYfGc5PJ3EeCVOUiNchK2Z6S8UU0uUpeOtNhM9Fo=; b=Z1yM3P77mGs/ORQUuNfZKqqNFWG8XlHuraUW/EItzd+5FcFg1GNarqsbv92G/PTpjX TiO0gL9sIBGcR9YkqpRpRqXdNRfe0y07qgC7zXUQZfBqpicvm00k9K+cg4IA9OEOV0nc +1UWk5RRZ1zKAyBraXmtUAOtj+ISf8QnMV+jsPDLkUSfULmgpr7t3xOCQriPADM6sk32 TZvtCO/LVJh6zrrgT/0vhqGT6VzldiopcPY++z6xM6bkodTvWcJZVMsNQ6Gkedn5MoHP 7vvthXq/ySeEmkPQ1kcrOK5u2P5IIeRhCM0u/+UiFdllyjhOKc88COHZXX+B0cvayNp1 po3g==
X-Gm-Message-State: ALoCoQl0SqCc5YOMPEIaqIRr3JPb8qBQmFauubxAM9PHbbtOBmX7GDl9mHhvFPfyP0Z3B9G1xENK
X-Received: by 10.107.137.80 with SMTP id l77mr11435484iod.92.1432923279719; Fri, 29 May 2015 11:14:39 -0700 (PDT)
MIME-Version: 1.0
References:  <20150527172329.GI27628@localhost>    
In-Reply-To: 
From: David Benjamin 
Date: Fri, 29 May 2015 18:14:29 +0000
Message-ID: 
To: "Salz, Rich" , Eric Rescorla ,  Martin Thomson 
Content-Type: multipart/alternative; boundary=001a113ec86414378c05173c73b2
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 18:14:41 -0000

--001a113ec86414378c05173c73b2
Content-Type: text/plain; charset=UTF-8

On Fri, May 29, 2015 at 2:09 PM Salz, Rich  wrote:

> > I poked a bit more and I was mistaken about OpenSSL's d2i_SSL_SESSION
> behavior: Although it does ignore the structure version, it will fail the
> parse if it sees elements at the end of the structure it doesn't understand.
>
> We'd like to change this.  Allow applications to append their own data to
> a session is very useful.
>
> (We is probably my employer submitting patches to OpenSSL which someone on
> the dev team like me will review.()
>

This is somewhat tangential, but this seems a bad idea. Having applications
squat the same namespace of tag numbers as OpenSSL will break when OpenSSL
internally adds more fields to the end. If you want applications-specific
data in the session, either the application should serialize and
deserialize a wrapper structure that happens to contain a serialized
SSL_SESSION, or explicitly introduce an OCTET STRING hole to stuff opaque
application-specific data into.

David

--001a113ec86414378c05173c73b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Fri, May 29=
, 2015 at 2:09 PM Salz, Rich <rsalz@=
akamai.com> wrote:
> I p=
oked a bit more and I was mistaken about OpenSSL's d2i_SSL_SESSION beha=
vior: Although it does ignore the structure version, it will fail the parse=
 if it sees elements at the end of the structure it doesn't understand.=




We'd like to change this.=C2=A0 Allow applications to append their own =
data to a session is very useful.



(We is probably my employer submitting patches to OpenSSL which someone on =
the dev team like me will review.()

This is somewh=
at tangential, but this seems a bad idea. Having applications squat the sam=
e namespace of tag numbers as OpenSSL will break when OpenSSL internally ad=
ds more fields to the end. If you want applications-specific data in the se=
ssion, either the application should serialize and deserialize a wrapper st=
ructure that happens to contain a serialized SSL_SESSION, or explicitly int=
roduce an OCTET STRING hole to stuff opaque application-specific data into.=


David


--001a113ec86414378c05173c73b2--


From nobody Fri May 29 11:16:26 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367621B2BB4 for ; Fri, 29 May 2015 11:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2M1iL0Rcmzu for ; Fri, 29 May 2015 11:16:24 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137D31B2BB0 for ; Fri, 29 May 2015 11:16:24 -0700 (PDT)
Received: by igbhj9 with SMTP id hj9so21157010igb.1 for ; Fri, 29 May 2015 11:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=9MC9RJFjoZVz19+kxG6rjxwhM+8izAYxOpEJkBylBl0=; b=h5kOI9XW9SA6d08H04Ca1vm5wtWrV+K+Mqf2Wdsb067PPYvUEZ4dMmI4Dnxk96Np0x qfLqfRzhXMr1KA7ZHUqCkuNWsnSLOFjGkIm1nK8ax96T0WFlJC+9TLwoIlMKlg5gdaY+ 8/ctTWHVQKiiue9Nv/hYb6qZjsALMkHMjLzZk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=9MC9RJFjoZVz19+kxG6rjxwhM+8izAYxOpEJkBylBl0=; b=Arl4sgmVrtHmY7RDxyjr8JiJX2JY6CttCjD8mdrU7WfgWos+RhcguIdTtEbxsClkF1 HrBri9Mon2H/Qn6hIjVIt7+8XeXUlmQaerNKV2I47tPfM923u4uE1Y49DRjpPi/klRVf 6uJBWFUt3ERz+k1wo8qg2kk4Rjw2FcnU8OSSsJBmwqOuDLfJJgoVLZqaXKbR4QebRtOU CkXQFanJHQvlkfTlshE0ii7jHaHQmmtR1DAVxMs/CN34w/f3N0787gk/pmZLetNMBQ+c szKHIhav/QVoD7tJtHPmD+iK5r5n4Ni1/Ngdx96a2oyDGw8yJeZDJ0m0SzYBg33UWE9E hTIg==
X-Gm-Message-State: ALoCoQlVpodmODX5/z7755qVG91lv3qt0bdGqq356yQhplsqT0pY0ei/B/ud5e9TYEocLpDSROPX
X-Received: by 10.43.84.73 with SMTP id aj9mr16548001icc.69.1432923383531; Fri, 29 May 2015 11:16:23 -0700 (PDT)
MIME-Version: 1.0
References:  <20150527172329.GI27628@localhost>     
In-Reply-To: 
From: David Benjamin 
Date: Fri, 29 May 2015 18:16:13 +0000
Message-ID: 
To: "Salz, Rich" , Eric Rescorla ,  Martin Thomson 
Content-Type: multipart/alternative; boundary=bcaec51824c6443a4c05173c796d
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 18:16:25 -0000

--bcaec51824c6443a4c05173c796d
Content-Type: text/plain; charset=UTF-8

On Fri, May 29, 2015 at 2:14 PM David Benjamin 
wrote:

> On Fri, May 29, 2015 at 2:09 PM Salz, Rich  wrote:
>
>> > I poked a bit more and I was mistaken about OpenSSL's d2i_SSL_SESSION
>> behavior: Although it does ignore the structure version, it will fail the
>> parse if it sees elements at the end of the structure it doesn't understand.
>>
>> We'd like to change this.  Allow applications to append their own data to
>> a session is very useful.
>>
>> (We is probably my employer submitting patches to OpenSSL which someone
>> on the dev team like me will review.()
>>
>
> This is somewhat tangential, but this seems a bad idea. Having
> applications squat the same namespace of tag numbers as OpenSSL will break
> when OpenSSL internally adds more fields to the end. If you want
> applications-specific data in the session, either the application should
> serialize and deserialize a wrapper structure that happens to contain a
> serialized SSL_SESSION, or explicitly introduce an OCTET STRING hole to
> stuff opaque application-specific data into.
>

(Not to mention the obvious bad consequences, such as the one discussed in
this thread, if an older OpenSSL happily parses an SSL_SESSION with fields
it doesn't understand from a new OpenSSL.)

David

--bcaec51824c6443a4c05173c796d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Fri, May 29=
, 2015 at 2:14 PM David Benjamin <davidben@chromium.org> wrote:
On Fri, M=
ay 29, 2015 at 2:09 PM Salz, Rich <rsalz@akamai.com> wrote:
> I poked a bit more and I was mistaken about OpenSSL'=
s d2i_SSL_SESSION behavior: Although it does ignore the structure version, =
it will fail the parse if it sees elements at the end of the structure it d=
oesn't understand.



We'd like to change this.=C2=A0 Allow applications to append their own =
data to a session is very useful.



(We is probably my employer submitting patches to OpenSSL which someone on =
the dev team like me will review.()

This is somewhat tangential, but =
this seems a bad idea. Having applications squat the same namespace of tag =
numbers as OpenSSL will break when OpenSSL internally adds more fields to t=
he end. If you want applications-specific data in the session, either the a=
pplication should serialize and deserialize a wrapper structure that happen=
s to contain a serialized SSL_SESSION, or explicitly introduce an OCTET STR=
ING hole to stuff opaque application-specific data into.
<=
/blockquote>

(Not to mention the obvious bad consequences, such as =
the one discussed in this thread, if an older OpenSSL happily parses an SSL=
_SESSION with fields it doesn't understand from a new OpenSSL.)

David


--bcaec51824c6443a4c05173c796d--


From nobody Fri May 29 14:01:51 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945BC1B2D5D for ; Fri, 29 May 2015 14:01:49 -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 o-6mxKsxg4Ku for ; Fri, 29 May 2015 14:01:48 -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 45D861B2D5C for ; Fri, 29 May 2015 14:01:48 -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 t4TL1WVl013048 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 29 May 2015 23:01:33 +0200
From: Simon Josefsson 
To: Yoav Nir 
References:   
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:150529:ynir.ietf@gmail.com::1JT9hznDxogPYRC+:JOk+
X-Hashcash: 1:22:150529:ekr@rtfm.com::rzqcAPXgC6jtmLIo:ILCZ
X-Hashcash: 1:22:150529:tls@ietf.org::AD4eATJrw0df1uSh:WDrs
Date: Fri, 29 May 2015 23:01:30 +0200
In-Reply-To:  (Yoav Nir's message of "Thu, 21 May 2015 00:48:57 +0300")
Message-ID: <87y4k7w11x.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: "tls@ietf.org" 
Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 21:01:49 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Yoav Nir  writes:

> Me too.
>
> I notice that while the draft doesn=E2=80=99t say that explicitly, it uses
> existing *_ECDHE_* ciphersuites, so that no new ciphersuites are
> required, despite the fact that this ECDHE has different point formats
> and different back-end math than the existing ECDHE.  I wonder if we
> can also get away with using *ECDSA* ciphersuites for EdDSA
> signatures.

This is an interesting idea, thanks for mentioning that.  It would ugly
for "ECDSA" in a cipher suite name to not actually mean that ECDSA is
used, but it is a valid engineering tradeoff to sometimes prefer ugly
things that simplify over beautiful things that complicate.

/Simon

> Yoav
>
>> On May 20, 2015, at 6:50 PM, Eric Rescorla  wrote:
>>=20
>> I am in favor of adopting this draft.
>>=20
>> -Ekr
>>=20
>>=20
>> On Wed, May 20, 2015 at 8:47 AM, Joseph Salowey > wrote:
>> This is the WG call for adoption of:
>>=20
>> https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt 
>>=20
>> This draft specifies the use of Curve25519 for ephemeral key
>> exchange in the TLS and DTLS.  This draft serves as the starting
>> point (it=E2=80=99s expired and needs to be updated in light of
>> http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/
>> ).  If you
>> object to the adoption of this draft, please let us know why by
>> 20150602.
>>=20
>> Note: We=E2=80=99re not doing an early code point assignment for this dr=
aft,
>> because it clearly needs to resurrected and tweaked.  Once that
>> happens, there=E2=80=99s nothing stopping a request from the authors for=
 an
>> early code point assignment.
>>=20
>> Thanks,
>>=20
>> J/S
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVaNOrAAoJEIYLf7sy+BGdUxcH/jRfK59Yz5/KZTWsU7YGQxbB
F6o8anjsS+3YKVgnISPF7U1qxUgS/l2fznDHRYqLNmMuQKMsK9/ZgoWPGA73DnVN
8OtKQU4MFOXCGho0nSSZ0bRqUTMgT8dUjhF2qcXfiIQq5mxn1A+4HofJ0B/6JmLl
2UFiMrN28UckP7BF2jXzWQPugPAyRnXqlE3VoryExKac9t6XsqvBexVyDbh+wgnf
7XWs0iUgyDXdMmDWsZyPXfHNVuKRLfwl2c4inbnv4dnNwEsDhx5XNqDm8pxsOl6b
u/GiJJILjd+JTuSWhumiDBgLjCMfeXyxwSAXjU5KveHgAVZk2pRzljnVgtROe80=
=I+PH
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri May 29 14:09:13 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8A31ACE92 for ; Fri, 29 May 2015 14:09:12 -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 MQzQ3elDnloS for ; Fri, 29 May 2015 14:09:11 -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 EE2AF1AD09F for ; Fri, 29 May 2015 14:09:10 -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 t4TL90Pk013516 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 29 May 2015 23:09:01 +0200
From: Simon Josefsson 
To: Ilari Liusvaara 
References:  <20150520171504.GA21197@LK-Perkele-VII>
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:150529:joe@salowey.net::7YJAbeqHqU2nCxUW:SHym
X-Hashcash: 1:22:150529:ilari.liusvaara@elisanet.fi::wfaMTSXOFypLzU/Y:F10Z
X-Hashcash: 1:22:150529:tls@ietf.org::MgYkrcqHeVzI2egu:ZUow
Date: Fri, 29 May 2015 23:08:58 +0200
In-Reply-To: <20150520171504.GA21197@LK-Perkele-VII> (Ilari Liusvaara's message of "Wed, 20 May 2015 20:15:04 +0300")
Message-ID: <87twuvw0ph.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: "tls@ietf.org" 
Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 21:09:12 -0000

--=-=-=
Content-Type: text/plain

Ilari Liusvaara  writes:

> - Add curve448?

Given that it has been added to the CFRG document, I assume that this is
a given.  Right now Ed448-Goldilocks is in
draft-josefsson-tls-additional-curves but it can be moved.

> - Do bit masking like cfrg-curves specifies?

I don't have a strong opinion.  I believe that tls-curve25519 should not
deviate from cfrg-curves on this without a really strong reason.

> - Add zero key check like crfg-curves specifies[1]?

Ditto.

It is not clear to me whether the current wording for this and the
previous issue will remain in the cfrg-curves document though.

> - Why the point format and prefix? Expecting other point formats without
>   new codepoint allocation[2]? Or some software engineering reason?

What would you prefer instead?  Maybe Manuel Pegourie-Gonnard can chime
in here.

/Simon

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVaNVrAAoJEIYLf7sy+BGd7/MH/2ibE4fs9F6SidS05tTVpj4U
27K5dQwKbYEWC4xw+kalBoZobMbHpBHC9z/cfytGy50087Er9gjDp61SEvdxesZw
+F36Jy8b8aOodddFIaoHGfi0st9Fe4SWI3vhQUW9WGtKq3l9nbpcfaKZrm959bz6
FkiK2bEb3BZwFHChsWfr80qj58KGoVMo2m72JiN+UQzuI3YPSRJ+Zycdwp2YtDCY
K1teUqxIS+U0TTA3ksP4Yoa1p3tGvqWfZ6U4YPMiy840T5XvGlA+R7McJ/WXX9JE
6OtfV0+oivc/1dThxZT0Bp26QKc4DZHl6PnWX3e0ss9aEnLBorUrfaTT4fCrtq8=
=/GJr
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri May 29 14:14:59 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAB81A877D for ; Fri, 29 May 2015 14:14: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 S8ZS_YcgXp0G for ; Fri, 29 May 2015 14:14:56 -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 BF1561AD09F for ; Fri, 29 May 2015 14:14:55 -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 t4TLEf8l014001 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 29 May 2015 23:14:42 +0200
From: Simon Josefsson 
To: Ilari Liusvaara 
References: <1432142087.2946.11.camel@josefsson.org> <20150520203011.GA25549@LK-Perkele-VII>
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:150529:tls@ietf.org::WGNpdDaoKh+LYm+P:29+p
X-Hashcash: 1:22:150529:ilari.liusvaara@elisanet.fi::UWT9R7NsSUHjiJIt:6CIg
Date: Fri, 29 May 2015 23:14:39 +0200
In-Reply-To: <20150520203011.GA25549@LK-Perkele-VII> (Ilari Liusvaara's message of "Wed, 20 May 2015 23:30:11 +0300")
Message-ID: <87pp5jw0g0.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: tls@ietf.org
Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 21:14:57 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Ilari Liusvaara  writes:

> On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote:
>>
>> Support for EdDSA/Ed25519 in TLS has been suggested a couple of times.
>> I have started to work on an I-D to describe more precisely what that
>> would actually mean, and here is an initial strawman document:
>>=20
>> https://tools.ietf.org/html/draft-josefsson-tls-eddsa-00
>>=20
>> I'm confident I missed some major pieces of the puzzle, but feedback and
>> review is welcome so the document can be improved into something that
>> can be implemented and interoperate.
>
> More ciphersuites? The signature algorithm negotiation (extension 13)
> doesn't work in practice?

Yoav suggested reusing the ECDSA ciphersuites with (I assume) a new
extension 13 value for eddsa.

>> One aspect I'm aware of is that there is no OID allocated nor
>> specification of PKIX certificates with EdDSA/Ed25519 public keys.  I'm
>> not sure the above document is the right place for doing that though,
>> and more thinking around this topic is especially appreciated.
>
> AFAIK, a way to put the key into PKIX SPKI is required for the
> new signature algorithm to be useful.
>
> And that means OIDs. The curve itself is 1.3.6.1.4.1.11591.15.1,
> but AFAIK, there is no OID for the signature primitive.
>
> I think one can find more expertise about how to put various
> keys into SPKI in the PKIX mailinglist.

I'll try to prepare an email asking for help.

> Reading the PKIX specs, it seems like there are two ways:
>
> 1) Use algorithm "Unresricted" and use a new point format to
> denote LE edwards points.
>
> 2) Define new algorithm (OID) for EdDSA, put the curve OID
> as parameter and the LE edwards point as the key.

I prefer 2).  Given that EdDSA is not applicable to arbitrary curves,
you might want to allocate a new algorithm OID for Ed25519 directly with
no parameters.  This will reduce complexity a bit.

Thank you Ilari!

/Simon

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVaNbAAAoJEIYLf7sy+BGdhXoH/2LlkZzORrSMEH4tiuFbHMwb
F1OgKvuib40ubM8Hz8AU8y+NkppXPDC+m49XbeBZtdoZyS39Yrr/a/zyCgxwRDA0
ijMX/cQbTuwsyP5OOa/e8SV0Z+9aAEkV8lz+kGUGTRThWjxHdKziQTnW3j5aqthk
OiPtwM35VOEfSiUVkg8VvmYUxYhHDaC47gW4Ff9pKeoxwRTL2tMfj5PVYc6xI2X9
i+ddb9qouSDtOvHl4rSMk8CpR3uvozeEg/3V2sHBtUCRX5d5dwNmOYz4tlc3P2f2
56nP3KdU9ef4phk8PnqbaxvTFpcqWc3reAU2ZUd4J23HG9daX1BBDUifBVkjOPU=
=g4Mh
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri May 29 14:19:01 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C7D1B2D84 for ; Fri, 29 May 2015 14:19:01 -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 USjOXu3IM9u9 for ; Fri, 29 May 2015 14:19:00 -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 3E8061B2D74 for ; Fri, 29 May 2015 14:19:00 -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 t4TLIqGd014471 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 29 May 2015 23:18:53 +0200
From: Simon Josefsson 
To: Peter Bowen 
References: <1432142087.2946.11.camel@josefsson.org> <20150520190727.GD19183@localhost> 
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:150529:nico@cryptonector.com::gxEGI2G/jwzF58LY:7cI2
X-Hashcash: 1:22:150529:tls@ietf.org::EOdjIpekA70TZkcZ:XeTf
X-Hashcash: 1:22:150529:pzbowen@gmail.com::qh8x+SB1KObZwdYQ:/q1P
Date: Fri, 29 May 2015 23:18:50 +0200
In-Reply-To:  (Peter Bowen's message of "Thu, 21 May 2015 19:42:53 -0700")
Message-ID: <87lhg7w091.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: "tls@ietf.org" 
Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 21:19:01 -0000

--=-=-=
Content-Type: text/plain

Peter Bowen  writes:

> On Wed, May 20, 2015 at 12:07 PM, Nico Williams  wrote:
>> On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote:
>>> Support for EdDSA/Ed25519 in TLS has been suggested a couple of times.
>>
>> I'm in favor.
>>
>>> One aspect I'm aware of is that there is no OID allocated nor
>>> specification of PKIX certificates with EdDSA/Ed25519 public keys.  I'm
>>> not sure the above document is the right place for doing that though,
>>> and more thinking around this topic is especially appreciated.
>>
>> It's an OID.  You can get your own OID arc and then allocate an OID.
>>
>> Is it important to separate the addition of a PKIX algorithm OID from
>> the TLS bits?  Well, it is neater that way.
>
> I'll donate a short OID to the cause if that will help move things
> forward.  We have the 1.3.187 arc which is only three bytes DER.  If
> someone has a smaller arc (third node would be 127 or lower) and would
> offer an OID from their arc we can shave off another couple of bytes.

Anyone?  I have 1.3.6.1.4.1.11591 but it is much longer.

If you can allocate one OID for PKIX-EdDSA and one for PKIX-Ed25519 we
have two values to work with for doing a PKIX EdDSA or Ed25519 draft.
It is not clear to me which approach is best, and if you have room for
two OIDs let have two different from the start in case people want to
experiment with both.

Thank you for thinking of saving bytes here! :-)

/Simon

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVaNe7AAoJEIYLf7sy+BGd3RoIAKgWgRzh9s0SrNJEB8i7TZ13
Tp4jqLVkLbIHIdGO/TEfuA0b5/QTgFEEfzFkvNkysAxJFoCwjW+pS42vM6W8DlkM
OlNbusSi3ujNMlkdjJH5+KmDmRunruCDyjDcYpetcm7eu/4//vT9OgRqZY3zBdBo
Xa5DFb4atQwelTixN/RotOuYQedxEHjMWrl3ZSc5/6TSVIc0x/NGfwW6cddXWbGp
2efWVgb+UFgv/kHEw8L2KfspIQgsHqWKiLp80BZTm/rdbkVECJto3gOnDjQ+6KOv
REiIGNaqF8timSgw3h8UF0ZeA1NmtNrRq2n5lJF899qZB28hr1thD1OkWaqmc7o=
=JGq/
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri May 29 14:33:05 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6151A8939 for ; Fri, 29 May 2015 14:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5Enh6aPkQsz for ; Fri, 29 May 2015 14:32:59 -0700 (PDT)
Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 4FB411A1A0B for ; Fri, 29 May 2015 14:32:59 -0700 (PDT)
Received: (qmail 14479 invoked by uid 1004); 29 May 2015 21:32:57 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 29 May 2015 22:32:57 +0100
Received: (qmail 24498 invoked by uid 1000); 29 May 2015 21:32:57 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 29 May 2015 22:32:57 +0100
Message-ID: <5568DB08.1060303@comodo.com>
Date: Fri, 29 May 2015 22:32:56 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Simon Josefsson , Yoav Nir 
References:    <87y4k7w11x.fsf@latte.josefsson.org>
In-Reply-To: <87y4k7w11x.fsf@latte.josefsson.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 21:33:02 -0000

On 29/05/15 22:01, Simon Josefsson wrote:
> Yoav Nir  writes:
>
>> Me too.
>>
>> I notice that while the draft doesnt say that explicitly, it uses
>> existing *_ECDHE_* ciphersuites, so that no new ciphersuites are
>> required, despite the fact that this ECDHE has different point formats
>> and different back-end math than the existing ECDHE.  I wonder if we
>> can also get away with using *ECDSA* ciphersuites for EdDSA
>> signatures.
>
> This is an interesting idea, thanks for mentioning that.  It would ugly
> for "ECDSA" in a cipher suite name to not actually mean that ECDSA is
> used, but it is a valid engineering tradeoff to sometimes prefer ugly
> things that simplify over beautiful things that complicate.

The TLS 1.3 draft renames the Supported Elliptic Curves extension so 
that it can contain non-EC groups.  So renaming things in the IANA TLS 
registries doesn't seem to be prohibited, AFAICT.

Could we rename the TLS_ECDHE_ECDSA_* cipher suites so that they're not 
specific to ECDSA?  (TLS_ECDHE_EC_* perhaps?)

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.


From nobody Fri May 29 14:40:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2262E1B2DAD for ; Fri, 29 May 2015 14:40:35 -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 d9m8UX4Drn6u for ; Fri, 29 May 2015 14:40:33 -0700 (PDT)
Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 428491B2D84 for ; Fri, 29 May 2015 14:40:33 -0700 (PDT)
Received: (qmail 4790 invoked by uid 1004); 29 May 2015 21:40:31 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 29 May 2015 22:40:31 +0100
Received: (qmail 28380 invoked by uid 1000); 29 May 2015 21:40:31 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 29 May 2015 22:40:31 +0100
Message-ID: <5568DCCF.3020801@comodo.com>
Date: Fri, 29 May 2015 22:40:31 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Simon Josefsson ,  Peter Bowen 
References: <1432142087.2946.11.camel@josefsson.org> <20150520190727.GD19183@localhost>  <87lhg7w091.fsf@latte.josefsson.org>
In-Reply-To: <87lhg7w091.fsf@latte.josefsson.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 21:40:35 -0000

On 29/05/15 22:18, Simon Josefsson wrote:
> Peter Bowen  writes:
>
>> On Wed, May 20, 2015 at 12:07 PM, Nico Williams  wrote:
>>> On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote:
>>>> Support for EdDSA/Ed25519 in TLS has been suggested a couple of times.
>>>
>>> I'm in favor.
>>>
>>>> One aspect I'm aware of is that there is no OID allocated nor
>>>> specification of PKIX certificates with EdDSA/Ed25519 public keys.  I'm
>>>> not sure the above document is the right place for doing that though,
>>>> and more thinking around this topic is especially appreciated.
>>>
>>> It's an OID.  You can get your own OID arc and then allocate an OID.
>>>
>>> Is it important to separate the addition of a PKIX algorithm OID from
>>> the TLS bits?  Well, it is neater that way.
>>
>> I'll donate a short OID to the cause if that will help move things
>> forward.  We have the 1.3.187 arc which is only three bytes DER.  If
>> someone has a smaller arc (third node would be 127 or lower) and would
>> offer an OID from their arc we can shave off another couple of bytes.
>
> Anyone?  I have 1.3.6.1.4.1.11591 but it is much longer.

CABForum has 2.23.140.  That's no shorter than Amazon's 1.3.187 OID though.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Fri May 29 14:51:47 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C3C1A894E for ; Fri, 29 May 2015 14:51:45 -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 NFc7MhGxnxtU for ; Fri, 29 May 2015 14:51:43 -0700 (PDT)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 1F3091A8944 for ; Fri, 29 May 2015 14:51:43 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id BB6B91C2130; Fri, 29 May 2015 23:45:58 +0200 (CEST)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 9EDDB1FE014F; Fri, 29 May 2015 23:45:58 +0200 (CEST)
Date: Fri, 29 May 2015 23:45:58 +0200
From: Kurt Roeckx 
To: Simon Josefsson 
Message-ID: <20150529214558.GA14224@roeckx.be>
References: <1432142087.2946.11.camel@josefsson.org> <20150520190727.GD19183@localhost>  <87lhg7w091.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87lhg7w091.fsf@latte.josefsson.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 May 2015 21:51:45 -0000

On Fri, May 29, 2015 at 11:18:50PM +0200, Simon Josefsson wrote:
> Peter Bowen  writes:
> 
> > On Wed, May 20, 2015 at 12:07 PM, Nico Williams  wrote:
> >> On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote:
> >>> Support for EdDSA/Ed25519 in TLS has been suggested a couple of times.
> >>
> >> I'm in favor.
> >>
> >>> One aspect I'm aware of is that there is no OID allocated nor
> >>> specification of PKIX certificates with EdDSA/Ed25519 public keys.  I'm
> >>> not sure the above document is the right place for doing that though,
> >>> and more thinking around this topic is especially appreciated.
> >>
> >> It's an OID.  You can get your own OID arc and then allocate an OID.
> >>
> >> Is it important to separate the addition of a PKIX algorithm OID from
> >> the TLS bits?  Well, it is neater that way.
> >
> > I'll donate a short OID to the cause if that will help move things
> > forward.  We have the 1.3.187 arc which is only three bytes DER.  If
> > someone has a smaller arc (third node would be 127 or lower) and would
> > offer an OID from their arc we can shave off another couple of bytes.
> 
> Anyone?  I have 1.3.6.1.4.1.11591 but it is much longer.

I see there is already a .15.1 there for ed25519 that is being used
by gpg.  They used 1.3.6.1.4.1.3029.1.5.1 before that.

IANA actually also has 1.3.90 that is unused as far as I know.


Kurt


From nobody Fri May 29 23:43:11 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F7A1A92AD for ; Fri, 29 May 2015 23:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 EnpxLoae7NRl for ; Fri, 29 May 2015 23:43:06 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31161A9142 for ; Fri, 29 May 2015 23:43:05 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id B1A9A9004B; Sat, 30 May 2015 09:43:03 +0300 (EEST)
Date: Sat, 30 May 2015 09:43:03 +0300
From: Ilari Liusvaara 
To: Simon Josefsson 
Message-ID: <20150530064303.GA20551@LK-Perkele-VII>
References: <1432142087.2946.11.camel@josefsson.org> <20150520203011.GA25549@LK-Perkele-VII> <87pp5jw0g0.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <87pp5jw0g0.fsf@latte.josefsson.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara 
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2015 06:43:09 -0000

On Fri, May 29, 2015 at 11:14:39PM +0200, Simon Josefsson wrote:
> Ilari Liusvaara  writes:
> 
> > On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote:
> >>
> >
> > More ciphersuites? The signature algorithm negotiation (extension 13)
> > doesn't work in practice?
> 
> Yoav suggested reusing the ECDSA ciphersuites with (I assume) a new
> extension 13 value for eddsa.

Actually, looking at TLS specs, one needs the codepoint useable with
extension 13 anyway for TLS 1.2 (and 1.3-editorscopy).

(This won't work with 1.0/1.1, but who really cares).

Then there is the hash algorithm field. There are basically three
choices here:
1) Don't use it for anything. Internal hash is fixed to SHA-512, no
   pre-hashing is performed.
2) Hash algorithm field determines pre-hash. Internal hash is fixed
   to SHA-512.
3) Hash algorithm field determines internal hash, no pre-hashing.

With 3), the hash algorithm pretty much has to have 512-bit output.

While pre-hashing is not a great idea for TLS 1.2 server certificate
and TLS 1.3 server/client certificate, it could be useful for TLS
1.2 client certificate, since that covers data from number of flights.


> > Reading the PKIX specs, it seems like there are two ways:
> >
> > 1) Use algorithm "Unresricted" and use a new point format to
> > denote LE edwards points.
> >
> > 2) Define new algorithm (OID) for EdDSA, put the curve OID
> > as parameter and the LE edwards point as the key.
> 
> I prefer 2).  Given that EdDSA is not applicable to arbitrary curves,
> you might want to allocate a new algorithm OID for Ed25519 directly with
> no parameters.  This will reduce complexity a bit.

(Nit: s/EdDSA/Ed25519/)

Yeah, agreed. Also, new algorithm lets one define what is in the
BIT STRING field containing the key data.



I actually read PKIX again, and noticed something I did not notice
before:

There actually are two kinds of OIDs relevant to a new signature
algorithm

1) What OID(s) are allowed as key algorithms for that signature
algorithm. This also sets the format of keys (and what parameters
if any there are).

E.g. ECDSA uses unrestricted EC point, which specifies the standard
SEC1 encoding, and curve OID as a parameter.


2) What OID does the actual signature algorithm, when combined
with hash algorithm use. This sets the parameters given, if any
and the signature format.

E.g. ECDSA uses multiple OIDs, one for each allowed hash function
(e.g. one for ECDSA/SHA-256, another for ECDSA/SHA-384 and another
for ECDSA/SHA-512).


Given that Ed25519 fixes the hash, it would technically (in the
sense that the protocol works) work to use the same OID for both,
but I have no idea how existing PKIX software handles that sort of
thing.

Also, given that EdDSA public keys are only usable with one single
hash algorithm (since hash algorithm is part of public key derivation),
it would make sense to limit the keys to just single hash.

So there would be Ed25519 key type and Ed25519 signature algorithm.
As said I have no idea if these two can be the same OID (these always
appear in different contexts) or not.


-Ilari


From nobody Sat May 30 01:23:49 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1951A010C for ; Sat, 30 May 2015 01:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_35=0.6, 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 koLPZaq3iV6f for ; Sat, 30 May 2015 01:23:47 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 2A0641A0111 for ; Sat, 30 May 2015 01:23:47 -0700 (PDT)
Received: by wizo1 with SMTP id o1so48927740wiz.1 for ; Sat, 30 May 2015 01:23:46 -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=X7kUn5E8BirRNnBZtP10qjj8bid82brdAtoc1s/mlpo=; b=kfkizy80J0Dr8jVOv5JP6NHJ7g/BQQ4rFY7YL00FfNC1BdqwyYvQnVQMy3FRfHdoCV Eob9qddBrI74bpnM58RuNPMHwHSL4eYL1lVhcHPdDXpBTRO4bRTX1uEWxezPKm55kslR IMUAkK8dkBMiBOFs1rs05W/NxjrSBflrBR1MDV1jf5+aDRoQKrrrslBpzIDBFWp4r7Os 4f6KvOFTLwG0XUAYtKKd8Vq5wgm5YYirj2MnYtCcqQYi4Hgmd3DHQ2EJk/dje50H35++ dePhHl6HTXPETCAtUv8TcN1RcG92uIQe5cxc8qcH3gg/F4eJlwW4MO6W8M+DHBJK1z2f zlog==
X-Received: by 10.194.58.11 with SMTP id m11mr23074964wjq.92.1432974225924; Sat, 30 May 2015 01:23:45 -0700 (PDT)
Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id f6sm11773126wjq.31.2015.05.30.01.23.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 May 2015 01:23:44 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir 
In-Reply-To: <87y4k7w11x.fsf@latte.josefsson.org>
Date: Sat, 30 May 2015 11:23:43 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BDD2EAD-C883-4F37-95AF-6857181898A2@gmail.com>
References:    <87y4k7w11x.fsf@latte.josefsson.org>
To: Simon Josefsson 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Call for WG adoption draft-josefsson-tls-curve25519
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2015 08:23:48 -0000

> On May 30, 2015, at 12:01 AM, Simon Josefsson  =
wrote:
>=20
> Yoav Nir  writes:
>=20
>> Me too.
>>=20
>> I notice that while the draft doesn=E2=80=99t say that explicitly, it =
uses
>> existing *_ECDHE_* ciphersuites, so that no new ciphersuites are
>> required, despite the fact that this ECDHE has different point =
formats
>> and different back-end math than the existing ECDHE.  I wonder if we
>> can also get away with using *ECDSA* ciphersuites for EdDSA
>> signatures.
>=20
> This is an interesting idea, thanks for mentioning that.  It would =
ugly
> for "ECDSA" in a cipher suite name to not actually mean that ECDSA is
> used, but it is a valid engineering tradeoff to sometimes prefer ugly
> things that simplify over beautiful things that complicate.

It=E2=80=99s based on Elliptic Curves; it=E2=80=99s a Digital Signature; =
it=E2=80=99s an Algorithm. The =E2=80=9CECDSA=E2=80=9D label seems to =
still fit.

If we wanted to be really radical while losing backward compatibility, =
we could call the ciphersuite SIG_with_DHE, and use point formats for =
supporting RSA, DSA, ECDSA and EdDSA for signatures and DHE,ECDHE and =
Curve25519 for key agreement.

But since we do want backward compatibility, I think lumping all kinds =
of elliptic curve ephemeral D-H on =E2=80=9C_ECDHE_=E2=80=9D and all =
kinds of elliptic curve signatures on =E2=80=9C_ECDSA_=E2=80=9D is fine, =
even though ANSI X9.62 has labeled only the particular signature scheme =
used with P-256 as =E2=80=9CECDSA=E2=80=9D.

Yoav


From nobody Sat May 30 15:42:14 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099A91ACEBE for ; Sat, 30 May 2015 15:42:13 -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 c7Nuxyu2xnXH for ; Sat, 30 May 2015 15:42:11 -0700 (PDT)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 814381A8994 for ; Sat, 30 May 2015 15:42:11 -0700 (PDT)
Received: by pacux9 with SMTP id ux9so42220336pac.3 for ; Sat, 30 May 2015 15:42:11 -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=vQmLJmJnFdzvYgbSDMnxFLxE3W2uKk5Y5u+JSl2x/xc=; b=PIEqYK9NgdSq3EB/lRLYwM9KctenM9qjBkPvXrVF91OhUb/52a6PZVzp63lNNfPx48 YBdRdapCrWYgxCqn7P2Ss+IY0KBW7MA4AvicNUGLEBb8bUnckXrJXYdkKdevwGxUgVfp xJM1pPNNaiGZtbYEs2E7a69S/qxr68MNBuauf8En1q4Ld2jnrEwEGMJDtao0+q7Y0Llq Cmb3jH12HhekjTUbkdxpHqoh1qPYIAM7MDudYP7Jsxo8Yct9TdbpUAanSCBW4GMi6MPV Z8LmR7ypUZ+/tQldQGt7u+c7TwVd/oe+uBC+AYqFCmMvLMhC0Pvm9HGu4NKAuQf13IT9 eZ8Q==
MIME-Version: 1.0
X-Received: by 10.70.128.68 with SMTP id nm4mr27398703pdb.74.1433025731007; Sat, 30 May 2015 15:42:11 -0700 (PDT)
Received: by 10.70.66.5 with HTTP; Sat, 30 May 2015 15:42:10 -0700 (PDT)
In-Reply-To: <20150529214558.GA14224@roeckx.be>
References: <1432142087.2946.11.camel@josefsson.org> <20150520190727.GD19183@localhost>  <87lhg7w091.fsf@latte.josefsson.org> <20150529214558.GA14224@roeckx.be>
Date: Sat, 30 May 2015 15:42:10 -0700
Message-ID: 
From: Peter Bowen 
To: Kurt Roeckx 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Simon Josefsson , "tls@ietf.org" 
Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 May 2015 22:42:13 -0000

On Fri, May 29, 2015 at 2:45 PM, Kurt Roeckx  wrote:
> IANA actually also has 1.3.90 that is unused as far as I know.

The 1.3 arc is not managed by IANA, it is managed per ISO/IEC 6523-2.
90 was skipped for some unknown reason. I asked to get 90 when I
applied, but found out that it will take ISO/IEC standards action to
get it assigned as the current requirement is to assign IDs under that
arc sequentially.

More power to you if you can get ISO/IEC to approve :)

Thanks,
Peter