From nobody Wed Apr 1 02: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 5398B1A00EF for ; Wed, 1 Apr 2015 02:42:15 -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 wvZ8wRScDtz5 for ; Wed, 1 Apr 2015 02:42:14 -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 C28811A00B8 for ; Wed, 1 Apr 2015 02:42:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 38745BED4; Wed, 1 Apr 2015 10:42:12 +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 TJroM3WavL1U; Wed, 1 Apr 2015 10:42:10 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.244]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D53AFBE3E; Wed, 1 Apr 2015 10:42:09 +0100 (IST) Message-ID: <551BBD6F.2070507@cs.tcd.ie> Date: Wed, 01 Apr 2015 10:42:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mrex@sap.com, Martin Thomson References: <20150401042731.403F61B256@ld9781.wdf.sap.corp> In-Reply-To: <20150401042731.403F61B256@ld9781.wdf.sap.corp> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 09:42:15 -0000 Hiya, On 01/04/15 05:27, Martin Rex wrote: > Martin Thomson wrote: >> Stephen Farrell wrote: >>> >>> #1 Have we tested in the wild that using elliptic_curves (10) >>> in the ClientHello won't trigger some ECC code that causes >>> handshakes to barf? >> >> Firefox sends the supported_curves extension in every handshake and so >> do most browsers. So for those, the risk of intolerance is obviously >> quite low. That's not hard numbers obviously, but that's a lot of >> ClientHello messages with the extension. Good stuff. But see below. > > I think Stephen might have meant something else. > > RFC4492 contains the following explicit prohibition (Section 4, 4th paragr.): > > https://tools.ietf.org/html/rfc4492#section-4 > > > The client MUST NOT include these extensions in the ClientHello > message if it does not propose any ECC cipher suites. Ooh - good catch, I hadn't spotted that. This draft is updating 4492 though so we can validly change that, but if we're doing so (and I guess we are) then it'd be better to be very explicit about it, e.g. by adding a sentence saying that we're changing that specific MUST NOT. > and the above requirement seems to prohibit a non-ECC client from > using the named FFDHE parameters through the ECC named curve extension > _without_ accompanying ECC cipher suites. Right. That's the kind of thing I was wondering about. I'll happily accept the wg's word on this, but to what extent have we checked that we're not breaking something with this change in semantics. (It's a small, but real, change.) Thanks, S. > > > -Martin > From nobody Wed Apr 1 02:49: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 DB0971A01A5 for ; Wed, 1 Apr 2015 02:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfVVBXrvIavB for ; Wed, 1 Apr 2015 02:49:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DCD1A014C for ; Wed, 1 Apr 2015 02:49:19 -0700 (PDT) Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lk7fW-1Z9Xsp01V4-00c7yi; Wed, 01 Apr 2015 11:49:13 +0200 Message-ID: <551BBF17.3090600@gmx.net> Date: Wed, 01 Apr 2015 11:49:11 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sean Turner , "" References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> In-Reply-To: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pbDen1KCSVcnk9s2F3eBxDaeXSThEaVn0" X-Provags-ID: V03:K0:wG19oXWDwuQGRDpFkCnSZ/R4ELyuJ+3Iq95fVyQQbExjO9UX8rG m0gR7/x+YzhRrudOxvFTv7YhjyLIwL3QIAq9TcgROn2TOJqlVBSeJILYaxiuKrRpJZjCYPL iQTyQD02gTND+DHim0+jbaMz37A9O/z1Y48LcbCHy2WTzEApshy6eAFLXwwOb+uW1tklKp+ tiNfElRPDqgibDjjVK7OA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 09:49:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pbDen1KCSVcnk9s2F3eBxDaeXSThEaVn0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I support the publication of this document to capture existing deployments. Happy to review the doc. On 03/31/2015 06:20 PM, Sean Turner wrote: > All, >=20 > There=92s been some interested expressed in having > http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ > adopted as a TLS WG item. If you would like for this draft to become > a WG document, and you are willing to review drafts as it moves > through the process please indicate as much on this thread. If you > are opposed to this being a WG document, please say so (and say why). > Thanks in advance. >=20 > J&S _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --pbDen1KCSVcnk9s2F3eBxDaeXSThEaVn0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVG78XAAoJEGhJURNOOiAt9t4H/iayscd+YbyCYxX4kUg3fs/D nHByN8nRj/004MfIsD0Ir1Xhg5Q3kjyqG53lj4Mf8zLfspScy1KExDixzq9sE1yX an8MgwMVo0yOvNNNZ+TX8HcbOTef0g5cup3iVqhWfs+UvAAOcLcB3NKqsy+Vsfic 42vqTnoehnCvz8S22X336+alUeBCRYwOReEM6+95p59FDpwdxw5EubrYN62sePxd jUEro5/pNBIg70ElZpXWWiHGF74OMpe0Pawhh1Ap+IC+haXrE2tWMi6UvfXEWgQj xKo7dJXeX/6OfCzNy13Kne/SKWxrQvCQTIUAyrqFfkNvNgkh8NfBz87N65RZT6E= =QxkY -----END PGP SIGNATURE----- --pbDen1KCSVcnk9s2F3eBxDaeXSThEaVn0-- From nobody Wed Apr 1 10:04: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 924691A0030 for ; Wed, 1 Apr 2015 10:04: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 QKI9gt7nZzUM for ; Wed, 1 Apr 2015 10:04:02 -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 DA1CB1A002D for ; Wed, 1 Apr 2015 10:04:01 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so3933160obb.2 for ; Wed, 01 Apr 2015 10:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wzBHTdjOhPGWX9/flol456MunoLJYT0dQesjImYWxaA=; b=VuzG7FiKA7nemM60c02wxXPpfL20oHG92fqFgynFAMSUdJdlv5c2pSgf7k7+wYZ/bY 5mejB2o9rh+y4SLnFfYsFR2lOGareNFuvRjHqTIwh1BuqBUofQnYOB7+i31DuR/kFkOK xDJ6IpliKCEKZ89aEYDUzKQDAcPL+dGRb12kMI9RyrE+4VGP+EFMxWUUI6LsPym7l1Wx FCp2xUAyY9WIHbL1K6DOZGpAG9JDG2X7BypRJclGvsSQ8yEL5a9aQixNdEri8kFWe6Xv rnLF8f2c5yab/cit4LFjD07uBIXTQQcYLlMb85cqOzpk+sqXrJvmKpVUZXdV0Y9MuZVF /buw== MIME-Version: 1.0 X-Received: by 10.182.88.136 with SMTP id bg8mr41829946obb.86.1427907840356; Wed, 01 Apr 2015 10:04:00 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Wed, 1 Apr 2015 10:04:00 -0700 (PDT) In-Reply-To: References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> Date: Wed, 1 Apr 2015 10:04:00 -0700 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 17:04:08 -0000 On 31 March 2015 at 19:33, Brian Smith wrote: > > 4. The references to (FF-)DHE key exchange being acceptable for False > Start are removed. Although it may be possible to safely implement > False start for FF-DHE, the current draft isn't a good starting point > for specifying how that might be done. It's better to remove the > references until an adequate description of doing False Start for > FF-DHE key exchange is available, if ever. I agree with most of what Brian says, particularly with respect to only accepting the "best" profile of TLS here. However, I am generally leery of making specific recommendations regarding cipher suite choice. With the explicit groups, this might be OK. Without explicit groups, I think that Brian's point is completely valid. From nobody Wed Apr 1 10:53: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 84D921AD0B4; Wed, 1 Apr 2015 09:42:53 -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 hbRVJzerMzAR; Wed, 1 Apr 2015 09:42:51 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 127801AD0BA; Wed, 1 Apr 2015 09:42:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A8AD71E5D8A; Wed, 1 Apr 2015 09:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxYXZ-hv2WBz; Wed, 1 Apr 2015 09:42:09 -0700 (PDT) Received: from [10.0.1.3] (pool-100-36-211-121.washdc.fios.verizon.net [100.36.211.121]) by c8a.amsl.com (Postfix) with ESMTPA id 0D5DF1E5D5D; Wed, 1 Apr 2015 09:42:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20150330230611.0D5E718046C@rfc-editor.org> Date: Wed, 1 Apr 2015 12:42:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <83742230-DDC3-420C-A49B-BADD80D2E952@amsl.com> References: <20150330230611.0D5E718046C@rfc-editor.org> To: RFC System X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 10:53:23 -0700 Cc: tls@ietf.org, dottomi@gmail.com, IESG Subject: Re: [TLS] [Errata Rejected] RFC7366 (4284) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 16:42:53 -0000 Greetings, This erratum has been deleted as requested. Thank you. RFC Editor/mf On Mar 30, 2015, at 7:06 PM, RFC Errata System = wrote: > The following errata report has been rejected for RFC7366, > "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram = Transport Layer Security (DTLS)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7366&eid=3D4284 >=20 > -------------------------------------- > Status: Rejected > Type: Technical >=20 > Reported by: Tomasz Sobczyk > Date Reported: 2015-03-02 > Rejected by: Stephen Farrell (IESG) >=20 > Section: 3 >=20 > Original Text > ------------- > The overall TLS packet [2] is then: >=20 > struct { > ContentType type; > ProtocolVersion version; > uint16 length; > GenericBlockCipher fragment; > opaque MAC; > } TLSCiphertext; >=20 > The equivalent DTLS packet [4] is then: >=20 > struct { > ContentType type; > ProtocolVersion version; > uint16 epoch; > uint48 sequence_number; > uint16 length; > GenericBlockCipher fragment; > opaque MAC; > } TLSCiphertext; >=20 > This is identical to the existing TLS/DTLS layout, with the only > difference being that the MAC value is moved outside the encrypted > data. >=20 >=20 > Corrected Text > -------------- > The overall TLS packet [2] is then: >=20 > struct { > ContentType type; > ProtocolVersion version; > uint16 length; > GenericBlockCipher fragment; > opaque MAC[SecurityParameters.mac_length]; > } TLSCiphertext; >=20 > The equivalent DTLS packet [4] is then: >=20 > struct { > ContentType type; > ProtocolVersion version; > uint16 epoch; > uint48 sequence_number; > uint16 length; > GenericBlockCipher fragment; > opaque MAC[SecurityParameters.mac_length]; > } TLSCiphertext; >=20 > This is identical to the existing TLS/DTLS layout, with the only > differences being that the MAC value is moved outside the encrypted > data and the definition of TLSCiphertext.length changes to: >=20 > length > The length (in bytes) of the following TLSCiphertext.fragment > and TLSCiphertext.MAC. > The length MUST NOT exceed 2^14 + 2048. >=20 >=20 > Notes > ----- > MAC array length is missing. > Also, the new structure changes the definition of = TLSCiphertext.length. > As it currently stands, the length of the MAC is excluded from = TLSCiphertext.length. > This is a duplicate of erratum 4212 which is now verified. > --VERIFIER NOTES--=20 > This is a duplicate of erratum 4212 which is now verified.=20 >=20 > -------------------------------------- > RFC7366 (draft-ietf-tls-encrypt-then-mac-03) > -------------------------------------- > Title : Encrypt-then-MAC for Transport Layer Security = (TLS) and Datagram Transport Layer Security (DTLS) > Publication Date : September 2014 > Author(s) : P. Gutmann > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Wed Apr 1 10: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 609431A882B; Tue, 31 Mar 2015 16:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK6IE4-IBc98; Tue, 31 Mar 2015 16:56:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D906C1A878B; Tue, 31 Mar 2015 16:56:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150331235624.30677.82279.idtracker@ietfa.amsl.com> Date: Tue, 31 Mar 2015 16:56:24 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 10:53:25 -0700 Subject: [TLS] ID Tracker State Update Notice: 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, 31 Mar 2015 23:56:26 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ From nobody Wed Apr 1 11: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 03F101A1B7C for ; Wed, 1 Apr 2015 11:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.307 X-Spam-Level: ** X-Spam-Status: No, score=2.307 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FSL_HELO_BARE_IP_2=1.675, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 1c5sseHwq-Ky for ; Wed, 1 Apr 2015 11:00:49 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.56.195.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1E31A1B6C for ; Wed, 1 Apr 2015 11:00:47 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 9CD8FD4D1FDDD; Wed, 1 Apr 2015 13:00:46 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 8F6C5D4D1FD98 for ; Wed, 1 Apr 2015 13:00:46 -0500 (CDT) Received: from [96.231.227.6] (port=50785 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YdMwX-0004kf-Pe for tls@ietf.org; Wed, 01 Apr 2015 13:00:45 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> Date: Wed, 1 Apr 2015 14:00:45 -0400 To: "" 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: 96.231.227.6 X-Exim-ID: 1YdMwX-0004kf-Pe X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [96.231.227.6]:50785 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 18:00:50 -0000 This message is to confirm the consensus reached @ the IETF 92 TLS = session in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 = PRF be an HKDF-based PRF (see = http://datatracker.ietf.org/doc/rfc5869/?include_text=3D1). Please indicate whether or not you agree with the consensus by = 2015-04-17. If not, please indicate why. Also, please note that we=92re = interested in uncovering new issues not rehashing issues already = discussed. Thanks - J&S= From nobody Wed Apr 1 11:12: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 0BED71A1A94 for ; Wed, 1 Apr 2015 11:12:20 -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_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdPvrYKKVNcF for ; Wed, 1 Apr 2015 11:12:12 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376C81A0270 for ; Wed, 1 Apr 2015 11:12:12 -0700 (PDT) Received: from pc1.fritz.box (x4d0c3efb.dyn.telefonica.de [::ffff:77.12.62.251]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 01 Apr 2015 20:12:10 +0200 id 000000000000006F.00000000551C34FA.000022F8 Date: Wed, 1 Apr 2015 20:12:21 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: "" Message-ID: <20150401201221.163745c2@pc1.fritz.box> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-8952-1427911930-0001-2" Archived-At: Subject: [TLS] 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: Wed, 01 Apr 2015 18:12:20 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-8952-1427911930-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Mozilla just removed DSA support from Firefox. It seems the use of (non-ecc) DSA in TLS is pretty much nonexistent. Still the TLS 1.3 draft contains DSA. Proposal: DSA should go away and not be part of TLS 1.3. Reasons to remove DSA: * DSA with 1024 bit is considered weak and DSA with more than 1024 bit is widely unsupported. * DSA has comparable security to RSA (it using same keysize) which is the de-facto-default. Given that everybody uses RSA and nobody uses DSA having the latter only adds unneccessary complexity. * DSA can fail badly with bad random number generators. Some numbers: In the 2013 https ecosystem scan there were 17 DSA keys on public IPs, none of them CA-trusted: http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf I think it's safe to say nobody will care if DSA is removed. cu, --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-8952-1427911930-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVHDUFAAoJEKWIAHK7tR5CpFcP/RiZlq+5BN78dtz+1teKWdd2 oCEySdrjygZ+AMtPL3x/HAiYK8sBF7MVEOJNXw/RRe717DMrfyq1K2paKQJ0r2hE FyMz6lCW/QjRrl+8talsMobJnau03gJiCy/oxdoUhIqHqCCjVUXmRcc/Zn91BMjs w2z/EGf9LriXNlmqOxDxonmCGfpJOKwC5rTeoF4baxrZOAAmHBetdn+npTUP0eqB FLv3P+W9x+tCH+TUgVshInP/bMpD5L5NtYu0dN7kb/qAS2viub3xDkM6SmpXcEhm Uw5ZQc/rGDAQcv6B3IreqM8Ya2+bN98NrUArwKT/WFCpdUCISr4fc/Gh7fVCqtjX hCPbwuMNwJa0z+rUTZ2YvjXEoWeQShntGSCNvxcg5+/raZSDQAimfYPiRFu0xDrR wIVrw1Lbxo9otAR5rLrCs2ycruLWB2ay1BeVqWFPdr/awlMsPX5bRHCPZ49QUoRQ ma1Xa+nkk9tTGybMs8RoXSvxTU801qTKMZjaGjAFjGIdhEGkhXAsCw0RLRvUIGZH ppXksXbRUMxTDIbUh7jCY2b/MEeTyt14rKslvt9bBwfwuEUJ3t0p/e8CQ3U4Di5M n59F8GSVRywqjdOTaC1D7AMM4XwWN+UFZdkrlQxqfj3DwqfngjkZO+CrpGJljSxn Igd07RQzp+zZ1zK0k2cj =Zoid -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-8952-1427911930-0001-2-- From nobody Wed Apr 1 11:12: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 78EF31A1A69 for ; Wed, 1 Apr 2015 11:12:22 -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 BHHySTbuof45 for ; Wed, 1 Apr 2015 11:12:20 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (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 8E1831A0270 for ; Wed, 1 Apr 2015 11:12:20 -0700 (PDT) Received: by qgfa8 with SMTP id a8so49917514qgf.0 for ; Wed, 01 Apr 2015 11:12:19 -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=zm2jAPaaB9JJ8yYp/q4Yv3Z+YcUEfK/JVPmkj40FfQA=; b=Si/uPmVDdJtPPMqpV4+dmcxmTmiP1IxH05Mln1wiJ1Hbp3VUbCHNX30awclHtLKJBG cSOF0Xp28Jb/sdkAzL3DSaiomaiqO1LeY0blOuvQXQmAQqE8v8MSlm97G2YpONaMuQYN A8fShfHL1PVxeE21/hwy7kSOF39Pl7giA0oeS6xDHpWQp9xcrs88MWXtise7f4f6iVcJ QC+RzDfNC9Lewd2bvTcXvbL6iHe63T1T/8m4p0sdevWTWya4fZs2N12ZrWfxOTP9gw6K qKU7DbkiPObYsclMDRDswEgUf7yJ+XwgH0MnpoVygQLCg3cdwiqLjmiHigJskzTMls5T lR4Q== X-Gm-Message-State: ALoCoQkqciJPLv505C7PR/zqiJgWffGglVYJf9bHJwR+K7JxzdH6NI27jGyimd1nlRh0YVgmnmla MIME-Version: 1.0 X-Received: by 10.55.24.157 with SMTP id 29mr92206260qky.83.1427911939849; Wed, 01 Apr 2015 11:12:19 -0700 (PDT) Received: by 10.96.121.104 with HTTP; Wed, 1 Apr 2015 11:12:19 -0700 (PDT) X-Originating-IP: [50.206.82.141] Date: Wed, 1 Apr 2015 11:12:19 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113b9232f21fec0512ada723 Archived-At: Subject: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 18:12:22 -0000 --001a113b9232f21fec0512ada723 Content-Type: text/plain; charset=UTF-8 We did not get a chance to talk about MTI algorithms in Dallas, but the chairs would like to judge consensus for the algorithms discussed in the interim. The CFRG has closed or will close soon on ChaCha20 and curve 25519 recommendations so they are included. We will be calling for acceptance to bring drafts on these into the working group shortly. Keep in mind that mandatory to implement (MTI) is not mandatory to use and that it is expected that there will be profiles for specific environments. Below is the proposed algorithm list that had consensus at the Seattle Interim. Please reply on the TLS mailing list indicating whether or not you agree with the consensus. If not, please indicate why. This consensus call will close on April, 23, 2015. o Symmetric: MUST AES-GCM 128 SHOULD ChaCha20-Poly1305 o Hash: MUST SHA-256 o Key Agreement: ECDH MUST P-256 SHOULD 25519 o Signature: MUST ECDSA P-256 MUST RSA Thanks, J&S --001a113b9232f21fec0512ada723 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We did not get a chance to = talk about MTI algorithms in Dallas, but the chairs would like to judge con= sensus for the algorithms discussed in the interim.=C2=A0 The CFRG has clos= ed or will close soon on ChaCha20 and curve 25519 recommendations so they a= re included.=C2=A0 We will be calling for acceptance to bring drafts on the= se into the working group shortly.

=
Keep in mind that mandatory to implemen= t (MTI) is not mandatory to use and that it is expected that there will be = profiles for specific environments.

=
Below is the proposed algorithm list th= at had consensus at the Seattle Interim. Please reply on the TLS mailing li= st indicating=C2=A0whether or not you agree with the consensus.=C2=A0 If no= t, please indicate why.=C2=A0 This consensus call will close on April, 23, = 2015. =C2=A0

o Symmetric:
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 MUST AES-GCM 128
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOULD ChaCha20-Poly= 1305

o Hash:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST SHA-256

o Ke= y Agreement: ECDH
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST P-256
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 SHOULD 25519

o Signature:
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 MUST ECDSA P-256
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST RSA

Thanks,

J&S
--001a113b9232f21fec0512ada723-- From nobody Wed Apr 1 11:14: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 547191A1BC6 for ; Wed, 1 Apr 2015 11:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 QDexxPbEOHRr for ; Wed, 1 Apr 2015 11:14:40 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id ECA121A1B5D for ; Wed, 1 Apr 2015 11:14:39 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 1D6BBF984; Wed, 1 Apr 2015 14:14:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 97E5020191; Wed, 1 Apr 2015 13:14:34 -0500 (CDT) From: Daniel Kahn Gillmor To: Sean Turner , tls@ietf.org In-Reply-To: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 01 Apr 2015 14:14:34 -0400 Message-ID: <87zj6remwl.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 18:14:44 -0000 On Wed 2015-04-01 14:00:45 -0400, Sean Turner wrote: > This message is to confirm the consensus reached @ the IETF 92 TLS > session in Dallas and at the TLS Interim in Seattle to make the TLS > 1.3 PRF be an HKDF-based PRF (see > http://datatracker.ietf.org/doc/rfc5869/?include_text=1). > > Please indicate whether or not you agree with the consensus by > 2015-04-17. If not, please indicate why. Also, please note that > we’re interested in uncovering new issues not rehashing issues already > discussed. I agree with the room's consensus to move to an HKDF-based PRF for TLS 1.3. --dkg From nobody Wed Apr 1 11:33: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 CE0461A7003 for ; Wed, 1 Apr 2015 11:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 hauqOapLtyom for ; Wed, 1 Apr 2015 11:33:53 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id CF5341A1B2D for ; Wed, 1 Apr 2015 11:33:51 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t31IXnaa004140 for ; Wed, 1 Apr 2015 14:33:49 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Consensus Call on MTI Algorithms Thread-Index: AQHQbKdrrgxSnl5sOUuqebcfK2nw3Z04e3AA Date: Wed, 1 Apr 2015 18:33:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3510743620_71962288" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-01_07:2015-04-01,2015-04-01,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-1504010162 Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 18:33:56 -0000 --B_3510743620_71962288 Content-type: multipart/alternative; boundary="B_3510743620_71952103" --B_3510743620_71952103 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Yes. > We did not get a chance to talk about MTI algorithms in Dallas, but the chairs > would like to judge consensus for the algorithms discussed in the interim. > The CFRG has closed or will close soon on ChaCha20 and curve 25519 > recommendations so they are included. We will be calling for acceptance to > bring drafts on these into the working group shortly. > > Keep in mind that mandatory to implement (MTI) is not mandatory to use and > that it is expected that there will be profiles for specific environments. > > Below is the proposed algorithm list that had consensus at the Seattle > Interim. Please reply on the TLS mailing list indicating whether or not you > agree with the consensus. If not, please indicate why. This consensus call > will close on April, 23, 2015. > > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 > > o Hash: > MUST SHA-256 > > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 > > o Signature: > MUST ECDSA P-256 > MUST RSA > > Thanks, > > J&S --B_3510743620_71952103 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Yes.

<= div>
We did not get a chance= to talk about MTI algorithms in Dallas, but the chairs would like to judge = consensus for the algorithms discussed in the interim.  The CFRG has cl= osed or will close soon on ChaCha20 and curve 25519 recommendations so they are included.  We will be calling for a= cceptance to bring drafts on these into the working group shortly.
Keep in mind = that mandatory to implement (MTI) is not mandatory to use and that it is exp= ected that there will be profiles for specific environments.

Below is the propose= d algorithm list that had consensus at the Seattle Interim. Please reply on = the TLS mailing list indicating whether or not you agree with the conse= nsus.  If not, please indicate why.  This consensus call will close on April, 23, 2015.  

o Symmetric:
        MUST AES-GCM 128
        SHOULD ChaCha20-Poly1305

o Hash:
        MUST SHA-256

o Key Agreement: ECDH
        MUST P-256
        SHOULD 25519

o Signature:
        MUST ECDSA P-256
        MUST RSA

Thanks,

= J&S
--B_3510743620_71952103-- --B_3510743620_71962288 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUQwYJKoZIhvcNAQcCoIIUNDCCFDACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EiYwggTqMIID0qADAgECAgoocmWKAAAAAC0IMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwMTIzMTc1MTM1WhcNMTYwMTIzMTc1MTM1WjBhMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOklcSXpjJctM4swQtIpkHVdKUdAV1ePMF26hYjs6vPGSHhi Ud2yNpphHz58wIYuQp7MdbnuC3tA9/u3LmDjgKoUEE+FMEwV1bRnI8T31OULqnM31EK4G6kQ 3PXL8AvgFKGlW4P9KMCi1rjzR510I4t8X9qDch1DBQRt6rrKyKygUikmdZ2Xlxohwbyp1Iex eaIzrkutRslHt4Ivw9uIjuXkuJa2W86zHDEOje70DScj8Y1tKG81qJBKfCpUyh+gLm46LmWf SUygeY29P/J0v+EO/gXBUYEPOAsVxBoaZkjsFWQbJa5N4PUA3yO/PdS7H6QLrc3vuJUCmRdT F+TeXL0CAwEAAaOCAbIwggGuMB0GA1UdDgQWBBSYMw3cMZSrQDIh1QeQ97yR7UrpMzAOBgNV HQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcB AQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAn BggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQw MC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pzAgFkAgEFMCIGA1Ud JQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgED AQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBz AGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAkzFCiBBS9mIYokb/iNnS0M5W rQD9s1WXqv+5bJfLBehbmgBMGOqofV0OulGTJdX38bi9ChCOmyXnmSKzeuVbFZ/ZRxjgAGIu pxKD+tzJAzBuCsj2TIkpEyJ4VfG9/73ZAIbPvZVmHg8+DPCwyQCfF1jbybP5D9e4VfOQ3Fth eKR+SMCiJymq03qrgkL6TJ8DFrVuvw+u589CkYhGMoCW1WhzH/0UyDLQ3cJavMdH2rNtUKFK HPHNnq7wNzOtSIWZ7wo4EWAu3LUeHVyHTa+NW02JKd8y+wyUIpgmflPDzP2DkGvxbShKjjh3 /hmHF4iyZSyP6ynGJt/GyCn1z/KOJzCCBLwwggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAw VDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNV BAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0 b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8F3yZ AjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6Yp HF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO +VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mN dUwN/c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8B Af8EBAMCAYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUv b2NzcDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xM UkNBMIGSBgNVHSAEgYowgYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZI hvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQsw DQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcN AQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQ uM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5 YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+BwGKkZWe7XFIdtOId7sO p9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s6SOXMpGzvuv9oyw8 ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2Myw06w98wggOD MIICa6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJv b3QgQ0EwHhcNMDgwOTIzMTIwMDAwWhcNMjkxMjMxMjM1OTU5WjBUMQswCQYDVQQGEwJVUzEf MB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQD Ew1NSVRMTCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxU4pF1iy JrL5rYq/XBAKg93kCTATG7Bw0NGFpEJ1A3Xsr6UIIq9/1VJBOgCwDqrVsAK1lRwy/lkrHzPk obiMr1wzjQ28SR/9sg5kAcmrMqBYbc302qtwCGKZxdNdhAh2nUOCO10AMpUsCNdpikPY9ukT 8lsA+eorM4Q1rc/L0J6AHRptOU7IuDBdZj+tdNb7gv+GKknr6wj9m2sVGawoaG7AAqhsWvQU M/q4h/H5FpYlwnVAEh2AzhqiG9bwl6uJJIzJ/8uUWldNkVwz1I5fR/vCaxiLXIW4oUydBuRK TG+ekEoxHGuD73yx5JtsSciS8HQL2oEM8tv+VAC+albqgwIDAQABo2AwXjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAfBgNVHSMEGDAWgBRnqnrP 9AqmuXK1iqDSnfIQw0PtKTALBgNVHQ8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAD4bbQVg 0Hh42EpYX4/JPkNS3OUAEWR/YgzZUY1QGi9rQZ4pfcjU1/TaoNT8Y7Yf0RO+e9NiG9+BDhQH /kQiZOQo9rv9NUb8xDtKCYCad7zEQtVsYsWuvK2XLw/Ji1m2eBvoOB4RS/5LAWfNws7W+DWt 2ayzeTCyrLSrx7ZVgBjzNOm0TPIkbfppdwgxuo7FZL8ts+M2492Al87d3VasevUS1pprRBEu pChmPTt1hjtajkQOpT4BQAzP1lVEYrWzlv+O/lbP9iujKpYWcfYqQ3FGf37YCvuDeues4xm+ nqmyraNsNeI8Gh3XDIwqfzHnLhy4Y80VyqN/Jj8df3SK9AAwggTtMIID1aADAgECAgoocHoy AAAAAC0HMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTUwMTIzMTc0OTI5WhcNMTYwMTIzMTc0OTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMW TUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVt ZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMX5 Fyz2E07mG+UTRh6W2p5cZRbW7dFUwbj/ZqDonYWByw4nE5nL+b7sV5h8Kjddis2rHr/chmYN JiWfcmfHM+KicNxsrZMn3EA6haWtTKQCGBSX48I7xqENXlhzS2YzN/kxcGuy5vSdTIl4OTE5 RjYh3nwPVRXPNeH0q+Nz5kJwFEWhWICCfszOee68rxjmbsuivWgtZLE01TKn3yALgSl0cucD zI/VaqY2vTH5iyyMmASIh9kWrHwa+/Y6q0doUYeHtjr5Y5YhlQsxoBz0kkSrxy2ez2YYhGV1 /YkwVw2xqFAkOGBSymY/pzVbP06tTGyDCcZDl94ir1z/hhlgRn8CAwEAAaOCAbUwggGxMB0G A1UdDgQWBBRHSF5uTiLrTrdiekQRVfJBTJ9IUzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgw FoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5s bC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0 dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29j c3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdm hq2HFYPq8EWFtqEfHYXr0HCD6+0gAgFkAgEEMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwME BgorBgEEAYI3CgMEMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJp QGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzAN BgkqhkiG9w0BAQsFAAOCAQEAOKbnONNv+Hd5r/roM0zrBKaLVOL0XZ/b8Ct7Zrtr0T8g9d+V 6Hf2VUbu5Nqd4QkxIfMOW2QHmToNgy/+3bye1CbaMsj1p0zBxwOUpJHa4gOyIDuOh2JPFuov 9pGL5YLjJtZaFe7NJuQx6xrK3lAAqm4osCvud7B9lpbHzM+dZTWdZkFslHtwsqBRNoSJC782 UJYgUkgL3JGHN74pHjW8hr7ueJCdQA2OhgIK7fZnzGDGEriRCvm15RVQ0OgKPTbHvzUYV/AK SfGmxYSb3k5YzWJpcoIYnxyKKi6UTOSxlSsgd0iYhJpBVX5d2Ztx3c4frLx82XWZl1efyzE0 lz7+DTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMwIKKHJligAA AAAtCDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFM05G/W68PHpbjglk56Jjj2ZZYKS MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwMTE4MzM0 MFowDQYJKoZIhvcNAQEBBQAEggEARzPOugEcJVCMGpx0RFurJhpNEqz3vCL+114DakYqmp83 gpD7rf75XBqEeVWU2gL51VnTnwWg/HOfNfKjHfurx9al1ljxMvt6c5/ljEn0IzAVy5cEwMdd UugZCzPmarBpNxtPMrDZlbnvXg1pwLQuCgrOkpW+08vsOlPGE2MkSSbfS/hMLBYNXtOV2Sze BD8vI+cFZg/OVn+JHW/ISht8HipeDk8MFn6SVF699eseZ43gYMNGsxyHbse0A9OkiPchyIz9 Rqiv/nITSr7HLiEm0VkukH3Cr7XYLISvKBoy/nX1plvHpUrHfIgFNlnhDJAJo5D98YRSbInQ 5NaW2l9kbg== --B_3510743620_71962288-- From nobody Wed Apr 1 11:43: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 69AB91A1A14 for ; Wed, 1 Apr 2015 11:43:24 -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 mMbueXYt8z0u for ; Wed, 1 Apr 2015 11:43:23 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::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 F39EA1A1AA8 for ; Wed, 1 Apr 2015 11:43:22 -0700 (PDT) Received: by qcrf4 with SMTP id f4so36519758qcr.0 for ; Wed, 01 Apr 2015 11:43:22 -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=NVG6aohHQIOrDiUQzKyoPcgU7oz7A38ptuC6djskGzg=; b=Va1IulANRQjPABnQfqpUMTh/gq4axzu8pftpSxcpOZtL4Iucm6QQxde4kLLaH3O3Ta MQsKbdtGG+NWUbw3FTRhs3eFBJpIKoZ805h9f9O8Qsln1Dp7GwZBURA0zIahh1jTiIc7 W9dpmtHRDH+iRBsA77mXauqTHT7eB09wXt/uHWm2lzKKQHA3bbY7RQeqnjCg4vAjkQrK 5umKetBKSUxTmsi4+t5pX8hIv/aUvexTQb1yt76JL49j480fZisUuDYPfzkr9Brr90mc NgaxwBcW5zOMiSsm2qkkhGrNiYZyzF5wFsupo5AdVQjYJ0O1ltHiV3B5wZVvIE95/8qh aQ8w== X-Received: by 10.140.81.242 with SMTP id f105mr55693822qgd.33.1427913802316; Wed, 01 Apr 2015 11:43:22 -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 q193sm1825540qha.14.2015.04.01.11.43.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Apr 2015 11:43:21 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 1 Apr 2015 14:43:20 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-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: <201504011443.20607.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 18:43:24 -0000 On Wednesday, April 01, 2015 02:12:19 pm Joseph Salowey wrote: > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 Some of us would rather have both be MTI in order to force the cipher ecosystem to not be entirely reliant on AES. (there was discussion prior on-list) I don't think a SHOULD is unacceptable, though. > o Hash: > MUST SHA-256 Can we add an official MUST NOT for MD5? I assume this is generally wanted. > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 I think Curve25519 should be a MUST at this point. I think TLS 1.3 should have an MTI curve that can pass the safety guidelines on safecurves.cr.yp.to, as this topic does get brought up from time to time. (P256 probably should be MTI too) The entire point of the CFRG drama is to get better standardized curves to replace things, so I think it's reasonable to require support. > o Signature: > MUST ECDSA P-256 > MUST RSA Any consideration for whatever CFRG wants to add here? (I don't have an opinion on the subject; just asking) That said, the current proposal is straightforward and not unreasonable. However, I argue that adoption of relatively new standards with TLS 1.3 should not be considered optional. Dave From nobody Wed Apr 1 11:53: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 CCB181A8881 for ; Wed, 1 Apr 2015 11:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcvucdgeSWG9 for ; Wed, 1 Apr 2015 11:53:12 -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 E4E211A886B for ; Wed, 1 Apr 2015 11:53:09 -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 t31Ir7O9059803; Wed, 1 Apr 2015 14:53:07 -0400 Date: Wed, 1 Apr 2015 14:53:07 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Sean Turner Message-ID: <1082369316.6361228.1427914387267.JavaMail.zimbra@redhat.com> In-Reply-To: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [94.112.138.148, 10.5.101.182] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: confirming the =?utf-8?B?cm9vbeKAmXM=?= consensus: adopt HKDF PRF for TLS 1.3 Thread-Index: T4JENAzDlqDpBcUXUQEtkSX7gFLrZA== Archived-At: Cc: tls Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 18:53:19 -0000 ----- Original Message ----- > This message is to confirm the consensus reached @ the IETF 92 TLS sessio= n in > Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an > HKDF-based PRF (see > http://datatracker.ietf.org/doc/rfc5869/?include_text=3D1). > Please indicate whether or not you agree with the consensus by 2015-04-17= . > If not, please indicate why. Also, please note that we=E2=80=99re intere= sted in > uncovering new issues not rehashing issues already discussed. I believe the question is totally unwarranteed. No-one has presented any ar= gument on why the TLS PRF is not sufficient for its purpose. The only arguments pr= esented are theoretical advantages of HKDF, which are fine, but do they add value t= o TLS? Does the advantages of HKDF translate into weaknesses of the TLS PRF? So no matter the output of that poll the result will be an uneducated guess= . In all cases it is alarming to see the easiness with which the protocol is being rewritt= en completely. Now its only similarity with TLS 1.2 is the TLS acronym. Would that rewrite= bring value in par with the efford needed for the rewrite? Would it make us safer in 20= 30 or are we simply apply yesterday's technology today? regards, Nikos From nobody Wed Apr 1 11:53: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 C1EE31A8867 for ; Wed, 1 Apr 2015 11:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHRTCc4YTU_s for ; Wed, 1 Apr 2015 11:53:33 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id B85781A86FA for ; Wed, 1 Apr 2015 11:53:32 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 35D8D9A401B for ; Wed, 1 Apr 2015 14:53:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id UJEptQvycibD for ; Wed, 1 Apr 2015 14:53:01 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4EE479A4019 for ; Wed, 1 Apr 2015 14:53:01 -0400 (EDT) From: Russ Housley Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-150-783088006 Date: Wed, 1 Apr 2015 14:52:50 -0400 In-Reply-To: To: IETF TLS References: Message-Id: <1C371A88-3F53-40F3-89F9-C04FC592DF3E@vigilsec.com> X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 18:53:34 -0000 --Apple-Mail-150-783088006 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii This seems fine to me for the roughly 128-bit strength. Russ On Apr 1, 2015, at 2:12 PM, Joseph Salowey wrote: > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 > > o Hash: > MUST SHA-256 > > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 > > o Signature: > MUST ECDSA P-256 > MUST RSA --Apple-Mail-150-783088006 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = seems fine to me for the roughly 128-bit = strength.

Russ


<= div>On Apr 1, 2015, at 2:12 PM, Joseph Salowey wrote:

o = Symmetric:
        MUST AES-GCM 128
  =       SHOULD ChaCha20-Poly1305

o Hash:
  =       MUST SHA-256

o Key Agreement: ECDH
  =       MUST P-256
        SHOULD = 25519

o Signature:
        MUST ECDSA = P-256
        MUST = RSA

= --Apple-Mail-150-783088006-- From nobody Wed Apr 1 12:11: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 DACC41A1C06 for ; Wed, 1 Apr 2015 12:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 CppYqzo04pUE for ; Wed, 1 Apr 2015 12:11:09 -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 4AF351A1A65 for ; Wed, 1 Apr 2015 12:11:09 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 078D328547; Wed, 1 Apr 2015 19:11:08 +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 CDF042854A; Wed, 1 Apr 2015 19:11:07 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id C9F792027; Wed, 1 Apr 2015 19:11:07 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 1 Apr 2015 15:10:31 -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.0913.011; Wed, 1 Apr 2015 15:10:31 -0400 From: "Salz, Rich" To: "" Thread-Topic: =?Windows-1252?Q?[TLS]_confirming_the_room=92s_consensus?= Thread-Index: AdBsr4ELtwNNv7UPQ8uleZgWmjLksg== Date: Wed, 1 Apr 2015 19:10:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.57.153] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 19:11:11 -0000 I was at the Seattle interim and the Dallas meetings and agree with both co= nsensuses. Consensii? From nobody Wed Apr 1 12:14: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 C73BD1A884C for ; Wed, 1 Apr 2015 12:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo74zMOC0dwk for ; Wed, 1 Apr 2015 12:14:44 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 678571A883A for ; Wed, 1 Apr 2015 12:14:44 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D873A1FE01F0; Wed, 1 Apr 2015 12:14:43 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 1 Apr 2015 12:14:44 -0700 (PDT) Message-ID: In-Reply-To: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> Date: Wed, 1 Apr 2015 12:14:44 -0700 (PDT) From: "Dan Harkins" To: "Sean Turner" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?iso-8859-1?q?confirming_the_room=92s_consensus=3A_adopt_H?= =?iso-8859-1?q?KDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 19:14:45 -0000 On Wed, April 1, 2015 11:00 am, Sean Turner wrote: > This message is to confirm the consensus reached @ the IETF 92 TLS session > in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an > HKDF-based PRF (see > http://datatracker.ietf.org/doc/rfc5869/?include_text=1). > > Please indicate whether or not you agree with the consensus by 2015-04-17. > If not, please indicate why. Also, please note that were interested in > uncovering new issues not rehashing issues already discussed. I agree with the consensus to adopt HKDF. Dan. From nobody Wed Apr 1 12:18: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 F0F2D1A8849 for ; Wed, 1 Apr 2015 12:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W12g1GztUYAp for ; Wed, 1 Apr 2015 12:18:18 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E6CBC1A1AA8 for ; Wed, 1 Apr 2015 12:18:17 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6FD261FE01F0; Wed, 1 Apr 2015 12:18:17 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 1 Apr 2015 12:18:17 -0700 (PDT) Message-ID: <8cb95e7b078f533847934a9342491490.squirrel@www.trepanning.net> In-Reply-To: References: Date: Wed, 1 Apr 2015 12:18:17 -0700 (PDT) From: "Dan Harkins" To: "Joseph Salowey" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 19:18:19 -0000 On Wed, April 1, 2015 11:12 am, Joseph Salowey wrote: > We did not get a chance to talk about MTI algorithms in Dallas, but the > chairs would like to judge consensus for the algorithms discussed in the > interim. The CFRG has closed or will close soon on ChaCha20 and curve > 25519 recommendations so they are included. We will be calling for > acceptance to bring drafts on these into the working group shortly. > > Keep in mind that mandatory to implement (MTI) is not mandatory to use and > that it is expected that there will be profiles for specific environments. > > Below is the proposed algorithm list that had consensus at the Seattle > Interim. Please reply on the TLS mailing list indicating whether or not > you > agree with the consensus. If not, please indicate why. This consensus > call will close on April, 23, 2015. > > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 > > o Hash: > MUST SHA-256 > > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 > > o Signature: > MUST ECDSA P-256 > MUST RSA I agree with this consensus on MTI algorithms. Dan. From nobody Wed Apr 1 12: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 628241A8A76 for ; Wed, 1 Apr 2015 12:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.6 X-Spam-Level: X-Spam-Status: No, score=-101.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWrQbSHMn6-Y for ; Wed, 1 Apr 2015 12:20:33 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4E71A1AA8 for ; Wed, 1 Apr 2015 12:20:16 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 044C29A401B for ; Wed, 1 Apr 2015 15:20:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id x0RrQhXrBMnS for ; Wed, 1 Apr 2015 15:19:45 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 0BFB89A4021 for ; Wed, 1 Apr 2015 15:19:45 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> Date: Wed, 1 Apr 2015 15:19:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> To: IETF TLS X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 19:20:34 -0000 The hum in the room showed overwhelming support for HKDF. One detail that was not discussed because we were running out of time is = important to me (and may be important to others). SHA-256 would be the = MTI. Is an alternative hash function chosen based on the cipher suite = or some other mechanism? Russ On Apr 1, 2015, at 2:00 PM, Sean Turner wrote: > This message is to confirm the consensus reached @ the IETF 92 TLS = session in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 = PRF be an HKDF-based PRF (see = http://datatracker.ietf.org/doc/rfc5869/?include_text=3D1). >=20 > Please indicate whether or not you agree with the consensus by = 2015-04-17. If not, please indicate why. Also, please note that we=92re = interested in uncovering new issues not rehashing issues already = discussed. >=20 > Thanks - J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 1 12:25: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 F0C591A883C for ; Wed, 1 Apr 2015 12:25:08 -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 bXzvB7qSp_nk for ; Wed, 1 Apr 2015 12:25:05 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (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 5C2F81A036E for ; Wed, 1 Apr 2015 12:25:05 -0700 (PDT) Received: by wgoe14 with SMTP id e14so63800775wgo.0 for ; Wed, 01 Apr 2015 12:25:04 -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=2VYnPQR8qperRvnFGi/UzMKAK2Vq9We9z12yNlJ42HI=; b=Tu8hKXhxArdVPa3F/SBaJav9wD6M3dVCduQWv1E9M0CRNEdbaOWBV7sjX5dfeZOKlc xEy810olOeqWwpS9rwxvlv9QRw9kMmf/gDrGT7rA69L35jXNGII3SNVPvG8FHAjI85sw SxxgYFZLKJXnVoBqDKeJUne9cZx7wCZ1tBJw8N0DswzMeAgnN1qxi80IZKpB5/KiRbnf Xf7wsqKWxAzD5ATJa/kcgnG1UC0+b9kTFe3UorwKe4x1UpO7YZAvxu6Su5c5X0IK7UAi wbHNxFLlaekUxxSVcNAQlPw6GTke4gVkhNMCwpIQpVmCmfaUwGlSQINC/ADgvxiTt/6s jepg== X-Gm-Message-State: ALoCoQn3HvTZ1fAItPdPuuqNrwN8UB9Cb1EeuKv6HDv8HCQvBXaobCrzTQcNpWuSMz0hwSKSrtb7 X-Received: by 10.180.108.81 with SMTP id hi17mr17639924wib.91.1427916304107; Wed, 01 Apr 2015 12:25:04 -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 u16sm4010011wjr.5.2015.04.01.12.25.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 12:25:03 -0700 (PDT) Message-ID: <551C460A.9060507@azet.org> Date: Wed, 01 Apr 2015 21:24:58 +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="------------enig2447D9030D85F10C4843DBA2" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 19:25:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2447D9030D85F10C4843DBA2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 >=20 > o Hash: > MUST SHA-256 >=20 > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 >=20 > o Signature: > MUST ECDSA P-256 > MUST RSA >=20 +1 for MUST on ChaCha and Cuve25519. Aaron --------------enig2447D9030D85F10C4843DBA2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVHEYLAAoJEOTbZJL9ubXV5QUQANtNNHIPxcIGnPgkklyHpT+S LdZ8e6IqFqmdc4/qd2JfPNRLyokGBx67tTbTIWhQ9qn+juoUGMX+IUYxxhrgUfID hPvFlLNfWBpgG3F4GaYKC8XoTCZ5pFRPzzJX93gX/f9mIhnBhojps0omoJL9wYD1 uNozM4XpSW84Vq4MlE5qwbnB+3n3QA/S00kzfBvMW3C6iC5aqReccftkjyFEMGL/ INop+kjDf1zFkQ4LhLPXnvYC6M55g8LSDODJ87X6xtAY0fSghElkWu4aTmlbEpWS vj4wxBqV0HWw0sE80sqX8Z7Qi8x0bIf+SavSolcs8o0JT9xGlseU0ysnFoIBOych CiO6K5iW9mEyjFUvplpqJgQu9BTJXdqw0Y3GV947N1qJ3rdT8+0cMFtPSJ1rkYX6 fuv0EeNajjlSq8eDBzMbf9VVMddOVvsGplfRBdEKyfyLXcn3+PET+Po6e3KQbQNy V6I/FdLK7SayckfUHORnWUWUalTXuEyAGecPw/EIMRa/UJDKy+DVtIXNAXwq6Td1 yHbueWtbgRbFqJYjeazScVcoCQzCg3PFk0wq+aldCmP+lX4gjobyKGiA8lACH/W9 R/+1t48cRNd5YmSJMRr0ZksasiW/646ojOmFZqN5PG9TFIc6HkWfZHusjuCJj6pW FqVSlwA20HsZ8cl2hoHO =8ctW -----END PGP SIGNATURE----- --------------enig2447D9030D85F10C4843DBA2-- From nobody Wed Apr 1 12:32: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 E384A1A1B85 for ; Wed, 1 Apr 2015 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs-FIVDN4em2 for ; Wed, 1 Apr 2015 12:32:22 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (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 BF7451A1A7C for ; Wed, 1 Apr 2015 12:32:22 -0700 (PDT) Received: by obbec2 with SMTP id ec2so94841415obb.3 for ; Wed, 01 Apr 2015 12:32:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YhqIgmNIcHEREXcCoPaoMflO0r0egOt2ojbtjwlWByI=; b=hxEKRlLgv7BjsAKLq8/ojakNFYHvmbMgs3AQefkg63MxSHJroauqWDIRgKA04tH/7v lF7InfFzRlNCi6kqedB2fj2kemqwZjAarfCwwRpLCc+9HOv2jHscS/3s02PMOprBVoIo NMJ0B+YMzRuifhnxb+I5g3XOOd8HGBXWs7r3azAZG0UGETWo/zouYxqeYRtFvOTIeRXg xGc78diIET1xC+OWrwITjCTWoop2oaCZ8irfPpaTIdiTDRFM6T9PSCDT3UA48FfYgaj1 d8Od/GBHIKPUHMjTYPqBh8tqXF+KjOuIixBp+lCw6CrIhgIOPBM7BpeNBkHtzxE/tlrF 3mCQ== X-Gm-Message-State: ALoCoQk0VxfeKDguq9z7uvOtmN1rnIrdTnR2XyHvaGYU/VxtBNjEk6/uA+fiZLlN4HYzP8MNmtS6 MIME-Version: 1.0 X-Received: by 10.182.230.132 with SMTP id sy4mr42717724obc.29.1427916742247; Wed, 01 Apr 2015 12:32:22 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Wed, 1 Apr 2015 12:32:22 -0700 (PDT) In-Reply-To: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> Date: Wed, 1 Apr 2015 09:32:22 -1000 Message-ID: From: Brian Smith To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 19:32:24 -0000 Sean Turner wrote: > This message is to confirm the consensus reached @ the IETF 92 TLS sessio= n in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an= HKDF-based PRF (see http://datatracker.ietf.org/doc/rfc5869/?include_text= =3D1). > > Please indicate whether or not you agree with the consensus by 2015-04-17= . If not, please indicate why. Also, please note that we=E2=80=99re inter= ested in uncovering new issues not rehashing issues already discussed. There's a lot of ambiguity in what "HKDF-based" means. I agree that new versions of TLS should use HKDF-Extract, then HKDF-Expand, with suitable parameters, as recommended in RFC5869, to build the keyblock that will be partitioned into keys. I also agree that TLS extractor should use HKDF in a similar way for new versions of TLS. Cheers, Brian From nobody Wed Apr 1 12:47: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 89A281A8825 for ; Wed, 1 Apr 2015 12:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omgkAFGY_hyE for ; Wed, 1 Apr 2015 12:47:31 -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 9611F1A8702 for ; Wed, 1 Apr 2015 12:47:31 -0700 (PDT) Received: by wgra20 with SMTP id a20so64494683wgr.3 for ; Wed, 01 Apr 2015 12:47: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=JccWjyl/HShCZrtzMheR2Hmq6EVtYBmYoqlI7LoYnCk=; b=FY9HUUT/jKI/A7QeilB8Kp1eQhI+ilrwVSjTt/BasW17My4XOopYbv9ghae2xSdKzv t6z/pBIyC9doNQJn4Fuyj/nxSFA5+LLl/Ajyd4XLODTXSvNoakiBv+vfNlqTKfdQu5+w AYdlqRFcJ4naFDxGhgfsRa8eFTaMMqrEQojDgjP2irkWvvIYTt0imSc+mzcnI6I5vfFS VqwzaX0B07fjKMaoOO1XDevf7ZdhX1AmqV/BKPnoY/fOTFNvpCyjQFPCBd1ja8iWEF95 g4a4Bm7C2d3iZDn/V2N3tNEATyVtIf/vMDO9cZNZd037oJHGIDWLMsuafUUq7tW39FTu CzLg== X-Gm-Message-State: ALoCoQmcRrXA3DEivrhufj8lBWLd+SBo5tZZivFox6Xx2WqYn0hMIaSYxj0tmhaKRkCgEEGMhjhk X-Received: by 10.180.104.66 with SMTP id gc2mr18086508wib.34.1427917650368; Wed, 01 Apr 2015 12:47:30 -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 xy2sm4072934wjc.14.2015.04.01.12.47.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 12:47:29 -0700 (PDT) Message-ID: <551C4B4D.1000705@azet.org> Date: Wed, 01 Apr 2015 21:47:25 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: =?UTF-8?B?SGFubm8gQsO2Y2s=?= References: <20150401201221.163745c2@pc1.fritz.box> In-Reply-To: <20150401201221.163745c2@pc1.fritz.box> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB512D68698D5C973367FCB6F" Archived-At: Cc: "" Subject: Re: [TLS] 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: Wed, 01 Apr 2015 19:47:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB512D68698D5C973367FCB6F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Hanno, TLS-WG, Hanno B=C3=B6ck wrote: > Proposal: DSA should go away and not be part of TLS 1.3. >=20 I concur, let's get rid of DSA as soon as possible. I don't see a reason why it should be in the 1.3 spec either. Aaron --------------enigB512D68698D5C973367FCB6F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVHEtOAAoJEOTbZJL9ubXVQR8QAK0B8U4m1s9mY4DZnoVS56WU Y3AxDBOJBEt5G2ivKKNRZNuJdwVjzAqcudcL9xWevJuOpGTOY+wMt9pLSZWiEFPy VYX/7AFUw81u7Jsk1YX0kdTjVxc4jD6QWCMHxG11Bv6D5Mgc8pQ9yaV61ZrsRKpQ D2Rq7qPpHU7DSloI2+bjCd72p6H410W6coXmmIB0xwUKZ0o/Uv1R1tZBakgIycKF F9GC4lrm2pODRAIBD9HrhCG1YEyNgXzaWz5DbhvrzB/2MX6aTIOHEPcSqrNgvXCu AI+eReKwuFt4tZIKxiTYfUyUDH3CmJwu99RWRMaEdlaS0/fN2qhdxzHLC3yrnj5O pq2fqlETdphabKvEjUKXwnx30qZ8MXit8k1FszbPmYdkYyJQur6rv7ZVaSZX1VVz gnAbZFk2hstmVETMquGVTIF3bmzP/jcWTjAwzzIWfMYhTGJtWZ8YmmViWZzsCl13 USoLEkMfRecjn4sKYOvkH34cLnowAJfwz1tP86bT0Fdx7SZRPZ/NqI99JmhsKPo6 LfOYkT07BchMck0x6Wmqgqs1B7XxhP53cVdfeJ18dB8peZLc+7D5xOd99xBf6Szp QqY8KFd5m/wWrgoz0sh29yrTiGIyPdO+QraCxE7b9UeRT+8ZAMgG6qluaMqmJ/kT xB8xoVG2uht/ILoRdHnH =hYef -----END PGP SIGNATURE----- --------------enigB512D68698D5C973367FCB6F-- From nobody Wed Apr 1 12:48: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 DB2821A8A5E for ; Wed, 1 Apr 2015 12:48:03 -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 tGB-5yP0BOXN for ; Wed, 1 Apr 2015 12:48:01 -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 83AF71A8732 for ; Wed, 1 Apr 2015 12:48:01 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 0562A1C208B; Wed, 1 Apr 2015 21:47:59 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id DB6CB1FE0574; Wed, 1 Apr 2015 21:47:58 +0200 (CEST) Date: Wed, 1 Apr 2015 21:47:58 +0200 From: Kurt Roeckx To: Joseph Salowey Message-ID: <20150401194758.GA13326@roeckx.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 19:48:04 -0000 On Wed, Apr 01, 2015 at 11:12:19AM -0700, Joseph Salowey wrote: > Keep in mind that mandatory to implement (MTI) is not mandatory to use and > that it is expected that there will be profiles for specific environments. I'm confused why we need a mandatory to implement when profiles might decide to use something different. Kurt From nobody Wed Apr 1 12:48: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 4AD4C1A8A10 for ; Wed, 1 Apr 2015 12:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 VtstSQx3glso for ; Wed, 1 Apr 2015 12:48:52 -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 A41A61A8AA0 for ; Wed, 1 Apr 2015 12:48:52 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 3AF0D9001A; Wed, 1 Apr 2015 22:48:50 +0300 (EEST) Date: Wed, 1 Apr 2015 22:48:50 +0300 From: Ilari Liusvaara To: Russ Housley Message-ID: <20150401194849.GA22718@LK-Perkele-VII> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> 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 Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s__consensus=3A_adopt?= =?utf-8?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 19:48:55 -0000 On Wed, Apr 01, 2015 at 03:19:33PM -0400, Russ Housley wrote: > > One detail that was not discussed because we were running out of > time is important to me (and may be important to others). SHA-256 > would be the MTI. Is an alternative hash function chosen based on > the cipher suite or some other mechanism? In TLS 1.2 and 1.3-current, the main PRF-hash is designated by the ciphersuite. I have not seen any proposals to change this. Then there is signature hash, which is negotiated using extensions. -Ilari From nobody Wed Apr 1 12:53: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 DDBB11A903D for ; Wed, 1 Apr 2015 12:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.212 X-Spam-Level: * X-Spam-Status: No, score=1.212 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, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, 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 RGnmfY6mPhwo for ; Wed, 1 Apr 2015 12:53:19 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::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 6C1711A9025 for ; Wed, 1 Apr 2015 12:53:19 -0700 (PDT) Received: by iedm5 with SMTP id m5so52710506ied.3 for ; Wed, 01 Apr 2015 12:53:18 -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 :content-type; bh=t7399b/pXF/6X/swXFrcpmeZfK2PPufYwupvzdghvyk=; b=JjGqsQBTgqkQWuUXIUJ6Su1NnoZ5g74QDIhV133523rBAA2+8MLcmCj85XL1+OUbd1 eAj7NgXIDji5EUzLHiE5yq3N/jgYQMUZ6F5M09ZxF2vJEK4mNBjwFKv6vcad0RilU+Lc smOw58x4BceLNSjkpkgP5NNjgvtODBIeN9AK0= 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:content-type; bh=t7399b/pXF/6X/swXFrcpmeZfK2PPufYwupvzdghvyk=; b=GQfyBQBKY4Gmz0TOMknlvA1MgzZHWHhsLvuxpuaZppt8D+iC39JfqTK8uPaQKw6YD1 S5pB28pacKfFzeJqrs2BBe7m4Bij9cssSNizd1fHa7Nfa34YxV0iqWMyCtijm4oMmjYT rCG8jEJk7RNMSpn8wrETsMtkA/uxD9FAtJh6RUC5UsmroNxhx+XL9k7HfOVm3VkxYUt1 tkWYGqNQKZ6UQGhMvFn4YsdLN4gNk5SHQKURcJzglMYaUUEj8GKsQ4uV7ztVmkYL8DKY E/iOeKpn4woAu4hxSibX49nZPx+3QNbAe9jJTRl0L6NlNDvwor/Yl73gJheM5qNTeBob Hv3Q== X-Gm-Message-State: ALoCoQl5dhvE1la9NLgisyA7kVZuKuwB4G3T5sdGpdOdrKZyh8d8mVYvDf1oyrnOdiKYsyo/+68B X-Received: by 10.42.88.206 with SMTP id d14mr76246991icm.40.1427917998681; Wed, 01 Apr 2015 12:53:18 -0700 (PDT) MIME-Version: 1.0 References: <20150401201221.163745c2@pc1.fritz.box> In-Reply-To: <20150401201221.163745c2@pc1.fritz.box> From: David Benjamin Date: Wed, 01 Apr 2015 19:53:18 +0000 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= , "" Content-Type: multipart/alternative; boundary=90e6ba3fcb83149ab90512af11c8 Archived-At: Subject: Re: [TLS] 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: Wed, 01 Apr 2015 19:53:21 -0000 --90e6ba3fcb83149ab90512af11c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable DSA has also been removed from Chrome, so that's two major browsers. (Chrome/Android saw it gone in October and Chrome/Windows last month.) There's been a couple reports of servers using self-signed DSA certs for some reason, but otherwise nothing. Before that, usage was in the noise. Seems a safe thing to prune. David On Wed, Apr 1, 2015 at 2:12 PM Hanno B=C3=B6ck wrote: > Hi, > > Mozilla just removed DSA support from Firefox. It seems the use of > (non-ecc) DSA in TLS is pretty much nonexistent. Still the TLS 1.3 draft > contains DSA. > > Proposal: DSA should go away and not be part of TLS 1.3. > > Reasons to remove DSA: > * DSA with 1024 bit is considered weak and DSA with more than 1024 bit > is widely unsupported. > * DSA has comparable security to RSA (it using same keysize) which is > the de-facto-default. Given that everybody uses RSA and nobody uses > DSA having the latter only adds unneccessary complexity. > * DSA can fail badly with bad random number generators. > > Some numbers: > In the 2013 https ecosystem scan there were 17 DSA keys on public IPs, > none of them CA-trusted: > http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf > > I think it's safe to say nobody will care if DSA is removed. > > cu, > -- > Hanno B=C3=B6ck > http://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: BBB51E42 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --90e6ba3fcb83149ab90512af11c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
DSA has also been removed from Chrome, so that's two m= ajor browsers. (Chrome/Android saw it gone in October and Chrome/Windows la= st month.) There's been a couple reports of servers using self-signed D= SA certs for some reason, but otherwise nothing. Before that, usage was in = the noise. Seems a safe thing to prune.

David

On Wed, Apr 1, 2015 at 2:12 PM Hanno B=C3=B6ck <hanno@hboeck.de> wrote:
Hi,

Mozilla just removed DSA support from Firefox. It seems the use of
(non-ecc) DSA in TLS is pretty much nonexistent. Still the TLS 1.3 draft contains DSA.

Proposal: DSA should go away and not be part of TLS 1.3.

Reasons to remove DSA:
* DSA with 1024 bit is considered weak and DSA with more than 1024 bit
=C2=A0 is widely unsupported.
* DSA has comparable security to RSA (it using same keysize) which is
=C2=A0 the de-facto-default. Given that everybody uses RSA and nobody uses<= br> =C2=A0 DSA having the latter only adds unneccessary complexity.
* DSA can fail badly with bad random number generators.

Some numbers:
In the 2013 https ecosystem scan there were 17 DSA keys on public IPs,
none of them CA-trusted:
http://conferences.sigcomm.org/imc/2013/p= apers/imc257-durumericAemb.pdf

I think it's safe to say nobody will care if DSA is removed.

cu,
--
Hanno B=C3=B6ck
http://hboeck.de/

mail/jabber: hanno@hbo= eck.de
GPG: BBB51E42
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--90e6ba3fcb83149ab90512af11c8-- From nobody Wed Apr 1 12:56: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 554F51A9044 for ; Wed, 1 Apr 2015 12:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 AZ-G1-x6Hl07 for ; Wed, 1 Apr 2015 12:56:47 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7321A9041 for ; Wed, 1 Apr 2015 12:56:46 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so90998586obb.1 for ; Wed, 01 Apr 2015 12:56:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Yt7H7qcVqT0p+GWC4bVIZbDffGJsu7P6lE7OJ5wubD8=; b=DQhfkneGtpOVG8J+6ipusC555Gs4fuayW9qTwMn/OAXg+U2DS5twlTM+U95njxc2nr MQ7s0Ffb5AfRAnagJ0AG2UzhXSksijxlTbECeX02PQPSlXtSIzi/iqbHm2leM18dLIwp dXSRin+nKet0xiKnzLSIQ5dQ48CvWjCEu5HIFlOJe7Ohe83aEFSVhRAYFqmGwmT0GB3n xkq1tbSh4eSpp/1BYq+wVd0CW2LiQs2w038DV6kXSXznEuthE8xN2km+kheEy8OaYGsj iUfT1tB18H9Dfny6uixuBFnfDlV7t0tWJS2BWSWSFC9kCEWGPKIxM/AvzLYZdrgpN3Ar gr/Q== X-Gm-Message-State: ALoCoQmwIs8M3+ltADCbwjYlHaDd1CaQLvhXxkzX809GnJ81Djuz5b9XyXZxMwRcLN/leU/8C5aA MIME-Version: 1.0 X-Received: by 10.60.139.1 with SMTP id qu1mr42419228oeb.83.1427918206275; Wed, 01 Apr 2015 12:56:46 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Wed, 1 Apr 2015 12:56:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Apr 2015 09:56:46 -1000 Message-ID: From: Brian Smith To: Joseph Salowey Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 19:56:48 -0000 Joseph Salowey wrote: > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 Like others, I think that ChaCha20-Poly1305 should be MUST. It uses 256-bit keys and so it better protects against future quantum and square-root attacks compared to AES-GCM 128. Also, it is easy to make a constant-time implementation of ChaCha20-Poly1305 that runs on a wide variety of hardware, but it is not to easy to do so for AES or GCM on many times of hardware. Accordingly, I suggest instead that ChaCha20-Poly1305 MUST be implemented unless AES-128 GCM *and* AES-256 GCM are implemented in a constant time manner. > o Hash: > MUST SHA-256 AFAICT, it is not necessary to specify a mandatory-to-implement hash function separately from the mandatory-to-implement cipher suites and mandatory-to-implement signature algorithms, because the hash function to use is always a function of the cipher suite or signature algorithm in TLS 1.2 and later. > o Signature: > MUST ECDSA P-256 > MUST RSA "RSA" is ambiguous. For RSA, please specify which padding scheme(s) and which parameters must be supported. I would recommend "MUST implement RSA PKCS#1 using the same digest function used in the PRF of the selected cipher suite." Similarly, "MUST ECDSA P-256" should be changed to "MUST ECDSA P-256 using the same digest function used in the PRF of the selected cipher suite." If the requirements for mandatory-to-implement signature algorithms are intended to also apply to certificates and certificate verification, then ECDSA P-384 and SHA-384 MUST be implemented. The reason is that CAs often choose algorithms for signing certificates. Cheers, Brian From nobody Wed Apr 1 13:16: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 C000D1A908A for ; Wed, 1 Apr 2015 13:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 o8chee2fNXRh for ; Wed, 1 Apr 2015 13:16:04 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (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 0161F1A90CE for ; Wed, 1 Apr 2015 13:16:04 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so12587821obb.2 for ; Wed, 01 Apr 2015 13:16:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=toAxL1zZNEkKbhNeqXHgn3I83n0yE5nt/CJAKHh2x1w=; b=Vl4pWyaZSx72DUT4g/HVQG03pgorz/KNt5PT6WUyLilWYkwcOYNNmEHsDO/pl9IrSC KcMY78n4Q1ZBMF9iRjI3dfPRDMuZ1c2Y1jNQ6Py3izZx7adPKzyLbkyLhOaUsdSkhpHz 2lUWSyW6broTh9BojREO9mnJziCyeCrwvyiYeECBOraFYUBwWL3vAID4VhZQsCvT6Spr FBKxBj2mYxIVgZ5r8ogsToaqOhok4SdFIg0cpB1TrqgPdiQz2ZtD4MzPA/UjMTCl39B6 51ixIJUmWhX+rTZfAKApJZSHez3VGDb7qBKU1DBA7JGeOCkS+pzG2iW9ppl5q35vjjS2 fujw== X-Gm-Message-State: ALoCoQl5kE5NdBn1fAuEQA+A6KQehB6aqDclfyEvYOh7MPkjxRns3awk/hJbcdk/GeesIc5OKeQg MIME-Version: 1.0 X-Received: by 10.182.66.79 with SMTP id d15mr32147276obt.58.1427919363505; Wed, 01 Apr 2015 13:16:03 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Wed, 1 Apr 2015 13:16:03 -0700 (PDT) In-Reply-To: References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> Date: Wed, 1 Apr 2015 10:16:03 -1000 Message-ID: From: Brian Smith To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 20:16:09 -0000 Martin Thomson wrote: > On 31 March 2015 at 19:33, Brian Smith wrote: >> >> 4. The references to (FF-)DHE key exchange being acceptable for False >> Start are removed. Although it may be possible to safely implement >> False start for FF-DHE, the current draft isn't a good starting point >> for specifying how that might be done. It's better to remove the >> references until an adequate description of doing False Start for >> FF-DHE key exchange is available, if ever. > > I agree with most of what Brian says, particularly with respect to > only accepting the "best" profile of TLS here. However, I am > generally leery of making specific recommendations regarding cipher > suite choice. With the explicit groups, this might be OK. Without > explicit groups, I think that Brian's point is completely valid. Implementing the negotiated FF-DHE mechanism as specified definitely isn't sufficient and may not be necessary for doing False Start with FF-DHE cipher suites: 1 The negotiated FF-DHE spec still allows the client to use FF-DHE parameters that it didn't send, in order to interop with implementations, as long as it has some "policy" for handling that case. For False Start, such a policy would have to be defined. 2. As I noted in the Firefox bug, even if the client only does False Start with parameters it advertised in its FF-DHE extension, there is still potential for material downgrade if the weakest FF-DHE parameters it advertises are weaker than the ECDHE curves it supports. 3. Even if the client doesn't implement ECDHE at all, the weakest FF-DHE key it offers during FF-DHE parameter negotiation may not be strong enough to do False Start. Given the research I did for Firefox that showed that any reasonably definition of "strong enough" is practically equivalent to disabling False Start for FF-DHE, it seems not to be worthwhile to bother trying to define "strong enough." Cheers, Brian From nobody Wed Apr 1 13:19: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 240F91A909F for ; Wed, 1 Apr 2015 13:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-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, GB_I_LETTER=-2, 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 WKvc3rtf18XJ for ; Wed, 1 Apr 2015 13:18:58 -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 AD4D31A90C1 for ; Wed, 1 Apr 2015 13:18:47 -0700 (PDT) Received: by qgeb100 with SMTP id b100so12442851qge.3 for ; Wed, 01 Apr 2015 13:18:47 -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=LsoEk5peXk4fAk8Tw5xOtdaZAEZPsmaAWoVYRweRVmA=; b=Ir3H/asRjZNRLCTWJfVX7c6aGEL0U0LGUBRT51zGYkqzxnUMgXBnMXlJVby1QhAMzU RM+Mj2U0Hg9sLV0FnqWCAqAVcSePNILx1ZMTLKCi1g/eyiR2jPnOjVW3TpqE8gDqf6iE EkIA675hefFGlwzyslRvJKAltm2xKI7aJ7mshL7HZWljme69POftcFZ+xlm95JEfE7jQ WlR2LjifYW9hCOVQIGjiMv0v/LA+8tM4FAp8xw1L37PrqO0NM6BpYVkz9LYDrCAlMuKg X+xGRA6O2/LDgGfxmVIZuLD03MQVKgtDe1Ts1kikqh9CoqTBU31jg7Z3xDXY8/5b1rBk SnSg== X-Received: by 10.55.42.39 with SMTP id q39mr90232378qkh.99.1427919526919; Wed, 01 Apr 2015 13:18:46 -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 b52sm2007747qgb.16.2015.04.01.13.18.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Apr 2015 13:18:46 -0700 (PDT) From: Dave Garrett To: Kurt Roeckx Date: Wed, 1 Apr 2015 16:18:45 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150401194758.GA13326@roeckx.be> In-Reply-To: <20150401194758.GA13326@roeckx.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201504011618.45618.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 20:18:59 -0000 On Wednesday, April 01, 2015 03:47:58 pm Kurt Roeckx wrote: > On Wed, Apr 01, 2015 at 11:12:19AM -0700, Joseph Salowey wrote: > > Keep in mind that mandatory to implement (MTI) is not mandatory to use and > > that it is expected that there will be profiles for specific environments. > > I'm confused why we need a mandatory to implement when profiles > might decide to use something different. When defining a protocol, it should at least be written in a way that is guaranteed to work if followed to the letter. At minimum, when an implementor that uses something else gets an interoperability failure, we can say "I told you so" and point to the fact that compliant implementations can easily be configured in a way that will work. Dave From nobody Wed Apr 1 13:33: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 D0A6D1A912B for ; Wed, 1 Apr 2015 13:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQabPcF4L8QQ for ; Wed, 1 Apr 2015 13:33:24 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630B31A911A for ; Wed, 1 Apr 2015 13:31:07 -0700 (PDT) Received: by qgep97 with SMTP id p97so53449473qge.1 for ; Wed, 01 Apr 2015 13:31:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=inIyVcrP7Gljm9or491w5wx0XvslNz3OnoL+1FLQD3M=; b=Q1AgdbEp+o8ecIZLYNcAbEZMruByLeTGNOo/1J8IY8sy5hmx/QS01O8FZN02yjT1FS uUbx5kqzWQ/Spyn4Kr+Ebj2eao7wqtGn7W2GuXuFgU7czQs9QXBd9VlDXqVaJg6Y+jTi j0KsmQb4Ea+zPT/L0GU81whVuDd3RJaqU1z95jkFr/MUwSBqQP/ymowqG/xNjHOLIE0C OwvrkoqSOdeP6bBWuYnlIPnQw0/FCGOKur7deuUNdYLORaxTBR+nUxUpktiVubg7y01E jL1Rk2oF9QTt+dlGi8fwQyCHFMy5OM5Bgs1kiRCxmwwVp75ttONm4HZKdbVV8xCAbhBR NXjQ== X-Gm-Message-State: ALoCoQm52gUtA+9jxI81MixaaleRnQCfi8DXz6uUHPudSu/nisKviDGxbu4/Mjue8BkQPEyguYRs X-Received: by 10.55.24.10 with SMTP id j10mr1347270qkh.88.1427920266657; Wed, 01 Apr 2015 13:31:06 -0700 (PDT) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id 131sm2004893qhh.48.2015.04.01.13.31.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 13:31:05 -0700 (PDT) Received: from [128.220.247.217] (unknown [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 8F69BAC286E for ; Wed, 1 Apr 2015 16:31:03 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: <20150401201221.163745c2@pc1.fritz.box> Date: Wed, 1 Apr 2015 16:30:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0F170464-AB56-440F-BC4A-EEEFCDFA46FA@pahtak.org> References: <20150401201221.163745c2@pc1.fritz.box> To: "" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TLS] 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: Wed, 01 Apr 2015 20:33:26 -0000 On Apr 1, 2015, at 2:12 PM, Hanno B=F6ck wrote: > Proposal: DSA should go away and not be part of TLS 1.3. +1 --=20 Stephen Checkoway From nobody Wed Apr 1 13:41: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 495ED1A9126 for ; Wed, 1 Apr 2015 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OOF4jXx_npp for ; Wed, 1 Apr 2015 13:41:18 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (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 02A311A910B for ; Wed, 1 Apr 2015 13:41:17 -0700 (PDT) Received: by qgep97 with SMTP id p97so53691361qge.1 for ; Wed, 01 Apr 2015 13:41:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=r+7+kMZdwi72qjIYUGGeNTl1orotlyMHwsx5rdoPjMw=; b=djPRRFMnCbry8A7RH2ihvmdx3y02X7Aen4KT+kZ70qcRkF3qlOqxhb3oA0xr2OoSqG bXQzuojqDYHhwlbkeWTieX83zdYAp5IXijKKIwBIbbV6mikFHUdC3/8NIogULM+Toxif IuOVO/NWH/GVZREE83QHzczE8yKsVnAimQNtLmQpg4lEhRupQnQmYrvcajfdif3Bxdr7 haAVD+on5aitYnieExtwBRGok7VfvnqAhcnDiQsIY7Vl1yjI3c0/PGYNfRbpGnlIqSwY ScOJCCCsnpcQFNYSXzxWhfq28uGn27Hm0I8TPwBrBZOmyAKTiylY21VDrZc6Os5E3sg1 zrsQ== X-Gm-Message-State: ALoCoQmyo6qP5iPkD6eJRh+4ABmAs3RCgIMPFOkrK7yaJ2akC3zoWi+ezQihspTHpLymP14CuizV X-Received: by 10.55.31.132 with SMTP id n4mr57042012qkh.64.1427920877294; Wed, 01 Apr 2015 13:41:17 -0700 (PDT) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id 131sm2023895qhh.48.2015.04.01.13.41.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 13:41:16 -0700 (PDT) Received: from [128.220.247.217] (unknown [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id AC091AC286E for ; Wed, 1 Apr 2015 16:41:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: Date: Wed, 1 Apr 2015 16:41:07 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7D29C2A0-8B61-4FE9-AFAB-116D692D26A7@pahtak.org> References: To: "tls@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 20:41:19 -0000 On Apr 1, 2015, at 2:12 PM, Joseph Salowey wrote: > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 Like several others, I think ChaCha20-Poly1305 and X25519 should be a MUST. > o Signature: > MUST ECDSA P-256 > MUST RSA Are we going to consider whatever the CFRG eventually comes up with? -- Stephen Checkoway From SRS0=c0Xe=EO=acm.org=bmoeller@srs.kundenserver.de Wed Apr 1 13:38: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 840E51A90D3 for ; Wed, 1 Apr 2015 13:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 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_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 dq6IbKG1Pkfu for ; Wed, 1 Apr 2015 13:38:16 -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 E4AA21A90D1 for ; Wed, 1 Apr 2015 13:38:15 -0700 (PDT) Received: from mail-ob0-f171.google.com ([209.85.214.171]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0M3fOP-1ZUY5M36Nl-00rF6X for ; Wed, 01 Apr 2015 22:38:13 +0200 Received: by obvd1 with SMTP id d1so99021973obv.0 for ; Wed, 01 Apr 2015 13:38:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.230.75 with SMTP id sw11mr4811152obc.7.1427920691814; Wed, 01 Apr 2015 13:38:11 -0700 (PDT) Received: by 10.76.144.230 with HTTP; Wed, 1 Apr 2015 13:38:11 -0700 (PDT) In-Reply-To: <2BD5254C-89AA-46EA-BB03-93A250DD5CC7@vpnc.org> References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> <2BD5254C-89AA-46EA-BB03-93A250DD5CC7@vpnc.org> Date: Wed, 1 Apr 2015 16:38:11 -0400 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1134b63a9a6ae40512afb122 X-Provags-ID: V03:K0:Nc3TwBlbbb6hBVQOSMozTErKYq9Q1Azad1JXkmFRHe1wD9mG73n O5Ca4Ol3UJm8QBRyJpD/s7ly7yCjcp7wWuo1cyjMtUw3lgrkt79Fk2tuT0QHWZlHnTS5tMs ywC1FRopccRwjFpHx+pqbUzsdSjIBXrNZ3aQ4YDb/Lc3IIqR4MPMFZ+vVpAtMj4ukYUjWlS Ede0s440v4XKUF8U/D6aA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 20:49:48 -0000 --001a1134b63a9a6ae40512afb122 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul Hoffman : > > There=E2=80=99s been some interested expressed in having > http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted as > a TLS WG item. If you would like for this draft to become a WG document, > and you are willing to review drafts as it moves through the process plea= se > indicate as much on this thread. If you are opposed to this being a WG > document, please say so (and say why). Thanks in advance. > > If the adopted draft becomes clearer that it is for TLS 1.2 (and possibly > 1.1) only, but not for 1.3 (since we don't know what that will look like)= , > I support its adoption. > Right, it makes complete sense to update the document to capture existing deployment: in particular, explicitly exclude TLS 1.3 from its scope (not just because we don't know what TLS 1.3 will look like but also because TLS 1.3 can speak for itself), and remove server-side False Start unless we find any implementations. (I'm not sure that we have to explicitly *disallow* False Start for versions below TLS 1.2 as Brian Smith has suggested. After all, servers may still encounter it with older clients, so that's a part of the reality of existing deployments. The current *recommendation* could be made stronger, though.) Bodo --001a1134b63a9a6ae40512afb122 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul= Hoffman <paul.hoffman@vpnc.org>:
=C2=A0
> There=E2=80=99s been some interested expressed in= having http://datatracker.ietf.org/doc/draft-bmoeller-tl= s-falsestart/ adopted as a TLS WG item.=C2=A0 If you would like for thi= s draft to become a WG document, and you are willing to review drafts as it= moves through the process please indicate as much on this thread.=C2=A0 If= you are opposed to this being a WG document, please say so (and say why). = Thanks in advance.
=C2=A0
If the adopted draft becomes clearer that it is for TLS 1.2 (and pos= sibly 1.1) only, but not for 1.3 (since we don't know what that will lo= ok like), I support its adoption.

Right= , it makes complete sense to update the document to capture existing deploy= ment: in particular, explicitly exclude TLS 1.3 from its scope (not just be= cause we don't know what TLS 1.3 will look like but also because TLS 1.= 3 can speak for itself), and remove server-side False Start unless we find = any implementations.

(I'm not sure that we hav= e to explicitly *disallow* False Start for versions below TLS 1.2 as Brian = Smith has suggested. After all, servers may still encounter it with older c= lients, so that's a part of the reality of existing deployments. The cu= rrent *recommendation* could be made stronger, though.)

Bodo

--001a1134b63a9a6ae40512afb122-- From nobody Wed Apr 1 13:50: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 4DF111A913E for ; Wed, 1 Apr 2015 13:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 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, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzgdZqAerdl9 for ; Wed, 1 Apr 2015 13:49:58 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003: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 F12801A914C for ; Wed, 1 Apr 2015 13:49:56 -0700 (PDT) Received: by obvd1 with SMTP id d1so99470318obv.0 for ; Wed, 01 Apr 2015 13:49: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=Ji+CG3FwB00GiZUBWGOVBPej5juI91ER5pnHnBu6RAo=; b=jkNd7Ul4y8y5wEAzhsBVMUUyGsjXtu9FhSFCSQuzO2w8oJIod7rOEkWjTHHecb80JX iBhclm4Oc9LMb1zmX57YkO+dPyNbbhrYj8W//cxA8VnNN6HBg0NiD6Cy2/ntVexB2Mtl yUcBEEia9Iem1ASVZlebD1jtjs9m9u3CFTpi6Es/wvI42p5oOiYV3GaQDr+UGWxmn5r7 KZVlQe0zW68MUqtXPYiKfPJUR8d/v+Qj8DQKALh8plioRqjOo0SclEAoU0uGP1LH8qaU zQ5cKH+GRXsTVm2QP5cPkIbwidQvIGTxPNp5Xm4/Y1uqwasdL5JEhB4XieKCe2VhaLIl sbjw== MIME-Version: 1.0 X-Received: by 10.182.120.7 with SMTP id ky7mr5893895obb.14.1427921396541; Wed, 01 Apr 2015 13:49:56 -0700 (PDT) Received: by 10.76.166.232 with HTTP; Wed, 1 Apr 2015 13:49:56 -0700 (PDT) In-Reply-To: <20150401201221.163745c2@pc1.fritz.box> References: <20150401201221.163745c2@pc1.fritz.box> Date: Wed, 1 Apr 2015 13:49:56 -0700 Message-ID: From: Tony Arcieri To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Content-Type: multipart/alternative; boundary=089e0139fc489bae350512afdb91 Archived-At: Cc: "" Subject: Re: [TLS] 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: Wed, 01 Apr 2015 20:49:59 -0000 --089e0139fc489bae350512afdb91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, April 1, 2015, Hanno B=C3=B6ck wrote: > Proposal: DSA should go away and not be part of TLS 1.3. > I'm strongly opposed, because I'm a user of YoloCA, which uses a 512-bit DSA certificate as its root: https://twitter.com/yolocrypto/status/378620239144955904 Just kidding, April Fools ;) (and yes die DSA die) --=20 Tony Arcieri --089e0139fc489bae350512afdb91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, April 1, 2015, Hanno B=C3=B6ck <hanno@hboeck.de> wrote:
P= roposal: DSA should go away and not be part of TLS 1.3.

I'm strongly opposed, because I'm = a user of YoloCA, which uses a=C2=A0512-bit DSA=C2=A0certificate as its roo= t:


Just kidding, April Fools ;)

(and yes die DSA die)


--
Tony= Arcieri

--089e0139fc489bae350512afdb91-- From nobody Wed Apr 1 14:21: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 872601A1ADF for ; Wed, 1 Apr 2015 14:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.074 X-Spam-Level: X-Spam-Status: No, score=0.074 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I5qxt41Oujw for ; Wed, 1 Apr 2015 14:21:05 -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 7A8371A1AB2 for ; Wed, 1 Apr 2015 14:21:04 -0700 (PDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway21.websitewelcome.com (Postfix) with ESMTP id DED41B65DF6BE for ; Wed, 1 Apr 2015 16:21:03 -0500 (CDT) Received: from [96.231.227.6] (port=53349 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YdQ4N-00050E-5u; Wed, 01 Apr 2015 16:21:03 -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: <1082369316.6361228.1427914387267.JavaMail.zimbra@redhat.com> Date: Wed, 1 Apr 2015 17:21:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <1082369316.6361228.1427914387267.JavaMail.zimbra@redhat.com> To: Nikos Mavrogiannopoulos 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: 96.231.227.6 X-Exim-ID: 1YdQ4N-00050E-5u X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [96.231.227.6]:53349 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: tls Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 21:21:06 -0000 On Apr 01, 2015, at 14:53, Nikos Mavrogiannopoulos = wrote: > ----- Original Message ----- >> This message is to confirm the consensus reached @ the IETF 92 TLS = session in >> Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be = an >> HKDF-based PRF (see >> http://datatracker.ietf.org/doc/rfc5869/?include_text=3D1). >> Please indicate whether or not you agree with the consensus by = 2015-04-17. >> If not, please indicate why. Also, please note that we=92re = interested in >> uncovering new issues not rehashing issues already discussed. >=20 > I believe the question is totally unwarranteed. No-one has presented = any argument > on why the TLS PRF is not sufficient for its purpose. The only = arguments presented > are theoretical advantages of HKDF, which are fine, but do they add = value to TLS? > Does the advantages of HKDF translate into weaknesses of the TLS PRF? Both ekr and I queued the whole discussion up with there=92s "nothing = really wrong" with the PRF as far as we know. The discussion in Dallas = starts about 2:31:15 on audio stream - listen for a muffled ekr saying = "oh god": http://www.ietf.org/audio/ietf92/ietf92-oak-20150326-0900-am1.mp3 At about 2:34:47 of the audio stream, Hugo discuses some of the = =93sub-optimal=94 aspects of the current PRF. > So no matter the output of that poll the result will be an uneducated = guess. In all cases > it is alarming to see the easiness with which the protocol is being = rewritten completely. > Now its only similarity with TLS 1.2 is the TLS acronym. Would that = rewrite bring value > in par with the efford needed for the rewrite? Would it make us safer = in 2030 or are we > simply apply yesterday's technology today? I guess I don=92t follow - the PRF changed in previous versions and we = kept the =93TLS=94 moniker. spt > regards, > Nikos From nobody Wed Apr 1 14:28: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 1FA301A1A79 for ; Wed, 1 Apr 2015 14:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.408 X-Spam-Level: X-Spam-Status: No, score=0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 aMI3owgmqn1J for ; Wed, 1 Apr 2015 14:27:58 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [69.93.164.2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5DF1A01F6 for ; Wed, 1 Apr 2015 14:27:58 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 3CD41B138DFF1; Wed, 1 Apr 2015 16:27:57 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 2E958B138DFCD for ; Wed, 1 Apr 2015 16:27:57 -0500 (CDT) Received: from [96.231.227.6] (port=53400 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YdQB2-0006Lu-GA; Wed, 01 Apr 2015 16:27:56 -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: <20150401194849.GA22718@LK-Perkele-VII> Date: Wed, 1 Apr 2015 17:27:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <76583724-9DD5-4048-9695-E05112449825@ieca.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <20150401194849.GA22718@LK-Perkele-VII> To: Russ Housley 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: 96.231.227.6 X-Exim-ID: 1YdQB2-0006Lu-GA X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [96.231.227.6]:53400 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: IETF TLS Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s__consensus=3A_adop?= =?windows-1252?q?t_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 21:27:59 -0000 On Apr 01, 2015, at 15:48, Ilari Liusvaara = wrote: > On Wed, Apr 01, 2015 at 03:19:33PM -0400, Russ Housley wrote: >>=20 >> One detail that was not discussed because we were running out of >> time is important to me (and may be important to others). SHA-256 >> would be the MTI. Is an alternative hash function chosen based on >> the cipher suite or some other mechanism? I=92m sure you saw the other thread where we=92re discussing MTI, but if = not SHA-256 was the proposed MTI. > In TLS 1.2 and 1.3-current, the main PRF-hash is designated by > the ciphersuite. I have not seen any proposals to change this. Yeah there=92s been no propose to change this. Granted @ the interim we = did discuss hard coding SHA-256 but knowing there will be profiles that = will want to use something else we decided hard coding it was not a = great idea. spt > Then there is signature hash, which is negotiated using > extensions. >=20 >=20 > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 1 14:35: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 7FCA21A01E2 for ; Wed, 1 Apr 2015 14:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, 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 XKS2Isv4UgdC for ; Wed, 1 Apr 2015 14:35:31 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.106.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263F71A3B9F for ; Wed, 1 Apr 2015 14:35:31 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 8E8C81C3CAF27; Wed, 1 Apr 2015 16:35:30 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 7F0F61C3CAEE6 for ; Wed, 1 Apr 2015 16:35:30 -0500 (CDT) Received: from [96.231.227.6] (port=53438 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YdQIL-0001IG-QZ for tls@ietf.org; Wed, 01 Apr 2015 16:35:30 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Wed, 1 Apr 2015 17:35:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DAE18D5-9378-4900-AB68-D0FE0EF70D93@ieca.com> References: To: "tls@ietf.org" 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: 96.231.227.6 X-Exim-ID: 1YdQIL-0001IG-QZ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [96.231.227.6]:53438 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 21:35:32 -0000 On Apr 01, 2015, at 14:12, Joseph Salowey wrote: > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 Nobody 2119-me-to-death, but I paraphrase SHOULD as: this is a MUST = unless you have a really, really, really, really good reason to not do = it. spt= From nobody Wed Apr 1 14:48: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 929E11A8707 for ; Wed, 1 Apr 2015 14:48:20 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H6UCM_HTY5e for ; Wed, 1 Apr 2015 14:48:19 -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 3F0F91A6F11 for ; Wed, 1 Apr 2015 14:48:19 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so83020517wib.1 for ; Wed, 01 Apr 2015 14:48:18 -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=z1EWvL3PQtAiKWkggpbn3pBCaZnh/YmV2v/kjW3iVPE=; b=Uh1r0UD0Ku2b4TQednJnSjssl+v2qRtpkqG2dp0fb1oUggN1l8Hzq7QpOHNZSuJgpz PZGE55nt0aeXy/DBlX5W5vI9iC62XQSpxSkNh1+KywWQRSpLP+v0WjiJdRDOC9/X0ViH q5SI2QzOpTEhtMBm9nQatty/OfZ3k0R93ApN9cxoh7NgJ4t9UQoj5w1w7XEbKDsp4KII 6VUehvnAs7wtTbkU7TRNoSWa93PO4b6XB51kPytmNBNj9tzh85cIh4dgM0vwYz480cHy B5S1mSbVyxyc5zOeU7YiarCejFJgSs2knEEoS4xe4TI7r8PKzWphhAZZNBNWleScANzB aw2w== X-Received: by 10.180.104.7 with SMTP id ga7mr18140450wib.37.1427924898004; Wed, 01 Apr 2015 14:48:18 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id vq9sm4442562wjc.6.2015.04.01.14.48.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 14:48:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <20150401201221.163745c2@pc1.fritz.box> Date: Thu, 2 Apr 2015 00:48:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0899615E-0ADC-4474-B031-0589014D0511@gmail.com> References: <20150401201221.163745c2@pc1.fritz.box> To: =?utf-8?Q?Hanno_B=C3=B6ck?= X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "" Subject: Re: [TLS] 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: Wed, 01 Apr 2015 21:48:20 -0000 +1 > On Apr 1, 2015, at 9:12 PM, Hanno B=C3=B6ck wrote: >=20 > Hi, >=20 > Mozilla just removed DSA support from Firefox. It seems the use of > (non-ecc) DSA in TLS is pretty much nonexistent. Still the TLS 1.3 = draft > contains DSA. >=20 > Proposal: DSA should go away and not be part of TLS 1.3. >=20 > Reasons to remove DSA: > * DSA with 1024 bit is considered weak and DSA with more than 1024 bit > is widely unsupported. > * DSA has comparable security to RSA (it using same keysize) which is > the de-facto-default. Given that everybody uses RSA and nobody uses > DSA having the latter only adds unneccessary complexity. > * DSA can fail badly with bad random number generators. >=20 > Some numbers: > In the 2013 https ecosystem scan there were 17 DSA keys on public IPs, > none of them CA-trusted: > = http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf >=20 > I think it's safe to say nobody will care if DSA is removed. >=20 From nobody Wed Apr 1 14:52: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 048F01A8750 for ; Wed, 1 Apr 2015 14:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uZbzqEKrFtr for ; Wed, 1 Apr 2015 14:52:11 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2E21A8701 for ; Wed, 1 Apr 2015 14:52:11 -0700 (PDT) Received: by wixo5 with SMTP id o5so64039327wix.1 for ; Wed, 01 Apr 2015 14:52:10 -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=AtAtqzYqlFcp5bhibVEQaFMYJ9oFnB32knAcyVdtnc4=; b=fTuu+wNXlpFfqnhUzNVU19rQHAwG+CiMQ9IRkvYVNCkSfJHfIDEjNREJc/z7xy1b1P Bd6KJ+UYMGwZs6D5fj6v5CEOnBKKNDtcv2Prz6bpUgsjHQ8OlJBQLq34TUdPadSKWxbg lwLribQhTzrGJqafwBL0wpFOJQMKO00ftJxM7yN0wrO6V5bm92klgkiWNPNYAKm/TOY0 vi+7wolxk20floOH7u5KD5QoEGa+jOoJzFEyoQCqX9HHAgVYFne7K7t//9X/l6rz8kaj B8i+/YAKPd18lREj4IFlE3ES1D89GnBX0DuhH7EOL+31r7ZGiefkpFrAIdnQd9AJNdkO bJww== X-Received: by 10.180.21.161 with SMTP id w1mr18501125wie.16.1427925130338; Wed, 01 Apr 2015 14:52:10 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id kr5sm4461713wjc.1.2015.04.01.14.52.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 14:52:09 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> Date: Thu, 2 Apr 2015 00:52:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0A3A3FF6-37C1-4108-85A0-2EBF56B531F7@gmail.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "" Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 21:52:15 -0000 I support this proposal. I agree that the weakness with the current PRF is theoretical, but the = cost is not significant and theoretical attacks sometimes morph into = pretty demos with funky acronyms. Let=92s not go there. Yoav > On Apr 1, 2015, at 9:00 PM, Sean Turner wrote: >=20 > This message is to confirm the consensus reached @ the IETF 92 TLS = session in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 = PRF be an HKDF-based PRF (see = http://datatracker.ietf.org/doc/rfc5869/?include_text=3D1). >=20 > Please indicate whether or not you agree with the consensus by = 2015-04-17. If not, please indicate why. Also, please note that we=92re = interested in uncovering new issues not rehashing issues already = discussed. >=20 > Thanks - J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 1 14:55: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 DD0AE1A8774 for ; Wed, 1 Apr 2015 14:55:25 -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 fWwf6XN40Ehc for ; Wed, 1 Apr 2015 14:55:24 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBB41A8701 for ; Wed, 1 Apr 2015 14:55:24 -0700 (PDT) Received: from [173.75.83.181] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YdQbb-0005TF-FG for tls@ietf.org; Wed, 01 Apr 2015 17:55:23 -0400 Date: Wed, 1 Apr 2015 14:55:23 -0700 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <0899615E-0ADC-4474-B031-0589014D0511@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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79e155ca178970ea05787b9d80c8452395350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.181 Archived-At: Subject: Re: [TLS] 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: Wed, 01 Apr 2015 21:55:26 -0000 +1 I have always worried about the issues with bad random values=20 and DSA. We keep seeing bad random number problems in the wild,=20 so replacing DSA with algorithms that don't have its problems=20 seems like a good idea. Currently, it appears that the effect on=20 the real world will be minor, so now seems like a good time. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345=20 Englewood Ave www.pwpconsult.com | - Jeff Frantz | Los Gatos,=20 CA 95032 From nobody Wed Apr 1 14:56: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 7C4441A8774 for ; Wed, 1 Apr 2015 14:56:44 -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 uusrPHP40fHf for ; Wed, 1 Apr 2015 14:56:42 -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 711571A8701 for ; Wed, 1 Apr 2015 14:56:42 -0700 (PDT) Received: by wixo5 with SMTP id o5so38280293wix.1 for ; Wed, 01 Apr 2015 14:56: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 :message-id:references:to; bh=DSh+YdTry+gnUjsz7L4WyGCCVj+ypXj8dibyXuC47js=; b=0qgObRuxzhuyx02u1GyaSSbHbDXuSKPmEQ9hnGxL0RPGYRf5sydtJ3l3sTaNqf1FZg egYZbXeBFlmw7xqo5xUbWcRUTwksR9BRuZbPzr6uQmNpaaWnDDQzfxABha55ZxyDcW15 neUudxYTV/hRU9ZgLexruLxlFtUjj3/CTwynAamwajnnfsuXwdLglytu/m1Vk2pd4r/A hsnyOhcGYAMWlkwzjCwGR8qusV3YcHE99qLsj2qdA3CKR+/EI28aWP70pgtqRUFtHoh6 HDc8sweXd0ljNwpU1a3WFiUMo90mYU75TlMLXHELEABfYPhQQjATSu/x9Kok0jxXM4zi XxZQ== X-Received: by 10.194.121.10 with SMTP id lg10mr89650403wjb.71.1427925401231; Wed, 01 Apr 2015 14:56:41 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id u10sm27254099wib.1.2015.04.01.14.56.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 14:56:40 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B978B24A-E1FD-4B0C-B36C-437F5E29FBF5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 2 Apr 2015 00:56:38 +0300 Message-Id: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> References: To: Joseph Salowey X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 21:56:44 -0000 --Apple-Mail=_B978B24A-E1FD-4B0C-B36C-437F5E29FBF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support this. I think it=E2=80=99s kind of funny to make ChaCha20-Poly1305 a = SHOULD-level requirement, when (a) there is no ciphersuite that uses = this algorithm in the registry, and (b) the WG has not accepted any = document that proposes such a ciphersuite. But it=E2=80=99s just funny, = not bad. I=E2=80=99m sure we will adopt the document soon. Yoav > On Apr 1, 2015, at 9:12 PM, Joseph Salowey wrote: >=20 > We did not get a chance to talk about MTI algorithms in Dallas, but = the chairs would like to judge consensus for the algorithms discussed in = the interim. The CFRG has closed or will close soon on ChaCha20 and = curve 25519 recommendations so they are included. We will be calling = for acceptance to bring drafts on these into the working group shortly. >=20 > Keep in mind that mandatory to implement (MTI) is not mandatory to use = and that it is expected that there will be profiles for specific = environments. >=20 > Below is the proposed algorithm list that had consensus at the Seattle = Interim. Please reply on the TLS mailing list indicating whether or not = you agree with the consensus. If not, please indicate why. This = consensus call will close on April, 23, 2015. =20 >=20 > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 >=20 > o Hash: > MUST SHA-256 >=20 > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 >=20 > o Signature: > MUST ECDSA P-256 > MUST RSA >=20 > Thanks, >=20 > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_B978B24A-E1FD-4B0C-B36C-437F5E29FBF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I support this.

I think it=E2=80=99s kind of funny to make ChaCha20-Poly1305 = a SHOULD-level requirement, when (a) there is no ciphersuite that uses = this algorithm in the registry, and (b) the WG has not accepted any = document that proposes such a ciphersuite. But it=E2=80=99s just funny, = not bad. I=E2=80=99m sure we will adopt the document soon.

Yoav

On Apr 1, 2015, at 9:12 PM, Joseph Salowey <joe@salowey.net> = wrote:

We did = not get a chance to talk about MTI algorithms in Dallas, but the chairs = would like to judge consensus for the algorithms discussed in the = interim.  The CFRG has closed or will close soon on ChaCha20 and = curve 25519 recommendations so they are included.  We will be = calling for acceptance to bring drafts on these into the working group = shortly.

Keep in mind = that mandatory to implement (MTI) is not mandatory to use and that it is = expected that there will be profiles for specific = environments.

Below is the = proposed algorithm list that had consensus at the Seattle Interim. = Please reply on the TLS mailing list indicating whether or not you = agree with the consensus.  If not, please indicate why.  This = consensus call will close on April, 23, 2015.  

o Symmetric:
        MUST AES-GCM 128
        SHOULD ChaCha20-Poly1305

o Hash:
      =   MUST SHA-256

o Key Agreement: = ECDH
        MUST P-256
        SHOULD 25519

o Signature:
        MUST = ECDSA P-256
        MUST RSA

Thanks,
J&S
_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_B978B24A-E1FD-4B0C-B36C-437F5E29FBF5-- From nobody Wed Apr 1 15:52: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 235EE1A6FEB for ; Wed, 1 Apr 2015 15:52:53 -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 NQnv0oaDGhfk for ; Wed, 1 Apr 2015 15:52:52 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 B2F901A6EDE for ; Wed, 1 Apr 2015 15:52:51 -0700 (PDT) Received: by wixo5 with SMTP id o5so65148253wix.1 for ; Wed, 01 Apr 2015 15:52: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=c4UyU98S9ay2zq7C1H95cA4xWZlOUWt/NLq4JwaISSQ=; b=WItI2lYgYVmjASdfuHVLNHBeLi/eMw9wZ68O/NUcuvkLj/nO7JwTL0oInlaXd54Nun 7WaUEda+z1zDTWACT2mR9u+pgp2KIYwFWIshQeJ1izkk7hAU+5biFrcx1laAqXUhPsfr VEKOAhzENROXdZXCZV1QRuumKjNOV/u2FV2GsvowjnS8yIVjlw7PGLdU/H62o/cVAMpm YtfwiM7lNQHSE3APN57H96ndtKQfk9180Zd0H5eGJWGf+LCAtXkXt9RNHONmNnNr0/MH OzlsyXP21x6X1y72+Wgqtah38lXwdmxeMsU4VBKRqmIm4AHOovu7aR42V3/HsBX1dJ8y 3bmw== X-Gm-Message-State: ALoCoQkm4TE0LH9XDuBRctgDaoflAXbPO93KCdPwkD/B2fCu7zfQItCsymuiClh9gyjNiDPzgfnV X-Received: by 10.180.91.162 with SMTP id cf2mr18793597wib.61.1427928770295; Wed, 01 Apr 2015 15:52:50 -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 ft7sm5084945wic.14.2015.04.01.15.52.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 15:52:48 -0700 (PDT) Message-ID: <551C76BD.5070504@azet.org> Date: Thu, 02 Apr 2015 00:52:45 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73AAFC29C6@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFC29C6@uxcn10-5.UoA.auckland.ac.nz> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3B75D4990ED25F038C99D3C8" Archived-At: Cc: "" Subject: Re: [TLS] comment on draft-ietf-tls-pwd-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Apr 2015 22:52:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B75D4990ED25F038C99D3C8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Peter, Peter Gutmann wrote: >=20 > Given that AES-CBC with EtM is a lot less vulnerable to problems than A= ES-GCM > (and arguably even without EtM it's a lot less brittle than GCM is), wh= y would > you remove it? It's a much more robust mode than GCM. >=20 You're right. I wrongly assumed that your ETM document is still in draft phase, I see that it's been accepted. Thanks, Aaron --------------enig3B75D4990ED25F038C99D3C8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVHHa+AAoJEOTbZJL9ubXVzfUQANDzihsik8Z3p3jRwqSXAzj/ H4fcJpxWI/tY6gDFjJoDb6VHIwNcojqppdcGWOcmG21HryzgffHL1wl+0DXEnY0+ jL4hmw9yaebCtARCX+IDdv7YVXqYHkaPBb1Snd0yMnjpq0uUKjjiW/9Hyn2YgaYN shZU5VXNNzklY328dd+orEmLQRt5uaS78K2WsTjiOxGBRK7E56FpLZRKfUcAxL52 XA0XyNFVgn4xAinEKN+b18N4bnRPOvUytzlyWEtFgNYHgo+B43pUrf9hTE7cpTf6 gaVd0lNuhzasRj8X+ZoWZhrSVyKFErqPLPosi5Xa+YD5hUrATqgkPx0AjNJ1bk2v A1VdICweIbZusTHEqvKlHIO2NSvIIFh1P+R8ut6wfY6wDbMviU/B23kyHjRph/Hx Ln3Pm57PMvswjnIHhhzju0LMooYswPRZmh1i29s5cEa3tnbEfbpoe0fhL/HcSG4N 7L+Xq0EZhLuoJ+0aCcPENRUsQAlk8FY70oSguAXoV+lGLCYRV/IkPAzA0/Ht+NjZ rbeZ+vSbfbMsmBcuKSXIDsG9qsV43QpY0bTxTyUSjE1bg4vS3s5zWDZ4hf4E0JrA N2Goa3vBhhwmGxfR2PUIzpXjoziqlgkePKf3B1LWnD9tUJAdIMgb7SBVMotz1LXM NpJytJXC6ynS/+qRiKqw =FMNd -----END PGP SIGNATURE----- --------------enig3B75D4990ED25F038C99D3C8-- From nobody Wed Apr 1 16:04: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 629EF1AC42E for ; Wed, 1 Apr 2015 16:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXkF4DSTtR3M for ; Wed, 1 Apr 2015 16:04:20 -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 6F88B1AC42C for ; Wed, 1 Apr 2015 16:04:20 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so59887612igc.0 for ; Wed, 01 Apr 2015 16:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dOZ2lpi6LLtnnIYQArvM9Ej75bP+EM2OICa/PWWBkY0=; b=K4UbdJILxrZtEHr5H06GcbmtUlno7KDpX1+LueUqhLf9IS/dEf0KIkfY/pv/cr0Kvl U/m81vsTQ4GFJRqGvXyJ4udI683Z/FE9/4XoriWGOX9SjtLhKkFn+g3K0myYeAAZ+Hg9 1QiYxl49Vw2Dey/TZ2ce0SRu3I+XWTaPXso/0= 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=dOZ2lpi6LLtnnIYQArvM9Ej75bP+EM2OICa/PWWBkY0=; b=aE/HfJnrKh9C7oYiwVxaPXdIVFJUnOnjf0d3cUzDxSg6QI+RTUZPpsqcdDyetfiMea XYbzyLucScT9OfqFFATHKuTZ7Rnp1ziu4PPWYAYOP/+0A3r1MYMAZ+5a66TZvmv3sJ3q +lC+/Uuc4OGJbhAp7Rtyf6ZSgjBBm/qutXg0FejrA8yYNyaopThNeSBKdbfQlYT3y+LQ pSjobmmEG9aZIlovGUJzHMylbHb6zl07ieaiySW2yoKEjHq/CYvy/zZXcdadpYTHM7ov CpMuRbZd/AIXBuka5qr5I+urOKdVaYm9xKudlv+z+hvRMK70jhrAUxPDtafXtcZbXzSQ Zd5Q== X-Gm-Message-State: ALoCoQk91HrEnTRHPhn2ZQs0tGKYX2Ro00SZ5MVQaDEqiMDZZexh1oXfPXS6bvPF+LNmge4O3ixw MIME-Version: 1.0 X-Received: by 10.107.12.158 with SMTP id 30mr12513289iom.61.1427929459918; Wed, 01 Apr 2015 16:04:19 -0700 (PDT) Received: by 10.107.166.84 with HTTP; Wed, 1 Apr 2015 16:04:19 -0700 (PDT) Received: by 10.107.166.84 with HTTP; Wed, 1 Apr 2015 16:04:19 -0700 (PDT) In-Reply-To: References: <0899615E-0ADC-4474-B031-0589014D0511@gmail.com> Date: Wed, 1 Apr 2015 18:04:19 -0500 Message-ID: From: Tom Ritter To: Bill Frantz Content-Type: multipart/alternative; boundary=001a113dc818392d370512b1bce8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] 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: Wed, 01 Apr 2015 23:04:21 -0000 --001a113dc818392d370512b1bce8 Content-Type: text/plain; charset=ISO-8859-1 +1 My pet oddity was inherited DSA parameters from a certificate chain. (Don't even know if that's supported in many implementations.) -tom --001a113dc818392d370512b1bce8 Content-Type: text/html; charset=ISO-8859-1

+1

My pet oddity was inherited DSA parameters from a certificate chain. (Don't even know if that's supported in many implementations.)

-tom

--001a113dc818392d370512b1bce8-- From nobody Wed Apr 1 17:26: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 C0FF41ACF58 for ; Wed, 1 Apr 2015 17:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.508 X-Spam-Level: X-Spam-Status: No, score=0.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, UPPERCASE_50_75=0.008] 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 UBP3oSagHCIZ for ; Wed, 1 Apr 2015 17:26:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA641ACF57 for ; Wed, 1 Apr 2015 17:26:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 640F3283031; Thu, 2 Apr 2015 00:26:46 +0000 (UTC) Date: Thu, 2 Apr 2015 00:26:46 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150402002646.GR17637@mournblade.imrryr.org> References: <20150401201221.163745c2@pc1.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401201221.163745c2@pc1.fritz.box> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] DSA should die 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, 02 Apr 2015 00:26:51 -0000 On Wed, Apr 01, 2015 at 08:12:21PM +0200, Hanno B?ck wrote: > Mozilla just removed DSA support from Firefox. It seems the use of > (non-ecc) DSA in TLS is pretty much nonexistent. Still the TLS 1.3 draft > contains DSA. > > Proposal: DSA should go away and not be part of TLS 1.3. I'm in. This also helps to shrink the ClientHello cipherlist zoo. OpenSSL has (SRP, EXPORT and single-DES excluded): DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 Which can all go. Speaking of house-cleaning, on my deprecation wish list are also (pardon the OpenSSL nomenclature): DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA Au=DH Enc=SEED(128) Mac=SHA1 DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS Au=DH Enc=SEED(128) Mac=SHA1 ADH-SEED-SHA SSLv3 Kx=DH Au=None Enc=SEED(128) Mac=SHA1 SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DH-RSA-DES-CBC-SHA SSLv3 Kx=DH/RSA Au=DH Enc=DES(56) Mac=SHA1 DH-DSS-DES-CBC-SHA SSLv3 Kx=DH/DSS Au=DH Enc=DES(56) Mac=SHA1 ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 and exotic key agreement schemes with static DH certificates (some of which appear above): DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(256) Mac=AEAD DH-RSA-AES256-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA256 DH-RSA-AES256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA1 DH-RSA-CAMELLIA256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(256) Mac=SHA1 DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(128) Mac=AEAD DH-RSA-AES128-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA256 DH-RSA-AES128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA1 DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA Au=DH Enc=SEED(128) Mac=SHA1 DH-RSA-CAMELLIA128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(128) Mac=SHA1 DH-RSA-DES-CBC3-SHA SSLv3 Kx=DH/RSA Au=DH Enc=3DES(168) Mac=SHA1 DH-RSA-DES-CBC-SHA SSLv3 Kx=DH/RSA Au=DH Enc=DES(56) Mac=SHA1 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1 ECDH-RSA-NULL-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=None Mac=SHA1 ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1 ECDH-ECDSA-NULL-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=None Mac=SHA1 -- Viktor. From nobody Wed Apr 1 17:40: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 855D81A8837 for ; Wed, 1 Apr 2015 17:40: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_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UPPERCASE_50_75=0.008] 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 wBY1-pVv4itj for ; Wed, 1 Apr 2015 17:40:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C733D1A1EFD for ; Wed, 1 Apr 2015 17:40:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 98421BEFE for ; Thu, 2 Apr 2015 01:40:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaewGMfEGUVB for ; Thu, 2 Apr 2015 01:40:40 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.244]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B387BBEE9 for ; Thu, 2 Apr 2015 01:40:40 +0100 (IST) Message-ID: <551C9008.5030605@cs.tcd.ie> Date: Thu, 02 Apr 2015 01:40:40 +0100 From: Stephen Farrell 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: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> In-Reply-To: <20150402002646.GR17637@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] 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: Thu, 02 Apr 2015 00:40:45 -0000 Here's a suggestion: why pick 'em off one by one? How about creating a new registry that only includes stuff we think is really good for TLS1.3? Personally, I'd go further and argue that the new registry only specify the TLS 1.3 MTIs, but that's a different question:-) I'd even argue that that new registry be defined so it only has space for two of anything - in other words maybe structure the new registry like the nice list in the MTI mail thread, [1] and then say how to map that to the old registry that has all 330+ ciphersuites including the good, the bad and the downright ugly. S. [1] https://www.ietf.org/mail-archive/web/tls/current/msg15774.html On 02/04/15 01:26, Viktor Dukhovni wrote: > On Wed, Apr 01, 2015 at 08:12:21PM +0200, Hanno B?ck wrote: > >> Mozilla just removed DSA support from Firefox. It seems the use of >> (non-ecc) DSA in TLS is pretty much nonexistent. Still the TLS 1.3 draft >> contains DSA. >> >> Proposal: DSA should go away and not be part of TLS 1.3. > > I'm in. This also helps to shrink the ClientHello cipherlist zoo. > > OpenSSL has (SRP, EXPORT and single-DES excluded): > > DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD > DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 > DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 > DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 > DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD > DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 > DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 > DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 > EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 > DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 > > Which can all go. Speaking of house-cleaning, on my deprecation wish list > are also (pardon the OpenSSL nomenclature): > > DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 > DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 > DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA Au=DH Enc=SEED(128) Mac=SHA1 > DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS Au=DH Enc=SEED(128) Mac=SHA1 > ADH-SEED-SHA SSLv3 Kx=DH Au=None Enc=SEED(128) Mac=SHA1 > SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 > IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 > RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 > EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 > EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 > DH-RSA-DES-CBC-SHA SSLv3 Kx=DH/RSA Au=DH Enc=DES(56) Mac=SHA1 > DH-DSS-DES-CBC-SHA SSLv3 Kx=DH/DSS Au=DH Enc=DES(56) Mac=SHA1 > ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1 > DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 > > and exotic key agreement schemes with static DH certificates (some of which > appear above): > > DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(256) Mac=AEAD > DH-RSA-AES256-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA256 > DH-RSA-AES256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA1 > DH-RSA-CAMELLIA256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(256) Mac=SHA1 > DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(128) Mac=AEAD > DH-RSA-AES128-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA256 > DH-RSA-AES128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA1 > DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA Au=DH Enc=SEED(128) Mac=SHA1 > DH-RSA-CAMELLIA128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(128) Mac=SHA1 > DH-RSA-DES-CBC3-SHA SSLv3 Kx=DH/RSA Au=DH Enc=3DES(168) Mac=SHA1 > DH-RSA-DES-CBC-SHA SSLv3 Kx=DH/RSA Au=DH Enc=DES(56) Mac=SHA1 > > ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD > ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 > ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 > ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD > ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 > ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 > ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 > ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1 > ECDH-RSA-NULL-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=None Mac=SHA1 > > ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD > ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 > ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 > ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD > ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 > ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 > ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 > ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1 > ECDH-ECDSA-NULL-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=None Mac=SHA1 > From nobody Wed Apr 1 17:46: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 939881A88B8 for ; Wed, 1 Apr 2015 17:46: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 Qe6VC8ruvbMv for ; Wed, 1 Apr 2015 17:46:44 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e: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 AE69C1A6F01 for ; Wed, 1 Apr 2015 17:46:44 -0700 (PDT) Received: by patj18 with SMTP id j18so67678899pat.2 for ; Wed, 01 Apr 2015 17:46:44 -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=mCH6Uqg1Svkg9SqcCHBbMV4FQON0QTU5n3mjJEP9XvY=; b=GX0ZzBMWd/q105A+Tabvak83yMbbPHYdcrs7/056V9fjlgA1lW5WBy3MVohbyie2Y0 qWEOZrIsiQY28+2WeOHBLDfhhzJvU2sFgWD0gZpupqlHHwQgHp+U+Agvs3BXlIFyccmP iRH2PUe2k88UKSdTsUsPh5bARQFCOTO1b4P/inLwAMKe0fDPTf9EZTNLfldv+BZ98PmU NtgBMP9TilnszOtEz1eGDvYy7wB+Ql3e/a6Ruz9CXKEfUzzDiZAVhXy5s8gEBmSVmeLW vCUR+rUdBjU4TQ4yr3oWVGGOEw5aDMTrqbG1hk6OKWdJLxi1tueNkXUkBJj4AkIiuP/y psMQ== X-Received: by 10.66.172.4 with SMTP id ay4mr41268862pac.157.1427935603974; Wed, 01 Apr 2015 17:46:43 -0700 (PDT) Received: from [192.168.51.195] (65-119-109-34.dia.static.qwest.net. [65.119.109.34]) by mx.google.com with ESMTPSA id rr10sm3323357pac.1.2015.04.01.17.46.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 17:46:42 -0700 (PDT) Message-ID: <551C9170.8050708@gmail.com> Date: Wed, 01 Apr 2015 17:46:40 -0700 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yoav Nir , Joseph Salowey References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> In-Reply-To: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 00:46:46 -0000 The TLS BCP (http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-11, soon to be published), recommends two cipher suites based on AES-256-GCM and SHA-384. Doesn't it make sense to have them as SHOULD, for the sake of continuity and also for those people who actually desire a higher level of bit-strength? Also, just wondering: is ECDSA popular enough today to be a MUST? For example, is the CAB Forum pushing its members to deploy such certificates? Thanks, Yaron On 04/01/2015 02:56 PM, Yoav Nir wrote: > I support this. > > I think it’s kind of funny to make ChaCha20-Poly1305 a SHOULD-level > requirement, when (a) there is no ciphersuite that uses this algorithm > in the registry, and (b) the WG has not accepted any document that > proposes such a ciphersuite. But it’s just funny, not bad. I’m sure we > will adopt the document soon. > > Yoav > >> On Apr 1, 2015, at 9:12 PM, Joseph Salowey > > wrote: >> >> We did not get a chance to talk about MTI algorithms in Dallas, but >> the chairs would like to judge consensus for the algorithms discussed >> in the interim. The CFRG has closed or will close soon on ChaCha20 >> and curve 25519 recommendations so they are included. We will be >> calling for acceptance to bring drafts on these into the working group >> shortly. >> >> Keep in mind that mandatory to implement (MTI) is not mandatory to use >> and that it is expected that there will be profiles for specific >> environments. >> >> Below is the proposed algorithm list that had consensus at the Seattle >> Interim. Please reply on the TLS mailing list indicating whether or >> not you agree with the consensus. If not, please indicate why. This >> consensus call will close on April, 23, 2015. >> >> o Symmetric: >> MUST AES-GCM 128 >> SHOULD ChaCha20-Poly1305 >> >> o Hash: >> MUST SHA-256 >> >> o Key Agreement: ECDH >> MUST P-256 >> SHOULD 25519 >> >> o Signature: >> MUST ECDSA P-256 >> MUST RSA >> >> Thanks, >> >> J&S >> _______________________________________________ >> 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 Apr 1 17:48: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 18CC31A88C0 for ; Wed, 1 Apr 2015 17:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, 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 92uPTJ1EDW3y for ; Wed, 1 Apr 2015 17:48:37 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 615DC1A8837 for ; Wed, 1 Apr 2015 17:48:37 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 2B24F2005E626 for ; Wed, 1 Apr 2015 17:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=DaN8R872R8nmY+FttUmv DhPQ/3c=; b=aPEEcaRbiOoyeGvl940HUW7f/y6mDps7SsTNt14mLCLFLSZ7bo++ X7zj3EyLWMf+Hi2hQF5AIqZsPbhNSw6n4LUp0JvM5PP4aIJMWCYQfzp7UB5j0TQr iFvnxhpA+7/fJ+g6fo8VTafbDH3X6MOfaBBgkMtYsirbPimjW0A97Zw= Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 19F272005E625 for ; Wed, 1 Apr 2015 17:48:37 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so64453019ied.1 for ; Wed, 01 Apr 2015 17:48:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.25.17 with SMTP id y17mr35452512icb.68.1427935716753; Wed, 01 Apr 2015 17:48:36 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 17:48:36 -0700 (PDT) In-Reply-To: <551C9008.5030605@cs.tcd.ie> References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@cs.tcd.ie> Date: Wed, 1 Apr 2015 19:48:36 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 00:48:38 -0000 On Wed, Apr 1, 2015 at 7:40 PM, Stephen Farrell wrote: > > > Here's a suggestion: why pick 'em off one by one? How about > creating a new registry that only includes stuff we think is > really good for TLS1.3? > > Personally, I'd go further and argue that the new registry > only specify the TLS 1.3 MTIs, but that's a different question:-) > > I'd even argue that that new registry be defined so it only > has space for two of anything - in other words maybe structure > the new registry like the nice list in the MTI mail thread, [1] > and then say how to map that to the old registry that has all > 330+ ciphersuites including the good, the bad and the downright > ugly. It would be easier to specify the inputs to the cartesian product. It would be better to also negotiate (cipher+mode), (hash), (KDF), and (key agreement+server authentication) separately. Nico -- From nobody Wed Apr 1 17:51: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 2F1421A88D7 for ; Wed, 1 Apr 2015 17:51:06 -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 fb4L59c00GdT for ; Wed, 1 Apr 2015 17:51: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 9FB3B1A88C0 for ; Wed, 1 Apr 2015 17:51:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 60D79BEFE; Thu, 2 Apr 2015 01:51:02 +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 eXgYTj6Gz4UV; Thu, 2 Apr 2015 01:51:01 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.244]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 42584BEE9; Thu, 2 Apr 2015 01:51:01 +0100 (IST) Message-ID: <551C9274.9010409@cs.tcd.ie> Date: Thu, 02 Apr 2015 01:51:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nico Williams References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@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" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 00:51:06 -0000 On 02/04/15 01:48, Nico Williams wrote: > On Wed, Apr 1, 2015 at 7:40 PM, Stephen Farrell > wrote: >> >> >> Here's a suggestion: why pick 'em off one by one? How about >> creating a new registry that only includes stuff we think is >> really good for TLS1.3? >> >> Personally, I'd go further and argue that the new registry >> only specify the TLS 1.3 MTIs, but that's a different question:-) >> >> I'd even argue that that new registry be defined so it only >> has space for two of anything - in other words maybe structure >> the new registry like the nice list in the MTI mail thread, [1] >> and then say how to map that to the old registry that has all >> 330+ ciphersuites including the good, the bad and the downright >> ugly. > > It would be easier to specify the inputs to the cartesian product. > > It would be better to also negotiate (cipher+mode), (hash), (KDF), and > (key agreement+server authentication) separately. Right. That's what Joe did in the mail to which I pointed. I'm not saying anything about how that's represented on the wire, but only about IANA registry structure (and size:-) S > > Nico > -- > > From nobody Wed Apr 1 18:01: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 7C0B71AD068 for ; Wed, 1 Apr 2015 18:01: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 VlMAqghy8q5h for ; Wed, 1 Apr 2015 18:01:54 -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 014841AD067 for ; Wed, 1 Apr 2015 18:01:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E8E32283031; Thu, 2 Apr 2015 01:01:52 +0000 (UTC) Date: Thu, 2 Apr 2015 01:01:52 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150402010152.GU17637@mournblade.imrryr.org> References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551C9008.5030605@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] DSA should die 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, 02 Apr 2015 01:01:55 -0000 On Thu, Apr 02, 2015 at 01:40:40AM +0100, Stephen Farrell wrote: > > > Here's a suggestion: why pick 'em off one by one? How about > creating a new registry that only includes stuff we think is > really good for TLS1.3? > > Personally, I'd go further and argue that the new registry > only specify the TLS 1.3 MTIs, but that's a different question:-) The problem is that leaves SRP and the like out in the cold. So there would need to be few such lists, but that's fine, a client doing SRP/PSS/... would only advertise SRP/PSS-capable cipher-suites, and client with no SRP/PSS/... shared secrets would not advertise any of them. So that means a short list per authentication trust-model. * A list for PKI TLS. * A list for anon TLS (that includes the PKI list, for interop, and the client will ignore the server's cert). * A list for SRP. * A list for PSS. Each list is short, and any client uses just one list. -- Viktor. From nobody Wed Apr 1 18:14: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 C07EB1AD084 for ; Wed, 1 Apr 2015 18:14: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 vqF53-KZpMog for ; Wed, 1 Apr 2015 18:14:27 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003: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 4B2DD1AD082 for ; Wed, 1 Apr 2015 18:14:27 -0700 (PDT) Received: by obbec2 with SMTP id ec2so106148392obb.3 for ; Wed, 01 Apr 2015 18:14:26 -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=2Jx2gIJWiktdLjzP0eVpQLRy48K94V8Tnc09lyPhtT0=; b=Snv0agrpmXJb0r5jx6bHJ0qJVfjLVOIOP6Vo4tDTxI3QPNfFt1JIWAPJgzya+jp8gy xrI+Hw8ysPY8z28XWvGkSR91WVqDeWiw6LdggI1Lk3uxKOGBqQE/5v+ceAio8el2KhuA SpfhSd/PhzgJc48Aymd5b1uOL1MUTYZrhbI7s6xu19b8V4iLQ1R2iGLUu8korxV5ewg3 5rpunA/us2TyxC52mqJyBbT6GivC4DhY11QP80GiiHgqZrk2EK4XYzYZzQKui4cON1e/ yyqlbhVI/muzhQYFPm4KvkcerNxFzm3BGK5T5iS4reFkTrtPGoncU8QXwbwqun2NQ640 Ay2w== MIME-Version: 1.0 X-Received: by 10.60.155.135 with SMTP id vw7mr43892897oeb.62.1427937266743; Wed, 01 Apr 2015 18:14:26 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Wed, 1 Apr 2015 18:14:26 -0700 (PDT) In-Reply-To: <551C9170.8050708@gmail.com> References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> Date: Wed, 1 Apr 2015 18:14:26 -0700 Message-ID: From: Martin Thomson To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 01:14:29 -0000 On 1 April 2015 at 17:46, Yaron Sheffer wrote: > AES-256-GCM and SHA-384. Doesn't it make sense to have them as SHOULD, I don't see much point. All involved likely know if they need something that strong, which is way down there in the "we might need it someday" category [1]. [1] http://www.keylength.com/en/3/ From nobody Wed Apr 1 18: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 7F9801AD09E for ; Wed, 1 Apr 2015 18:15: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 0mNbpVOaokao for ; Wed, 1 Apr 2015 18:15:12 -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 0CF7C1AD082 for ; Wed, 1 Apr 2015 18:15:11 -0700 (PDT) Received: by qgh3 with SMTP id 3so58419444qgh.2 for ; Wed, 01 Apr 2015 18:15:11 -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=Hlqf7SARubJMWhCU4Cj54Gw/xwpJz30ZuXsS20TIc1E=; b=Oxa8XXbgVecZHCF2M0L6f3zl1xHec21mm7GEW8ZnrCLqbpEsoK1djK0MQos99RwDdH wPSreSFPmt3mtqF7Q3x5ILdV7NC/+9yJTuqyJa2cw+EK7PrvqUgputtV3r3kZc6VDZGy F5Lj7XRvQR1dNlAaD6ITSmmNuRTlS2clPHUM4msHSUm0Tp0Sgwy49GaYZLj+pkL3MW3Z Ioq7qPhONj0SY+XDdoJwsx169qfmFFWvcLoNZqblstN9H1S1vxCNi9hwoy2xm99WLLKL RTDzjlGwqQ/8Bvrio71NyMgslizrHimIsquq+4J5h4eYDXPpicEeDnw2JoJhzcZUENrK 5Y3g== X-Received: by 10.141.23.205 with SMTP id z196mr59323375qhd.66.1427937311146; Wed, 01 Apr 2015 18:15:11 -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 206sm2512454qhy.1.2015.04.01.18.15.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Apr 2015 18:15:10 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 1 Apr 2015 21:15:08 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@cs.tcd.ie> In-Reply-To: <551C9008.5030605@cs.tcd.ie> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201504012115.09048.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] 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: Thu, 02 Apr 2015 01:15:13 -0000 On Wednesday, April 01, 2015 08:40:40 pm Stephen Farrell wrote: > > > Here's a suggestion: why pick 'em off one by one? How about > creating a new registry that only includes stuff we think is > really good for TLS1.3? I don't think a whole new registry is a good idea. The ClientHello has to stay the same for backwards compatibility, and cipher suites will need to be listed for TLS 1.2 compatibility at least. Creating a whole new system is only good if you can completely ignore the old one. There's plenty of space in the current registry if you want to start over. Just say 0xD000 and up is for TLS2 suites, and all below are TLS1. (at this point it's definitely time for 2.0) Define TLS2 codepoints for valid combinations for TLS2 and the TLS1 would be invalid to negotiate for TLS2 but in there for TLS1. This would cost a few more bytes to list AES-GCM in both TLS1 & TLS2 format in the same list, but resorting to a whole new system would add more bytes anyway, along with another registry to keep track of. On Wednesday, April 01, 2015 08:48:36 pm Nico Williams wrote: > It would be better to also negotiate (cipher+mode), (hash), (KDF), and > (key agreement+server authentication) separately. I'm definitely in favor of reducing the combinatorial explosion in suites and moving hash, KEA, & etc. into a separate negotiation. Instead of an extension, you could just do the same thing again, really. Reserve a sizable block of the 16-bit suite space for hashes and another for KEA and list them all in the same cipher_suites array. TLS1 would ignore them, and TLS2 would just see points between [a,b] are hash, [b+1,c] are KEA, etc. So, new registries in the existing space, just dumped all into the same pile. Dave From nobody Wed Apr 1 18:18: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 470091ACCF3 for ; Wed, 1 Apr 2015 18:18: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 h6xGVO4ZX16j for ; Wed, 1 Apr 2015 18:18:13 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003: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 A2A521ACCF9 for ; Wed, 1 Apr 2015 18:18:13 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so101224815obb.1 for ; Wed, 01 Apr 2015 18:18: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=2q0rqJL4Cgifer/i2D/AkCOX/b0Iw6QICezuRVUcrfI=; b=GckcCbPCpAPPn2Pxl29/Gtitk9moZ3pFGzd6n7zcQKeDxfxfFpNJLlgoTrWpBwh8pq V6yd6bWHN69kzn7NEdAdH54+o5i82V4LH/24XieIAgjN6WIbGen0cq9gx0KNcfd7GIwp XCPovP98VU9C5aLIdvXg96wbcSGFFicAOGlmPWgSPRCq7gUeFvIlMXX/R8Ep36PakVfL fcydZiCtHksokW6qfp5kU3Aa3tkfqV7Ni/+cfn6kO+O3HKX0DMAqs175XVC/mRyixCXV emt2vrCEunQ05ALoyO6D01fvrDjqcfwwjk4D3ZOVF9WQNXQT/YonoC+9nrCUc3HGdZfw qruQ== MIME-Version: 1.0 X-Received: by 10.182.210.197 with SMTP id mw5mr44297754obc.26.1427937493073; Wed, 01 Apr 2015 18:18:13 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Wed, 1 Apr 2015 18:18:12 -0700 (PDT) In-Reply-To: <551C9008.5030605@cs.tcd.ie> References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@cs.tcd.ie> Date: Wed, 1 Apr 2015 18:18:12 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 01:18:18 -0000 On 1 April 2015 at 17:40, Stephen Farrell wrote: > > Here's the exhaustive list that we've already removed. http://http2.github.io/http2-spec/#BadCipherSuites Some of those are still in wide use today, but none of these work in 1.3. Removing DSS helps a little, but it is worth doing. From nobody Wed Apr 1 18:38: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 43EB01AD1EC for ; Wed, 1 Apr 2015 18:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, 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 zVVbTjOOJIk3 for ; Wed, 1 Apr 2015 18:38:50 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 98F181AD1DB for ; Wed, 1 Apr 2015 18:38:50 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 70AF936007C for ; Wed, 1 Apr 2015 18:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ulOTstHeaRUt/64iKfd17v9XF18=; b=YkGghinmmXZ hSq1X2N9Dk5RhWPfy8xspKVxhtoeGPa8rYe1AAFKzZuD5cwVwNujUL72aUJu6lDg xWPPi/WHszZ5cK0/UR+psMjxQeYG66ThqMdHI6L8gJPozeK4KTZ3oaGFFOtXtSWr GbmIPMX+j9QQxEwfGC9Ei4G8I1aY7QZQ= Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 64C91360072 for ; Wed, 1 Apr 2015 18:38:50 -0700 (PDT) Received: by ignm3 with SMTP id m3so41400209ign.0 for ; Wed, 01 Apr 2015 18:38:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.25.17 with SMTP id y17mr35625123icb.68.1427938729981; Wed, 01 Apr 2015 18:38:49 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 18:38:49 -0700 (PDT) In-Reply-To: <201504012115.09048.davemgarrett@gmail.com> References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@cs.tcd.ie> <201504012115.09048.davemgarrett@gmail.com> Date: Wed, 1 Apr 2015 20:38:49 -0500 Message-ID: From: Nico Williams To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 01:38:51 -0000 On Wed, Apr 1, 2015 at 8:15 PM, Dave Garrett wrote= : > On Wednesday, April 01, 2015 08:48:36 pm Nico Williams wrote: >> It would be better to also negotiate (cipher+mode), (hash), (KDF), and >> (key agreement+server authentication) separately. > > I'm definitely in favor of reducing the combinatorial explosion in suites= and moving hash, KEA, & etc. into a separate negotiation. Instead of an ex= tension, you could just do the same thing again, really. Reserve a sizable = block of the 16-bit suite space for hashes and another for KEA and list the= m all in the same cipher_suites array. TLS1 would ignore them, and TLS2 wou= ld just see points between [a,b] are hash, [b+1,c] are KEA, etc. So, new re= gistries in the existing space, just dumped all into the same pile. Yes, we could patch in a-la-carte ciphersuite negotiation by having non-functional ciphersuites that wild-card all but the one kind of thing. You offer those. A matching functional ciphersuite gets selected. Done. TLS_*_*_WITH_AES_GCM_* TLS_*_*_WITH_*_*_SHA384 TLS_ECDHE_*_WITH_*_*_* ... Nico -- From nobody Wed Apr 1 19:05: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 4499D1AD35D for ; Wed, 1 Apr 2015 19:05:36 -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 UbnoA41_nQSk for ; Wed, 1 Apr 2015 19:05:32 -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 71F481AD2EE for ; Wed, 1 Apr 2015 19:05:21 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id C7A912ADA7; Thu, 2 Apr 2015 04:05:17 +0200 (CEST) X-purgate-ID: 152705::1427940319-00003099-1F6C9EC1/0/0 X-purgate-size: 1896 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id E2CBA471B4; Thu, 2 Apr 2015 04:05:17 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id DBBDF1B25A; Thu, 2 Apr 2015 04:05:17 +0200 (CEST) In-Reply-To: <551BBD6F.2070507@cs.tcd.ie> To: Stephen Farrell Date: Thu, 2 Apr 2015 04:05:17 +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: <20150402020517.DBBDF1B25A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 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, 02 Apr 2015 02:05:36 -0000 Stephen Farrell wrote: >Martin Rex wrote: >> >> I think Stephen might have meant something else. >> >> RFC4492 contains the following explicit prohibition (Section 4, 4th paragr.): >> >> https://tools.ietf.org/html/rfc4492#section-4 >> >> >> The client MUST NOT include these extensions in the ClientHello >> message if it does not propose any ECC cipher suites. > > Ooh - good catch, I hadn't spotted that. This draft is updating 4492 > though so we can validly change that, but if we're doing so (and I > guess we are) then it'd be better to be very explicit about it, e.g. > by adding a sentence saying that we're changing that specific MUST NOT. I believe that this is *NOT* an option here (more below). > >> and the above requirement seems to prohibit a non-ECC client from >> using the named FFDHE parameters through the ECC named curve extension >> _without_ accompanying ECC cipher suites. > > Right. That's the kind of thing I was wondering about. > > I'll happily accept the wg's word on this, but to what extent have > we checked that we're not breaking something with this change in > semantics. (It's a small, but real, change.) The problem with the quoted requirement in rfc4492 is (similar to several highly bogus and/or overbroad requirements in other TLS-related RFCs), that it does not distinguish PDU content from communication peer behaviour, and does not declare whether that requirement applies only to sender or also to recipient. The result is, that there may easily exist server implementation of rfc4492 which abort the TLS handshake when they receive a TLS ClientHello with the TLS ECC named_curve extension (and only ffdhe named curves in it) but no accompanying ECC cipher suites in the ClientHello cipher_suites_list, and that interoperability failure OUGHT to be avoided. REALLY. -Martin From nobody Wed Apr 1 19:17: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 EC94D1A1B12 for ; Wed, 1 Apr 2015 19:17:26 -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 DIqEJvW16YDR for ; Wed, 1 Apr 2015 19:17:25 -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 5D8731A1A97 for ; Wed, 1 Apr 2015 19:17:25 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id C039F44950; Thu, 2 Apr 2015 04:17:23 +0200 (CEST) X-purgate-ID: 152705::1427941043-0000765A-9719369D/0/0 X-purgate-size: 1609 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id B727E46418; Thu, 2 Apr 2015 04:17:23 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AD9EC1B25A; Thu, 2 Apr 2015 04:17:23 +0200 (CEST) In-Reply-To: <201504012115.09048.davemgarrett@gmail.com> To: Dave Garrett Date: Thu, 2 Apr 2015 04:17: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: <20150402021723.AD9EC1B25A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] DSA should die 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, 02 Apr 2015 02:17:27 -0000 Dave Garrett wrote: > On Wednesday, April 01, 2015 08:40:40 pm Stephen Farrell wrote: >> >> >> Here's a suggestion: why pick 'em off one by one? How about >> creating a new registry that only includes stuff we think is >> really good for TLS1.3? > > I don't think a whole new registry is a good idea. The ClientHello > has to stay the same for backwards compatibility, and cipher suites > will need to be listed for TLS 1.2 compatibility at least. > Creating a whole new system is only good if you can completely > ignore the old one. > > There's plenty of space in the current registry if you want to > start over. Just say 0xD000 and up is for TLS2 suites, and all > below are TLS1. (at this point it's definitely time for 2.0) > Define TLS2 codepoints for valid combinations for TLS2 and the TLS1 > would be invalid to negotiate for TLS2 but in there for TLS1. I agree that ClientHello needs to remain backwards-compatible. But how about using the Cipher Suites registry in a more creative fashion. For TLSv1.3, we could do the negotiation through he cipher suites list more like this: 0x10,0xXX specifies a key exchange algorithm (XX) 256 codepoints 0x12,0xYY specifies an authentication algorithm (YY) 256 codepoints 0x14,0xZZ specifies a symmetric encryption scheme (ZZ) 256 codepoints 0x16,0xQQ specifies a mac algorithm (QQ) 256 codepoints 0x18,0xPP specifies a PRF algorithm (PP) 256 codepoints (with a little room in between if we ever exceed the 256 codepoints) -Martin From nobody Wed Apr 1 22:03: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 B3A3D1B2ACD for ; Wed, 1 Apr 2015 22:03: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 lRQVck0NxmOG for ; Wed, 1 Apr 2015 22:03:34 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 DAC011AC3F2 for ; Wed, 1 Apr 2015 22:03:33 -0700 (PDT) Received: by qgep97 with SMTP id p97so61358163qge.1 for ; Wed, 01 Apr 2015 22:03: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=9JJOPjVqoYMGha6JpuT9Ura+oFFARTeC5HxZhaNoVyo=; b=BqV1yIKho9dL1e5FVAPoaGl9kSzgF0233f/7ZuIzaC9gXhxiR7+AIl51nX8KXd8cka jkbxCM510AW3WKyWCnyKmgfOLf7o+8i2pq/2IDonIsBwkRS9I3D1c9lYobjDeFG/RCr8 +xiqLds4f4U0OutCTV+Gf4sMSYTht9XkGhTJudc8RsTOWL9vm8vttfJY1PLo5AJwxAfO k2OeoBbW1f0lAm9M+4zPl1OfflKkDOxDZ1e+/nGV6xFeqxPC/R5J9wIKb4+jVbVQhkF/ mRk8UXTlSHL5m0zyj08ZhK4nW1p3GiFuVWE/NqJh7z9hqQLOug7EPhVYhNjd4yjk4fFB vUPg== X-Received: by 10.229.118.5 with SMTP id t5mr60808912qcq.19.1427951013170; Wed, 01 Apr 2015 22:03: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 187sm2823612qhv.8.2015.04.01.22.03.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Apr 2015 22:03:32 -0700 (PDT) From: Dave Garrett To: mrex@sap.com Date: Thu, 2 Apr 2015 01:03:31 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150402021723.AD9EC1B25A@ld9781.wdf.sap.corp> In-Reply-To: <20150402021723.AD9EC1B25A@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201504020103.31536.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] 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: Thu, 02 Apr 2015 05:03:35 -0000 On Wednesday, April 01, 2015 09:15:08 pm Dave Garrett wrote: > There's plenty of space in the current registry if you want to start > over. Just say 0xD000 and up is for TLS2 suites, and all below are TLS1. > (at this point it's definitely time for 2.0) Define TLS2 codepoints for > valid combinations for TLS2 and the TLS1 would be invalid to negotiate > for TLS2 but in there for TLS1. This would cost a few more bytes to list > AES-GCM in both TLS1 & TLS2 format in the same list, but resorting to a > whole new system would add more bytes anyway, along with another registry > to keep track of. [...] > I'm definitely in favor of reducing the combinatorial explosion in suites > and moving hash, KEA, & etc. into a separate negotiation. Instead of an > extension, you could just do the same thing again, really. Reserve a > sizable block of the 16-bit suite space for hashes and another for KEA > and list them all in the same cipher_suites array. TLS1 would ignore > them, and TLS2 would just see points between [a,b] are hash, [b+1,c] are > KEA, etc. So, new registries in the existing space, just dumped all into > the same pile. On Wednesday, April 01, 2015 10:17:23 pm Martin Rex wrote: > But how about using the Cipher Suites registry in a more creative > fashion. > > For TLSv1.3, we could do the negotiation through he cipher suites list > more like this: > > 0x10,0xXX specifies a key exchange algorithm (XX) 256 codepoints > 0x12,0xYY specifies an authentication algorithm (YY) 256 codepoints > 0x14,0xZZ specifies a symmetric encryption scheme (ZZ) 256 codepoints > 0x16,0xQQ specifies a mac algorithm (QQ) 256 codepoints > 0x18,0xPP specifies a PRF algorithm (PP) 256 codepoints > > (with a little room in between if we ever exceed the 256 codepoints) Yes, that's basically what I'm proposing. Myself, Nico, and you are all just describing the same sort of scheme differently. Yours is the clearest thus far, as it covers everything we might want here. The only difference I suggest is picking points all above a threshold that separates new from old so filtering out the old system trivial. That looks to be around 0xD000, or 0xC100 if you want to get closer to the current highest assigned value. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 Dave From nobody Wed Apr 1 22:32: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 9D7711A8822 for ; Wed, 1 Apr 2015 22:32:22 -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_34=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 WcmKl_5CZMhH for ; Wed, 1 Apr 2015 22:32:21 -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 C27001A0383 for ; Wed, 1 Apr 2015 22:32:20 -0700 (PDT) Received: by wizk4 with SMTP id k4so3229115wiz.1 for ; Wed, 01 Apr 2015 22:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GmurxFwHuDKaWYFXDFz1A59cBagmSl+UB6XnTyVtwTk=; b=pS2YplPYsHUkKFevjGDIHGOZNSaIu4C6VO84SLH1j/EBCKRqCAHwUeYu3U2Rsv1ZWi tHneP9llnORmGetqf3wrL4oJwXQCCDWvmdboB1LNPcHVvkXhlzPYT06zgKGYBAU48uES mx9f2WGhesWg1EpfyYYef0rYvP0avhWSn/1N7hvYN48t3DvnP0w9kGjDuj6vLTkmhcHF K2LMjbfUs9rRqbJlcTTWKLQwFgEhks0CWvEa/hFs9OUcWwuP4x+VRk6L5be/a3TYJdwI X9ZhRwAYAidZZDkcl0QRwgFSVhmaZT6CZ09CwzVw3j1PXYlRlseXza8v9ieLkZnjnMYe rSOA== MIME-Version: 1.0 X-Received: by 10.180.86.162 with SMTP id q2mr21162438wiz.26.1427952739539; Wed, 01 Apr 2015 22:32:19 -0700 (PDT) Received: by 10.194.136.233 with HTTP; Wed, 1 Apr 2015 22:32:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Apr 2015 22:32:19 -0700 Message-ID: From: Watson Ladd To: Joseph Salowey Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 05:32:22 -0000 On Wed, Apr 1, 2015 at 11:12 AM, Joseph Salowey wrote: > We did not get a chance to talk about MTI algorithms in Dallas, but the > chairs would like to judge consensus for the algorithms discussed in the > interim. The CFRG has closed or will close soon on ChaCha20 and curve 25519 > recommendations so they are included. We will be calling for acceptance to > bring drafts on these into the working group shortly. > > Keep in mind that mandatory to implement (MTI) is not mandatory to use and > that it is expected that there will be profiles for specific environments. > > Below is the proposed algorithm list that had consensus at the Seattle > Interim. Please reply on the TLS mailing list indicating whether or not you > agree with the consensus. If not, please indicate why. This consensus call > will close on April, 23, 2015. > > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 > > o Hash: > MUST SHA-256 > > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 > > o Signature: > MUST ECDSA P-256 > MUST RSA > > Thanks, > > J&S I disagree with this consensus. Many devices have hardware accelerated AES, but not GCM. As it stands we don't have an efficient performer on these devices: AES+HMAC is probably the best option on these devices. I also don't like the idea of making non-interoperable profiles for different environments. Sincerely, Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Apr 1 22:32: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 204F81B2AE5 for ; Wed, 1 Apr 2015 22:32:55 -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 ri-Gj3GSnZhQ for ; Wed, 1 Apr 2015 22:32:53 -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 655BE1B2AE4 for ; Wed, 1 Apr 2015 22:32:53 -0700 (PDT) Received: by widdi4 with SMTP id di4so66767985wid.0 for ; Wed, 01 Apr 2015 22:32:52 -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=hhEx8DlditHXB93jDcp7eMN/O7A0Br93JBMM1xdodTE=; b=cbg42ISIW3WaxCGQJ/9sZvF4nYQ8Na1Dl6hi6vqvu2FGvzAk6JjlDrVcmRW+3z0gWJ hoN1/iiMsci95kjQLMGDpzY1U2FqAhJ96ggQKR/Lk8aU0cTpzVrO7q3Z6/5Qt4akV67y aGqbyDf00tv/x3d4OwQU0oUA/tbpEKXOUUEhH9PLRTjqOKssw4jL3c3d/zhCLgviJiIq xOzca9tpVM2KTmFYJU2BySH49Dw2sor1I239ZoWtwG2jTF8JcAbCE4b8tcE5LYlVN9qc G46fzePJADubqj5enQ8L28TGOfSz1UrxRVDRetViDiTZ1mooxNTvBN0fhFsuSq5KHQVt gk6g== MIME-Version: 1.0 X-Received: by 10.180.80.101 with SMTP id q5mr21312554wix.83.1427952772125; Wed, 01 Apr 2015 22:32:52 -0700 (PDT) Received: by 10.194.136.233 with HTTP; Wed, 1 Apr 2015 22:32:52 -0700 (PDT) In-Reply-To: <20150402021723.AD9EC1B25A@ld9781.wdf.sap.corp> References: <201504012115.09048.davemgarrett@gmail.com> <20150402021723.AD9EC1B25A@ld9781.wdf.sap.corp> Date: Wed, 1 Apr 2015 22:32:52 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 05:32:55 -0000 On Wed, Apr 1, 2015 at 7:17 PM, Martin Rex wrote: > Dave Garrett wrote: >> On Wednesday, April 01, 2015 08:40:40 pm Stephen Farrell wrote: >>> >>> >>> Here's a suggestion: why pick 'em off one by one? How about >>> creating a new registry that only includes stuff we think is >>> really good for TLS1.3? >> >> I don't think a whole new registry is a good idea. The ClientHello >> has to stay the same for backwards compatibility, and cipher suites >> will need to be listed for TLS 1.2 compatibility at least. >> Creating a whole new system is only good if you can completely >> ignore the old one. >> >> There's plenty of space in the current registry if you want to >> start over. Just say 0xD000 and up is for TLS2 suites, and all >> below are TLS1. (at this point it's definitely time for 2.0) >> Define TLS2 codepoints for valid combinations for TLS2 and the TLS1 >> would be invalid to negotiate for TLS2 but in there for TLS1. > > I agree that ClientHello needs to remain backwards-compatible. > > But how about using the Cipher Suites registry in a more creative fashion. > > For TLSv1.3, we could do the negotiation through he cipher suites list > more like this: > > 0x10,0xXX specifies a key exchange algorithm (XX) 256 codepoints > 0x12,0xYY specifies an authentication algorithm (YY) 256 codepoints > 0x14,0xZZ specifies a symmetric encryption scheme (ZZ) 256 codepoints > 0x16,0xQQ specifies a mac algorithm (QQ) 256 codepoints > 0x18,0xPP specifies a PRF algorithm (PP) 256 codepoints > > (with a little room in between if we ever exceed the 256 codepoints) I don't understand why we want a different mechanism for TLS 1.3 and TLS 1.2 ciphersuite negotiation. Even worse, I don't see how something like SRP fits cleanly into the scheme above. Yes, SRP is little-used, but people seem to think it's important. What's wrong with the existing mechanism, if we remove things we don't want? Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Apr 1 22:49: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 DA7281B2AEE for ; Wed, 1 Apr 2015 22:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_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 N07mbocRjW6J for ; Wed, 1 Apr 2015 22:49:19 -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 94DE61B2AF6 for ; Wed, 1 Apr 2015 22:49:16 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 5F9202AC06E for ; Wed, 1 Apr 2015 22:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=SCQQx0+WXI2XQ9wD4gd5 Z0YnNwY=; b=WtOjPSJ4LaIQThlFatZotB0IHto23TOX0nNiBZ7bRZc1MgMIPuXM HWx8jmyzwcmldA8B0dwJxB+ez5LAsK9VOeDLtVKJfss6HLJn3jETJhmjkig3nzz0 zDZaU32FamJnGQqtmfFHaoloXkR+WFXa46dcdTjCX9vQVB8EIln9RfM= Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 44DCE2AC059 for ; Wed, 1 Apr 2015 22:49:15 -0700 (PDT) Received: by iedm5 with SMTP id m5so61390015ied.3 for ; Wed, 01 Apr 2015 22:49:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.226.69 with SMTP id iv5mr70329131icb.58.1427953754885; Wed, 01 Apr 2015 22:49:14 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 22:49:14 -0700 (PDT) In-Reply-To: References: <201504012115.09048.davemgarrett@gmail.com> <20150402021723.AD9EC1B25A@ld9781.wdf.sap.corp> Date: Thu, 2 Apr 2015 00:49:14 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c319a650ea0c0512b76405 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 05:49:21 -0000 --001a11c319a650ea0c0512b76405 Content-Type: text/plain; charset=UTF-8 On Thursday, April 2, 2015, Watson Ladd wrote: > On Wed, Apr 1, 2015 at 7:17 PM, Martin Rex > > wrote: > > Dave Garrett wrote: > >> On Wednesday, April 01, 2015 08:40:40 pm Stephen Farrell wrote: > >>> > >>> > >>> Here's a suggestion: why pick 'em off one by one? How about > >>> creating a new registry that only includes stuff we think is > >>> really good for TLS1.3? > >> > >> I don't think a whole new registry is a good idea. The ClientHello > >> has to stay the same for backwards compatibility, and cipher suites > >> will need to be listed for TLS 1.2 compatibility at least. > >> Creating a whole new system is only good if you can completely > >> ignore the old one. > >> > >> There's plenty of space in the current registry if you want to > >> start over. Just say 0xD000 and up is for TLS2 suites, and all > >> below are TLS1. (at this point it's definitely time for 2.0) > >> Define TLS2 codepoints for valid combinations for TLS2 and the TLS1 > >> would be invalid to negotiate for TLS2 but in there for TLS1. > > > > I agree that ClientHello needs to remain backwards-compatible. > > > > But how about using the Cipher Suites registry in a more creative > fashion. > > > > For TLSv1.3, we could do the negotiation through he cipher suites list > > more like this: > > > > 0x10,0xXX specifies a key exchange algorithm (XX) 256 codepoints > > 0x12,0xYY specifies an authentication algorithm (YY) 256 codepoints > > 0x14,0xZZ specifies a symmetric encryption scheme (ZZ) 256 > codepoints > > 0x16,0xQQ specifies a mac algorithm (QQ) 256 codepoints > > 0x18,0xPP specifies a PRF algorithm (PP) 256 codepoints > > > > (with a little room in between if we ever exceed the 256 codepoints) > > I don't understand why we want a different mechanism for TLS 1.3 and > TLS 1.2 ciphersuite negotiation. Even worse, I don't see how something > like SRP fits cleanly into the scheme above. Yes, SRP is little-used, > but people seem to think it's important. > > What's wrong with the existing mechanism, if we remove things we don't > want? For one: some combinations that are useful get lost in the shuffle because there are so many ciphersuites. It has happened before and it will happen again. A la carte combination is a useful compression function for: us, operators, and the network. It's a compression function that leaves us with the essential information that we really need. There are two separate proposals here: a la carte registration, and a la carte negotiation on the wire. The latter is only an on-the-wire compression function -- perhaps it's too disruptive, though now is the only time it could happen. There is no excuse for not doing the former. Nico -- --001a11c319a650ea0c0512b76405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, April 2, 2015, Watson Ladd <watsonbladd@gmail.com> wrote:
On Wed, Apr 1, 2015 at 7:17 PM, Martin Rex <mrex@sap.c= om> wrote:
> Dave Garrett wrote:
>> On Wednesday, April 01, 2015 08:40:40 pm Stephen Farrell wrote: >>> <no-hats-except-the-330+-ciphersuites-is-crap-hat>
>>>
>>> Here's a suggestion: why pick 'em off one by one? How = about
>>> creating a new registry that only includes stuff we think is >>> really good for TLS1.3?
>>
>> I don't think a whole new registry is a good idea. The ClientH= ello
>> has to stay the same for backwards compatibility, and cipher suite= s
>> will need to be listed for TLS 1.2 compatibility at least.
>> Creating a whole new system is only good if you can completely
>> ignore the old one.
>>
>> There's plenty of space in the current registry if you want to=
>> start over. Just say 0xD000 and up is for TLS2 suites, and all
>> below are TLS1. (at this point it's definitely time for 2.0) >> Define TLS2 codepoints for valid combinations for TLS2 and the TLS= 1
>> would be invalid to negotiate for TLS2 but in there for TLS1.
>
> I agree that ClientHello needs to remain backwards-compatible.
>
> But how about using the Cipher Suites registry in a more creative fash= ion.
>
> For TLSv1.3, we could do the negotiation through he cipher suites list=
> more like this:
>
>=C2=A0 =C2=A0 0x10,0xXX=C2=A0 =C2=A0 specifies a key exchange algorithm= (XX) 256 codepoints
>=C2=A0 =C2=A0 0x12,0xYY=C2=A0 =C2=A0 specifies an authentication algori= thm (YY) 256 codepoints
>=C2=A0 =C2=A0 0x14,0xZZ=C2=A0 =C2=A0 specifies a symmetric encryption s= cheme (ZZ) 256 codepoints
>=C2=A0 =C2=A0 0x16,0xQQ=C2=A0 =C2=A0 specifies a mac algorithm (QQ) 256= codepoints
>=C2=A0 =C2=A0 0x18,0xPP=C2=A0 =C2=A0 specifies a PRF algorithm (PP) 256= codepoints
>
> (with a little room in between if we ever exceed the 256 codepoints)
I don't understand why we want a different mechanism for TLS 1.3 and TLS 1.2 ciphersuite negotiation. Even worse, I don't see how something<= br> like SRP fits cleanly into the scheme above. Yes, SRP is little-used,
but people seem to think it's important.

What's wrong with the existing mechanism, if we remove things we don= 9;t want?

For one: some combinations that a= re useful get lost in the shuffle because there are so many ciphersuites.= =C2=A0 It has happened before and it will happen again.=C2=A0 A la carte co= mbination is a useful compression function for: us, operators, and the netw= ork.=C2=A0 It's a compression function that leaves us with the essentia= l information that we really need.

There are two s= eparate proposals here: a la carte registration, and a la carte negotiation= on the wire.=C2=A0 The latter is only an on-the-wire compression function = -- perhaps it's too disruptive, though now is the only time it could ha= ppen.=C2=A0 There is no excuse for not doing the former.

Nico
--=C2=A0
--001a11c319a650ea0c0512b76405-- From nobody Thu Apr 2 00:39: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 D8DF61B2BA8 for ; Thu, 2 Apr 2015 00:39: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 sk9BNRLvh_-D for ; Thu, 2 Apr 2015 00:39:32 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45F91B2BA6 for ; Thu, 2 Apr 2015 00:39:32 -0700 (PDT) Received: by igbud6 with SMTP id ud6so69809076igb.1 for ; Thu, 02 Apr 2015 00:39: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=v0bXdKQPOIB3QgtSjR9VWc2zmzLzyFqzQWRGRDaRKWQ=; b=HKnMWrBCpPVfbCCkLKy+WOWlvMmdv2nrZv80XmJEBiAM8kV8pn9yBZ4cwRiSYyxrPV x8vd1bQmjI7JMH1DDpCHo3cW9ctQDGCfEPObtSycNSSFK4OU35j44xtmVDCDtljtF4IE +hbfE0+bnsC2W+4NhMJpAYvKDfjtIvGoH+MlNYTsBRfCACwoGNzx4xLJNofYNN1Y4wg7 vsD0ucMnFKJycAuN0NIY7Kij7W25sh+zUedt1m1PgSHoWEdkWgFTSHv7pZhC+ECboaMF 5gBhsGEYjFLY5W26GBzKFPvjSqAKe/5ORk6XkwFyJb3gsKOX/4p4gV9siBxk6itqntox W+Iw== MIME-Version: 1.0 X-Received: by 10.42.14.131 with SMTP id h3mr7369951ica.7.1427960372200; Thu, 02 Apr 2015 00:39:32 -0700 (PDT) Received: by 10.107.142.148 with HTTP; Thu, 2 Apr 2015 00:39:32 -0700 (PDT) In-Reply-To: References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@cs.tcd.ie> <201504012115.09048.davemgarrett@gmail.com> Date: Thu, 2 Apr 2015 09:39:32 +0200 Message-ID: From: CodesInChaos To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 07:39:34 -0000 Nico Williams nico@cryptonector.com wrote: > Yes, we could patch in a-la-carte ciphersuite negotiation by having > non-functional ciphersuites that wild-card all but the one kind of > thing. You offer those. A matching functional ciphersuite gets > selected. Done. > > TLS_*_*_WITH_AES_GCM_* > TLS_*_*_WITH_*_*_SHA384 > TLS_ECDHE_*_WITH_*_*_* > ... I think full a-la-carte is too complex. But I'm for negotiating the handshake and symmetric crypto separately. They're already very loosely coupled and most proposals that introduce/obsolete ciphersuites are only interested in one of the two sides, with the other being only an afterthought. From nobody Thu Apr 2 01:59: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 737371B2C0E for ; Thu, 2 Apr 2015 01:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, 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 87O5YskxDUy9 for ; Thu, 2 Apr 2015 01:59:07 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE521B2C0D for ; Thu, 2 Apr 2015 01:59:04 -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=1427965148; x=1459501148; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BVn4FziuDjhx1DEZNq+ERg6lGSo93iN8X1dyVjRhbuA=; b=KeFTzDEUkeugXuU7wt/OeGAkcmF6WMhTH7hNIhBu9KhFws0DPKFcJaEU MTSEMvey8NTfj/sOGKbJzMKJkHcbCdzaBQFUv06GfecuzRikziHD/ASp+ Fq845fzEsZsbkd7KVc0ahK/zkekc86txz3PFmNYo+zGjC/MaGSWpoOwpp M=; X-IronPort-AV: E=Sophos;i="5.11,509,1422874800"; d="scan'208";a="318640645" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 02 Apr 2015 21:59:02 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.129]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 2 Apr 2015 21:59:00 +1300 From: Peter Gutmann To: "" Thread-Topic: =?Windows-1252?Q?[TLS]_confirming_the_room=92s_consensus:_adopt_HKDF_PRF_?= =?Windows-1252?Q?for_TLS_1.3?= Thread-Index: AdBtI0LriC002d9AQd2CQh5WncxaLA== Date: Thu, 2 Apr 2015 08:59:00 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFD1029@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] =?windows-1252?q?_confirming_the_room=92s_consensus=3A_adop?= =?windows-1252?q?t_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 08:59:10 -0000 Sean Turner writes:=0A= =0A= >This message is to confirm the consensus reached @ the IETF 92 TLS session= in=0A= >Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an HKD= F-=0A= >based PRF (see http://datatracker.ietf.org/doc/rfc5869/?include_text=3D1).= =0A= >=0A= >Please indicate whether or not you agree with the consensus by 2015-04-17.= If=0A= >not, please indicate why. Also, please note that we're interested in=0A= >uncovering new issues not rehashing issues already discussed.=0A= =0A= Yes, definitely.=0A= =0A= Peter.= From nobody Thu Apr 2 02:07: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 347CE1B2C10 for ; Thu, 2 Apr 2015 02:07: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 f-oiFR5zttEp for ; Thu, 2 Apr 2015 02:07:31 -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 BD9601B2B3C for ; Thu, 2 Apr 2015 02:07:30 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so97482174wib.1 for ; Thu, 02 Apr 2015 02:07: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=4R6ghUj2r7gTWM2c6Aj4osJnhdK+K635qmB6habPVGs=; b=QZDzc+L3i9xKXxHCre4KGYc06cEIfwNXvvbo/oQ4DGy9f1fR08q4/dwt03hFX5qEbY w8jqqyOeiwe+3Aky5B46OObK3rfoJAuS+PtlRcVaLpBXYIvUxN9YUXycdTcKsp0kilwg yNxZKaRtnZJOvykzG7ryTCeXMBgIvWDEc90/ffOB/VvMobCfgrSgIr/QMTiNbaRVX+uk x27oXzci+BhmHw69TksEHWOw+lZ80kMRlcyY71EIzPxmNAOTvc8CVjL4zxJ8Yw266MfW pt843dfEtz4qdh9P2L3iVE8x1Fo2LiQWQXAnWYbHk21tCeu0XmjsGKYqH0bJ5Ti47CIp tONQ== X-Gm-Message-State: ALoCoQm9o/+D5TP8nI9NCM8+0IzdL6t8Oq/iWuPjsB8KQ3lgPGNQ+YhPe0nMMSkaoqz8uQ1Klsdj X-Received: by 10.180.93.5 with SMTP id cq5mr22405441wib.18.1427965623917; Thu, 02 Apr 2015 02:07:03 -0700 (PDT) Received: from [10.60.20.18] ([193.170.94.190]) by mx.google.com with ESMTPSA id fm10sm6797985wib.7.2015.04.02.02.07.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 02:07:02 -0700 (PDT) Message-ID: <551D06B3.2020103@azet.org> Date: Thu, 02 Apr 2015 11:06:59 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Yaron Sheffer References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> In-Reply-To: <551C9170.8050708@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0DF20CB0F99AFD42582FB87D" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 09:07:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0DF20CB0F99AFD42582FB87D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yaron, Yaron Sheffer wrote: > Also, just wondering: is ECDSA popular enough today to be a MUST? For > example, is the CAB Forum pushing its members to deploy such certificat= es? As far as I know most commercial CAs still are not willing/able to issue ECDSA certificates. Maybe ECDSA will go under in history entirely in a couple of years w.r.t. Certificates? Aaron --------------enig0DF20CB0F99AFD42582FB87D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVHQa0AAoJEOTbZJL9ubXVCBwP/2oz8DUWUPmZsLOQS+eczRiu AN12du33NS/sHSSveRAUGCP5Cfl8p1FSyaPnSu+bGq2bR6dN6bcEdqXkiL9iUPy8 G/QhM6rCmqaDaoe6GhLhCDSAyIa7CuiJ/2Q13HQxUmSKRQaxXKnI/SMJGr3ZY5qk J07THTBr9VcaxGuC+ZIghpYl0ba0k5VQsNShcdLZub54n5VIwRa4rj+wsnPhGKbu hA68DCsyByDWW3Pf9AJt4vPS4hhdiQMUMqlcSiHnh4U9pl4nfpadrMDIRKmZ4dM1 RR6rCygRSCK6C0NWftOtZjsQ/+Mh8Q5DsDxv8c2Zxyqd7vwQibruKkbwJdvGF9fb emqujDwbeFt2yE+cBUygiFDbTIHvvgqZOpKzhX2ynieErXMJzMY2Yq6iRfxQgzth 4PzxlL62MIRJ1lY2LUniCt3F2w71LMHpwRygmGaioe+Lxg+lRjA1BKS2FOxZQf+C R1fZm63c8WSkHNQJOIidInye+EDBkW8Fnh7S9yfG1Aqxv0vdig5C7J0ReJaD4zWj jEfbZ+zqKSJPgO1NLAJKOxkncNq8pOKUmtxeR+0IPymBIUYMquIoW4KFE0ZhI7U/ PqKuV6ZKqlTV8m+nBxIR+wSARCDg0Fxh+8xbvMn5QKB3LMJiaJgvtbuLR9axsWxt 8Ts/sNZZpBro1wR6xLp4 =XJL4 -----END PGP SIGNATURE----- --------------enig0DF20CB0F99AFD42582FB87D-- From nobody Thu Apr 2 02:12: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 C787D1B2C10 for ; Thu, 2 Apr 2015 02:12:02 -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 tBeR70Ezuxpm for ; Thu, 2 Apr 2015 02:12:00 -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 0B30F1B2C11 for ; Thu, 2 Apr 2015 02:12:00 -0700 (PDT) Received: (qmail 696 invoked by uid 1004); 2 Apr 2015 09:11:58 -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; Thu, 02 Apr 2015 10:11:58 +0100 Received: (qmail 25101 invoked by uid 1000); 2 Apr 2015 09:11:58 -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; Thu, 02 Apr 2015 10:11:58 +0100 Message-ID: <551D07DE.70705@comodo.com> Date: Thu, 02 Apr 2015 10:11:58 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yaron Sheffer , Yoav Nir , Joseph Salowey References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> In-Reply-To: <551C9170.8050708@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 09:12:03 -0000 On 02/04/15 01:46, Yaron Sheffer wrote: > Also, just wondering: is ECDSA popular enough today to be a MUST? All of the certificates used by CloudFlare's "Universal SSL" are ECDSA certificates issued by Comodo. When CloudFlare announced "Universal SSL" six months ago, they said: "Yesterday, there were about 2 million sites active on the Internet that supported encrypted connections. By the end of the day today, we'll have doubled that." Before "Universal SSL", Netcraft's SSL Survey found only ~80 ECDSA publicly-trusted ECDSA certs. But now, simply because of "Universal SSL", I would definitely say that ECDSA is "popular enough today to be a MUST". > For example, is the CAB Forum pushing its members to deploy such certificates? Pushing? Not that I've noticed. [1] https://blog.cloudflare.com/introducing-universal-ssl/ -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Apr 2 03:38: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 818D41B2C4A for ; Thu, 2 Apr 2015 03:38:47 -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 IW4Re1in1kwI for ; Thu, 2 Apr 2015 03:38:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0995B1B2C3F for ; Thu, 2 Apr 2015 03:38:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 01CEFBF08; Thu, 2 Apr 2015 11:38:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO6eQMLY0e3L; Thu, 2 Apr 2015 11:38:39 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CF941BEFE; Thu, 2 Apr 2015 11:38:39 +0100 (IST) Message-ID: <551D1C2F.2070104@cs.tcd.ie> Date: Thu, 02 Apr 2015 11:38:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mrex@sap.com References: <20150402020517.DBBDF1B25A@ld9781.wdf.sap.corp> In-Reply-To: <20150402020517.DBBDF1B25A@ld9781.wdf.sap.corp> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 10:38:47 -0000 On 02/04/15 03:05, Martin Rex wrote: > Stephen Farrell wrote: >> Martin Rex wrote: >>> >>> I think Stephen might have meant something else. >>> >>> RFC4492 contains the following explicit prohibition (Section 4, 4th paragr.): >>> >>> https://tools.ietf.org/html/rfc4492#section-4 >>> >>> >>> The client MUST NOT include these extensions in the ClientHello >>> message if it does not propose any ECC cipher suites. >> >> Ooh - good catch, I hadn't spotted that. This draft is updating 4492 >> though so we can validly change that, but if we're doing so (and I >> guess we are) then it'd be better to be very explicit about it, e.g. >> by adding a sentence saying that we're changing that specific MUST NOT. > > I believe that this is *NOT* an option here (more below). > > >> >>> and the above requirement seems to prohibit a non-ECC client from >>> using the named FFDHE parameters through the ECC named curve extension >>> _without_ accompanying ECC cipher suites. >> >> Right. That's the kind of thing I was wondering about. >> >> I'll happily accept the wg's word on this, but to what extent have >> we checked that we're not breaking something with this change in >> semantics. (It's a small, but real, change.) > > > The problem with the quoted requirement in rfc4492 is (similar to several > highly bogus and/or overbroad requirements in other TLS-related RFCs), > that it does not distinguish PDU content from communication peer behaviour, > and does not declare whether that requirement applies only to sender > or also to recipient. > > > The result is, that there may easily exist server implementation of rfc4492 > which abort the TLS handshake when they receive a TLS ClientHello with > the TLS ECC named_curve extension (and only ffdhe named curves in it) > but no accompanying ECC cipher suites in the ClientHello cipher_suites_list, > and that interoperability failure OUGHT to be avoided. REALLY. Right, it is a possible interop break. It seems the browser folks are confident it won't bite them (did they test yet without any ECC ciphersuites?) but that (so far) we've not heard from others. I'd like to hear more myself, but this is something the WG could choose to do and, if done carefully, that can be fine. OTOH, it could also be a mistake, if not done sufficiently carefully, which is why I'm asking about it. (Right now, I think I need more input still, but it could also be that that's already in the list archive, I'm not sure.) Cheers, S. > > > -Martin > From nobody Thu Apr 2 05:45: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 EAABC1A8A07 for ; Thu, 2 Apr 2015 05:45: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 wGeFKFKO7IP8 for ; Thu, 2 Apr 2015 05:45:21 -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 0617C1A8923 for ; Thu, 2 Apr 2015 05:45:21 -0700 (PDT) Received: by wixm2 with SMTP id m2so55239672wix.0 for ; Thu, 02 Apr 2015 05:45:19 -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=9MrbeqYDXVd/sOhCywa8+byZGOFFv3FPUDHGUEOTT1c=; b=FZ4PqOP0L5k6prlZziw1UT8J568bT+2c9Mu52K99+ahUJq8qcfRbqiVB7QGrPTBOr6 VdZuqzh5YC2ugGgPIwxsdFdXpQaYz214PDQnnULqdLeQhT6rC9gQSp/tlxyp81H7FGtp R5n8ASRpnx9hS6MHYdh1H3rFTn73AoakgJRngTynZrnYBZn9BU3/yNdIPk03oMvwBUsZ NJJtHYi4AWAF2p2RS4VwnvOyUSlb3N34yn64zT4iAsQcnJFU7T5+WiK3huRbpg4wnnDu tpXmcSwUKZBRLK5D2BaMlgb2h9qotu2jQghbp9Ehp7QhGT+HeTCWdxKP/0JvA6BV2WYa o/6w== X-Received: by 10.194.158.234 with SMTP id wx10mr95059193wjb.23.1427978719787; Thu, 02 Apr 2015 05:45:19 -0700 (PDT) Received: from [10.32.181.183] ([37.205.56.247]) by mx.google.com with ESMTPSA id gy9sm7583558wib.12.2015.04.02.05.45.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 05:45:18 -0700 (PDT) Message-ID: <551D2D06.6000603@gmail.com> Date: Thu, 02 Apr 2015 04:50:30 -0700 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Thomson References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 12:45:23 -0000 > On 1 April 2015 at 17:46, Yaron Sheffer wrote: >> AES-256-GCM and SHA-384. Doesn't it make sense to have them as SHOULD, > > I don't see much point. All involved likely know if they need > something that strong, which is way down there in the "we might need > it someday" category [1]. > > [1] http://www.keylength.com/en/3/ > The TLS BCP is IETF consensus, not just one person's opinion. If people deploy stuff based on our recommendations, we should ensure that it is still available to them when they migrate to TLS 1.3. Thanks, Yaron From nobody Thu Apr 2 05:48: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 464681A8A3B for ; Thu, 2 Apr 2015 05:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mzyO5RXqvDHI for ; Thu, 2 Apr 2015 05:48:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08E61A8A12 for ; Thu, 2 Apr 2015 05:48:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8E696BF08; Thu, 2 Apr 2015 13:48:09 +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 Y4Bzeyr5yWuC; Thu, 2 Apr 2015 13:48:08 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 21E42BEE8; Thu, 2 Apr 2015 13:48:08 +0100 (IST) Message-ID: <551D3A87.5060801@cs.tcd.ie> Date: Thu, 02 Apr 2015 13:48:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yaron Sheffer , Martin Thomson References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> <551D2D06.6000603@gmail.com> In-Reply-To: <551D2D06.6000603@gmail.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 12:48:12 -0000 On 02/04/15 12:50, Yaron Sheffer wrote: >> On 1 April 2015 at 17:46, Yaron Sheffer wrote: >>> AES-256-GCM and SHA-384. Doesn't it make sense to have them as SHOULD, >> >> I don't see much point. All involved likely know if they need >> something that strong, which is way down there in the "we might need >> it someday" category [1]. >> >> [1] http://www.keylength.com/en/3/ >> > > The TLS BCP is IETF consensus, not just one person's opinion. If people > deploy stuff based on our recommendations, we should ensure that it is > still available to them when they migrate to TLS 1.3. But isn't it likely we revise the TLS BCP once TLS1.3 is done and implementations start to become common? We can make sure things all add up at that point in time, and are in-whack with what people are deploying, but we don't necessarily need to do so now I think. S. > > Thanks, > Yaron > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Thu Apr 2 05:52: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 790491A8A12 for ; Thu, 2 Apr 2015 05:52: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 mCabyJPPVs6i for ; Thu, 2 Apr 2015 05:52:40 -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 A47861A1B87 for ; Thu, 2 Apr 2015 05:52:39 -0700 (PDT) Received: by wgdm6 with SMTP id m6so84381692wgd.2 for ; Thu, 02 Apr 2015 05:52:38 -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=Q+ASa5Rd6ZVjdgjFBaOAZIPcPnNy9FTyynynBBFbbQE=; b=DNMUeadMN5gG8ge1mDIo4tzQ7bUlF72uYudXnKyYv3bRUCsQcR0ffZm214zrKKDjKK WilG4wQduf8LCEa3khi2ASMopqSBoUZNEkHk+MGkt2gyCdYtAGEIBOHU7ePJNZGIUC+D XrJCP229rq7P9Y6dc08Zuc8GDmpeyRZSFB1kuiIwpUnsXfg4N1DmwlR5KalA6kUidSf4 T3mAPshyFyQ/rTH5B27cMs4zge8ZKDIS3yU0ZIqGyiagIYhjSEKHVCew4VAM67KkDhFN gUEZPIyn9CQ+J63hnIc1eM1lyRw3Flc2K+pSiKAwwFWzo4t6Rkm3YZtco9GpopYx3+EH +Emg== X-Received: by 10.180.73.9 with SMTP id h9mr24130003wiv.63.1427979158421; Thu, 02 Apr 2015 05:52:38 -0700 (PDT) Received: from [10.32.181.183] ([37.205.56.247]) by mx.google.com with ESMTPSA id jt8sm29912582wid.4.2015.04.02.05.52.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 05:52:37 -0700 (PDT) Message-ID: <551D3B94.7070100@gmail.com> Date: Thu, 02 Apr 2015 05:52:36 -0700 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Stephen Farrell , Martin Thomson References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> <551D2D06.6000603@gmail.com> <551D3A87.5060801@cs.tcd.ie> In-Reply-To: <551D3A87.5060801@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 12:52:41 -0000 On 04/02/2015 05:48 AM, Stephen Farrell wrote: > > > On 02/04/15 12:50, Yaron Sheffer wrote: >>> On 1 April 2015 at 17:46, Yaron Sheffer wrote: >>>> AES-256-GCM and SHA-384. Doesn't it make sense to have them as SHOULD, >>> >>> I don't see much point. All involved likely know if they need >>> something that strong, which is way down there in the "we might need >>> it someday" category [1]. >>> >>> [1] http://www.keylength.com/en/3/ >>> >> >> The TLS BCP is IETF consensus, not just one person's opinion. If people >> deploy stuff based on our recommendations, we should ensure that it is >> still available to them when they migrate to TLS 1.3. > > But isn't it likely we revise the TLS BCP once TLS1.3 is done and > implementations start to become common? We can make sure things > all add up at that point in time, and are in-whack with what people > are deploying, but we don't necessarily need to do so now I think. > It entirely likely. But even then, I am not sure we'll be able to convince people who went to AES-256 (presumably, for "compliance" reasons) to move to ChaCha. And certainly not to AES-128... From nobody Thu Apr 2 06:37: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 350CA1A1A2E for ; Thu, 2 Apr 2015 06:37:08 -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 lzWKr2MraWWP for ; Thu, 2 Apr 2015 06:37:05 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6731A1A8F for ; Thu, 2 Apr 2015 06:37:04 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t32DatSU028439; Thu, 2 Apr 2015 09:36:55 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "'yaronf.ietf@gmail.com'" , "'stephen.farrell@cs.tcd.ie'" , "'martin.thomson@gmail.com'" Thread-Topic: [TLS] Consensus Call on MTI Algorithms Thread-Index: AQHQbKdrrgxSnl5sOUuqebcfK2nw3Z049zQAgAAvgQCAAAfCAIAAsbcAgAAQGYCAAAFBAP//yUYP Date: Thu, 2 Apr 2015 13:36:54 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC2711709F@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <551D3B94.7070100@gmail.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.13.68, 1.0.33, 0.0.0000 definitions=2015-04-02_04:2015-04-02,2015-04-02,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-1504020131 Archived-At: Cc: "'tls@ietf.org'" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 13:37:08 -0000 You mandated AES-GCM with 128-bit key. Would it be a burden to add 256-bit = key support for the algorithm you have to have anyway?=20 Why not add AES-GCM-256 as SHOULD?=20 -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street, Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ MIT LL Root CA: ----- Original Message ----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Thursday, April 02, 2015 08:52 AM=0A= To: Stephen Farrell ; Martin Thomson Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call on MTI Algorithms On 04/02/2015 05:48 AM, Stephen Farrell wrote: > > > On 02/04/15 12:50, Yaron Sheffer wrote: >>> On 1 April 2015 at 17:46, Yaron Sheffer wrote: >>>> AES-256-GCM and SHA-384. Doesn't it make sense to have them as SHOULD, >>> >>> I don't see much point. All involved likely know if they need >>> something that strong, which is way down there in the "we might need >>> it someday" category [1]. >>> >>> [1] http://www.keylength.com/en/3/ >>> >> >> The TLS BCP is IETF consensus, not just one person's opinion. If people >> deploy stuff based on our recommendations, we should ensure that it is >> still available to them when they migrate to TLS 1.3. > > But isn't it likely we revise the TLS BCP once TLS1.3 is done and > implementations start to become common? We can make sure things > all add up at that point in time, and are in-whack with what people > are deploying, but we don't necessarily need to do so now I think. > It entirely likely. But even then, I am not sure we'll be able to=20 convince people who went to AES-256 (presumably, for "compliance"=20 reasons) to move to ChaCha. And certainly not to AES-128... _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Apr 2 06:55: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 54D231A9048 for ; Thu, 2 Apr 2015 06:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LDg7YvFrJuJB for ; Thu, 2 Apr 2015 06:55:44 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 95FFB1A9008 for ; Thu, 2 Apr 2015 06:55:44 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 0842D9A4029; Thu, 2 Apr 2015 09:55:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id UcIDthPm+WYl; Thu, 2 Apr 2015 09:55:10 -0400 (EDT) Received: from [129.6.254.78] (unknown [129.6.254.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CBD909A4017; Thu, 2 Apr 2015 09:55:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <551C9170.8050708@gmail.com> Date: Thu, 2 Apr 2015 09:55:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF TLS Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 13:55:47 -0000 Yaron: > The TLS BCP (http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-11, = soon to be published), recommends two cipher suites based on AES-256-GCM = and SHA-384. Doesn't it make sense to have them as SHOULD, for the sake = of continuity and also for those people who actually desire a higher = level of bit-strength? Thanks for highlighting this dependency. I support your recommendation. Russ From nobody Thu Apr 2 09:05: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 AB18D1B2D38 for ; Thu, 2 Apr 2015 09:05: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 N4QRC4Ni5c9I for ; Thu, 2 Apr 2015 09:05:47 -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 57CB51B2D37 for ; Thu, 2 Apr 2015 09:05:47 -0700 (PDT) Received: by obbec2 with SMTP id ec2so135015536obb.3 for ; Thu, 02 Apr 2015 09:05: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=7Mc7mYPdd+RbJi2OWjedxjjU+UwPkezb7A6miG3bzyQ=; b=UpZtUVvgjoXxCA/sHHyNSkQwxtdxMOeu0LJgsaxCIoGmBx4F+diAaFG5Kna7J4xqN2 2VM5YYGWDdB5+7vQggf5GWVyZaViB9prMMlMaU7UpCwokwrrx6qvVu4A2RcgJgstw3ua uHgxKWwckopxyigsYch7J5/WjeA3Dd22Q/jlX5qOXEjLYczCx1pGLvSQtcqO3T+CCR7Y B9LsagWZUS34SYpC96P+m5rf4EU5Bep90FBnNjSQGqyI0nM5bhjCV6aEzpbKSPyPCAMX vjIuHeY8It1VhyAU+s9L50zkKK2BC/CsroOuWcZW03MzdZutcbTbfMMitA4pNQK96dZ+ kxhQ== MIME-Version: 1.0 X-Received: by 10.60.132.33 with SMTP id or1mr48705819oeb.82.1427990746762; Thu, 02 Apr 2015 09:05:46 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Thu, 2 Apr 2015 09:05:46 -0700 (PDT) In-Reply-To: References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@cs.tcd.ie> Date: Thu, 2 Apr 2015 09:05:46 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 16:05:48 -0000 On 1 April 2015 at 18:18, Martin Thomson wrote: > Here's the exhaustive list that we've already removed. > > http://http2.github.io/http2-spec/#BadCipherSuites > > Some of those are still in wide use today, but none of these work in 1.3. It was pointed out to me that this list includes some PSK suites. I believe that the intent is to support those in 1.3. From nobody Thu Apr 2 09:45: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 0DE451ACD83 for ; Thu, 2 Apr 2015 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, 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 lP1ufevjfYvc for ; Thu, 2 Apr 2015 09:45:44 -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 9E8661ACE2C for ; Thu, 2 Apr 2015 09:45:36 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 5876F9406B for ; Thu, 2 Apr 2015 09:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fLMU/q1g5TFcn+UP8r6Z t4PFsTM=; b=HZuiYBJGwDz6K5FcZW5YKmWdE+0mqhCoeVVJdU4pGDoO3M2qAY5r csOIOxop6Kumr4zWg/xB5BIy3dDrknMrztMSwy+oGRoZ9ootynSb5QzfeX/foKsg 7j3iZvC1RXpO2N/+5h6kN4FT5nefNgSIJefqq85mgsH62dCi0i9T63Q= Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 409CB94065 for ; Thu, 2 Apr 2015 09:45:36 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so78363006igc.0 for ; Thu, 02 Apr 2015 09:45:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.27.143 with SMTP id b137mr73369967iob.76.1427993135912; Thu, 02 Apr 2015 09:45:35 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Thu, 2 Apr 2015 09:45:35 -0700 (PDT) In-Reply-To: References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@cs.tcd.ie> <201504012115.09048.davemgarrett@gmail.com> Date: Thu, 2 Apr 2015 11:45:35 -0500 Message-ID: From: Nico Williams To: CodesInChaos Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 16:45:45 -0000 On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos wrote: > Nico Williams nico@cryptonector.com wrote: >> Yes, we could patch in a-la-carte ciphersuite negotiation by having >> non-functional ciphersuites that wild-card all but the one kind of >> thing. You offer those. A matching functional ciphersuite gets >> selected. Done. >> >> TLS_*_*_WITH_AES_GCM_* >> TLS_*_*_WITH_*_*_SHA384 >> TLS_ECDHE_*_WITH_*_*_* >> ... > > I think full a-la-carte is too complex. But I'm for negotiating the > handshake and symmetric crypto separately. They're already very > loosely coupled and most proposals that introduce/obsolete > ciphersuites are only interested in one of the two sides, with the > other being only an afterthought. That would be a huge improvement over what we have now. Nico -- From nobody Thu Apr 2 09:57: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 6B0631AC3C5 for ; Thu, 2 Apr 2015 09:57:26 -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 GZj2wSTgym26 for ; Thu, 2 Apr 2015 09:57:25 -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 3D2FA1ACE83 for ; Thu, 2 Apr 2015 09:57:12 -0700 (PDT) Received: by qgep97 with SMTP id p97so74518669qge.1 for ; Thu, 02 Apr 2015 09:57:11 -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=ovnSf4e3AOOsIT6kGKXFFaOZ70AknSSFJm3GlhtVUHo=; b=ra061zLhjOMn7urp7EeuG+VL1HL6dxOk4RPBSKyBBVrh58wuUzpO1dYPv5lNUx8/2t 2/7abYl/wm93anG/P56m3RvcR0FB8n9Jd1GVwnuN3g51Kq/891FeUQLzVFgU2acpx+i1 5XCIw4HZApnijotMqCcYAon3tpRqh3bftlDBEqpWf9hka9b2WUGgwLu6ree6BKWkOZRM xCBgIEJ8XjASdKFSdvSqo+V4gor+12BT6drDcfVftUHLbPj7wPyIFnx1hgqIBLTOSVws IpGBs+fUrMyHrO8bc00CDOXHv1zCzlyJb+ltyi3nYdfJHi4RU9gv0TC4urbouvc4Xm4K vXuA== X-Received: by 10.55.15.15 with SMTP id z15mr17311045qkg.21.1427993831519; Thu, 02 Apr 2015 09:57:11 -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 187sm3829747qhv.8.2015.04.02.09.57.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 09:57:10 -0700 (PDT) From: Dave Garrett To: Nico Williams Date: Thu, 2 Apr 2015 12:57:09 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150401201221.163745c2@pc1.fritz.box> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504021257.09955.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 16:57:26 -0000 On Thursday, April 02, 2015 12:45:35 pm Nico Williams wrote: > On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos wrote: > > I think full a-la-carte is too complex. But I'm for negotiating the > > handshake and symmetric crypto separately. They're already very > > loosely coupled and most proposals that introduce/obsolete > > ciphersuites are only interested in one of the two sides, with the > > other being only an afterthought. > > That would be a huge improvement over what we have now. That could be a good middle ground. Just split cipher suites into essentially asymmetric & symmetric cipher suites, and put them both in the same array. Server just picks one of each for handshake & connection. Dave From nobody Thu Apr 2 10:04: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 CF8301ACEB8 for ; Thu, 2 Apr 2015 10:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V4rH2eNbt7R for ; Thu, 2 Apr 2015 10:03:57 -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 51ECB1ACE9E for ; Thu, 2 Apr 2015 10:03:57 -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 t32H3upT010972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 2 Apr 2015 13:03:56 -0400 Received: from pintsize.usersys.redhat.com (dhcp-0-197.brq.redhat.com [10.34.0.197]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t32H3tlw016999 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 2 Apr 2015 13:03:56 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 02 Apr 2015 19:03:49 +0200 Message-ID: <2049332.0fGm7COnvG@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.4 (Linux/3.18.9-100.fc20.x86_64; KDE/4.14.6; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2227252.6movqKVf5F"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 17:03:59 -0000 --nextPart2227252.6movqKVf5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 01 April 2015 11:12:19 Joseph Salowey wrote: > We did not get a chance to talk about MTI algorithms in Dallas, but t= he > chairs would like to judge consensus for the algorithms discussed in = the > interim. The CFRG has closed or will close soon on ChaCha20 and curv= e > 25519 recommendations so they are included. We will be calling for > acceptance to bring drafts on these into the working group shortly. >=20 > Keep in mind that mandatory to implement (MTI) is not mandatory to us= e and > that it is expected that there will be profiles for specific environm= ents. >=20 > Below is the proposed algorithm list that had consensus at the Seattl= e > Interim. Please reply on the TLS mailing list indicating whether or n= ot you > agree with the consensus. If not, please indicate why. This consens= us > call will close on April, 23, 2015. >=20 > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 >=20 > o Hash: > MUST SHA-256 >=20 > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 >=20 > o Signature: > MUST ECDSA P-256 > MUST RSA >=20 > Thanks, >=20 > J&S Yes =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 --nextPart2227252.6movqKVf5F 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 iQIcBAABCgAGBQJVHXZ6AAoJEJKo0bgB0vX1b+cP/RwrY+b3mCaf5Kiy8jDnv7lK 0XRY/p98X1/pBGDr44svVrRsIt7kHZPepUX10VOWHgsHoVXEUbI8YMMHRHtuJ7Mp rI2el30pA/cHc0cE7sQf6MIZcqbSvWYVfYJFejtlmjvZcQApqtQl+NOoxD0x86w0 0IRuA6swuuEGv3VNw7Bv3FT6Gjv/Qo5KTJ9bjuMFe2fm4n8bUgCnItD6TgWNle41 2eSSeP5rnDGlPyohT9s5X5rQVHwWGgPdxXPqEN4CtpHVp2eo4pljLbgxKnjHt9wV HTC3zPanfR4HtAfNlAgOcaf7iz0fzwkO94EMKT0AFdnX3+HyzclDrw/YtkBYawq4 MH7jcgLIuc3bWptQm3iATOfT4fASZ9KghGmOOg6k0q3RwRg+qyKFipjIu44qaYCZ KozpeYGdwHELtjQLOVwWQxClfXM7kY/1m0LGHtIZy4C80FkjZq2KasrpbMsKnmdv EKIAVTLA4duApcPHovXtzK7cQlh7ISjdROFT74JD7r48b653ol+hBvW8GgBr8bw9 xmoLaUzlmKbT6qM8RjYs1Xqyqd+J8LCeCdz2xEMwvmRKEmaAQLNv/Gq76wIWt7t+ MfieVk1qYySYt6t33h7yyFdZaXtVyegNUf+1MY7NhzgEWZ6ZRCnQY/NcJsShWpgd ejustmir8ds9J8GQTFS4 =cWWb -----END PGP SIGNATURE----- --nextPart2227252.6movqKVf5F-- From nobody Thu Apr 2 10:16: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 9BEA21AD05C for ; Thu, 2 Apr 2015 10:16:49 -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_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH0uW3uT8zsI for ; Thu, 2 Apr 2015 10:16:47 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3CD1ACDFA for ; Thu, 2 Apr 2015 10:16:47 -0700 (PDT) Received: from pc1.fritz.box (x4d06ffff.dyn.telefonica.de [::ffff:77.6.255.255]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 02 Apr 2015 19:16:45 +0200 id 000000000000005A.00000000551D797D.00005C37 Date: Thu, 2 Apr 2015 19:16:57 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20150402191657.43cd35ee@pc1.fritz.box> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-23607-1427995006-0001-2" Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 17:16:49 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-23607-1427995006-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I have a number of issues with these algs, but I think these touch some fundamentals. Given that TLS 1.3 should get "things right" for a long timeframe I think we shouldn't shrink back from bigger decisions however. On Wed, 1 Apr 2015 11:12:19 -0700 Joseph Salowey wrote: > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 GCM: I have the feeling word of mouth in the crypto community is that nobody really likes GCM. The only reason it gained so much popularity is because it was "the only thing left" in TLS after CBC (in the MtE variant) and RC4 got under attack. I would like to discuss if this word of mouth is based on hard and if we come to the conclusion that GCM is not a particularly good cipher mode then I ask: Why should it be part of TLS 1.3 at all? Especially I hear again and again people have concerns that it's close to impossible to implement GCM timing-safe if there is no hw instruction support. That leaves the question what is better. One could of course say "go with chacha/poly as the default", because it seems to be popular. Arguments against: AES has widely hardware support and it's a well-respected standard. Other options: AES-CBC with EtM (Peter Gutmann just claimed here he thinks its less brittle than GCM) or other block modes (OCB?). > o Hash: > MUST SHA-256 Fine with that. > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 It's a bit similar to the issue above: It seems nobody really likes the NIST curves. Claims that it's almost impossible to implement them timing-safe. Even NIST doesn't seem to like the curves that much any more and they want to move on. And we had this painful discussion on 25519 now for such a long time and most crypto people seem to like it. Did we do that just to make it the second-best option? If there is agreement that curve25519 is superior to the nist curves then why keep the latter? (There's of course also this "issue" with the NIST curves and their random numbers of unknown origin, but it seems right now majority opinion is that it is highly unlikely this is a sign of a backdoor.) > o Signature: > MUST ECDSA P-256 > MUST RSA It pretty much follows from above: If we agree people don't like the NIST curves very much and every one likes curve25519 then ecdsa with p256 should go away. However there's even a stronger argument: ECDSA isn't that popular either. (RNG failures.) I'd like to add that RSA should preferrably be RSA-PSS (if we're talking about the connection handshake sigs - for the certificate sigs this is a different issue, for backwards compatibilty reasons it seems hard to require pss here). Conclusion: There seem to be a number of options in this MTI list that are algorithms that many crypto experts think aren't that good. I don't like that. I want TLS 1.3 to be based on algorithms people think are the best of their kind. (And add to that that I'm in full support of everyone saying that we should also try to not have too many options - just causing confusion, more attack surface and more complexity. One or two algs each and be done with it.) Hanno --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-23607-1427995006-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVHXmJAAoJEKWIAHK7tR5CGWgP/RC4Glsjs/LAxUIWAti53ZBZ gGFlXNo5MFZV91IXLQm+aMlJbc7qjwpNRBuCAqmDl7NKzeBudaV+XRQQUPWv8IoO +nRMSVGZ8ybJbqypgaJ4OtGVC1k7x5LA1pakrU74k0b4RNPPjkqOt2YtJDICZGfb WQm9nOzDXDf5w6W9348u5IOJ8Xzz65rt96j48XgqlLuKc4lBDHaTJCQ+rvqq8IXH IPUNpC2YPKv9H5I1JCwt6bZKZRxr3KeKOjQIq7bUDaauqQS8vXtygjBz51XGUftZ BBE1fPhvySF2FBRBzbvLoPxBZDyCU1YZC0kohst9pwuemgye5VQdzJ3pjmYAc/6e n7QRymNrBsqAkg8EOOkcZIQtY1lm5Le9c916rUggvY2nZ9nnoZ6EHrmNsNVURD8h 3FZbe9xHa7liJ/nj7ATmq5YUz4Ib93NoEHsleUwvfNoKOD8oRVASwN6/wsMj7mq1 EhZunTFsDpLsJHlf5Q3PNIfXxL/KZzDjJJFH8hqR692yJ7hNTV88T0EWrglQXkFH VLF7HeLj4NftowXJdxeP6SX332TuifrLAOY8p6EEvYhP8ViqJ3ssmpkYHsb+fSmL yPLfBmDYGZZGfpMqCCtbCDbZqJ83auqhFcLWu+o3EWq052I9sj/w4oLV541CETts LLPhsWwq0Ne76dax5Der =qQMQ -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-23607-1427995006-0001-2-- From nobody Thu Apr 2 10:28: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 487931A014D for ; Thu, 2 Apr 2015 10:28:12 -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 P5jq4Yfkq72M for ; Thu, 2 Apr 2015 10:28:09 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE0D1A006B for ; Thu, 2 Apr 2015 10:28:06 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t32HRVmu012686; Thu, 2 Apr 2015 13:27:31 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "'hanno@hboeck.de'" , "'tls@ietf.org'" Thread-Topic: [TLS] Consensus Call on MTI Algorithms Thread-Index: AQHQbKdrrgxSnl5sOUuqebcfK2nw3Z06O2SA//+/2f8= Date: Thu, 2 Apr 2015 17:27:31 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC2711972C@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <20150402191657.43cd35ee@pc1.fritz.box> 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.13.68, 1.0.33, 0.0.0000 definitions=2015-04-02_06:2015-04-02,2015-04-02,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-1504020165 Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 17:28:12 -0000 Well, I for one do like GCM (the fact that more platforms now provide hardw= are acceleration makes me like it even more :), and I like NIST curves (and= already have the code to deal with them).=20 I guess those who dislike either one (or both) are just more vocal.=20 P.S. I also like OCB, especially considering the license Phil Rogaway grant= ed OpenSSL (or was it to TLS protocol at large? :).=20 -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street, Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ MIT LL Root CA: ----- Original Message ----- From: Hanno B=F6ck [mailto:hanno@hboeck.de] Sent: Thursday, April 02, 2015 01:16 PM=0A= To: tls@ietf.org Subject: Re: [TLS] Consensus Call on MTI Algorithms Hello, I have a number of issues with these algs, but I think these touch some fundamentals. Given that TLS 1.3 should get "things right" for a long timeframe I think we shouldn't shrink back from bigger decisions however. On Wed, 1 Apr 2015 11:12:19 -0700 Joseph Salowey wrote: > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 GCM: I have the feeling word of mouth in the crypto community is that nobody really likes GCM. The only reason it gained so much popularity is because it was "the only thing left" in TLS after CBC (in the MtE variant) and RC4 got under attack. I would like to discuss if this word of mouth is based on hard and if we come to the conclusion that GCM is not a particularly good cipher mode then I ask: Why should it be part of TLS 1.3 at all? Especially I hear again and again people have concerns that it's close to impossible to implement GCM timing-safe if there is no hw instruction support. That leaves the question what is better. One could of course say "go with chacha/poly as the default", because it seems to be popular. Arguments against: AES has widely hardware support and it's a well-respected standard. Other options: AES-CBC with EtM (Peter Gutmann just claimed here he thinks its less brittle than GCM) or other block modes (OCB?). > o Hash: > MUST SHA-256 Fine with that. > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 It's a bit similar to the issue above: It seems nobody really likes the NIST curves. Claims that it's almost impossible to implement them timing-safe. Even NIST doesn't seem to like the curves that much any more and they want to move on. And we had this painful discussion on 25519 now for such a long time and most crypto people seem to like it. Did we do that just to make it the second-best option? If there is agreement that curve25519 is superior to the nist curves then why keep the latter? (There's of course also this "issue" with the NIST curves and their random numbers of unknown origin, but it seems right now majority opinion is that it is highly unlikely this is a sign of a backdoor.) > o Signature: > MUST ECDSA P-256 > MUST RSA It pretty much follows from above: If we agree people don't like the NIST curves very much and every one likes curve25519 then ecdsa with p256 should go away. However there's even a stronger argument: ECDSA isn't that popular either. (RNG failures.) I'd like to add that RSA should preferrably be RSA-PSS (if we're talking about the connection handshake sigs - for the certificate sigs this is a different issue, for backwards compatibilty reasons it seems hard to require pss here). Conclusion: There seem to be a number of options in this MTI list that are algorithms that many crypto experts think aren't that good. I don't like that. I want TLS 1.3 to be based on algorithms people think are the best of their kind. (And add to that that I'm in full support of everyone saying that we should also try to not have too many options - just causing confusion, more attack surface and more complexity. One or two algs each and be done with it.) Hanno --=20 Hanno B=F6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 From nobody Thu Apr 2 10:40: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 C8DAC1B2D66 for ; Thu, 2 Apr 2015 10:40:27 -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 4zObWuDVJoSN for ; Thu, 2 Apr 2015 10:40: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 6E0521B2D64 for ; Thu, 2 Apr 2015 10:40:26 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A044016575B; Thu, 2 Apr 2015 17:40:25 +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 954A7165758; Thu, 2 Apr 2015 17:40:25 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 91F409803E; Thu, 2 Apr 2015 17:40:25 +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.913.22; Thu, 2 Apr 2015 12:40:24 -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.0913.011; Thu, 2 Apr 2015 12:40:24 -0500 From: "Salz, Rich" To: "Blumenthal, Uri - 0553 - MITLL" , "'hanno@hboeck.de'" , "'tls@ietf.org'" Thread-Topic: [TLS] Consensus Call on MTI Algorithms Thread-Index: AQHQbKd0Pp94k8TVYUO8WBujEGUR9J06TCeAgAAC9ID//6+UUA== Date: Thu, 2 Apr 2015 17:40:24 +0000 Message-ID: References: <20150402191657.43cd35ee@pc1.fritz.box> <65D2FD736B6B2B48B2EAD2BD189DC9CC2711972C@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <65D2FD736B6B2B48B2EAD2BD189DC9CC2711972C@LLE2K10-MBX01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.33.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 17:40:27 -0000 > I guess those who dislike either one (or both) are just more vocal. That is usually how it goes. For ANY topic in the world. > P.S. I also like OCB, especially considering the license Phil Rogaway gra= nted > OpenSSL (or was it to TLS protocol at large? :). It was first OpenSSL, then he recently stated his intent to freely license = for to use in TLS. From nobody Thu Apr 2 10:48: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 4C9B01B2DA3 for ; Thu, 2 Apr 2015 10:48:31 -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 Crt0WgfNu9iZ for ; Thu, 2 Apr 2015 10:48:29 -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 D726A1B2DA2 for ; Thu, 2 Apr 2015 10:48:28 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 68023188780; Thu, 2 Apr 2015 20:48:26 +0300 (EEST) Date: Thu, 2 Apr 2015 20:48:26 +0300 From: Ilari Liusvaara To: Nico Williams Message-ID: <20150402174826.GA7414@LK-Perkele-VII> References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@cs.tcd.ie> <201504012115.09048.davemgarrett@gmail.com> 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] 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: Thu, 02 Apr 2015 17:48:31 -0000 On Thu, Apr 02, 2015 at 11:45:35AM -0500, Nico Williams wrote: > On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos wrote: > > Nico Williams nico@cryptonector.com wrote: > >> Yes, we could patch in a-la-carte ciphersuite negotiation by having > >> non-functional ciphersuites that wild-card all but the one kind of > >> thing. You offer those. A matching functional ciphersuite gets > >> selected. Done. > >> > >> TLS_*_*_WITH_AES_GCM_* > >> TLS_*_*_WITH_*_*_SHA384 > >> TLS_ECDHE_*_WITH_*_*_* > >> ... > > > > I think full a-la-carte is too complex. But I'm for negotiating the > > handshake and symmetric crypto separately. They're already very > > loosely coupled and most proposals that introduce/obsolete > > ciphersuites are only interested in one of the two sides, with the > > other being only an afterthought. > > That would be a huge improvement over what we have now. I say if one splits symmetric/asymmetric, then the hash should go to the asymmetric part, since it is used there. And furthermore, since there are group and cert type negotiation mechanism already can do unified DH/w certs. So (with some added in): TLS13_A_DH_CERT_SHA256 TLS13_A_DH_CERT_SHA384 TLS13_S_AES_128_GCM TLS13_S_AES_256_GCM TLS13_S_ARIA_128_GCM TLS13_S_ARIA_256_GCM TLS13_S_CAMELLIA_128_GCM TLS13_S_CAMELLIA_256_GCM TLS13_S_AES_128_CCM TLS13_S_AES_256_CCM TLS13_S_AES_128_CCM8 TLS13_S_AES_256_CCM8 TLS13_S_CHACHA20_POLY1305 (I included a cipher if it had an existing codepoint or was in wide use and was TLS 1.3 compatible). I'm on fence about splitting hash out: TLS13_A_DH_CERT TLS13_H_SHA256 TLS13_H_SHA384 TLS13_S_* As it seems to me that symmetric algorithm, key exchange and hash to use are relatively independent concerns (I know gnutls has internal mapping table that breaks ciphersuites to internal component parts). Regarding ServerHello parts of this, the ServerHello could be redesigned, except for the version field, which is convinently the first. So one could put two or three ciphersuite fields, one for each type there. If one wanted to add anonDH and PSK: TLS13_A_DH_ANON TLS13_A_DH_PSK TLS13_A_PSK Giving 17 ciphers that span cartesian space of 88 cipher- suites. -Ilari From nobody Thu Apr 2 11:05: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 0F0E31A005B for ; Thu, 2 Apr 2015 11:05:29 -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_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 ybyhqeS9HTte for ; Thu, 2 Apr 2015 11:05:27 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBA61B2DA5 for ; Thu, 2 Apr 2015 11:05:19 -0700 (PDT) X-AuditID: d80ac3f1-f797f6d0000019aa-4c-551d84dee7f5 Received: from ecl1mtahubpin01.ges.symantec.com (ecl1mtahubpin01.ges.symantec.com [10.48.69.201]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id CB.EC.06570.ED48D155; Thu, 2 Apr 2015 19:05:19 +0100 (BST) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by ecl1mtahubpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1YdjUT-0000mI-V7 for tls@ietf.org; Thu, 02 Apr 2015 18:05:18 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Thu, 2 Apr 2015 11:05:17 -0700 From: Rick Andrews To: "tls@ietf.org" Date: Thu, 2 Apr 2015 11:05:16 -0700 Thread-Topic: [TLS] Consensus Call on MTI Algorithms Thread-Index: AdBtby03R0f6JGcQTFi+g3z0XixxLw== Message-ID: <544B0DD62A64C1448B2DA253C01141460BD6B99FAA@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsXCZeB6Uvd+i2yoQauhxafzXYwOjB5Llvxk CmCM4rJJSc3JLEst0rdL4Mq49+cZc8ER5opNvxcyNzC+Yepi5OSQEDCRuHfiKpQtJnHh3nq2 LkYuDiGBd4wSu/ZNYIZw/jJK3D16mxHCWcko8XL9LbAWNgE9iS2Pr7CD2CICihI7rnaD2SwC KhL7V5wAGsXBISxgLHG8NwaiBGjbhBlQ5XoSn7/tZwWxeQWiJBp3T2UGsRmBrvh+ag3YeGYB cYlbT+ZDXScgsWTPeWYIW1Ti5eN/rBD1ohJ32tczQtTrSCzY/YkNwtaWWLbwNTPEfEGJkzOf sExgFJmFZOwsJC2zkLTMQtKygJFlFaNMSWmxYXFuSX5pSUFqhYGhXnFlbiIwCpL1kvNzNzEC I+EG1+GPOxiP7nU8xCjAwajEw/u1UjZUiDWxDKjyEKMEB7OSCK97M1CINyWxsiq1KD++qDQn tfgQozQHi5I477tO0VAhgfTEktTs1NSC1CKYLBMHp1QDo/rZ3W875j+e3KJn3hZ3Q774W323 Xr1Yzbz1VvsCAn6xl/zdle/o1FnIGXPreGmPnNBKn8/28y+fknc+vzho/S8ZnY1hZ6+qpMRs EJVs35Fify00XPNJRfYCJq93L1K0ddcdFf/eMv/YqbnVnfYzMxbEHpkcPLmH96m09oLsjdnv I9VNnR+8VmIpzkg01GIuKk4EAGS2an2AAgAA Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 18:05:29 -0000 >> Also, just wondering: is ECDSA popular enough today to be a MUST? > All of the certificates used by CloudFlare's "Universal SSL" are ECDSA ce= rtificates issued by Comodo. Symantec has been offering ECDSA certs for years. I believe most of the maj= or CAs offer them. Allowed curves are spelled out in the CA/Browser Forum B= aseline Requirements doc (https://cabforum.org/wp-content/uploads/BRv1.2.3.= pdf, Appendix A). -Rick From nobody Thu Apr 2 11:36: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 A56B91A0404 for ; Thu, 2 Apr 2015 11:36:25 -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 gI9k2Ad65iyS for ; Thu, 2 Apr 2015 11:36:25 -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 10CD01A03C7 for ; Thu, 2 Apr 2015 11:36:25 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id CCD1220047B83; Thu, 2 Apr 2015 11:36:24 -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=+kh993u9Wa9G23 VVSgbq7MpCf7w=; b=I8wJQwk2gKTpumViZx2zK4zTgYBwOTsacNU/V3UxzRn3gk f7h8POqr+jidRSOzFwX4ZTcAFI50q0d7UY4KClW9CO7fAAOswLlZjrAqM2kAepnv y/v5T/quMIj1alDJvNUfkJKvPSpAKbrfYvm0EsQ5/HfFKJQup6bZDVl8KOBGs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id 50A6220047B80; Thu, 2 Apr 2015 11:36:24 -0700 (PDT) Date: Thu, 2 Apr 2015 13:36:23 -0500 From: Nico Williams To: Yaron Sheffer Message-ID: <20150402183622.GE10960@localhost> References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> <551D2D06.6000603@gmail.com> <551D3A87.5060801@cs.tcd.ie> <551D3B94.7070100@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551D3B94.7070100@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 18:36:25 -0000 On Thu, Apr 02, 2015 at 05:52:36AM -0700, Yaron Sheffer wrote: > On 04/02/2015 05:48 AM, Stephen Farrell wrote: > >But isn't it likely we revise the TLS BCP once TLS1.3 is done and > >implementations start to become common? We can make sure things > >all add up at that point in time, and are in-whack with what people > >are deploying, but we don't necessarily need to do so now I think. > > It entirely likely. But even then, I am not sure we'll be able to > convince people who went to AES-256 (presumably, for "compliance" > reasons) to move to ChaCha. And certainly not to AES-128... Must-implement != must-deploy. From nobody Thu Apr 2 11:48: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 2650A1A1A2C for ; Thu, 2 Apr 2015 11:48:52 -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 litgIbRWQRM9 for ; Thu, 2 Apr 2015 11:48:51 -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 665271A0687 for ; Thu, 2 Apr 2015 11:48:51 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 3BF89160D; Thu, 2 Apr 2015 11:48:51 -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=33sIBnjqiW7xhS YKbLf9TT9unfQ=; b=pl44cZLOo98bqH1cyHh34CmLHuiwc1Tnw9f7RvLnJ714KX f+QMSuhoyjBi+y0p0c8NiFA7se7x5uXmqBgXjNk1FKnhY0YR2sGOhyQtnjzQztW2 lH/2y7pdGDjt2BUpLm9aFhJR3PaxUBPU+nuLU0/y/Bhx1XJI5tw5d6GCNuejQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id E32CF160C; Thu, 2 Apr 2015 11:48:50 -0700 (PDT) Date: Thu, 2 Apr 2015 13:48:50 -0500 From: Nico Williams To: Joseph Salowey Message-ID: <20150402184849.GF10960@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] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 18:48:52 -0000 On Wed, Apr 01, 2015 at 11:12:19AM -0700, Joseph Salowey wrote: > [...] I'd like to have at least two required algorithms for each class, at least for the 128-bit security level. The rationale is: to make it easy to switch one off if it becomes a problem. We've already had to disable broken algorithms in a hurry in several Internet protocols including TLS. We should learn the lesson: we should aim to have at least one left. In all cases recall that required-to-implement != required-to-enable. > o Symmetric: > MUST AES-GCM 128 > SHOULD ChaCha20-Poly1305 I would like at least two modes for AES to be required: one AEAD (probably GCM) and one AEAD-by-generic-construction (e.g., using HMAC). I would like one non-AES cipher to be required. ChaCha20-Poly1305 works for me. Total: three required algorithms. Here I want three because I'm not sure that GCM is easy enough to implement and use safely in all environments (see Watson L.'s comments on this), and because I'd like two ciphers just in case. > o Hash: > MUST SHA-256 I would like two hash functions to be required. I don't have a strong preference as to the second hash function, but I like SHA-3. > o Key Agreement: ECDH > MUST P-256 > SHOULD 25519 By the rationale above I would like both of these to be required. > o Signature: > MUST ECDSA P-256 > MUST RSA Ditto. We won't have the luxury of waiting until CFRG blesses an ECC signature scheme other than ECDSA, but when they do... we should add that to the list. Nico -- From nobody Thu Apr 2 11:54: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 4398B1A0A6A for ; Thu, 2 Apr 2015 11:54:02 -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 5fEufwMDgvMq for ; Thu, 2 Apr 2015 11:54:00 -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 D07621A1A34 for ; Thu, 2 Apr 2015 11:54:00 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id B0C4867C08F; Thu, 2 Apr 2015 11:54:00 -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=JGdxrumOeLFg/8 QoN/mAxy/78Zc=; b=kXLK1lsi/Ru7qoVIueRwFQ2wx3Y9DShs0+nlTQTyRyDP4/ dC3hvRndZKtAhASVdoP2EtCdk2JZJOcLZX0t2yuC3x30MVZXkE86jLV+773ct2nU 1iB5MLUN7S9sQQbvRmhFbe54OpcBx9yh+Va/LblthXO+g+N5iwGKX645s1mOU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPA id 2CE5E67C07D; Thu, 2 Apr 2015 11:54:00 -0700 (PDT) Date: Thu, 2 Apr 2015 13:53:59 -0500 From: Nico Williams To: Sean Turner Message-ID: <20150402185358.GG10960@localhost> References: <9DAE18D5-9378-4900-AB68-D0FE0EF70D93@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9DAE18D5-9378-4900-AB68-D0FE0EF70D93@ieca.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 18:54:02 -0000 On Wed, Apr 01, 2015 at 05:35:30PM -0400, Sean Turner wrote: > On Apr 01, 2015, at 14:12, Joseph Salowey wrote: > > > o Symmetric: > > MUST AES-GCM 128 > > SHOULD ChaCha20-Poly1305 > > Nobody 2119-me-to-death, but I paraphrase SHOULD as: this is a MUST > unless you have a really, really, really, really good reason to not do > it. The same is really true of the MUST, because if AES-128-GCM dies on the cryptanalysis table, well, we'll all want to turn it off and start ripping it out of the implementations as soon as possible. We really need *two* mandatory-to-implement algorithms for each class at the 128-bit security level. Your interpretation of SHOULD is a bit stronger than what RFC2119 says. We shouldn't play RFC2119 interpretation games. We should say what we want. We *should* want what I said above (already repeating myself). Nico -- From nobody Thu Apr 2 11: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 102061A1A98 for ; Thu, 2 Apr 2015 11:59:24 -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 EmyIzds0I4Hr for ; Thu, 2 Apr 2015 11:59:19 -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 6CF5C1A0364 for ; Thu, 2 Apr 2015 11:59:19 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6ED2A285E8; Thu, 2 Apr 2015 18:59:18 +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 5634A285E7; Thu, 2 Apr 2015 18:59:18 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 3A9A12029; Thu, 2 Apr 2015 18:59:18 +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.913.22; Thu, 2 Apr 2015 13:59:11 -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.0913.011; Thu, 2 Apr 2015 13:59:11 -0500 From: "Salz, Rich" To: Nico Williams , Joseph Salowey Thread-Topic: [TLS] Consensus Call on MTI Algorithms Thread-Index: AQHQbKd0Pp94k8TVYUO8WBujEGUR9J06ZdMA//+up3A= Date: Thu, 2 Apr 2015 18:59:11 +0000 Message-ID: References: <20150402184849.GF10960@localhost> In-Reply-To: <20150402184849.GF10960@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.33.94] 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] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 18:59:24 -0000 It's reasonably easy to add ciphers. Especially since most TLS 1.3 impleme= ntations will be built on a 1.[012] codebase.=20 It is nearly impossible to remove ciphers. Because of this, I am strongly in favor of JUST TWO. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Thu Apr 2 12:00: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 2E0B51A0687 for ; Thu, 2 Apr 2015 12:00:16 -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 SZFo2pFmV6CA for ; Thu, 2 Apr 2015 12:00:12 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 874A21A904F for ; Thu, 2 Apr 2015 12:00:09 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 9E04ABBA130; Thu, 2 Apr 2015 11:59:39 -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=corA1UEscluwqA 0QrNtCaajQM3Q=; b=pRGD0BtJTJS1ca6RmKbylaHDQHzSuI7vknXzal07V++xnV HADJELsr2oEB6wTH4FqYzLvHSsqrh4sKAibAuE+wkvBNVv42MemKXfKF37ahO7A7 ecUYl3N75ukvbkeHnQOJ7hPzPnuFAYB1FsYvLbJfwOEMi/7loVPWi9LHurCH4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 3DE69BBA160; Thu, 2 Apr 2015 11:35:18 -0700 (PDT) Date: Thu, 2 Apr 2015 13:35:16 -0500 From: Nico Williams To: Stephen Farrell Message-ID: <20150402183515.GD10960@localhost> References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> <551D2D06.6000603@gmail.com> <551D3A87.5060801@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551D3A87.5060801@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 19:00:16 -0000 On Thu, Apr 02, 2015 at 01:48:07PM +0100, Stephen Farrell wrote: > >> On 1 April 2015 at 17:46, Yaron Sheffer wrote: > >>> AES-256-GCM and SHA-384. Doesn't it make sense to have them as SHOULD, > >> > >> I don't see much point. All involved likely know if they need > >> something that strong, which is way down there in the "we might need > >> it someday" category [1]. > >> > >> [1] http://www.keylength.com/en/3/ > >> > > > > The TLS BCP is IETF consensus, not just one person's opinion. If people > > deploy stuff based on our recommendations, we should ensure that it is > > still available to them when they migrate to TLS 1.3. > > But isn't it likely we revise the TLS BCP once TLS1.3 is done and > implementations start to become common? We can make sure things > all add up at that point in time, and are in-whack with what people > are deploying, but we don't necessarily need to do so now I think. First, there will be no flag day. Operators will need implementations that support TLS 1.1 and 1.2 for a while yet. So they should get support for ciphersuites that used to be recommended. Second, these are symmetric ciphers we're talking about. Switching from one set in 1.1 and 1.2 on the one hand, and 1.3 on the other, is an operational non-issue. Deprecating RSA, say, would be a much bigger deal operationally. Nico -- From nobody Thu Apr 2 12: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 8186A1A0364 for ; Thu, 2 Apr 2015 12:04: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 R5ZEmSLcezAI for ; Thu, 2 Apr 2015 12:04:28 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.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 BD6E31A1B5D for ; Thu, 2 Apr 2015 12:04:28 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) by DM2PR0301MB1248.namprd03.prod.outlook.com (25.160.219.25) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 2 Apr 2015 19:04:28 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 2 Apr 2015 19:04:27 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) with mapi id 15.01.0118.022; Thu, 2 Apr 2015 19:04:27 +0000 From: Christian Huitema To: Nico Williams , Yaron Sheffer Thread-Topic: [TLS] Consensus Call on MTI Algorithms Thread-Index: AQHQbKd23SkjMeyZOkOkfPrXiYtBbp04tCUAgAAvggCAAAfCAIAAsbcAgAAQGYCAAAFBAIAAYA2AgAAG5aA= Date: Thu, 2 Apr 2015 19:04:27 +0000 Message-ID: References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> <551D2D06.6000603@gmail.com> <551D3A87.5060801@cs.tcd.ie> <551D3B94.7070100@gmail.com> <20150402183622.GE10960@localhost> In-Reply-To: <20150402183622.GE10960@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.254] authentication-results: cryptonector.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB1248; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(66066001)(76176999)(102836002)(62966003)(77156002)(54356999)(86612001)(2950100001)(92566002)(2900100001)(86362001)(87936001)(93886004)(74316001)(122556002)(2656002)(99286002)(46102003)(50986999)(106116001)(76576001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 0534947130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 19:04:27.0718 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 19:04:32 -0000 > Must-implement !=3D must-deploy. Not really true. If you implement something and the code is never used, the= n you cannot really trust that code. This is the old paradigm of the fire e= xit. If you never used it before the fire, you are surprised to see it rust= ed or blocked by debris the day there is a fire. If you implement something= , you need at a minimum the equivalent of fire-drills to test that it actua= lly works. -- Christian Huitema From nobody Thu Apr 2 12:09: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 3CC431A1B78 for ; Thu, 2 Apr 2015 12:09:10 -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 gQ0xXCBHMM5y for ; Thu, 2 Apr 2015 12:09:09 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 06D901A1A70 for ; Thu, 2 Apr 2015 12:09:09 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id C9930554060; Thu, 2 Apr 2015 12:09:08 -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=6/rbw5v/0BBgMD mpfOS0CMNs0JM=; b=HAImksyn2dWtDBlw3eNiBzZ4sgV1wdFkG1hfNfspViR2NN 8VDlDCYq0a+GjT7iM4GIEIe7gMHYOC7htguV1RGW5G9MWRdxWzPxCDLqtXNNn7DU Q9l2NiMaY7me5DD1DH/vkocbukUu7sElR/mjc/2nHtzhTSZmm64C3SSlSv3uA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPA id 56A8055405F; Thu, 2 Apr 2015 12:09:08 -0700 (PDT) Date: Thu, 2 Apr 2015 14:09:07 -0500 From: Nico Williams To: "Salz, Rich" Message-ID: <20150402190905.GH10960@localhost> References: <20150402184849.GF10960@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 19:09:10 -0000 On Thu, Apr 02, 2015 at 06:59:11PM +0000, Salz, Rich wrote: > It's reasonably easy to add ciphers. Especially since most TLS 1.3 > implementations will be built on a 1.[012] codebase. > > It is nearly impossible to remove ciphers. If *all* clients and servers implement the same required N>1 algorithms, then removing one is possible when you still have at least one of those remaining. Things get dicey when you're out of required algorithms and you need to prefer less-universal recommended algorithms, or if not all implementations adhere to the requirements. Now, if requiring 3 algorithms turns out to be a joke because some implementors will ignore one, and others another, then 3 would be a very bad number indeed; 4 would be worse. We do have to consider how likely this is; 3 will be more costly than 2, no doubt, and that may be enough. > Because of this, I am strongly in favor of JUST TWO. I can get on board with two, but then I'd want AES-128-GCM and ChaCha20-Poly1305. I think having two very different algorithms is a big plus. Nico -- From nobody Thu Apr 2 12:19: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 6476A1A1C03 for ; Thu, 2 Apr 2015 12:19: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 t9ZbSLi2FaYM for ; Thu, 2 Apr 2015 12:19:22 -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 E5BFF1A1BBE for ; Thu, 2 Apr 2015 12:19:21 -0700 (PDT) Received: by widjs5 with SMTP id js5so15196610wid.1 for ; Thu, 02 Apr 2015 12:19: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=KIL/dC7rD+nqEKCnevbVVjEpbD2gwBeOsE0hwr6gO5c=; b=D0iyNsxZjtI4Hg1eT2PJTFdEoZPmYH1JbkLKv8sdZRqjvZFO4Mfyx8xoBrds36YHnz jzD5N4gTMJjxvEChqHpivgwenIz1+5mzFzc0SbYaVdw5VhOqS0j8/OqzKh2DoF2jtQzB Rb95nusKXcoDcOw2gGC+1s9e6jTuykPZsrc0WjUGFVnISzNkgoaeYnJERRt7gCGHb02n zPtvhI4CXQmz2uhp2ExmEIHKmfJaej1wU4rgSobF4l4F3ZUL7/Vuk45S6bkMK6+Z9HZ8 v2vfyqsHaD2rv6cQGmderZwri89WECqGJ2p8UHosAULp36TSSe3oJQiu5HF0YtpCq8lP Ww0w== X-Received: by 10.194.19.10 with SMTP id a10mr98618872wje.153.1428002360742; Thu, 02 Apr 2015 12:19:20 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id cf12sm8493707wjb.10.2015.04.02.12.19.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 12:19:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <20150402183622.GE10960@localhost> Date: Thu, 2 Apr 2015 22:19:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> <551D2D06.6000603@gmail.com> <551D3A87.5060801@cs.tcd.ie> <551D3B94.7070100@gmail.com> <20150402183622.GE10960@localhost> To: Nico Williams X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 19:19:23 -0000 > On Apr 2, 2015, at 9:36 PM, Nico Williams = wrote: >=20 > On Thu, Apr 02, 2015 at 05:52:36AM -0700, Yaron Sheffer wrote: >> On 04/02/2015 05:48 AM, Stephen Farrell wrote: >>> But isn't it likely we revise the TLS BCP once TLS1.3 is done and >>> implementations start to become common? We can make sure things >>> all add up at that point in time, and are in-whack with what people >>> are deploying, but we don't necessarily need to do so now I think. >>=20 >> It entirely likely. But even then, I am not sure we'll be able to >> convince people who went to AES-256 (presumably, for "compliance" >> reasons) to move to ChaCha. And certainly not to AES-128... >=20 > Must-implement !=3D must-deploy. Hi, Nico. That=E2=80=99s a nice catch-phrase, but what does it mean? Suppose I am = implementing a TLS library specifically for the IoT space. Being a = standards-compliant implementation, my library and all its users will of = course conform to the profile in draft-ietf-dice-profile. That means = TLS_PSK_WITH_AES_128_CCM_8. Given this, why must I implement AES-GCM? = Why should I implement ChaCha? I and any other IoT implementer will = argue that the devices don=E2=80=99t have the memory for code that will = never run.=20 Sure, if I=E2=80=99m writing an OpenSSL, then I can implement everything = and allow users to configure whatever algorithm they want. But I really = don=E2=80=99t get what this phrase means in this context. Yoav From nobody Thu Apr 2 12:28: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 E7B091A000B for ; Thu, 2 Apr 2015 12:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxvdBLtiyE9d for ; Thu, 2 Apr 2015 12:28:34 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 6812C1A0016 for ; Thu, 2 Apr 2015 12:28:34 -0700 (PDT) Received: by wiaa2 with SMTP id a2so117023842wia.0 for ; Thu, 02 Apr 2015 12:28:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:cc :subject:references:in-reply-to:content-type; bh=ZYcPD3Ahf6m94EHAaWi4FH3q3LliR26XT+6hV/L7M4c=; b=NlZvufTKgKZrTMpwz+ZO7NQ0v2VHzO2ScE+EXcMXIqwPM6Ydd+5/jqvHZWoICDloNa EppSUt7Q/EOgX9Pfa2rawZWcg4xpd2Aot6Yylqzut7k9JlF+nSR5UvvaOq5/MNGAqYm2 or6ulwcRD1DdE+szJPUGAPFA8VYAVdXpMGTieFq0djX5BXWnZWii0B/oW7tSOBzFx7+P is2aH253kz0qta7XXGJ2tFvwlWaYmUCgdJ9Tz0938YYGVHtA/1Afbf2GvTLzKWHuSFK5 ucYrUvLsqnIdD4esINxarU6CwjF5MfFWf54u7ZeQ+BJMuYzJPcVJa1Y6/YuNDdZjCRpU 0YvA== X-Gm-Message-State: ALoCoQkY2O96odxxqD1nJPPYUkoMb2YaGxt9SUsianWDKqONTfu4j9PAR55rjWVdaqBQrc0hSb1G X-Received: by 10.194.142.205 with SMTP id ry13mr99447203wjb.73.1428002913042; Thu, 02 Apr 2015 12:28:33 -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 o5sm2600173wia.0.2015.04.02.12.28.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 12:28:32 -0700 (PDT) Message-ID: <551D985B.6080204@azet.org> Date: Thu, 02 Apr 2015 21:28:27 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 References: <20150402184849.GF10960@localhost> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA69C028056E9F82F1AE9C9D2" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 19:28:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA69C028056E9F82F1AE9C9D2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Hmm. I'd agree that an alternative to AES-GCM (still AES based) would be nice -- I have this AES-OCB draft still floating around, if anybody is interested. IBM is currently working through IPR stuff as far as I understand. :) Suggestion: MUST - AES-GCM, ChaCha20/Poly1305 SHOULD - AES-CCM or AES-OCB Thinking about ECDH, why even make the NIST curve mandatory to implement? Just go with 25519 & maybe (!) a secondary non-NIST curve. What about Ed448 as a second alternative (SHOULD) for signatures? Aaron --------------enigA69C028056E9F82F1AE9C9D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVHZhcAAoJEOTbZJL9ubXVOeMQALrWf7H9D9Du6SHsgb1VeTZ+ 9R7mfVUm4cTTWbwyo5t3LxPyfK2UuzAUICjN46f6aI+qsYOLwXqhnszE4hEFbTqn MVYD5Fi/mMo5ow/MbRYnGjRupN5tMx6r9fEAN4f+t7fqPP3PV5hScMPnULA9L97B +PzLrNKE4qCcnDypfL3RmmtEf4KXhJxP5xV9AKlBoaE2LYtGTJ8iIIWF7BXJ07wX tl93HaSiDXlaRQjjZvGfkhOVYNTBn56EMu0Y7iCkOVREE0lYNTN4UKtXofyKSxcy xgTGWIkcgdH+doS+ja3EofahgQuEymkOGArn6OvS8trKoaC99iPecs9l0gzPfO9A qYZ40OwHiAVk2zckngHOTMwuc5dFv/5aNaIJygA2Y0y0hqDw8jP1ypcEYYyetBQb 6ELJmBrouq7BkVqLxoWvAjXcpCcrZMVjLjfnWQ4WxA/XJZE9ub0SNi2YB8bTJEoM gx5OfetrieCZvNmRGd/1YQEytOJ/hCNDxiAQeU2c4ztpSkYR0N7nKkwaI0FEpDN0 yFK8Gg0i5PWiJ39zI/5MvvzPZV52em1j0jbfSgJa8BC8EthtWTuQFbXxwyZh/gQy 4GzZYFzW1YhAkzzynsolDQe21HkHfoavK0512ctY183FESMWlIxH6yY79y1eZzMc 2zgQBKY2UhILcTbTevuV =ixrW -----END PGP SIGNATURE----- --------------enigA69C028056E9F82F1AE9C9D2-- From nobody Thu Apr 2 12: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 B698F1A019B for ; Thu, 2 Apr 2015 12:44:20 -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 BnPs2XRsJkq6 for ; Thu, 2 Apr 2015 12:44:19 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CA80E1A0193 for ; Thu, 2 Apr 2015 12:44:19 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 83090554062; Thu, 2 Apr 2015 12:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=c1NkEJbx34fnfRkoDmkQpwM3ZxM=; b=qBf2Jx7Z7jZ rOXi61LcPGEh4mn/Rzu1mS3sTk62EptFQtGgXiGO3SLAaYpKJ14B2DLBiR42aedj IQ9uxxEe7LdiSM+EV7t7iI5LgA/i+B8z4ZjkVZ3UeUJjSOzzeTk832DrAytPYEjo 2si4IJu1w3XyoKMg8kKvTjnq3t8lhp+c= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPA id E8706554060; Thu, 2 Apr 2015 12:44:18 -0700 (PDT) Date: Thu, 2 Apr 2015 14:44:18 -0500 From: Nico Williams To: Yoav Nir Message-ID: <20150402194417.GJ10960@localhost> References: <4EAF777A-0F04-400D-BFCA-AA1F13526770@gmail.com> <551C9170.8050708@gmail.com> <551D2D06.6000603@gmail.com> <551D3A87.5060801@cs.tcd.ie> <551D3B94.7070100@gmail.com> <20150402183622.GE10960@localhost> 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] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 19:44:20 -0000 On Thu, Apr 02, 2015 at 10:19:17PM +0300, Yoav Nir wrote: >=20 > > On Apr 2, 2015, at 9:36 PM, Nico Williams wro= te: > >=20 > > On Thu, Apr 02, 2015 at 05:52:36AM -0700, Yaron Sheffer wrote: > >> On 04/02/2015 05:48 AM, Stephen Farrell wrote: > >>> But isn't it likely we revise the TLS BCP once TLS1.3 is done and > >>> implementations start to become common? We can make sure things > >>> all add up at that point in time, and are in-whack with what people > >>> are deploying, but we don't necessarily need to do so now I think. > >>=20 > >> It entirely likely. But even then, I am not sure we'll be able to > >> convince people who went to AES-256 (presumably, for "compliance" > >> reasons) to move to ChaCha. And certainly not to AES-128... > >=20 > > Must-implement !=3D must-deploy. >=20 > Hi, Nico. >=20 > That=E2=80=99s a nice catch-phrase, but what does it mean? Suppose I am I should have completed the thought :/ And I probably misunderstood your point about compliance. What I'd meant to say is that if external-to-the-IETF "compliance" rules have anything to say on the matter, no problem: - external rules can demand additional algorithms - external rules can demand that some algorithms be disabled that we require to implement External rules could refer to: IoT realities, protocol-specific profiles of TLS, laws and regulations of various countries, corporate policies, ... My catch-phrase was about the latter. > implementing a TLS library specifically for the IoT space. Being a > standards-compliant implementation, my library and all its users will > of course conform to the profile in draft-ietf-dice-profile. That > means TLS_PSK_WITH_AES_128_CCM_8. Given this, why must I implement > AES-GCM? Why should I implement ChaCha? I and any other IoT > implementer will argue that the devices don=E2=80=99t have the memory f= or code > that will never run.=20 This is a bit of a semantics game. Is an implementation of TLS that doesn't implement any of the required algorithms still TLS? Can we have profiles that specify different sets of required/recommended algorithms? The answers don't really matter. Suppose that you are implementing such a library, you don't implement the required algorithms, and that you call the result something like YoavTLS, or FooLangTLS ("TLS for the Foo programming language"). Will the IETF police drag you to the IETF jail for doing that? No. These requirements are really for general purpose TLS implementations. IoT is a bit of a special case for many reasons, not just their limited hardware capabilities. Nico --=20 From nobody Thu Apr 2 13:12: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 7AF901A0366 for ; Thu, 2 Apr 2015 13:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak6WWipkjLX3 for ; Thu, 2 Apr 2015 13:12:39 -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 A77981A065C for ; Thu, 2 Apr 2015 13:12:38 -0700 (PDT) Received: by qgeb100 with SMTP id b100so38347444qge.3 for ; Thu, 02 Apr 2015 13:12:38 -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=8YZW2tNwovo019gfBscyUenqCqtJydkZfyX4tzSC5aI=; b=lujqKZGPP4ohgsTUaBYOlm0l+bcF8rtxMrQa4PSnrhnvXEfxNJOBSHc77DyCKJGjUF vBghlSZGTswPIJOW/Hq9hxYyiTpcsQFhw5bqAjY0VUzCDlZlTHxbbP4eUI/mFidzYTJI zq3VgUADsfCgV4838O+UNDbtiKvgv+VJChv+JkDNVdAmyhaBeyWuoJNHL5p5y3issSdH P5RjSzvS2C2Wwtvrr2SD2W3miLowL1zLsOtRb1JdsbZcDtImUG6+ItREQOK/CcuEi+KX KQPMJx5REfB8eIYlVLSE9OXltXCGCjptB37f3yjCn9jtdcvDxyCmU64rGcbFQcUjZ3W2 IA0A== X-Received: by 10.140.150.151 with SMTP id 145mr12376868qhw.100.1428005557939; Thu, 02 Apr 2015 13:12: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 x10sm4192687qha.2.2015.04.02.13.12.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 13:12:37 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Thu, 2 Apr 2015 16:12:35 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150402194417.GJ10960@localhost> In-Reply-To: <20150402194417.GJ10960@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504021612.35877.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 20:12:40 -0000 On Thursday, April 02, 2015 03:44:18 pm Nico Williams wrote: > The answers don't really matter. Suppose that you are implementing such > a library, you don't implement the required algorithms, and that you > call the result something like YoavTLS, or FooLangTLS ("TLS for the Foo > programming language"). Will the IETF police drag you to the IETF jail > for doing that? No. Fortunately for you, the IETF police are only armed with water balloons made out of an over-engineered rubber that doesn't break on impact, and whilst the IETF jail was agreed to be on an island in the middle of nowhere that nobody can really get to, it has never been constructed because they've been arguing over the color to paint the roof for the past 30 years. :p Serious answer: Just write a separate IoT TLS spec that just contains modifications for whatever isn't viable because you're creating a system not designed to necessarily interoperate with the general Internet. General TLS implementations could implement it as well, or not, depending on needs. Dave From nobody Thu Apr 2 13:34: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 6A2211A1A63 for ; Thu, 2 Apr 2015 13:34:21 -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 okxEwrTKnajm for ; Thu, 2 Apr 2015 13:34:20 -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 AFD8B1A1A5A for ; Thu, 2 Apr 2015 13:34:20 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 5534C1B4078; Thu, 2 Apr 2015 13:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LoyC5ZNpjwOU/r hNClOdHSLKOko=; b=e3licPH6lqh0TXqYmZ6TXeFsWtc5iouSbUe6zbBmAfSZCt 9EEKSaMMkQhI8J/bVoD3kcgQPIRtepmm8d4UM8wavRgNeQL+0KLAeV799BmKRNhM dulAPuNTpN0fvw07hxnI+Kk7RkReewSobmvTSMjK6wjLfNS9FVVuLWvjokDGU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id E4F561B406B; Thu, 2 Apr 2015 13:34:14 -0700 (PDT) Date: Thu, 2 Apr 2015 15:34:14 -0500 From: Nico Williams To: Dave Garrett Message-ID: <20150402203412.GK10960@localhost> References: <20150402194417.GJ10960@localhost> <201504021612.35877.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201504021612.35877.davemgarrett@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 20:34:21 -0000 On Thu, Apr 02, 2015 at 04:12:35PM -0400, Dave Garrett wrote: > Fortunately for you, the IETF police are only armed with water > balloons made out of an over-engineered rubber that doesn't break on > impact, and whilst the IETF jail was agreed to be on an island in the [Not to be a total nitpicker or anything, but a water balloon that doesn't break probably hurts a lot more than one that does!] > middle of nowhere that nobody can really get to, it has never been > constructed because they've been arguing over the color to paint the > roof for the past 30 years. :p Also: it's just a bikeshed. Amnesty International would have one out in a heartbeat. > Serious answer: Just write a separate IoT TLS spec that just contains > modifications for whatever isn't viable because you're creating a > system not designed to necessarily interoperate with the general > Internet. General TLS implementations could implement it as well, or > not, depending on needs. Sure, that'd be nice (because different manufacturers of IoT devices will want to know what to implement as a common denominator). Nico -- From nobody Thu Apr 2 13:36: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 D88841A1A68 for ; Thu, 2 Apr 2015 13:36:01 -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 Q4qttFnEWctT for ; Thu, 2 Apr 2015 13:35:59 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF641A1A7E for ; Thu, 2 Apr 2015 13:35:36 -0700 (PDT) Received: by wiaa2 with SMTP id a2so118825689wia.0 for ; Thu, 02 Apr 2015 13:35:35 -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=s7kzyN/uMZMmU0nvV4C9TNvqno/O1ixs96/IqCxZJTY=; b=gScJOPZH+P6g0/sF9p6OYaqiXhm3jRnUnyZnxRTF2sVg55BOKKwZqpjvxkEGL3LjEv n3THTC0TA3CbeyEIPJz6KSoIT0120HZKWkqhxSwuBCxyBPyc1Yy7eZZ60hqECwUtAnt6 3xTCzReAjWtmulEVdxilIeglts1GIWISHHGL+DjMjdUU1CW7ZGktsUUB/RQTgqmx0PZn JxoZyHz4GHDlUDNM+AVrPIRIQ/3KM5zfVWBf+u6MxJiQUOQTPd9dHGD68wRBmYDe4Vrn 458Wgm+C7ay4mLID+gjoCVcPz1XPqoHHo84R1wqmqScUAOlE/8HoMphULH6CilCkQVI4 cuJA== X-Gm-Message-State: ALoCoQlA1KAG+oKz7NIhvoFo2Cf36MKOt8R+rg9bYNyd10p0/dPFw2Cf78tEoewrdEloBRIbUmGW X-Received: by 10.180.21.178 with SMTP id w18mr27477456wie.90.1428006935190; Thu, 02 Apr 2015 13:35:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Thu, 2 Apr 2015 13:34:55 -0700 (PDT) In-Reply-To: <201504021612.35877.davemgarrett@gmail.com> References: <20150402194417.GJ10960@localhost> <201504021612.35877.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 2 Apr 2015 13:34:55 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7bb70a7c1bf4970512c3c6fa Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 20:36:02 -0000 --047d7bb70a7c1bf4970512c3c6fa Content-Type: text/plain; charset=UTF-8 Indeed: https://tools.ietf.org/html/draft-ietf-dice-profile-10 -Ekr On Thu, Apr 2, 2015 at 1:12 PM, Dave Garrett wrote: > On Thursday, April 02, 2015 03:44:18 pm Nico Williams wrote: > > The answers don't really matter. Suppose that you are implementing such > > a library, you don't implement the required algorithms, and that you > > call the result something like YoavTLS, or FooLangTLS ("TLS for the Foo > > programming language"). Will the IETF police drag you to the IETF jail > > for doing that? No. > > Fortunately for you, the IETF police are only armed with water balloons > made out of an over-engineered rubber that doesn't break on impact, and > whilst the IETF jail was agreed to be on an island in the middle of nowhere > that nobody can really get to, it has never been constructed because > they've been arguing over the color to paint the roof for the past 30 > years. :p > > Serious answer: Just write a separate IoT TLS spec that just contains > modifications for whatever isn't viable because you're creating a system > not designed to necessarily interoperate with the general Internet. General > TLS implementations could implement it as well, or not, depending on needs. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7bb70a7c1bf4970512c3c6fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 2, 2015 at 1:12= PM, Dave Garrett <davemgarrett@gmail.com> wrote:
On Thursday, April 02, 2015 0= 3:44:18 pm Nico Williams wrote:
> The answers don't really matter.=C2=A0 Suppose that you are implem= enting such
> a library, you don't implement the required algorithms, and that y= ou
> call the result something like YoavTLS, or FooLangTLS ("TLS for t= he Foo
> programming language").=C2=A0 Will the IETF police drag you to th= e IETF jail
> for doing that?=C2=A0 No.

Fortunately for you, the IETF police are only armed with water ballo= ons made out of an over-engineered rubber that doesn't break on impact,= and whilst the IETF jail was agreed to be on an island in the middle of no= where that nobody can really get to, it has never been constructed because = they've been arguing over the color to paint the roof for the past 30 y= ears. :p

Serious answer: Just write a separate IoT TLS spec that just contains modif= ications for whatever isn't viable because you're creating a system= not designed to necessarily interoperate with the general Internet. Genera= l TLS implementations could implement it as well, or not, depending on need= s.


Dave

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

--047d7bb70a7c1bf4970512c3c6fa-- From nobody Thu Apr 2 13:55: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 E758B1A1AFB for ; Thu, 2 Apr 2015 13:55: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 V5dZuSsILHqN for ; Thu, 2 Apr 2015 13:55:36 -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 241091A1ADD for ; Thu, 2 Apr 2015 13:55:36 -0700 (PDT) Received: by qgdy78 with SMTP id y78so18239822qgd.0 for ; Thu, 02 Apr 2015 13:55:35 -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=AyBQIu2tp6Tm2sRs9G7NEZQDSBHvao9S1jEQhL2HGnI=; b=z6I0aNnW86573B53yn+SUfWFi0Epns0tYhmLrihrO1EUFRlU+//N8kwQczciUynnAx NPpj/k9lYXxwELqgeo/ge7b/oHXoSuM/oM0iR4mgf3benkGKNZlGDciUcEXU/0RhRyso HDnV/KDEj/RW0t31RwiCP+QLfKmAsxRhZg6+9FuyZUNumk3DoWM53v9OptAzu3hVRFqf UoynU7kDQlyw1WD6Bbf+l1fJBYZtMTmQ7d65h/zCWv4hWfCIZaDLggFCxN86offbf64n vzoNtoKTAOwmHBm4DfIDP/LZW++cGdoYd3Puj+sFXHSkz7n8KQGE8vTiuTWvdxfYYgbV ejcA== X-Received: by 10.140.48.37 with SMTP id n34mr46091206qga.82.1428008135397; Thu, 02 Apr 2015 13:55:35 -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 15sm4247013qhx.31.2015.04.02.13.55.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 13:55:34 -0700 (PDT) From: Dave Garrett To: Nico Williams Date: Thu, 2 Apr 2015 16:55:33 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504021612.35877.davemgarrett@gmail.com> <20150402203412.GK10960@localhost> In-Reply-To: <20150402203412.GK10960@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201504021655.33958.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 20:55:38 -0000 On Thursday, April 02, 2015 04:34:14 pm Nico Williams wrote: > On Thu, Apr 02, 2015 at 04:12:35PM -0400, Dave Garrett wrote: > > Fortunately for you, the IETF police are only armed with water > > balloons made out of an over-engineered rubber that doesn't break on > > impact, and whilst the IETF jail was agreed to be on an island in the > > [Not to be a total nitpicker or anything, but a water balloon that > doesn't break probably hurts a lot more than one that does!] Nah, very stretchy. Just mildly annoying. But they're too expensive anyway, so it's not like you'll ever see one. > > middle of nowhere that nobody can really get to, it has never been > > constructed because they've been arguing over the color to paint the > > roof for the past 30 years. :p > > Also: it's just a bikeshed. Amnesty International would have one out in > a heartbeat. Also, there's no enforcement. It's basically just an island vacation. > > Serious answer: Just write a separate IoT TLS spec that just contains > > modifications for whatever isn't viable because you're creating a > > system not designed to necessarily interoperate with the general > > Internet. General TLS implementations could implement it as well, or > > not, depending on needs. > > Sure, that'd be nice (because different manufacturers of IoT devices > will want to know what to implement as a common denominator). On Thursday, April 02, 2015 04:34:55 pm Eric Rescorla wrote: > Indeed: > https://tools.ietf.org/html/draft-ietf-dice-profile-10 The existing TLS 1.3 spec already says: "In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite [...]" Maybe just describe the issue in more detail, possibly even cite some profile(s) that could be considered? I don't think there's really any disagreement here on what MTI means in this scenario, but a more thorough explanation that this section is over-ridable for specialized cases wouldn't hurt. Dave From nobody Thu Apr 2 14:28: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 47BE21A6EF4 for ; Thu, 2 Apr 2015 14:28: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 mHDiIoILmbN8 for ; Thu, 2 Apr 2015 14:28:15 -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 9EB341A6EE1 for ; Thu, 2 Apr 2015 14:28:14 -0700 (PDT) Received: by wizk4 with SMTP id k4so28289947wiz.1 for ; Thu, 02 Apr 2015 14:28:13 -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=nNCqwHajq3ST+4CeHqe4d9gbO83evVR05VHKtn0D6Dc=; b=gd48r2WbqSGylN3hHfWeLERd36Qm/vIk451/yxAMsXhyTpiQcFNuhZHGpvtH0jwbUm lwbpXBmJETqqp1H2hlpTDTc1JtihXPNQhzUA86nKsuTOSeBJs0rLvYDRj1YVnWoAe3vH x7OZ7uQFYT2m1uOqTyqTDnd/dxqw8YA5F+YHaGZzoZ00oYwQihmBav784LLK1s8Fhce3 pL76J8wWSmOWf3PPG9JqKgofqnS9hJRzwOXwsRhtRsfnN/fCHxU3MfW1Mz0yZMASKnaD 7nZ9Ndse5m2o9A6vpOO8hdmcshvVAaHEUK0GFsDANIvrngdHMfLYITOxCFJHaYCRsYFN 7bVg== X-Received: by 10.195.11.73 with SMTP id eg9mr95419043wjd.62.1428010093349; Thu, 02 Apr 2015 14:28:13 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id cj9sm8865037wjc.42.2015.04.02.14.28.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 14:28:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <201504021612.35877.davemgarrett@gmail.com> Date: Fri, 3 Apr 2015 00:28:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <45AA2438-891F-4B36-AD2C-EA06D57ED8EF@gmail.com> References: <20150402194417.GJ10960@localhost> <201504021612.35877.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 21:28:16 -0000 > On Apr 2, 2015, at 11:12 PM, Dave Garrett = wrote: >=20 >=20 > Serious answer: Just write a separate IoT TLS spec that just contains = modifications for whatever isn't viable because you're creating a system = not designed to necessarily interoperate with the general Internet. = General TLS implementations could implement it as well, or not, = depending on needs. I thought the whole point of IoT (as opposed to proprietary protocols) = was that it *did* interact with the Internet. But that aside, =E2=80=9Cthe= web=E2=80=9D as represented by the HTTP/2 document made its own = profile. For applications other than =E2=80=9Cthe web=E2=80=9D, UTA made = their BCP document. For the IoT DICE made their profile.=20 So everyone has their own MTI algorithms, some of them contradictory to = what we are proposing to recommend. So who takes their MUSTs and SHOULDs = from TLS as opposed to their own niche document? Yoav From nobody Thu Apr 2 14:31: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 7A5C21A6EF4 for ; Thu, 2 Apr 2015 14:31:41 -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 kMcT3b4s5VZ0 for ; Thu, 2 Apr 2015 14:31:39 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.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 4C5A91A6EFC for ; Thu, 2 Apr 2015 14:31:39 -0700 (PDT) Received: by qgep97 with SMTP id p97so80671578qge.1 for ; Thu, 02 Apr 2015 14:31:38 -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=M3N4bu+nnB9DBVdTIc3IXIM0ACxazVE0avEEGC7j1yQ=; b=Ta2/JsPrqJcP92HcOHKAawd1EDpmZV/1248b5rC2js1r7twM38BCpVhvx4QYZqo0Ot DB2x9T5ZLqqAJnB6KviK/39zEksMMKvTjeEXjMn/7DS2xqTBX9qBOoAPco9BSRf8GEeo hYQm7LNMxG2EZRKL7IQg+18jsl74qObOCoUVdFiz/Nx6uthUf5Yj6n7IF8+xpLjYO61l Jie1ZXqe/EIpOcTsslGI9vW3L1e2efF2fKvjurdvZ+7iWG16k3jvZhdMMTCxlowd8iS+ xe9GMDT025NEgnpIFEmiHzYxV14IyfI4sYo9XtPkIemEDsUYZCG9AUYOHuSCgpVIj19Q bu+g== X-Gm-Message-State: ALoCoQlTQjHsDJObj6LlFzus9GijcDHxdbnoAoBKftBp7nbmCLFG56OWg1fIgzk5EHjynrdOWS1J MIME-Version: 1.0 X-Received: by 10.140.165.198 with SMTP id l189mr66370934qhl.93.1428010298472; Thu, 02 Apr 2015 14:31:38 -0700 (PDT) Received: by 10.96.121.104 with HTTP; Thu, 2 Apr 2015 14:31:38 -0700 (PDT) X-Originating-IP: [50.206.82.141] In-Reply-To: <201504021257.09955.davemgarrett@gmail.com> References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> Date: Thu, 2 Apr 2015 14:31:38 -0700 Message-ID: From: Joseph Salowey To: Dave Garrett Content-Type: multipart/alternative; boundary=001a1134ee6e9392b70512c48e9f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 21:31:41 -0000 --001a1134ee6e9392b70512c48e9f Content-Type: text/plain; charset=UTF-8 I think I would prefer to break things up between what is needed for the record protection and what is needed for authentication (of the peer). The argument has been made on other threads on the list that these are two separate concerns and I think it would be best to treat each one as a unit. I think TLS 1.3 will make this separation a bit more formal especially with the removal of RSA key transport. The record layer protection aspect would include things directly involved in generating and using the encryption keys: AEAD Cipher (e.g. AES-GCM) + Key agreement (e.g. DH) + KDF/PRF (HKDF-SHA256) I'm tempted to throw the groups used in the DH agreement (25519, p-256,etc) because that way you can make sure you are consistent matching your algorithm strength between key agreement and encryption. I could also see negotiating the group separately to contain the combinatorial possibilities of allocations, although we may want to warn against some combinations It might make sense to tie the KDF into Key agreement and perhaps these are fixed to the TLS version. Authentication would include what the handshake uses use for authenticating the peers. It seems there are a number of parameters here: signature algorithm (RSA-PSS-SHA256, PSK MAC, PAKE), certification parameters (cert types and params), handshake hash (maybe this is set by the KDF above). The parameterization of authentication mechanisms may be a bit more complex, but I think we have much of the machinery there already, it just may need to be tweaked a bit. Joe On Thu, Apr 2, 2015 at 9:57 AM, Dave Garrett wrote: > On Thursday, April 02, 2015 12:45:35 pm Nico Williams wrote: > > On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos > wrote: > > > I think full a-la-carte is too complex. But I'm for negotiating the > > > handshake and symmetric crypto separately. They're already very > > > loosely coupled and most proposals that introduce/obsolete > > > ciphersuites are only interested in one of the two sides, with the > > > other being only an afterthought. > > > > That would be a huge improvement over what we have now. > > That could be a good middle ground. Just split cipher suites into > essentially asymmetric & symmetric cipher suites, and put them both in the > same array. Server just picks one of each for handshake & connection. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1134ee6e9392b70512c48e9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think I would prefer to break things up between what is = needed for the record protection and what is needed for authentication (of = the peer). =C2=A0 The argument has been made on other threads on the list t= hat these are two separate concerns and I think it would be best to treat e= ach one as a unit.=C2=A0 I think TLS 1.3 will make this separation a bit mo= re formal especially with the removal of RSA key transport.=C2=A0

<= /div>
The record layer protection aspect would include things directly = involved in generating and using the encryption keys:

<= div>=C2=A0 =C2=A0 =C2=A0 AEAD Cipher (e.g. AES-GCM) + =C2=A0Key agreement (= e.g. DH) =C2=A0+ KDF/PRF (HKDF-SHA256)

I'm tem= pted to throw the groups used in the DH agreement (25519, p-256,etc) becaus= e that way you can make sure you are consistent matching your algorithm str= ength between key agreement and encryption. =C2=A0 I could also see negotia= ting the group separately to contain the combinatorial possibilities of all= ocations, although we may want to warn against some combinations =C2=A0 =C2= =A0It might make sense to tie the KDF into Key agreement and perhaps these = are fixed to the TLS version.

Authentication would= include what the handshake uses use for authenticating the peers. =C2=A0 I= t seems there are a number of parameters here: signature algorithm (RSA-PSS= -SHA256, PSK MAC, PAKE), certification parameters (cert types and params), = handshake hash (maybe this is set by the KDF above). =C2=A0 The parameteriz= ation of authentication mechanisms may be a bit more complex, but I think w= e have much of the machinery there already, it just may need to be tweaked = a bit. =C2=A0

Joe





=C2=A0 =C2=A0=C2=A0

On Thu, = Apr 2, 2015 at 9:57 AM, Dave Garrett <davemgarrett@gmail.com><= /span> wrote:
On Thursda= y, April 02, 2015 12:45:35 pm Nico Williams wrote:
> On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos <codesinchaos@gmail.com> wrote:
> > I think full a-la-carte is too complex. B= ut I'm for negotiating the
> > handshake and symmetric crypto separately. They're already ve= ry
> > loosely coupled and most proposals that introduce/obsolete
> > ciphersuites are only interested in one of the two sides, with th= e
> > other being only an afterthought.
>
> That would be a huge improvement over what we have now.

That could be a good middle ground. Just split cipher suites into es= sentially asymmetric & symmetric cipher suites, and put them both in th= e same array. Server just picks one of each for handshake & connection.=


Dave

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

--001a1134ee6e9392b70512c48e9f-- From nobody Thu Apr 2 14:43: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 8227C1A6FFB for ; Thu, 2 Apr 2015 14:43:45 -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 SWmcxjo8GGH3 for ; Thu, 2 Apr 2015 14:43:44 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 09B621A700F for ; Thu, 2 Apr 2015 14:43:44 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id A7019508072; Thu, 2 Apr 2015 14:43:43 -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=tILfJT0oNsUm6dcYXljPIZIz11E=; b=kpTnyAY+VnA MiQidjNAP4PutajRrH8rfUjhWyB1ldnfKXKqMPgGNxga2OqlB5DfACSMFZBfImru WAa191CvHT0sQsPt1zT3i3IrlTf114kAwVyRoybFYy+xb2ZWkTeX56486MFSazKm 84HJuT0XZEZGiQDdF9SwRMPp22YomIPQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 4F118508064; Thu, 2 Apr 2015 14:43:43 -0700 (PDT) Date: Thu, 2 Apr 2015 16:43:42 -0500 From: Nico Williams To: Yoav Nir Message-ID: <20150402214341.GM10960@localhost> References: <20150402194417.GJ10960@localhost> <201504021612.35877.davemgarrett@gmail.com> <45AA2438-891F-4B36-AD2C-EA06D57ED8EF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <45AA2438-891F-4B36-AD2C-EA06D57ED8EF@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 21:43:45 -0000 On Fri, Apr 03, 2015 at 12:28:09AM +0300, Yoav Nir wrote: > I thought the whole point of IoT (as opposed to proprietary protocols) > was that it *did* interact with the Internet. But that aside, =E2=80=9C= the > web=E2=80=9D as represented by the HTTP/2 document made its own profile= . For > applications other than =E2=80=9Cthe web=E2=80=9D, UTA made their BCP d= ocument. For > the IoT DICE made their profile.=20 I'm not entirely sure that I want my things interacting with the web. I may want to interact with my things across the Internet. IoT needs something of a definition, yeah? > So everyone has their own MTI algorithms, some of them contradictory > to what we are proposing to recommend. So who takes their MUSTs and > SHOULDs from TLS as opposed to their own niche document? IoT seems rather special. Ignoring IoT, how many profiles of TLS do you think we'd need for the protocols and non-IoT devices we have now? IoT's definition, scope, requirements, ... -- we're going to need to pin these down. As for *this* thread, I think we should factor IoT out. Nico --=20 From nobody Thu Apr 2 15:05: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 7EEF91A86F4 for ; Thu, 2 Apr 2015 15:05:19 -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 FV_NRu3Zhrtb for ; Thu, 2 Apr 2015 15:05:14 -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 0A33E1A3BA3 for ; Thu, 2 Apr 2015 15:05:14 -0700 (PDT) Received: by qgep97 with SMTP id p97so81240068qge.1 for ; Thu, 02 Apr 2015 15:05: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=xYCskg7MaQRyWDsoN6QY7qIlUZT6os22BRS1VrY0zzM=; b=AYFv1XpNo8C/2JKa74cs3XdoFyZE0SZqWPJ3m3lgVQT1hzdKJFl2wE4epiQg+X2Pq/ 5nVPwR14QCGCQ2xyDiaemt/cpaItpUYnyCkPVpCeseQg1Y98d7WjOrl5qKDOJ4B9Qpjq JtTxNFs61sci0ek1mPPuu4otG1QCBmcOQvoOuhnigSjfWMa9Pkwdql8lwqHo4WV3iL9d PHsw6MqIa4mAjQ3emDDVXDC4mxbHxAIyGBXG8vbtuiPmj78J9vraOcIS+SpJ5B3+BUFf 4TowDfCdGikjOo8S59r/exk0wvkoh6+Pxik6t13pLU9iM3jKz6WptvfAmOtS9DmFSKp6 qwJQ== X-Received: by 10.229.214.199 with SMTP id hb7mr66402553qcb.12.1428012313345; Thu, 02 Apr 2015 15:05:13 -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 f44sm4400837qgd.3.2015.04.02.15.05.12 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 15:05:12 -0700 (PDT) From: Dave Garrett To: Yoav Nir Date: Thu, 2 Apr 2015 18:05:11 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504021612.35877.davemgarrett@gmail.com> <45AA2438-891F-4B36-AD2C-EA06D57ED8EF@gmail.com> In-Reply-To: <45AA2438-891F-4B36-AD2C-EA06D57ED8EF@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201504021805.11751.davemgarrett@gmail.com> Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 22:05:19 -0000 On Thursday, April 02, 2015 05:28:09 pm Yoav Nir wrote: > But that aside, =E2=80=9Cthe web=E2=80=9D as represented by the HTTP/2 do= cument made its own profile. For applications other than =E2=80=9Cthe web= =E2=80=9D, UTA made their BCP document. For the IoT DICE made their profile= =2E=20 >=20 > So everyone has their own MTI algorithms, some of them contradictory to w= hat we are proposing to recommend. So who takes their MUSTs and SHOULDs fro= m TLS as opposed to their own niche document? HTTP/2 & 1.1 will be using the MTIs in the TLS 1.3 spec. The additional req= uirements on TLS in the HTTP/2 spec are explicitly restricted to TLS 1.2 us= e. (TLS 1.0 & 1.1 being prohibited) The only requirement on TLS 1.3+ use is= mandatory usage of SNI. Dave From nobody Thu Apr 2 15:23: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 C9BA01A7028 for ; Thu, 2 Apr 2015 15:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, 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 C2nARZL2LarC for ; Thu, 2 Apr 2015 15:23:08 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (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 3FFF81A1BF8 for ; Thu, 2 Apr 2015 15:23:08 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 77C211EF73; Thu, 2 Apr 2015 22:23:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1428013387; bh=Gdnn+5cx12zwF59wONkW7H1Hnis3mS3orJaIi4j96HE=; h=From:To:Subject:In-Reply-To:References:Date:From; b=OaUbXiRKhOrXi3NauWrfS5LFANSX8jwI9hG5KqsEi5pBoYowoVeAdTuP2Kc5LIy6u bJ3g+nZyGqz60u7sNSWB+/cOkScI82rlW/Ju6e2hLa4AnBkn9suIm+CT2SKnK8gubP f6aC3prSZtoLPhieSHCT4JqGqj69IAjL6XwKftrU= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 95B32106FD882; Thu, 2 Apr 2015 22:22:59 +0000 (UTC) From: James Cloos To: tls@ietf.org In-Reply-To: <20150402191657.43cd35ee@pc1.fritz.box> ("Hanno =?iso-8859-1?Q?B=F6ck=22's?= message of "Thu, 2 Apr 2015 19:16:57 +0200") References: <20150402191657.43cd35ee@pc1.fritz.box> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 02 Apr 2015 18:22:59 -0400 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150402:tls@ietf.org::IUm8TXqDAdM5M78i:00001J4o5 Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2015 22:23:10 -0000 For symmetric, chacha20-poly1305 ought to be MUST, and the MUST AES should be at (about) the same security level, ie AES256. Even on slow hardware the speed difference between aes128 and aes256 is not enough to make 128 mandatory and 256 optional, rather than vice-versa. On a pi b+, openssl's implementation of 256 is about 7/8ths as fast as 128. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Thu Apr 2 15:36: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 08CB91A872C for ; Thu, 2 Apr 2015 15:36: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, 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 ew_6ICofKRlY for ; Thu, 2 Apr 2015 15:36:02 -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 3DB151A1B49 for ; Thu, 2 Apr 2015 15:36:02 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 812A41C20DF; Fri, 3 Apr 2015 00:35:59 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 668BF1FE074A; Fri, 3 Apr 2015 00:35:59 +0200 (CEST) Date: Fri, 3 Apr 2015 00:35:59 +0200 From: Kurt Roeckx To: Nico Williams Message-ID: <20150402223559.GA23692@roeckx.be> References: <20150401201221.163745c2@pc1.fritz.box> <20150402002646.GR17637@mournblade.imrryr.org> <551C9008.5030605@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Thu, 02 Apr 2015 22:36:04 -0000 On Wed, Apr 01, 2015 at 07:48:36PM -0500, Nico Williams wrote: > > It would be easier to specify the inputs to the cartesian product. > > It would be better to also negotiate (cipher+mode), (hash), (KDF), and > (key agreement+server authentication) separately. I've been wondering about getting rid of the ciphers as we know it now and that maybe each of the components should instead have it's own extension. Kurt From nobody Thu Apr 2 16:33: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 97AE11A8792 for ; Thu, 2 Apr 2015 16:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TQV2QynczVmc for ; Thu, 2 Apr 2015 16:33:30 -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 782731A038A for ; Thu, 2 Apr 2015 16:33:30 -0700 (PDT) Received: by qgfi89 with SMTP id i89so209371qgf.1 for ; Thu, 02 Apr 2015 16:33: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=tDHRLPVgf+EanYXTG3OySVY6uH3FvJEsT92iWtAzsyY=; b=BOoUkWEXStT4k2EG2qMef9DjE1aoFhNMzrN/aJGtljVCB77mYTPcECE1oCUEXGMkSW SLClFAU3y7qmsrxQtKNNyK3K9JGH5DXPTzxUtF9/M6sPWoVqQEQYZdbhXV+oK+KjNjj7 Sh5BF9f3BDEY+Fyf3hBrmLkBbpFyad9OywkT7ia98bzQSIRVUW//mjjtgKO3kKqimZK4 cxKNvC10vr8LXo8jsUZPz2lkObCK56TwCqZrDOPe5D7RXhwF88/3xOnF9EDZrlNE9i4a nemrC2r5BGDXA9d/bz/f4NgOc8y9E+Fx6UOhMagiCK58Qn28fJNvz2VxDHwwhJY/8pmC jsRw== X-Gm-Message-State: ALoCoQn7IGJT8hNWbn1EtFlPscrp0lKV2lrDmKj8jgDpmqSrIHj1Rl0rzKIR58+x9okLeBCZYlNB X-Received: by 10.140.84.164 with SMTP id l33mr62448427qgd.11.1428017609615; Thu, 02 Apr 2015 16:33:29 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:f827:63cf:7b05:550e? ([2601:a:2a00:84:f827:63cf:7b05:550e]) by mx.google.com with ESMTPSA id h34sm4516683qkh.34.2015.04.02.16.33.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 16:33:28 -0700 (PDT) Message-ID: <551DD1CC.1040502@nthpermutation.com> Date: Thu, 02 Apr 2015 19:33:32 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <20150401201221.163745c2@pc1.fritz.box> In-Reply-To: <20150401201221.163745c2@pc1.fritz.box> Content-Type: multipart/alternative; boundary="------------060902030403030002000605" Archived-At: Subject: Re: [TLS] 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: Thu, 02 Apr 2015 23:33:32 -0000 This is a multi-part message in MIME format. --------------060902030403030002000605 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 4/1/2015 2:12 PM, Hanno Bck wrote: > Hi, > > Mozilla just removed DSA support from Firefox. It seems the use of > (non-ecc) DSA in TLS is pretty much nonexistent. Still the TLS 1.3 draft > contains DSA. > > Proposal: DSA should go away and not be part of TLS 1.3. To translate the above, its basically asking that DHE_DSS and DH_DSS be removed as key exchange mechanisms. I've watched the discussion and mostly this is a don't care for me except: This is a cipher suite issue and nothing else. E.g. its an implementation decision rather than a protocol decision and vendors should be free to offer this if they think they have a market. The rest of us should gleefully remove this from the set of cipher suites we offer or accept. I would deprecate the older suites (e.g. anything less than <112 bits of strength) on general principles, but I would leave the choice whether or not to implement these to those who will charge what they need to charge when these are specified in RFPs as necessary. So for the base question - no. The section on DHE_DSS and DH_DSS in the TLS1.3 document should be unchanged from the TLS1.2 document AFAICT so there shouldn't be any additional work leaving it. Mike > > Reasons to remove DSA: > * DSA with 1024 bit is considered weak and DSA with more than 1024 bit > is widely unsupported. > * DSA has comparable security to RSA (it using same keysize) which is > the de-facto-default. Given that everybody uses RSA and nobody uses > DSA having the latter only adds unneccessary complexity. > * DSA can fail badly with bad random number generators. > > Some numbers: > In the 2013 https ecosystem scan there were 17 DSA keys on public IPs, > none of them CA-trusted: > http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf > > I think it's safe to say nobody will care if DSA is removed. > > cu, > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------060902030403030002000605 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 4/1/2015 2:12 PM, Hanno Bck wrote:
Hi,

Mozilla just removed DSA support from Firefox. It seems the use of
(non-ecc) DSA in TLS is pretty much nonexistent. Still the TLS 1.3 draft
contains DSA.

Proposal: DSA should go away and not be part of TLS 1.3.
To translate the above, its basically asking that DHE_DSS and DH_DSS be removed as key exchange mechanisms.

I've watched the discussion and mostly this is a don't care for me except:

This is a cipher suite issue and nothing else. E.g. its an implementation decision rather than a protocol decision and vendors should be free to offer this if they think they have a market. The rest of us should gleefully remove this from the set of cipher suites we offer or accept.

I would deprecate the older suites (e.g. anything less than <112 bits of strength) on general principles, but I would leave the choice whether or not to implement these to those who will charge what they need to charge when these are specified in RFPs as necessary.

So for the base question - no. The section on DHE_DSS and DH_DSS in the TLS1.3 document should be unchanged from the TLS1.2 document AFAICT so there shouldn't be any additional work leaving it.

Mike


Reasons to remove DSA:
* DSA with 1024 bit is considered weak and DSA with more than 1024 bit
  is widely unsupported.
* DSA has comparable security to RSA (it using same keysize) which is
  the de-facto-default. Given that everybody uses RSA and nobody uses
  DSA having the latter only adds unneccessary complexity.
* DSA can fail badly with bad random number generators.

Some numbers:
In the 2013 https ecosystem scan there were 17 DSA keys on public IPs,
none of them CA-trusted:
http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf

I think it's safe to say nobody will care if DSA is removed.

cu,



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

--------------060902030403030002000605-- From nobody Thu Apr 2 17:22: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 ABE711A8908 for ; Thu, 2 Apr 2015 17:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 XUtYcUvEwHtH for ; Thu, 2 Apr 2015 17:22:36 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.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 E75BD1A8905 for ; Thu, 2 Apr 2015 17:22:35 -0700 (PDT) Received: by qcrf4 with SMTP id f4so67718934qcr.0 for ; Thu, 02 Apr 2015 17:22:35 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Y5GFYukvctYVr76icp/MyZFcuAEKmBd2VLwnsDnLrFk=; b=cPFruHKyMy5UoVZHpHu60NhyKKQ1ReVEC8knVVKE5BGfjX/zPdPV2iuznRq1fMK795 xC3oXKKvRqBIMiAY7774urPTUwxXQOVUFRlOOYePPCxKKiiBxM/2MVL7x6kseOrBjA7D QpzDX844t4Q/O3RL3zOq6wXZDwi+lWklVWqwabMkHdDOkf50gDimgFxYSgZmahDW6m0b QURLna9ZnuBOno8eW2vsQYu2trff0FuU+SRVI2bdNIRB4G5EZMsheHu6BRXO8L7XYseR If94ijjVPvrWpvQ0QMhIJIjin6gPxyO8k/mJrgtC4W956XB3T1kT3OyoW/hSsYVvfmD/ mnOA== X-Gm-Message-State: ALoCoQlv3ceFXs7lCsQ+IIVAB/aotdoDZ1lbMGVZNlRnzFZEtcs8nIQQGtl1a4A6jAxiF6C1Ssqx X-Received: by 10.141.23.205 with SMTP id z196mr65651021qhd.66.1428020555114; Thu, 02 Apr 2015 17:22:35 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:f827:63cf:7b05:550e? ([2601:a:2a00:84:f827:63cf:7b05:550e]) by mx.google.com with ESMTPSA id 138sm4608248qhx.7.2015.04.02.17.22.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 17:22:34 -0700 (PDT) Message-ID: <551DDD4E.5070509@nthpermutation.com> Date: Thu, 02 Apr 2015 20:22:38 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> In-Reply-To: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 00:22:37 -0000 On 4/1/2015 2:00 PM, Sean Turner wrote: > This message is to confirm the consensus reached @ the IETF 92 TLS session in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an HKDF-based PRF (see http://datatracker.ietf.org/doc/rfc5869/?include_text=1). > > Please indicate whether or not you agree with the consensus by 2015-04-17. If not, please indicate why. Also, please note that were interested in uncovering new issues not rehashing issues already discussed. > > Thanks - J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls I have a large preference to move to a different KDF than we're currently using. (And to limit the output of said KDF to key material and nothing else). Deprecating the current TLS KDF will help with resolving some HSM related security issues. I have a medium preference that that KDF be counter based rather than recursive (as is the current PRF and HKDF). I've got a sneaking suspicion that doing so would be cleaner to implement in hardware as the only field changing with every call to HMAC is that of the counter. I have a small preference that we cite a more widely accepted/reviewed standard than RFC5869 (which is basically the authors republication of their original paper or vice versa). I will note that the author claimed in his paper that the IETF was standardizing this, but I can't find any data suggesting this actually went through the IETF standardization process (vs independent informational RFC submission process). It did garner some review on the CFRG mailing list, but not to what I normally think of as comprehensive and resolving all comments. I wish David et al had ended up completing the work on https://datatracker.ietf.org/doc/draft-irtf-cfrg-kdf-uses/, but what's there suggests that we could select one of those instead and get a more widely acceptable KDF. All that said, I won't oppose HKDF. Mike From nobody Thu Apr 2 17:38: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 D8B7C1A8996 for ; Thu, 2 Apr 2015 17:37:57 -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 JjXDd2WiEmj1 for ; Thu, 2 Apr 2015 17:37:56 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 5111D1A8994 for ; Thu, 2 Apr 2015 17:37:56 -0700 (PDT) Received: from [173.75.83.181] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YdpcR-0004Vy-HL for tls@ietf.org; Thu, 02 Apr 2015 19:37:55 -0500 Date: Thu, 2 Apr 2015 17:37:50 -0700 From: Bill Frantz To: tls@ietf.org X-Priority: 3 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec791ce8ce0d6e7ca1b1d77933f8a9f1a483350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.181 Archived-At: Subject: [TLS] Killing Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 00:37:58 -0000 There has been discussion stating that having at least two=20 algorithms for each function allows algorithms to be turned off=20 when weaknesses are discovered. There needs to be a way to=20 actually implement this decision. At a minimum, the security considerations section should mention=20 this requirement. Perhaps saying something like this: History has shown that all of the algorithms SSL/TLS depended on=20 20 years ago have been shown to have weaknesses and as a result,=20 they are no longer included in TLS 1.3. There is no reason to=20 believe that the algorithms required for TLS 1.3 won't share=20 their fate. TLS 1.3 requires at least 2 algorithms for each=20 security function so failing algorithms can be turned off. Each=20 implementation of TLS MUST have a technique for effectively=20 turning algorithms off. ----------- From my point of view, acceptable techniques include online=20 code update and special messages which cause implementations to=20 permanently cease using an algorithm, along with methods and=20 procedures to ensure that these techniques actually work in the field. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz |Security, like correctness, is| Periwinkle (408)356-8506 |not an add-on feature. - Attr-| 16345=20 Englewood Ave www.pwpconsult.com |ibuted to Andrew Tanenbaum | Los Gatos,=20 CA 95032 From nobody Thu Apr 2 18:12: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 2B3441A8AAA for ; Thu, 2 Apr 2015 18:12:46 -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 KZBatPDnSR1M for ; Thu, 2 Apr 2015 18:12:44 -0700 (PDT) Received: from p3plsmtpa06-07.prod.phx3.secureserver.net (p3plsmtpa06-07.prod.phx3.secureserver.net [173.201.192.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079CA1A8A9E for ; Thu, 2 Apr 2015 18:12:43 -0700 (PDT) Received: from spectre ([173.8.184.78]) by p3plsmtpa06-07.prod.phx3.secureserver.net with id BDCi1q0061huGat01DCijb; Thu, 02 Apr 2015 18:12:43 -0700 From: "Peter Yee" To: "'Bill Frantz'" , References: In-Reply-To: Date: Thu, 2 Apr 2015 18:12:51 -0700 Message-ID: <005801d06dab$4edcc1f0$ec9645d0$@akayla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHskLZoBr1oJ1vV2//8VjKecJuha50CM1oA Content-Language: en-us Archived-At: Subject: Re: [TLS] Killing Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 01:12:46 -0000 I don't think killing off algorithms has been a problem of not having a means to do so. Rather, I suspect it's a question of inertia. It takes a really catastrophic failure or wide news coverage of a new attack to move server admins away from a configuration that "has been working fine up until now." Breaking someone's fielded server setup with a special message is not going to be a popular feature. Enterprises are a conservative lot when it comes to changing things. -Peter -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Bill Frantz Sent: Thursday, April 02, 2015 5:38 PM To: tls@ietf.org Subject: [TLS] Killing Algorithms There has been discussion stating that having at least two algorithms for each function allows algorithms to be turned off when weaknesses are discovered. There needs to be a way to actually implement this decision. At a minimum, the security considerations section should mention this requirement. Perhaps saying something like this: History has shown that all of the algorithms SSL/TLS depended on 20 years ago have been shown to have weaknesses and as a result, they are no longer included in TLS 1.3. There is no reason to believe that the algorithms required for TLS 1.3 won't share their fate. TLS 1.3 requires at least 2 algorithms for each security function so failing algorithms can be turned off. Each implementation of TLS MUST have a technique for effectively turning algorithms off. ----------- From my point of view, acceptable techniques include online code update and special messages which cause implementations to permanently cease using an algorithm, along with methods and procedures to ensure that these techniques actually work in the field. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz |Security, like correctness, is| Periwinkle (408)356-8506 |not an add-on feature. - Attr-| 16345 Englewood Ave www.pwpconsult.com |ibuted to Andrew Tanenbaum | Los Gatos, CA 95032 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Apr 2 18: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 3268F1A8AB2 for ; Thu, 2 Apr 2015 18:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2KCSJn3SVTYe for ; Thu, 2 Apr 2015 18:12:49 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.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 A21341A7030 for ; Thu, 2 Apr 2015 18:12:49 -0700 (PDT) Received: by qcbii10 with SMTP id ii10so58220980qcb.2 for ; Thu, 02 Apr 2015 18:12:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=FALYNgpbHPdiPtKZ5gApvI2w9LJd2Cn+w5P/aIaIxHk=; b=kbXpPdHBjLIPQYmkuOU2GrCqx1A0t0SmQn1PjFQA6Pc0zv7bKEID+ES8kzt7XZkxZe 9gFU9R60H14QHmAEDqlQ9XqvSymQ5LK228wFif5sQwYllD9YSjh50tVn31E8w/qXOCI1 Ejskjp7JzoZfBaXOOXGDo5rWNdZc/wAhGxzUqbXwkNmL0yWnDOC58O0QOTaFuc7C08tu EebeG/Vfl6B5FwQQE3eVuNx06qsOSJZ88IpmCBfoHtpHmYiKfiLDwlwRO+cAQkLnuEep ep45cYw1Hcez5D4xQQIkjLKGmTO3ITSMZJ+V+/Wht+ce8dnB/0FHHxKyfI5jj42eflDJ jYoQ== X-Gm-Message-State: ALoCoQlKk8rADtiKjlh2ORJtxJ7zAUtc975+VkFlHK5N35NjYegniVArXL5GYe/PrJh2CXpuNhTg X-Received: by 10.55.49.138 with SMTP id x132mr124554qkx.19.1428023568885; Thu, 02 Apr 2015 18:12:48 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:f827:63cf:7b05:550e? ([2601:a:2a00:84:f827:63cf:7b05:550e]) by mx.google.com with ESMTPSA id 13sm4682123qku.20.2015.04.02.18.12.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 18:12:48 -0700 (PDT) Message-ID: <551DE914.4010804@nthpermutation.com> Date: Thu, 02 Apr 2015 21:12:52 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000800020400020206090700" Archived-At: Subject: Re: [TLS] Ala Carte Cipher suites - 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: Fri, 03 Apr 2015 01:12:58 -0000 This is a multi-part message in MIME format. --------------000800020400020206090700 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 4/2/2015 5:31 PM, Joseph Salowey wrote: > I think I would prefer to break things up between what is needed for > the record protection and what is needed for authentication (of the > peer). The argument has been made on other threads on the list that > these are two separate concerns and I think it would be best to treat > each one as a unit. I think TLS 1.3 will make this separation a bit > more formal especially with the removal of RSA key transport. > > The record layer protection aspect would include things directly > involved in generating and using the encryption keys: > > AEAD Cipher (e.g. AES-GCM) + Key agreement (e.g. DH) + KDF/PRF > (HKDF-SHA256) > > I'm tempted to throw the groups used in the DH agreement (25519, > p-256,etc) because that way you can make sure you are consistent > matching your algorithm strength between key agreement and encryption. > I could also see negotiating the group separately to contain the > combinatorial possibilities of allocations, although we may want to > warn against some combinations It might make sense to tie the KDF > into Key agreement and perhaps these are fixed to the TLS version. > > Authentication would include what the handshake uses use for > authenticating the peers. It seems there are a number of parameters > here: signature algorithm (RSA-PSS-SHA256, PSK MAC, PAKE), > certification parameters (cert types and params), handshake hash > (maybe this is set by the KDF above). The parameterization of > authentication mechanisms may be a bit more complex, but I think we > have much of the machinery there already, it just may need to be > tweaked a bit. > > Joe > > > The parameter negotiation phase needs to negotiate the hash function used for the handshake summary. The key agreement phase needs to negotiate the KDF function, the pre-master secret, the master secret, and the session keys. Right now the KDF function is a fixed construct which uses the hash function from the parameter negotiation as its underlying function - but that could be changed. [Lost track of this, but in TLS1.3 I believe the handshake summary is now a mixin to the derivation of either the master secret or the session keys?] Then you have the record level cipher suite and the authentication mechanisms. So maybe its more like 6-8 boxes you need to split cipher suites up into: { [cipher strengths], [handshake summary families], [kdf modes], [key agreement mechs], [auth mechs], [record mechs]} e.g. { [128], [SHA2 | SHA3], [HKDF | SP800-108], [ECDHE | ECDH | GOSTXX], [CERT-ECDSA | CERT-RSA-ECDSA | CERT-RSA], [AES-CCM |AES-CCM]} Pick a security level in bits, map each of the individual mode choices to a specific security level etc. The above isn't quite right (first attempt) - you might need to add families for the key agreement mechanisms (specifically ECDH) to add curve selection and you might split off the encryption type from the encryption mode ([AES] [CCM | GCM]) Mike > > > > On Thu, Apr 2, 2015 at 9:57 AM, Dave Garrett > wrote: > > On Thursday, April 02, 2015 12:45:35 pm Nico Williams wrote: > > On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos > > wrote: > > > I think full a-la-carte is too complex. But I'm for negotiating the > > > handshake and symmetric crypto separately. They're already very > > > loosely coupled and most proposals that introduce/obsolete > > > ciphersuites are only interested in one of the two sides, with the > > > other being only an afterthought. > > > > That would be a huge improvement over what we have now. > > That could be a good middle ground. Just split cipher suites into > essentially asymmetric & symmetric cipher suites, and put them > both in the same array. Server just picks one of each for > handshake & connection. > > > Dave > > _______________________________________________ > 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 --------------000800020400020206090700 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 4/2/2015 5:31 PM, Joseph Salowey wrote:
I think I would prefer to break things up between what is needed for the record protection and what is needed for authentication (of the peer). The argument has been made on other threads on the list that these are two separate concerns and I think it would be best to treat each one as a unit. I think TLS 1.3 will make this separation a bit more formal especially with the removal of RSA key transport.

The record layer protection aspect would include things directly involved in generating and using the encryption keys:

AEAD Cipher (e.g. AES-GCM) + Key agreement (e.g. DH) + KDF/PRF (HKDF-SHA256)

I'm tempted to throw the groups used in the DH agreement (25519, p-256,etc) because that way you can make sure you are consistent matching your algorithm strength between key agreement and encryption. I could also see negotiating the group separately to contain the combinatorial possibilities of allocations, although we may want to warn against some combinations It might make sense to tie the KDF into Key agreement and perhaps these are fixed to the TLS version.

Authentication would include what the handshake uses use for authenticating the peers. It seems there are a number of parameters here: signature algorithm (RSA-PSS-SHA256, PSK MAC, PAKE), certification parameters (cert types and params), handshake hash (maybe this is set by the KDF above). The parameterization of authentication mechanisms may be a bit more complex, but I think we have much of the machinery there already, it just may need to be tweaked a bit.

Joe




The parameter negotiation phase needs to negotiate the hash function used for the handshake summary.

The key agreement phase needs to negotiate the KDF function, the pre-master secret, the master secret, and the session keys. Right now the KDF function is a fixed construct which uses the hash function from the parameter negotiation as its underlying function - but that could be changed. [Lost track of this, but in TLS1.3 I believe the handshake summary is now a mixin to the derivation of either the master secret or the session keys?]

Then you have the record level cipher suite and the authentication mechanisms.

So maybe its more like 6-8 boxes you need to split cipher suites up into:

{ [cipher strengths], [handshake summary families], [kdf modes], [key agreement mechs], [auth mechs], [record mechs]}

e.g.

{ [128], [SHA2 | SHA3], [HKDF | SP800-108], [ECDHE | ECDH | GOSTXX], [CERT-ECDSA | CERT-RSA-ECDSA | CERT-RSA], [AES-CCM |AES-CCM]}

Pick a security level in bits, map each of the individual mode choices to a specific security level etc.

The above isn't quite right (first attempt) - you might need to add families for the key agreement mechanisms (specifically ECDH) to add curve selection and you might split off the encryption type from the encryption mode ([AES] [CCM | GCM])

Mike






On Thu, Apr 2, 2015 at 9:57 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
On Thursday, April 02, 2015 12:45:35 pm Nico Williams wrote:
> On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos <codesinchaos@gmail.com> wrote:
> > I think full a-la-carte is too complex. But I'm for negotiating the
> > handshake and symmetric crypto separately. They're already very
> > loosely coupled and most proposals that introduce/obsolete
> > ciphersuites are only interested in one of the two sides, with the
> > other being only an afterthought.
>
> That would be a huge improvement over what we have now.

That could be a good middle ground. Just split cipher suites into essentially asymmetric & symmetric cipher suites, and put them both in the same array. Server just picks one of each for handshake & connection.


Dave

_______________________________________________
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

--------------000800020400020206090700-- From nobody Thu Apr 2 19:04: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 08FE71A8FD4 for ; Thu, 2 Apr 2015 19:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.408 X-Spam-Level: X-Spam-Status: No, score=0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 X3ml5fMZVVhx for ; Thu, 2 Apr 2015 19:04:48 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.81.23]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2B51A8F50 for ; Thu, 2 Apr 2015 19:04:47 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 26E47D753B94F; Thu, 2 Apr 2015 21:04:47 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 19A41D753B92E for ; Thu, 2 Apr 2015 21:04:47 -0500 (CDT) Received: from [96.231.227.6] (port=62982 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YdqyU-0001Ph-Gm; Thu, 02 Apr 2015 21:04:46 -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: <551DDD4E.5070509@nthpermutation.com> Date: Thu, 2 Apr 2015 22:04:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> To: Michael StJohns 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: 96.231.227.6 X-Exim-ID: 1YdqyU-0001Ph-Gm X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [96.231.227.6]:62982 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 02:04:49 -0000 On Apr 02, 2015, at 20:22, Michael StJohns = wrote: > I will note that the author claimed in his paper that the IETF was = standardizing this, but I can't find any data suggesting this actually = went through the IETF standardization process (vs independent = informational RFC submission process). It did garner some review on the = CFRG mailing list, but not to what I normally think of as comprehensive = and resolving all comments. The pre-5869 draft was AD sponsored by Tim Polk. The IETF LC can be = found here: = https://mailarchive.ietf.org/arch/msg/ietf-announce/8rYOi-6zUEljAX4XprWbjP= 7on0s We can refer to it normatively if we want to, we just have to make sure = the DOWNREF is explicitly cited, as per RFC 3647. spt= From nobody Thu Apr 2 22:45: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 CAD0D1A90BC for ; Thu, 2 Apr 2015 22:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 e3DZsP2EwsQJ for ; Thu, 2 Apr 2015 22:45:48 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.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 C4FC91A8F4A for ; Thu, 2 Apr 2015 22:45:47 -0700 (PDT) Received: by qcrf4 with SMTP id f4so71185717qcr.0 for ; Thu, 02 Apr 2015 22:45:47 -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=gAclu5cfMHgZR2zY1HHZqYTmOvnrcsxeDrDBcmAxoak=; b=Ze1ao+GRRiXLx3wcemRvWkL3tlVYnMsNZpPOW4GWFViUNDCsH1ZpJtR/7KBw5PA1gt 33mYLEa6oIUcLEt7qmFYREuannb+aPpY5ZFtLpN0Fyb72lvoDEC9Vuks4GnkmC0k9B3O Cs9Ig8ewVrP0ihRtl3I6uDzkOUxkyQvyY3g2p+vJ+YebLKS6zrAd8LfCyPgo1vpp1ORE 1c0zVrHaIL/3pcyrF+sz0gSZ10tDOGd+6/K58J2VacDMVoGKpopHGqwo8et9vA7Wkopx Q2LCEXLKCna9Zk90jiG7wWywbqbkQTQFMrg4YIj5PqVhaAkrltgdqNrNGvNoiXaKv20m DFCA== X-Gm-Message-State: ALoCoQnawqx8KfnyxDf2K11iwu0BzEYVyVW/wa/xxbT1gVzzwL4wHg3SX05WE11GPlM6EfgiBYow X-Received: by 10.140.233.3 with SMTP id e3mr957087qhc.94.1428039946908; Thu, 02 Apr 2015 22:45:46 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:7d17:2073:7e:bad2? ([2601:a:2a00:84:7d17:2073:7e:bad2]) by mx.google.com with ESMTPSA id p18sm5056088qkh.10.2015.04.02.22.45.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 22:45:46 -0700 (PDT) Message-ID: <551E290D.7020207@nthpermutation.com> Date: Fri, 03 Apr 2015 01:45:49 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sean Turner References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050300020706090507080208" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 05:45:50 -0000 This is a multi-part message in MIME format. --------------050300020706090507080208 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 4/2/2015 10:04 PM, Sean Turner wrote: > On Apr 02, 2015, at 20:22, Michael StJohns wrote: > >> I will note that the author claimed in his paper that the IETF was standardizing this, but I can't find any data suggesting this actually went through the IETF standardization process (vs independent informational RFC submission process). It did garner some review on the CFRG mailing list, but not to what I normally think of as comprehensive and resolving all comments. > The pre-5869 draft was AD sponsored by Tim Polk. The IETF LC can be found here: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/8rYOi-6zUEljAX4XprWbjP7on0s I saw that, but that's for Informational, not Standard. Different bar. > > We can refer to it normatively if we want to, we just have to make sure the DOWNREF is explicitly cited, as per RFC 3647. Yup. But considering that the difference between HKDF vs the combination of SP800-56C plus SP800-108 section 5.2 is the placement of the iteration value in what gets HMAC'd and the fact that _the HDKF doesn't mix in the total length of the data to be output_, I'd rather use the latter cites if we could even if they require an extra paragraph to describe the selected sizes of L and i and what goes in to Label and Context (basically "info" by another name). AFAICT, the addition of the L of the output to the data HMAC'd is there to force a change to the key stream if the length of the output key stream changes and that's probably a good additional security property. Other than that, I would say that these are pretty much identical in cryptographic composition. Lastly, I still have hopes one day to remove the requirement for the dependency on a HASH function in the handshake and this construct allows for a CMAC based MAC. Again - I can live with HKDF, but I'm unclear of why citing the RFC is a better choice given the above comparison. Thanks - Mike ps - I will write the paragraph for SP800-56C/108 inclusion if you want if we go that way. > > spt --------------050300020706090507080208 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 4/2/2015 10:04 PM, Sean Turner wrote:
On Apr 02, 2015, at 20:22, Michael StJohns <msj@nthpermutation.com> wrote:


 I will note that the author claimed in his paper that the IETF was standardizing this, but I can't find any data suggesting this actually went through the IETF standardization process (vs independent informational RFC submission process).  It did garner some review on the CFRG mailing list, but not to what I normally think of as comprehensive and resolving all comments.

The pre-5869 draft was AD sponsored by Tim Polk.  The IETF LC can be found here:

https://mailarchive.ietf.org/arch/msg/ietf-announce/8rYOi-6zUEljAX4XprWbjP7on0s
I saw that, but that's for Informational, not Standard. Different bar.


We can refer to it normatively if we want to, we just have to make sure the DOWNREF is explicitly cited, as per RFC 3647.
Yup. But considering that the difference between HKDF vs the combination of SP800-56C plus SP800-108 section 5.2 is the placement of the iteration value in what gets HMAC'd and the fact that the HDKF doesn't mix in the total length of the data to be output, I'd rather use the latter cites if we could even if they require an extra paragraph to describe the selected sizes of L and i and what goes in to Label and Context (basically "info" by another name).

AFAICT, the addition of the L of the output to the data HMAC'd is there to force a change to the key stream if the length of the output key stream changes and that's probably a good additional security property. Other than that, I would say that these are pretty much identical in cryptographic composition.

Lastly, I still have hopes one day to remove the requirement for the dependency on a HASH function in the handshake and this construct allows for a CMAC based MAC.


Again - I can live with HKDF, but I'm unclear of why citing the RFC is a better choice given the above comparison.

Thanks - Mike

ps - I will write the paragraph for SP800-56C/108 inclusion if you want if we go that way. 



spt

--------------050300020706090507080208-- From nobody Thu Apr 2 23:49: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 18ABB1A9122 for ; Thu, 2 Apr 2015 23:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.611 X-Spam-Level: X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 fDoLBvMV8U_g for ; Thu, 2 Apr 2015 23:49:33 -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 50BCA1A9120 for ; Thu, 2 Apr 2015 23:49:33 -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 t336nRoL009038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 3 Apr 2015 02:49:27 -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 t336nPpZ007488 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2015 02:49:27 -0400 Message-ID: <1428043764.3853.14.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Sean Turner Date: Fri, 03 Apr 2015 08:49:24 +0200 In-Reply-To: References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <1082369316.6361228.1427914387267.JavaMail.zimbra@redhat.com> 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.27 Archived-At: Cc: tls Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 06:49:35 -0000 On Wed, 2015-04-01 at 17:21 -0400, Sean Turner wrote: > > ----- Original Message ----- > >> This message is to confirm the consensus reached @ the IETF 92 TLS session in > >> Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an > >> HKDF-based PRF (see > >> http://datatracker.ietf.org/doc/rfc5869/?include_text=1). > >> Please indicate whether or not you agree with the consensus by 2015-04-17. > >> If not, please indicate why. Also, please note that we’re interested in > >> uncovering new issues not rehashing issues already discussed. > > > > I believe the question is totally unwarranteed. No-one has presented any argument > > on why the TLS PRF is not sufficient for its purpose. The only arguments presented > > are theoretical advantages of HKDF, which are fine, but do they add value to TLS? > > Does the advantages of HKDF translate into weaknesses of the TLS PRF? > > Both ekr and I queued the whole discussion up with there’s "nothing really wrong" with the PRF as far as we know. The discussion in Dallas starts about 2:31:15 on audio stream - listen for a muffled ekr saying "oh god": > http://www.ietf.org/audio/ietf92/ietf92-oak-20150326-0900-am1.mp3 > > At about 2:34:47 of the audio stream, Hugo discuses some of the “sub-optimal” aspects of the current PRF. Ok, if I can summarize the argument presented against the current PRF is the fact that it works well when the input (pre_master_secret) is uniform but not otherwise. So in the words of the speaker it works well for the RSA ciphersuites because the premaster secret is simply a random nonce, but not in the other ciphersuites. My words now. The other ciphersuites are Diffie-Hellman and Elliptic curve Diffie-Hellman. In these cases the pre-master-secret is the negotiated key. I've seem several cryptographic proofs assuming that the negotiated key in DH and ECDH is uniform, but indeed that may not be correct, and let's accept the speaker's argument. So we have a problem in the TLS handshake, and we have decided in an afternoon to replace the PRF with what the speaker suggested which is HKDF. That also happens to be the speaker's invention. That's pretty much expected of course. Shouldn't, however, the WG investigate whether there are better alternatives to fix the problem? Shouldn't other cryptographers asked to say their opinion on the fix and the issue? That's what the WG did with Salsa20 proposal, asked the CFRG. Maybe there are even more issues in the current PRF we don't know. In any case, HKDF is not bad choice, it is a good choice and already used in IKEv2. However, I am not an expert in PRFs, but I still see many design similarities in HKDF and the TLS PRF. So I wonder whether there are better from these two choices which we will never know if we only listen to one opinion. > > So no matter the output of that poll the result will be an uneducated guess. In all cases > > it is alarming to see the easiness with which the protocol is being rewritten completely. > > Now its only similarity with TLS 1.2 is the TLS acronym. Would that rewrite bring value > > in par with the efford needed for the rewrite? Would it make us safer in 2030 or are we > > simply apply yesterday's technology today? > I guess I don’t follow - the PRF changed in previous versions and we kept the “TLS” moniker. That's not the comment I make. My main concern is "Would that rewrite bring value in par with the efford needed for the rewrite?". In that particular case with HKDF; is HKDF the best choice we can do now to keep us with a good PRF until 2030? regards, Nikos From nobody Fri Apr 3 01:52: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 82D0C1A1AB8 for ; Fri, 3 Apr 2015 01:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, 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 j9H5qOndp_dw for ; Fri, 3 Apr 2015 01:52:13 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB6E1A1AC1 for ; Fri, 3 Apr 2015 01:52: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=uoa; t=1428051133; x=1459587133; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iPKT04dqOfFAauaAtgN2QFuQIbFtrMtGCf+fxtj7yMs=; b=UMhnG0Aw8yhHsyKbA1/fX3i21f5pBzXfXZ0fMxpPEz8/CDI3K+y2trCW +W/l+Xv+Mkg2LnrbM3DkTWkQKvfkhA1X4VxTPb60z0gB58AtgMb8oOGRi y53yLaRdIWVlUpidVMuT0wSdH3Qsj9cIzp0Jf1NXEh5wDWNGLPQB2rMT+ s=; X-IronPort-AV: E=Sophos;i="5.11,516,1422874800"; d="scan'208";a="318818677" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 03 Apr 2015 21:52:12 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.245]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Fri, 3 Apr 2015 21:52:10 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Hanno_B=F6ck?= , "tls@ietf.org" Thread-Topic: [TLS] Consensus Call on MTI Algorithms Thread-Index: AQHQbKeDwNeK1AEgwEC7Z+eGtfd7J505HmiAgAHfApk= Date: Fri, 3 Apr 2015 08:52:10 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFD49DC@uxcn10-tdc05.UoA.auckland.ac.nz> References: , <20150402191657.43cd35ee@pc1.fritz.box> In-Reply-To: <20150402191657.43cd35ee@pc1.fritz.box> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 08:52:15 -0000 Hanno =3D?UTF-8?B?QsO2Y2s=3D?=3D writes:=0A= =0A= >Other options: AES-CBC with EtM (Peter Gutmann just claimed here he thinks= =0A= >its less brittle than GCM) or other block modes (OCB?).=0A= =0A= I've always liked OCB, and the removal of encumbrance for TLS implementatio= ns=0A= finally makes it available for use there. GCM is just too brittle, a minor= =0A= implementation flaw (as has already occurred in things like tarsnap and JCE= )=0A= leads to a complete loss of security, while the same flaw using CBC (and=0A= presumably OCB) leads to mostly theoretical weaknesses. GCM (or at least i= ts=0A= underlying primitive, CTR) is RC4 all over again, and we're already seeing= =0A= some of the same mistakes that killed RC4 use appearing in GCM deployments.= =0A= =0A= Peter.=0A= From nobody Fri Apr 3 02:14: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 1D9DA1A1B4B for ; Fri, 3 Apr 2015 02:14:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 3QN0ZfUilxJO for ; Fri, 3 Apr 2015 02:14:26 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7311A1B45 for ; Fri, 3 Apr 2015 02:14:25 -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=1428052467; x=1459588467; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LbOzclBRI4dLmDGVpzVx3S0NYTTnVEdHdaYf+YZIgYU=; b=KdfXd/TgHOx7u3yxC7THzoUW8V1RjzqYv4/m6vrq2JOENk+jS58FOnoi 5+2HFDjqVHn+aH3zud0asr4T+vo0OZc8aEbKvshBs2rvTK45cYTPMJdNi T5QEV4bwadNb2w4W4z99tLMfmqtJAWyodfWjcNk3yZOMsNEdFaZeloROI E=; X-IronPort-AV: E=Sophos;i="5.11,516,1422874800"; d="scan'208";a="318819795" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 03 Apr 2015 22:14:24 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.245]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Fri, 3 Apr 2015 22:14:22 +1300 From: Peter Gutmann To: Nico Williams , Dave Garrett Thread-Topic: [TLS] Consensus Call on MTI Algorithms Thread-Index: AQHQbKeDwNeK1AEgwEC7Z+eGtfd7J5032jcAgAAvggCAAAfCAIAAsbcAgAAQGYCAATtLPv//MgCAgAAG/QCAAAfngIAABgwAgAGuO8k= Date: Fri, 3 Apr 2015 09:14:21 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFD49FE@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20150402194417.GJ10960@localhost> <201504021612.35877.davemgarrett@gmail.com>, <20150402203412.GK10960@localhost> In-Reply-To: <20150402203412.GK10960@localhost> 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] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 09:14:28 -0000 Nico Williams writes:=0A= =0A= >Sure, that'd be nice (because different manufacturers of IoT devices will= =0A= >want to know what to implement as a common denominator).=0A= =0A= The IoT environment doesn't work the way some people seem to think it does.= =0A= IoT devices can be divided into two classes, those that can't run TLS and= =0A= those that can. The class "those that can't run TLS" is a lot larger than = you=0A= think, because a typical target might for example have 15% of an ARM7 TDMI = and=0A= 18K RAM available, and restrictions like the fact that no operation can tie= up=0A= the CPU for more than 2ms before it's killed by the system watchdog.=0A= =0A= So for "TLS" on these devices you've got a large class of systems that have= to=0A= run some homebrew protocol invented by an embedded systems guy who's read t= he=0A= first three chapters of Applied Cryptography (this became particularly=0A= problematic when smart meters started to become widespread and regulators= =0A= imposed requirements for certificate-based signed messaging and updates ont= o=0A= CPUs like TI MSP430s, Motorola ColdFires, and ARM Cortex-Ms, some clocked a= s=0A= high as 16MHz and with as much as 32kB of RAM (for everything, not just the= =0A= crypto). The solution with smart meters was to cut corners as much as=0A= possible in order to make things fit, skipping certificate verification,=0A= assuming hardcoded public keys, and various other measures that are destine= d=0A= to become entertaining Black Hat or Defcon presentations in the future).=0A= =0A= For the other class, those that can run TLS, the reason for running it isn'= t=0A= to talk to another device running TLS (you use your homebrew protocol for= =0A= that), it's so they can be controlled via a web interface. For these devic= es=0A= the profile is "whatever we need to implement to talk to a web browser/smar= t=0A= phone/web control/AJAX/whatever". That is the entire device profile. Sinc= e=0A= the underlying hardware can't handle this, you get approaches like the ones= =0A= I've talked about in the past, 1024-bit keys for everything (perfectly OK f= or=0A= embedded device security, I've been waiting for the negotiated-ff-dhe draft= to=0A= be approved so I can push out one that extends it to specify 1024- and 1280= -=0A= bit parameter sets), pre-encoded cert chains memcpy()'d out into TLS stream= s=0A= (the device has zero PKI functionality because there isn't room), and so on= ,=0A= just whatever you can get away with and have the other side still talk to y= ou=0A= (I've seen some truly ingenious solutions applied to systems that have to t= alk=0A= to web browsers but just can't handle the high resource requirements for TL= S).=0A= =0A= If you want to do an IoT TLS profile (what would have been called an embedd= ed=0A= device TLS profile before IoT became a buzzword) you need to look at how TL= S=0A= is used in the embedded world, and for what purposes. Simply dreaming up= =0A= something and calling it an IoT profile won't work, because vendors are=0A= already working with de facto profiles of "whatever we need to do to get=0A= things working".=0A= =0A= Peter.= From nobody Fri Apr 3 03:07: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 40A431A702D for ; Fri, 3 Apr 2015 03:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 v5OuCfFIvP7i for ; Fri, 3 Apr 2015 03:07:01 -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 891091A6F38 for ; Fri, 3 Apr 2015 03:06:59 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id CB2791A25E4; Fri, 3 Apr 2015 13:06:56 +0300 (EEST) Date: Fri, 3 Apr 2015 13:06:56 +0300 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20150403100656.GA25092@LK-Perkele-VII> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <1082369316.6361228.1427914387267.JavaMail.zimbra@redhat.com> <1428043764.3853.14.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1428043764.3853.14.camel@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s__consensus=3A_adopt?= =?utf-8?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 10:07:04 -0000 On Fri, Apr 03, 2015 at 08:49:24AM +0200, Nikos Mavrogiannopoulos wrote: > On Wed, 2015-04-01 at 17:21 -0400, Sean Turner wrote: > > > ----- Original Message ----- > > >> This message is to confirm the consensus reached @ the IETF 92 TLS session in > > >> Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an > > >> HKDF-based PRF (see > > >> http://datatracker.ietf.org/doc/rfc5869/?include_text=1). > > >> Please indicate whether or not you agree with the consensus by 2015-04-17. > > >> If not, please indicate why. Also, please note that we’re interested in > > >> uncovering new issues not rehashing issues already discussed. > > > > > > I believe the question is totally unwarranteed. No-one has presented any argument > > > on why the TLS PRF is not sufficient for its purpose. The only arguments presented > > > are theoretical advantages of HKDF, which are fine, but do they add value to TLS? > > > Does the advantages of HKDF translate into weaknesses of the TLS PRF? > > > > Both ekr and I queued the whole discussion up with there’s "nothing really wrong" with the PRF as far as we know. The discussion in Dallas starts about 2:31:15 on audio stream - listen for a muffled ekr saying "oh god": > > http://www.ietf.org/audio/ietf92/ietf92-oak-20150326-0900-am1.mp3 > > > > At about 2:34:47 of the audio stream, Hugo discuses some of the “sub-optimal” aspects of the current PRF. > > Ok, if I can summarize the argument presented against the current PRF is > the fact that it works well when the input (pre_master_secret) is > uniform but not otherwise. So in the words of the speaker it works well > for the RSA ciphersuites because the premaster secret is simply a random > nonce, but not in the other ciphersuites. Can be proven to work well. Big difference. Furthermore, I think any attack here is at least one of: - Banana attack. - Requires seriously breaking the prf-hash. - Requires seriously breaking other things than just PRF. And "seriously breaking" means deprecate/replace this ASAP. > My words now. The other > ciphersuites are Diffie-Hellman and Elliptic curve Diffie-Hellman. In > these cases the pre-master-secret is the negotiated key. I've seem > several cryptographic proofs assuming that the negotiated key in DH and > ECDH is uniform, but indeed that may not be correct, and let's accept > the speaker's argument. Furthermore, if prf-hash is even close to being collision-resistant (which it has to be or some other stuff breaks), I really don't see how feeding DH or ECDH outputs could cause problems. Basically, if inputs are adversarial or overly long, you have worse problems than what those inputs do to the PRF. > So we have a problem in the TLS handshake, and we have decided in an > afternoon to replace the PRF with what the speaker suggested which is > HKDF. That also happens to be the speaker's invention. That's pretty > much expected of course. Shouldn't, however, the WG investigate whether > there are better alternatives to fix the problem? Shouldn't other > cryptographers asked to say their opinion on the fix and the issue? > That's what the WG did with Salsa20 proposal, asked the CFRG. Maybe > there are even more issues in the current PRF we don't know. In any > case, HKDF is not bad choice, it is a good choice and already used in > IKEv2. However, I am not an expert in PRFs, but I still see many design > similarities in HKDF and the TLS PRF. So I wonder whether there are > better from these two choices which we will never know if we only listen > to one opinion. I know two problems with TLS PRF: - Label/Seed separation. -> The way HKDF is used in the WIP has the exact same mistake. -> Could be fixed by maiking label to be ASCIIZ/UTF8Z. -> Close enough for many(?) existing implementations. - Problems with key >1 input block. -> HKDF trips the problem with key >1 output block (which is more often) -> Big enough keys are mainly seen with (ff)DHE (or P-521 with SHA-256). > > > So no matter the output of that poll the result will be an uneducated guess. In all cases > > > it is alarming to see the easiness with which the protocol is being rewritten completely. > > > Now its only similarity with TLS 1.2 is the TLS acronym. Would that rewrite bring value > > > in par with the efford needed for the rewrite? Would it make us safer in 2030 or are we > > > simply apply yesterday's technology today? > > I guess I don’t follow - the PRF changed in previous versions and we kept the “TLS” moniker. > > That's not the comment I make. My main concern is "Would that rewrite > bring value in par with the efford needed for the rewrite?". In that > particular case with HKDF; is HKDF the best choice we can do now to keep > us with a good PRF until 2030? I think one could make PRF that is better than both TLS-PRF and HKDF, but I don't know anything that really is. -Ilari From nobody Fri Apr 3 03:52: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 F04341A879F for ; Fri, 3 Apr 2015 03:52:00 -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 EMarlUgFrrKp for ; Fri, 3 Apr 2015 03:51:59 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 4FFD21A879B for ; Fri, 3 Apr 2015 03:51:59 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so136236078wib.1 for ; Fri, 03 Apr 2015 03:51:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=EFbsRsfNtvFcVg/Be6LLjv5SrBSEJdhdWMZPEYQQZkU=; b=YW5RT+fI1bEnJghz0tZyP7EGjduFycT9LBX+Wspx7g/wiQamT7HlFG3qZsv5nmCjHm 00Ft0SI9Wr/p0+1xOk/BTwlEjq71jd4EdK3GZpkZAs4JPFwWpNTx5DuIVkpiCQ9v9LNZ wSQ4+13SOnGVvRlLMqa/RbJVn6TL7PRGvAR3zDSUe4YxReoqo7+YpcC8uLAoRF2PN6Du 1uM5PDorYiygUgcEs3/lWGKWOEg1ROQJqCjohDXXAyyksOzUQMQcZaverHANDHfMS4Rv H+wCQYoYRN50xbFwyRyxCuxhb7ZPDyR1zDXEf4BsnPkXwQb2nMvpzr21oY214VKdBKt7 umRw== X-Gm-Message-State: ALoCoQkkfDAo57jTc4XIJgCyOjy4HLF3EzaJfcsgLz/4Co1vNxh8aqgM73+FPSO1k/W7/2CZL1Z2 X-Received: by 10.194.120.230 with SMTP id lf6mr3707550wjb.78.1428058317869; Fri, 03 Apr 2015 03:51:57 -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 gy9sm2229404wib.12.2015.04.03.03.51.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 03:51:56 -0700 (PDT) Message-ID: <551E70C9.6060705@azet.org> Date: Fri, 03 Apr 2015 12:51:53 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Peter Gutmann References: , <20150402191657.43cd35ee@pc1.fritz.box> <9A043F3CF02CD34C8E74AC1594475C73AAFD49DC@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFD49DC@uxcn10-tdc05.UoA.auckland.ac.nz> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCC37BDDD379C9113A6AF17AC" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 10:52:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC37BDDD379C9113A6AF17AC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Peter Gutmann wrote: > I've always liked OCB, and the removal of encumbrance for TLS implement= ations > finally makes it available for use there. GCM is just too brittle, a m= inor > implementation flaw (as has already occurred in things like tarsnap and= JCE) > leads to a complete loss of security, while the same flaw using CBC (an= d > presumably OCB) leads to mostly theoretical weaknesses. GCM (or at lea= st its > underlying primitive, CTR) is RC4 all over again, and we're already see= ing > some of the same mistakes that killed RC4 use appearing in GCM deployme= nts. I think CBC-ETM or OCB would be quite a good fit when native instructions for AES aren't supported on a given platform. Of course ChaCha20/Poly1305 gives us a very nice AEAD construction for these as well. But then we're down to one algorithm for all common platforms that don't have AESNI. I'd like to see a second MTI cipher for these devices which, these days, are everywhere (not talking about IoT but rather smartphones, tons of smartphones and some netbook-like computers). And I'm not just saying this because I have a draft for AES-OCB, if we end up with e.g. CBC-ETM or another cipher entirely that's fine as well. IPRs on OCB: https://datatracker.ietf.org/ipr/search/?draft=3D&rfc=3D7253&submit=3Drfc= &holder=3D&patent=3D&group=3D&doctitle=3D&iprtitle=3D IBM folks are telling me they're working on something similar as rogaway's statement regarding TLS. Let's see with what they come up with.= Aaron --------------enigCC37BDDD379C9113A6AF17AC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVHnDKAAoJEOTbZJL9ubXVAygP/A2XSR7gZuiusJtPaU3CRO45 Eh4dkBJO6cLgw+rVve1V1OQJOuHyPV0ppfoOVYXQhXVPF/yQy0cg7rU465KdIV+F qiYRllk3qu7ImUd/f7CImKuT3RMkNFHzzFa2+S44iEuct7VM1YarIQi61AsWWlVU tq2P3IRacAyCstF22y7YczKRW+4/9tYJk8wltb7RuUr7YnOXPiwXkntnxKEawC0z x0wSVhTFH4jnVQ28n8g9EgYfB8biGfcm1H3D4kRzxgsQKGY2HHCiHLeT/D8gEvj7 K5/14Xd7JiGhFqEE3zyKK3LpJ/qN01RbdmGqefz5A9kyJDul9M7iuvuPRM/8sX6c 8D/3HA26XwW+U3Kusx/WvCBKWGDwhNZ2qwDEmSkCv1nFuBIvnV73/8TnSP7TvS+4 b2bKS0UbH09fYXOA3D1nmSN+okurluFVdfvj/MpRrIj3xPRUqw8OWuFaxb882lig 15IVkOoE7Y73iwK4UyCLAJYLVf+IBaKwjceU+JEnZP0BbiFePX41rUToh7dvMmrJ dhDIn93s8Kg0qhw6xlwB89XXhSfMW1sDtkbObniEpFPfow/OQjTJ7oksruo70BbE rXHVhN2VABoIDtIJCqYYT6117ein4cho8bi9uZg+XrOENhnsP5tt/K7WxSUJ8HW2 YFex+tcJfUUGAQYBJonY =lbnR -----END PGP SIGNATURE----- --------------enigCC37BDDD379C9113A6AF17AC-- From nobody Fri Apr 3 06:55: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 920941A92FA for ; Fri, 3 Apr 2015 06:55: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 irKeFxIcfSiK for ; Fri, 3 Apr 2015 06:55:33 -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 7B9371A8A94 for ; Fri, 3 Apr 2015 06:55:33 -0700 (PDT) Received: by wgin8 with SMTP id n8so22265644wgi.0 for ; Fri, 03 Apr 2015 06:55: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=sVAzN9YGrgPJtxGyN300TIsiNmMWJrgcVCDpq9wnCHU=; b=xN9XX9XjFT97+ils01hbIO+8E2vhJaKlCOcB7A44qQHhxJdM+7sUhsFKjyp3sYmIXH 9rzOoJA0bq1KOl4PkY8e499Mj2w2mplY6oGOGC5zoVAI9ZsS3QRoDZGyyiA2Recq/65s cl389Fsq+9EnqCdG2WeXvpANL3JkeaDlS9B2FvZTUTLGYQlUjG8JtvauzHhRwXzbunnT /uLfGA6TrEZYdLrMUOSe0hZnX+k1Z8Nge7yQ6QKBwd+yJBtcGCexwu9oB/TQfNijw9hp dgg4HHObyxHs3Pkkt5ej/5EjekICHP8fbq1feJEiMfgFqZ6TARihMYuGexeXyzBUUNQ7 OsZw== MIME-Version: 1.0 X-Received: by 10.180.206.13 with SMTP id lk13mr5681486wic.35.1428069332236; Fri, 03 Apr 2015 06:55:32 -0700 (PDT) Received: by 10.194.136.233 with HTTP; Fri, 3 Apr 2015 06:55:32 -0700 (PDT) In-Reply-To: <20150402184849.GF10960@localhost> References: <20150402184849.GF10960@localhost> Date: Fri, 3 Apr 2015 06:55:32 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 13:55:35 -0000 On Apr 2, 2015 11:49 AM, "Nico Williams" wrote: > > On Wed, Apr 01, 2015 at 11:12:19AM -0700, Joseph Salowey wrote: > > [...] > > I'd like to have at least two required algorithms for each class, at > least for the 128-bit security level. The rationale is: to make it easy > to switch one off if it becomes a problem. > > We've already had to disable broken algorithms in a hurry in several > Internet protocols including TLS. We should learn the lesson: we should > aim to have at least one left. Is that really what happened with RC4 and the MAC construction? Or was it nearly a decade of ignoring widely reported weaknesses? > > In all cases recall that required-to-implement != required-to-enable. All sites with RC4 enabled and preferred implement and offer AES128-SHA in the handshake. The absence of alternatives in implementations isn't what is keeping RC4 alive. > > > o Symmetric: > > MUST AES-GCM 128 > > SHOULD ChaCha20-Poly1305 > > I would like at least two modes for AES to be required: one AEAD > (probably GCM) and one AEAD-by-generic-construction (e.g., using HMAC). OCB is a better fit constrained devices. CCM requires two passes. > > I would like one non-AES cipher to be required. ChaCha20-Poly1305 works > for me. What does this requirement translate to in practice? It doesn't necessarily mean that we can switch, as there is no requirement to use the other ciphers, or even offer them. We seem to have quietly admitted to opening up a zoo of ciphers, where every profile picks a different one. How do these proposals actually improve security? What we need to do is ensure that bad ciphers aren't used. The exercise of ensuring that we have alternatives only matters if we have an answer to the question of how migration works. Sincerely, Watson Ladd > > Total: three required algorithms. Here I want three because I'm not > sure that GCM is easy enough to implement and use safely in all > environments (see Watson L.'s comments on this), and because I'd like > two ciphers just in case. > > > o Hash: > > MUST SHA-256 > > I would like two hash functions to be required. I don't have a strong > preference as to the second hash function, but I like SHA-3. > > > o Key Agreement: ECDH > > MUST P-256 > > SHOULD 25519 > > By the rationale above I would like both of these to be required. > > > o Signature: > > MUST ECDSA P-256 > > MUST RSA > > Ditto. We won't have the luxury of waiting until CFRG blesses an ECC > signature scheme other than ECDSA, but when they do... we should add > that to the list. > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Apr 3 07: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 5FA661A8BC4 for ; Fri, 3 Apr 2015 07:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, 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 WHcpLUCs3YQ3 for ; Fri, 3 Apr 2015 07:22:58 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.52.26]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F4B1A8AD9 for ; Fri, 3 Apr 2015 07:22:58 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 0D45DA9BE5D85; Fri, 3 Apr 2015 09:22:58 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway03.websitewelcome.com (Postfix) with ESMTP id F3FA2A9BE5D1F for ; Fri, 3 Apr 2015 09:22:57 -0500 (CDT) Received: from [96.231.227.6] (port=63710 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Ye2Uq-0005MV-TR; Fri, 03 Apr 2015 09:22:57 -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: <551B3415.5080105@cs.tcd.ie> Date: Fri, 3 Apr 2015 10:22:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2D4BF0F9-E771-4E79-848F-11617E77A36C@ieca.com> References: <551B3415.5080105@cs.tcd.ie> To: Stephen Farrell 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: 96.231.227.6 X-Exim-ID: 1Ye2Uq-0005MV-TR X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [96.231.227.6]:63710 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 14:23:00 -0000 On Mar 31, 2015, at 19:56, Stephen Farrell = wrote: > #2 I've never quite gotten the reasoning behind not giving > any names to any of the RFC3526 curves and I think that > question deserves an answer (to be in the list archive). > So - why not? Maybe I=92m not following but are you asking that we retroactively name = the "4096-bit MODP Group=94? spt= From nobody Fri Apr 3 07: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 D16621ABC75 for ; Fri, 3 Apr 2015 07:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IijPOhgk3AQC for ; Fri, 3 Apr 2015 07:56:34 -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 EB3E11ABB1A for ; Fri, 3 Apr 2015 07:56:33 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 221921658C8; Fri, 3 Apr 2015 14:56:33 +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 178311658C3; Fri, 3 Apr 2015 14:56:33 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 13DA29803E; Fri, 3 Apr 2015 14:56:33 +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.913.22; Fri, 3 Apr 2015 09:56:19 -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.0913.011; Fri, 3 Apr 2015 09:56:19 -0500 From: "Salz, Rich" To: Bill Frantz , "tls@ietf.org" Thread-Topic: [TLS] Killing Algorithms Thread-Index: AQHQbaZyMkbCY293OkCg3bAFv0mFgJ07YNXw Date: Fri, 3 Apr 2015 14:56:18 +0000 Message-ID: <722ae4fed0e64a1fbfb11ac916337a9f@ustx2ex-dag1mb2.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-originating-ip: [172.19.32.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Killing Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 14:56:36 -0000 > Each implementation of TLS MUST have a technique for effectively turning > algorithms off. This is a no-op; the implementation's method can be "rebuild and re-install= all dependant software" or "keep your licenses current and download the la= test updates from your vendor" I understand the sentiment, but I don't want to put "noise" requirements in= to the RFC. From nobody Fri Apr 3 08:10: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 5A5A41A90E9 for ; Fri, 3 Apr 2015 08:10: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 lTk8oNJzFLzG for ; Fri, 3 Apr 2015 08:10:43 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::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 AFE891A9090 for ; Fri, 3 Apr 2015 08:10:43 -0700 (PDT) Received: by qcgx3 with SMTP id x3so90924882qcg.3 for ; Fri, 03 Apr 2015 08:10:43 -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=x+xnArCxcQWgqUMAFPN48kAZ4JFMIHuvw6BSMUZTK38=; b=xmdVJ2234kYkkUFq8xoHDn2V/y+G2yRLYl6Q70tZRJIuE8rIubKuIwN0L7+lkD1b00 85xj4rKD9RTTey3HY9wsy5zRBKF18Rneif5ZcrL2noAxIwQyVPGMFVfHQaoesdoSa3Q9 DRwcSsZlBD76VxLRpzeC5lCnC3bq5nQlnqF2WiZSlAjeLX3P4y+vf1gAHq+XIKcS7I7m Znr+GRzxRvql5lL2sAapHT6TKD/0CFmyUbcvuFD0/rL14guMswDoikDQvxm33cbqcWDd X5nnmO0VRg6x+6Ish9yQ0Jagh7SmmgG1Ss+MCbBgvMmAM7N+qJMPn3WG0RQWgE95iRP1 MigA== X-Received: by 10.55.55.7 with SMTP id e7mr5128141qka.52.1428073842981; Fri, 03 Apr 2015 08:10: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 b73sm2042912qge.5.2015.04.03.08.10.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Apr 2015 08:10:42 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 3 Apr 2015 11:10:40 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150402184849.GF10960@localhost> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201504031110.41062.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 15:10:45 -0000 On Friday, April 03, 2015 09:55:32 am Watson Ladd wrote: > On Apr 2, 2015 11:49 AM, "Nico Williams" wrote: > > On Wed, Apr 01, 2015 at 11:12:19AM -0700, Joseph Salowey wrote: > > > o Symmetric: > > > MUST AES-GCM 128 > > > SHOULD ChaCha20-Poly1305 > > > > I would like at least two modes for AES to be required: one AEAD > > (probably GCM) and one AEAD-by-generic-construction (e.g., using HMAC). > > OCB is a better fit constrained devices. CCM requires two passes. So, at this point in the discussion, this is sounding like what might get closer to agreement: o Symmetric: MUST AES-OCB 128 (or 256?) MUST ChaCha20-Poly1305 OPTIONAL AES-GCM 128, but MUST if supporting TLS 1.2 This is essentially 2 MTI for TLS 1.3, with a required amendment to the TLS 1.2 spec to add an AEAD MTI. Without this, when falling back a version there'd be a higher likelihood of having to downgrade to CBC. (current draft has a SHOULD for using AEAD with TLS 1.2, if available) The question is, however: is the WG willing to specify two new MTI? Not having one that's currently in widespread use might slow adoption. Then again, ChaChaPoly is getting out there from Google's pushing of it. Or, all 3 could just be MUSTs. Dave From nobody Fri Apr 3 08:15: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 1C5321A914B for ; Fri, 3 Apr 2015 08:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3uNFWAr4T1y for ; Fri, 3 Apr 2015 08:15:22 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9C41A90E9 for ; Fri, 3 Apr 2015 08:15:22 -0700 (PDT) Received: by wiaa2 with SMTP id a2so142687572wia.0 for ; Fri, 03 Apr 2015 08:15:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=B6yGsqZOVX86XlppxgtW9n22XBKyB6FWt7B4PWnO/t0=; b=WZSp7iON2PzK0oCKJmqTVX7npf2x8qUn8GqbEn+YtOoiHwF+eDgHFV/Za+Ep6f4e0F thDKaPVN4hzcTs3CHOE+5xONzWumFP2NR2eQcpsNEVgeo6+Uxd6StfmyJAgfPZ5WlncS KBGKWP8TwYQJETOKN9dSAXQVOMxKjeygg7I/o2sI3rZr7SiWDIeFuq/KGZ8aBfPoFrmF sYAHj0Yvsa9cWa6KjHlytpDQOg7lzNnd+9u1kaLP85bnrG0Wn0jdfVXiV51+9/+VmfdJ YKh5N7VyhJR5VFcc8jOQj1CeaaRBv25gDfOMMu7mGvSbXQwNX9p979JgwCimjuSX/ulS XjuA== X-Gm-Message-State: ALoCoQllTS6N0tw5tOMc0kbJar3JAyUrmYjUfk0WQOpG/PoPHWtDSgpovmd8AT8ST78fmCJJ2AZl X-Received: by 10.194.178.164 with SMTP id cz4mr5668735wjc.140.1428074120878; Fri, 03 Apr 2015 08:15:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Fri, 3 Apr 2015 08:14:40 -0700 (PDT) In-Reply-To: <201504031110.41062.davemgarrett@gmail.com> References: <20150402184849.GF10960@localhost> <201504031110.41062.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 3 Apr 2015 08:14:40 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=089e013d1672b0505b0512d36a09 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 15:15:24 -0000 --089e013d1672b0505b0512d36a09 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 8:10 AM, Dave Garrett wrote: > On Friday, April 03, 2015 09:55:32 am Watson Ladd wrote: > > On Apr 2, 2015 11:49 AM, "Nico Williams" wrote: > > > On Wed, Apr 01, 2015 at 11:12:19AM -0700, Joseph Salowey wrote: > > > > o Symmetric: > > > > MUST AES-GCM 128 > > > > SHOULD ChaCha20-Poly1305 > > > > > > I would like at least two modes for AES to be required: one AEAD > > > (probably GCM) and one AEAD-by-generic-construction (e.g., using HMAC). > > > > OCB is a better fit constrained devices. CCM requires two passes. > > So, at this point in the discussion, this is sounding like what might get > closer to agreement: > > o Symmetric: > MUST AES-OCB 128 (or 256?) > MUST ChaCha20-Poly1305 > OPTIONAL AES-GCM 128, but MUST if supporting TLS 1.2 > I would not be in favor of this. I prefer the proposal that the chairs originally made based on the interim. -Ekr This is essentially 2 MTI for TLS 1.3, with a required amendment to the TLS > 1.2 spec to add an AEAD MTI. Without this, when falling back a version > there'd be a higher likelihood of having to downgrade to CBC. (current > draft has a SHOULD for using AEAD with TLS 1.2, if available) > > The question is, however: is the WG willing to specify two new MTI? Not > having one that's currently in widespread use might slow adoption. Then > again, ChaChaPoly is getting out there from Google's pushing of it. Or, all > 3 could just be MUSTs. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e013d1672b0505b0512d36a09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Apr 3, 2015 at 8:10 AM, Dave Garrett <davemgarrett@gmail.com= > wrote:
O= n Friday, April 03, 2015 09:55:32 am Watson Ladd wrote:
> On Apr 2, 2015 11:49 AM, "Nico Williams" <nico@cryptonector.com> wrote:
> > On Wed, Apr 01, 2015 at 11:12:19AM -0700, Joseph Salowey wrote: > > > o Symmetric:
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST AES-GCM 128
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD ChaCha20-Poly1305 > >
> > I would like at least two modes for AES to be required: one AEAD<= br> > > (probably GCM) and one AEAD-by-generic-construction (e.g., using = HMAC).
>
> OCB is a better fit constrained devices. CCM requires two passes.

So, at this point in the discussion, this is sounding like what migh= t get closer to agreement:

o Symmetric:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST AES-OCB 128 (or 256?)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST ChaCha20-Poly1305
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTIONAL AES-GCM 128, but MUST if supporting TL= S 1.2

I would not be in favor of this. = I prefer the proposal that the chairs originally made
based on th= e interim.

-Ekr

This is essentially 2 MTI for TLS 1.3, with a required amendment to the TLS= 1.2 spec to add an AEAD MTI. Without this, when falling back a version the= re'd be a higher likelihood of having to downgrade to CBC. (current dra= ft has a SHOULD for using AEAD with TLS 1.2, if available)

The question is, however: is the WG willing to specify two new MTI? Not hav= ing one that's currently in widespread use might slow adoption. Then ag= ain, ChaChaPoly is getting out there from Google's pushing of it. Or, a= ll 3 could just be MUSTs.


Dave

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

--089e013d1672b0505b0512d36a09-- From nobody Fri Apr 3 08: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 8712D1A914B for ; Fri, 3 Apr 2015 08:21:50 -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 xFZ__OP2L04g for ; Fri, 3 Apr 2015 08:21:49 -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 268401A9118 for ; Fri, 3 Apr 2015 08:21:49 -0700 (PDT) Received: by widdi4 with SMTP id di4so110569977wid.0 for ; Fri, 03 Apr 2015 08:21:47 -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=YRm00GbZ9D02B1IDbk6pW6qYQY3zhCdr/a9/cts4glc=; b=OCzpgQVC+u2M8x/eCbutmXn0dlvd9VujbxGV51kg+fCGTTqo1/5Ga0J4XtD0f1fcT8 g5nf7kAXv7ilYgElcitZtyVX2HpG9pBgHZZww+8ydaL6IenyAtGQQUVXoFIKH0CkYkb/ yrV7JamAea/HCQUMMClaS4nIH9tdE2Tk1T48dHb0YktEfqEkmvetCR9C07BDrQuS05mb DJ6Yd6JSdhuGpvZilmoDkM25JTjnP+gDFWXZ7zCJqILpK/+DW3sUj9BPNdrJP3QllEtA /MWMtL0jtSvWBa3q4a4B3euoiT6HynTiWl7zICt3cMEqvfWF5xTZ4TTB4iR14s2wsWgU Us/g== X-Gm-Message-State: ALoCoQk3ta13DyLlEx93m/ElOmBL2PK1KjjOeecajrtNJghFSQ406M6vfg48tRXpzcQdLKcrZHpN X-Received: by 10.194.5.103 with SMTP id r7mr5676970wjr.47.1428074507884; Fri, 03 Apr 2015 08:21:47 -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 u16sm11929932wjr.5.2015.04.03.08.21.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 08:21:46 -0700 (PDT) Message-ID: <551EB007.2010304@azet.org> Date: Fri, 03 Apr 2015 17:21:43 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Bill Frantz References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCA30B43381B0AF4AA7B908CD" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Killing Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 15:21:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCA30B43381B0AF4AA7B908CD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Bill Frantz wrote: > From my point of view, acceptable techniques include online code update= > and special messages which cause implementations to permanently cease > using an algorithm, along with methods and procedures to ensure that > these techniques actually work in the field. As much as I like the idea, until someone proposes a sane method to do so /online/ in the protocol, I don't think it makes a lot of sense to add that to the document, it'll only confuse readers. I can't think of a way a client or server could negotiate that a cipher is deprecated. That'll cause downgrade attacks all over again, possibly to the cipher that would by then be deprecated. Aaron --------------enigCA30B43381B0AF4AA7B908CD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVHrAIAAoJEOTbZJL9ubXVV5cP/R6iiR9t0AiLuCOS/3hF7+Fs fFS6bAw0D5sTWDpXcVbh/2CKDH1pm2/RhFJt9GKPlgnk5K3uADfN5nzI3GXSQpG7 qRSXUIIM2OnxMZPv6usmp9nVemeF00xfS3ttqPw+0KcIvU9/500xEI9u18heUN0A egzf9jOhQqYS3NAk88e//qYY+q6uNjpVWPWhVphb3kOuNA4x50CTgNTGPhw1l2hy Alb8FjhnGWKIiqseCmzTNE5+MMijrNy7j3PFZmA0mAxHH5cgTeTopXQtZE9PZTTp +lgv3Sjr0/qkRx1pTs7CobvF8zi0ALnkKKYRyQRo7u5rI5SFiSNurLQhBZzgESXu wYeWhjr35RIEW2QcHj8AaRjDUj2Sq1ngF1HInmZzGg+Ev6h78cLFv4CeVlexMeq1 E8+gczJ0O7IDRM1uqYuS9yNEX/mNG2ZRrzKIIj5xGlFtl0X0eWmI3NgCEJdqWdWg nlI5lu7YBmECjYS59jznhvn8zXVSxKlIO2BfHSjKhj51JbXbXTdi81WMsBSh1cn0 CGJQDo6Q3qaX7C0ldlaC8Og04Ycs/tZosZ22keh0O5Baqy/RJqDUcnTOEvbsF1I0 52De0pbvLiHWKivta7YkQ01KVyNu1lD/UhSuASfrtXUvJ5v4VCnlNo5J+Y1+QLct Nlozcx+I1XJ6m1vMldIf =ElyG -----END PGP SIGNATURE----- --------------enigCA30B43381B0AF4AA7B908CD-- From nobody Fri Apr 3 10:54: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 7B47F1ACE7B for ; Fri, 3 Apr 2015 10:54:44 -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 upEBR0Yy0Tqs for ; Fri, 3 Apr 2015 10:54:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34001ACE77 for ; Fri, 3 Apr 2015 10:54:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 28155BEDC; Fri, 3 Apr 2015 18:54:39 +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 U5TB_LcbU4lw; Fri, 3 Apr 2015 18:54:38 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F2543BEC9; Fri, 3 Apr 2015 18:54:37 +0100 (IST) Message-ID: <551ED3DD.8080409@cs.tcd.ie> Date: Fri, 03 Apr 2015 18:54:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sean Turner References: <551B3415.5080105@cs.tcd.ie> <2D4BF0F9-E771-4E79-848F-11617E77A36C@ieca.com> In-Reply-To: <2D4BF0F9-E771-4E79-848F-11617E77A36C@ieca.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 17:54:44 -0000 On 03/04/15 15:22, Sean Turner wrote: > On Mar 31, 2015, at 19:56, Stephen Farrell > wrote: > >> #2 I've never quite gotten the reasoning behind not giving any >> names to any of the RFC3526 curves and I think that question >> deserves an answer (to be in the list archive). So - why not? > > Maybe I’m not following but are you asking that we retroactively name > the "4096-bit MODP Group”? Right, that and any others we still like. The thought is that we might get a minor security benefit if the client says that they're ok with e.g. the 2048-bit MODP group thereby causing some server to not try use a custom group or the old smaller groups. (I mean that'd be a minor benefit compared to the current situation, not compared to what the draft proposes.) It's not a major thing as the client can still just check for the RFC3626 groups but I'm not sure how likely it is that'd be done. OTOH, anyone who updates their code to handle this can just as easily adopt the new groups, and I don't think there's any particular benefit to sticking with the RFC3526 groups (e.g. there's no dedicated h/w for those I think). So if the answer is "yeah, we considered that and didn't like it because " that's fine, I just don't recall having seen it on the list. It's also fine if the answer is "we didn't think of that, but we still don't like it" btw:-) S. > > spt > From nobody Fri Apr 3 11:09: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 C90411ACED0 for ; Fri, 3 Apr 2015 11:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pwTlAIFiAVSp for ; Fri, 3 Apr 2015 11:09:40 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 557051ACE97 for ; Fri, 3 Apr 2015 11:09:40 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id EBBBA9A402E; Fri, 3 Apr 2015 14:09:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id fbDhznqC7fL5; Fri, 3 Apr 2015 14:09:08 -0400 (EDT) Received: from [129.6.254.78] (unknown [129.6.254.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id F0C959A4020; Fri, 3 Apr 2015 14:09:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <201504031110.41062.davemgarrett@gmail.com> Date: Fri, 3 Apr 2015 14:09:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2C67979F-34A6-4E1E-B889-1EF5CB0CE0E8@vigilsec.com> References: <20150402184849.GF10960@localhost> <201504031110.41062.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1085) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 18:09:48 -0000 >>> I would like at least two modes for AES to be required: one AEAD >>> (probably GCM) and one AEAD-by-generic-construction (e.g., using = HMAC). >>=20 >> OCB is a better fit constrained devices. CCM requires two passes. >=20 > So, at this point in the discussion, this is sounding like what might = get closer to agreement: >=20 > o Symmetric: > MUST AES-OCB 128 (or 256?) The patent uncertainty prevents me from supporting this approach. I'd = need to see IPR disclosures from all three patent holders before = revisiting this as a MTI algorithm. I am not opposed to assigning a code point for AES-OCB at any key size = now. Russ From nobody Fri Apr 3 13: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 62BDD1A0111 for ; Fri, 3 Apr 2015 13:22:41 -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 FmWG9Y1Z6D4l for ; Fri, 3 Apr 2015 13:22:39 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAD81A0058 for ; Fri, 3 Apr 2015 13:22:39 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 42BBFF986 for ; Fri, 3 Apr 2015 16:22:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 724DF207B2; Fri, 3 Apr 2015 15:22:34 -0500 (CDT) From: Daniel Kahn Gillmor To: IETF TLS Working Group In-Reply-To: <551BBD6F.2070507@cs.tcd.ie> References: <20150401042731.403F61B256@ld9781.wdf.sap.corp> <551BBD6F.2070507@cs.tcd.ie> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 03 Apr 2015 16:22:34 -0400 Message-ID: <87384harn9.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 20:22:41 -0000 Hi all-- Thanks to Stephen and both Martins for the review. On Wed 2015-04-01 05:42:07 -0400, Stephen Farrell wrote: > On 01/04/15 05:27, Martin Rex wrote: >> I think Stephen might have meant something else. >> >> RFC4492 contains the following explicit prohibition (Section 4, 4th paragr.): >> >> https://tools.ietf.org/html/rfc4492#section-4 >> >> The client MUST NOT include these extensions in the ClientHello >> message if it does not propose any ECC cipher suites. > > Ooh - good catch, I hadn't spotted that. This draft is updating 4492 > though so we can validly change that, but if we're doing so (and I > guess we are) then it'd be better to be very explicit about it, e.g. > by adding a sentence saying that we're changing that specific MUST NOT. I'd be happy to add a sentence to the draft clarifying this point. If anyone wants to propose concrete text i'm happy to use it, or i'll try to come up with something short and sweet. >> and the above requirement seems to prohibit a non-ECC client from >> using the named FFDHE parameters through the ECC named curve extension >> _without_ accompanying ECC cipher suites. > > Right. That's the kind of thing I was wondering about. > > I'll happily accept the wg's word on this, but to what extent have > we checked that we're not breaking something with this change in > semantics. (It's a small, but real, change.) In practice, i've yet to find a TLS server that chokes when offered these extensions without any ECC cipher suites. GnuTLS as a client does not follow this MUST. You can try it yourself to connect to any server with something from the 3.x line: gnutls-cli --priority NORMAL:-ECDHE-RSA:-ECDHE-ECDSA $SERVER looking with wireshark, you'll see that there are no ECC ciphersuites, but the groups and point formats extensions are sent anyway. I haven't done a full zmap scan of the full ipv4 space, but i've tested many systems and have not found any servers that abort just because these extensions are present without an ECC ciphersuite. --dkg From nobody Fri Apr 3 13:25: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 753201A0381 for ; Fri, 3 Apr 2015 13:25:46 -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 gh1ya7YFUA_Z for ; Fri, 3 Apr 2015 13:25:45 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 461821A01D6 for ; Fri, 3 Apr 2015 13:25:45 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 9AC65F984 for ; Fri, 3 Apr 2015 16:25:42 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 17A9A201E4; Fri, 3 Apr 2015 15:25:40 -0500 (CDT) From: Daniel Kahn Gillmor To: IETF TLS Working Group In-Reply-To: <20150402020517.DBBDF1B25A@ld9781.wdf.sap.corp> References: <20150402020517.DBBDF1B25A@ld9781.wdf.sap.corp> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 03 Apr 2015 16:25:40 -0400 Message-ID: <87zj6p9cxn.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 20:25:46 -0000 On Wed 2015-04-01 22:05:17 -0400, Martin Rex wrote: > The problem with the quoted requirement in rfc4492 is (similar to several > highly bogus and/or overbroad requirements in other TLS-related RFCs), > that it does not distinguish PDU content from communication peer behaviour, > and does not declare whether that requirement applies only to sender > or also to recipient. This suggestion seems to imply that we should be relaxing this requirement (we've relaxed other overeager requirements in TLS that just cause interop failure), which, iiuc, is what Stephen was proposing also. > The result is, that there may easily exist server implementation of rfc4492 > which abort the TLS handshake when they receive a TLS ClientHello with > the TLS ECC named_curve extension (and only ffdhe named curves in it) > but no accompanying ECC cipher suites in the ClientHello cipher_suites_list, > and that interoperability failure OUGHT to be avoided. REALLY. If you know of any server implementations that do this, please point me (and/or the list) to them. --dkg From nobody Fri Apr 3 13:32: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 91DF11A1A70 for ; Fri, 3 Apr 2015 13:32: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 pd3i183B91a8 for ; Fri, 3 Apr 2015 13:32:03 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABEE1A1A6F for ; Fri, 3 Apr 2015 13:32:03 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 6A14EF984 for ; Fri, 3 Apr 2015 16:32:01 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id D417A20191; Fri, 3 Apr 2015 15:31:48 -0500 (CDT) From: Daniel Kahn Gillmor To: IETF TLS Working Group In-Reply-To: <551ED3DD.8080409@cs.tcd.ie> References: <551B3415.5080105@cs.tcd.ie> <2D4BF0F9-E771-4E79-848F-11617E77A36C@ieca.com> <551ED3DD.8080409@cs.tcd.ie> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 03 Apr 2015 16:31:48 -0400 Message-ID: <87wq1t9cnf.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 20:32:04 -0000 On Fri 2015-04-03 13:54:37 -0400, Stephen Farrell wrote: > On 03/04/15 15:22, Sean Turner wrote: >> On Mar 31, 2015, at 19:56, Stephen Farrell >> wrote: >> >>> #2 I've never quite gotten the reasoning behind not giving any >>> names to any of the RFC3526 curves and I think that question >>> deserves an answer (to be in the list archive). So - why not? >> >> Maybe I’m not following but are you asking that we retroactively name >> the "4096-bit MODP Group”? > > Right, that and any others we still like. The thought is that > we might get a minor security benefit if the client says that > they're ok with e.g. the 2048-bit MODP group thereby causing > some server to not try use a custom group or the old smaller > groups. (I mean that'd be a minor benefit compared to the > current situation, not compared to what the draft proposes.) > > It's not a major thing as the client can still just check for > the RFC3626 groups but I'm not sure how likely it is that'd > be done. OTOH, anyone who updates their code to handle this > can just as easily adopt the new groups, and I don't think > there's any particular benefit to sticking with the RFC3526 > groups (e.g. there's no dedicated h/w for those I think). > > So if the answer is "yeah, we considered that and didn't like > it because " that's fine, I just don't recall having seen > it on the list. There are two concrete (and related) answers in the draft as to why we're not importing several pre-existing named groups: https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08#section-9.5 https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08#section-10.1 Please let me know if there are any changes that could be made to make the situation more clear, or if you disagree with the rationales. --dkg From nobody Fri Apr 3 13:34: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 77B141A0267 for ; Fri, 3 Apr 2015 13:34:21 -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 96Vlitk8i_mv for ; Fri, 3 Apr 2015 13:34:16 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC391A0242 for ; Fri, 3 Apr 2015 13:34:16 -0700 (PDT) Received: by qgfi89 with SMTP id i89so16884966qgf.1 for ; Fri, 03 Apr 2015 13:34:15 -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=E76VYKoS06NfRM1tSUwEldo01XaBORyoJe6PSE/eL+E=; b=fpne+Q/zZt3tbd0888R5f9QL62xFuXg0LKsV5j1Um0DRTJmAQvd6JsVK5mdehTguRX geQfFl6OxVoUH+V3jhEB+RF6QpoFkCKVDRMEQfeQTudgNYBVNEZ3pNs7mlf+feESM6pz DhBtZzb/2+OovvACzBRapC1z+U5eXsjWQFdeetsKnRqwKMR/omexO0MYQcqrYA7n2j5J XJb8GxIErGa7VQgcq2Dgm7EZdCiqq+F5ukvNalYcsvzr/zU6ICwWc/NREW/Iqx2XiXMK PfNfqOMym/ZTE4ztde0tbP251LtzgO6+YX2HdQE4Hp8JY7D4YS++91vXtpgDZ0cVJl3Z lt/A== X-Gm-Message-State: ALoCoQlHyzsOwvUOmtvWlhe/5J6lcNehNRmre/CMrxy2+6xf2w6S9/q3LU5McAKSMPZQwVUZwe/5 MIME-Version: 1.0 X-Received: by 10.55.52.13 with SMTP id b13mr7708956qka.7.1428093255317; Fri, 03 Apr 2015 13:34:15 -0700 (PDT) Received: by 10.96.121.104 with HTTP; Fri, 3 Apr 2015 13:34:15 -0700 (PDT) X-Originating-IP: [50.206.82.141] Date: Fri, 3 Apr 2015 13:34:15 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1147806e3091290512d7dfcb Archived-At: Subject: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 20:34:21 -0000 --001a1147806e3091290512d7dfcb Content-Type: text/plain; charset=UTF-8 In the interim meeting we had consensus to use an implicit IV for AEAD. The proposal was to use the record sequence number and pad with zeros as described in pull request 155 ( https://github.com/tlswg/tls13-spec/pull/155/files). This was also discussed in the IETF-92 meeting in Dallas along with options to change the offset. The consensus was to stay with the original proposal. We are posting to the mailing list to confirm this consensus. If you have comments, please reply by April 17, 2015. Thanks, S&J --001a1147806e3091290512d7dfcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the interim meeting we had consensus to use an implicit= IV for AEAD.=C2=A0 The proposal was to use the record sequence number and = pad with zeros as described in pull request 155 (https://github.com/tlswg/tls13-spec/pu= ll/155/files).=C2=A0 This was also discussed in the IETF-92 meeting in = Dallas along with options to change the offset.=C2=A0 The consensus was to = stay with the original proposal.=C2=A0 We are posting to the mailing list t= o confirm this consensus. If you have comments, =C2=A0please reply by April= 17, 2015. =C2=A0

Thanks,

S&J
--001a1147806e3091290512d7dfcb-- From nobody Fri Apr 3 13:46: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 C13811A037D for ; Fri, 3 Apr 2015 13:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.295 X-Spam-Level: ** X-Spam-Status: No, score=2.295 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 chSxUi_ui5kb for ; Fri, 3 Apr 2015 13:46:26 -0700 (PDT) Received: from dragaera.releasedominatrix.com (unknown [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 438421A037B for ; Fri, 3 Apr 2015 13:46:26 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 6908533D29F; Fri, 3 Apr 2015 20:46:25 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <551BBD6F.2070507@cs.tcd.ie> <20150402020517.DBBDF1B25A@ld9781.wdf.sap.corp> From: Geoffrey Keating Date: 03 Apr 2015 13:46:25 -0700 In-Reply-To: <20150402020517.DBBDF1B25A@ld9781.wdf.sap.corp> Message-ID: Lines: 23 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] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 20:46:29 -0000 mrex@sap.com (Martin Rex) writes: > >Martin Rex wrote: > >> RFC4492 contains the following explicit prohibition (Section 4, 4th paragr.): > >> > >> https://tools.ietf.org/html/rfc4492#section-4 > >> > >> > >> The client MUST NOT include these extensions in the ClientHello > >> message if it does not propose any ECC cipher suites. > The result is, that there may easily exist server implementation of rfc4492 > which abort the TLS handshake when they receive a TLS ClientHello with > the TLS ECC named_curve extension (and only ffdhe named curves in it) > but no accompanying ECC cipher suites in the ClientHello cipher_suites_list, > and that interoperability failure OUGHT to be avoided. REALLY. There's no way an implementation can be sure there are no ECC cipher suites proposed unless it recognizes every proposed cipher suite, and I understand that elsewhere we're proposing a complete redesign of the cipher suites so there will always be cipher suites that a pre-1.3 implementation does not recognize. Implementations could be buggy, of course---but that's always true. From nobody Fri Apr 3 13:48: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 C0EE71A0162 for ; Fri, 3 Apr 2015 13:48:31 -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 i-fxTFSAIdMb for ; Fri, 3 Apr 2015 13:48:30 -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 CCE941A0158 for ; Fri, 3 Apr 2015 13:48:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 95D60BECA; Fri, 3 Apr 2015 21:48:28 +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 Gdh3wLEpf7fy; Fri, 3 Apr 2015 21:48:26 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6D6C3BE38; Fri, 3 Apr 2015 21:48:26 +0100 (IST) Message-ID: <551EFC9A.8070804@cs.tcd.ie> Date: Fri, 03 Apr 2015 21:48:26 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , IETF TLS Working Group References: <551B3415.5080105@cs.tcd.ie> <2D4BF0F9-E771-4E79-848F-11617E77A36C@ieca.com> <551ED3DD.8080409@cs.tcd.ie> <87wq1t9cnf.fsf@alice.fifthhorseman.net> In-Reply-To: <87wq1t9cnf.fsf@alice.fifthhorseman.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 20:48:31 -0000 On 03/04/15 21:31, Daniel Kahn Gillmor wrote: > On Fri 2015-04-03 13:54:37 -0400, Stephen Farrell wrote: >> On 03/04/15 15:22, Sean Turner wrote: >>> On Mar 31, 2015, at 19:56, Stephen Farrell >>> wrote: >>> >>>> #2 I've never quite gotten the reasoning behind not giving any >>>> names to any of the RFC3526 curves and I think that question >>>> deserves an answer (to be in the list archive). So - why not? >>> >>> Maybe I’m not following but are you asking that we retroactively name >>> the "4096-bit MODP Group”? >> >> Right, that and any others we still like. The thought is that >> we might get a minor security benefit if the client says that >> they're ok with e.g. the 2048-bit MODP group thereby causing >> some server to not try use a custom group or the old smaller >> groups. (I mean that'd be a minor benefit compared to the >> current situation, not compared to what the draft proposes.) >> >> It's not a major thing as the client can still just check for >> the RFC3626 groups but I'm not sure how likely it is that'd >> be done. OTOH, anyone who updates their code to handle this >> can just as easily adopt the new groups, and I don't think >> there's any particular benefit to sticking with the RFC3526 >> groups (e.g. there's no dedicated h/w for those I think). >> >> So if the answer is "yeah, we considered that and didn't like >> it because " that's fine, I just don't recall having seen >> it on the list. > > There are two concrete (and related) answers in the draft as to why > we're not importing several pre-existing named groups: > > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08#section-9.5 > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08#section-10.1 > > Please let me know if there are any changes that could be made to make > the situation more clear, or if you disagree with the rationales. It's not that I disagree with 'em, but I don't find them that compelling tbh. The best (to me) seems to be that additional usage in multiple protocols makes for a more attractive target. But the MODP groups are already used in TLS, and naming them in this way might reduce the liklihood that some implementation accepts groups without checking 'em. (E.g. an updated client would have the code to check that a known-named group has been selected by the server, so might benefit even if the server hasn't been updated). However, let's proceed and please treat the above as just another last call comment. In this case, you've responded already so if nobody else wants to pursue the discussion then we'll be all set. S. > > --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Apr 3 13:49: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 08E231A037B for ; Fri, 3 Apr 2015 13:49:25 -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 EKIx-AP-kCG3 for ; Fri, 3 Apr 2015 13:49:23 -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 625131A0158 for ; Fri, 3 Apr 2015 13:49:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2DCC2BECA; Fri, 3 Apr 2015 21:49:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxgaZWPj59S3; Fri, 3 Apr 2015 21:49:20 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 98113BE38; Fri, 3 Apr 2015 21:49:20 +0100 (IST) Message-ID: <551EFCD0.1010803@cs.tcd.ie> Date: Fri, 03 Apr 2015 21:49:20 +0100 From: Stephen Farrell 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" , Daniel Kahn Gillmor References: <551B3415.5080105@cs.tcd.ie> In-Reply-To: <551B3415.5080105@cs.tcd.ie> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 20:49:25 -0000 Hi all, So I've gotten responses for both issues, and will now start the IETF LC. Please comment as part of that if you think there's something more to be done. Cheers, S. On 01/04/15 00:56, Stephen Farrell wrote: > > Hiya, > > I've done my AD review of this, and it's very good. I have > two questions I'd like to check on before starting IETF > last call. If the answers are already in the list archive, > then just pointing there is entirely fine. If not, well, > they're not such hard questions:-) > > #1 Have we tested in the wild that using elliptic_curves (10) > in the ClientHello won't trigger some ECC code that causes > handshakes to barf? > > #2 I've never quite gotten the reasoning behind not giving > any names to any of the RFC3526 curves and I think that > question deserves an answer (to be in the list archive). > So - why not? > > Cheers, > S. > > PS: I also have a bunch of nitty nits, feel free to handle > those however is best. > > - intro: What is "Traditional TLS"? Ye olde something or > other? :-) > > - intro: "p > 1024 bits" is fine by me but better would be > to say "p is longer than 1024 bits" > > - s3, 2nd para: I suggest a para break before you get to the > bit about both ECC and DHE. > > - s3, 3rd para: what is the "these" in here? This reads a > bit oddly. > > - 5.1: "public key" is less common than "public value" I > think, when talking about DH. FWIW, I prefer value as saying > key confuses some people into thinking this is a long term > value. > > - 5.2: 4419 has a reference to a Paul Van Oorschot paper > that justifies the security here. Did we check there are no > more recent results? (Esp ones that might invalidate the > optimisation.) Could also be good to include whatever is > today's best reference for this directly rather than just > via 4419. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Fri Apr 3 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 0AF651A1BA2 for ; Fri, 3 Apr 2015 14:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-3eqd1LfGEq for ; Fri, 3 Apr 2015 14:01:17 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A34E01A1B9C for ; Fri, 3 Apr 2015 14:01:16 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 23031F984; Fri, 3 Apr 2015 17:01:13 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id D3F152023A; Fri, 3 Apr 2015 16:01:00 -0500 (CDT) From: Daniel Kahn Gillmor To: Aaron Zauner , Bill Frantz In-Reply-To: <551EB007.2010304@azet.org> References: <551EB007.2010304@azet.org> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 03 Apr 2015 17:01:00 -0400 Message-ID: <87sich9bar.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Killing Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 21:01:25 -0000 On Fri 2015-04-03 11:21:43 -0400, Aaron Zauner wrote: > Bill Frantz wrote: >> From my point of view, acceptable techniques include online code update >> and special messages which cause implementations to permanently cease >> using an algorithm, along with methods and procedures to ensure that >> these techniques actually work in the field. > > As much as I like the idea, until someone proposes a sane method to do > so /online/ in the protocol, I don't think it makes a lot of sense to > add that to the document, it'll only confuse readers. > > I can't think of a way a client or server could negotiate that a cipher > is deprecated. That'll cause downgrade attacks all over again, possibly > to the cipher that would by then be deprecated. I've thought about this a lot, and haven't come up with any answers that i like very much. Perhaps i'm not imaginative or accepting enough, though! The problem is even worse than "we don't have a good way to switch an algorithm off when we learn that it's broken" -- at the moment we don't even have a good way to switch an algorithm off when we have known for years that it has been catastrophically broken (e.g. EXPORT ciphersuites still biting people in 2015, thanks FREAK)! At the moment, the only deprecation models we have seen in practice are: 0) explicit deprecation documents from standards bodies (like we've done for SSLv2 and are doing for RC4). These often don't have teeth, but are used as advice. 1) phased approaches driven by powerful vendors (e.g. SHA-1 deprecation driven by Google and Microsoft) that rely on gradually-increasing minor "penalties" (log messages, UI deprecation hints, no EV decoration, etc) with a well-published timeline for outright banning of the algorithm. These approaches only seem possible only for those players with a lot of weight to throw around. Here's a thought experiment to consider (i don't think i like this any more than either of the above, but i haven't heard any other proposals): Suppose the TLS WG (or some other part of the IETF or IRTF) places a "believed good until" date on every algorithm in the spec. We would commit to updating this "freshness" estimate some interval before the algorithm "expires". We would ask implementations with access to a "real" clock to commit to disabling each algorithm after its expiration date, unless they recieve notice that the algorithm's expiration has been extended. This would put an upper bound on algorithm lifetime, as well as on the lifetime that a given implementation could survive in the wild without at least some form of update mechanism (for updating the algorithm expiration dates at least). This also provides an impetus for the community to do active, regular review, rather than assuming that a given algorithm is just "good until proven otherwise". Some problems i have this proposal (i'm sure there are others too!): * smells like "planned obsolescence" -- from a "consumer" perspective, it feels manipulative and cagey, esp. if i have to pay my vendor for the upgrades. Do we need to start thinking about software less like a hammer or saw, and more like fruits and vegetables? * not every implementation has a wall clock, or has it set right. what happens to these machines? * what happens when the update mechanism fails? * what kinds of attacks do we introduce by being able to turn off algorithms by fiddling with a victim's clock? * who is responsible for refreshing the expiration dates? how is this done? this is a time-sensitive, potentially-controversial topic. What if the deadline passes without being able to establish a rough consensus? what if the relevant parties fall asleep at the switch? * what does this do to the incentives in the academic community to study algorithms that have not yet reached their expiration date? what about algorithms past their expiration date? I'd love to hear other concrete proposals for how we can actually effectively deprecate algorithms in the wild, once a deployed base exists. --dkg From nobody Fri Apr 3 14:16: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 7DCDE1A886B for ; Fri, 3 Apr 2015 14:16:56 -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 FhK6AxoFfw_A for ; Fri, 3 Apr 2015 14:16:54 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E859C1A8775 for ; Fri, 3 Apr 2015 14:16:53 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id F14B4F984; Fri, 3 Apr 2015 17:16:50 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 819E4207B2; Fri, 3 Apr 2015 16:16:37 -0500 (CDT) From: Daniel Kahn Gillmor To: Stephen Farrell , IETF TLS Working Group In-Reply-To: <551EFC9A.8070804@cs.tcd.ie> References: <551B3415.5080105@cs.tcd.ie> <2D4BF0F9-E771-4E79-848F-11617E77A36C@ieca.com> <551ED3DD.8080409@cs.tcd.ie> <87wq1t9cnf.fsf@alice.fifthhorseman.net> <551EFC9A.8070804@cs.tcd.ie> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 03 Apr 2015 17:16:37 -0400 Message-ID: <87k2xsap56.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 21:16:56 -0000 On Fri 2015-04-03 16:48:26 -0400, Stephen Farrell wrote: > It's not that I disagree with 'em, but I don't find them > that compelling tbh. The best (to me) seems to be that > additional usage in multiple protocols makes for a more > attractive target. But the MODP groups are already used > in TLS, and naming them in this way might reduce the > liklihood that some implementation accepts groups without > checking 'em. The MODP groups are not explicitly used anywhere in the TLS specs (though of course nothing prevents a TLS server from chooing to use one of them). Some of the MODP groups (with different generators in some cases) are used in TLS SRP (this is not the standard FFDHE handshake), but aiui, we're talking about killing off SRP anyway. > (E.g. an updated client would have the code to check that a > known-named group has been selected by the server, so might benefit > even if the server hasn't been updated). If it were already common practice to use strong MODP groups for FFDHE, this might be a convincing argument. But in the surveys i've seen, most DHE implementations restrict themselves to 1024-bit FFDHE anyway, possibly due to client incompatibility or lack of understanding of the protocol. Whether that's MODP 1024 or some other 1024-bit DHE group, this is still too weak for most guarantees i'd like to see TLS be able to make. > However, let's proceed and please treat the above as just > another last call comment. In this case, you've responded > already so if nobody else wants to pursue the discussion > then we'll be all set. sounds good to me. thanks for the review and the feedback, Stephen. --dkg From nobody Fri Apr 3 14:19: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 990001A882A for ; Fri, 3 Apr 2015 14:19:46 -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 7rSx-dfGbMmB for ; Fri, 3 Apr 2015 14:19:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C11A1A8775 for ; Fri, 3 Apr 2015 14:19:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 295A0BEDB; Fri, 3 Apr 2015 22:19:44 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNPR9vjUl2pE; Fri, 3 Apr 2015 22:19:43 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 20FB3BED0; Fri, 3 Apr 2015 22:19:43 +0100 (IST) Message-ID: <551F03EE.7040001@cs.tcd.ie> Date: Fri, 03 Apr 2015 22:19:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , IETF TLS Working Group References: <551B3415.5080105@cs.tcd.ie> <2D4BF0F9-E771-4E79-848F-11617E77A36C@ieca.com> <551ED3DD.8080409@cs.tcd.ie> <87wq1t9cnf.fsf@alice.fifthhorseman.net> <551EFC9A.8070804@cs.tcd.ie> <87k2xsap56.fsf@alice.fifthhorseman.net> In-Reply-To: <87k2xsap56.fsf@alice.fifthhorseman.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 21:19:46 -0000 On 03/04/15 22:16, Daniel Kahn Gillmor wrote: > Whether that's MODP 1024 or some other 1024-bit DHE group, > this is still too weak for most guarantees i'd like to see TLS be able > to make. I fully agree that naming MODP1024 as part of this would be a bad idea. S. From nobody Fri Apr 3 14:38: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 F264D1A1A42 for ; Fri, 3 Apr 2015 14:38: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 ycXGR2r4ZVy1 for ; Fri, 3 Apr 2015 14:38:16 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003: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 839381A0193 for ; Fri, 3 Apr 2015 14:38:16 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so177906476obb.1 for ; Fri, 03 Apr 2015 14:38:16 -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=uUV1CBScVxhtZsBukdFXPG4f9Z5tGgvnpdFGMaVv8fI=; b=twBPIsmxk1S3xIbxOrqPBxEYILdQEwXKM1Q1pma45QMmlujmzHeivOIpEJF7HsAmOo 7JbDwvoOPClQKpw72KnJr9nUmWEh8bJ4l+05SNyIWdbIQwPOhIWnSyzOPjAbNylxnrEL mUthpxeEmeuE7FWQLn2eVEPdAaLu5BTfN3hYBhnaRBAErgceS8JLZ4VAPD3L2iW2PQ13 BjQTCTnPESn0PkTjThMtLKJZtjrWI3cYH76GsuiMRSZfJqPPQPFGbZ7TOorIdpimKq29 XiBm/CktdCocfhzU/2Kl69NC/id0PhiGaXKQul48aNUfNLhecI9PnPBbrnVGbRHLo9m8 qJ2g== X-Received: by 10.60.94.244 with SMTP id df20mr5242803oeb.16.1428097096076; Fri, 03 Apr 2015 14:38:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.213.206 with HTTP; Fri, 3 Apr 2015 14:37:55 -0700 (PDT) From: Fabrice Gautier Date: Fri, 3 Apr 2015 14:37:55 -0700 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 21:38:18 -0000 Hi all, It's not clear to me what should be the protocol version be selected when trying to resume sessions. For the cipher_suite in the ServerHello, the TLS 1.2 RFC explicitly says: For resumed sessions, this field is the value from the state of the session being resumed. But for the protocol_version it does not say anything specific about resumption, so, its just: This field will contain the lower of that suggested by the client in the client hello and the highest supported by the server. I also note that in Section 7, the definition of a Session does NOT include the protocol version. Given that, it seems that it's acceptable for a server to attempt to resume a session with TLS 1.2 that was originally established with TLS 1.0, or vice-versa. That seems wrong, but I also guess this is a very plausible scenario given that many implementation do version fallback if something goes wrong. So what should be the behavior of a server when trying to resume but there is a version mismatch ? (1) Cache the old ClientHello.version and do not resume a session if the new ClientHello.version does not match the cached one. (2) Cache the old ServerHello.version and do not resume if the new ClientHello.version does not allow to negotiate the same ServeHello.version. Allow resuming at lower version even if both side support higher version. (3) Cache the old ServerHello.version and do not resume unless the cached version is the max of ClientHello.version and max supported Server version. (e.g.: Do full handshake at best version instead of downgrading to a lower cached version) (4) Don't cache any version, always attempt to resume with the max of ClientHello.version and max supported Server version My guts tell me that (3) is the right thing to do. What do other think ? Thanks -- Fabrice From nobody Fri Apr 3 14:42: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 59FF01A1A9B for ; Fri, 3 Apr 2015 14:42:25 -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 28YbOQQFrLrZ for ; Fri, 3 Apr 2015 14:42:23 -0700 (PDT) Received: from BLU004-OMC4S34.hotmail.com (blu004-omc4s34.hotmail.com [65.55.111.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771371A1A4F for ; Fri, 3 Apr 2015 14:42:23 -0700 (PDT) Received: from BLU177-W41 ([65.55.111.135]) by BLU004-OMC4S34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 3 Apr 2015 14:42:22 -0700 X-TMN: [vwDkPW0u76D5v1A43OXAQ2c/4fK61LNg] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Fabrice Gautier , "tls@ietf.org" Date: Fri, 3 Apr 2015 14:42:22 -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: 03 Apr 2015 21:42:22.0833 (UTC) FILETIME=[117C8E10:01D06E57] Archived-At: Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 21:42:25 -0000 I am thinking that the introduction of the TLS session hash extension is a = good time to clarify this matter.=0A= =0A= ----------------------------------------=0A= > From: fabrice.gautier@gmail.com=0A= > Date: Fri=2C 3 Apr 2015 14:37:55 -0700=0A= > To: tls@ietf.org=0A= > Subject: [TLS] Interaction between session resumption and negotiated prot= ocol version=0A= >=0A= > Hi all=2C=0A= >=0A= > It's not clear to me what should be the protocol version be selected=0A= > when trying to resume sessions.=0A= >=0A= > For the cipher_suite in the ServerHello=2C the TLS 1.2 RFC explicitly say= s:=0A= >=0A= > For resumed sessions=2C this field is the value from the state of=0A= > the session being resumed.=0A= >=0A= > But for the protocol_version it does not say anything specific about=0A= > resumption=2C so=2C its just:=0A= >=0A= > This field will contain the lower of that suggested by the=0A= > client in the client hello and the highest supported by the server.=0A= >=0A= >=0A= > I also note that in Section 7=2C the definition of a Session does NOT=0A= > include the protocol version.=0A= >=0A= >=0A= > Given that=2C it seems that it's acceptable for a server to attempt to=0A= > resume a session with TLS 1.2 that was originally established with TLS=0A= > 1.0=2C or vice-versa.=0A= >=0A= > That seems wrong=2C but I also guess this is a very plausible scenario=0A= > given that many implementation do version fallback if something goes=0A= > wrong.=0A= >=0A= > So what should be the behavior of a server when trying to resume but=0A= > there is a version mismatch ?=0A= >=0A= > (1) Cache the old ClientHello.version and do not resume a session if=0A= > the new ClientHello.version does not match the cached one.=0A= > (2) Cache the old ServerHello.version and do not resume if the new=0A= > ClientHello.version does not allow to negotiate the same=0A= > ServeHello.version. Allow resuming at lower version even if both side=0A= > support higher version.=0A= > (3) Cache the old ServerHello.version and do not resume unless the=0A= > cached version is the max of ClientHello.version and max supported=0A= > Server version. (e.g.: Do full handshake at best version instead of=0A= > downgrading to a lower cached version)=0A= > (4) Don't cache any version=2C always attempt to resume with the max of= =0A= > ClientHello.version and max supported Server version=0A= >=0A= >=0A= > My guts tell me that (3) is the right thing to do.=0A= >=0A= > What do other think ?=0A= >=0A= >=0A= > Thanks=0A= >=0A= > -- Fabrice=0A= >=0A= > _______________________________________________=0A= > TLS mailing list=0A= > TLS@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tls=0A= = From nobody Fri Apr 3 16:06: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 6ABED1A8749 for ; Fri, 3 Apr 2015 16:06:23 -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 XzQLk0djY-_T for ; Fri, 3 Apr 2015 16:06:21 -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 290801A8740 for ; Fri, 3 Apr 2015 16:06:21 -0700 (PDT) Received: by igblo3 with SMTP id lo3so16866757igb.0 for ; Fri, 03 Apr 2015 16:06:20 -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 :content-type; bh=t5aDhLjMXJd1omghPa5ykqJ8Y+mVxrnmvwC2grJ/+aE=; b=nQV/IF6wm1BxOM94uLrBevwHGD+ijZcIe7Hs+3MKA0uIbRUd5xJSS+xFwoB4wKP18X WxJZNGkEQXKT2FNS1Zns3NuQRRvtgGoO195HwG04xERIZkYbmgv7ZtfXZGRPmgGqQbzZ t8yFdTmjZg66Mh1HgWw/dPIvLlQmDuaQreCJ4= 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:content-type; bh=t5aDhLjMXJd1omghPa5ykqJ8Y+mVxrnmvwC2grJ/+aE=; b=Ii1ifflcZD5yRX8Jn8rCRKrG91u2MpJIAJKPXL07nrrwcRxcJzJbA/Bn4e1dKm/lnz bElN9mRiDp438Pk8uozHIWvjHTfjBbg31Mpi9nebQDGFlTY/qCTjV83/S3W2iACXqGMF XVju/7L3cVGbxMGI0uc/6ZLrk0p8LYqWP9d4ojRojDkkHWLPSXi4CiTz6X+ugUoh0eFi CyZ9gtOQ7Ah+48G0A6HZq8vhRUDckGopDqjmkseEfgmjH96JccBUUeCZ5WuC6xq43iXS zNuxHFRhT40hLWXIC4J11iU+WOpbsurqyoFRiV+BaaGEdT8XZv7sjOGPF7bBgUMDAwww 06kw== X-Gm-Message-State: ALoCoQl4zZ/mK7aKxfNswH6z0yAkMoRzz41pkYUb5jfivXxOV0ya+xJmyafolxk4kMFwEy8RIK87 X-Received: by 10.50.66.141 with SMTP id f13mr8005674igt.9.1428102380542; Fri, 03 Apr 2015 16:06:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Fri, 03 Apr 2015 23:06:19 +0000 Message-ID: To: Yuhong Bao , Fabrice Gautier , "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc0dd218adf80512d9ffec Archived-At: Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 23:06:23 -0000 --047d7bdc0dd218adf80512d9ffec Content-Type: text/plain; charset=UTF-8 Conveniently, I spent a lot of time wrestling with this a while back and testing client implementations: https://github.com/tlswg/tls13-spec/issues/136 #4 turns out to be incompatible with basically every client implementation out there. They all reject cross-version resumptions. It's not even clear what this should mean if a future TLS version were to, say, change the size of the master secret or how resumption works. I agree #3 is the most natural. The behavior for a server is then: 1. Based on client_version, select a protocol version. 2. Look up session based on session_id or ticket. 3. If the version the session was established at does not match the negotiated version, pretend the lookup failed. 4. Do a full or abbreviated handshake based on whether other properties of the session check out (cipher suite still allowed, etc.). This is equivalent to saying that the notion of a "session" or "session cache" is a version-specific thing. A TLS 1.0 session cache is a different beast from a TLS 1.1 session cache, so a cross-version lookup should fail, and lookup isn't even defined until you've picked a version. This also works best with future versions of TLS changing how session resumption works. But no one, to my knowledge, has separate 1.0 and 1.1 session cache implementations, so this should be spelled out explicitly. Otherwise, #1 probably works too, though OpenSSL doesn't store the client_version. I think I mostly see that as the client's responsibility; session resumption skips negotiation of lots of parameters, so you already have to be aware of handling this when your half of preferences change. A server SHOULD flush its session cache and invalidate tickets when changing cipher preferences, a client SHOULD shard the session cache by fallback type, etc. David On Fri, Apr 3, 2015 at 5:42 PM Yuhong Bao wrote: > I am thinking that the introduction of the TLS session hash extension is a > good time to clarify this matter. > > ---------------------------------------- > > From: fabrice.gautier@gmail.com > > Date: Fri, 3 Apr 2015 14:37:55 -0700 > > To: tls@ietf.org > > Subject: [TLS] Interaction between session resumption and negotiated > protocol version > > > > Hi all, > > > > It's not clear to me what should be the protocol version be selected > > when trying to resume sessions. > > > > For the cipher_suite in the ServerHello, the TLS 1.2 RFC explicitly says: > > > > For resumed sessions, this field is the value from the state of > > the session being resumed. > > > > But for the protocol_version it does not say anything specific about > > resumption, so, its just: > > > > This field will contain the lower of that suggested by the > > client in the client hello and the highest supported by the server. > > > > > > I also note that in Section 7, the definition of a Session does NOT > > include the protocol version. > > > > > > Given that, it seems that it's acceptable for a server to attempt to > > resume a session with TLS 1.2 that was originally established with TLS > > 1.0, or vice-versa. > > > > That seems wrong, but I also guess this is a very plausible scenario > > given that many implementation do version fallback if something goes > > wrong. > > > > So what should be the behavior of a server when trying to resume but > > there is a version mismatch ? > > > > (1) Cache the old ClientHello.version and do not resume a session if > > the new ClientHello.version does not match the cached one. > > (2) Cache the old ServerHello.version and do not resume if the new > > ClientHello.version does not allow to negotiate the same > > ServeHello.version. Allow resuming at lower version even if both side > > support higher version. > > (3) Cache the old ServerHello.version and do not resume unless the > > cached version is the max of ClientHello.version and max supported > > Server version. (e.g.: Do full handshake at best version instead of > > downgrading to a lower cached version) > > (4) Don't cache any version, always attempt to resume with the max of > > ClientHello.version and max supported Server version > > > > > > My guts tell me that (3) is the right thing to do. > > > > What do other think ? > > > > > > Thanks > > > > -- Fabrice > > > > _______________________________________________ > > 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 > --047d7bdc0dd218adf80512d9ffec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Conveniently, I spent a lot of time wrestling with this a = while back and testing client implementations:
https://github.com/tlswg/tls13-spec/issue= s/136

#4 turns out to be incompatible with basically every = client implementation out there. They all reject cross-version resumptions.= It's not even clear what this should mean if a future TLS version were= to, say, change the size of the master secret or how resumption works.
=
I agree #3 is the most natural.=C2=A0The behavior for a server is= then:
1. Based on client_version, select a protocol version.
2. Look= up session based on session_id or ticket.
3. If the version the sessio= n was established at does not match the negotiated version, pretend the loo= kup failed.
4. Do a full or abbreviated handshake based on whether other= properties of the session check out (cipher suite still allowed, etc.).

This is equivalent to saying that the notion of a &q= uot;session" or "session cache" is a version-specific thing.= A TLS 1.0 session cache is a different beast from a TLS 1.1 session cache,= so a cross-version lookup should fail, and lookup isn't even defined u= ntil you've picked a version. This also works best with future versions= of TLS changing how session resumption works. But no one, to my knowledge,= has separate 1.0 and 1.1 session cache implementations, so this should be = spelled out explicitly.

Otherwise, #1 probably works too, though Ope= nSSL doesn't store the client_version. I think I mostly see that as the= client's responsibility; session resumption skips negotiation of lots = of parameters, so you already have to be aware of handling this when your h= alf of preferences change. A server SHOULD flush its session cache and inva= lidate tickets when changing cipher preferences, a client SHOULD shard the = session cache by fallback type, etc.

David

On Fri, Apr 3, 2015 at 5:42 PM Yuhong Bao <yuhongbao_386@hotmail.com> wro= te:
I am thinking that the introduction o= f the TLS session hash extension is a good time to clarify this matter.

----------------------------------------
> From: f= abrice.gautier@gmail.com
> Date: Fri, 3 Apr 2015 14:37:55 -0700
> To: tls@ietf.org=
> Subject: [TLS] Interaction between session resumption and negotiated p= rotocol version
>
> Hi all,
>
> It's not clear to me what should be the protocol version be select= ed
> when trying to resume sessions.
>
> For the cipher_suite in the ServerHello, the TLS 1.2 RFC explicitly sa= ys:
>
> For resumed sessions, this field is the value from the state of
> the session being resumed.
>
> But for the protocol_version it does not say anything specific about > resumption, so, its just:
>
> This field will contain the lower of that suggested by the
> client in the client hello and the highest supported by the server. >
>
> I also note that in Section 7, the definition of a Session does NOT > include the protocol version.
>
>
> Given that, it seems that it's acceptable for a server to attempt = to
> resume a session with TLS 1.2 that was originally established with TLS=
> 1.0, or vice-versa.
>
> That seems wrong, but I also guess this is a very plausible scenario > given that many implementation do version fallback if something goes > wrong.
>
> So what should be the behavior of a server when trying to resume but > there is a version mismatch ?
>
> (1) Cache the old ClientHello.version and do not resume a session if > the new ClientHello.version does not match the cached one.
> (2) Cache the old ServerHello.version and do not resume if the new
> ClientHello.version does not allow to negotiate the same
> ServeHello.version. Allow resuming at lower version even if both side<= br> > support higher version.
> (3) Cache the old ServerHello.version and do not resume unless the
> cached version is the max of ClientHello.version and max supported
> Server version. (e.g.: Do full handshake at best version instead of > downgrading to a lower cached version)
> (4) Don't cache any version, always attempt to resume with the max= of
> ClientHello.version and max supported Server version
>
>
> My guts tell me that (3) is the right thing to do.
>
> What do other think ?
>
>
> Thanks
>
> -- Fabrice
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--047d7bdc0dd218adf80512d9ffec-- From nobody Fri Apr 3 16:33: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 E9F5B1A8761 for ; Fri, 3 Apr 2015 16:33: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 DZteFT-xt0S1 for ; Fri, 3 Apr 2015 16:33:33 -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 899CB1A875C for ; Fri, 3 Apr 2015 16:33:33 -0700 (PDT) Received: by qgeb100 with SMTP id b100so60535221qge.3 for ; Fri, 03 Apr 2015 16:33: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=Rp72C5yvz4vQMw7sQSHMxTTsQbKqaj8Y1BTDWET+0IA=; b=dReRW+nZ/OZMVJl063s/m1+iGZ9IYyTK9pD9ziVP1MsVbILetOZvpMRLkP3CrO4A+/ qHdBCJst9rhjsLIBggXKq3HtmexIe0C2vUKma1sezwgIiV0NZBWLovcerp4tXkRdFJej j4WlnzTCySOuhDb+jgivyvZZSE9BpV44V2eS/gIWZHamL8GimGbDIz6rfAct/w6iMS29 3MZf4l2DpPloRad0p8RTeoYrB28ovIEhHay1XO7/EBVMx8rdCiUcCKAX1jp6L2/n6HTf 5O3m4QjKbV8+KlLnTQCRky+ww6xvKbWLx970hQHohe6Z2oF4p94XAfmAeA2ZR5iXtxGw 0Gsw== X-Received: by 10.140.97.98 with SMTP id l89mr4305862qge.92.1428104012832; Fri, 03 Apr 2015 16:33: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 x10sm6656597qha.2.2015.04.03.16.33.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Apr 2015 16:33:32 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 3 Apr 2015 19:33:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-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: <201504031933.31280.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 23:33:35 -0000 On Friday, April 03, 2015 07:06:19 pm David Benjamin wrote: > Conveniently, I spent a lot of time wrestling with this a while back and > testing client implementations: > https://github.com/tlswg/tls13-spec/issues/136 Just to note, the current draft still has an equivalent "SHOULD" in the updated backwards compatibility section. I dropped the "already knows" part, as that was not a particularly safe assumption to keep. (both the "knowing" part & the fact that things could of course change) The loose requirement for resumption is still in there, just worded to be just for resumption. TLS 1.2 has: Whenever a client already knows the highest protocol version known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol. TLS 1.3 currently has: A client resuming a session SHOULD initiate the connection using the version that was previously negotiated. Dave From nobody Fri Apr 3 16:49: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 BEAC01A87AE for ; Fri, 3 Apr 2015 16:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 o6ZwQHCGD3Ke for ; Fri, 3 Apr 2015 16:48:58 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.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 36C9A1A87A7 for ; Fri, 3 Apr 2015 16:48:58 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so102841771obb.2 for ; Fri, 03 Apr 2015 16:48:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DXXV+AcUXDu/xQePrv4HnvGKgJts2Xl3KuFU3jL5r24=; b=XU0On6wEeQr2OlUaE47VxlORSlBLtGwsjGloNeIpPv9yXpPWSdcpSyGqciDEzHhgsB KBZjbO7nKo79nAc2PFxlkb1M/meogVJmNoGot6pyGw1klU9s+00aOMsYbFOUF9RNpbXW KE6o29S3yr4oe+d6sItJUjUGA7HMTDZDtbCUvHMoFFmpQsDiG0hY4RvX1HBvifL356VO kZOvD84/j8sE23CDjzBBIkUtD23/0SkV0ZW1iTSzVtMEo5GYoPtlaHEcCplB9IDa0QSj HkqyqJ8XbZjwW6Fu/elbumbjeZ4n5h0zWF8swjxtY1XjYAzi/j0A9aVbXaa5AjWso8vi 8zFw== X-Gm-Message-State: ALoCoQk0iCcPh1RH/W1xykZdCgbfJL6DPUVFSSnwrcxWn8jPBCgazj67CMNbpYnLd+papndJL1ze MIME-Version: 1.0 X-Received: by 10.182.255.231 with SMTP id at7mr5573288obd.20.1428104937660; Fri, 03 Apr 2015 16:48:57 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Fri, 3 Apr 2015 16:48:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Apr 2015 13:48:57 -1000 Message-ID: From: Brian Smith To: Fabrice Gautier Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 23:48:59 -0000 Fabrice Gautier wrote: > Given that, it seems that it's acceptable for a server to attempt to > resume a session with TLS 1.2 that was originally established with TLS > 1.0, or vice-versa. Perhaps one could construct a logical argument for that. However, is it really worth the complication for the server to try to resume a session that was established at a different version than it would otherwise create a new session? I doubt any potential benefit would outweigh the likely harm of doing so. > That seems wrong, but I also guess this is a very plausible scenario > given that many implementation do version fallback if something goes > wrong. Two wrongs don't make a right. > (3) Cache the old ServerHello.version and do not resume unless the > cached version is the max of ClientHello.version and max supported > Server version. (e.g.: Do full handshake at best version instead of > downgrading to a lower cached version) > My guts tell me that (3) is the right thing to do. Yes! Here's another way of thinking about it: Given ClientHello.client_version and the max version the server supports, calculate ServerHello.server_version. Then, look in the session cache for an entry that has the *exact same* ServerHello.server_version. If you find one, resume that session. Otherwise, do a full handshake. If you want to be really careful, also calculate cipher_suite before resuming, and only resume a session that has the same cipher_suite. Cheers, Brian From nobody Fri Apr 3 16: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 51A6C1A87A7 for ; Fri, 3 Apr 2015 16:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 DtXGFKEQBB_T for ; Fri, 3 Apr 2015 16:52:55 -0700 (PDT) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.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 234681A877F for ; Fri, 3 Apr 2015 16:52:55 -0700 (PDT) Received: by obvd1 with SMTP id d1so188353797obv.0 for ; Fri, 03 Apr 2015 16:52:54 -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=3mIKjybpOtETRVySFa4lTkKVjz4HTQXuVPbwCbDCXzY=; b=jleSiuKlgeErsy7+yop1o+kdMmfRLf7Kx99iLUhUz3Se2RvoHLRWjAC4YPCSRAcjRy FzbHwICXKM1B5AuHV1isuwie34CuOQ/1e6D9CUp+7mv/WkZqQn31gu5Sw4yax+SQPzXW PnkRD18dLI3pGnEhJ/QJC0GtJ3BDx0C7/GMIjSfhbm+ewfQgMqqhyj6CKjIsceNRJfQu LKLtiUYV/bMDS+qlQ1tnR9smLgfZZG6/tWltPHE3E82pkRX7BKHMLuNXnt8XBY2C7se1 5c8weQTYZMQtO6c0sLhVI5hsi3jOwy2Zb/GKjD1tb0KNB5JmJ05tmsW99Rly9EGOTzWx UcGg== X-Gm-Message-State: ALoCoQmmfNNGcMlEd9DdAYDiPAqzpykgy6c46U0y8MNxarU96d32Ynn+W+oM63gJJR/PrpnaXN10 MIME-Version: 1.0 X-Received: by 10.182.230.132 with SMTP id sy4mr5640854obc.29.1428105174618; Fri, 03 Apr 2015 16:52:54 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Fri, 3 Apr 2015 16:52:54 -0700 (PDT) In-Reply-To: <201504031933.31280.davemgarrett@gmail.com> References: <201504031933.31280.davemgarrett@gmail.com> Date: Fri, 3 Apr 2015 13:52:54 -1000 Message-ID: From: Brian Smith To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 23:52:56 -0000 Dave Garrett wrote: > TLS 1.2 has: > > Whenever a client already knows the highest protocol version known to > a server (for example, when resuming a session), it SHOULD initiate > the connection in that native protocol. > > TLS 1.3 currently has: > > A client resuming a session SHOULD initiate the connection using the > version that was previously negotiated. These are both bad. The best way for the client to behave is to calculate ClientHello.client_version independently of the session cache. For any full handshake, the client_version should be the best version the client supports. Since the server is allowed to respond to any ClientHello by initiating a full handshake (e.g. because it blew away its session cache), ClientHello.client_version shouldn't be different for ClientHellos that include a session ID or session ticket. Cheers, Brian From nobody Fri Apr 3 16:53: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 D77491AC3D9 for ; Fri, 3 Apr 2015 16:53:21 -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 gf03vyA17OH9 for ; Fri, 3 Apr 2015 16:53:20 -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 AC7061A87E3 for ; Fri, 3 Apr 2015 16:53:20 -0700 (PDT) Received: by ignm3 with SMTP id m3so72081295ign.0 for ; Fri, 03 Apr 2015 16:53:20 -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=WgV2fzv17tsnHyg4Q27PCqKwg/kytcDje6mkKlzSrys=; b=iLS8zO60KLeSQIs67RJnj7x6dR/NXz4E9zc4IuI0sVQ24RypMUztphrc/wxFspSVCZ JYHUTum0LsNxFrA4qF2n+NwONQhAQ7D9nTiTkm0U5ne9r+zlS03RUCeY8jBVLtTqXvqW /i+Wvw0WESpra5jbGp9/pxfbstqlVSFmcIHB8= 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=WgV2fzv17tsnHyg4Q27PCqKwg/kytcDje6mkKlzSrys=; b=gBS7n2HghjJoHVdpxIY7cm2viSkJxB042Un7PQZBdB/J3EHjwVSGg8ME46ay6Jy+yv vBaqVZL2/IXjXWIvc+qrc9PxtF/qBO5gp42c4K010rz1PteTzBY50ivkHcEqRvbRWsA/ iYmFnvn5goHyIY9H8XChiOJJRIo3PzdlaEgB5A+kBwnhs9yhl7y/wado8sizYxua5+yO 6cX8I+zFDYPjwF7kRrW9MC0j4Gp8fhPHLESmHKnzDBO6F+2JvPpWT/NRwcFfjfOzkXEO M30GOaMe5RNuS2ZpJQotRKayhJkhGspO/bAhZBcOosIrEgG+kBbIQKpNSzyzoi318yY0 McYg== X-Gm-Message-State: ALoCoQmCZ/HX/pPKm45+dKzk/qSU0qe9cHnRfZIcpNnRjd6xABGfDFUl0VQ9PTp8nJxltTWueBHF X-Received: by 10.51.17.40 with SMTP id gb8mr8063550igd.44.1428105200173; Fri, 03 Apr 2015 16:53:20 -0700 (PDT) MIME-Version: 1.0 References: <201504031933.31280.davemgarrett@gmail.com> In-Reply-To: <201504031933.31280.davemgarrett@gmail.com> From: David Benjamin Date: Fri, 03 Apr 2015 23:53:19 +0000 Message-ID: To: Dave Garrett , tls@ietf.org Content-Type: multipart/alternative; boundary=001a1134c2e228a0b90512daa7e8 Archived-At: Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 23:53:22 -0000 --001a1134c2e228a0b90512daa7e8 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 7:33 PM Dave Garrett wrote: > TLS 1.2 has: > > Whenever a client already knows the highest protocol version known to > a server (for example, when resuming a session), it SHOULD initiate > the connection in that native protocol. > > TLS 1.3 currently has: > > A client resuming a session SHOULD initiate the connection using the > version that was previously negotiated. > That new version is also unwise and the entire text just be dropped. It means you get stuck at that version even if the server gets upgraded later. It also tends to compound itself with other problems. Maybe you implement a version fallback, but fail to shard the session cache by fallback type (you really really should do that if you have a fallback). Now any spurious callback is sticky and there's no way to get back to the original version unless the session expires on the client. (Expiring on the server doesn't help you any. The damage is done before ServerHello.) I cannot stress enough how much pain and suffering that one little sentence can cause. :-) I ended up completely redoing the version negotiation logic in BoringSSL because of how far OpenSSL takes that advice on the client and how much it breaks. David --001a1134c2e228a0b90512daa7e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 3, 2015 at 7:33 PM = Dave Garrett <davemgarrett@gma= il.com> wrote:
TLS 1.2 has:

Whenever a client already knows the highest protocol version known to
a server (for example, when resuming a session), it SHOULD initiate
the connection in that native protocol.

TLS 1.3 currently has:

A client resuming a session SHOULD initiate the connection using the
version that was previously negotiated.

That new v= ersion is also unwise and the entire text just be dropped.=C2=A0It means yo= u get stuck at that version even if the server gets upgraded later.

= It also tends to compound itself with other problems. Maybe you implement a= version fallback, but fail to shard the session cache by fallback type (yo= u really really should do that if you have a fallback). Now any spurious ca= llback is sticky and there's no way to get back to the original version= unless the session expires on the client. (Expiring on the server doesn= 9;t help you any. The damage is done before ServerHello.)

I cannot s= tress enough how much pain and suffering that one little sentence can cause= . :-) I ended up completely redoing the version negotiation logic in Boring= SSL because of how far OpenSSL takes that advice on the client and how much= it breaks.

David
--001a1134c2e228a0b90512daa7e8-- From nobody Fri Apr 3 16:54: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 7CF281A87E0 for ; Fri, 3 Apr 2015 16:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 WwzW9DGBIBVm for ; Fri, 3 Apr 2015 16:54:38 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003: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 503971A877F for ; Fri, 3 Apr 2015 16:54:38 -0700 (PDT) Received: by obbec2 with SMTP id ec2so186974899obb.3 for ; Fri, 03 Apr 2015 16:54:37 -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=ryAi0SNZEtjg20vog9iks7wZBTcl0k9Lpi+q3+qaYf4=; b=ZL73UfCFwYrmbkYLUUQAo4xbYndbmXuA5N+Shk1CLYNHVG71Q2SW/9eNO3QY9qIN8X VGfnhGKK0K9pZqZCbu9bgiIHeU5yff1LBIgy8OqDFnkZLP/pii0WrMYFgyL2NjSzQ1Sn vbLo7AO0K7rGIv5iIrrKnaou6AAwCqQt136qoes2hz3o3rAjP9ivlfLhmPw74FL58Cvg UPlIN0iTbELxFvGlFUZdBSpLfg777nSJdAu0t8q+UNs9E5ZBr78i3Qhl9HdjuTgrAn+v E9b4Q2tpcC9NhQQv8h4LI6psLBPc0earUrqkcFo44O8XWPlfK/mQN6x7NdCND2zvI7He FnBg== MIME-Version: 1.0 X-Received: by 10.182.210.197 with SMTP id mw5mr5658287obc.26.1428105277777; Fri, 03 Apr 2015 16:54:37 -0700 (PDT) Sender: richmoore44@gmail.com Received: by 10.182.22.51 with HTTP; Fri, 3 Apr 2015 16:54:37 -0700 (PDT) In-Reply-To: <87sich9bar.fsf@alice.fifthhorseman.net> References: <551EB007.2010304@azet.org> <87sich9bar.fsf@alice.fifthhorseman.net> Date: Sat, 4 Apr 2015 00:54:37 +0100 X-Google-Sender-Auth: 8SN9IQnqQ4VHU3rcJZIU_8mz8MI Message-ID: From: Richard Moore To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a11c29be8c8ac560512daabd2 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Killing Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2015 23:54:39 -0000 --001a11c29be8c8ac560512daabd2 Content-Type: text/plain; charset=ISO-8859-1 On 3 April 2015 at 22:01, Daniel Kahn Gillmor wrote: > * not every implementation has a wall clock, or has it set right. > what happens to these machines? > > This problem already exists since you need the time to validate the certificate. Overall though, I'm not in favour of having a set cut off date except perhaps for ciphers we already know are weak, however since the idea is to design a new version of TLS why would things that are known to be weak be included in the first place? Rich. --001a11c29be8c8ac560512daabd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 3 April 2015 at 22:01, Daniel Kahn Gillmor <dkg@fifthhorseman.= net> wrote:
=A0 * not ever= y implementation has a wall clock, or has it set right.
=A0 =A0 what happens to these machines?


This problem already exists since you need = the time to validate the certificate.

Overall though, I'm not in favour of having a set cut off d= ate except perhaps for ciphers we already know are weak, however since the = idea is to design a new version of TLS why would things that are known to b= e weak be included in the first place?

Rich.

--001a11c29be8c8ac560512daabd2-- From nobody Fri Apr 3 17:05: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 104D71ACE04 for ; Fri, 3 Apr 2015 17:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 kAPfqvtvsIIX for ; Fri, 3 Apr 2015 17:05:04 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8B41ACDFA for ; Fri, 3 Apr 2015 17:05:04 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so103112251obb.2 for ; Fri, 03 Apr 2015 17:05:04 -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=IRVSL+sTO/ezH0jwe1+QdTQ4iYctgYZ6h2ktWnkaW4I=; b=WwCPoOFXMlO+49c+gxydk3dq5/ld8orCKOoVaeo95z/LqrPJn578kVBGOw8aUvd43g FobiVoR1uNed4d5OR3e6QQAGk35hXbNJzex6LH5o4Th2I9MjVvHK25qCZ8C4HckT1FyR 4zk8i7BzUyGR7zBiTLPY8nc+ANXNgzS7hN645FhxWxrJdfBUXMNbGbL29yMVXNlqUleo 4G7sMNZz2jGumMvuvHEoLS1zZc6gxLKHxy+WwyUHX3VwvGhrqffxe6Aa1/BYntkIXxc5 Z6xcV3ANcpsqE3D5WqUuPL+eo3u3eObE7YpHMUyfzv3tlA9T9FbS6wYr8BP1AjsCJuS3 nD0g== X-Gm-Message-State: ALoCoQk3iMtUUEG1DUVBj1x7WE3DZkiTsUlFHZ22YR8+s+nfYPzijCRPs80ij/5e2b1un9Udo+cN MIME-Version: 1.0 X-Received: by 10.60.82.10 with SMTP id e10mr5678532oey.85.1428105903995; Fri, 03 Apr 2015 17:05:03 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Fri, 3 Apr 2015 17:05:03 -0700 (PDT) In-Reply-To: <551DE914.4010804@nthpermutation.com> References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> Date: Fri, 3 Apr 2015 14:05:03 -1000 Message-ID: From: Brian Smith To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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: Sat, 04 Apr 2015 00:05:06 -0000 Please don't change the syntax for negotiating cipher suites. Although it seems like a good idea to try to make things simpler conceptually by negotiating the different components of the cipher suite differently, it would take a lot of effort to standardize a new way of doing things. I don't think the current mechanism is problematic enough (at all, really) to justify that effort. Also, any new mechanism is going to make any implementation more complicated--and thus more more-prone--if it also has to support older versions of TLS. Again, I don't think that extra complication is warranted. Finally, there are a lot of reasons to avoid wasting bytes in the ClientHello message, for improved compatibility. Having two cipher suite negotiation mechanisms in the ClientHello, one for TLS 1.3+ and one for earlier versions, would likely be counter to that goal. Cheers, Brian From nobody Fri Apr 3 17:19: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 B0DB91A87CC for ; Fri, 3 Apr 2015 17:18:57 -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 HZawHKcuPfwa for ; Fri, 3 Apr 2015 17:18:55 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003: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 8F9271A87C2 for ; Fri, 3 Apr 2015 17:18:55 -0700 (PDT) Received: by obvd1 with SMTP id d1so188791626obv.0 for ; Fri, 03 Apr 2015 17:18: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:from:date:message-id:subject:to :cc:content-type; bh=41MxmRbD/j7N0oraviT+UcWDhNYS+vX5U4/3yJd+izk=; b=HQS0Z0ExT/S23Or0klyOv0cUjYCXyb29wq149ZURp0NS8yD+6qHU+YDd13e8zg/YzY M4jnsBXWu7pgo5ziFuKGhX97VoMURmsfxoG7jKT6LGjiwN9Gc/R3uTcdOmDYnwNKgpn0 7Nh1r0+7pGaPpm213MnYBavJIcj48IyEM1MZfeu7x9PFwDKQ9CedmbwV1UU1nb8S7QcK 1GEiKUHO1PpzpVHLQK74Qfv3sCtAX5ifZQtK7ey7+gFlDP8uP7GfgiDjfqqB2KaBeZGd HPIzGK7cCi5bMzO6zc/XB3N9zxtoGJvrZUrmU9cjeDSJepHkr1noeaL5NkISfdWZtwmb U/Ag== X-Received: by 10.60.179.227 with SMTP id dj3mr5580815oec.29.1428106735103; Fri, 03 Apr 2015 17:18:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.166.232 with HTTP; Fri, 3 Apr 2015 17:18:34 -0700 (PDT) In-Reply-To: References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> From: Tony Arcieri Date: Fri, 3 Apr 2015 17:18:34 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=047d7bd6b21aa5b7c10512db0286 Archived-At: Cc: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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: Sat, 04 Apr 2015 00:18:57 -0000 --047d7bd6b21aa5b7c10512db0286 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 5:05 PM, Brian Smith wrote: > Please don't change the syntax for negotiating cipher suites. Although > it seems like a good idea Personally I think it's a great idea, and a pretty simple one and also an incredibly needed one. In fact, this post and its ensuing discussion actually made me excited about TLS 1.3: https://mailarchive.ietf.org/arch/msg/tls/JZoIXZMRg80-tDC23kt5BL0nQaQ If you read through the suggestions, I think a new syntax could actually be backwards compatible in terms of computing the possibility matrix / combinatorial explosion of all authentication and (symmetric) encryption ciphers/ciphersuites. I think this sort of approach sorts out a lot of collusion and confusion (not in the Claude Shannon sense) which has been lingering in TLS for years. --047d7bd6b21aa5b7c10512db0286 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 5:05 PM, Brian Smith <brian@briansmith.org> wrote:
Please don't change the syntax for neg= otiating cipher suites. Although
it seems like a good idea

Personally I thin= k it's a great idea, and a pretty simple one and also an incredibly nee= ded one. In fact, this post and its ensuing discussion actually made me exc= ited about TLS 1.3:


=
If you read through the suggestions, I think a new syntax could actual= ly be backwards compatible in terms of computing the possibility matrix / c= ombinatorial explosion of all authentication and (symmetric) encryption cip= hers/ciphersuites.

I think this sort of approach s= orts out a lot of collusion and confusion (not in the Claude Shannon sense)= which has been lingering in TLS for years.
--047d7bd6b21aa5b7c10512db0286-- From nobody Fri Apr 3 17:34: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 F06F51A8894 for ; Fri, 3 Apr 2015 17:34:32 -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 sfdTU3iPYnh0 for ; Fri, 3 Apr 2015 17:34:31 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003: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 77A9C1A888B for ; Fri, 3 Apr 2015 17:34:31 -0700 (PDT) Received: by obbec2 with SMTP id ec2so187628453obb.3 for ; Fri, 03 Apr 2015 17:34:31 -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=XP1Dv+N5sXl61nEdkRI9aUesdmCgjEifS0mS5OIFkC8=; b=LgTtbS05wFCYXg6xOWCKsucyDkh2LkaTeQ8aop5pmuCqiSbIN+gytsaMezU5yjTjzQ 1qpIZMg+NTESQzipZ05hEaPPfqiCgMrXWZ2RWzrHDiqg/FSPHNmUJIL4KSG3NlcAWXrY 3NFId/kXiU2ou2+7F/0zb5GQJ7/JXbi6zPeOUwn9+NvfxyScqM/vLBTwd4G+zKNBKyhj Gw/Nw/ylzfy8EJ2stJMpJiGd/6DDW9bOFwCgDZjv3BPff5D/dZGxTikbXPlCDYAhG+eQ ybWyvoxXdL81ce9j3W+r3l3ZUvoNYcyWchqxk+XKh0ZNVfYiQmc06rh1Sh5JyAa/nSqI XdCQ== MIME-Version: 1.0 X-Received: by 10.60.131.37 with SMTP id oj5mr5643392oeb.77.1428107671047; Fri, 03 Apr 2015 17:34:31 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Fri, 3 Apr 2015 17:34:31 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Apr 2015 17:34:31 -0700 Message-ID: From: Martin Thomson To: Joseph Salowey Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 00:34:33 -0000 WFM On 3 April 2015 at 13:34, Joseph Salowey wrote: > In the interim meeting we had consensus to use an implicit IV for AEAD. The > proposal was to use the record sequence number and pad with zeros as > described in pull request 155 > (https://github.com/tlswg/tls13-spec/pull/155/files). This was also > discussed in the IETF-92 meeting in Dallas along with options to change the > offset. The consensus was to stay with the original proposal. We are > posting to the mailing list to confirm this consensus. If you have comments, > please reply by April 17, 2015. > > Thanks, > > S&J > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Apr 3 17:37: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 C91C01A8894 for ; Fri, 3 Apr 2015 17:37: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 UDjL8hSWuws2 for ; Fri, 3 Apr 2015 17:37:07 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD601A888B for ; Fri, 3 Apr 2015 17:37:07 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so181135423obb.1 for ; Fri, 03 Apr 2015 17:37:07 -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=3IGN3svSjAue2Yfk02DnNeKOF/QvyDPH1FkLcxlxrz8=; b=Mor+gdr2gq1oqgNhydJymHAmB2q2yrxsi4UImwLwpnWvnI8FBAYT3T16HcgNpvz5uR b2O7ns+ImTM9mHbWVZgXC5Qg2cdlnKcdbBtimTqZlgiX80A1rvNZZBhT7PK2cFg9fJEY uj4uSi4s8kDhnp5Ck2KCXqywfM2+BX26dufDr4aYHM0+iLngAz3sqNgRMPOFoI+xu6ZT vhiqeXSukTtVOI1/pHphV+hHiItGHGW+b09EP/uAQmlMt5WW2ulUKpBm9ZOCDnJVk7Dd vFpeWAgIg6rQgXnoFKv4a6gjRYfcuYMuyZGqHnOS/hujF7Zd2reUx1iuJvuKx2gGCdT+ vNBQ== MIME-Version: 1.0 X-Received: by 10.60.132.33 with SMTP id or1mr5846256oeb.82.1428107827280; Fri, 03 Apr 2015 17:37:07 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Fri, 3 Apr 2015 17:37:07 -0700 (PDT) In-Reply-To: References: <201504031933.31280.davemgarrett@gmail.com> Date: Fri, 3 Apr 2015 17:37:07 -0700 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 00:37:08 -0000 On 3 April 2015 at 16:53, David Benjamin wrote: > That new version is also unwise and the entire text just be dropped. It > means you get stuck at that version even if the server gets upgraded later. Yep. I recently landed a change in NSS that does exactly this. That risks badness with servers that didn't do what Brian suggested (your option 3), but our assessment (advised by telemetry) was that the probability of that was low enough. From nobody Fri Apr 3 17:40: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 E2DD41A88B2 for ; Fri, 3 Apr 2015 17:40: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 sa2qbOv26f6B for ; Fri, 3 Apr 2015 17:40:02 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003: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 855BB1A88B0 for ; Fri, 3 Apr 2015 17:40:02 -0700 (PDT) Received: by obvd1 with SMTP id d1so189122617obv.0 for ; Fri, 03 Apr 2015 17:40:02 -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=o1BYBvuRqDAPpWR+7SR20eihh+JigMLvVgSb+Lxj4hU=; b=kEnJjk9RmeyQtfZYAtgsUp32U2pHQbReBBmKLe0I4+jgHZOTZU3Ny0H4Sw+d3LmQ9/ IdoLiaRc7tI5J4xbfiqgVN+DQcUtXRd70ZcqJ34w+VTll1vLM1lAUo1D8Hm2IYuZaY/6 P1pOqywYIDGHnFcveePTxcRLY9KCrzO4GQo0zHVPSA5bNgPYCqGDbMNEwP5Y664i3evh qkD5zJfN8YMi0EwSA27MdewIDPuFrpkvDU0u8fvCuIjw7Q+Dh+5u14T3og7WJIzRXqzV aqfZp1clbaQCL18e2P95J+FE8Xcn30TPzYjnJEIzKG9IH+x1+IR++gMaAymdSlIn9yOI XotQ== MIME-Version: 1.0 X-Received: by 10.60.155.135 with SMTP id vw7mr5731496oeb.62.1428108002130; Fri, 03 Apr 2015 17:40:02 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Fri, 3 Apr 2015 17:40:02 -0700 (PDT) In-Reply-To: References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> Date: Fri, 3 Apr 2015 17:40:02 -0700 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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: Sat, 04 Apr 2015 00:40:04 -0000 On 3 April 2015 at 17:05, Brian Smith wrote: > I don't think the current mechanism is problematic > enough (at all, really) to justify that effort. I think that I've the same view. Then you have to consider interaction problems where some implementations have hardware for certain things, and software for others. Not only does that produce strong preferences for some things over others, it also can lead to holes in support tables, making a la carte selection tricky. That was always the clincher for me. From nobody Fri Apr 3 17:45: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 A79B61A88BA for ; Fri, 3 Apr 2015 17:45:55 -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 IrQ9zWpPRYn9 for ; Fri, 3 Apr 2015 17:45:54 -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 5222C1A88B2 for ; Fri, 3 Apr 2015 17:45:54 -0700 (PDT) Received: by qcbii10 with SMTP id ii10so75962875qcb.2 for ; Fri, 03 Apr 2015 17:45: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=woZj8rBbEMww48ky5dKrwIUMfX7/X81A0cp8+1IZsSo=; b=gyQeiEyjVnjgxZqI4nFdmtOu6Yah9Ubf0l7eGlP0+XGDj0m/qbVGZsPgRE+U8hL7sr SbQVbeM/u5FMStBG2yRA684NHe47gvdEsVrWuSkrVWK0N28fZhKw68doYyLNifvqoN2H +rQ0PCdu2n0F34FD/Q9GEGPfI+KgUjUFaXHxpRqWKe1WbyKeFPgt5VUqI3fg4uOtmF// uKP+hhSUoznVEuYIaB1Eotk4wK+bHNZ/hkpQPRIs27360Y7cGpvxVAYlzzxZkI4f4sPQ fUrnTUe5GfohD2p2kKtz6CfUeFcsV9vMvJFbXfTvz7nxucw3p6sKYOXH6zvzxrXI+MNl ywAA== X-Received: by 10.55.53.21 with SMTP id c21mr8994234qka.40.1428108353619; Fri, 03 Apr 2015 17:45: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 69sm6750602qkr.41.2015.04.03.17.45.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Apr 2015 17:45:53 -0700 (PDT) From: Dave Garrett To: David Benjamin Date: Fri, 3 Apr 2015 20:45:52 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504031933.31280.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504032045.52429.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 00:45:55 -0000 On Friday, April 03, 2015 07:53:19 pm David Benjamin wrote: > On Fri, Apr 3, 2015 at 7:33 PM Dave Garrett wrote: > > TLS 1.2 has: > > > > Whenever a client already knows the highest protocol version known to > > a server (for example, when resuming a session), it SHOULD initiate > > the connection in that native protocol. > > > > TLS 1.3 currently has: > > > > A client resuming a session SHOULD initiate the connection using the > > version that was previously negotiated. > > That new version is also unwise and the entire text just be dropped. It > means you get stuck at that version even if the server gets upgraded later. I'd certainly support dropping it and putting in very clear resumption instructions with no SHOULDs like this. I just left it in as it was generally outside the scope of the updates I was doing, and there's an open issue filed for it. Dave From nobody Fri Apr 3 18:21: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 A91CB1A1A9A for ; Fri, 3 Apr 2015 18:21:11 -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 mTpHXmz_0Tjh for ; Fri, 3 Apr 2015 18:21:09 -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 820BE1A1A88 for ; Fri, 3 Apr 2015 18:21:09 -0700 (PDT) Received: by qgfi89 with SMTP id i89so19911716qgf.1 for ; Fri, 03 Apr 2015 18:21:08 -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=i2QHbxef2mJwmo539Fc/5C/Ae4kYj6RWauzTfqFln9w=; b=d7oKpL+/V6wBmFszEedCI1sF/xZBwU8wGP7ItZYqe/2EA3TaMQx7YSCFb9/xDUbjuU xs/LU29A1cvuu8nGWtlXfi9c4ArMxByucM1CCUQA1/QxfQ7hq1xZfdMTs1IvvE0l0zH4 pwsJ5WjYbjVn6V2RiK9yvBS0y03u28dvEViFSNSfeqsKc3lFmwJQaKozalQBS/9DSTIZ vFN7K9FezwqsxgOQtzoD04tY3jPm4OXvDyWLb7CrFz4v7X0mfOJfdnOTP0I54e7Dqer4 JYphKuyN3AWJVsPCd4WxbyOr8W2y37QqFonrw8FC6YHLcZAMfqp8WP+Q5iCSqG2EjJkq 9N+g== X-Received: by 10.140.20.99 with SMTP id 90mr4766929qgi.87.1428110468774; Fri, 03 Apr 2015 18:21:08 -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 10sm6806319qha.38.2015.04.03.18.21.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Apr 2015 18:21:08 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 3 Apr 2015 21:21:07 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150401201221.163745c2@pc1.fritz.box> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504032121.07726.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Ala Carte Cipher suites - 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: Sat, 04 Apr 2015 01:21:11 -0000 On Friday, April 03, 2015 08:18:34 pm Tony Arcieri wrote: > On Fri, Apr 3, 2015 at 5:05 PM, Brian Smith wrote: > > Please don't change the syntax for negotiating cipher suites. Although > > it seems like a good idea > > Personally I think it's a great idea, and a pretty simple one and also an > incredibly needed one. In fact, this post and its ensuing discussion > actually made me excited about TLS 1.3: > > https://mailarchive.ietf.org/arch/msg/tls/JZoIXZMRg80-tDC23kt5BL0nQaQ > > If you read through the suggestions, I think a new syntax could actually be > backwards compatible in terms of computing the possibility matrix / > combinatorial explosion of all authentication and (symmetric) encryption > ciphers/ciphersuites. > > I think this sort of approach sorts out a lot of collusion and confusion > (not in the Claude Shannon sense) which has been lingering in TLS for years. On Friday, April 03, 2015 08:40:02 pm Martin Thomson wrote: > On 3 April 2015 at 17:05, Brian Smith wrote: > > I don't think the current mechanism is problematic > > enough (at all, really) to justify that effort. > > I think that I've the same view. > > Then you have to consider interaction problems where some > implementations have hardware for certain things, and software for > others. Not only does that produce strong preferences for some things > over others, it also can lead to holes in support tables, making a la > carte selection tricky. > > That was always the clincher for me. After the initial discussion, the middle point between the current system and my initial "just dump it all in a pile" idea (which Nico more elegantly named a la carte), is just to split cipher suites into symmetric and asymmetric suites. The one for the handshake and one for the connection would be negotiated separately. This could work rather well without too much change. That said, how much combinatorial explosion are we even dealing with anymore? We ditched all non-ephemeral handshakes. There's fewer variations now, at least at the moment. A non-hypothetical example: https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-02#section-3 OCB wants to define in its current draft: CipherSuite TLS_DHE_RSA_WITH_AES_128_OCB = {TBD1, TBD1} CipherSuite TLS_DHE_RSA_WITH_AES_256_OCB = {TBD2, TBD2} CipherSuite TLS_ECDHE_RSA_WITH_AES_128_OCB = {TBD3, TBD3} CipherSuite TLS_ECDHE_RSA_WITH_AES_256_OCB = {TBD4, TBD4} CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_OCB = {TBD5, TBD5} CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_OCB = {TBD6, TBD6} CipherSuite TLS_PSK_WITH_AES_128_OCB = {TBD7, TBD7} CipherSuite TLS_PSK_WITH_AES_256_OCB = {TBD8, TBD8} CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB = {TBD9, TBD9} CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB = {TBD10, TBD10} CipherSuite TLS_ECDHE_PSK_WITH_AES_128_OCB = {TBD11, TBD11} CipherSuite TLS_ECDHE_PSK_WITH_AES_256_OCB = {TBD12, TBD12} If we just split handshake from connection, it would just be: defined in TLS 1.3/2.0 spec: CipherSuite TLS2_DHE_RSA = TBD CipherSuite TLS2_ECDHE_RSA = TBD CipherSuite TLS2_ECDHE_ECDSA = TBD CipherSuite TLS2_PSK = TBD CipherSuite TLS2_DHE_PSK = TBD CipherSuite TLS2_ECDHE_PSK = TBD (by the way, do we really want plain PSK?) and OCB would only need to define: CipherSuite TLS2_AES_128_OCB = TBD CipherSuite TLS2_AES_256_OCB = TBD That's already fewer suites. All new ciphers would only need to define one or two suites, as the 6 handshakes would be common to all. It'd be a hell of a lot easier to configure and negotiate into the future. We already add weird SCSV fake suites, so adding a few newly handled ones shouldn't break the world. Just splitting it into only two parts would avoid the risk of support holes you'd get with the full a la carte route. There's plenty of space in the registry to keep adding piles and piles of variations for each suite, but I have seen actual instances where a server and client actually do support the same handshake and connection ciphers in TLS 1.2, but don't negotiate it because the specific combination isn't listed. The current system does lead to some support holes as-is. Dave From nobody Fri Apr 3 19:05: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 E78281A87C3 for ; Fri, 3 Apr 2015 19:05:07 -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 i0WdFpsFGu0h for ; Fri, 3 Apr 2015 19:05:06 -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 450A31A87B2 for ; Fri, 3 Apr 2015 19:05:06 -0700 (PDT) Received: by wgbdm7 with SMTP id dm7so122607365wgb.1 for ; Fri, 03 Apr 2015 19:05: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=5bJzRPCmGBS3YbehUA46HJVJhkeWRdk4bBcRDBFAjYs=; b=jCfQJTIClleA4rul+FhfCjfD9oyA9bmR+ayzBTU/IZHUWv9GM1hQd74rh1pCqe+ZKh okaQ93szFc0OwjZriftZT6YLqRqpKrnY0bCC5G2tVYvdecN/4VBWzJWq0NwzbEhj9VBv 78d+htTo2Y8lFO61qVBoCg2p3Vmtc55/2MC5Gmm9rcpSc1cAWLOIHdH03r1NJJDgcci0 oUEZ5EQoSSagd5/u1hlv/EPb2kAr2tQanTuC6Ps6momV7OolgoA/O+olSoq8mM2BKdmm kC1OgnVxplQHm6FIUwc9cux+2b2fwq2gTr7bAy5SATMsyK1zLA0UIAp9UG+EDN8olqyY TF4w== MIME-Version: 1.0 X-Received: by 10.180.84.198 with SMTP id b6mr38719425wiz.25.1428113105088; Fri, 03 Apr 2015 19:05:05 -0700 (PDT) Received: by 10.194.5.97 with HTTP; Fri, 3 Apr 2015 19:05:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Apr 2015 22:05:05 -0400 Message-ID: From: Daniel Migault To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d0418264a53f4fe0512dc7ecf Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 02:05:08 -0000 --f46d0418264a53f4fe0512dc7ecf Content-Type: text/plain; charset=UTF-8 Fine to me. BTW how do you position this toward FIPS/NIST Cryptographic Module Validation program? On Fri, Apr 3, 2015 at 8:34 PM, Martin Thomson wrote: > WFM > > On 3 April 2015 at 13:34, Joseph Salowey wrote: > > In the interim meeting we had consensus to use an implicit IV for AEAD. > The > > proposal was to use the record sequence number and pad with zeros as > > described in pull request 155 > > (https://github.com/tlswg/tls13-spec/pull/155/files). This was also > > discussed in the IETF-92 meeting in Dallas along with options to change > the > > offset. The consensus was to stay with the original proposal. We are > > posting to the mailing list to confirm this consensus. If you have > comments, > > please reply by April 17, 2015. > > > > Thanks, > > > > S&J > > > > _______________________________________________ > > 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 > -- Daniel Migault Ericsson --f46d0418264a53f4fe0512dc7ecf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fine to me. BTW how do you position this toward FIPS/= NIST Cryptographic Module Validation program?


On Fri, Apr 3, 2015 at 8:34= PM, Martin Thomson <martin.thomson@gmail.com> wrote:=
WFM

On 3 April 2015 at 13:34, Joseph Salowey <joe@salowey.net> wrote:
> In the interim meeting we had consensus to use an implicit IV for AEAD= .=C2=A0 The
> proposal was to use the record sequence number and pad with zeros as > described in pull request 155
> (https://github.com/tlswg/tls13-spec/pull/155/files).=C2=A0 = This was also
> discussed in the IETF-92 meeting in Dallas along with options to chang= e the
> offset.=C2=A0 The consensus was to stay with the original proposal.=C2= =A0 We are
> posting to the mailing list to confirm this consensus. If you have com= ments,
> please reply by April 17, 2015.
>
> Thanks,
>
> S&J
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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



--
Daniel Migault
Ericsson
--f46d0418264a53f4fe0512dc7ecf-- From nobody Fri Apr 3 19:07: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 D05D41A87EA; Fri, 3 Apr 2015 19:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 15Pty0aSghrt; Fri, 3 Apr 2015 19:07:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA711A87B2; Fri, 3 Apr 2015 19:07:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150404020709.31136.3025.idtracker@ietfa.amsl.com> Date: Fri, 03 Apr 2015 19:07:09 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] Last Call: (Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@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, 04 Apr 2015 02:07:11 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 3 19:54: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 0FD511A8904 for ; Fri, 3 Apr 2015 19:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 b4XnDTu8zW6G for ; Fri, 3 Apr 2015 19:54:36 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99EA11A88F3 for ; Fri, 3 Apr 2015 19:54:36 -0700 (PDT) Received: by obbec2 with SMTP id ec2so189761458obb.3 for ; Fri, 03 Apr 2015 19:54: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:date :message-id:subject:from:to:cc:content-type; bh=nseJDSGPDK3H/Xp1GfH52TqEPObMwOf96Sxkssryhcg=; b=D+JFe9yaMXNjudVy/W5jLVOQBCKpxvNi5+V0EMy3ny+FdOVzBQuA8xupgIDhyWiVth iGzIWGKHGTP+of8dlx53tF28uanf3wJB6Oaa0zOjz3CVHICh95yn2t2O0Q2WhHfBPhtc wy0/9JQ82VQMGQ/W4akEALUdu+M6ZUm2txzKOLoLdiZM/vvEPRGw/wEexNK/NYbgxK3f U4wNckalpLg4g/nTR0FlUqj5q6OdZ3Sr4FheiETHEz/ZLXgpyg99VKd7UzFnIEKDGQES GytiWqewBXgi39DVQ+QhwGTs4mY9hKwpPKT33j2aA4dLU81yw4+YgknTqhY0G4r8uRcS i09g== X-Gm-Message-State: ALoCoQkg/V0TFnhL76oMd0GONiF3dgTS6r2wU+MuutkCxbwHPyHYi+mj7wjAItZ1GiAiVamDMb5N MIME-Version: 1.0 X-Received: by 10.60.160.236 with SMTP id xn12mr6197611oeb.53.1428116076077; Fri, 03 Apr 2015 19:54:36 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Fri, 3 Apr 2015 19:54:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Apr 2015 16:54:36 -1000 Message-ID: From: Brian Smith To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 02:54:38 -0000 David Benjamin wrote: > I agree #3 is the most natural. The behavior for a server is then: > 1. Based on client_version, select a protocol version. > 2. Look up session based on session_id or ticket. > 3. If the version the session was established at does not match the > negotiated version, pretend the lookup failed. > 4. Do a full or abbreviated handshake based on whether other properties of > the session check out (cipher suite still allowed, etc.). > Otherwise, #1 probably works too, though OpenSSL doesn't store the > client_version. I think I mostly see that as the client's responsibility; > session resumption skips negotiation of lots of parameters, so you already > have to be aware of handling this when your half of preferences change. Agreed. > A server SHOULD flush its session cache and invalidate tickets when > changing cipher preferences I think implementing your step #4 above is better than relying on such flushing, because in a setup where multiple servers are sharing a session cache, the flushing would likely be racy, and/or the individual servers may be configured differently--either temporarily as a setting change propagates across a set of servers, or permanently due to some (mis)configuration issue. > a client SHOULD shard the session cache by fallback > type, etc. Alternatively, the client should avoid doing any fallback at all. If it has to do fallback for some reason, it could also avoid the issue by avoiding session resumption during fallback. Cheers, Brian From nobody Fri Apr 3 20:17: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 08C371A892F for ; Fri, 3 Apr 2015 20:17: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, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tE7xDDKZbhJ for ; Fri, 3 Apr 2015 20:17:05 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.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 9A53C1A892E for ; Fri, 3 Apr 2015 20:17:05 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so106064070obb.2 for ; Fri, 03 Apr 2015 20:17: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=YJqpKfI4IbHuRoHlhUJ1Q6BKSzVJR0D+OUlkOXvCD/Q=; b=UUrl3Rdlw5BcdoX5UMPJdJQqFeEKBalokI9gLcY6MBw32l9blBpG9lTevLCG2I+OkT p/ZsgkPinkNXEkKFS6L5MeY1vv221zvSW6fvJSTfVc3+Y52k9juObmAe863v5q2DvDJr 3905o7Dr7zO0P92V6mwDqYj78gOmLw2P2k4lZr0sy53Ob/5ynEUT7LT+UeE4w/lB0qKL 8kEmTHDh/gTURQqGTwdnIZbZhDb7BfXuBLKPIHs3ICnbjl7ik/MqyGeSywsXFGpAr8Kf tNzf5I+u7ZgflgenzMxASfb6mc83Whz34hxhevBbqndhyWTl5JBufWDMA0axEJck/W/x KMyw== X-Gm-Message-State: ALoCoQnJHiMiDfVK9KVmtKcnNdDvzBjOujngivAuz1qn7DiM5PaNEmatordtmbt1nu36O4ng+54i MIME-Version: 1.0 X-Received: by 10.182.24.202 with SMTP id w10mr6290915obf.9.1428117425040; Fri, 03 Apr 2015 20:17:05 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Fri, 3 Apr 2015 20:17:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Apr 2015 17:17:04 -1000 Message-ID: From: Brian Smith To: Joseph Salowey Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 03:17:07 -0000 Joseph Salowey wrote: > In the interim meeting we had consensus to use an implicit IV for AEAD. The > proposal was to use the record sequence number and pad with zeros as > described in pull request 155 > (https://github.com/tlswg/tls13-spec/pull/155/files). This was also > discussed in the IETF-92 meeting in Dallas along with options to change the > offset. The consensus was to stay with the original proposal. We are > posting to the mailing list to confirm this consensus. If you have comments, > please reply by April 17, 2015. Right now, based on my reading of the draft minutes, it doesn't look like there was a complete, reasoned discussion of the issue during IETF 92, nor is it clear to what extent any kind of consensus or agreement was expressed during the meeting. Perhaps the draft minutes are incomplete, but the statement that there was a consensus to stay with the original proposal doesn't seem consistent with draft minutes. Conversely, there is a clear record of my objection to the zero-padding mechanism on the mailing list, and there seems to be at least some mild support for my suggested alternative of deriving the initial nonce from the keyblock. I think I provided a good justification for moving to the randomized initial nonce. I think that the concerns about it being more work to support a randomized nonce in crypto modules that attempt to enforce a cryptographic boundary are valid,m but those concerns outweigh the security benefits of starting with a randomized nonce. I would be happy to work with the people who expressed that concern to show that a randomized initial nonce can work well and isn't unreasonably burdensome even in such products. I've also thought of another reason why it seems useful to start with a randomized initial nonce: As mentioned previously on this list, in reality many AES-GCM implementations are far from being constant-time. As far as I can reason, AES-GCM with predictable nonces, combined with predictable plaintext and/or chosen plaintext, seem more likely to attack via side channel attacks than AES-GCM with randomized nonces. This is another significant advantage of randomization. Finally, Ilari Liusvaara noted in the previous thread on the topic that SSH already does exactly what I'm proposing, or very similar. And, he also noted that IPSEC partially randomizes the nonce, as does TLS 1.2. It seems like zero padding would be a regression from what TLS 1.2 does, in terms of security. I find that concerning. Here's exactly what Ilari Liusvaara wrote in [1]: > As to what other protocols do with GCM, both SSH and IPSec do derive > initial nonce out of key block (like TLS 1.2 does). [...] > As to what other protocols do with GCM, SSH derives a full block and > increments that. IPSec derives just a prefix (like TLS 1.2). Cheers, Brian [1] https://www.ietf.org/mail-archive/web/tls/current/msg15578.html From nobody Fri Apr 3 20:24: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 9D1411A8935 for ; Fri, 3 Apr 2015 20:24:07 -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 N3VRURMb2hNB for ; Fri, 3 Apr 2015 20:24:06 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 68A761A8934 for ; Fri, 3 Apr 2015 20:24:06 -0700 (PDT) Received: by igblo3 with SMTP id lo3so18829128igb.0 for ; Fri, 03 Apr 2015 20:24:05 -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=hj4RfH70wd5AomQlhegFdbjA382d9UpZGVoMWTrElrM=; b=XxL8i5MiSBNFAWA0rQVOIOaLqDNN7dbj1sJzeB9tE9BDZYAhptNXR7l++cgTW4FfOW CHD2l7iRYt1K8hgmzhjaJ5GzfliXTbIvLJXVP2gUIt1uZDDiZ0KJqWS2cnWJF4aClV9+ nLRF4vfRZsy42SQ/omi6Jrl10U0fuQCkLKFME= 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=hj4RfH70wd5AomQlhegFdbjA382d9UpZGVoMWTrElrM=; b=N5A4LVtSJ06f+yN8IbTrA5AfvvP3fO7lF9h/FpeUydcOvVs1VVZGIBA40RuS3Hmd7G QLycGwit/SlaF9+uARRNANpdoq9uUyt4qBtQ18WL3wkLcz6D5IKfCzH8nm5H8rHZlg7P 4fbktqG3wIu1N3/Hvy5o9PnRLMJ4xucgqp1MMyHhkVhLcYg+V8EYwe5KpSCnHyXgZGTp k0k/hWQ/e0nzIsfqxMerlurXih+750YiCMllk49yWf2UMh42XY/RPc5zqAqh0TZvO7p6 l7N0wPNo42LZOG+4EjLwQFDJwlHqgdGca1AJ3IClx2TqjWmwFVIhN5CGi6mDYIE3omQW cRRg== X-Gm-Message-State: ALoCoQnHSxW4no7ouwsGBJGRmUaVaqpKAwsPfNPP+F6myWEyjHAl95Zh4SxORvw5LR5PnENc4dpM X-Received: by 10.107.136.158 with SMTP id s30mr8160966ioi.65.1428117845821; Fri, 03 Apr 2015 20:24:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Sat, 04 Apr 2015 03:24:04 +0000 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a113eb318e606030512dd98c6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Interaction between session resumption and negotiated protocol version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 03:24:07 -0000 --001a113eb318e606030512dd98c6 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 10:54 PM Brian Smith wrote: > David Benjamin wrote: > > A server SHOULD flush its session cache and invalidate tickets when > > changing cipher preferences > > I think implementing your step #4 above is better than relying on such > flushing, because in a setup where multiple servers are sharing a > session cache, the flushing would likely be racy, and/or the > individual servers may be configured differently--either temporarily > as a setting change propagates across a set of servers, or permanently > due to some (mis)configuration issue. > > > a client SHOULD shard the session cache by fallback > > type, etc. > > Alternatively, the client should avoid doing any fallback at all. If > it has to do fallback for some reason, it could also avoid the issue > by avoiding session resumption during fallback. > Well, yes. Fallback was just the first example that popped into my head, hence the "etc". Mentally substitute a different one if you really prefer. :-P More generally, connections made with different configurations should use separate session caches (on either server or the client). (And, yeah, if your server is multi-homed or whatever when you'd have to care about races, you'd need to treat it as separate session caches. Flushing is a special case of that when only one cache is active at a time.) David --001a113eb318e606030512dd98c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 3, 2015 at 10:54 PM= Brian Smith <brian@briansmith.o= rg> wrote:
David Benjamin <davidben@chromium.or= g> wrote:
> A server SHOULD flush its session cache and invali= date tickets when
> changing cipher preferences

I think implementing your step #4 above is better than relying on such
flushing, because in a setup where multiple servers are sharing a
session cache, the flushing would likely be racy, and/or the
individual servers may be configured differently--either temporarily
as a setting change propagates across a set of servers, or permanently
due to some (mis)configuration issue.

> a client SHOULD shard the session cache by fallback
> type, etc.

Alternatively, the client should avoid doing any fallback at all. If
it has to do fallback for some reason, it could also avoid the issue
by avoiding session resumption during fallback.

Well, yes. Fallback was just the first example that popped into my head,= hence the "etc". Mentally substitute a different one if you real= ly prefer. :-P More generally, connections made with different configuratio= ns should use separate session caches (on either server or the client).
=

(And, yeah, if your server is multi-homed or whatever when you= 9;d have to care about races, you'd need to treat it as separate sessio= n caches. Flushing is a special case of that when only one cache is active = at a time.)

David
--001a113eb318e606030512dd98c6-- From nobody Fri Apr 3 21:01: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 E59F81A8965 for ; Fri, 3 Apr 2015 21:01: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 aof_JypBnzN2 for ; Fri, 3 Apr 2015 21:01:28 -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 B0AA21A894E for ; Fri, 3 Apr 2015 21:01:28 -0700 (PDT) Received: by qgeb100 with SMTP id b100so62758173qge.3 for ; Fri, 03 Apr 2015 21:01: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=w4luTVhz6xOkT7ZRNZnBTHVrmaTRz4x2uk0y0mb2HiY=; b=bzRwXLeuaaLLI0VatlB0ocLRtf6DO/dZtAgtUN6t7PxNoYwiK3Y1JRs0mzRsYOY2Jh tybOdBMwA3YkFmvV0eivXXzt+FX4sk9vDV9jZRkMvvqP8BqTOrRfFePgPh1UBZvHjTn0 GWW6oz38tYmYkqK0s1bBkGIDKqBLV39gXquH2nNno7+N14qCng+o2vqXJ4uxZpcz7akb 9CrUBHo+ci4cUdh1pUmSrtPBlVXEdhSaWWuPlau/Y1yUIVBNvAS0T5ke8XOO4d7ENu6u eU3IyhG/usa5KIMfnaUcdeLlwPEbvfkkGxVlqA1+qx4FGNSeLGE5yIi7uNFFrKklG8q3 KqDg== X-Received: by 10.140.131.79 with SMTP id 76mr6329037qhd.57.1428120088027; Fri, 03 Apr 2015 21:01: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 c80sm7043407qkh.37.2015.04.03.21.01.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Apr 2015 21:01:27 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 4 Apr 2015 00:01:26 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201504040001.26398.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 04:01:30 -0000 On Friday, April 03, 2015 11:17:04 pm Brian Smith wrote: > Conversely, there is a clear record of my objection to the > zero-padding mechanism on the mailing list, and there seems to be at > least some mild support for my suggested alternative of deriving the > initial nonce from the keyblock. Yeah, correct me if I missed it, but there didn't seem to be any real opposition to adding randomization to the nonce. There was suggestion of using XOR rather than ADD to mix random & sequence, but either could work. > Finally, Ilari Liusvaara noted in the previous thread on the topic > that SSH already does exactly what I'm proposing, or very similar. > And, he also noted that IPSEC partially randomizes the nonce, as does > TLS 1.2. It seems like zero padding would be a regression from what > TLS 1.2 does, in terms of security. I find that concerning. I would think it shouldn't be too hard to get agreement that following this pattern is something worth continuing. At worst, it won't hurt. Dave From nobody Fri Apr 3 21: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 AF8321A89EF for ; Fri, 3 Apr 2015 21: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, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkGB9s0guaRj for ; Fri, 3 Apr 2015 21:52:57 -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 53E991A01EC for ; Fri, 3 Apr 2015 21:52:57 -0700 (PDT) Received: by wixm2 with SMTP id m2so82556229wix.0 for ; Fri, 03 Apr 2015 21:52: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=nqMIG6IOET3Ac6ufjxzBuHV0GkN1NhN//2GNJ6Mtnbc=; b=jHj8eo+Yp3oZxrqi3EWeHWGNfIko9RuN3j76l3xooJiw+sJW5wDYxidZrWXRErekbD AJFKxlCZ/KkndWc6vVGI0yQ9ocHvim3/gYTZkHibPs6O0OjOqhcUkDeOj5XZuwSHA5U4 p8XqXrvYd5zK8yT875UYAEnTW/rfNR5vzmnj1uTJqIZ9cA27T7xOtFMf7WlSgHJUTp4k TkXk0DiajXi2BaNO64LiZyeObmphIj8F/kwBmq0AGSOfw41kH2OyKU0iF2a5mAhBHl58 Gfk+ALF/nfymCoL1md7ZSXiKB0xsTgfowGkoO9phd3NcdBy4CfnKOXO/h5/k5W4Hdmw/ POoA== X-Gm-Message-State: ALoCoQl615AXzGq6HpzhzHyqj8RrNknPiwamrK0AolyiQS/rkiDhKqZXsbTu/xWppXLSPyaFo1c4 X-Received: by 10.194.201.164 with SMTP id kb4mr10764215wjc.32.1428123176025; Fri, 03 Apr 2015 21:52:56 -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 xy2sm14100793wjc.14.2015.04.03.21.52.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 21:52:54 -0700 (PDT) Message-ID: <551F6E22.1040207@azet.org> Date: Sat, 04 Apr 2015 06:52:50 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <20150401201221.163745c2@pc1.fritz.box> <201504032121.07726.davemgarrett@gmail.com> In-Reply-To: <201504032121.07726.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6BCE258E0BB68E0F05356AB0" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Ala Carte Cipher suites - 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: Sat, 04 Apr 2015 04:52:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6BCE258E0BB68E0F05356AB0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Dave Garrett wrote: > (by the way, do we really want plain PSK?) Added the PSK ciphersuites after lengthy discussion with nikos and peter gutmann, they assure me it's of importance to the embedded world. > Just splitting it into only two parts would avoid the risk of support h= oles you'd get with the full a la carte route. >=20 > There's plenty of space in the registry to keep adding piles and piles = of variations for each suite, but I have seen actual instances where a se= rver and client actually do support the same handshake and connection cip= hers in TLS 1.2, but don't negotiate it because the specific combination = isn't listed. The current system does lead to some support holes as-is. >=20 I actually really like the idea. But there're a couple of open questions to that; What happens to existing ciphersuites? And given we switch to a model of asymmetric and symmetric ciphersuites: (how) do we document all the implicit ciphersuites that are defined once a new symmetric or asymmetric algorithm is defined? Aaron --------------enig6BCE258E0BB68E0F05356AB0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVH24jAAoJEOTbZJL9ubXVh9YQANoE8TyX9eI9RuXMpsFNiE5t zVjUj70JeyT+swOeX5EwlZb5jKHkmy0rSavHJedR+67PKvTRWfY+R5q1C+Y8x8Qu y0BpyMF3rkFwtmYLbLhqPq5i96eEUFrGiHHKsiK/ojipWJ33iFguFEqlEN7gTzBj rRlrAFWCW1svvIFOcOROSwamKzbQYMgZ3E1XgHmkvWbAW+1TuFq+pOCCbi6KQEut h5rpPUrdRIIy1DN/pOLZsgoePipmeauomRFFEtyQsESqQFqw/5hanAV0zL5CSn7u l1op+LeqOLLa9KXEb7f1Ff+pypQe+ElbcnzI343/7B1HrUBpXwAWE/uZw9SP7O9+ fzOwP+5hGP92IeHwjwIwpFkKsGss/N+rjMFGT2NIRHkkhMvwD7hK4Q2K47dToBmB Vm+f9DDQHwakKFrAzgpouNT02E+hb2DZY4MAOXuPjaI+aVrLswnXNqqTbgCf8EfD PEE9nm9TZsF4xy74gXxAVYX/mdL0D55x56R+73cnGcsibMRvw8GkApBjHgPYspvu jrRwJPJxj/r6SctrCiJv38bdvZTm/179JRQXyZ9DBiJpni23Z06neKjn6ob+SmgS eGnd641X4DbtEYky5Yyz5cyTLxq3Bfj5KNJgeoRQAfSD8p3A7dizX9XdI79dXQYe T6I7r55+/hpjrEVomy4O =bw2L -----END PGP SIGNATURE----- --------------enig6BCE258E0BB68E0F05356AB0-- From nobody Sat Apr 4 07: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 795D11B2B6E for ; Sat, 4 Apr 2015 07:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3RW-4JKPBXk for ; Sat, 4 Apr 2015 07:08:23 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 A57551B2B69 for ; Sat, 4 Apr 2015 07:08:22 -0700 (PDT) Received: by wiaa2 with SMTP id a2so165533664wia.0 for ; Sat, 04 Apr 2015 07:08:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lVsl9DCBqZZYOzIzOuy2kCKS81aa5VBB8QxGo0aaJmU=; b=fH4CkOYbuuu5WbNKqSqlR2TPHpV84dnMNPe0usmOIiom3kOOuOja0jhzBC/iPNeYiB w10MhsnPIVca/29nlclbEZmlWsBTMkWIeX9LZtvYIDkmvcaa0eBelQAbVOQmDyFB11sl ZMrJJp/a798Sfif/JW0vBCsNVphDu60bDKR/+NddHGuIfEs0OdEcOF4XWIRoKE/xxDrW hsCPmIphh2RzATjpN82wudZzSEFos0xEZbMBhtK0kkudh82GdCuZgZaBBI1PIGu9pNyy kk09Q4DqAqs2plJFsC4/jg8iFtUaFte6Vg7xEkevcnvwO8lW36zOuwaqmtdaJqyh9qYU 7Sow== X-Gm-Message-State: ALoCoQnE4juGFRtvpn1Gk5fyiLQb2WD+iPIWEB6ZqC3OyUX8Lmx8+l5MrMTF2RNlstcDnePfdNxQ X-Received: by 10.194.133.101 with SMTP id pb5mr14571195wjb.40.1428156501423; Sat, 04 Apr 2015 07:08:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sat, 4 Apr 2015 07:07:41 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sat, 4 Apr 2015 07:07:41 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=089e011771f3f38d390512e698e0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 14:08:24 -0000 --089e011771f3f38d390512e698e0 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 8:17 PM, Brian Smith wrote: > Joseph Salowey wrote: > > In the interim meeting we had consensus to use an implicit IV for AEAD. > The > > proposal was to use the record sequence number and pad with zeros as > > described in pull request 155 > > (https://github.com/tlswg/tls13-spec/pull/155/files). This was also > > discussed in the IETF-92 meeting in Dallas along with options to change > the > > offset. The consensus was to stay with the original proposal. We are > > posting to the mailing list to confirm this consensus. If you have > comments, > > please reply by April 17, 2015. > > Right now, based on my reading of the draft minutes, Which draft minutes are you referring to? I only see interim minutes on the site. > it doesn't look > like there was a complete, reasoned discussion of the issue during > IETF 92, nor is it clear to what extent any kind of consensus or > agreement was expressed during the meeting. Perhaps the draft minutes are incomplete, but the statement that there was a consensus to stay > with the original proposal doesn't seem consistent with draft minutes. > You can find the discussion (which may or may not be complete or reasoned) at: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_TLS&chapter=chapter_0 Starting at around 2:37:30. The consensus call starts at around 2:44:30. -Ekr --089e011771f3f38d390512e698e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 3, 2015 at 8:17 PM, Brian Smith <brian@briansmith.org> wrote:
Joseph Salowey <joe@salowey.net> wro= te:
> In the interim meeting we had consensus to use an implicit IV for AEAD= .=C2=A0 The
> proposal was to use the record sequence number and pad with zeros as > described in pull request 155
> (https://github.com/tlswg/tls13-spec/pull/155/files).=C2=A0 = This was also
> discussed in the IETF-92 meeting in Dallas along with options to chang= e the
> offset.=C2=A0 The consensus was to stay with the original proposal.=C2= =A0 We are
> posting to the mailing list to confirm this consensus. If you have com= ments,
> please reply by April 17, 2015.

Right now, based on my reading of the draft minutes,

Which draft minutes are you referring to? I only see= interim minutes
on the site.

=C2=A0=
it doesn't look
like there was a complete, reasoned discussion of the issue during
IETF 92, nor is it clear to what extent any kind of consensus or
agreement was expressed during the meeting. Perhaps the draft minutes
are incomplete, but the statement that there was a consensus to stay
with the original proposal doesn't seem consistent with draft minutes.<= br>

You can find the discussion (which may = or may not be complete or
reasoned) at:
http://recordings.conf.meetecho.co= m/Playout/watch.jsp?recording=3DIETF92_TLS&chapter=3Dchapter_0
<= /div>

Starting at around 2:37:30.

The consensus call starts at around 2:44:30.

-E= kr
--089e011771f3f38d390512e698e0-- From nobody Sat Apr 4 08:41: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 38C261B2BD2 for ; Sat, 4 Apr 2015 08:41:49 -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_52=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 qurl077pBntu for ; Sat, 4 Apr 2015 08:41:48 -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 100F01B2BD0 for ; Sat, 4 Apr 2015 08:41:48 -0700 (PDT) Received: by qgdy78 with SMTP id y78so46924626qgd.0 for ; Sat, 04 Apr 2015 08:41:47 -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=0kOBYiJEznf5YAsyqfdRDskuVNKB2IEIbtPXHUPd8Cs=; b=rltv+aDbM9IL9ANlKfb16ev2XeDNYgTPMib0TpC2mvnrXTQMynh0Cmz2YN5uVWKwc/ soAmhzcAz75AujL/8JgNviZ5C7kRZEq+xlOY+mn5EQeDWvLobDUF7bHGVpUHO53K3aOH w+ZwqTmYVdGdaBSdE9DUqf8zOMWtOG/y01rtaoX2bFbik/911ODv2T9EzjuZjUwf/sNn pJZtnXOFaMc8jOCOYDRHhpAxFZss52tWmamp9eMzFpnsAVh3LPT1xGIeqmeGZJSIQHsQ 5YOkX/gHs5xJdBi2QKMekWNeKMHzCrWdnMJ3z/1jl64tETJqQqLlslQmj6RYz06KzNpZ U6Vg== X-Received: by 10.140.202.144 with SMTP id x138mr8627841qha.14.1428162107355; Sat, 04 Apr 2015 08:41:47 -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 m68sm8032622qge.15.2015.04.04.08.41.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 04 Apr 2015 08:41:46 -0700 (PDT) From: Dave Garrett To: Aaron Zauner Date: Sat, 4 Apr 2015 11:41:38 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150401201221.163745c2@pc1.fritz.box> <201504032121.07726.davemgarrett@gmail.com> <551F6E22.1040207@azet.org> In-Reply-To: <551F6E22.1040207@azet.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504041141.39158.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Ala Carte Cipher suites - 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: Sat, 04 Apr 2015 15:41:49 -0000 On Saturday, April 04, 2015 12:52:50 am Aaron Zauner wrote: > Added the PSK ciphersuites after lengthy discussion with nikos and peter > gutmann, they assure me it's of importance to the embedded world. I'm fine with (EC)DHE_PSK, but I thought the consensus was that non-ephemeral cipher suites were not permitted any longer. I thought usage of plain PSK would be against TLS 1.3 & HTTP/2 consensus. If it really is needed, I think they should be prohibited in general TLS and only allowed via the IoT application profile. > > Just splitting it into only two parts would avoid the risk of support holes you'd get with the full a la carte route. > > > > There's plenty of space in the registry to keep adding piles and piles of variations for each suite, but I have seen actual instances where a server and client actually do support the same handshake and connection ciphers in TLS 1.2, but don't negotiate it because the specific combination isn't listed. The current system does lead to some support holes as-is. > > I actually really like the idea. But there're a couple of open questions > to that; What happens to existing ciphersuites? There's hardly any left that are still permitted. Each cipher that would be usable in TLS 1.3+ would need to define its own set of new cipher suites. The TLS 1.3 spec could have a short section to just assign the IDs for the existing ones. Clients would propose both the old suites and the new suites in the same array. Old servers would ignore the new, and new servers would ignore the old. (again, set all new above some point so checking is just a greater/lesser than comparison) It would be an extra few bytes, but again, any system to improve this via an extension would also add an extra few bytes. > And given we switch to a > model of asymmetric and symmetric ciphersuites: (how) do we document all > the implicit ciphersuites that are defined once a new symmetric or > asymmetric algorithm is defined? The two are separate enough that all combinations should be valid and all implementations should be capable of handling all combinations. Dave From nobody Sat Apr 4 08:52: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 4501A1B2BDA for ; Sat, 4 Apr 2015 08:52:21 -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_52=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 zDvKaCvXGSIg for ; Sat, 4 Apr 2015 08:52:20 -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 0DC531B2BD2 for ; Sat, 4 Apr 2015 08:52:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id ACA9B283032; Sat, 4 Apr 2015 15:52:18 +0000 (UTC) Date: Sat, 4 Apr 2015 15:52:18 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150404155218.GO17637@mournblade.imrryr.org> References: <20150401201221.163745c2@pc1.fritz.box> <201504032121.07726.davemgarrett@gmail.com> <551F6E22.1040207@azet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551F6E22.1040207@azet.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die 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, 04 Apr 2015 15:52:21 -0000 On Sat, Apr 04, 2015 at 06:52:50AM +0200, Aaron Zauner wrote: > I actually really like the idea. But there're a couple of open questions > to that; > What happens to existing ciphersuites? Those that are strong enough to survive into TLS 1.3 are subsumed by the new ala-carte choices. > And given we switch to a > model of asymmetric and symmetric ciphersuites: (how) do we document all > the implicit ciphersuites that are defined once a new symmetric or > asymmetric algorithm is defined? There's no need to document the "cross-product", just document the inputs. Making it a cross-product fills in gaps, for example, there are at present no AECDH (key agreement) plus AEAD (symmetric bulk crypto) ciphersuites. Note that digests play a role in both the handshake and in the bulk crypto MAC. For the handshake, there's the digest used in certificates (which seems odd to negotiate as it is I think rare for either end to have multiple variands of a given certificate chain with different digests). There's also the digest used for key derivation. If the leading proposal is to go with 2 axes for the cross-product, then I would fix the key-agreement PRF in each handshake type, and use the supported digests extension as a "hint" to the peer to aid in certificate selection. I say "hint", because the peer will do its best to send a suitable chain, when it has more than one, but typically such "hints" are not particularly effective, and the peer may as well use whatever it has. For example, with DANE-EE(3) the signature of the peer certificate is never checked and is irrelevant. -- Viktor. From nobody Sat Apr 4 10:53: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 881E21A00F4 for ; Sat, 4 Apr 2015 10:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrqCvTi1aZdW for ; Sat, 4 Apr 2015 10:53:02 -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 0D4721A010C for ; Sat, 4 Apr 2015 10:53:02 -0700 (PDT) Received: by qkgx75 with SMTP id x75so2090616qkg.1 for ; Sat, 04 Apr 2015 10:53: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:mime-version:content-type :content-transfer-encoding:message-id; bh=+6tqMbJCReoCUPkSedmAy5uy5upLwdTpZsAwIiR6Rto=; b=TewIxh3E1j3OhSNqdLWWYlSJEv7wIh/d/DO8PeekY2y9Ew08i+Eo2qKQsgYunxQ7K7 BF5r9nVAQkLoTBB8w2t0IS2Ya4phUYywqCri4qXqMDOuj5KHG2SY9sC0r+qd0otOgzGG Ok5djj1rjPDZAnp52iUB79NAKcsPmIpuUZ7XcXEI0giawjqMah3o7lj3QF2FPMB+dsEO aCxdLcYslFJytwiAVrcO8pJP6C3mXMo7Uh/Bi2uvsXwjV44lVi2+I2rSj8e37ZnuM7Zs VUenkF0uWQlYbu90VX0d9D5Fy7LdWcXJHN7CnHIKVKSCVboGTH3TGvEHq59s4L50mKsg lMbg== X-Received: by 10.55.31.90 with SMTP id f87mr14393390qkf.38.1428169981250; Sat, 04 Apr 2015 10:53: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 g21sm8147588qhc.35.2015.04.04.10.53.00 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 04 Apr 2015 10:53:00 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 4 Apr 2015 13:52:12 -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: <201504041352.12431.davemgarrett@gmail.com> Archived-At: Subject: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 17:53:03 -0000 And now, a simple issue with a simple solution: https://github.com/tlswg/tls13-spec/issues/64 Consensus was to drop time from the random fields. Prohibiting non-random in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really simple solution. (note that ServerHello is already changed by dropping compression_method) The ability of a client to sanity check or sync its time seems like something worth having, especially for only a 4 byte cost. Dave From nobody Sat Apr 4 12:53: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 46AB31A1AFC for ; Sat, 4 Apr 2015 12:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=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 1DzPSk8FBO-q for ; Sat, 4 Apr 2015 12:53:31 -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 02E621A1AD3 for ; Sat, 4 Apr 2015 12:53:29 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id B02D31887DE; Sat, 4 Apr 2015 22:53:26 +0300 (EEST) Date: Sat, 4 Apr 2015 22:53:26 +0300 From: Ilari Liusvaara To: Brian Smith Message-ID: <20150404195326.GA2392@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] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 19:53:33 -0000 On Fri, Apr 03, 2015 at 05:17:04PM -1000, Brian Smith wrote: > > Conversely, there is a clear record of my objection to the > zero-padding mechanism on the mailing list, and there seems to be at > least some mild support for my suggested alternative of deriving the > initial nonce from the keyblock. I think I provided a good > justification for moving to the randomized initial nonce. I think that > the concerns about it being more work to support a randomized nonce in > crypto modules that attempt to enforce a cryptographic boundary are > valid,m but those concerns outweigh the security benefits of starting > with a randomized nonce. I would be happy to work with the people who > expressed that concern to show that a randomized initial nonce can > work well and isn't unreasonably burdensome even in such products. The stated reason for not deriving IV from keyblock is to support "hardware modules" that don't know about TLS. I do not think such support is actually possible without severe restrictions: One major problem (and there are others) is interaction of resumption and TLS-unique (which is needed for e.g. token binding). TLS-Unique value is public. But on resumption, it needs to depend on resumption key, which is secret (resumption key can be abused to misuse client certificates). Second problem: If TLS-Extractor is to be supported, those values are keying and publically binding at the same time (I have seen examples of both in various widely used protocols). Keying means there is no choice but to derive from secret values. Publically binding means the values are public. Deprecating either of TLS-Unique or TLS-Extractor or changing properties thereof does not seem to be an option, so full TLS 1.3 needs to derive public values out of private ones anyway. Also, exposing nonce generation to "untrusted" code seems pretty dangerous, given how fragile most fast AEAD ciphers are (it is difficult to even imagine worse nAEAD in this regard than *-GCM). > I've also thought of another reason why it seems useful to start with > a randomized initial nonce: As mentioned previously on this list, in > reality many AES-GCM implementations are far from being constant-time. > As far as I can reason, AES-GCM with predictable nonces, combined with > predictable plaintext and/or chosen plaintext, seem more likely to > attack via side channel attacks than AES-GCM with randomized nonces. > This is another significant advantage of randomization. As a datapoint about (lack of) hardware support for AES-GCM: When Cloudflare turned Chacha ciphers on, it took about one fourth of the AES-GCM connection count (other ciphers didn't bulge). > It seems like zero padding would be a regression from what > TLS 1.2 does, in terms of security. I find that concerning. As brought up in the meeting, 128 bit ciphers are suspectable to multi-key weakening (it is an generic attack against symmetric ciphers). The answer was to use 256-bit ciphers, but AES-256 isn't that widely supported (I think Chrome is planning to deprecate it[1]). Then when it comes to cipher-specific weaknesses (and we know that ciphers have annoying tendency to stay in use way past the best before date, *cough* RC4 *cough*), it depends on type of weakness if having a known nonce significantly helps breaking or not. BTW: SSLv3 applied special handling for EXPORT ciphers: The initial IV was derived in public way[2] (instead from keyblock like non-export ciphers). Of course, didn't matter much, given that all IVs were for CBC modes. [1] Also on some security-oriented forums, one frequently hears remarks about AES-256-CBC being worse than AES-128-GCM. [2] I think this was a due to a restriction on export ciphers that disallowed hiding the nonces. -Ilari From nobody Sat Apr 4 12:53: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 EE8E71A1AD3 for ; Sat, 4 Apr 2015 12:53:33 -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 aQvlUASCdyQf for ; Sat, 4 Apr 2015 12:53:32 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003: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 80ACE1A1A16 for ; Sat, 4 Apr 2015 12:53:32 -0700 (PDT) Received: by obvd1 with SMTP id d1so1102766obv.0 for ; Sat, 04 Apr 2015 12:53:32 -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=KfT9JkE5K4dLESplsgt4BoMz1FG7aKdr1npzlNZ8/pg=; b=Jact8+6u0BMqb4fXQlUB9L5BTc9NCOyBgO92xB+r6Aw1No3ttTErA52MpswmzmgctR 3xmGzUsW+57W3umKN3SMmgxyFywMk3Jf5pMTn2hQAgfXuJ2dh6esuIyTbHqNS1VENri5 mFO2541Ut3PFCFK0qrGeVZHe9XiZc9iqLcQGbP1KE9gIA3r5Ljn92VZjxLtOxeWKUAq9 +7unQj9JJ32OSNI3KF3bbxYdTR7QHWUPwy9veRn4e3XNIjrcjTyYyqRi2Gvjsch9TERV 48wTvcDUaokQYB48pnhVo2vPpeXR7w4MpR6byFNU3OX4O8CvJdjLjeKk3bUSwRdma++a O5QQ== MIME-Version: 1.0 X-Received: by 10.182.248.161 with SMTP id yn1mr9791736obc.25.1428177211953; Sat, 04 Apr 2015 12:53:31 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.202.176.130 with HTTP; Sat, 4 Apr 2015 12:53:31 -0700 (PDT) Received: by 10.202.176.130 with HTTP; Sat, 4 Apr 2015 12:53:31 -0700 (PDT) In-Reply-To: <201504041352.12431.davemgarrett@gmail.com> References: <201504041352.12431.davemgarrett@gmail.com> Date: Sat, 4 Apr 2015 15:53:31 -0400 X-Google-Sender-Auth: EwCyeAQMTaFPbFY_tWpZXx9177U Message-ID: From: Erik Nygren To: Dave Garrett Content-Type: multipart/alternative; boundary=001a11c2a8ac651a8a0512eb6b02 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 19:53:34 -0000 --001a11c2a8ac651a8a0512eb6b02 Content-Type: text/plain; charset=UTF-8 If we do, can we please make the extension y2038 safe? With 17 years to go when this launches, that will be the same age as tls 1.0 and older than sslv3. It does seem like a useful server hello extension, however, as long as clients wait for a complete and authenticated handshake before using it. Erik Sent from my mobile device And now, a simple issue with a simple solution: https://github.com/tlswg/tls13-spec/issues/64 Consensus was to drop time from the random fields. Prohibiting non-random in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really simple solution. (note that ServerHello is already changed by dropping compression_method) The ability of a client to sanity check or sync its time seems like something worth having, especially for only a 4 byte cost. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --001a11c2a8ac651a8a0512eb6b02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If we do, can we please make the extension y2038 safe?=C2=A0= With 17 years to go when this launches, that will be the same age as tls 1= .0 and older than sslv3.

It does seem like a useful server hello extension, however, = as long as clients wait for a complete and authenticated handshake before u= sing it.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik

Sent from my mobile device

And now, a simple issue with = a simple solution:

https://github.com/tlswg/tls13-spec/issues/64

Consensus was to drop time from the random fields. Prohibiting non-random i= n ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS 1.= 3+ seems like a really simple solution. (note that ServerHello is already c= hanged by dropping compression_method)

The ability of a client to sanity check or sync its time seems like somethi= ng worth having, especially for only a 4 byte cost.


Dave

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--001a11c2a8ac651a8a0512eb6b02-- From nobody Sat Apr 4 14:09: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 9BE381A00CD for ; Sat, 4 Apr 2015 14:09: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 uGqT3WM7AhPd for ; Sat, 4 Apr 2015 14:09:08 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADF51A0030 for ; Sat, 4 Apr 2015 14:09:08 -0700 (PDT) Received: by igblo3 with SMTP id lo3so54632igb.0 for ; Sat, 04 Apr 2015 14:09:07 -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=BHoph31dVa5Liw4BQFBdV5LwEAvU4DEYTIPndgNy64s=; b=Dq72FtBBJI0IDSJ5+i8kTvHX0xcE3oEtMpvLpNF+RQPe6LsjnNS3UHetk90P9qNN1i uLo2DrhotOTIBYihJQQ+3SY6iHs4rCp3zes/9wNYdlAEuVVGqnWAvGMr5KkM8ASN1g1E yfxpio97AG20B/Jhu9bhNr9iXkOud6leHeZh4gbPGBkTDTLTRd+pwWCW8N074ygm420Y +ObY2mEZvo9U1alO3sYdmOk8lpY8Aeix7lJStCuh0blOgNFYWO5D89qjqOulKvEE+zVS 6m1/eUAnyjdOVxO4XkrkHR2DkmzDEPgCUQpwX+HMl9Xgp6+m3mX5YbnHvpd1+Q8R7bdJ h2sw== MIME-Version: 1.0 X-Received: by 10.42.109.12 with SMTP id j12mr10822957icp.22.1428181747692; Sat, 04 Apr 2015 14:09:07 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Sat, 4 Apr 2015 14:09:07 -0700 (PDT) In-Reply-To: <201504041352.12431.davemgarrett@gmail.com> References: <201504041352.12431.davemgarrett@gmail.com> Date: Sat, 4 Apr 2015 17:09:07 -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] Server time 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, 04 Apr 2015 21:09:09 -0000 > Consensus was to drop time from the random fields. Prohibiting non-random= in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS = 1.3+ seems like a really simple solution. (note that ServerHello is already= changed by dropping compression_method) > +1. Random should be random. Placing time in the random field meant the field was not used for its intended purpose. It violated the engineering design. (Whether it resulted in a vulnerability is a different debate). > The ability of a client to sanity check or sync its time seems like somet= hing worth having, especially for only a 4 byte cost. > +1. Some Android phones have a peculiarity where they will fail their very first path validation (like after a factory reset). The phones don't have a SIM and use Wifi. We think its because of the clock (we have never been able to duplicate it, but I've seen the field reports). Other older phones have the same issue, but its persistent. That is, the phone won't set the time if there's no network. You have to SIM the phone or manually set the time. I think the same problem will arise in the future with the Internet of Things. Refrigerators and thermostats will experience similar issues. History has a tendency to repeat itself. The time field begs the question: what is the presentation of time? Is it a UTC or GMT time? Is it a local time? Is there time zone data associated with it? From nobody Sat Apr 4 14:09: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 11D4D1A00DC for ; Sat, 4 Apr 2015 14:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK7DMPIeIlxM for ; Sat, 4 Apr 2015 14:09:30 -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 CF4A51A0030 for ; Sat, 4 Apr 2015 14:09:29 -0700 (PDT) Received: by qgdy78 with SMTP id y78so54739qgd.0 for ; Sat, 04 Apr 2015 14:09:29 -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=mBwuEU2VlSk0ecorWxVb9xw14LIK2rBhn4wcuvsZNtE=; b=yEUHZnIa+634dI2Ryv1sl0WrZVXptRqaJN1Pig0hbrWuKSTt8lVoREB/+JrGukM9T7 ZoeIMnC6njjc28BqkLAPdQHdwgtWKC3TpAQ93jYhtNYy7fqWjgIK2sM8Pamc7arcSETF lioI62awqJ/kFC9b7M/u7fyzEtnTXPkbMC/4RijfXNIg/pqAlL70+KOabMQPuykhZbbH aRd6fbjPj081eAS5a6aIU67svMOxFp5y2QJo7cLRaosWDABd8T7ouOfHuguR7hxXoLM0 W9VVoqhJ1pixXLt9PAZM+f5e46KUN++iWBQltZshz5e7tJoAZhkomAdQh6OvSISW9g1C R7IA== X-Received: by 10.140.32.34 with SMTP id g31mr9145434qgg.74.1428181769047; Sat, 04 Apr 2015 14:09:29 -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 s7sm175217qgd.4.2015.04.04.14.09.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 04 Apr 2015 14:09:28 -0700 (PDT) From: Dave Garrett To: Erik Nygren Date: Sat, 4 Apr 2015 17:09:27 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504041352.12431.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504041709.27640.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 21:09:31 -0000 On Saturday, April 04, 2015 03:53:31 pm Erik Nygren wrote: > If we do, can we please make the extension y2038 safe? With 17 years to go > when this launches, that will be the same age as tls 1.0 and older than > sslv3. Yeah, I suggested uint32, which will last the century. Not worth the extra 4 bytes to go 64-bit, IMO. Nobody should be still using this at the beginning of the 22nd century. (if someone does, and is looking back in time in the archives: upgrade your crap) The previous not-random-but-in-random time was uint32 as well, so that was fine so long as clients actually handled it properly. A warning could be added about signage saying not to ever treat it as signed and that after reading as uint32, it should probably be handled as int64 or whatever type the implementation uses for time values. Dave From nobody Sat Apr 4 14:57: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 3CAF21A035F for ; Sat, 4 Apr 2015 14:57:11 -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 AgdQEvnZUJfH for ; Sat, 4 Apr 2015 14:57:08 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 F07B81A036C for ; Sat, 4 Apr 2015 14:57:07 -0700 (PDT) Received: by qku63 with SMTP id 63so223676qku.3 for ; Sat, 04 Apr 2015 14:57: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:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=zpWrkuvlBwTGRrmdVmT9VVsB/TigVLa/5NiYHSoBCTQ=; b=d2xmNxqkKViwaTUWQZRkgi5NcXbwf+YUD4hrDs2h4FWcM/FMMQyiYbXVeN0Wx1RAPg MMjyPXdFfK2jNIfgijv4z0bg+KsQEPyEt7hROkLEO6By/Mwgz1LUyC1BLOGii8Mjwcnm 21+byRop3ZlrgBPlwZlOb8Lcd6vedAt+7QzEL72WEcYsi4XDp1ujAy1cQ5fMKqUBxpfI YI4MaKSwNzlTaCVp4se5mbbGBMFB7NTGINvdz1qCFs5Mi1SPJceqrV0TVNicexv7wTtn fj4U3sE/SB+pS7ldS+9w9e9C1ir1YSNvjNkU8Ip1qx+PeKOz1bu+6HeB2UBjxPNoVmIV iBVQ== X-Received: by 10.55.55.85 with SMTP id e82mr15915507qka.2.1428184627206; Sat, 04 Apr 2015 14:57: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 80sm228784qhb.26.2015.04.04.14.57.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 04 Apr 2015 14:57:06 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 4 Apr 2015 17:57:05 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504041352.12431.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504041757.05854.davemgarrett@gmail.com> Archived-At: Cc: Erik Nygren Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Apr 2015 21:57:11 -0000 On Saturday, April 04, 2015 03:53:31 pm Erik Nygren wrote: > It does seem like a useful server hello extension, however, as long as > clients wait for a complete and authenticated handshake before using it. Just sticking in an extra ServerHello field for the time is the quick and simple replacement for the old standardized hack. If we want more, it wouldn't be difficult to write a simple time/ping protocol to build into the spec. Do a ping with a time request after authentication and it would be protected, measure latency, and easily provide precise remote time adjusted for response time. Might be overkill, though it'd be simple enough to add. Dave From nobody Sat Apr 4 15:10: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 00DA91A039B for ; Sat, 4 Apr 2015 15:10:11 -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 MCV-HTzCJ1PC for ; Sat, 4 Apr 2015 15:10:09 -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 AA0CC1A039C for ; Sat, 4 Apr 2015 15:10:09 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so575960ied.1 for ; Sat, 04 Apr 2015 15:10:09 -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=hGa1b+BLVcT80llyLCLILEPFasxkVUHWcdXY408C1G0=; b=HgjzviFK7i4awqBE/MfRtdh2H5vTyBZPALNmE7SxJo5gKkCO0+iJ22q9Z2wCZSxsre TnybnMrHdEejkoz5hvM45HQ8NdrFoM5gRVg+vHJnJcT+qxR5srs3ITiEABxyk9qfTii8 hse/1VJNbkn/M1kXOL6nEVXighpyfemItFAu86jaKmpp1tChrWJR98ayLc/Cc0Mz9jPK D6jdQflX2Jgl1DbrqxGuUUv+3/m/uF6Isls0US3Bt4cV2RX2OU+S6L+m+dAvw77EI6Ah ATy7OP9cTbigqiGfkZC/poqVRc88NWO5JWQRTe0kc7TzNM/uNvo0PaEG4jSCv6GB9HH+ 6Nzw== MIME-Version: 1.0 X-Received: by 10.42.109.12 with SMTP id j12mr11004394icp.22.1428185409123; Sat, 04 Apr 2015 15:10:09 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Sat, 4 Apr 2015 15:10:09 -0700 (PDT) In-Reply-To: <201504041757.05854.davemgarrett@gmail.com> References: <201504041352.12431.davemgarrett@gmail.com> <201504041757.05854.davemgarrett@gmail.com> Date: Sat, 4 Apr 2015 18:10:09 -0400 Message-ID: From: Jeffrey Walton To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Server time 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, 04 Apr 2015 22:10:11 -0000 On Sat, Apr 4, 2015 at 5:57 PM, Dave Garrett wrote: > ... > > Do a ping with a time request after authentication and it would be protected, measure latency, and easily provide precise remote time adjusted for response time. Might be overkill, though it'd be simple enough to add. > I think the problem here is channel setup will fail *if* the client's clock is wrong. The client will fail to validate the end-entity certificate due to problems with the notBefore and notAtfer (even though its correct). You won't have a channel to perform the ping. I like the idea of a field like ServerHello.time so the server can communicate its belief in time. A client can defer a simple failure based on time until key exchange completes. If key exchange completes successfully, then the client can decide if it wants to accept the server's view of time. The functionality leads to other attack surfaces, like a rogue server rolling back its time and using compromised key. But I think that can be solved with a good degree of certainty using Guttmann's security diversification techniques. Jeff From nobody Sat Apr 4 16:55: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 11AD01A03B3 for ; Sat, 4 Apr 2015 16:55:11 -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 bdL-xitoLXQ8 for ; Sat, 4 Apr 2015 16:55: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 CB2121A039F for ; Sat, 4 Apr 2015 16:55:09 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B35B6165771; Sat, 4 Apr 2015 23:55:08 +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 A882716576F; Sat, 4 Apr 2015 23:55:08 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 9BA3F9803E; Sat, 4 Apr 2015 23:55:08 +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.913.22; Sat, 4 Apr 2015 18:55: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.0913.011; Sat, 4 Apr 2015 18:55:07 -0500 From: "Salz, Rich" To: Brian Smith , Michael StJohns Thread-Topic: [TLS] Ala Carte Cipher suites - was: DSA should die Thread-Index: AQHQbatXX8opwuFX2UyJqmUeOB4HcZ08TnqAgAE7orA= Date: Sat, 4 Apr 2015 23:55:07 +0000 Message-ID: <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.32.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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: Sat, 04 Apr 2015 23:55:11 -0000 > Please don't change the syntax for negotiating cipher suites. +1, for the reasons Brian said. From nobody Sun Apr 5 09:32: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 57F271A89ED for ; Sun, 5 Apr 2015 09:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 u701OLymsRPE for ; Sun, 5 Apr 2015 09:32:36 -0700 (PDT) Received: from hauke-m.de (hauke-m.de [5.39.93.123]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABA21A895D for ; Sun, 5 Apr 2015 09:32:35 -0700 (PDT) Received: from [192.168.178.22] (ip-109-43-19-230.web.vodafone.de [109.43.19.230]) by hauke-m.de (Postfix) with ESMTPSA id 424ED20541; Sun, 5 Apr 2015 18:32:33 +0200 (CEST) Message-ID: <5521639F.4070500@hauke-m.de> Date: Sun, 05 Apr 2015 18:32:31 +0200 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: noloader@gmail.com, Dave Garrett References: <201504041352.12431.davemgarrett@gmail.com> <201504041757.05854.davemgarrett@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2015 16:32:37 -0000 On 04/05/2015 12:10 AM, Jeffrey Walton wrote: > On Sat, Apr 4, 2015 at 5:57 PM, Dave Garrett wrote: >> ... >> >> Do a ping with a time request after authentication and it would be protected, measure latency, and easily provide precise remote time adjusted for response time. Might be overkill, though it'd be simple enough to add. >> > I think the problem here is channel setup will fail *if* the client's > clock is wrong. The client will fail to validate the end-entity > certificate due to problems with the notBefore and notAtfer (even > though its correct). You won't have a channel to perform the ping. If the client trusts the servers clock the notBefore and notAtfer check is useless, because a bad server could change the time of the check to a value where the certificate check is valid. If you take the time from the same entity where you get your certificate to check from the time check is useless. There is a big problem with embedded devices, which do not have a real time clock. One solution would be that you burn a valid certificate or CA certificate into a firmware and your device trusts this certificate regardless of the validity period. And this server could be used to get the time from. But wouldn't it be better to deign this as an extra protocol on top of TLS/DTLS? The German electronic identity card is unable to do any online checks and does not have a real time clock. It stores the issue date of the most recent certificate it saw and checks every other certificate if it was at least valid at this date. (The certificates used there are normally only valid for some days and there is no revocation mechanism) > I like the idea of a field like ServerHello.time so the server can > communicate its belief in time. A client can defer a simple failure > based on time until key exchange completes. If key exchange completes > successfully, then the client can decide if it wants to accept the > server's view of time. Adding such a field could also result in some stupid developers using this field to check if the certificate is valid for every handshake. > The functionality leads to other attack surfaces, like a rogue server > rolling back its time and using compromised key. But I think that can > be solved with a good degree of certainty using Guttmann's security > diversification techniques. > > Jeff From nobody Sun Apr 5 11:11: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 9F4ED1ACD19 for ; Sun, 5 Apr 2015 11:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 ZUYAQmNCLk0X for ; Sun, 5 Apr 2015 11:11:50 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (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 07CDC1ACD1D for ; Sun, 5 Apr 2015 11:11:50 -0700 (PDT) Received: by obbec2 with SMTP id ec2so16562438obb.3 for ; Sun, 05 Apr 2015 11:11:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=H7vxZ/75Ebo3meZxOocIAf8pHm8OYFlaJS80RUnuxCA=; b=I+uv2NiZ1ZHIOJtndSKADDmfGRb81ZADxEy0yMTFV96ZXl/yRBSK3SQGvd7ZcDzXeg P6aMUETaVusqteuVd5AFjV/hUH9tER36fxvVRw936pW7t2KU566RBZq9rsr7btNWM4xJ c7EcpT74zEowZVptKJAuDajs4FmgoWHosFLscti+dtL9JQk10ZWJ+AFRGxCz8bOX117z 0H9Qe6TMgL1W90+R9uGBjfxcZek8bBCLYjVnUphX8H8qUZXqMpwPyb8W5kmY5DeR1CDZ yXGoROQiEtrVQbMb6oKF4LBE4LbIzyiqEx/sKXovp/Szo8llzT14ABZtQobDs3ZnR1OR DHtQ== X-Gm-Message-State: ALoCoQmyTXBhp+vU9hNeEBrrKzlabHB2SC0+5TH8bomhyadMzW7hA7OIg9Z3hipLmpXUmedHhCIc MIME-Version: 1.0 X-Received: by 10.60.160.236 with SMTP id xn12mr14449474oeb.53.1428257509433; Sun, 05 Apr 2015 11:11:49 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Sun, 5 Apr 2015 11:11:49 -0700 (PDT) In-Reply-To: <201504041352.12431.davemgarrett@gmail.com> References: <201504041352.12431.davemgarrett@gmail.com> Date: Sun, 5 Apr 2015 08:11:49 -1000 Message-ID: From: Brian Smith To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2015 18:11:51 -0000 Dave Garrett wrote: > Consensus was to drop time from the random fields. Right. > Prohibiting non-random in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really simple solution. What problem does it solve? > (note that ServerHello is already changed by dropping compression_method) That seems unnecessary to me. compression_method could/should just be fixed to be "null", avoiding unnecessary compatibility risk. > The ability of a client to sanity check or sync its time seems like something worth having, especially for only a 4 byte cost. The client can sanity check or sync its time using other mechanisms already, even with earlier versions of TLS. I don't see how adding a time field to ServerHello would help solve that problem. There may be occasions when the server and client need to sync time, e.g. if it helps the 0-RTT handshake in some way. But, that should be done as part of the specification for whatever mechanisms require it. See the long-ago discussion about this [0]. Keep in mind that we removed the time from the Hello random fields because they leaked information that made it easier to track clients. And note that clients often play the server roll in (D)TLS. In particular, clients act as both the client and server in DTLS for WebRTC. Consequently, there always needs to be a way for the server to NOT say what time it thinks it is. Cheers, Brian [0] https://www.ietf.org/mail-archive/web/tls/current/msg10861.html From nobody Sun Apr 5 11:31: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 F000A1ACD3B for ; Sun, 5 Apr 2015 11:31:32 -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 jcMDSsYwKm2u for ; Sun, 5 Apr 2015 11:31:31 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::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 2E59B1ACD39 for ; Sun, 5 Apr 2015 11:31:31 -0700 (PDT) Received: by ierf6 with SMTP id f6so8818757ier.2 for ; Sun, 05 Apr 2015 11:31: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=LajNn9qyrQ993xbI3I3HuoeWcH30bRelxGJZcjtVkoE=; b=rHt5cHLzLYsWdjVzHy3Jh8pjWMitaZDYef6ce3omDIWEd+YhjX7n0ngslYGgyd2VXb ivJC2IAaODV4YXqup9x0d4K9w7hMr+YFTECPotLOsrxTpqJlpWNzI3633OJ8RXYZObpX rIsD+y5B/jXx00+hISj5NGoRf0R5/xojkGba2KUvDtUIGF++i5WOUyc0vIosxsHVdu1L u0ZgH3aETrgFVeWzNJ4JzG1StTTIJ2srz+Fx4lpif8zUv2LrVxwt3jEncXq+osprJhlo 4y0oa5ICSe1kUdR5Q98DGHw34cejWQyScy89++Zr7y08UwK2wQSuOP8p5dJqOqOcfSg5 +0Dw== MIME-Version: 1.0 X-Received: by 10.50.20.233 with SMTP id q9mr42175004ige.9.1428258690664; Sun, 05 Apr 2015 11:31:30 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Sun, 5 Apr 2015 11:31:30 -0700 (PDT) In-Reply-To: References: <201504041352.12431.davemgarrett@gmail.com> Date: Sun, 5 Apr 2015 14:31:30 -0400 Message-ID: From: Jeffrey Walton To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Server time 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, 05 Apr 2015 18:31:33 -0000 > Keep in mind that we removed the time from the Hello random fields > because they leaked information that made it easier to track clients. Tracking and anonymity has a different solution. I don't understand how folks can claim they are solving this when the first TCP SYN usually begins the tracking process. What happens after the TCP stream begins is irrelevant. > And note that clients often play the server roll in (D)TLS. In > particular, clients act as both the client and server in DTLS for > WebRTC. Consequently, there always needs to be a way for the server to > NOT say what time it thinks it is. In this case, allow a value of 0. In RFC 1952 (GZIP file format specification), a MTIME of 0 means no time is available. On Sun, Apr 5, 2015 at 2:11 PM, Brian Smith wrote: > Dave Garrett wrote: >> Consensus was to drop time from the random fields. > > Right. > >> Prohibiting non-random in ServerHello.random and adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really simple solution. > > What problem does it solve? > >> (note that ServerHello is already changed by dropping compression_method) > > That seems unnecessary to me. compression_method could/should just be > fixed to be "null", avoiding unnecessary compatibility risk. > >> The ability of a client to sanity check or sync its time seems like something worth having, especially for only a 4 byte cost. > > The client can sanity check or sync its time using other mechanisms > already, even with earlier versions of TLS. I don't see how adding a > time field to ServerHello would help solve that problem. > > There may be occasions when the server and client need to sync time, > e.g. if it helps the 0-RTT handshake in some way. But, that should be > done as part of the specification for whatever mechanisms require it. > See the long-ago discussion about this [0]. > > Keep in mind that we removed the time from the Hello random fields > because they leaked information that made it easier to track clients. > And note that clients often play the server roll in (D)TLS. In > particular, clients act as both the client and server in DTLS for > WebRTC. Consequently, there always needs to be a way for the server to > NOT say what time it thinks it is. > > Cheers, > Brian > > [0] https://www.ietf.org/mail-archive/web/tls/current/msg10861.html From nobody Sun Apr 5 12:04: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 9AA5C1ACDD0 for ; Sun, 5 Apr 2015 12:04: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 EdewhEO4GxxU for ; Sun, 5 Apr 2015 12:04: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 3948F1ACDCB for ; Sun, 5 Apr 2015 12:04:33 -0700 (PDT) Received: by wiax7 with SMTP id x7so10428250wia.0 for ; Sun, 05 Apr 2015 12:04: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=z443ETX4a/mXRPi4joAMpNwStgvBBPwklPltbBjXV+o=; b=fBAm02kyZOpYG0+tvT8TsX3qlFuxqcXr1rIevj9Rr27K+9+ufKldfY58vY49wZS0Oz 52HCwLI0H9FnJ1IwIW2seEo6k6OJhCbHqoG3VJk+hqzwqTZ9nmhCJ6op/VQwe/V2YCah PYC0P7jJiZknlfH7A8FBy5L+YHOD6oJLbXafUG/OUxJezEU4sq9Gj4NrxVCRS/L+oYV6 sHfiFI5WLifNyMM33t4OwiLDPJr4s3jR5CydSgPjFFlCX0KYOMYtpsoezVxClWn7l6v2 nOV0iY032tmJ4lKK6B/y393GLBeGWS/va8d3ia9G6BqmGXdYXg5QcXuIFqmo/UWI0/0H 4Wog== X-Gm-Message-State: ALoCoQkWNIz4Uer1WJcVFg0Nr38bC/z/dVLGRdLtcT8g9UzG9XAFqQOfK9KUfKomUz3gXU/wmzih X-Received: by 10.180.84.3 with SMTP id u3mr52969213wiy.38.1428260671955; Sun, 05 Apr 2015 12:04:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Sun, 5 Apr 2015 12:03:51 -0700 (PDT) In-Reply-To: References: <201504041352.12431.davemgarrett@gmail.com> From: Eric Rescorla Date: Sun, 5 Apr 2015 12:03:51 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=14dae9cc9c94ffba150512fed9e4 Archived-At: Cc: "" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2015 19:04:35 -0000 --14dae9cc9c94ffba150512fed9e4 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 5, 2015 at 11:11 AM, Brian Smith wrote: > Dave Garrett wrote: > > Consensus was to drop time from the random fields. > > Right. > > > Prohibiting non-random in ServerHello.random and adding a 4 byte uint32 > ServerHello.time for TLS 1.3+ seems like a really simple solution. > > What problem does it solve? > > > (note that ServerHello is already changed by dropping compression_method) > > That seems unnecessary to me. compression_method could/should just be > fixed to be "null", avoiding unnecessary compatibility risk. I think I agree with this, actually. Filed https://github.com/tlswg/tls13-spec/issues/161 so we don't lose this comment. -Ekr > > > The ability of a client to sanity check or sync its time seems like > something worth having, especially for only a 4 byte cost. > > The client can sanity check or sync its time using other mechanisms > already, even with earlier versions of TLS. I don't see how adding a > time field to ServerHello would help solve that problem. > > There may be occasions when the server and client need to sync time, > e.g. if it helps the 0-RTT handshake in some way. But, that should be > done as part of the specification for whatever mechanisms require it. > See the long-ago discussion about this [0]. > > Keep in mind that we removed the time from the Hello random fields > because they leaked information that made it easier to track clients. > And note that clients often play the server roll in (D)TLS. In > particular, clients act as both the client and server in DTLS for > WebRTC. Consequently, there always needs to be a way for the server to > NOT say what time it thinks it is. > > Cheers, > Brian > > [0] https://www.ietf.org/mail-archive/web/tls/current/msg10861.html > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --14dae9cc9c94ffba150512fed9e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 5, 2015 at 11:11 AM, Brian Smith <brian@briansmith.org<= /a>> wrote:
Dave Garrett <= ;davemgarrett@gmail.com> w= rote:
> Consensus was to drop time from the random fields.

Right.

> Prohibiting non-random in ServerHello.random and adding a 4 byte uint3= 2 ServerHello.time for TLS 1.3+ seems like a really simple solution.

What problem does it solve?

> (note that ServerHello is already changed by dropping compression_meth= od)

That seems unnecessary to me. compression_method could/should just b= e
fixed to be "null", avoiding unnecessary compatibility risk.

I think I agree with this, actually.
=
this comment.


-Ekr=
=C2=A0

> The ability of a client to sanity check or sync its time seems like so= mething worth having, especially for only a 4 byte cost.

The client can sanity check or sync its time using other mechanisms<= br> already, even with earlier versions of TLS. I don't see how adding a time field to ServerHello would help solve that problem.

There may be occasions when the server and client need to sync time,
e.g. if it helps the 0-RTT handshake in some way. But, that should be
done as part of the specification for whatever mechanisms require it.
See the long-ago discussion about this [0].

Keep in mind that we removed the time from the Hello random fields
because they leaked information that made it easier to track clients.
And note that clients often play the server roll in (D)TLS. In
particular, clients act as both the client and server in DTLS for
WebRTC. Consequently, there always needs to be a way for the server to
NOT say what time it thinks it is.

Cheers,
Brian

[0] https://www.ietf.org/mail-archive/web/tls/current/ms= g10861.html

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

--14dae9cc9c94ffba150512fed9e4-- From nobody Sun Apr 5 13:06: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 B5E1F1ACE2C for ; Sun, 5 Apr 2015 13:06: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 uNJd6yLkCFut for ; Sun, 5 Apr 2015 13:06:21 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EB4B1ACE27 for ; Sun, 5 Apr 2015 13:06:21 -0700 (PDT) Received: by qku63 with SMTP id 63so11011273qku.3 for ; Sun, 05 Apr 2015 13:06:20 -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=IH6KwcY6PRaGDuwxDoxeIilCw/MPI3DiNLEtv6HFC70=; b=z0BgV4ri0jIawVYLJUynK4b+zet0rlrESRI+fdeFt1RkfPo4cH8AMKswCceO42m/K5 K9Gg/up6/HSWI1mc6Ew1U8GCmMEUi8OAJNouzr7+ABZj6KUreuEBNMA8GAOMx0ngtTuH Q0Pcwsub66rw2+pPXd5ZrK09R+SgfG3n5VdR20gaIgnTTksAeEBu0zeaBBotCOpkJez0 9UdDavS+5orCs437Nc0KSDqsuDrPk0FeG/ydhV5FchIyaDAt0egUdSwuHYKTVbviEsmQ bbEY8i5b34Jc1TkDtFjkFleE9x42KVOQCCCSpMn6K7VsoTLRZ/JM2xk9sLyp5oalynW0 oG/g== X-Received: by 10.140.145.202 with SMTP id 193mr2226780qhr.43.1428264380275; Sun, 05 Apr 2015 13:06:20 -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 n13sm1721014qkh.8.2015.04.05.13.06.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 05 Apr 2015 13:06:19 -0700 (PDT) From: Dave Garrett To: Brian Smith , Hauke Mehrtens , Jeffrey Walton Date: Sun, 5 Apr 2015 16:06:17 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504041352.12431.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504051606.18088.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2015 20:06:22 -0000 On Saturday, April 04, 2015 06:10:09 pm Jeffrey Walton wrote: > I like the idea of a field like ServerHello.time so the server can > communicate its belief in time. A client can defer a simple failure > based on time until key exchange completes. If key exchange completes > successfully, then the client can decide if it wants to accept the > server's view of time. > > The functionality leads to other attack surfaces, like a rogue server > rolling back its time and using compromised key. But I think that can > be solved with a good degree of certainty using Guttmann's security > diversification techniques. On Sunday, April 05, 2015 12:32:31 pm Hauke Mehrtens wrote: > Adding such a field could also result in some stupid developers using > this field to check if the certificate is valid for every handshake. On Sunday, April 05, 2015 02:11:49 pm Brian Smith wrote: > And note that clients often play the server roll in (D)TLS. In > particular, clients act as both the client and server in DTLS for > WebRTC. Consequently, there always needs to be a way for the server to > NOT say what time it thinks it is. The problems have solutions, but ones that would need to be implemented carefully. In particular, the safest way to handle servers needing time privacy would be to make ServerHello.time the last field, and simply not include it when not desired. (rather than zeroing it out) Unauthenticated time is safe for sanity checking the client time, but relying on it to verify anything as opposed to just rejecting would be bad. Unauthenticated time sync is a far more narrow case that probably isn't worth having for the general case. The above is sufficient to convince me that unauthenticated time in the ServerHello is not likely to be worth the risk in the general case. It's not idiot-proof enough. The time could be integrated elsewhere into the handshake and authenticated, but now it's no longer simple. A basic ping/time protocol would be really simple, though, it'd have to be after the handshake. As to the actual issue #64, fully prohibiting time in the random field entirely seems appropriate, however. That part seems simple enough. As noted by Brian, not doing so allows the time to accidentally be leaked in P2P usage. Dave From nobody Sun Apr 5 18: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 E02411ACED2 for ; Sun, 5 Apr 2015 18:10:39 -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 XgpOYlruMkDG for ; Sun, 5 Apr 2015 18:10:35 -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 6DA6D1ACEC4 for ; Sun, 5 Apr 2015 18:10:35 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so13828463ied.1 for ; Sun, 05 Apr 2015 18:10:34 -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=OBf5P6KH/LPktRQebzukV/a5VWnr4xdS/Hl9oYDNgV4=; b=GEE88PQV+CLXQrILo3pqF5zxUMsXyHGDbwQUSftF06lSIGTHJ0bMad+G6bInbkqXUc oo49z2uGheJtGJavJTIZjH/gu6qzCHnmwigpi8yuOjbQEwkxWQvY6M73+UCfBpaqjHLZ CmL1gcMZwpDcHRCCGm0J7Gm4GijoBe0iKG22k= 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=OBf5P6KH/LPktRQebzukV/a5VWnr4xdS/Hl9oYDNgV4=; b=iRm/HVfHTdU62hUrxZMxybIizO0aoHguI0lg2Qe6AIwu/gepWrAaw9ojeDsJmom1Gq 1BBDM6PzqhrOuGJNoXSjTNBAP/o/cF/n0ZTvPTaCQbV6zP2/KNXVO2fIdGjmBMDpsRLl zmCa3ohct58M0Pu1AnMtkVEWZ+ZYANWKz6TZYuX4i86xeH2VrNpb5ho2hZEflsiCWsxx Eq6yg1nFozXmmGYSNTi8IF5iqaUrcLIGWahhgCkwu+Mrb+XuobcuPBp3UrULQ9TQXtlf Ds2xOc20FVjmmnJVPlrLs10QBg6jhhKDXO/GtzI6Upt9pk7+y8YgBSmEf4gbQwLBiCgT h/mw== X-Gm-Message-State: ALoCoQmOGtbmXSm53UFR36YgBeZ0iU3BJoMRijsdt6vKpq1+M/9i6hw/3+iVlzfTqZWYjAQXdSrK X-Received: by 10.50.225.72 with SMTP id ri8mr19867952igc.48.1428282634844; Sun, 05 Apr 2015 18:10:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.166.84 with HTTP; Sun, 5 Apr 2015 18:10:14 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Sun, 5 Apr 2015 20:10:14 -0500 Message-ID: To: Joseph Salowey Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 01:10:40 -0000 On 3 April 2015 at 15:34, Joseph Salowey wrote: > In the interim meeting we had consensus to use an implicit IV for AEAD. The > proposal was to use the record sequence number and pad with zeros as > described in pull request 155 > (https://github.com/tlswg/tls13-spec/pull/155/files). This was also > discussed in the IETF-92 meeting in Dallas along with options to change the > offset. The consensus was to stay with the original proposal. We are > posting to the mailing list to confirm this consensus. If you have comments, > please reply by April 17, 2015. I apologize if I'm mistaken or this has been raised previously, but I feel compelled to speak up and not assume it has. The record sequence number is predictable. It's not in the clear on the wire, but it begins at 0 and increments with every record. (Right?) This will result in a predictable IV for the AEAD mode. We have two AEAD modes today: - GCM - IV must be unique, being predictable doesn't matter (Right?) - poly1305 - IV/Nonce must be unique, being predictable doesn't matter (Right?) But we also don't know what AEAD modes we will add in the future. I'm far from being 'up' on the CAESER competition, but I skimmed the first ~10 entries, and one, CMCC is based on CBC mode. It seems like a predictable IV = BEAST. Am I right in thinking we will be pigeonholing ourselves into only allowing AEAD modes that do _not_ require an unpredictable IV? -tom From nobody Sun Apr 5 18: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 153F01A1B40 for ; Sun, 5 Apr 2015 18:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.895 X-Spam-Level: * X-Spam-Status: No, score=1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_WORD2_END_DOLLAR=3.294, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 QhWJYEKXjfmc for ; Sun, 5 Apr 2015 18:35:15 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d: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 1BB631A1B47 for ; Sun, 5 Apr 2015 18:35:15 -0700 (PDT) Received: by qcyk17 with SMTP id k17so5334045qcy.1 for ; Sun, 05 Apr 2015 18:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=lHbcfCNJ8Glb/BrunmULDZMBsoX2tfTFtoUC3LANF/M=; b=bUGQxklbh6Obmn+keAyyxtD9pziyT88yRAX1b30dSBNACOkePvNbzhlhC/LUwpmd7M HhrjagGN0C1dT82Vrj4UkPpE3j0NSBRyBWpKpj7r9cOAFrhcWIlVHtxUnPU9P4lvDnDe 2fsNenC6CUsz0c8YN4lU52McfPvNhXVBl45RA3lJ0RjTXkIVaU0MyUzpL2FcixQiJQQq QQtETJRUMKQllNHwSsAW2deKkXz4cCk5FlWne2WlwKdU5A+XWZZ1RvQfgpRKbcBfK2CA 7p3d/3NfIfBTxnqzF+iRNcDofQg+9Fnc0/wR5xwsH/JtnDezyOQ090oIt8A5Sxf/yGX5 iKRw== X-Received: by 10.140.237.140 with SMTP id i134mr15309992qhc.70.1428284114406; Sun, 05 Apr 2015 18:35:14 -0700 (PDT) Received: from hedwig-63.prd.orcali.com (ec2-54-85-253-19.compute-1.amazonaws.com. [54.85.253.19]) by mx.google.com with ESMTPSA id k126sm2190656qhc.42.2015.04.05.18.35.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Apr 2015 18:35:13 -0700 (PDT) Date: Sun, 05 Apr 2015 18:35:13 -0700 (PDT) X-Google-Original-Date: Mon, 06 Apr 2015 01:35:13 GMT MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Message-Id: <1428284113031.414dc341@Nodemailer> In-Reply-To: References: X-Orchestra-Oid: 1C577474-8A60-441B-B607-A1EB4E50FFAF X-Orchestra-Sig: 2db57d4dd6a5b45002135bf16e49a20e21fa35bc X-Orchestra-Thrid: TA0A48A94-F93D-4145-9A0F-E0395A71098E_1497464329329387742 X-Orchestra-Thrid-Sig: 3c3c4fd84f7707b3f19f44ea5bb4465efcd084a5 X-Orchestra-Account: e93509845f7aebbaaed96e49ec387c71ff04dfac From: "David Leon Gil" To: "Tom Ritter" Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1428284113404" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 01:35:17 -0000 ------Nodemailer-0.5.0-?=_1-1428284113404 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In support of Tom, I would note that Namprempre et al.'s EUROCRYPT paper = 'Reconsidering Generic Composition' is relevant:=C2=A0https://eprint.iacr.= org/2014/206.pdf They define a nonce-based AEAD (nAE) scheme as a function (inputs and = outputs are bitstrings): =C2=A0 =C2=A0 (n, ad, p) \rarrow (c, t) and requires that the resulting scheme be IND-CCA$ (=3F) iff =C2=A0 =C2=A0 =C2=A0$\forall m, \nexist m', m.ad =3D m'.ad \wedge m.n =3D = m'.n \wedge m.p \nea m'.p$ I would strongly suggest that the TLS 1.3 recommendation impose this = requirement for any AEAD suites specified in future. -- Or, more simply: IVs must be indistinguishable from random bytes. Nonces = must simply be unique. Assuming that the 'IV' input to the TLS AEAD functions is predictable, it = isn't an IV. It's a nonce. Please call it that, and disallow ivAE schemes. =E2=80=94 Sent using alpine: an Alternatively Licensed Program for Internet News and = Email On Sun, Apr 5, 2015 at 6:10 PM, Tom Ritter wrote: > On 3 April 2015 at 15:34, Joseph Salowey wrote: >> In the interim meeting we had consensus to use an implicit IV for AEAD. = The >> proposal was to use the record sequence number and pad with zeros as >> described in pull request 155 >> (https://github.com/tlswg/tls13-spec/pull/155/files). This was also >> discussed in the IETF-92 meeting in Dallas along with options to change = the >> offset. The consensus was to stay with the original proposal. We are >> posting to the mailing list to confirm this consensus. If you have = comments, >> please reply by April 17, 2015. > I apologize if I'm mistaken or this has been raised previously, but I > feel compelled to speak up and not assume it has. > The record sequence number is predictable. It's not in the clear on > the wire, but it begins at 0 and increments with every record. > (Right=3F) > This will result in a predictable IV for the AEAD mode. We have two > AEAD modes today: > - GCM - IV must be unique, being predictable doesn't matter (Right=3F) > - poly1305 - IV/Nonce must be unique, being predictable doesn't matter = (Right=3F) > But we also don't know what AEAD modes we will add in the future. I'm > far from being 'up' on the CAESER competition, but I skimmed the first > ~10 entries, and one, CMCC is based on CBC mode. It seems like a > predictable IV =3D BEAST. Am I right in thinking we will be > pigeonholing ourselves into only allowing AEAD modes that do =5Fnot=5F > require an unpredictable IV=3F > -tom > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ------Nodemailer-0.5.0-?=_1-1428284113404 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In support of Tom, I would note that Namprempre et al.'s EUROCRYPT = paper 'Reconsidering Generic Composition' is relevant:=C2=A0https://eprint.iacr.= org/2014/206.pdf

They define a nonce-based AEAD (nAE) scheme as a function (inputs and = outputs are bitstrings):

=C2=A0 =C2=A0 (n, ad, p) \rarrow (c, t)

and requires that the resulting scheme be IND-CCA$ (=3F) iff

=C2=A0 =C2=A0 =C2=A0$\forall m, \nexist m', m.ad =3D m'.ad \wedge m.n = =3D m'.n \wedge m.p \nea m'.p$

I would strongly suggest that the TLS 1.3 recommendation impose this = requirement for any AEAD suites specified in future.

--

Or, more simply: IVs must be indistinguishable from random bytes. = Nonces must simply be unique.

Assuming that the 'IV' input to the TLS AEAD functions is predictable,= it isn't an IV. It's a nonce. Please call it that, and disallow ivAE = schemes.

=E2=80=94
Sent using alpine: an Alternatively Licensed Program for = Internet News and Email


On Sun, Apr 5, 2015 at 6:10 PM,= Tom Ritter <tom@ritter.vg> = wrote:

On 3 April 2015 = at 15:34, Joseph Salowey <joe@salowey.net> wrote:
> In the interim meeting we had consensus to use an implicit IV for = AEAD. The
> proposal was to use the record sequence number and pad with zeros = as
> described in pull request 155
> (https://github.com/tlswg/tls13-spec/pull/155/files). This was = also
> discussed in the IETF-92 meeting in Dallas along with options to = change the
> offset. The consensus was to stay with the original proposal. We= are
> posting to the mailing list to confirm this consensus. If you have= comments,
> please reply by April 17, 2015.


I apologize if I'm mistaken or this has been raised previously,= but I
feel compelled to speak up and not assume it has.

The record sequence number is predictable. It's not in the clear = on
the wire, but it begins at 0 and increments with every record.
(Right=3F)

This will result in a predictable IV for the AEAD mode. We have = two
AEAD modes today:
- GCM - IV must be unique, being predictable doesn't matter = (Right=3F)
- poly1305 - IV/Nonce must be unique, being predictable doesn't matter= (Right=3F)

But we also don't know what AEAD modes we will add in the future. = I'm
far from being 'up' on the CAESER competition, but I skimmed the first
~10 entries, and one, CMCC is based on CBC mode. It seems like a
predictable IV =3D BEAST. Am I right in thinking we will be
pigeonholing ourselves into only allowing AEAD modes that do =5Fnot=5F
require an unpredictable IV=3F

-tom

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


------Nodemailer-0.5.0-?=_1-1428284113404-- From nobody Sun Apr 5 19:13: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 E490A1A6EFB for ; Sun, 5 Apr 2015 19:13:47 -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 6ukTyvzItDi9 for ; Sun, 5 Apr 2015 19:13:46 -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 92D6B1A6EE1 for ; Sun, 5 Apr 2015 19:13:45 -0700 (PDT) Received: by wiun10 with SMTP id n10so21758111wiu.1 for ; Sun, 05 Apr 2015 19:13: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wfjWzQCCCwr76eC4f7JHjFAcQ0LDLOh09NQJmnAf7q8=; b=TmkpRuBOIlLAur6LsUi8B/+aQ4BZWlxt68Kz2LTLUH8+0ZfNUIOrHdBc2Sn/+1BcMb ZnKy91069IEW+hn73crh7aEmlVMVTDhPLqPKGU9TfWggpqGmGGjVJ8MLQT9cWWFvBdJP yTlAGsgZk6jBNlNBsl+GaVhWPCFtENJrBfmGmNqq6MDh7waYsslriiGds5E390u5dJl4 MOqn0k+BwYc3LBKyvN06g0BEpOBUBcj5txexpZ1jrQf4l1JSIGKLi+f5qkCNAnIMdvCN 8ZT7QEbwF/eyDfLHuNlxJZfGxzx55P947zKQgXIJWLcQXKZtJ2CtGVT0JQ++YKVjMu6Q K2dw== X-Gm-Message-State: ALoCoQkaiRbKIIJoALP/oaBY1NLV0hcTfqrkHd3/pnq9b+3DzS+rOY/alLp82ltqTd5EqSfpNpNm X-Received: by 10.180.91.11 with SMTP id ca11mr55391441wib.10.1428286424335; Sun, 05 Apr 2015 19:13:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Sun, 5 Apr 2015 19:13:04 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 5 Apr 2015 19:13:04 -0700 Message-ID: To: Tom Ritter Content-Type: multipart/alternative; boundary=f46d043c7e76f5db30051304d86e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 02:13:48 -0000 --f46d043c7e76f5db30051304d86e Content-Type: text/plain; charset=UTF-8 On Sun, Apr 5, 2015 at 6:10 PM, Tom Ritter wrote: > On 3 April 2015 at 15:34, Joseph Salowey wrote: > > In the interim meeting we had consensus to use an implicit IV for AEAD. > The > > proposal was to use the record sequence number and pad with zeros as > > described in pull request 155 > > (https://github.com/tlswg/tls13-spec/pull/155/files). This was also > > discussed in the IETF-92 meeting in Dallas along with options to change > the > > offset. The consensus was to stay with the original proposal. We are > > posting to the mailing list to confirm this consensus. If you have > comments, > > please reply by April 17, 2015. > > > I apologize if I'm mistaken or this has been raised previously, but I > feel compelled to speak up and not assume it has. > > The record sequence number is predictable. It's not in the clear on > the wire, but it begins at 0 and increments with every record. > (Right?) > > This will result in a predictable IV for the AEAD mode. We have two > AEAD modes today: > - GCM - IV must be unique, being predictable doesn't matter (Right?) > - poly1305 - IV/Nonce must be unique, being predictable doesn't matter > (Right?) > > But we also don't know what AEAD modes we will add in the future. I'm > far from being 'up' on the CAESER competition, but I skimmed the first > ~10 entries, and one, CMCC is based on CBC mode. It seems like a > predictable IV = BEAST. Am I right in thinking we will be > pigeonholing ourselves into only allowing AEAD modes that do _not_ > require an unpredictable IV? I think we are restricting ourselves to AEAD modes that allow a predictable nonce (this is the 5116 terminology). However, it's worth noting two points about this: 1. All of the proposed constructions use related nonces in the sense that if you knew the nonce for a single record, you could derive the nonce for all records sent in that direction. 2. A predictable nonce does not mean that you have a predictable IV for an underlying cipher. For instance, as AGL noted in a previous e-mail [0], it is possible to construct an unpredictable IV from a predictable nonce. -Ekr [0] https://www.ietf.org/mail-archive/web/tls/current/msg15533.html > > -tom > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043c7e76f5db30051304d86e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 5, 2015 at 6:10 PM, Tom Ritter <tom@ritter.vg> w= rote:
On 3 April 2015= at 15:34, Joseph Salowey <joe@salowe= y.net> wrote:
> In the interim meeting we had consensus to use an implicit IV for AEAD= .=C2=A0 The
> proposal was to use the record sequence number and pad with zeros as > described in pull request 155
> (https://github.com/tlswg/tls13-spec/pull/155/files).=C2=A0 = This was also
> discussed in the IETF-92 meeting in Dallas along with options to chang= e the
> offset.=C2=A0 The consensus was to stay with the original proposal.=C2= =A0 We are
> posting to the mailing list to confirm this consensus. If you have com= ments,
> please reply by April 17, 2015.


I apologize if I'm mistaken or this has been raised previou= sly, but I
feel compelled to speak up and not assume it has.

The record sequence number is predictable. It's not in the clear on
the wire, but it begins at 0 and increments with every record.
(Right?)

This will result in a predictable IV for the AEAD mode.=C2=A0 We have two AEAD modes today:
=C2=A0- GCM - IV must be unique, being predictable doesn't matter (Righ= t?)
=C2=A0- poly1305 - IV/Nonce must be unique, being predictable doesn't m= atter (Right?)

But we also don't know what AEAD modes we will add in the future.=C2=A0= I'm
far from being 'up' on the CAESER competition, but I skimmed the fi= rst
~10 entries, and one, CMCC=C2=A0 is based on CBC mode. It seems like a
predictable IV =3D BEAST.=C2=A0 Am I right in thinking we will be
pigeonholing ourselves into only allowing AEAD modes that do _not_
require an unpredictable IV?

I think we are= restricting ourselves to AEAD modes that allow a predictable
non= ce (this is the 5116 terminology). However, it's worth noting two point= s
about this:

1. All of the proposed con= structions use related nonces in the sense that
if you knew the n= once for a single record, you could derive the nonce
for all reco= rds sent in that direction.

2. A predictable nonce= does not mean that you have a predictable IV
for an underlying c= ipher. For instance, as AGL noted in a previous
e-mail [0], it is= possible to construct an unpredictable IV from a predictable
non= ce.

-Ekr
=C2=A0

-tom

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

--f46d043c7e76f5db30051304d86e-- From nobody Sun Apr 5 21:07: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 D940B1A0406; Fri, 3 Apr 2015 13:50:53 -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 zrsXgLmGQ97A; Fri, 3 Apr 2015 13:50:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8F51A037B; Fri, 3 Apr 2015 13:50:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150403205046.26518.89784.idtracker@ietfa.amsl.com> Date: Fri, 03 Apr 2015 13:50:46 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Sun, 05 Apr 2015 21:07:15 -0700 Subject: [TLS] ID Tracker State Update Notice: 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, 03 Apr 2015 20:50:54 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ From nobody Sun Apr 5 21:07: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 ED1941A8872; Fri, 3 Apr 2015 19:07:12 -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 N3QExKwIPArY; Fri, 3 Apr 2015 19:07:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5F41A87B3; Fri, 3 Apr 2015 19:07:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150404020711.31136.5516.idtracker@ietfa.amsl.com> Date: Fri, 03 Apr 2015 19:07:11 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Sun, 05 Apr 2015 21:07:15 -0700 Subject: [TLS] ID Tracker State Update Notice: 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, 04 Apr 2015 02:07:13 -0000 Last call has been made for draft-ietf-tls-negotiated-ff-dhe and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ From nobody Mon Apr 6 01: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 E0D511A1BF2 for ; Mon, 6 Apr 2015 01:41: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 nOK8Yf_5KI-T for ; Mon, 6 Apr 2015 01:41:43 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::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 02EE81A1BEF for ; Mon, 6 Apr 2015 01:41:43 -0700 (PDT) Received: by wgbdm7 with SMTP id dm7so21599997wgb.1 for ; Mon, 06 Apr 2015 01:41: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=jQsZ8HjdhXneDsnAyiqjO1RannF63koaWj1SPn2wAVo=; b=UHZqmOsrkQ38Fckta935r8eXWKJ0v0tXKz/6EpCzWUQpM3Krt7PkYJ/LjCwlSu+ZSs H67NGsEYEow2OTdZpzwKMsZzL7YQSJNs5GZ8cej4FVo672dJYNN9rjLxs/qfTgKGDuaN Doh++YvLxPOCv5TkuUr9llTFeVbwkhGNbfdMuzSfPw3ueuiDpbXzl00yD4mQqk1OC6+N F09dt99NKlUzFLCK1v4gAZzzB4+ephb5b+HCTiGQNIFNF9vnzx/yYrAPb4LDsHzUg2cb jvrNdbA84gAWiEVc+sFrIYobmliPqF47/M+4BfzlqZ7tVfuPW0rVKKQht55zzVGGMQ37 edjw== X-Received: by 10.194.222.135 with SMTP id qm7mr29559747wjc.14.1428309701799; Mon, 06 Apr 2015 01:41:41 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id g8sm5588651wiy.19.2015.04.06.01.41.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Apr 2015 01:41:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Mon, 6 Apr 2015 11:41:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <16A0B45C-5631-4270-9888-7E9FB90481DC@gmail.com> References: To: Tom Ritter X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 08:41:45 -0000 > On Apr 6, 2015, at 4:10 AM, Tom Ritter wrote: >=20 > On 3 April 2015 at 15:34, Joseph Salowey wrote: >> In the interim meeting we had consensus to use an implicit IV for = AEAD. The >> proposal was to use the record sequence number and pad with zeros as >> described in pull request 155 >> (https://github.com/tlswg/tls13-spec/pull/155/files). This was also >> discussed in the IETF-92 meeting in Dallas along with options to = change the >> offset. The consensus was to stay with the original proposal. We = are >> posting to the mailing list to confirm this consensus. If you have = comments, >> please reply by April 17, 2015. >=20 >=20 > I apologize if I'm mistaken or this has been raised previously, but I > feel compelled to speak up and not assume it has. >=20 > The record sequence number is predictable. It's not in the clear on > the wire, but it begins at 0 and increments with every record. > (Right?) Yes, and in DTLS it=E2=80=99s even transmitted on the wire. > This will result in a predictable IV for the AEAD mode. We have two > AEAD modes today: > - GCM - IV must be unique, being predictable doesn't matter (Right?) > - poly1305 - IV/Nonce must be unique, being predictable doesn't matter = (Right?) Yes to both questions. There=E2=80=99s also CCM and OCB and it=E2=80=99s = true for them as well. > But we also don't know what AEAD modes we will add in the future. I'm > far from being 'up' on the CAESER competition, but I skimmed the first > ~10 entries, and one, CMCC is based on CBC mode. It seems like a > predictable IV =3D BEAST. Am I right in thinking we will be > pigeonholing ourselves into only allowing AEAD modes that do _not_ > require an unpredictable IV? So either IVs (actually nonces) are compressible only for such = ciphersuites that support using the record counter as nonce/IV (add a = flag to the registry), or else we use some method such as AGL=E2=80=99s = for generating unpredictable IVs from predictable nonces. Yoav= From nobody Mon Apr 6 04:15: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 4B8781A8777 for ; Mon, 6 Apr 2015 04:15:53 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 lVCMN7_HwMef for ; Mon, 6 Apr 2015 04:15:51 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5D61A876A for ; Mon, 6 Apr 2015 04:15:49 -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=1428318951; x=1459854951; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=6fo4kKG6YOyGgfyjj3mme+XRs7j/napLPlVJZ2W8qyk=; b=A3oUxh+0q7sG6b1Y5KAK0M4BtXryY7HHPrKSm/00G2ZGQsJ86/7NWPXg z8NIjN/K1davg/h6LnUml+YTaKfRJOtzhBlkyQWrGF6Q5jDrej0Js3Hwa XMMAcvoZ5EwVhwlZbBXcW7Swinlk+2Vfi199A46PtZPn4SKpsXylvY7ZG c=; X-IronPort-AV: E=Sophos;i="5.11,531,1422874800"; d="scan'208";a="319095299" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Apr 2015 23:15:46 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.245]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Mon, 6 Apr 2015 23:15:45 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Server time Thread-Index: AdBwWwZWLI5EjwU2QTib8HL0ZtCF+w== Date: Mon, 6 Apr 2015 11:15:44 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFDB939@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] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 11:15:53 -0000 Dave Garrett writes:=0A= =0A= >adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really= =0A= >simple solution. (note that ServerHello is already changed by dropping=0A= >compression_method)=0A= =0A= It's also a really dangerous solution. All of PKI is critically dependent = on=0A= everyone having the correct time. For a server to advertise the fact that = its=0A= clock is off, and thus revoked and expired certs will still be regarded as= =0A= valid (among other things) is a really bad idea.=0A= =0A= >The ability of a client to sanity check or sync its time seems like someth= ing=0A= >worth having, especially for only a 4 byte cost.=0A= =0A= Given that there's already a globally-deployed dedicated infrastructure tha= t=0A= requires nothing more complicated than sending a single UDP packet to port = 123=0A= and checking the response, turning your TLS server into a sort of proxy tim= e=0A= server that may or may not have the correct time in the first place seems l= ike=0A= a bad idea.=0A= =0A= Peter.= From nobody Mon Apr 6 04:25: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 97E5A1A8795 for ; Mon, 6 Apr 2015 04:25:25 -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 XuH4uBd-TXFs for ; Mon, 6 Apr 2015 04:25:24 -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 BCA2C1A8780 for ; Mon, 6 Apr 2015 04:25:24 -0700 (PDT) Received: by igcau2 with SMTP id au2so17647967igc.1 for ; Mon, 06 Apr 2015 04:25:24 -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=YQjB4Yvlac2r9Xufh9Z9UKDmFv3iTWYueKitqRQVCrU=; b=Nb8jzuoAoml6f/SrVrjhexz9hUOIBw1x8jo4QpLyjLfyzQWwJpcyNoR4kB/eqXshIB h1v2Ju6NhpvTfZI5CllYGc9xKOW4+AScu3szhTYvU4TCwB72KjagS+z5Gn6srKZ7LG4i mYIIMPW3OlKxVxTAS8gLbEeYSsT1v919Z53jw= 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=YQjB4Yvlac2r9Xufh9Z9UKDmFv3iTWYueKitqRQVCrU=; b=lvUQEX5yVAnqohchAx5q8VKPQLEtG2shaDeB+vuEnHUPC4Yx0UZyiqmEihSDjmo+hH ug/gz2sk++nuMtXemUGhY5BwP8UaIMwqM6ajMc+JFpBIVSKndFW1Pi79ez6QgqSyoiOa s525aGFfyq5wbFN/UE286iyaCxmM6Pfz+WKRiZqqPTZ8mlK0VdTH582Vv6kCmmUXoyxU RKACf6kIQINypI1lx/4j3i+suCasRTt7X3ctUO+xGcFcbzhanCabCEYhLnYJ7dRYas4D nIXA96Zl8/OW7xiXal6sWsrNGjjgBFhxxDz+gYQBl5Q5DqNwI84wuKz7Hl/4D0PtJ4LP 0W9g== X-Gm-Message-State: ALoCoQl6XBkr00tWJpwbsd44YGCQdkfEyHLk+ZFwzpmfQoPx6TtEe9w02oID2y2hx3FS0F8TvznD X-Received: by 10.42.84.14 with SMTP id j14mr19250821icl.66.1428319524229; Mon, 06 Apr 2015 04:25:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.166.84 with HTTP; Mon, 6 Apr 2015 04:25:03 -0700 (PDT) In-Reply-To: <16A0B45C-5631-4270-9888-7E9FB90481DC@gmail.com> References: <16A0B45C-5631-4270-9888-7E9FB90481DC@gmail.com> From: Tom Ritter Date: Mon, 6 Apr 2015 06:25:03 -0500 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 11:25:25 -0000 On 6 April 2015 at 03:41, Yoav Nir wrote: > So either IVs (actually nonces) are compressible only for such ciphersuites that support using the record counter as nonce/IV (add a flag to the registry), or else we use some method such as AGL's for generating unpredictable IVs from predictable nonces. Thanks Yoav, ekr, I obviously haven't followed all the arguments here (and from skimming Brian's reply) - but I prefer defining a construction that makes the IV given to the AEAD unpredictable and random. Doing that from a predictable nonce seems okay. -tom From nobody Mon Apr 6 04:35: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 92BA41A87AA for ; Mon, 6 Apr 2015 04:35:15 -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 kXOpm2d46KGg for ; Mon, 6 Apr 2015 04:35:14 -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 906381A87A6 for ; Mon, 6 Apr 2015 04:35:14 -0700 (PDT) Received: by ignm3 with SMTP id m3so17779515ign.0 for ; Mon, 06 Apr 2015 04:35:14 -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=1hIm6BH/dqmd8SGC930EPG3WLPfzDadAETPUczEz9xs=; b=ov10zjc4q/qxrPY7vPVqUeOZilmBmv3zzYaDFMD8DBXlNyi15HVcSlF+oD4oBtWPNC OL4MhNvGRPyrijVuydLEQylZBcTIjZfc43ZCKjdw2sBHb9kcFkDXllAIf2Huxb6b3khn CBC+DKbRYCPMqrbpA8Icxu3avmhlleNlww0uU= 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=1hIm6BH/dqmd8SGC930EPG3WLPfzDadAETPUczEz9xs=; b=JczEKBfP/CuXi8BQbioQP+2mmTqeVMeEtDXgW5gepjYgpjovkic79D/2hjqbmuXmE7 Sqt3RBwNYX3qRv7T1GdJe+ok6U06N5zr3R8udL7gI+qNzDAExMKxewKAFjzAwKoYTUTr Uvd3p1mqoiOGtjGnHPaBxHzszbOjYqWe7FxEJ9r+uZkqGQvLInmBrSdAG5mDp80Bna0E QOsrnZk6rgMR9YWbkVTZZxdC001YV71Aho49O0ZTYvAxnGi+v7yoX4x2oSskQHqs43U4 oSoITBmIfabrkJKc4nRCjUqwWmmYDvj55iydrZnK91Wf+icFRlvVtwHzHa0OD2waC6Qc W+Bg== X-Gm-Message-State: ALoCoQmxHK/gPy7D6+qafU5+WYD9K7vkgecH40ptK0NP70XQer7ZjRebXtRdJdckgJ/5x3XP/+aH X-Received: by 10.107.156.19 with SMTP id f19mr21716275ioe.45.1428320113964; Mon, 06 Apr 2015 04:35:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.166.84 with HTTP; Mon, 6 Apr 2015 04:34:53 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFDB939@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB939@uxcn10-tdc05.UoA.auckland.ac.nz> From: Tom Ritter Date: Mon, 6 Apr 2015 06:34:53 -0500 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 11:35:15 -0000 On 6 April 2015 at 06:15, Peter Gutmann wrote: >>The ability of a client to sanity check or sync its time seems like something >>worth having, especially for only a 4 byte cost. > > Given that there's already a globally-deployed dedicated infrastructure that > requires nothing more complicated than sending a single UDP packet to port 123 > and checking the response, turning your TLS server into a sort of proxy time > server that may or may not have the correct time in the first place seems like > a bad idea. Is it better or worse than relying on a completely unauthenticated protocol to get the time? AGL commented earlier on this topic that ChromeOS uses (a fork of?) tlsdate to set the time securely, and that Google will likely keep some (all?) servers responding with a valid time to support that use case. I don't know what other users of tlsdate (Whonix, etc) point to. I think we can do away with server time in TLS 1.3, and the future solution is TLS 1.2 to a known-good server (or HTTPS for the Date Header) for rough time accuracy and NTP for correcting the skew. -tom From nobody Mon Apr 6 04:44: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 C9BF61A87CC for ; Mon, 6 Apr 2015 04:44:40 -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 eaBhbJqX6_nE for ; Mon, 6 Apr 2015 04:44:39 -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 0DF581A87CA for ; Mon, 6 Apr 2015 04:44:39 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id AD38E1C20F4; Mon, 6 Apr 2015 13:44:36 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 77EDD1FE0241; Mon, 6 Apr 2015 13:44:36 +0200 (CEST) Date: Mon, 6 Apr 2015 13:44:36 +0200 From: Kurt Roeckx To: Peter Gutmann Message-ID: <20150406114436.GA5162@roeckx.be> References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB939@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFDB939@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 11:44:41 -0000 On Mon, Apr 06, 2015 at 11:15:44AM +0000, Peter Gutmann wrote: > >The ability of a client to sanity check or sync its time seems like something > >worth having, especially for only a 4 byte cost. > > Given that there's already a globally-deployed dedicated infrastructure that > requires nothing more complicated than sending a single UDP packet to port 123 > and checking the response, turning your TLS server into a sort of proxy time > server that may or may not have the correct time in the first place seems like > a bad idea. There is work being done to make NTP more secure. But if you don't know what time it is there is no way that we know how to get the correct time in a secure way. About the best you can do is assume that not everybody is compromised. Kurt From nobody Mon Apr 6 05:06: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 5AAD61A8839 for ; Mon, 6 Apr 2015 05:06:01 -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 LivZIoqPFc-r for ; Mon, 6 Apr 2015 05:05:59 -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 3A66C1A8838 for ; Mon, 6 Apr 2015 05:05:57 -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 6BF0C81811; Mon, 6 Apr 2015 15:05:54 +0300 (EEST) Date: Mon, 6 Apr 2015 15:05:54 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150406120554.GA23058@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] 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: Mon, 06 Apr 2015 12:06:01 -0000 On Sun, Mar 22, 2015 at 02:49:28PM -0700, Eric Rescorla wrote: > In the interim in Seattle, we had an extensive discussion of 0-RTT > anti-replay in which DKG observed that all the proposed anti-replay > mechanisms provide limited protection. The underlying problem is the > desire to present a uniform interface in which the calling application > can count on reliable delivery of the data it provides in the first > flight, thus requiring the TLS stack to retransmit it automatically. [...] > The other two options clearly require a separate API to handle this > special first-flight data and would require applications to handle it > separately. So, for instance, in option 2, you would have something > like: > > c = new TLSConnection(...) > c.setReplayable0RTTData("GET /....") > c.connect(); This is on client side, but how about server side? 1) - Server app indicates to TLS stack if it supports 0RTT. - If no support or 0RTT fails, 0RTT is refused and retransmitted data is prefixed into connection data. - If supported and 0RTT transmission succeeds, app can read 0RTT data using separate call. Problem: 0RTT supported but failing (e.g. wrong keys) is a special case for serverside. 2) - Server app indicates to TLS stack if it supports 0RTT. - If no support, this is signaled to client. - If supported but fails, this is signaled to client. - 0RTT data (original or retransmit) is read using separate interface. Problems: 0RTT supported/not supported is two different cases for the client. Retransmit would need to be flagged specially. 3) - If 0RTT fails or not supported, it is refused. - Just prefix 0RTT data into connection data. Prolem: Server can't tell apart 0RTT data from normal data. Also, regarding security considerations due to replayability, would "MUST NOT authenticate in 0RTT data" (which e.g. means cookies that are possibly authenticating can't be sent) be useful consideration? -Ilari From nobody Mon Apr 6 05:46: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 035DA1A885E for ; Mon, 6 Apr 2015 05:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 X8XsdFfV-m-N for ; Mon, 6 Apr 2015 05:46:08 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788B31A885C for ; Mon, 6 Apr 2015 05:46: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=uoa; t=1428324368; x=1459860368; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=u6faKyoByTKUkAhoI9IjzstfzD5ehKV4Ef6xnr1dHWo=; b=lX8l5Z8z+DGD3OGjR5PClbmpOaA7ciQiULb4TW2zL34YqqV4VhBw+z1f hC2J/uffWM35tTxZNf7MimwIwkFwAJf/cX0BLJl96Kl+KjgPnH9DaJhPk zXOfUOKnnNYSf95/aEQ32fNYoCCssv2ssRCHa2UY0QpeQD+xOeb0MQNbg E=; X-IronPort-AV: E=Sophos;i="5.11,531,1422874800"; d="scan'208";a="319102616" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 07 Apr 2015 00:45:59 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.245]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Tue, 7 Apr 2015 00:45:58 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Server time Thread-Index: AdBwZ6GD+C5DBwD+SeCkDTaZlcyh5A== Date: Mon, 6 Apr 2015 12:45:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@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] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 12:46:12 -0000 Tom Ritter writes:=0A= =0A= >Is it better or worse than relying on a completely unauthenticated protoco= l=0A= >to get the time?=0A= =0A= If you really need a secure time source you either use NTPv4 security or ru= n=0A= your own stratum 1. The problem with getting time from the server is, as= =0A= others and I have pointed out, the server may not have the correct time (or= =0A= any time at all for an embedded device), by manipulating the time the clien= t=0A= sees a malicious server can break the client's PKI, and so on.=0A= =0A= Using TLS as a pseudo-NTP source makes about as much sense as using HTTP as= a=0A= pseudo-NTP source, which has happened a number of times in the past. TLS i= s a=0A= means of building a secure tunnel from A to B, not a kludgy way of avoiding= =0A= use of NTP.=0A= =0A= Peter.= From nobody Mon Apr 6 06:08: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 37CAC1A8868 for ; Mon, 6 Apr 2015 06:08:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 46x0e0P_FSnA for ; Mon, 6 Apr 2015 06:08:48 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6761A870A for ; Mon, 6 Apr 2015 06:08:47 -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=1428325728; x=1459861728; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=F8YuUCHq/Syyhi0THnGAcZaruGx1Q6RXvQWxyIzXzBk=; b=s7Tp0CWgl4m3/uDJTo3fUvBT13Oj5rlLg6MUU7OL5bTwNHUqa/5LOu3R LyB3/dOmvaI54EtfIdEjsswMx1J66Q3Nq26VHfmRiNuX8OmjzovEetOL8 KZWDqCvVeWwfx0ZE0bTi2GhNGanEK4NuqUO+HYtZ83HqNgobGKTWJLr59 s=; X-IronPort-AV: E=Sophos;i="5.11,531,1422874800"; d="scan'208";a="319105118" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 07 Apr 2015 01:08:46 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.245]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 7 Apr 2015 01:08:45 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Killing Algorithms Thread-Index: AdBwatAk2Nmcoo9ATBKVIweLTsO3Xg== Date: Mon, 6 Apr 2015 13:08:45 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFDBA18@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] Killing Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 13:08:49 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >Suppose the TLS WG (or some other part of the IETF or IRTF) places a=0A= >"believed good until" date on every algorithm in the spec. We would commi= t=0A= >to updating this "freshness" estimate some interval before the algorithm= =0A= >"expires". We would ask implementations with access to a "real" clock to= =0A= >commit to disabling each algorithm after its expiration date, unless they= =0A= >recieve notice that the algorithm's expiration has been extended.=0A= =0A= The first thing you'd need to do there is add an explicit exception for=0A= embedded devices/SCADA. The algorithm replacement policy there is "when th= e=0A= hardware fails", typically 10-15 years away minimum. Once something is=0A= deployed, you never touch anything that might trigger a failure of some kin= d,=0A= ever. There are devices out there still using single DES, and that's=0A= perfectly all right because it's secure enough for what they do. Sure, an= =0A= attacker could spend tends of thousands of dollars on a custom-built FPGA D= ES-=0A= breaker and carry out some high-tech attack to bypass network security=0A= controls and mess with a power substation, but the same would be achieved m= uch=0A= more cheaply by slipping some random guy a bag of weed to throw a bike chai= n=0A= over a HV feeder.=0A= =0A= >Some problems i have this proposal (i'm sure there are others too!):=0A= =0A= One not on your list, and one of my favourites:=0A= =0A= * Your device receives a message authenticated with algorithm A saying=0A= "Algorithm B is broken, don't use it", and a message authenticated with= =0A= algorithm B saying "Algorithm A is broken, don't use it".=0A= =0A= There's also the delightful prospect of embedded control engineers drawing= =0A= lots to see who has to flip the break-things switch. Perhaps someone who's= =0A= due to retire shortly anyway.=0A= =0A= >I'd love to hear other concrete proposals for how we can actually effectiv= ely=0A= >deprecate algorithms in the wild, once a deployed base exists.=0A= =0A= For SCADA, you choose a good enough algorithm (and by "good enough" I mean= =0A= good enough for practical use, not good enough for academics), and you stic= k=0A= with it. So there is a de facto way of dealing with this issue, it's "wait= =0A= for the hardware to die".=0A= =0A= Peter.= From nobody Mon Apr 6 06:17: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 755971A8880 for ; Mon, 6 Apr 2015 06:17: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 PoO042scV1-n for ; Mon, 6 Apr 2015 06:17:32 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::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 C58841A87EF for ; Mon, 6 Apr 2015 06:17:31 -0700 (PDT) Received: by wgbdm7 with SMTP id dm7so26660300wgb.1 for ; Mon, 06 Apr 2015 06:17: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=pxVBw4Dj+pw0ggLjFIiNrEA67fFiZN+SyCaZCc5pumY=; b=NDwC+kDlax4ame6a9K7l+l4qxJduZU7Qpl7WE2VdZ7K+FJO1eMG8hXNggpbDxPb6R1 M0ohRW3e3xToXQibooZ+U6frF3bjgMh7mXb6Pyzu7BsUvG+drEjeLjdBcKakyXVjZbRh fIopnRRcWx1+aHPXj9816IiNUyn5Ky5Z8SgcdP116PyD5roSqoc+mnSYDQJ5vsKS+Z21 g6CPifOCA1eY4HlnNnW9uqey9LBd8+E5yT1Rg+vMruaP2SMOkyB69aFZTeW5p/xqYKQu WqrF1IA0q8kiom9WViOAqSKXtgoKwvIZ9AkBcBHEbIiAUBvEAc3qMC6WbeTRLtY0kzEo lzWw== X-Received: by 10.194.121.10 with SMTP id lg10mr31348312wjb.71.1428326250611; Mon, 06 Apr 2015 06:17:30 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id bx3sm6444428wjc.21.2015.04.06.06.17.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Apr 2015 06:17:29 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Mon, 6 Apr 2015 16:17:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <075E6F22-6CA2-4030-A0FF-1E2C5B5CFA5F@gmail.com> References: <16A0B45C-5631-4270-9888-7E9FB90481DC@gmail.com> To: Tom Ritter X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 13:17:33 -0000 > On Apr 6, 2015, at 2:25 PM, Tom Ritter wrote: >=20 > On 6 April 2015 at 03:41, Yoav Nir wrote: >> So either IVs (actually nonces) are compressible only for such = ciphersuites that support using the record counter as nonce/IV (add a = flag to the registry), or else we use some method such as AGL's for = generating unpredictable IVs from predictable nonces. >=20 >=20 > Thanks Yoav, ekr, >=20 > I obviously haven't followed all the arguments here (and from skimming > Brian's reply) - but I prefer defining a construction that makes the > IV given to the AEAD unpredictable and random. Doing that from a > predictable nonce seems okay. That depends. AES-GCM accepts a 64-bit IV. ChaCha20-Poly1305 is the = same. If you feed it random bitstrings, you=92re very likely to repeat a = bitstring after a few billion records, and you have a good chance of = repeating the IV even after many fewer records. So it=92s much better to = use a counter or 64-bit LFSR, even though they=92re predictable. With a = function that receives a 128-bit IV such as AES-CBC, randomization is = fine.=20 A good way for both is to encrypt a counter with a secret key (whether = shared with the other side and then you can omit the IV or not and then = you need to include it), but using a 64-bit cipher (DES?) to generate = random-looking, non-repeating nonces for AES-GCM seems like a very weird = idea. So I=92d rather have a nonce, and require whoever defines an AEAD based = on CBC mode to either add an IV to the payload or define a way to = calculate a non-predictable IV from that nonce. Yoav From nobody Mon Apr 6 06:38: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 D2F1F1A889D for ; Mon, 6 Apr 2015 06:38:24 -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 3k0p44rLqQTh for ; Mon, 6 Apr 2015 06:38:22 -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 949171A875B for ; Mon, 6 Apr 2015 06:38:22 -0700 (PDT) Received: by wgsk9 with SMTP id k9so4518503wgs.3 for ; Mon, 06 Apr 2015 06:38:21 -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=SVePdxGd0f7rAt5m+oiQVX1DzO0MudFPmV8TIDffU/Y=; b=OiNodaMhEcLxdzbGE2dUuA9bkXtvxMfn1U6q/TolTQi4Pi7OsNT3I/ou2gE/PurXey nb0pAf9M3RCCmCKi7U8U2s0TVnupos0iROV+HzmepCQjeyeK9vnyyvlo5dyxMGdgn0dK 6m+fzA9gEY7v09D7hEuSO57ChXh4cJEuJX5Jo9tj5OGjPum1l0HeHBmecwtgcChJ90NF YorEaet2MPkSsVK2eiROTW64s+YdbaKfUV+3ezhQc3nzIbwxRo4rXAWvVZ2KBpvQD8f5 Ro5CdWIYlLww5ieYMwYRH+CuCdl4o61vt7NIIdkzcizsVOMVWxiTcV4c40BqX6kR1MSp 7KGA== MIME-Version: 1.0 X-Received: by 10.180.85.130 with SMTP id h2mr59362209wiz.3.1428327501336; Mon, 06 Apr 2015 06:38:21 -0700 (PDT) Received: by 10.194.5.97 with HTTP; Mon, 6 Apr 2015 06:38:21 -0700 (PDT) In-Reply-To: References: <16A0B45C-5631-4270-9888-7E9FB90481DC@gmail.com> Date: Mon, 6 Apr 2015 09:38:21 -0400 Message-ID: From: Daniel Migault To: Tom Ritter Content-Type: multipart/alternative; boundary=f46d0444e9dd57167405130e69f3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 13:38:25 -0000 --f46d0444e9dd57167405130e69f3 Content-Type: text/plain; charset=UTF-8 We had similar discussions this in IPsecme WG in Dallas [1]. AES-CBC for example would require an unpredictable IV, which makes the IV generation more complex. Keys to generate the IV have to be negotiated and agreed. During the WG session, we agree to limit our scope for the implicit IV on AES-CCM/GCM/CTR and making AES-CBC out of scope. There are at least two ways to remove the IV, either you perform a compression that can be applied to any algorithm or you define specific protocol suites that have an implicit IV. With compression, you may design a mechanism that works with any suite and design the IV compression so highest requirements are fulfilled... hoping no other conditions may be introduced in the future. By defining specific protocols like (AES-CCM_IMPLICIT_IV) the protocol is designed specifically to meet IV properties. The draft presented at IPsecme adopted the second approach. The remaining discussion point raised was how to position this implicit IV protocol with FIPS/NIST Cryptographic Module Validation program. I have not had enough time to check that for now. [1] https://tools.ietf.org/html/draft-mglt-6lo-aes-implicit-iv-01 BR, Daniel On Mon, Apr 6, 2015 at 7:25 AM, Tom Ritter wrote: > On 6 April 2015 at 03:41, Yoav Nir wrote: > > So either IVs (actually nonces) are compressible only for such > ciphersuites that support using the record counter as nonce/IV (add a flag > to the registry), or else we use some method such as AGL's for generating > unpredictable IVs from predictable nonces. > > > Thanks Yoav, ekr, > > I obviously haven't followed all the arguments here (and from skimming > Brian's reply) - but I prefer defining a construction that makes the > IV given to the AEAD unpredictable and random. Doing that from a > predictable nonce seems okay. > > -tom > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson --f46d0444e9dd57167405130e69f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We had similar discussions this in IPsecme = WG in Dallas [1].

AES-CBC for example would require an unpredictabl= e IV, which makes the IV generation more complex. Keys to generate the IV h= ave to be negotiated and agreed. During the WG session, we agree to limit o= ur scope for the implicit IV on AES-CCM/GCM/CTR and making AES-CBC out of s= cope.

There are at least two ways to remove the IV, eithe= r you perform a compression that can be applied to any algorithm or you def= ine specific protocol suites that have an implicit IV. With compression, yo= u may design a mechanism that works with any suite and design the IV compre= ssion so highest requirements are fulfilled... hoping no other conditions m= ay be introduced in the future. By defining specific protocols like (AES-CC= M_IMPLICIT_IV) the protocol is designed specifically to meet IV properties.= The draft presented at IPsecme adopted the second approach.

The rem= aining discussion point raised was how to position this implicit IV protoco= l with FIPS/NIST Cryptographic Module Validation program. I have not had en= ough time to check that for now.


[1] https://tools.ietf.org= /html/draft-mglt-6lo-aes-implicit-iv-01
BR,
Daniel





On Mon, Apr 6= , 2015 at 7:25 AM, Tom Ritter <tom@ritter.vg> wrote:
On 6 April 2015 at 03:41, Yoav Nir = <ynir.ietf@gmail.com> wrot= e:
> So either IVs (actually nonces) are compressible only for such ciphers= uites that support using the record counter as nonce/IV (add a flag to the = registry), or else we use some method such as AGL's for generating unpr= edictable IVs from predictable nonces.


Thanks Yoav, ekr,

I obviously haven't followed all the arguments here (and from skimming<= br> Brian's reply) - but I prefer defining a construction that makes the IV given to the AEAD unpredictable and random. Doing that from a
predictable nonce seems okay.

-tom

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



--
Daniel Migault
Eri= csson
--f46d0444e9dd57167405130e69f3-- From nobody Mon Apr 6 09:14: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 19FB71A8AF5 for ; Mon, 6 Apr 2015 09:14: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 3_hq0xOQLov4 for ; Mon, 6 Apr 2015 09:13:59 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003: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 680991A8AF6 for ; Mon, 6 Apr 2015 09:13:59 -0700 (PDT) Received: by obvd1 with SMTP id d1so47578812obv.0 for ; Mon, 06 Apr 2015 09:13:58 -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=UpQSg+4rScl8vXRI0s2oLw6gapaU+1VBjQJTkCRqY/4=; b=I4ltEE2CLzcOvt/h0nI5wRKvtpODAATKLmXvWIe7qEwDf17o8AcasvVN2RK5Sy4d1i BAyJFn7znrENj7+C6S2afIXs6IW1R9GUEnKaPrkQGKFsh5z1MEol1mEjcT61ng3PSTw3 liG/NvaVaISbjakqka/Scy1kXQSVzis1MNaNWctjt7okblM88YEvOuaNeNfQGaHoFuMn MmiWNnYpcRwTdl6B/OLz7oTEsgN+r+w8XKLw851Z9Mm1tOXte3Z5K10NQfvd9Y/uEZ0F atTKszJutAhc4jEkJDOymPU9oC5b5iFTlhh3GHfHU43Qz8Kb4lV6/uVYVEco2pCcNVnZ c+6A== MIME-Version: 1.0 X-Received: by 10.60.15.133 with SMTP id x5mr13967632oec.80.1428336838838; Mon, 06 Apr 2015 09:13:58 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 6 Apr 2015 09:13:58 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Mon, 6 Apr 2015 09:13:58 -0700 Message-ID: From: Martin Thomson To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 16:14:01 -0000 On 6 April 2015 at 05:45, Peter Gutmann wrote: > Using TLS as a pseudo-NTP source makes about as much sense as using HTTP as a > pseudo-NTP source, which has happened a number of times in the past. TLS is a > means of building a secure tunnel from A to B, not a kludgy way of avoiding > use of NTP. Yes, this is right. There's nothing inherently wrong with using a HTTP server that you trust to have good time for a little sanity checking. That said, it doesn't make any sense to use arbitrary servers. From nobody Mon Apr 6 09: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 F1AA51A8AFC for ; Mon, 6 Apr 2015 09:24:27 -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 UqYJ-xTKxMmB for ; Mon, 6 Apr 2015 09:24:25 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003: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 AFC631A8FD3 for ; Mon, 6 Apr 2015 09:24:10 -0700 (PDT) Received: by obvd1 with SMTP id d1so48043581obv.0 for ; Mon, 06 Apr 2015 09:24:10 -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=TX+rzYWAUfzwQZM1MH20/0dNK8gQc5d7EBDqFRVjq+k=; b=V1/xJ+71C6med43LcyulaMrv+Y40ozHEnT0yPS03fyPtre0scI/qUyk4f+nE3rb4sE AkxGjIHj3zM4JYtaVMaQf9KLhzC3vBbpg+4cl1QbllSdS2ZBICHoyzEpWiU4wwRZ7GEF 6gnho1UmFrim44eIS6v+3vZ4nlVzcKWQ1xKa7c8zFYbJpUr1NjHIjqMR2vc89klOJmrR NTX4oVHhvfr1kBI2A9VctGlpHkfim7+z81PM1AaetxT9XmfbqQ0jEsqgG/xBv/Sbgb9l SryvK0UxIbAiPjDoQdHRrxJf6ug/LiURj+2Kq6vi9t1xy8QKy7Q6F/cKbCEA0jvbTNnv me9w== MIME-Version: 1.0 X-Received: by 10.60.15.133 with SMTP id x5mr14024614oec.80.1428337449421; Mon, 06 Apr 2015 09:24:09 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 6 Apr 2015 09:24:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Apr 2015 09:24:09 -0700 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 16:24:28 -0000 On 3 April 2015 at 20:17, Brian Smith wrote: > a clear record of my objection to the > zero-padding mechanism on the mailing list, For the record then, the objection was this: If you are concerned that someone might spend a large amount of computing resources (2^60+ iterations) to gain themselves a reasonable chance of decrypting a randomly selected session from a similar sized set of sessions, pick a stronger cipher. There's a history of attempting to paper over perceived weaknesses in the crypto we use. I get the belt and braces approach here, but I'd rather see us develop stronger constructions (ChaCha+Poly uses a longer key, for example). If the complaint is specific to AES-GCM, I see nothing stopping someone from proposing AES-GCMv2 that operates on extra keying material internally in order to make the IV unpredictable. I'd rather keep the nonce sane though, it keeps it easy to reason about the construction. From nobody Mon Apr 6 09:31: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 8B2ED1A8826 for ; Mon, 6 Apr 2015 09:31: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 pFToojZyBjqp for ; Mon, 6 Apr 2015 09:30:59 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::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 298971A87B9 for ; Mon, 6 Apr 2015 09:30:59 -0700 (PDT) Received: by ierf6 with SMTP id f6so25107322ier.2 for ; Mon, 06 Apr 2015 09:30:58 -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=sEimj0EEihNfxCc2hlohoHLa4BBRz7bIkeR4PKUWsNw=; b=sXk1hOucEWk3WqjVDhyKkq1O9vWocfuWYKCRfUf1B24TQqHTEps4FhaMHvs+G0R5z3 oDCxgxs/aEAK9NxlogxxM1G+A06PZVa+QbpueiGsJzSZnKIG3IxCb+zz3TOw6LP0F03l Pmcgs87E++WIXt8oVoMaeD+JnkdSm0h6ao/mdYZKys8HXvcieucSWwZXWRGW3TIhVrTx MeWZG3mniJN87ifaCLTh+r9gkUVvdCFjcTI9m+sWBNT+bksYObINvhSyvwSuEA7Lqm7f bcrKR5pDiwOq3ZUaqUUB4I85s2NCc+lj1f/DWzC9zUrLx2fOZi3as4L/aW9HgFcKZA+M 46cQ== MIME-Version: 1.0 X-Received: by 10.42.111.68 with SMTP id t4mr20441642icp.36.1428337858649; Mon, 06 Apr 2015 09:30:58 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 6 Apr 2015 09:30:58 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Mon, 6 Apr 2015 12:30:58 -0400 Message-ID: From: Jeffrey Walton To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Server time 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: Mon, 06 Apr 2015 16:31:00 -0000 On Mon, Apr 6, 2015 at 12:13 PM, Martin Thomson wrote: > On 6 April 2015 at 05:45, Peter Gutmann wrote: >> Using TLS as a pseudo-NTP source makes about as much sense as using HTTP as a >> pseudo-NTP source, which has happened a number of times in the past. TLS is a >> means of building a secure tunnel from A to B, not a kludgy way of avoiding >> use of NTP. > > Yes, this is right. There's nothing inherently wrong with using a > HTTP server that you trust to have good time for a little sanity > checking. That said, it doesn't make any sense to use arbitrary > servers. +1. That was the exact use case I was envisioning - an LG refrigerator abandons the browser security model and pins to LG's CA. In this case, it trusts its own organization's PKI and servers (but no others). Jeff From nobody Mon Apr 6 09: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 D8DED1A89A6 for ; Mon, 6 Apr 2015 09:46:50 -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 7GbqF3ti1FKU for ; Mon, 6 Apr 2015 09:46:46 -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 DEC711A89A7 for ; Mon, 6 Apr 2015 09:46:45 -0700 (PDT) Received: by widdi4 with SMTP id di4so36285318wid.0 for ; Mon, 06 Apr 2015 09:46: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; bh=gkRVJ8uAEtySBrda/86SrGYZ5L4aNSobqdipEbUi5Bw=; b=nJhqCwm+UwC993cQA0hloOK33eQTbD6fjhraXuo14LtOC4YJ3pjvdCmQ3F1t9hUhSn TM3k+WAzo0Vo+9jASxNJvPgUK2GAcNW/Z90CJEODMYaURcuSokYMwJI53/aMGJ40Kn4V hyYdilCJPAbIQH3WILqIVd97Cxz0eU8fvCn5bpvJ+H1p2G03ciCNmkhYLfn6iEy1xXqu /opjK6GGdi8lsQYlr/Cwv8juCHMKuSLC/s+bI7uo3tfks+Fcv0uDWLQzU6RCdokGMWRo sVPTqWYSEXdSY7cKuNSupWnL7SEo9NNx86Fwc3hhzNuOITo3OS4uE8aQuO14eTlT2r6P XDww== MIME-Version: 1.0 X-Received: by 10.180.23.99 with SMTP id l3mr15346854wif.25.1428338804527; Mon, 06 Apr 2015 09:46:44 -0700 (PDT) Received: by 10.194.5.97 with HTTP; Mon, 6 Apr 2015 09:46:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Apr 2015 12:46:44 -0400 Message-ID: From: Daniel Migault To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1134291010156d0513110bb5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 16:46:51 -0000 --001a1134291010156d0513110bb5 Content-Type: text/plain; charset=UTF-8 'I'd rather keep the nonce sane though, it keeps it easy to reason about the construction.' This is also the reason I would prefer not involving the nonce. It would also help keeping the design for IPsec and TLS close. On Mon, Apr 6, 2015 at 12:24 PM, Martin Thomson wrote: > On 3 April 2015 at 20:17, Brian Smith wrote: > > a clear record of my objection to the > > zero-padding mechanism on the mailing list, > > For the record then, the objection was this: > > If you are concerned that someone might spend a large amount of > computing resources (2^60+ iterations) to gain themselves a reasonable > chance of decrypting a randomly selected session from a similar sized > set of sessions, pick a stronger cipher. > > There's a history of attempting to paper over perceived weaknesses in > the crypto we use. I get the belt and braces approach here, but I'd > rather see us develop stronger constructions (ChaCha+Poly uses a > longer key, for example). > > If the complaint is specific to AES-GCM, I see nothing stopping > someone from proposing AES-GCMv2 that operates on extra keying > material internally in order to make the IV unpredictable. I'd rather > keep the nonce sane though, it keeps it easy to reason about the > construction. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson --001a1134291010156d0513110bb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
'I'd rather keep the nonce sane though, it ke= eps it easy to reason about the
construction.'

This is also the reason I would prefer not involv= ing the nonce. It would also help keeping the design for IPsec and TLS clos= e.


On Mon, Apr 6, 2015 at 12:24 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 3 April 2015 at 20:17, Brian Smith <brian@briansmith.org> wrote:
> a clear record of my objection to the
> zero-padding mechanism on the mailing list,

For the record then, the objection was this:

If you are concerned that someone might spend a large amount of
computing resources (2^60+ iterations) to gain themselves a reasonable
chance of decrypting a randomly selected session from a similar sized
set of sessions, pick a stronger cipher.

There's a history of attempting to paper over perceived weaknesses in the crypto we use.=C2=A0 I get the belt and braces approach here, but I'= ;d
rather see us develop stronger constructions (ChaCha+Poly uses a
longer key, for example).

If the complaint is specific to AES-GCM, I see nothing stopping
someone from proposing AES-GCMv2 that operates on extra keying
material internally in order to make the IV unpredictable.=C2=A0 I'd ra= ther
keep the nonce sane though, it keeps it easy to reason about the
construction.

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



--
Daniel Migault
Eri= csson
--001a1134291010156d0513110bb5-- From nobody Mon Apr 6 10:36: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 43F3E1A9047 for ; Mon, 6 Apr 2015 10:36:11 -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 xFh0RF2DR0aN for ; Mon, 6 Apr 2015 10:36:09 -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 3B2BA1A9043 for ; Mon, 6 Apr 2015 10:36:09 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 0067E188765; Mon, 6 Apr 2015 20:36:06 +0300 (EEST) Date: Mon, 6 Apr 2015 20:36:06 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150406173606.GA599@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] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 17:36:11 -0000 On Mon, Apr 06, 2015 at 09:24:09AM -0700, Martin Thomson wrote: > On 3 April 2015 at 20:17, Brian Smith wrote: > > a clear record of my objection to the > > zero-padding mechanism on the mailing list, > > For the record then, the objection was this: > > If you are concerned that someone might spend a large amount of > computing resources (2^60+ iterations) to gain themselves a reasonable > chance of decrypting a randomly selected session from a similar sized > set of sessions, pick a stronger cipher. Which stronger cipher? AES-128 doesn't stand losing many bits before becoming too weak, AES-192 is pretty much forgotten (I don't think it even has codepoints) and AES-256 is seemingly being effectively deprecated. > There's a history of attempting to paper over perceived weaknesses in > the crypto we use. I get the belt and braces approach here, but I'd > rather see us develop stronger constructions (ChaCha+Poly uses a > longer key, for example). So remove AES-128 entierely (MUST NOT negotiate) from 1.3? -Ilari From nobody Mon Apr 6 10:47: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 E2A011A9063 for ; Mon, 6 Apr 2015 10:47:25 -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 Wud7Xjx_nzUT for ; Mon, 6 Apr 2015 10:47:24 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91301A9064 for ; Mon, 6 Apr 2015 10:46:53 -0700 (PDT) Received: by obbec2 with SMTP id ec2so51346980obb.3 for ; Mon, 06 Apr 2015 10:46: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=ku58GsKGYQpp7m+MBTYtKNcF/YVu7iBJOxWJ+pe9a3c=; b=WVDtQw9iIN4kz38T5s0oBzkLMdOka85eiD8Pb+0lgw04KEk1kbEIhxbTPNocLBNj2u KsEi5mMr2pNOBR90+xBchs92CtRVVXpY3dxC5Kbg0ScgdOokMzVP7Fnyjfss+MSbMQPD WEl+26YmLaG3QeWw/W+bV6lAusOWi0dF8PAmDnSN1sA9HAsMp7H7Eo/CNeXWaYdSSbrc wAVUwmRhg8g1aV9s3Oz/51CTMT4V01bxvVcyu7RiQF5nixF+2zKj/dDm+ARj2CXVYQm4 KJObB9KkjutPqqTkjZlISn9mtkPYcn7FtIXssd8T+vV4no/wDefZvO1mg+I8PUoBSuqV WXmg== MIME-Version: 1.0 X-Received: by 10.60.15.133 with SMTP id x5mr14439819oec.80.1428342413299; Mon, 06 Apr 2015 10:46:53 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 6 Apr 2015 10:46:52 -0700 (PDT) In-Reply-To: <20150406173606.GA599@LK-Perkele-VII> References: <20150406173606.GA599@LK-Perkele-VII> Date: Mon, 6 Apr 2015 10:46:52 -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] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 17:47:26 -0000 On 6 April 2015 at 10:36, Ilari Liusvaara wrote: > So remove AES-128 entierely (MUST NOT negotiate) from 1.3? Your words, not mine. From nobody Mon Apr 6 13:08: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 438C11A9115 for ; Mon, 6 Apr 2015 13:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_Irjq0OusSi for ; Mon, 6 Apr 2015 13:08:54 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9781A9111 for ; Mon, 6 Apr 2015 13:08:54 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id F4183F984 for ; Mon, 6 Apr 2015 16:08:51 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 955E320042; Mon, 6 Apr 2015 15:08:50 -0500 (CDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFD49FE@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20150402194417.GJ10960@localhost> <201504021612.35877.davemgarrett@gmail.com> <20150402203412.GK10960@localhost> <9A043F3CF02CD34C8E74AC1594475C73AAFD49FE@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 06 Apr 2015 16:08:50 -0400 Message-ID: <87sicd58a5.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Consensus Call on MTI Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 20:08:56 -0000 On Fri 2015-04-03 05:14:21 -0400, Peter Gutmann wrote: > For the other class, those that can run TLS, the reason for running it isn't > to talk to another device running TLS (you use your homebrew protocol for > that), it's so they can be controlled via a web interface. For these devices > the profile is "whatever we need to implement to talk to a web browser/smart > phone/web control/AJAX/whatever". That is the entire device profile. Since > the underlying hardware can't handle this, you get approaches like the ones > I've talked about in the past, 1024-bit keys for everything (perfectly OK for > embedded device security While this profile may be "perfectly OK for embedded device security", once the device is presented to the Internet and to peers like "web browser/smart phone", there's a pretty nasty UI/UX issue: the browser and the smartphone normally don't have any idea that they're talking to a constrained device that doesn't warrant/deserve a high standard of security. Put another way: if we make our browsers willing to accept lower security for our IoT devices, how do we get them to require higher security for confidential messaging applications or banking transactions or video chat? Without a clear UI/UX story to solve this distinction for normal users, a simple assertion that weaker crypto is "perfectly OK" for some class of device puts all the rest of the network at risk. --dkg From nobody Mon Apr 6 16:20: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 E762D1ACE43 for ; Mon, 6 Apr 2015 16:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljUOzPTirpoC for ; Mon, 6 Apr 2015 16:20:19 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003: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 B1AEC1ACE3E for ; Mon, 6 Apr 2015 16:20:19 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so61854925obb.1 for ; Mon, 06 Apr 2015 16:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamcaudill.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZDKYWFhf/ohTmZHjx+eVHxEKzcDwFjZFI4KOau5tWIg=; b=S8tGt+3htTT7c7vga9yvULzyc3gfuXi4EL9psXRCopaCGDmAwgtdQh4mMW9zZlPDQB hgyPGwgBWegKcneeAcHkqUgoLnBLsWDXTuCHRv19MBjsL+Mw/34jffTh01m0yBZSbG1Z asYdb6xFtPFWdbBy0kdHKD3KF+PbW5RGojNTM= 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=ZDKYWFhf/ohTmZHjx+eVHxEKzcDwFjZFI4KOau5tWIg=; b=dllYyOWLuz5MMczSTIbFLJBviYcsZwJwtJqerD2HYs4yAZ8XG0zgdE0hp3en/jt53N ppTCpkqct30UU0KiSZfU94FgBLoPy0AKBhoTcTMatRG61y7A+PENeNLH13sDnpcLv6jm rvwB50TEhk0BoXYqOy6lXxWo5MC80AxVBrex40RWn1tJD5+aiqvPGKuDUSZAF1d9Kb1j hUODfJOUyvWQNd9WLxPU8eMMYjZjUWUyC6V39GBqx3Esgs16sTpax+aJyPshF7AW/rl/ mmQDzCBKgrO8U7Erautl9NpnMwym9b0ZRZGt4R5CCk2TVkbWlFNn6c4iECJVLVNej01j M86w== X-Gm-Message-State: ALoCoQlOdSXyTLiP3O+LRcYRTW6UvjPMD2q7lbxs+8dfUuEIalDFAvaNyf5Hf89lEvJMgiIx3CTw X-Received: by 10.60.147.165 with SMTP id tl5mr13174791oeb.81.1428362419203; Mon, 06 Apr 2015 16:20:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.125.138 with HTTP; Mon, 6 Apr 2015 16:19:58 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> From: Adam Caudill Date: Mon, 6 Apr 2015 19:19:58 -0400 Message-ID: To: noloader@gmail.com Content-Type: multipart/alternative; boundary=047d7b2e4fbe9b83310513168a00 Archived-At: Cc: "" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2015 23:20:21 -0000 --047d7b2e4fbe9b83310513168a00 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 6, 2015 at 12:30 PM, Jeffrey Walton wrote: > On Mon, Apr 6, 2015 at 12:13 PM, Martin Thomson > wrote: > > On 6 April 2015 at 05:45, Peter Gutmann > wrote: > >> Using TLS as a pseudo-NTP source makes about as much sense as using > HTTP as a > >> pseudo-NTP source, which has happened a number of times in the past. > TLS is a > >> means of building a secure tunnel from A to B, not a kludgy way of > avoiding > >> use of NTP. > > > > Yes, this is right. There's nothing inherently wrong with using a > > HTTP server that you trust to have good time for a little sanity > > checking. That said, it doesn't make any sense to use arbitrary > > servers. > +1. That was the exact use case I was envisioning - an LG refrigerator > abandons the browser security model and pins to LG's CA. In this case, > it trusts its own organization's PKI and servers (but no others). > > Jeff > > In certain circumstances, using a HTTPS server as a time source isn't a horrible idea, but why change TLS for such an edge case? To me, this seems like a clear case of trying to address the issue at the wrong level - this adds no security, introduces privacy issues, and introduces further changes for an edge case that could easily be addressed in many other ways. If there are use cases where it is important that time be acquired from an HTTPS, have the server return the timestamp at whatever precision desired as the body of the response to the GET request - it's still simple to work with, and doesn't impact all TLS users as this would. --047d7b2e4fbe9b83310513168a00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 6, 2015 at 12:30 PM, Jeffrey Wal= ton <noloader@gmail.com> wrote:
On Mon, Apr 6, 2015 at 12:13 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 6 April 2015 at 05:45, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
>> Using TLS as a pseudo-NTP source makes about as much sense as usin= g HTTP as a
>> pseudo-NTP source, which has happened a number of times in the pas= t.=C2=A0 TLS is a
>> means of building a secure tunnel from A to B, not a kludgy way of= avoiding
>> use of NTP.
>
> Yes, this is right.=C2=A0 There's nothing inherently wrong with us= ing a
> HTTP server that you trust to have good time for a little sanity
> checking.=C2=A0 That said, it doesn't make any sense to use arbitr= ary
> servers.
+1. That was the exact use case I was envisioning - an LG refrigerat= or
abandons the browser security model and pins to LG's CA. In this case,<= br> it trusts its own organization's PKI and servers (but no others).

Jeff

<= br>
In certain circumstances, using a HTTPS server as a time sour= ce isn't a horrible idea, but why change TLS for such an edge case? To = me, this seems like a clear case of trying to address the issue at the wron= g level - this adds no security, introduces privacy issues, and introduces = further changes for an edge case that could easily be addressed in many oth= er ways.

If there are use cases where it is import= ant that time be acquired from an HTTPS, have the server return the timesta= mp at whatever precision desired as the body of the response to the GET req= uest - it's still simple to work with, and doesn't impact all TLS u= sers as this would.


--047d7b2e4fbe9b83310513168a00-- From nobody Mon Apr 6 16:49: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 A0DB01B2AC7 for ; Mon, 6 Apr 2015 16:49: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 RaKbRuXFHCXP for ; Mon, 6 Apr 2015 16:49:40 -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 4545F1B2AC5 for ; Mon, 6 Apr 2015 16:49:40 -0700 (PDT) Received: by ignm3 with SMTP id m3so3154038ign.0 for ; Mon, 06 Apr 2015 16:49:39 -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=chma8RLsbxzharaHoDChA5Xw90qym+ZSVR0D1/kb354=; b=KWFQydBAOUagyKiQbqXlo33ZFcHwYFovYbERCasFGH90hTHGuat+PTBR8LH+5ww/8N QDlN/6b0PF9i7+RK9UIcy2ZM4oS0ITaOWWxSswRoTByP8hF5h5XnbJowGfgow3KG60Jv mZ0FDgsAE7d2Q1rIP82S5b9JAy321PsbZG+DWMYHSLr0VcNme3m7K2UMuk8+3VENJhVu n3sgUvnFYMzypTBcM61qV4ogNfiqkXHF0BJ00mVtsLJBmYz2Rqa41DWWOuOWarzjuTai F3oKQJUYrS+uxdRh6Z3D/W0z4AnDmArgdxtl0nhEaPnfVJiaPa/qblT7SASLb5UXkJmm Ov/Q== MIME-Version: 1.0 X-Received: by 10.107.29.21 with SMTP id d21mr26633723iod.11.1428364179740; Mon, 06 Apr 2015 16:49:39 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 6 Apr 2015 16:49:39 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Mon, 6 Apr 2015 19:49:39 -0400 Message-ID: From: Jeffrey Walton To: Adam Caudill Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Server time 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: Mon, 06 Apr 2015 23:49:41 -0000 > In certain circumstances, using a HTTPS server as a time source isn't a > horrible idea, but why change TLS for such an edge case? Well, that edge case is going to inundate us in years to come. There will be hundreds of millions of PC sales in a year; hundreds of millions to billions of smartphones sales in a year, and billions of IoT gadget sales in a year. Not to mention all the SmartCard applications that may need it. Is SSL_VERIFY_NONE really the only choice for resource constrained and low end devices? > If there are use cases where it is important that time be acquired from an > HTTPS, have the server return the timestamp at whatever precision desired as > the body of the response to the GET request - it's still simple to work > with, and doesn't impact all TLS users as this would. > Doesn't that set-up the chicken-and-the-egg problem? Channel setup will never occur because of the failed certificate validation due to the time skew at the client. Or maybe it won't matter because the folks programming the system will helpfully add SSL_VERIFY_NONE. Anyway, I'm not arguing either way. I just know what I've experienced in the past, and I expect it to happen again in the future. From nobody Mon Apr 6 19:56: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 88AD41B2DDB for ; Mon, 6 Apr 2015 19:56:20 -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 JFdaQZbjktQi for ; Mon, 6 Apr 2015 19:56:18 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id AE72B1B2DD8 for ; Mon, 6 Apr 2015 19:56:18 -0700 (PDT) Received: from [173.75.83.181] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YfJgU-0003Gu-Uj; Mon, 06 Apr 2015 22:56:15 -0400 Date: Mon, 6 Apr 2015 19:56:12 -0700 From: Bill Frantz To: "Salz, Rich" , Peter Gutmann X-Priority: 3 In-Reply-To: <722ae4fed0e64a1fbfb11ac916337a9f@ustx2ex-dag1mb2.msg.corp.akamai.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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec792a3a8e3a1f8b52aada68ec7ef648c3a1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.181 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Killing Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 02:56:20 -0000 On 4/3/15 at 7:56 AM, rsalz@akamai.com (Salz, Rich) wrote: >>Each implementation of TLS MUST have a technique for effectively turning >>algorithms off. > >This is a no-op; the implementation's method can be "rebuild=20 >and re-install all dependant software" or "keep your licenses=20 >current and download the latest updates from your vendor" It is not quite a NOP. I am willing to agree that everyone=20 reading this list understands the need. What I want is something=20 an auditor can point to and say, unless you have a way to remove=20 unsafe crypto from the application, you are not TLS standard=20 compliant. I want people who come to the standard for guidance=20 to learn that the current state of the art in crypto isn't permanent. It is hard to find the argument that we need several of each=20 type of algorithm in case security problems are found with one=20 if we can't turn it off. My immediate reaction is that having=20 only one of each type of algorithm would be much better because=20 it would eliminate a complex part of TLS, algorithm negotiation.=20 (Further reflection says that that approach might make version=20 negotiation harder. But single algorithm TLS might still be a win.) On 4/6/15 at 6:08 AM, pgut001@cs.auckland.ac.nz (Peter Gutmann) wrote: >For SCADA, you choose a good enough algorithm (and by "good enough" I mean >good enough for practical use, not good enough for academics), and you sti= ck >with it. So there is a de facto way of dealing with this issue, it's "wai= t >for the hardware to die". This approach worries me. Even though SCADA applications don't=20 need secrecy anywhere near as much as they need authentication,=20 the authentication data they are working off can go very stale=20 in the 10-20 year lifespan of industrial equipment. Heck, (I=20 know some industrial equipment which is over 100 years old and=20 still in use. Fortunately, it doesn't have any crypto=20 components.) At a minimum, I would want to be able to update the=20 trust anchors a lot more frequently. Keys can be stolen, and=20 nation state actors, who might want to sabotage industrial=20 equipment, have a long history of successfully stealing keys. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"We used to quip that "password" is the most common 408-356-8506 | password. Now it's 'password1.' Who said=20 users haven't www.pwpconsult.com | learned anything about security?" -- Bruce Schneier From nobody Mon Apr 6 20:25: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 B93BF1B30DE for ; Mon, 6 Apr 2015 20:25: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 UDpYud6quE7H for ; Mon, 6 Apr 2015 20:25:23 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 9ED591B30D6 for ; Mon, 6 Apr 2015 20:25:23 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so70326683obb.2 for ; Mon, 06 Apr 2015 20:25:23 -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=f1ke/JyOue5vN2RKQ7TSCUX9XyZx3hS4CUonAdn66Dg=; b=nsJ6lXwUeRp4KBKHDdUTZOSSClnS2346WlqL6IsFygONNKjJ+Gu7qTm1nuDtIACPQ3 B7xWgxP7QhDVcfPyMeVsElv1vb5KZycMCU/GAccuj2Tc2vCdHTpqqXZ2981m7WgHyPBb 6H/hOI0oreJT28ri9p/7+548IXDj8tq73uey7+EAjE/6/yjV1/RPI7K3DPuTMP3LoJG4 aPoproPsKILvEPPGh/mPGv+QMlAMupVHT1JV41FNHbxBIhHiaOALadVHh4jE0J3ucD0W d95fjO3EUZJSOV5UyPdWbM3/D8B+Ip04iAf5xgs0JNpjdoyhxBpSapqYI0zKrwlLtwUn 0kTQ== X-Received: by 10.182.66.79 with SMTP id d15mr22478133obt.58.1428377123095; Mon, 06 Apr 2015 20:25:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.166.232 with HTTP; Mon, 6 Apr 2015 20:25:02 -0700 (PDT) In-Reply-To: <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.com> From: Tony Arcieri Date: Mon, 6 Apr 2015 20:25:02 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=e89a8fb1fca4070c9b051319f752 Archived-At: Cc: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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, 07 Apr 2015 03:25:25 -0000 --e89a8fb1fca4070c9b051319f752 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 4, 2015 at 4:55 PM, Salz, Rich wrote: > > Please don't change the syntax for negotiating cipher suites. > > +1, for the reasons Brian said. Looks like the opinion of TLS implementers is this far unanimously against this proposal. I would like to give the counterpoint from a TLS user perspective. I am more or less in charge of the ciphersuite selection for a large web site with a lot of users. I find the present means of describing ciphersuites to TLS stacks to be difficult at best. As myself and many others have described, we're essentially being asked to compute the combinatorial explosion of different ciphersuite configurations by hand. Guess what happens when you do that? People make mistakes. I think the TLS libraries should have an easier-to-use configuration format that computes things for me so I don't have to. I understand why TLS implementers are reluctant to provide that. It's more work for them. But so far none of them have said why this is qualitatively bad. The proposed approach of splitting up what is more or less key exchange vs symmetric cipher configuration (please excuse that rough description, I know how deep the rabbit hole under this bikeshed goes) and require you specify both parts in order of preference sounds like it should fit within all of the existing TLS configuration frameworks and notations. People would only use the new syntax with TLS 1.3+ compatible libraries, and it should be fully backwards compatible with the old one. I also think that requiring this sort of configuration could help designers TLS tease out these concepts internally so they aren't colluded into an amorphous mush of algorithms, every possible combination of which a TLS deployer is expected to whitelist. Seems like a huge win to me. So what's the problem from an implementer perspective besides "it'd be hard"? --e89a8fb1fca4070c9b051319f752 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Apr 4, 2015 at 4:55 PM, Salz, Rich <rsalz@akamai.com> wrote:
<= span class=3D"">> Please don't change the syntax for negotiating cip= her suites.

+1, for the reasons Brian said.

Look= s like the opinion of TLS implementers is this far unanimously against this= proposal. I would like to give the counterpoint from a TLS user perspectiv= e.

I am more or less in charge of the ciphersuite = selection for a large web site with a lot of users. I find the present mean= s of describing ciphersuites to TLS stacks to be difficult at best. As myse= lf and many others have described, we're essentially being asked to com= pute the combinatorial explosion of different ciphersuite configurations by= hand. Guess what happens when you do that? People make mistakes. I think t= he TLS libraries should have an easier-to-use configuration format that com= putes things for me so I don't have to. I understand why TLS implemente= rs are reluctant to provide that. It's more work for them. But so far n= one of them have said why this is qualitatively bad.

The proposed approach of splitting up what is more or less key excha= nge vs symmetric cipher configuration (please excuse that rough description= , I know how deep the rabbit hole under this bikeshed goes) and require you= specify both parts in order of preference sounds like it should fit within= all of the existing TLS configuration frameworks and notations. People wou= ld only use the new syntax with TLS 1.3+ compatible libraries, and it shoul= d be fully backwards compatible with the old one.

= I also think that requiring this sort of configuration could help designers= TLS tease out these concepts internally so they aren't colluded into a= n amorphous mush of algorithms, every possible combination of which a TLS d= eployer is expected to whitelist.

Seems like a hug= e win to me. So what's the problem from an implementer perspective besi= des "it'd be hard"?

--e89a8fb1fca4070c9b051319f752-- From nobody Mon Apr 6 22:38: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 32AD71B3175 for ; Mon, 6 Apr 2015 22:38: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 8bZiFoLnPWlr for ; Mon, 6 Apr 2015 22:38:20 -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 396431B3174 for ; Mon, 6 Apr 2015 22:38:20 -0700 (PDT) Received: by wiun10 with SMTP id n10so4649571wiu.1 for ; Mon, 06 Apr 2015 22:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5bRtDsoF2ftglSWuZW/puO5fwM1helskQJyKuTsrqOI=; b=xa6sq+9++N8MO16/IHvif1duDwUpIOuHVJb4/A3NvGMJXAvuApPgMtILN3oIQDPyea FDYuItx+86OHxoKXQAit8f2wA7GTSHdgP7GN5jDkZ9lqGC7qD+OseT/tGs6Drm+Tl+ne 62ISExvb8dFbKLaKcQsHm6wc8H7iOCI6TC2oOj2pVdgcARzSpYG9ZgcT+bBksjoNWIZx ycsFkRjrDAUK2w4KoFD86SOWqwoXen2LmkYTaiOZ9qMccbl0nzBcMt0Yjaq57amkN7nt a/NreHmG1lA0ZKKlQ6rHru6lkBqDH07kKhQDEJTQVkk/OMd2uD+AJ1hq1QMzgMzVsXxp MmtQ== MIME-Version: 1.0 X-Received: by 10.180.75.212 with SMTP id e20mr1330440wiw.26.1428385099000; Mon, 06 Apr 2015 22:38:19 -0700 (PDT) Received: by 10.194.136.233 with HTTP; Mon, 6 Apr 2015 22:38:18 -0700 (PDT) In-Reply-To: <20150406120554.GA23058@LK-Perkele-VII> References: <20150406120554.GA23058@LK-Perkele-VII> Date: Mon, 6 Apr 2015 22:38:18 -0700 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 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: Tue, 07 Apr 2015 05:38:22 -0000 On Mon, Apr 6, 2015 at 5:05 AM, Ilari Liusvaara wrote: > On Sun, Mar 22, 2015 at 02:49:28PM -0700, Eric Rescorla wrote: >> In the interim in Seattle, we had an extensive discussion of 0-RTT >> anti-replay in which DKG observed that all the proposed anti-replay >> mechanisms provide limited protection. The underlying problem is the >> desire to present a uniform interface in which the calling application >> can count on reliable delivery of the data it provides in the first >> flight, thus requiring the TLS stack to retransmit it automatically. > > [...] > >> The other two options clearly require a separate API to handle this >> special first-flight data and would require applications to handle it >> separately. So, for instance, in option 2, you would have something >> like: >> >> c = new TLSConnection(...) >> c.setReplayable0RTTData("GET /....") >> c.connect(); > > This is on client side, but how about server side? > > 1) > > - Server app indicates to TLS stack if it supports 0RTT. > - If no support or 0RTT fails, 0RTT is refused and retransmitted > data is prefixed into connection data. > - If supported and 0RTT transmission succeeds, app can read 0RTT > data using separate call. > > Problem: 0RTT supported but failing (e.g. wrong keys) is a special > case for serverside. > > > 2) > > - Server app indicates to TLS stack if it supports 0RTT. > - If no support, this is signaled to client. > - If supported but fails, this is signaled to client. > - 0RTT data (original or retransmit) is read using separate > interface. > > Problems: 0RTT supported/not supported is two different cases > for the client. Retransmit would need to be flagged specially. > > > 3) > > - If 0RTT fails or not supported, it is refused. > - Just prefix 0RTT data into connection data. > > Prolem: Server can't tell apart 0RTT data from normal data. > > > > Also, regarding security considerations due to replayability, would > "MUST NOT authenticate in 0RTT data" (which e.g. means cookies that are > possibly authenticating can't be sent) be useful consideration? Only if we don't guarantee that the person who sent the 0-RTT data is the same person who carries out the rest of the connection. This seems possible, but I don't know what the right definition is. > > > > -Ilari > > _______________________________________________ > 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 Mon Apr 6 22:51: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 BF2CD1B31AA for ; Mon, 6 Apr 2015 22:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfuKIDZkQ0CZ for ; Mon, 6 Apr 2015 22:51:30 -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 8913B1B31A9 for ; Mon, 6 Apr 2015 22:51:29 -0700 (PDT) Received: by wgyo15 with SMTP id o15so33776183wgy.2 for ; Mon, 06 Apr 2015 22:51:28 -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=hSY08MvdOkjqWeP4kk2h8qyRpb9eGyjT3elwRc5rKBY=; b=NBI0uT/hfydJA9CzoX6oBCPRlRmD1Oqz6WJNvCY0bhCFCKvz2TghQcXHt9vzfz+NuG Qr1snvciC+TPGWfbLIk58fMU/i8BSdIuSwokk5TMbTQEN8MgsDw0JjVSrklyVexn9sDw p0x7anOujR86d7qi86Bs/g7MWOOE3khzokxk8cfPoe3tSCKEQMLscQlfg0sSOA6KoQjK UZsuThCfWqZWHeoOhdw3cWunYhWb6DvjFvOgL9xmSY1JBcclUQkxh5lFYfh4jxAum9JH uQVjMFnAkCX776ENhs0nhsluR2RYGUfCgaPAVLofM23AdLDk502BQuBhW2F9hTgMgM1S j9bA== X-Received: by 10.194.200.194 with SMTP id ju2mr28723920wjc.61.1428385888243; Mon, 06 Apr 2015 22:51:28 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([109.253.134.170]) by mx.google.com with ESMTPSA id hw7sm9324670wjb.24.2015.04.06.22.51.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Apr 2015 22:51:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8A987AA6-2287-4CD0-A808-3EDA7A45B16D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Tue, 7 Apr 2015 08:51:22 +0300 Message-Id: <9721D27E-207C-47EE-83A8-42FE61D50052@gmail.com> References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.com> To: Tony Arcieri X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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, 07 Apr 2015 05:51:32 -0000 --Apple-Mail=_8A987AA6-2287-4CD0-A808-3EDA7A45B16D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 7, 2015, at 6:25 AM, Tony Arcieri wrote: >=20 > On Sat, Apr 4, 2015 at 4:55 PM, Salz, Rich > wrote: > > Please don't change the syntax for negotiating cipher suites. >=20 > +1, for the reasons Brian said. >=20 > Looks like the opinion of TLS implementers is this far unanimously = against this proposal. I would like to give the counterpoint from a TLS = user perspective. I=E2=80=99m a TLS implementer and I kind of like a-la-carte, but = wouldn=E2=80=99t mind either way. Might have something to do with me = having been an IKE implementer before I was a TLS implementer. > I am more or less in charge of the ciphersuite selection for a large = web site with a lot of users. I find the present means of describing = ciphersuites to TLS stacks to be difficult at best. As myself and many = others have described, we're essentially being asked to compute the = combinatorial explosion of different ciphersuite configurations by hand. = Guess what happens when you do that? People make mistakes. I think the = TLS libraries should have an easier-to-use configuration format that = computes things for me so I don't have to. I understand why TLS = implementers are reluctant to provide that. It's more work for them. But = so far none of them have said why this is qualitatively bad. This is about UI, not about wire format. I totally agree that the = OpenSSL string format for specifying ciphersuites is a horrid mess, but = nothing is stopping an implementer from creating an a-la-carte UI and = translating the user preferences to a combinatorial explosion on the = wire. > The proposed approach of splitting up what is more or less key = exchange vs symmetric cipher configuration (please excuse that rough = description, I know how deep the rabbit hole under this bikeshed goes) = and require you specify both parts in order of preference sounds like it = should fit within all of the existing TLS configuration frameworks and = notations. People would only use the new syntax with TLS 1.3+ compatible = libraries, and it should be fully backwards compatible with the old one. So sure, UIs range in sophistication from a set of radio buttons labeled = =E2=80=9Csecure=E2=80=9D, =E2=80=9Cnot so secure=E2=80=9D, and =E2=80=9Cno= t secure=E2=80=9D to a list of ciphersuites, each with a check box next = to it, and those kind of UI choices can be expressed in string = configuration as well.=20 > I also think that requiring this sort of configuration could help = designers TLS tease out these concepts internally so they aren't = colluded into an amorphous mush of algorithms, every possible = combination of which a TLS deployer is expected to whitelist. I think implementers understand what goes on behind the long list of = ciphersuites. > Seems like a huge win to me. So what's the problem from an implementer = perspective besides "it'd be hard=E2=80=9D? There=E2=80=99s always that fear that some combination of algorithms = will turn out to be not secure, while other combinations of each of = those algorithms will be fine. Yoav --Apple-Mail=_8A987AA6-2287-4CD0-A808-3EDA7A45B16D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 7, 2015, at 6:25 AM, Tony Arcieri <bascule@gmail.com> = wrote:

On Sat, Apr 4, 2015 at 4:55 PM, Salz, Rich <rsalz@akamai.com> = wrote:
> Please don't change the syntax for negotiating cipher = suites.

+1, for the reasons Brian said.

Looks like the opinion of TLS = implementers is this far unanimously against this proposal. I would like = to give the counterpoint from a TLS user = perspective.

I=E2=80=99m a TLS implementer and I kind of like = a-la-carte, but wouldn=E2=80=99t mind either way. Might have something = to do with me having been an IKE implementer before I was a TLS = implementer.

I am = more or less in charge of the ciphersuite selection for a large web site = with a lot of users. I find the present means of describing ciphersuites = to TLS stacks to be difficult at best. As myself and many others have = described, we're essentially being asked to compute the combinatorial = explosion of different ciphersuite configurations by hand. Guess what = happens when you do that? People make mistakes. I think the TLS = libraries should have an easier-to-use configuration format that = computes things for me so I don't have to. I understand why TLS = implementers are reluctant to provide that. It's more work for them. But = so far none of them have said why this is qualitatively bad.

This is about UI, not about wire format. I totally = agree that the OpenSSL string format for specifying ciphersuites is a = horrid mess, but nothing is stopping an implementer from creating an = a-la-carte UI and translating the user preferences to a combinatorial = explosion on the wire.

The = proposed approach of splitting up what is more or less key exchange vs = symmetric cipher configuration (please excuse that rough description, I = know how deep the rabbit hole under this bikeshed goes) and require you = specify both parts in order of preference sounds like it should fit = within all of the existing TLS configuration frameworks and notations. = People would only use the new syntax with TLS 1.3+ compatible libraries, = and it should be fully backwards compatible with the old = one.

So sure, UIs range in sophistication from a set of = radio buttons labeled =E2=80=9Csecure=E2=80=9D, =E2=80=9Cnot so = secure=E2=80=9D, and =E2=80=9Cnot secure=E2=80=9D to a list of = ciphersuites, each with a check box next to it, and those kind of UI = choices can be expressed in string configuration as = well. 

I also = think that requiring this sort of configuration could help designers TLS = tease out these concepts internally so they aren't colluded into an = amorphous mush of algorithms, every possible combination of which a TLS = deployer is expected to = whitelist.

I think implementers understand what goes on behind the = long list of ciphersuites.

Seems = like a huge win to me. So what's the problem from an implementer = perspective besides "it'd be = hard=E2=80=9D?

There=E2=80=99s always that fear that some = combination of algorithms will turn out to be not secure, while other = combinations of each of those algorithms will be fine.

Yoav


= --Apple-Mail=_8A987AA6-2287-4CD0-A808-3EDA7A45B16D-- From nobody Mon Apr 6 23: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 539971B31E6 for ; Mon, 6 Apr 2015 23:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 Z2R3KmT3HT8p for ; Mon, 6 Apr 2015 23:09:09 -0700 (PDT) Received: from mail-vn0-f49.google.com (mail-vn0-f49.google.com [209.85.216.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 C10871B31E5 for ; Mon, 6 Apr 2015 23:09:08 -0700 (PDT) Received: by vnbg129 with SMTP id g129so7372756vnb.4 for ; Mon, 06 Apr 2015 23:09:08 -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=Jbn1804+2LnBeSXeGHZEctz7tR94WAT0jwn7mURXVI0=; b=jCMH87XNMyT2izrxfNh/gpjsBwGAx5p5fZylYVbgDt0GW5ghIGNRIWPQwL68VcnCDw zQrHsyqd/JZ4uo4BnxhoVZjYWQlZ5c14t0My+32d7M33hRIMYYWjfLNnEhzl7dYxDIEP IQ7Ciut7VeI3BsfxnAYnEKNU8ZEn/p92s9KNdSjs9klYoXzrW9MxG0QA1kXwxTjYh2m9 ems9KSVoCl3vF7Yqyplb/WBqIkTyxyRza0Or55V+n2KcbgqKeVKeqwa7XnKZZF6HkFAj 76KOuxbMqFtg69KZ6+b7D5k74J0N87AtqsYCaa1kwoGH74jMFluyfSKc99NXP55DF/KB a0sw== X-Gm-Message-State: ALoCoQmzciflVzrlG799rIlNAi2M1Ky09pnIaVoFg3AM8VgAOLeqVdYFghpQTmLGctjYUrLpPsU8 MIME-Version: 1.0 X-Received: by 10.60.82.10 with SMTP id e10mr23366824oey.85.1428386947909; Mon, 06 Apr 2015 23:09:07 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Mon, 6 Apr 2015 23:09:07 -0700 (PDT) In-Reply-To: References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Mon, 6 Apr 2015 20:09:07 -1000 Message-ID: From: Brian Smith To: Tony Arcieri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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, 07 Apr 2015 06:09:11 -0000 Tony Arcieri wrote: > On Sat, Apr 4, 2015 at 4:55 PM, Salz, Rich wrote: >> >> > Please don't change the syntax for negotiating cipher suites. >> >> +1, for the reasons Brian said. > > Looks like the opinion of TLS implementers is this far unanimously against > this proposal. I would like to give the counterpoint from a TLS user > perspective. > > I am more or less in charge of the ciphersuite selection for a large web > site with a lot of users. I find the present means of describing > ciphersuites to TLS stacks to be difficult at best. As myself and many > others have described, we're essentially being asked to compute the > combinatorial explosion of different ciphersuite configurations by hand. As far as I understand, that problem doesn't have much to do with the syntax of cipher suites in the ClientHello, because that problem is about describing to your web server software which cipher suites to enable on the server. > Guess what happens when you do that? People make mistakes. I think the TLS > libraries should have an easier-to-use configuration format that computes > things for me so I don't have to. I understand why TLS implementers are > reluctant to provide that. It's more work for them. But so far none of them > have said why this is qualitatively bad. That can be done already today, without any protocol changes, and without any TLS library changes (at least as far as OpenSSL is concerned). Somebody just needs to write the code to do it. > Seems like a huge win to me. So what's the problem from an implementer > perspective besides "it'd be hard"? The client doesn't always (ever?) want to enable the entire set of (key exchange algorithm * authentication algorithm * encryption algorithm * integrity algorithm) combinations, so a syntax that only allows the client to describe cipher suites by the individual components is too limiting. More generally, an "a la cart" syntax automates the enabling of lots of cipher suites. But, how is enabling lots of cipher suites a good thing? it seems like a bad idea, in general, to me. If we had a need to have clients enable a whole lot more cipher suites, such that the size of the ClientHello would become really large with the current syntax, then that would be a reason to consider a new syntax. But, it seems that when we consider that the old syntax has to be supported for backward compatibility with TLS 1.2 and below, it seems like the set of new cipher suites to enable would have to be quite large before we would enjoy any positive space savings from doing that. Thus, the idea seems counterproductive even considering the area where it would be most likely to help. Finally, there is a lot of value to getting TLS 1.3 done in a reasonable time frame. Cutting unnecessary or counterproductive changes accelerates the schedule while giving us more time to solve more important problems. Cheers, Brian From nobody Mon Apr 6 23:11: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 2E9661B31EB for ; Mon, 6 Apr 2015 23:11:00 -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 ENRqTBoKXpmJ for ; Mon, 6 Apr 2015 23:10:58 -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 1EC531B31E5 for ; Mon, 6 Apr 2015 23:10:58 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 76610402E; Tue, 7 Apr 2015 09:10:55 +0300 (EEST) Date: Tue, 7 Apr 2015 09:10:55 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20150407061055.GA5404@LK-Perkele-VII> References: <20150406120554.GA23058@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 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: Tue, 07 Apr 2015 06:11:00 -0000 On Mon, Apr 06, 2015 at 10:38:18PM -0700, Watson Ladd wrote: > On Mon, Apr 6, 2015 at 5:05 AM, Ilari Liusvaara > wrote: > > > > Also, regarding security considerations due to replayability, would > > "MUST NOT authenticate in 0RTT data" (which e.g. means cookies that are > > possibly authenticating can't be sent) be useful consideration? > > Only if we don't guarantee that the person who sent the 0-RTT data is > the same person who carries out the rest of the connection. This seems > possible, but I don't know what the right definition is. The problems here are: - 0RTT data is replayable (seems there's no way around). - You can't wait for confirmation (connection reaches normal application data capability in 1RTT). Also, in order to client replaying 0RTT not be able to negotiate with replayed 0RTT data, one needs client finished type message, or 0RTT key needs to mixed into session key[1] + encrypted message from client. The corresponding consideration in server earlydata is "MUST NOT be confidential.", since it is sent to unknown recipient. [1] "unified DH-based key exchange" does not get this right, this input is independent from ES input in late key exchange. -Ilari From nobody Mon Apr 6 23:18: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 43ED01A0177 for ; Mon, 6 Apr 2015 23:18:34 -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 E9h6VvGZzLxu for ; Mon, 6 Apr 2015 23:18:32 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003: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 A8ED81A0171 for ; Mon, 6 Apr 2015 23:18:32 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so71926395obb.1 for ; Mon, 06 Apr 2015 23:18: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:from:date:message-id:subject:to :cc:content-type; bh=nl1Dne62LeXwviU7DGY832KbNABOMn4C+MJNqOsgEi0=; b=0Qy7gHWWmwxRw8WWOMLnvYlCo2auwgZbSJf9WE1Lqgp3EC7SAwtu8LoWidNXWwP9Mh HNeMq2kmbs8ZUQ4CBtEjoq5KkWe9MALZ4Av2XmVLTv6VkyVKeJjBm6rj6cVwpjReV4IM Ve0IOw8zlzWattXnN4V4Aaa0iqpqjjxAvUtT8cvJjb7so+GIGLX85p+90Cxt/n0Fe9qp QsjML2kIZvhEA+sf1KDDcrFhRLN2esEucLWYmrPKRCgnJXgzqkZy+ny0Dku3R/gjHC88 NpD37c22ByetLJHTY0Xzm3AABgi5aJhs6i/JL1b1MqPcdE7isi2GOldWQvhCq5QjX3dD OeWQ== X-Received: by 10.182.46.129 with SMTP id v1mr23246786obm.22.1428387512245; Mon, 06 Apr 2015 23:18:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.166.232 with HTTP; Mon, 6 Apr 2015 23:18:12 -0700 (PDT) In-Reply-To: References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.com> From: Tony Arcieri Date: Mon, 6 Apr 2015 23:18:12 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a11c1d9d244e3af05131c627c Archived-At: Cc: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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, 07 Apr 2015 06:18:34 -0000 --001a11c1d9d244e3af05131c627c Content-Type: text/plain; charset=UTF-8 On Mon, Apr 6, 2015 at 10:51 PM, Yoav Nir wrote: > This is about UI, not about wire format. > On Mon, Apr 6, 2015 at 11:09 PM, Brian Smith wrote: > As far as I understand, that problem doesn't have much to do with the > syntax of cipher suites in the ClientHello, because that problem is > about describing to your web server software which cipher suites to > enable on the server. I think some are trying to argue that the problem is deeper than just the user interface, but you're both correct in saying that's where the problem starts. -- Tony Arcieri --001a11c1d9d244e3af05131c627c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 6, 2015 at 10:51 PM, Yoav Nir=C2=A0<ynir.ietf@gmail.com>=C2=A0wrote:
This is about UI, not about wire for= mat.=C2=A0

On Mon, Apr 6, 2015 at 11:09 PM, Brian Smith <brian@briansmith.org> wrote:
As far as I understand, that problem doesn= 9;t have much to do with the
syntax of cipher suites in the ClientHello, because that problem is
about describing to your web server software which cipher suites to
enable on the server.

I think some are tryi= ng to argue that the problem is deeper than just the user interface, but yo= u're both correct in saying that's where the problem starts.
<= /div>

--
Tony Arcieri
<= /div>
--001a11c1d9d244e3af05131c627c-- From nobody Mon Apr 6 23:31: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 D0BB71A033A for ; Mon, 6 Apr 2015 23:31:37 -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 DpnTiK1NPAdK for ; Mon, 6 Apr 2015 23:31:36 -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 4E5CE1A0338 for ; Mon, 6 Apr 2015 23:31:36 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id A486069A4C; Tue, 7 Apr 2015 09:31:33 +0300 (EEST) Date: Tue, 7 Apr 2015 09:31:33 +0300 From: Ilari Liusvaara To: Tony Arcieri Message-ID: <20150407063133.GA5877@LK-Perkele-VII> References: <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.com> 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: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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, 07 Apr 2015 06:31:38 -0000 On Mon, Apr 06, 2015 at 11:18:12PM -0700, Tony Arcieri wrote: > On Mon, Apr 6, 2015 at 10:51 PM, Yoav Nir wrote: > > > This is about UI, not about wire format. > > > > On Mon, Apr 6, 2015 at 11:09 PM, Brian Smith wrote: > > > As far as I understand, that problem doesn't have much to do with the > > syntax of cipher suites in the ClientHello, because that problem is > > about describing to your web server software which cipher suites to > > enable on the server. > > > I think some are trying to argue that the problem is deeper than just the > user interface, but you're both correct in saying that's where the problem > starts. Also, the certificate format negotiation is supposedly both via ciphersuites and an extension. And when you have the same thing in two places, the relevant question is "which is definitive?". Also, consider if new signature algorithm needs to be added (e.g. CFRG picks something EdDSA-like for new signature algorithm). Also, it is not like existing TLS stacks don't have tables mapping ciphersuites into their component algorithms, since otherwise there would be plenty of code duplication. As for "components are fine but combination is insecure", that would likely require very odd algorithms, and would likely point to TLS key derivation being bad anyway. -Ilari From nobody Tue Apr 7 05:04: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 964AF1B3527 for ; Tue, 7 Apr 2015 05:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T7dPP11j8M2 for ; Tue, 7 Apr 2015 05:04:40 -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 249281B3518 for ; Tue, 7 Apr 2015 05:04:40 -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 9E36638591E for ; Tue, 7 Apr 2015 12:04:39 +0000 (UTC) Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t37C4cC2018560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Apr 2015 08:04:39 -0400 Message-ID: <5523C7D5.8090703@redhat.com> Date: Tue, 07 Apr 2015 14:04:37 +0200 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: [TLS] Interop failure due to wrong encoding of ServerDHParams X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 12:04:41 -0000 I've encountered a TLS 1.2 server implementation which sometimes sends a ServerDHParams structure as part of the ServerKeyExchange message which indicates a length of 127 bytes for the dh_Ys parameter, but the parameter actually sent contains 128 bytes. As a result, parsing the ServerKeyExchange message fails, leading to a handshake failure. (Maybe this happens if the most significant byte of dh_Ys is zero.) In this situation, the OpenSSL client logs this error message: error:1408D172:SSL routines:SSL3_GET_KEY_EXCHANGE:wrong signature type:s3_clnt.c:1863: Does this ring a bell? I don't know any details about the server implementation, unfortunately. -- Florian Weimer / Red Hat Product Security From nobody Tue Apr 7 05:31: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 7EB631A8793 for ; Tue, 7 Apr 2015 05:31:37 -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_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ox_Q3Lurhkol for ; Tue, 7 Apr 2015 05:31:35 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9130E1A878B for ; Tue, 7 Apr 2015 05:31:35 -0700 (PDT) Received: from pc1.fritz.box (x4d0c5d25.dyn.telefonica.de [::ffff:77.12.93.37]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 07 Apr 2015 14:31:33 +0200 id 000000000000005D.000000005523CE25.00000620 Date: Tue, 7 Apr 2015 14:31:48 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20150407143148.2f76a26f@pc1.fritz.box> In-Reply-To: <5523C7D5.8090703@redhat.com> References: <5523C7D5.8090703@redhat.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-1568-1428409893-0001-2" Archived-At: Subject: Re: [TLS] Interop failure due to wrong encoding of ServerDHParams X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 12:31:37 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-1568-1428409893-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 07 Apr 2015 14:04:37 +0200 Florian Weimer wrote: > I've encountered a TLS 1.2 server implementation which sometimes > sends a ServerDHParams structure as part of the ServerKeyExchange > message which indicates a length of 127 bytes for the dh_Ys > parameter, but the parameter actually sent contains 128 bytes. As a > result, parsing the ServerKeyExchange message fails, leading to a > handshake failure. (Maybe this happens if the most significant byte > of dh_Ys is zero.) Hannes from ocaml-tls said something very similar a few days ago in a talk at CCC Berlin. But I think he also said he observed something like that on their servers, but doesn't know which implementation caused it. The talk was streamed and recorded, but I think it's not online yet. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-1568-1428409893-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVI840AAoJEKWIAHK7tR5C7PIP/jiGySvZzww8tHfE7O2amasD RlK1PFUknEDhiHgDNSq2N0XDP3QDwiYceTuUVeVYQMMvcCzL7g87I8fJHh1Krb+H +jvv/v5k+kuhKkaSDDCHs8pYidcy3fofjI2xZ2Qgc61gSSJQVyxYEj3DvCWkJkIT YueOqoB5gr2Y/cKtII76nYJN5i87ARpJA2YS8z3ulCW11FdN4s8H8VnfCTXUZ/+Z qf2JCDJ/wysCyt+XVidGmYNMEaBcp7padmyahd1BilKXKlOm2UeLU9JQ0pteMEFt OLqNgxA0rOLm3I29D9KuYcNVdKKwXgHqmfxjAlCPVd77zSF4kTg66VSLdSiklmmA mNs08ajQ3P1YuIIBakRB5F8YpXLiFCHpcHfBQdo4FIMR2Ki1Q0tPCee8ZxZJX6yR VGFKEodsuNp+PMrLizHKjFP39lYf6hzWDSDkrlPHr//9X2ZptzA78f9sRBlazb6r DpaQcgDnAsewgz5x7CTm6Qz+prMeX5Nydn61AMiSEUt/zD18kVCENds59n8nNAxH 57h++MNGhRj15kEi7iWGbkyDFPGmh+hNQOS8tbDCEh9DFBja6Kx4yiTt7w8m1wmG 29xVY5IAo9XpTy7HMPoNZQL2lplViSVstdsIlPBR5alSD4ZnEjKkF/qQ37iMI5RZ lfUV2Hrr9jKZ/LGrr5am =u2Uh -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-1568-1428409893-0001-2-- From nobody Tue Apr 7 06: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 AF3551B3586 for ; Tue, 7 Apr 2015 06:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, 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 iVCoFjEdu7Zs for ; Tue, 7 Apr 2015 06:23:33 -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 E0DF61B3585 for ; Tue, 7 Apr 2015 06:23:32 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 15F8F28610 for ; Tue, 7 Apr 2015 13:23:32 +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 F29BC285CB for ; Tue, 7 Apr 2015 13:23:31 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id D536D2029 for ; Tue, 7 Apr 2015 13:23:31 +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.913.22; Tue, 7 Apr 2015 08:23:30 -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.0913.011; Tue, 7 Apr 2015 08:23:30 -0500 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Thread-Topic: A question to implementors about compression Thread-Index: AdBxNfE7tVA2J42XQkCpKPgiornfKg== Date: Tue, 7 Apr 2015 13:23:29 +0000 Message-ID: <2dbc5ad134f544619db764781a8bb249@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: [172.19.113.140] Content-Type: multipart/alternative; boundary="_000_2dbc5ad134f544619db764781a8bb249ustx2exdag1mb2msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [TLS] A question to implementors about compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 13:23:35 -0000 --_000_2dbc5ad134f544619db764781a8bb249ustx2exdag1mb2msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I want to completely remove TLS-layer compression from the next release of = OpenSSL (roughly year-end). If you this will cause interop problems with yo= ur stack, can you please let me know? Thanks. -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_2dbc5ad134f544619db764781a8bb249ustx2exdag1mb2msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I want to completely remove TLS-layer compression fr= om the next release of OpenSSL (roughly year-end). If you this will cause i= nterop problems with your stack, can you please let me know?  Thanks.<= o:p>

 

-- 

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_2dbc5ad134f544619db764781a8bb249ustx2exdag1mb2msgcorpak_-- From nobody Tue Apr 7 06:46: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 5F0CA1B35A7 for ; Tue, 7 Apr 2015 06:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, SPF_HELO_PASS=-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 Pno1uuChvXgr for ; Tue, 7 Apr 2015 06:46:16 -0700 (PDT) Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1156D1B359C for ; Tue, 7 Apr 2015 06:46:16 -0700 (PDT) Received: from [192.168.1.101] (i5E86DD8A.versanet.de [94.134.221.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (not verified)) by mail.mehnert.org (Postfix) with ESMTPS id 7344E12A7 for ; Tue, 7 Apr 2015 15:46:14 +0200 (CEST) Message-ID: <5523DF8B.8010409@mehnert.org> Date: Tue, 07 Apr 2015 15:45:47 +0200 From: Hannes Mehnert User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <5523C7D5.8090703@redhat.com> <20150407143148.2f76a26f@pc1.fritz.box> In-Reply-To: <20150407143148.2f76a26f@pc1.fritz.box> OpenPGP: id=DF7C28EE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Interop failure due to wrong encoding of ServerDHParams X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 13:46:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Hi, On 04/07/2015 14:31, Hanno Böck wrote: > On Tue, 07 Apr 2015 14:04:37 +0200 Florian Weimer > wrote: > >> I've encountered a TLS 1.2 server implementation which sometimes >> sends a ServerDHParams structure as part of the >> ServerKeyExchange message which indicates a length of 127 bytes >> for the dh_Ys parameter, but the parameter actually sent contains >> 128 bytes. As a result, parsing the ServerKeyExchange message >> fails, leading to a handshake failure. (Maybe this happens if >> the most significant byte of dh_Ys is zero.) > > Hannes from ocaml-tls said something very similar a few days ago in > a talk at CCC Berlin. But I think he also said he observed > something like that on their servers, but doesn't know which > implementation caused it. What I discovered while running https://tls.openmirage.org (a handshake visualisation for TLS-1.* (it picks protocol version and ciphersuite at random!) - gathered around 30000 TLS sessions) was that our own OCaml-TLS implementation padded the DH parameters with 0 bytes (both the public on the wire, as well as the shared secret). When looking through the session traces, it seems that another implementation does exactly the same: padding with 0 if the DH shared/public has leading zeroes. Using the list of ciphersuites and named curve extension as fingerprint (obviously a very probabilistic approach, see below), the recorded HTTP user-agents are: 293 Google-HTTP-Java-Client/1.17.0-rc (gzip) 174 Mozilla/5.0 () 13 other Thus, it seems to be likely that some Java implementation has this behaviour. Maybe someone with more insight into the Java implementation(s) could look deeper into this!? hannes Here is the fingerprint: ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_EMPTY_RENEGOTIATION_INFO_SCSV extensions: EllipticCurves: SECP256R1 SECT163K1 SECT163R2 SECP192R1 SECP224R1 SECT233K1 SECT233R1 SECT283K1 SECT283R1 SECP384R1 SECT409K1 SECT409R1 SECP521R1 SECT571K1 SECT571R1 SECP160K1 SECP160R1 SECP160R2 SECT163R1 SECP192K1 SECT193R1 SECT193R2 SECP224K1 SECT239K1 SECP256K1 ECPointFormats: UNCOMPRESSED -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJVI9+LAAoJELyJZYjffCjuF00P/00ZeIsxcmSCHzkAn60HXEYg rVeW4aQ1ewIgGETCkQluh9QbJosKjh9w+I9FtbZnUYVd5DAb5kXpN4pKwGkc63GA U830XQ2Uy4no7TViUhvb+TnWVPpIvXAqE8IGNtvGPhRsg9JlcZzINFcECGXPK9ee /14ZlQGx00pn6vOc7Nh6oLNhcw7FViSzRwk9J9+zoa8khaGIRTCKHyw9VHCTDm13 v1U86ajfleqRqXV00NA6/pNICm1q86yW/ONcZ6pG/MQGncyzk88BXs755wlOooww vPGl6LFrYFLfpKJhbJ8KPA/G9F5kpGmjYwPitXCNxrGttnXilS4bcjSnEhvSinWc 8CB1BsWupPtDnnvN0GXoY61clxcfx+mczzepwUzgQaaI1+HEeze3IqwcyCUeXo9U bXbUki9g49cnC2k8IGyPZhR/6YRkKlGQMKcGbMR/oFQjWIIDF00beR0RZspZSzWN BHodOei2hq+XyqIZCVHm4Qf5s02sLDxBov/XTn1HMP9HBxtakbjWlHHD/k8gtIAa lJb2CKPXxZI1WuG02jz6xBcmYV1+FiFs/2M64HIoiosufmhXtiwYG0a2jqFYvv/y Ar6bTtL01m3wvUqbG9SOhCxaL8AHlk+BU1zFbQRMmBj15R6TQqJ7iWc7Fq1USwSP fx4JXDb1y5uqJ3g3AqoK =lSY1 -----END PGP SIGNATURE----- From nobody Tue Apr 7 07:24: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 8CB061B35EB for ; Tue, 7 Apr 2015 07:24:18 -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 y-978MwmH1Oq for ; Tue, 7 Apr 2015 07:24:14 -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 4D1DE1B35EC for ; Tue, 7 Apr 2015 07:23:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CB995BEB5 for ; Tue, 7 Apr 2015 15:23:45 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RDSLBygDLH5 for ; Tue, 7 Apr 2015 15:23:45 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9E9ADBE88 for ; Tue, 7 Apr 2015 15:23:45 +0100 (IST) Message-ID: <5523E871.6040208@cs.tcd.ie> Date: Tue, 07 Apr 2015 15:23:45 +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: "tls@ietf.org" References: <20150407134752.25925.31040.idtracker@ietfa.amsl.com> In-Reply-To: <20150407134752.25925.31040.idtracker@ietfa.amsl.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <20150407134752.25925.31040.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] Fwd: Last Call: (X.509v3 TLS Feature Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 14:24:18 -0000 Hiya, This draft has previously been discussed on this list. Phill has worked it to the point where I think it's now ready for IETF LC. Please read and comment (on the ietf@ietf.org list ideally, but I'll also watch for comments here). Thanks, S. PS: I posted my own non-blocking LC comments [1] [1] https://www.ietf.org/mail-archive/web/ietf/current/msg92766.html -------- Forwarded Message -------- Subject: Last Call: (X.509v3 TLS Feature Extension) to Proposed Standard Date: Tue, 07 Apr 2015 06:47:52 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'X.509v3 TLS Feature Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as OCSP stapling. Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled. This in turn prevents a denial of service attack that might otherwise be possible. The file can be obtained via http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ballot/ No IPR declarations have been submitted directly on this I-D. This draft has previously been (briefly) discussed on the TLS WG list but is not a working group item. The WG seemed fine with progressing an earlier version at that time. From nobody Tue Apr 7 10:02: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 C03251A8A80 for ; Tue, 7 Apr 2015 10:02: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 1hZsbYJ4G20z for ; Tue, 7 Apr 2015 10:02:42 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003: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 BB4631A8A7A for ; Tue, 7 Apr 2015 10:02:42 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so25326915obb.3 for ; Tue, 07 Apr 2015 10:02:42 -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=Fp/ipZBEuPdArksHL+FB9ssZ4LwJ6D6N8y64AcYCsQ0=; b=kwsvHY7f0CT8LjZ6X2KjM7MrVY2gJ47iL/n5zlMameiaG/fgFT5Fx4dyayzPO/AM1d wwSaUo/9AnFA8oOfw7H4FxA8P3Ky2fyFE9aMMIZ9C3J3FvfCoUuhWUBQy6GpJ0hiimLw fxBCfwX5W3BKqyMeJJ3lMgISrXM2QuxVYg2nPC1KIlFtdj3Rkd7euqQ3I4Esxcl8a4GG OmPlreJejucJlBPmr0q+0vVPYWpaAlGBlOymiB/AFVKL200SyfaEgOnWgNTmqlx3YBo0 ZmlSDd6c9JMFjCsfpfnUBR8N6RuhThmabafBbKmBmQaS1sciMQFK3YZz59B5UQAV9xo+ xl0Q== MIME-Version: 1.0 X-Received: by 10.60.101.195 with SMTP id fi3mr26512059oeb.65.1428426144402; Tue, 07 Apr 2015 10:02:24 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Tue, 7 Apr 2015 10:02:24 -0700 (PDT) In-Reply-To: <2dbc5ad134f544619db764781a8bb249@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <2dbc5ad134f544619db764781a8bb249@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Tue, 7 Apr 2015 10:02:24 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] A question to implementors about compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 17:02:44 -0000 On 7 April 2015 at 06:23, Salz, Rich wrote: > I want to completely remove TLS-layer compression from the next release of > OpenSSL (roughly year-end). If you this will cause interop problems with > your stack, can you please let me know? Thanks. I'm guessing that interop problems with other stacks will be the least of your concerns: the uncompressed option is pretty well-tested. NSS happily doesn't compress. I'd be more concerned about users who might have gotten attached to the feature. From nobody Tue Apr 7 13:21: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 5C4751B3C0A for ; Tue, 7 Apr 2015 13:21:52 -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 xwU5sbrSj3c5 for ; Tue, 7 Apr 2015 13:21:50 -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 D65181B3C03 for ; Tue, 7 Apr 2015 13:21:47 -0700 (PDT) Received: by qkgx75 with SMTP id x75so60146058qkg.1 for ; Tue, 07 Apr 2015 13:21:47 -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=S6f1v9QsHGeZeI/OEin0KTL/zOPSwI4bERHrTI0+Fdw=; b=aaupcspBHAeU7bpr/PkUnvJiiBNxdUE5LVs1UPeEU1hIujgjtDzU7SaE/ULikkPaOv ercAHyZv00C2tw8p6NJL4iAHgQ+5MNWLTLQRVBemuOhZbJ559UlCJImwuJsGMcIugv02 HSBMtMcPsoaFg0fceEgIkozeW29soHJsKduqXkHtTAlyLHN0p4GmN6TN7IghKL6zWhDD vdHwg1eqGFKsBLtRFkDT6/+xtEtVW6eU+8f6aLBFyKDEA3Mhh7FKVby75kXbEu/Fgmd7 saUzojJwapBrTi2p4MU6KG9SQXQQVRNrQSzrY6b1RjV0d+JAZyoXTc3+FxGejlRpFHc3 8G7g== 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=S6f1v9QsHGeZeI/OEin0KTL/zOPSwI4bERHrTI0+Fdw=; b=FtiIYqYUJCn8n3cECbOOpGk5o2Vc6KGE14NyQrlTt0/A4axJYanSeXBBjxjIaGAggt zp/Bt4HuOMOMIoZKBOBROSsN/e8tfl8gMCrx1/nWrLaRc1YK0E5BB0Dn/huIWBd87AL1 GrpNdTc+P+ATQ4eH3nKMxIcEB0ryxLnaPu+UTwVAAjlrfE+cZhPCM6ZgjFBlehMRPQS9 lFf2OkuoskAP9cPrgC9m9FSAnb+KFnC8vg3sR/tCOiExX/9ck5mEdXw7sJlDo4EKb/KV psd64vvxctccdmCzmNeBlxYynJaiBX6LvpMaHB6T0eV1X8qTGC1CrmWus1ygQC6sT+a+ uBRQ== X-Gm-Message-State: ALoCoQkF9SqtSkxY1u3wtN1XhJ+TdEepHSJ6llR3dCsxmBPY1a3LBycldmNdkcCkPhJq8WyNa6CK MIME-Version: 1.0 X-Received: by 10.55.21.139 with SMTP id 11mr9037802qkv.19.1428438107095; Tue, 07 Apr 2015 13:21:47 -0700 (PDT) Received: by 10.229.178.135 with HTTP; Tue, 7 Apr 2015 13:21:46 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Tue, 7 Apr 2015 21:21:46 +0100 Message-ID: From: Ben Laurie To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 20:21:52 -0000 On 6 April 2015 at 13:45, Peter Gutmann wrote: > If you really need a secure time source you either use NTPv4 security or run > your own stratum 1. How does NTPv4 security provide a secure time source (i.e. something I can rely on as if it were stratum 1)? From nobody Tue Apr 7 14:02: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 D40F11A0161 for ; Tue, 7 Apr 2015 14:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l1nBUYDCYGV for ; Tue, 7 Apr 2015 14:02:07 -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 1527D1B3C9E for ; Tue, 7 Apr 2015 14:02:06 -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 t37L22xU030828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 7 Apr 2015 17:02:02 -0400 Received: from oldenburg.str.redhat.com ([10.10.116.43]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t37L1xsM023899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2015 17:02:01 -0400 Message-ID: <552445C4.4000800@redhat.com> Date: Tue, 07 Apr 2015 23:01:56 +0200 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 21:02:14 -0000 On 04/06/2015 02:45 PM, Peter Gutmann wrote: > Tom Ritter writes: > >> Is it better or worse than relying on a completely unauthenticated protocol >> to get the time? > > If you really need a secure time source you either use NTPv4 security NIST has published a protocol for NTPv4 key negotiation: Yes, it's a manual protocol, due to the lack of better alternatives. > or run your own stratum 1. That's still subject to spoofing. One solution is to obtain cryptographically secured time from the national time source (which exists in most countries, I assume), with a baked-in (CA) certificate. If it's wrong, it's still correct because it's the official time. The Network Time Security effort more or less explicitly excludes importing time from the outside (over the Internet or otherwise) because it's requirements RFC, RFC 7384, explicitly states this is a non-requirement in section 3.2.10. (The RFC also has requirements which seem quite impossible to implement.) The current NTS protocol proposal uses CMS over UDP for key negotiation, but has some issues. I don't know yet if they can be persuaded to adopt DTLS (maybe lack of server-side state is absolutely critical to them). -- Florian Weimer / Red Hat Product Security From nobody Tue Apr 7 16:13: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 DAB041A8035 for ; Tue, 7 Apr 2015 16:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 XbBFfeBjD4kR for ; Tue, 7 Apr 2015 16:13:13 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE8F1A7014 for ; Tue, 7 Apr 2015 16:13: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=uoa; t=1428448394; x=1459984394; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k2EVbggb+hEmvlCkpIBrwQUTWBZtSBkR4FFWwW/F78c=; b=bc6wHlHYLT5Jgm9WF5ZiCocIXxrG9LoHikeJhwdPdoNAk99Oq9nwAdnE 4dHZq7tStS8jOpOaIDHHkhYUIfrzIDIM8Yx7VrntBQCUZbs/Ht/nMIFrI sbl2ALcdEsNgLfUj4E5xb31+HZ9bk/K2j8XFKFt40t4YcN+n/aGHgn4MR 0=; X-IronPort-AV: E=Sophos;i="5.11,540,1422874800"; d="scan'208";a="319347125" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Apr 2015 11:13:12 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.245]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 8 Apr 2015 11:13:10 +1200 From: Peter Gutmann To: Florian Weimer , "" Thread-Topic: [TLS] Server time Thread-Index: AdBwZ6GD+C5DBwD+SeCkDTaZlcyh5AAqd3oAAB23Emk= Date: Tue, 7 Apr 2015 23:13:10 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFDD546@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz>, <552445C4.4000800@redhat.com> In-Reply-To: <552445C4.4000800@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: Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 23:13:17 -0000 Florian Weimer writes:=0A= >On 04/06/2015 02:45 PM, Peter Gutmann wrote:=0A= >> or run your own stratum 1.=0A= >=0A= >That's still subject to spoofing.=0A= =0A= If you're up against an attacker who's got the ability, means, and motivati= on=0A= to haul sophisticated GPS-spoofing equipment to wherever you are and deploy= it=0A= against you, presumably in some manner where it won't interfere with other = GPS=0A= activity which would make it detectable, then you're toast anyway.=0A= =0A= In the situations I know of where time is part of the TCB, the other side= =0A= tracks the source's clock drift and compensates accordingly. In other word= s=0A= the source has some built-in clock that doesn't have to be very accurate, a= s=0A= long as it's reasonably consistently inaccurate, i.e. not a Vetinari clock.= =0A= =0A= Peter.=0A= From nobody Tue Apr 7 16:25: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 DEEC81A913E for ; Tue, 7 Apr 2015 16:25:37 -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 JBl4IgF-Pfye for ; Tue, 7 Apr 2015 16:25:36 -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 005D41A9140 for ; Tue, 7 Apr 2015 16:25:35 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3323328539; Tue, 7 Apr 2015 23:25:35 +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 1E6742852B; Tue, 7 Apr 2015 23:25:35 +0000 (GMT) Received: from tereva.kendall.corp.akamai.com (sfo-wp8n3.kendall.corp.akamai.com [172.19.34.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id ECF182026; Tue, 7 Apr 2015 23:25:34 +0000 (GMT) From: Brian Sniffen To: Tony Arcieri , "Salz\, Rich" In-Reply-To: References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-apple-darwin14.0.0) Date: Tue, 07 Apr 2015 19:25:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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, 07 Apr 2015 23:25:38 -0000 > As myself and many others have described, we're essentially being > asked to compute the combinatorial explosion of different ciphersuite > configurations by hand. Guess what happens when you do that? People > make mistakes. Lots of them, and terrible mistakes. For example, the OpenSSL configuration language encourages selections like: HIGH TLSv1:SSLv3:-EDH:-ADH:-NULL:@STRENGTH TLSv1:SSLv3:HIGH:-SSLv2:-MEDIUM:-LOW all of which admit terrible choices. I think this is because those look like short, easily comprehensible commands---but aren't. > Seems like a huge win to me. So what's the problem from an implementer > perspective besides "it'd be hard"? But that's not the wire format. That's the best attempt of implementors to provide a better configuration format than just listing everything you want. After a lot of trying for better, I am persuaded that the right answer is to explicitly list exactly what you want, or to reference first-order named sets of what you want---that set algebra on cipher selections is more dangerous. The best advice we can give now could be expressed to OpenSSL as 'EECDH+AESGCM', but it's not much more work to say ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256, and at least that looks like something you should read carefully and make sure you didn't swap a : and a -. -Brian -- Brian Sniffen From nobody Tue Apr 7 19:54: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 DB48D1A1B27 for ; Tue, 7 Apr 2015 19:54:41 -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_00=-1.9, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_34=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 jg6x99SYAmz5 for ; Tue, 7 Apr 2015 19:54:40 -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 AB9851A1A1E for ; Tue, 7 Apr 2015 19:54:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0A100283031; Wed, 8 Apr 2015 02:54:39 +0000 (UTC) Date: Wed, 8 Apr 2015 02:54:39 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150408025438.GH17637@mournblade.imrryr.org> References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.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] Ala Carte Cipher suites - was: DSA should die 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, 08 Apr 2015 02:54:42 -0000 On Mon, Apr 06, 2015 at 08:25:02PM -0700, Tony Arcieri wrote: > Looks like the opinion of TLS implementers is this far unanimously against > this proposal. I would like to give the counterpoint from a TLS user > perspective. I see no unanimity. I think that long-term the cross product simplifies maintenance (simpler internal tables with less duplication), and makes it easier to sensibly sort the cipher-suites by independent preferences for each feature. Yes, there'll need to be new APIs for specifying separate preferences for the key agreement suites vs. bulk crypto suites. Some may find this an opportunity to drop legacy interfaces. In OpenSSL many of the building blocks are already there, thus we can build up a cipher-suite from its parts: $ openssl ciphers -v kECDHE+aECDSA+AES128+AESGCM ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD All that's missing is separate ordered cipherstring settings for the components. These would be UI improvements I think. Yes, not easy retrofits into existing applications, but ultimately worth it IMHO. Assuming of course TLS is still the swiss-army knife of security protocols and needs to support a range of choices for each element of the cipher-suite. Were any radical simplification to just 1 or 2 (composite) ciphersuites actually realistic, then breaking those down would be silly. As it stands I don't see a likely choice of just 2 ciphersuites that serve all TLS users, and thus ala carte makes sense to me. -- Viktor. From nobody Tue Apr 7 20:00: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 513781B2C13 for ; Tue, 7 Apr 2015 20:00:56 -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 OnYObJysvPz9 for ; Tue, 7 Apr 2015 20:00:55 -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 181821B2C11 for ; Tue, 7 Apr 2015 20:00:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7F1EA283031; Wed, 8 Apr 2015 03:00:54 +0000 (UTC) Date: Wed, 8 Apr 2015 03:00:54 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150408030054.GI17637@mournblade.imrryr.org> References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <54c69c7ac7074ba8a2e71734843bf106@ustx2ex-dag1mb2.msg.corp.akamai.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] Ala Carte Cipher suites - was: DSA should die 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, 08 Apr 2015 03:00:56 -0000 On Tue, Apr 07, 2015 at 07:25:34PM -0400, Brian Sniffen wrote: > Lots of them, and terrible mistakes. For example, the OpenSSL > configuration language encourages selections like: > > HIGH > TLSv1:SSLv3:-EDH:-ADH:-NULL:@STRENGTH > TLSv1:SSLv3:HIGH:-SSLv2:-MEDIUM:-LOW The problem is that this attempts to mix choices along multiple axes into a single list. Very few people understand this oranges and apples interface. If each setting just expressed preferences along a single axis, the interface would be much simpler. This is why the wire format should avoid combining independent choices, that way the user's preferences for any given apples to apples comparison can be expressed without change on the wire. Otherwise one has to make trade-offs that try to decide whether ECDHE with AES128 is better than DHE with AES256? And similar imponderables. So I would go further and urge a full decomposition, not just handshake vs. bulk crypto. -- Viktor. From nobody Wed Apr 8 01:11: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 B19281B2DDA for ; Wed, 8 Apr 2015 01:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqveAzRG4bPb for ; Wed, 8 Apr 2015 01:11:55 -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 394D41B2DD9 for ; Wed, 8 Apr 2015 01:11:55 -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 t388BsLh009162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 8 Apr 2015 04:11:54 -0400 Received: from oldenburg.str.redhat.com ([10.10.116.39]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t388Bqew010657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Apr 2015 04:11:53 -0400 Message-ID: <5524E2C6.80000@redhat.com> Date: Wed, 08 Apr 2015 10:11:50 +0200 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB939@uxcn10-tdc05.UoA.auckland.ac.nz> <20150406114436.GA5162@roeckx.be> In-Reply-To: <20150406114436.GA5162@roeckx.be> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 08:11:56 -0000 On 04/06/2015 01:44 PM, Kurt Roeckx wrote: > There is work being done to make NTP more secure. But if you > don't know what time it is there is no way that we know how to > get the correct time in a secure way. About the best you can do > is assume that not everybody is compromised. What about hard-coded (CA) certificates? The time dependency was pioneered by X.509/PKIX and its certificate revocation model, it's not inherent to (asymmetric) cryptography. -- Florian Weimer / Red Hat Product Security From nobody Wed Apr 8 03:06: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 DB37B1B2F07 for ; Wed, 8 Apr 2015 03:06:34 -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 hAmlXAhooudd for ; Wed, 8 Apr 2015 03:06:33 -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 166121B2F02 for ; Wed, 8 Apr 2015 03:06:32 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id BA5BD1C208B; Wed, 8 Apr 2015 12:06:30 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 958431FE058C; Wed, 8 Apr 2015 12:06:30 +0200 (CEST) Date: Wed, 8 Apr 2015 12:06:30 +0200 From: Kurt Roeckx To: Florian Weimer Message-ID: <20150408100630.GA9933@roeckx.be> References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> <552445C4.4000800@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552445C4.4000800@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 10:06:35 -0000 On Tue, Apr 07, 2015 at 11:01:56PM +0200, Florian Weimer wrote: > I don't know yet if they can be persuaded to adopt > DTLS (maybe lack of server-side state is absolutely critical to them). The lack of server-side state really is important to them. There are too many clients to keep track of. I also think they want to avoid having the crypto reduce the accuracy too much. But I think both problems can be solved. Kurt From nobody Wed Apr 8 03:10: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 2622E1B2F0C for ; Wed, 8 Apr 2015 03:10:33 -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 87QPrO7ke35t for ; Wed, 8 Apr 2015 03:10:32 -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 0A2EF1B2EF7 for ; Wed, 8 Apr 2015 03:10:32 -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 9A32E8E92B; Wed, 8 Apr 2015 10:10:30 +0000 (UTC) Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t38AASpR029991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 06:10:29 -0400 Message-ID: <5524FE93.5080701@redhat.com> Date: Wed, 08 Apr 2015 12:10:27 +0200 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kurt Roeckx References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz> <552445C4.4000800@redhat.com> <20150408100630.GA9933@roeckx.be> In-Reply-To: <20150408100630.GA9933@roeckx.be> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: "" Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 10:10:33 -0000 On 04/08/2015 12:06 PM, Kurt Roeckx wrote: > On Tue, Apr 07, 2015 at 11:01:56PM +0200, Florian Weimer wrote: >> I don't know yet if they can be persuaded to adopt >> DTLS (maybe lack of server-side state is absolutely critical to them). > > The lack of server-side state really is important to them. There > are too many clients to keep track of. DTLS would only be used to negotiate a shared key for subsequent message authentication. The DTLS sessions would not be persistent during an entire NTP association. If that's not clear from my comments, I should send a clarification to the NTPWG list. (UDP with large messages still needs state in the IP stack for fragment reassembly, so even the current CMS-based proposal is not exactly stateless.) -- Florian Weimer / Red Hat Product Security From nobody Wed Apr 8 03:15: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 1F7831B2F19 for ; Wed, 8 Apr 2015 03:15:32 -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 kraq-JtYBszC for ; Wed, 8 Apr 2015 03:15:31 -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 1BCCC1B2F18 for ; Wed, 8 Apr 2015 03:15:31 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id ABCB41C208B; Wed, 8 Apr 2015 12:15:29 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 8644D1FE058C; Wed, 8 Apr 2015 12:15:29 +0200 (CEST) Date: Wed, 8 Apr 2015 12:15:29 +0200 From: Kurt Roeckx To: Florian Weimer Message-ID: <20150408101529.GB9933@roeckx.be> References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB939@uxcn10-tdc05.UoA.auckland.ac.nz> <20150406114436.GA5162@roeckx.be> <5524E2C6.80000@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5524E2C6.80000@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 10:15:32 -0000 On Wed, Apr 08, 2015 at 10:11:50AM +0200, Florian Weimer wrote: > On 04/06/2015 01:44 PM, Kurt Roeckx wrote: > > > There is work being done to make NTP more secure. But if you > > don't know what time it is there is no way that we know how to > > get the correct time in a secure way. About the best you can do > > is assume that not everybody is compromised. > > What about hard-coded (CA) certificates? That might have expired, been revoked, whatever. If you go and check a CRL the attacker might give you an old copy. If you use OCSP it might give you an old reply. You probably at least want an OCSP server that supports a nonce. Kurt From nobody Wed Apr 8 03: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 427DA1B2F28 for ; Wed, 8 Apr 2015 03:27: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 ZODj8GnZa6F1 for ; Wed, 8 Apr 2015 03:27:28 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::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 E0F2C1B2F21 for ; Wed, 8 Apr 2015 03:27:27 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so79084155ied.1 for ; Wed, 08 Apr 2015 03:27:27 -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:content-type; bh=cQyjmFi/H/NEjLfxlujo0bMSE3e+uV4XtJkTvct9PMw=; b=V06bFTXh+khImqon4FcLs4uQPu8jH/8vsqRsEbHgOFGjMsEcV1tq0qEX/tyipLgh09 9kjlBtz0CFEjyzNXvaw5CCgm5DKQXV4THhT5nsEHtFImsf122nzA2l8IqFjq8FqjVTFk K4reK8UFfDP4LVRHqNhadNAE2hnS2SEYQlXpMc9yf96H9cvChmzUvip4vHV3MrVhZndH VRteXb3hmUwtuoCzSZfQgUxNfEvXfOa0IzO/u9w4c+tpWmDwKjMZa5swRihYigfTpkpj HQH+kFS+ib8YkbeFNbversQro+0gNj9XItKz3NArg8QpShpBlFstUiEnsarZX1va3Prt CFcw== MIME-Version: 1.0 X-Received: by 10.107.29.21 with SMTP id d21mr37903216iod.11.1428488847472; Wed, 08 Apr 2015 03:27:27 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Wed, 8 Apr 2015 03:27:27 -0700 (PDT) In-Reply-To: <20150408101529.GB9933@roeckx.be> References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB939@uxcn10-tdc05.UoA.auckland.ac.nz> <20150406114436.GA5162@roeckx.be> <5524E2C6.80000@redhat.com> <20150408101529.GB9933@roeckx.be> Date: Wed, 8 Apr 2015 06:27:27 -0400 Message-ID: From: Jeffrey Walton To: Kurt Roeckx , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Server time 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: Wed, 08 Apr 2015 10:27:29 -0000 On Wed, Apr 8, 2015 at 6:15 AM, Kurt Roeckx wrote: > On Wed, Apr 08, 2015 at 10:11:50AM +0200, Florian Weimer wrote: >> On 04/06/2015 01:44 PM, Kurt Roeckx wrote: >> >> > There is work being done to make NTP more secure. But if you >> > don't know what time it is there is no way that we know how to >> > get the correct time in a secure way. About the best you can do >> > is assume that not everybody is compromised. >> >> What about hard-coded (CA) certificates? > > That might have expired, been revoked, whatever. If you go and > check a CRL the attacker might give you an old copy. If you use > OCSP it might give you an old reply. You probably at least want > an OCSP server that supports a nonce. > Gossip protocols. As the density of networked devices increases (especially with mobile clients), I think it makes sense to look at it as a partial solution or a way to reduce the problem. The mobile clients bring in time from outside channels, so its a nice cross check. A device still probably needs to contact an NTP server on occasion for sanity checking. But there won't be a need to hammer a secure time server every 30 minutes or every hour. From nobody Wed Apr 8 06:25: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 41F641A00B6 for ; Tue, 7 Apr 2015 22:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.129 X-Spam-Level: * X-Spam-Status: No, score=1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FSL_HELO_BARE_IP_2=1.675, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-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 bwwPC0-McRpD for ; Tue, 7 Apr 2015 22:52:37 -0700 (PDT) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B391A00D0 for ; Tue, 7 Apr 2015 22:52:30 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YfiuZ-0006Zg-Rp for tls@ietf.org; Wed, 08 Apr 2015 07:52:28 +0200 Received: from 66.87.139.208 ([66.87.139.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2015 07:52:27 +0200 Received: from eternaleye by 66.87.139.208 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2015 07:52:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Alex Elsayed Date: Tue, 07 Apr 2015 22:52:18 -0700 Lines: 18 Message-ID: References: <2dbc5ad134f544619db764781a8bb249@ustx2ex-dag1mb2.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 66.87.139.208 User-Agent: KNode/4.14.6 Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 06:25:12 -0700 Subject: Re: [TLS] A question to implementors about compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 05:52:38 -0000 Martin Thomson wrote: > On 7 April 2015 at 06:23, Salz, Rich wrote: >> I want to completely remove TLS-layer compression from the next release >> of OpenSSL (roughly year-end). If you this will cause interop problems >> with >> your stack, can you please let me know? Thanks. > > I'm guessing that interop problems with other stacks will be the least > of your concerns: the uncompressed option is pretty well-tested. NSS > happily doesn't compress. I'd be more concerned about users who might > have gotten attached to the feature. Fortunately, LibreSSL ripped it out a while back, and a large number of things got fixed to handle that - so I think it's unlikely this will break the entire world; more likely about 10-25% of it (i.e. "nobody built this with LibreSSL" or "upstream hasn't taken patches to fix the build on LibreSSL"). From nobody Wed Apr 8 06:25:31 2015 Return-Path: X-Original-To: expand-draft-ietf-tls-session-hash.all@virtual.ietf.org Delivered-To: tls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4C4121A8ADA; Tue, 7 Apr 2015 10:16:00 -0700 (PDT) X-Original-To: xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA9B1A8AAC; Tue, 7 Apr 2015 10:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw9xHqpFPie2; Tue, 7 Apr 2015 10:15:58 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5F65E1A8AA4; Tue, 7 Apr 2015 10:15:58 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 4C0DA9A401B; Tue, 7 Apr 2015 13:15:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 5DOMM2ln+cyH; Tue, 7 Apr 2015 13:15:26 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 45CBF9A4015; Tue, 7 Apr 2015 13:15:26 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 7 Apr 2015 13:15:15 -0400 Message-Id: To: draft-ietf-tls-session-hash.all@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 06:25:27 -0700 Cc: IETF Gen-ART , IETF Subject: [TLS] Gen-ART Review of draft-ietf-tls-session-hash-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2015 17:16:00 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . This review is in response to a request for early Gen-ART review. Document: draft-ietf-tls-session-hash-04 Reviewer: Russ Housley Review Date: 2015-04-01 IETF LC End Date: 2015-04-13 IESG Telechat date: unknown Summary: Ready Major Concerns: None Minor Concerns: The most recent RFC Editor style guide places normative and informative references in top-level sections. In this document, the normative references should be Section 9, and the informative references should be in a new Section 10. Other Comments: For absolute clarity, I suggest a small addition to Section 5.1. It says: "Thus, the entire encoding of the extension is 00 17 00 00." I would add to the end of the sentence: "(in hexadecimal)". Typo correction in Section 6.3: "sent by the server/". Please replace the slash with a period. From nobody Wed Apr 8 09:46: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 78F2C1B3431 for ; Wed, 8 Apr 2015 09:46: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 ioxi_pxXlzsB for ; Wed, 8 Apr 2015 09:46:56 -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 40A7D1B342E for ; Wed, 8 Apr 2015 09:46:56 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so71721730obb.3 for ; Wed, 08 Apr 2015 09:46: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=rGrNjOJP+HCg4Y9dGUyHUzFEZuOl59Z1rYdg2GRz35w=; b=oIj0CXO0iZ89SMiOR/BUtBUe7L9YHDZtkbABUEtVWfpbPifhw4br/LRm6keuKKEvtu 9DK7ivlHEm32tnC8tnUDPP28E+OTi0/t/RKZgj7FeQ3uDj0Qbs7cHynhMEqzuQDKe+hU K8YzMIeqXMLkN0imLrGZw+dscaGYI2UsW2n7Q19VS1WtK5PCGnYZwwlIuqCSlwQQ/QO5 QTXbBL3MBTRrHSKTnt8RYK5DnHfFGZlTYm+b/VxbceSh9AxJ7AVc1LsEYjmqtDo06UHW Yl6uTcPljXcLzFD/G2lFfHXoH5ct/sOx3KT6FrGmk5eCAGTSswFW+76tWbRxoD82JQph Hh6Q== MIME-Version: 1.0 X-Received: by 10.182.63.3 with SMTP id c3mr1992346obs.1.1428511606503; Wed, 08 Apr 2015 09:46:46 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Wed, 8 Apr 2015 09:46:46 -0700 (PDT) In-Reply-To: References: <2dbc5ad134f544619db764781a8bb249@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Wed, 8 Apr 2015 09:46:46 -0700 Message-ID: From: Martin Thomson To: Alex Elsayed Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A question to implementors about compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 16:46:57 -0000 On 7 April 2015 at 22:52, Alex Elsayed wrote: > Martin Thomson wrote: > >> On 7 April 2015 at 06:23, Salz, Rich wrote: >>> I want to completely remove TLS-layer compression from the next release >>> of OpenSSL (roughly year-end). If you this will cause interop problems >>> with >>> your stack, can you please let me know? Thanks. >> >> I'm guessing that interop problems with other stacks will be the least >> of your concerns: the uncompressed option is pretty well-tested. NSS >> happily doesn't compress. I'd be more concerned about users who might >> have gotten attached to the feature. > > Fortunately, LibreSSL ripped it out a while back, and a large number of > things got fixed to handle that - so I think it's unlikely this will break > the entire world; more likely about 10-25% of it (i.e. "nobody built this > with LibreSSL" or "upstream hasn't taken patches to fix the build on > LibreSSL"). Are you suggesting that LibreSSL/OpenSSL prior to the removal would fail to properly negotiate the absence of compression? I'm fairly sure we'd know if that was the case. From nobody Wed Apr 8 09:54: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 EBE4D1B343F for ; Wed, 8 Apr 2015 09:54:13 -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 WWgW2hR6bVPn for ; Wed, 8 Apr 2015 09:54:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953BC1B33E9 for ; Wed, 8 Apr 2015 09:54:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 943F8283032; Wed, 8 Apr 2015 16:54:11 +0000 (UTC) Date: Wed, 8 Apr 2015 16:54:11 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150408165411.GT17637@mournblade.imrryr.org> References: <2dbc5ad134f544619db764781a8bb249@ustx2ex-dag1mb2.msg.corp.akamai.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] A question to implementors about compression 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, 08 Apr 2015 16:54:14 -0000 On Wed, Apr 08, 2015 at 09:46:46AM -0700, Martin Thomson wrote: > Are you suggesting that LibreSSL/OpenSSL prior to the removal would > fail to properly negotiate the absence of compression? I'm fairly > sure we'd know if that was the case. That's not the case. OpenSSL interoperates whether compression is disabled at compile time, run-time or not enabled by the peer. Disabling it at compile time or even excising the underlying code reduce the attack surface and effort to support the code. If some applications insist on negotiating compression, then of course they are free to abort connections that don't negotiate compression. -- Viktor. From nobody Wed Apr 8 10:47: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 272731A87ED for ; Wed, 8 Apr 2015 10:47:49 -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 Q6xpoY6yPmXG for ; Wed, 8 Apr 2015 10:47:47 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6672E1A87EC for ; Wed, 8 Apr 2015 10:47:47 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-75-552569c2c0f8 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 26.CA.03488.2C965255; Wed, 8 Apr 2015 13:47:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t38HljUJ008756 for ; Wed, 8 Apr 2015 13:47:46 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t38HliDX029561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 8 Apr 2015 13:47:45 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t38Hlhf7019470; Wed, 8 Apr 2015 13:47:43 -0400 (EDT) Date: Wed, 8 Apr 2015 13:47:43 -0400 (EDT) From: Benjamin Kaduk To: tls@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6nrnsoUzXUoG+huMWn812MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOPHjGltBI2fF3OPr2RoYV7N3MXJySAiYSCz5e58ZwhaTuHBv PVsXIxeHkMBiJokdGzewQjiHGSWeHJ8O1iEkcIVJ4nWzOIRdL/FsxgqwOIuAlsTnpY1gNpuA isTMNxuBJnFwiAgISDS/FAMJCwuoSmw/sZ4RxOYUsJS41LQXzOYVcJR4v/EaC8RIC4mrj6ew gtiiAjoSq/dPYYGoEZQ4OfMJmM0MtGr59G0sExgFZiFJzUKSWsDItIpRNiW3Sjc3MTOnODVZ tzg5MS8vtUjXSC83s0QvNaV0EyMo9DgleXcwvjuodIhRgINRiYe3z1M1VIg1say4MvcQoyQH k5Iob2QyUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIbxZIjjclsbIqtSgfJiXNwaIkzrvpB1+I kEB6YklqdmpqQWoRTFaGg0NJgvdJBlCjYFFqempFWmZOCUKaiYMTZDgP0PCFIDW8xQWJucWZ 6RD5U4y6HMueNC1mEmLJy89LlRLnvQFSJABSlFGaBzcHljJeMYoDvSXMywdMIEI8wHQDN+kV 0BImoCX8z5RAlpQkIqSkGhgLXA+WL+s9nD9dmu+ksHJZTgTvoyMb2o+1n3j+6S9P+dreWJeM +JjY13w3nv5a2WMm7a57tjtsks/n5vgtB85M4GUUu6Yl+urA09pns19K5hUuOfufPU21JWLS MtvXLJ4Jy3/7cty71N3DmRPMtkl+alhowVfLVWXvViqv+fSff99X8Wj39bZKLMUZiYZazEXF iQCyJtd19AIAAA== Archived-At: Subject: Re: [TLS] Killing Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 17:47:49 -0000 On Mon, 6 Apr 2015, tls-request@ietf.org wrote: > Date: Mon, 6 Apr 2015 13:08:45 +0000 > From: Peter Gutmann > To: "" > Subject: Re: [TLS] Killing Algorithms > Message-ID: > <9A043F3CF02CD34C8E74AC1594475C73AAFDBA18@uxcn10-tdc05.UoA.auckland.ac.nz> > > Content-Type: text/plain; charset="us-ascii" > > Daniel Kahn Gillmor writes: > > ever. There are devices out there still using single DES, and that's > perfectly all right because it's secure enough for what they do. Sure, an > attacker could spend tends of thousands of dollars on a custom-built FPGA DES- > breaker and carry out some high-tech attack to bypass network security > controls and mess with a power substation, but the same would be achieved much > more cheaply by slipping some random guy a bag of weed to throw a bike chain > over a HV feeder. Since I didn't see anyone else mention it, or by paying $100 to a cloud service which is renting out time on their FPGA cracker. No need to build your own unless you need to keep the fact that you're attacking it secret. -Ben From nobody Wed Apr 8 13:01: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 D2D861B35BE for ; Wed, 8 Apr 2015 13:01: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_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 7ToAPGrGbjGR for ; Wed, 8 Apr 2015 13:01:28 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E311B35BD for ; Wed, 8 Apr 2015 13:01:28 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-b8-5525891665ed Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 89.B6.03488.71985255; Wed, 8 Apr 2015 16:01:27 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t38K1QZ8025073 for ; Wed, 8 Apr 2015 16:01:26 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t38K1OvL014404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 8 Apr 2015 16:01:26 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t38K1O89006213; Wed, 8 Apr 2015 16:01:24 -0400 (EDT) Date: Wed, 8 Apr 2015 16:01:24 -0400 (EDT) From: Benjamin Kaduk To: tls@ietf.org In-Reply-To: <20150404020709.31136.3025.idtracker@ietfa.amsl.com> Message-ID: References: <20150404020709.31136.3025.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6noiveqRpqsOIyp8Wn812MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWHS9uqCZqeLbgV9sDYxHGLsYOTkkBEwkFp/byAJhi0lcuLee rYuRi0NIYDGTxLz3J1ghnMOMEhde/GGBcK4wSTy+3sgO0iIkUC/x+v9lNhCbRUBL4tP7dWA2 m4CKxMw3G4FsDg4RAQGJ5pdiIL3CAgsYJVb8Pwq2mlPAUeLWy0Ng9bxA9szPk1hA6oUEHCQ2 zjUCCYsK6Eis3j+FBaJEUOLkzCdgNjPQquXTt7FMYBSYhSQ1C0lqASPTKkbZlNwq3dzEzJzi 1GTd4uTEvLzUIl0jvdzMEr3UlNJNjKDQ45Tk3cH47qDSIUYBDkYlHt4+T9VQIdbEsuLK3EOM khxMSqK8kclAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8WSA53pTEyqrUonyYlDQHi5I476Yf fCFCAumJJanZqakFqUUwWRkODiUJ3uIOoEbBotT01Iq0zJwShDQTByfIcB6g4YEgNbzFBYm5 xZnpEPlTjLocd6b8X8QkxJKXn5cqJc7LAVIkAFKUUZoHNweWMl4xigO9JcwrDVLFA0w3cJNe AS1hAlrC/0wJZElJIkJKqoFRb9avKpU9GoePfn525c7lnzv/CX37/+gnn4ozK8ujs8fn2LdH 2E13Sb3xR+wNv7rrFon7T6c72pjPet6kkKYcxhm8vHT/OcmDhX03zvNWqq81OCDf4sm/fH7t vLOT+w/kB6uuz5h6eduJX72/Uv02df359ldP8Xvml32xHvF9/krSLwxLuf89UGIpzkg01GIu Kk4EAN16HMH0AgAA Archived-At: Subject: Re: [TLS] Last Call: (Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 20:01:31 -0000 No interesting comments here, just a note that section 9.1 has: Pretend that a non-compatible client is compatible (e.g. by . This could cause the server to select a particular named group in which seems to be missing something... -Ben From nobody Wed Apr 8 15:32: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 A2CDD1A9085 for ; Wed, 8 Apr 2015 15:32:45 -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 7aZJYyj_hwpP for ; Wed, 8 Apr 2015 15:32:44 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 20E021A8A48 for ; Wed, 8 Apr 2015 15:32:44 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 377BFF984; Wed, 8 Apr 2015 18:32:41 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CF595200FA; Wed, 8 Apr 2015 17:32:29 -0500 (CDT) From: Daniel Kahn Gillmor To: Benjamin Kaduk , tls@ietf.org In-Reply-To: References: <20150404020709.31136.3025.idtracker@ietfa.amsl.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 08 Apr 2015 18:32:29 -0400 Message-ID: <87y4m21caq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Last Call: (Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 22:32:45 -0000 On Wed 2015-04-08 16:01:24 -0400, Benjamin Kaduk wrote: > No interesting comments here, just a note that section 9.1 has: > > Pretend that a non-compatible client is compatible (e.g. by . > This could cause the server to select a particular named group in > > which seems to be missing something... Thanks for catching that, Ben. That should be: (e.g. by adding the Supported Groups extension, or by adding FFDHE groups to the extension) I'm accumulating these changes (including the note about relaxing 4492's MUST NOT) in git [0]; i don't know whether i should push these edits to the RFC editor now, or do them in batch after Last Call. --dkg [0] visible at https://github.com/dkg/tls-negotiated-ff-dhe or via git://lair.fifthhorseman.net/~dkg/tls-negotiated-ff-dhe From nobody Wed Apr 8 15:34: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 6516D1A909A for ; Wed, 8 Apr 2015 15:34:48 -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 UNE8cwbL8DJQ for ; Wed, 8 Apr 2015 15:34:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F92D1A9091 for ; Wed, 8 Apr 2015 15:34:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B78FCBED5; Wed, 8 Apr 2015 23:34:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Qog2KW3ts2T; Wed, 8 Apr 2015 23:34:42 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 50293BE79; Wed, 8 Apr 2015 23:34:42 +0100 (IST) Message-ID: <5525AD02.7000102@cs.tcd.ie> Date: Wed, 08 Apr 2015 23:34:42 +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: Daniel Kahn Gillmor , Benjamin Kaduk , tls@ietf.org References: <20150404020709.31136.3025.idtracker@ietfa.amsl.com> <87y4m21caq.fsf@alice.fifthhorseman.net> In-Reply-To: <87y4m21caq.fsf@alice.fifthhorseman.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Last Call: (Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 22:34:48 -0000 On 08/04/15 23:32, Daniel Kahn Gillmor wrote: > On Wed 2015-04-08 16:01:24 -0400, Benjamin Kaduk wrote: >> No interesting comments here, just a note that section 9.1 has: >> >> Pretend that a non-compatible client is compatible (e.g. by . >> This could cause the server to select a particular named group in >> >> which seems to be missing something... > > Thanks for catching that, Ben. That should be: > > (e.g. by adding the Supported Groups extension, or by adding FFDHE > groups to the extension) > > I'm accumulating these changes (including the note about relaxing 4492's > MUST NOT) in git [0]; i don't know whether i should push these edits to the > RFC editor now, or do them in batch after Last Call. The latter please. If we hit some major change or debate we can revisit that but so long as they're small changes re-issuing at the end of LC is fine. Thanks, S. > > --dkg > > [0] visible at https://github.com/dkg/tls-negotiated-ff-dhe or via > git://lair.fifthhorseman.net/~dkg/tls-negotiated-ff-dhe > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Thu Apr 9 06:52: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 E689F1B33D8 for ; Wed, 8 Apr 2015 09:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.129 X-Spam-Level: * X-Spam-Status: No, score=1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FSL_HELO_BARE_IP_2=1.675, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-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 9m_sl4Ha8Ivu for ; Wed, 8 Apr 2015 09:50:58 -0700 (PDT) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4811A8A1C for ; Wed, 8 Apr 2015 09:50:58 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YftBo-0003QP-Vk for tls@ietf.org; Wed, 08 Apr 2015 18:50:57 +0200 Received: from 66.87.138.176 ([66.87.138.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2015 18:50:56 +0200 Received: from eternaleye by 66.87.138.176 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2015 18:50:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Alex Elsayed Date: Wed, 08 Apr 2015 09:50:49 -0700 Lines: 29 Message-ID: References: <2dbc5ad134f544619db764781a8bb249@ustx2ex-dag1mb2.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 66.87.138.176 User-Agent: KNode/4.14.6 Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 06:52:39 -0700 Subject: Re: [TLS] A question to implementors about compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2015 16:51:00 -0000 Martin Thomson wrote: > On 7 April 2015 at 22:52, Alex Elsayed wrote: >> Martin Thomson wrote: >> >>> On 7 April 2015 at 06:23, Salz, Rich wrote: >>>> I want to completely remove TLS-layer compression from the next release >>>> of OpenSSL (roughly year-end). If you this will cause interop problems >>>> with >>>> your stack, can you please let me know? Thanks. >>> >>> I'm guessing that interop problems with other stacks will be the least >>> of your concerns: the uncompressed option is pretty well-tested. NSS >>> happily doesn't compress. I'd be more concerned about users who might >>> have gotten attached to the feature. >> >> Fortunately, LibreSSL ripped it out a while back, and a large number of >> things got fixed to handle that - so I think it's unlikely this will >> break the entire world; more likely about 10-25% of it (i.e. "nobody >> built this with LibreSSL" or "upstream hasn't taken patches to fix the >> build on LibreSSL"). > > Are you suggesting that LibreSSL/OpenSSL prior to the removal would > fail to properly negotiate the absence of compression? I'm fairly > sure we'd know if that was the case. No, I'm not - however, it entirely removed the #define for the flag that the program linking to LibreSSL passes in to turn it on, which meant anything that used it failed to compile. From nobody Fri Apr 10 12:46: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 3F3391A8748; Fri, 10 Apr 2015 12:46:12 -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 KAVQhQGvpNZw; Fri, 10 Apr 2015 12:46:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A5C1A86EC; Fri, 10 Apr 2015 12:46:10 -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: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410194610.21584.72939.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 12:46:10 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-sslv3-diediedie-03.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: Fri, 10 Apr 2015 19:46:12 -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 : Deprecating Secure Sockets Layer Version 3.0 Authors : Richard Barnes Martin Thomson Alfredo Pironti Adam Langley Filename : draft-ietf-tls-sslv3-diediedie-03.txt Pages : 6 Date : 2015-04-10 Abstract: Secure Sockets Layer version 3.0 (SSLv3) [RFC6101] is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular Transport Layer Security (TLS) 1.2 [RFC5246], are considerably more secure and capable protocols. This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sslv3-diediedie-03 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 Fri Apr 10 12:52: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 6B0631A1B76 for ; Fri, 10 Apr 2015 12:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-y3h-KzVqGK for ; Fri, 10 Apr 2015 12:52:51 -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 CE9171A879C for ; Fri, 10 Apr 2015 12:52:50 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so30700273obb.3 for ; Fri, 10 Apr 2015 12:52:50 -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=Wm4u/drI1U+pvy77WvDyIE/N5hp0SHSp/7SZBFCEBcA=; b=it1hp910CPPunW1qOTq1oXAQKgRzj1GkPqukaw8niQhqA+pEICNpgbs3C8wHW4j8qP /tSJQKcAhRO5SbD32pqkOxBJwGen+udzwGodjZS5bJtalzDkdJR5IZoEtHz2qBndsPJZ 1NE5n/amXXyjsNl9Y4bdRAmrLx1T4uHy2N0V/Tn5e/lOWfc21PRm9yAUPtaOZwes/ywS Js8YAeZ4Pg2o3/qdobHTR+KegAjUo+0jA7N7nMXabGVtwYDwQGNGlPJOUwVEzJQ/LINH VTYIAbeTcidOIDyEDE7Mj6rLd4VBE49fh2evFVUIsqsIBOSwc5zoLMr/lmZp6XEyqlGv LKcA== MIME-Version: 1.0 X-Received: by 10.182.34.131 with SMTP id z3mr4094788obi.4.1428695570272; Fri, 10 Apr 2015 12:52:50 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Fri, 10 Apr 2015 12:52:50 -0700 (PDT) In-Reply-To: <20150410194610.21584.72939.idtracker@ietfa.amsl.com> References: <20150410194610.21584.72939.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 12:52:50 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-sslv3-diediedie-03.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, 10 Apr 2015 19:52:53 -0000 This is a maintenance update only, it covers some of the feedback during last call(s), of which there was nothing major. The diff is pretty easy to read if you are concerned that I pulled a fast one. http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sslv3-diediedie-03 I just realized that there is a regression here, but it's a very minor one: the Abstract includes citations, which doesn't conform to the RFC style guide. I'm going to leave this to the RFC editor. On 10 April 2015 at 12:46, wrote: > Title : Deprecating Secure Sockets Layer Version 3.0 > Authors : Richard Barnes > Martin Thomson > Alfredo Pironti > Adam Langley > Filename : draft-ietf-tls-sslv3-diediedie-03.txt From nobody Fri Apr 10 16:25: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 0B7891B2E64 for ; Fri, 10 Apr 2015 16:25:56 -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 illxTqjulPhG for ; Fri, 10 Apr 2015 16:25:54 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FC81B2E63 for ; Fri, 10 Apr 2015 16:25:54 -0700 (PDT) Received: by iggg4 with SMTP id g4so10117687igg.0 for ; Fri, 10 Apr 2015 16:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=GR5i9DGRwzjmAAcmdySgeHI//SlmzzAtpMYnedYVvw4=; b=ZVenRCCOid4o3TFgOQ/bheFrKcNSAjV3AMsCQlIqP0gluqdVD4kr76eayooweX/o/Z dSfhdPw2JzEwBfXAOef29gpXPQPqex/T9IZoIuBwA2wg1DTNEQjfYaqG4AmCh4okY/6S VKisgR7jzlp8EajNJFnQk6A2p+cr7kpdVFhSc= 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:cc :content-type; bh=GR5i9DGRwzjmAAcmdySgeHI//SlmzzAtpMYnedYVvw4=; b=gwe9MoRq5S3zt4QPIhedK52/+aA1K7HSfcRS33RoOcKzUiPN8P6cMdKezOTu/FDYEE tDpVonndkBFB9g1vqxJDsJSCj1XSAAcCfWPTFP9O1GM7xeQ5eeKN06mmOMiVjpE7sJOh kLNE9NAxpwHkHr18T0t/1g/McX654YHO1i+A29TBz7X67XfaJPuTOxYIwBSKQaU4Byyd kH4xKzW+jITnosO1b7YH9g9xGXGTErNLePyGcSnSyYxmW0C87Me52kCJJSJw14zFSuf+ GEewMlpB3bP+3sn81sWvx+lCEzl46lp6SvfqXjGqNM82MVmm07NUJ9wOylfjw5888Puf T35w== X-Gm-Message-State: ALoCoQlkQ+5ncqYa+6aHSYzurkFW1T5f+8g7NIEwj0IOyAs0uU+/mTCKgpNfFymK59G9zsRX2CeV X-Received: by 10.43.72.138 with SMTP id yo10mr6818989icb.69.1428708354170; Fri, 10 Apr 2015 16:25:54 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Fri, 10 Apr 2015 23:25:53 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c204fef075e10513671572 Archived-At: Cc: Emilia Kasper , Bill Cox Subject: [TLS] draft-ietf-tls-session-hash-04 and session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2015 23:25:56 -0000 --001a11c204fef075e10513671572 Content-Type: text/plain; charset=UTF-8 Sorry this is rather late feedback. I was looking at the new session resumption provisions in draft-ietf-tls-session-hash-04, and one seems problematic. So, the draft has some SHOULDs which disable all EMS-less session resumption: > The client SHOULD NOT offer an abbreviated handshake to resume a session that does not use an extended master secret. > If the new ClientHello does not contain the "extended_master_secret" extension, the server SHOULD fall back to a full handshake by sending a ServerHello that rejects the offered session but continues with a full handshake. > If the new ServerHello does not contain the "extended_master_secret" extension, the client SHOULD abort the handshake. I suspect most implementations will ignore them for the time being. Assuming they're ignored, being only SHOULDs, > 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 abort the handshake. Consider a client which persists sessions to disk and then upgrades with EMS support. Alternatively, the server may have since upgraded while retaining the session cache. This can cause a client to offer an EMS-less session to an EMS-ful server. This MUST now causes the server to abort the handshake, which is rather unfriendly. Instead, I propose it change to: > 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 reject the session and fall back to a full handshake. The new session will still be EMS-ful and we don't risk hard-to-diagnose failures. David --001a11c204fef075e10513671572 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry this is rather late feedback. I was looking at the n= ew session resumption provisions in draft-ietf-tls-session-hash-04, and one= seems problematic.

So, the draft has some SHOULDs which= disable all EMS-less session resumption:

> The client= SHOULD NOT offer an abbreviated handshake to resume a session that does no= t use an extended master secret.

> If the new ClientHello does no= t contain the "extended_master_secret" extension, the server SHOU= LD fall back to a full handshake by sending a ServerHello that rejects the = offered session but continues with a full handshake.

> If th= e new ServerHello does not contain the "extended_master_secret" e= xtension, the client SHOULD abort the handshake.

I suspect most im= plementations will ignore them for the time being. Assuming they're ign= ored, being only SHOULDs,

> If the original session did not = use an extended master secret but the new ClientHello does contain the &quo= t;extended_master_secret" extension, the server MUST abort the handsha= ke.

Consider a client which persists sessions to disk and then upgra= des with EMS support. Alternatively, the server may have since upgraded whi= le retaining the session cache. This can cause a client to offer an EMS-les= s session to an EMS-ful server. This MUST now causes the server to abort th= e handshake, which is rather unfriendly.=C2=A0Instead, I propose it change = to:

> If the original session did not use an extended mast= er secret but the new ClientHello does contain the "extended_master_se= cret" extension, the server MUST reject the session and fall back to a= full handshake.

The new session will still be EMS-ful and we don= 9;t risk hard-to-diagnose failures.

David
--001a11c204fef075e10513671572-- From nobody Fri Apr 10 18:42: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 8F0081A006D for ; Fri, 10 Apr 2015 18:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMopZ3HUo3V6 for ; Fri, 10 Apr 2015 18:42:52 -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 5AA811A0037 for ; Fri, 10 Apr 2015 18:42:52 -0700 (PDT) Received: by qku63 with SMTP id 63so55499734qku.3 for ; Fri, 10 Apr 2015 18:42:51 -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=B1i6zMCZdvfz7D8VzGGT4I+FFbvPpnPMgu8bD0lJAdI=; b=YmV1LVCyBUU86HRfYN27PhRYw75W35q5ENLz/RWMrptPyl0LKwiaMM8c1Rrp/1f/K1 9T4D0vPm1uso5CqqPkYmlaVztRpN0/VEvGPnnBPrCkociObKfUXUxjI35FZp/2Vrk3fn g2+oeJ+iLCzyKoIrms1w3lypb8SpTT7gl3ltwo1rgNm2ujkxh0Hhr6AP1En5IDPujB8s pRxvi5gIONDVF6bQlVcvEll7P5tQxhMqseMp/fS8XNo26i17VVKdklGXf4+F/8zVimJa rvaYXgbsh3eF8VYjh2VMfnGPKFs1F/5lUhtS/ecIYTt7cdkB/jx8q2DtDPA6Xkq+GsWT 1DHQ== MIME-Version: 1.0 X-Received: by 10.182.39.195 with SMTP id r3mr4940453obk.44.1428716571638; Fri, 10 Apr 2015 18:42:51 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Fri, 10 Apr 2015 18:42:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Apr 2015 18:42:51 -0700 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Emilia Kasper , "tls@ietf.org" , Bill Cox Subject: Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Apr 2015 01:42:53 -0000 On 10 April 2015 at 16:25, David Benjamin wrote: >> 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 reject the session and fall back to a full handshake. WFM. ... MUST reject the session *resumption* and fall back ... From nobody Sat Apr 11 12:19: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 DC4851B29B6 for ; Sat, 11 Apr 2015 12:19:45 -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 pTDSvu17PFHJ for ; Sat, 11 Apr 2015 12:19:44 -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 CC6531B29B0 for ; Sat, 11 Apr 2015 12:19:41 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so39903990ieb.0 for ; Sat, 11 Apr 2015 12:19:41 -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=zwAHn56Nz2mQt3Oj6DXkpLmbFUPSIaeyoZ+/dnowENs=; b=hurM3xLW9rrM0sOp19d4WQzgfJ40NXrSWihWe7f6Q4+iiTyo8BKOWeEq4zKzxSW8cw BPjtTIkI1+Wc2nqZ8kIq0iub6t8SEi6PzopX5jHhaBy5paA4O9OD6wynU8Zrt4RuWCRU xptCMZycrZOOhXAlQkCp+JYe2y1GDoQBJs6S3f1i7jcXzwkwb7Bp0kw1p/9m5midhRzv EZoMaH+R1bV3im3SylmNDO1Qj5Bmcib2QdOdQsEdl+oTX+gxWT5c26naB0WptqPDf5T6 QR/udCiE4qRRTS9rv3DpiHFn4Ybq2n9jbKtaFE/05jyL9PATtVKI540qQGIrviLG9m3U M9IQ== MIME-Version: 1.0 X-Received: by 10.43.151.83 with SMTP id kr19mr10666059icc.3.1428779981233; Sat, 11 Apr 2015 12:19:41 -0700 (PDT) Received: by 10.50.25.231 with HTTP; Sat, 11 Apr 2015 12:19:41 -0700 (PDT) Date: Sat, 11 Apr 2015 19:19:41 +0000 Message-ID: From: Loganaden Velvindron To: TLS@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] draft-ietf-tls-sslv3-diediedie-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Apr 2015 19:19:46 -0000 Dear All, I think that this draft (draft-ietf-tls-sslv3-diediedie-03) is very close to what implementors are doing already. For example: LibreSSL disabled SSLv3 by default since last year. Kind regards, //Logan C-x-C-c From nobody Sun Apr 12 09:55: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 25E1A1A03F9 for ; Sun, 12 Apr 2015 09:55:48 -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, 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 ObUiPJPXnnBt for ; Sun, 12 Apr 2015 09:55:46 -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 171841A014E for ; Sun, 12 Apr 2015 09:55:44 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 65E19699D4; Sun, 12 Apr 2015 19:55:42 +0300 (EEST) Date: Sun, 12 Apr 2015 19:55:42 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150412165542.GA19481@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: [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: Sun, 12 Apr 2015 16:55:48 -0000 On Sun, Mar 22, 2015 at 02:49:28PM -0700, Eric Rescorla wrote: > In the interim in Seattle, we had an extensive discussion of 0-RTT > anti-replay in which DKG observed that all the proposed anti-replay > mechanisms provide limited protection. The underlying problem is the > desire to present a uniform interface in which the calling application > can count on reliable delivery of the data it provides in the first > flight, thus requiring the TLS stack to retransmit it automatically. 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)? 2) What are the semantics of successfully received 0-RTT transfer (especially considering the client-side autoretransmit on failure)? 3) How does 0-RTT interact with ALPN (especially considering potential for multiple protocol candidates)? 4) Can handshake with attempted 0-RTT be securely downgraded to v1.2 (obviously causes the 0-RTT to fail)? 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? 6) The same as above, but when attempting to resume a session. with a client certificate (since cc is property of session)? 7) What guidance to give regarding what data can be put to 0-RTT, considering its replayability? 8) If resumption attempt has 0-RTT data, what keying material is used for the 0-RTT? 9) Can server roll over its 0-RTT keys without waiting for the previous ones to expire? 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? -Ilari From nobody Sun Apr 12 23:01: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 9863D1B2CD7 for ; Sun, 12 Apr 2015 23:01:57 -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 V_ruCLRuOoZE for ; Sun, 12 Apr 2015 23:01:56 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 001A81B2D28 for ; Sun, 12 Apr 2015 23:01:55 -0700 (PDT) Received: by qkhg7 with SMTP id g7so163111193qkh.2 for ; Sun, 12 Apr 2015 23:01:55 -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=ifdarSjzcc4JT3UFAONJ1k5dCaMnjZFBE6C7BDKuUFU=; b=EmrmUkXwekMBD50EG9Ue2g2NZzjZIqaYZc408p+hGUiWB0zYnpPG61gVlkgAO37uK6 vCN+bgD/WO5zC7WyiwFW/YSA70efDRAsDSYunU6SzOnk3T3Y040nj2Bgegkf720s+S20 xHAsS6EtCGipgnP0xjljK05+QuQR1xRlwRv6vwh8J+BAi8ppD2ph9I3P/FppmIVkIEEe LGuhHIwigTe1GHin7ZC9H4CJIGZTAdqdWOt15NVYB6kOpa/4VdyInJHlyrOyHJB9AGiE S5KApJT66voZStKUun1CazIAilTGYXs/tXqIbkxtzxwQSqH4nfpXh/eKrmVUOtz3m7w1 WVcw== X-Received: by 10.55.31.137 with SMTP id n9mr26233823qkh.91.1428904915319; Sun, 12 Apr 2015 23:01:55 -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 i185sm5117472qhc.18.2015.04.12.23.01.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 12 Apr 2015 23:01:54 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 13 Apr 2015 02:01:52 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150407063133.GA5877@LK-Perkele-VII> In-Reply-To: <20150407063133.GA5877@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-Id: <201504130201.53432.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 06:01:57 -0000 T24gVHVlc2RheSwgQXByaWwgMDcsIDIwMTUgMDI6MzE6MzMgYW0gSWxhcmkgTGl1c3ZhYXJhIHdy b3RlOgo+IEFsc28sIHRoZSBjZXJ0aWZpY2F0ZSBmb3JtYXQgbmVnb3RpYXRpb24gaXMgc3VwcG9z ZWRseSBib3RoIHZpYQo+IGNpcGhlcnN1aXRlcyBhbmQgYW4gZXh0ZW5zaW9uLiBBbmQgd2hlbiB5 b3UgaGF2ZSB0aGUgc2FtZSB0aGluZyBpbgo+IHR3byBwbGFjZXMsIHRoZSByZWxldmFudCBxdWVz dGlvbiBpcyAid2hpY2ggaXMgZGVmaW5pdGl2ZT8iLgoKSGVyZSdzIGEgZGlmZmVyZW50IGlkZWEg Zm9yIGZpeGluZyB0aGUgY29tYmluYXRvcmlhbCBtZXNzOiBGb3IgVExTIDEuMyssIG9ubHkgdXNl IGNpcGhlciBzdWl0ZXMgdG8gbmVnb3RpYXRlIHN5bW1ldHJpYyBjaXBoZXJzLiBSZWx5IGVudGly ZWx5IG9uIHRoZSBleHRlbnNpb25zIGZvciB0aGUgaGFuZHNoYWtlLgoKRm9yIHRoZSBoYW5kc2hh a2UsIG1hbmRhdGUgdXNhZ2Ugb2YgdGhlICJzdXBwb3J0ZWRfZ3JvdXBzIiBleHRlbnNpb24gKG7D qWUgImVsbGlwdGljX2N1cnZlcyIpIGFuZCB0aGUg4oCcc2lnbmF0dXJlX2FsZ29yaXRobXPigJ0g ZXh0ZW5zaW9uIGZvciBhbGwgY29ubmVjdGlvbiBhdHRlbXB0cy4gKHJlamVjdCBjb25uZWN0aW9u IGlmIG5vdCBwcmVzZW50IGFuZCB2YWxpZCkgSWYgVExTIDEuMysgaXMgbmVnb3RpYXRlZCwgdGhl biB0aGUgREhFL0VDREhFIHdpbGwgYmUgc2VsZWN0ZWQgYmFzZWQgb24gdGhlIGhpZ2hlc3QgcHJl ZmVycmVkIHN1cHBvcnRlZCBOYW1lZEdyb3VwIGFuZCBSU0EvRUNEU0EvZXRjIHdpbGwgYmUgc2Vs ZWN0ZWQgYmFzZWQgb24gdGhlIGhpZ2hlc3QgcHJlZmVycmVkIFNpZ25hdHVyZUFuZEhhc2hBbGdv cml0aG0uIEFzc2lnbiBwb2ludHMgdG8gTmFtZWRHcm91cCBhbmQgU2lnbmF0dXJlQWxnb3JpdGht IHRvIG5lZ290aWF0ZSBQU0sgdXNhZ2UgdmlhIHRoZSBleHRlbnNpb25zLiAoZS5nLiBOYW1lZEdy b3VwPTAgZm9yIHBsYWluIFBTSykgVGhlIHNlcnZlciB3b3VsZCB0aGVuIGlnbm9yZSBldmVyeXRo aW5nIGluIHByb3Bvc2VkIGNpcGhlciBzdWl0ZXMgb3RoZXIgdGhhbiB0aGUgc3ltbWV0cmljIGNp cGhlciBzdWl0ZSBjb21wb25lbnRzLiAoZS5nLiBhbGwgb2YgdGhlIGZvbGxvd2luZyB3b3VsZCBi ZSBjb25zaWRlcmVkIGVxdWl2YWxlbnQgZm9yIFRMUyAxLjMrOiBUTFNfREhFX1JTQV9XSVRIX0FF U18xMjhfR0NNX1NIQTI1NiwgVExTX0VDREhFX1JTQV9XSVRIX0FFU18xMjhfR0NNX1NIQTI1Niwg VExTX0VDREhFX0VDRFNBX1dJVEhfQUVTXzEyOF9HQ01fU0hBMjU2KSBOZXcgY2lwaGVycyB0aGF0 IGFyZSBzdXBwb3J0ZWQgdmlhIFRMUyAxLjMrIHdvdWxkIG9ubHkgbmVlZCB0byBkZWZpbmUgc29t ZXRoaW5nIGluIHRoZSBmb3JtIG9mIFRMU19FWFRfV0lUSF94X3lfeiB3aXRoIHZhcmlhdGlvbnMg b2Ygc3ltbWV0cmljIHBhcmFtZXRlcnMgKGZvciBPQ0IsIHRoZXJlJ2QgYmUgb25seSAyIHN1aXRl cykuIE5ldyBjaXBoZXJzIHRoYXQgd2lzaCB0byBzdXBwb3J0IFRMUyAxLjIgYnV0IHdpdGhvdXQg YWRkaW5nIHRoZSBsaXRhbnkgb2YgY29tYmluYXRpb25zIG9mIHN1aXRlcyBjb3VsZCBzaW1wbHkg YWxsb3cgbmVnb3RpYXRpb24gb2YgYW55IG9mIHRoZSBuZXcgc3VpdGVzIHRvIGFzc3VtZSBESEVf UlNBIHVubGVzcyB0aGUgbmVjZXNzYXJ5IGV4dGVuc2lvbnMgYXJlIHVzZWQgdG8gc2F5IG90aGVy d2lzZS4gKHRob3VnaCwganVzdCByZXF1aXJpbmcgdGhlIGV4dGVuc2lvbnMgdG8gdXNlIHRoZW0g aXMgbm90IHVucmVhc29uYWJsZSkKClRoaXMgcm91dGUgZG9lcyBub3QgY2hhbmdlIGNpcGhlciBz dWl0ZXMgaW4gYSBtYWpvciB3YXkgYW5kIHVzZXMgYWxyZWFkeSBpbi1kcmFmdCBleHRlbnNpb25z IHRvIGRvIHRoZSBuZWdvdGlhdGlvbiwgd2l0aG91dCBhbnkgbW9kaWZpY2F0aW9ucyBiZXlvbmQg bWFuZGF0aW5nIHRoZWlyIHVzZSBhbmQgYWJzb2x1dGUgcHJpb3JpdHkgb3ZlciB0aGUgcGFyYW1l dGVycyBzcGVjaWZpZWQgaW4gdGhlIGNpcGhlciBzdWl0ZS4gTm90IG9ubHkgZG9lcyB0aGlzIG1h a2UgdGhlIGNpcGhlciBzdWl0ZSBzZWxlY3Rpb24gc2ltcGxlciBhbmQgYXZvaWRzIGVuZHBvaW50 cyBub3QgbmVnb3RpYXRpbmcgYSB2aWFibGUgY29tYmluYXRpb24gdGhhdCdzIGp1c3Qgbm90IG9m ZmVyZWQgaW4gdGhlIGxpc3QsIGJ1dCBpdCByZW1vdmVzIGFueSBleGlzdGluZyBhbWJpZ3VpdHkg b3ZlciB3aGljaCBzdXBwb3J0IGxpc3RpbmcgaXMgZGVmaW5pdGl2ZS4gQ2lwaGVyIHN1aXRlcyBu ZWdvdGlhdGUgc3ltbWV0cmljIGFuZCB0aGVzZSB0d28gZXh0ZW5zaW9uIG5lZ290aWF0ZSBhc3lt bWV0cmljLgoKCkRhdmUK From nobody Mon Apr 13 00:08: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 067AE1B2E6C; Mon, 13 Apr 2015 00:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsFFpj9dDS4t; Mon, 13 Apr 2015 00:08:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A32B31B2E62; Mon, 13 Apr 2015 00:08:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150413070843.1441.66274.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 00:08:43 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [TLS] Last Call Expired: 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: Mon, 13 Apr 2015 07:08:45 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Mon Apr 13 00: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 9E6661B2E8A for ; Mon, 13 Apr 2015 00:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoa_sNYx8BhB for ; Mon, 13 Apr 2015 00:14:49 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1201B2E88 for ; Mon, 13 Apr 2015 00:14:49 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 77C7BF984 for ; Mon, 13 Apr 2015 03:14:46 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id BBC521FF48; Mon, 13 Apr 2015 02:14:45 -0500 (CDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: <201504130201.53432.davemgarrett@gmail.com> References: <20150407063133.GA5877@LK-Perkele-VII> <201504130201.53432.davemgarrett@gmail.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 13 Apr 2015 03:14:45 -0400 Message-ID: <87sic4v6sa.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 07:14:50 -0000 On Mon 2015-04-13 02:01:52 -0400, Dave Garrett wrote: > On Tuesday, April 07, 2015 02:31:33 am Ilari Liusvaara wrote: >> Also, the certificate format negotiation is supposedly both via >> ciphersuites and an extension. And when you have the same thing in >> two places, the relevant question is "which is definitive?". > > Here's a different idea for fixing the combinatorial mess: For TLS > 1.3+, only use cipher suites to negotiate symmetric ciphers. Rely > entirely on the extensions for the handshake. This is the cleanest and most backward-compatible suggestion i've heard yet for a la carte algorithm selection in TLS. If we decide to do a la carte algorithm selection, this seems like a variant i could be comfortable with. > For the handshake, mandate usage of the "supported_groups" extension > (née "elliptic_curves") and the “signature_algorithms” extension for > all connection attempts. (reject connection if not present and valid) > If TLS 1.3+ is negotiated, then the DHE/ECDHE will be selected based > on the highest preferred supported NamedGroup and RSA/ECDSA/etc will > be selected based on the highest preferred > SignatureAndHashAlgorithm. Assign points to NamedGroup and > SignatureAlgorithm to negotiate PSK usage via the > extensions. (e.g. NamedGroup=0 for plain PSK) I'm not convinced that we want to use 0 for PSK (this may be purely aesthetic: it makes PSK sound like the "default", and if we later find other non-DH key exchange we want to stuff in this registry, it'd be nice to group them together, and there are no available neighbors close to 0). I think i'd be ok using some other currently-unallocated codepoint, though. > The server would then ignore everything in proposed cipher suites > other than the symmetric cipher suite components. (e.g. all of the > following would be considered equivalent for TLS 1.3+: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) New ciphers that are > supported via TLS 1.3+ would only need to define something in the form > of TLS_EXT_WITH_x_y_z with variations of symmetric parameters (for > OCB, there'd be only 2 suites). New ciphers that wish to support TLS > 1.2 but without adding the litany of combinations of suites could > simply allow negotiation of any of the new suites to assume DHE_RSA > unless the necessary extensions are used to say otherwise. (though, > just requiring the extensions to use them is not unreasonable) We could also say that TLS 1.2 implementations that know about a new symmetric cipher must be able to negotiate key exchange choice independently via the supported_group ("supported_key_exchange"?) mechanism when that cipher is selected. --dkg From nobody Mon Apr 13 01:26: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 2E6FA1B2ECB for ; Mon, 13 Apr 2015 01:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 kQmVHFXV3w9Q for ; Mon, 13 Apr 2015 01:26:50 -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 E31561B2EC4 for ; Mon, 13 Apr 2015 01:26:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,568,1422918000"; d="scan'208";a="133746253" Received: from wifi-auth-191208.inria.fr ([128.93.191.208]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 13 Apr 2015 10:26:36 +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: Date: Mon, 13 Apr 2015 10:26:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <147002D3-4F04-4895-8826-C9FE3664D6BA@gmail.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Emilia Kasper , "tls@ietf.org" , Bill Cox Subject: Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Apr 2015 08:26:52 -0000 How about the following: 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 fall back to a full handshake by sending a ServerHello that rejects session resumption and offers a new session. On 11 Apr 2015, at 03:42, Martin Thomson = wrote: > On 10 April 2015 at 16:25, David Benjamin = wrote: >>> 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 reject the session and fall back to a full handshake. >=20 > WFM. >=20 > ... MUST reject the session *resumption* and fall back ... >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Apr 13 05:59: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 150BD1B2F73 for ; Mon, 13 Apr 2015 05:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rg-g_4TEZTb for ; Mon, 13 Apr 2015 05:59:06 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 D02BF1B2F58 for ; Mon, 13 Apr 2015 05:59:05 -0700 (PDT) Received: by widdi4 with SMTP id di4so71198936wid.0 for ; Mon, 13 Apr 2015 05:59:04 -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=XxEPtNKmQqwwl1x8IXHZv0R52W3vdoSkHfXFwM3mwiM=; b=CZ+TS0yBWpdv8upb+MnCC352rAHvnYeuM1EVrXE4iMAC9mRMEyKZjCQ4D1ALEPvcd0 zu6MQ8ED1N0PQAy/oAPY6l0Ffl3AtLNULuEiohZF0cfWKrivXRSBxdztv+Ew9Y/6B0XM c2JDoqbgl3Mz+ApNtbP1cpzAxw+8rOfzmeNDIGRP9zKqLBSCec9XT30w/F3bqrW1/Enl mhYtpO889jdcyDfn9fYs7adCbvIcD4IopCTcjCvPYXn5yw/9r06UBcXsGp/HSFzd+zFs S1BJz7Sx4bCMaSiYIzIolookUKQBBBH3m/atVz9/C9DxnGNAcoULyb4/H0GXaDWz7ghV WGWg== X-Gm-Message-State: ALoCoQmqZogBd/kSXYVgB/zy5bdlB1HdWOryxGsXRQLgWmBM61jWCo4rlLk9mXkPrv3aN7m7WQY4 X-Received: by 10.194.177.167 with SMTP id cr7mr26476466wjc.19.1428929944551; Mon, 13 Apr 2015 05:59:04 -0700 (PDT) Received: from [192.168.23.81] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by mx.google.com with ESMTPSA id eh5sm11401009wic.20.2015.04.13.05.59.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Apr 2015 05:59:03 -0700 (PDT) Message-ID: <552BBD92.3010807@azet.org> Date: Mon, 13 Apr 2015 14:58:58 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <20150401201221.163745c2@pc1.fritz.box> <201504032121.07726.davemgarrett@gmail.com> <551F6E22.1040207@azet.org> <201504041141.39158.davemgarrett@gmail.com> In-Reply-To: <201504041141.39158.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig52B3B2557CD2DFE98B2DA3E8" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 12:59:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig52B3B2557CD2DFE98B2DA3E8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dave et al., Sorry for the late reply. Dave Garrett wrote: > I'm fine with (EC)DHE_PSK, but I thought the consensus was that non-eph= emeral cipher suites were not permitted any longer. I thought usage of pl= ain PSK would be against TLS 1.3 & HTTP/2 consensus. If it really is need= ed, I think they should be prohibited in general TLS and only allowed via= the IoT application profile. As the draft currently is written it also applies to TLS 1.2. I have no problem with removing non-ephemeral ciphersuites from the document, given that there's agreement among embedded implementers. So far no further comments on the ensuing discussion, your ideas are all very interesting and -- I think -- are well worth exploring. Aaron --------------enig52B3B2557CD2DFE98B2DA3E8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVK72TAAoJEOTbZJL9ubXVcbQQAIkFixuBoD205e18wV0U/vEx G/ySqIiuxX9svJG/u5IcSoQEW3q21ZCZ03KWBXzoOfQj7He6ZVQZPwCYZbE2kCLw SYl7M59xZA9nGc0d0TF8uY3CEY/l0tk7FjGrcZLBCw6pE1++CWM1SG5J5KHNNQvb navQsnD9eqesH346Sm2m/t2Pf+Vmzm0FnUnzJpTn/Dg1n1SMxDvYP4+jH8QhVC06 wDEFPgDnA7d2cNyjMRcBIu9n7KrMf2JS9KFlHQV0SBKkgb2jvSYh2V8PsH4eR4Dt eXUxTkCdqquG1Fc5y6tWwI2QNn9ydi9l6zNFMt8uF1iWRtym70pM6K3GyyUpN3cB 87eMHzPdQyYJLEpXENtK6sTpFaRsD4vdvWRd4v1V73dqklLdgh3J0hWTUZo9BS+V j6jNc2cxl2P+xOyhubd4fKOQWBo2Qe9cGnvYDRYx2rLdk+MMiQmp+4d+CmQz9Yro ndbZDYn/Wp7YHGeiNaOMsExad5dnu61FIGHoqSLTe2hS8AZWqltVdAnqiof9Us9M wq6IkjuX9hz/btZJR+rdnRWx7wlM8MCeXJE2yrOMl1BgnB2b3UCbLYDsPs571u/R 7FqLri66rs1MavLXShXAPeh6fi8+ARkNpdyrBEHEeJBaj6TsUsJ1461UUz1vfZKI K+EEkSG/7XjyG5mTtsZ9 =ENXf -----END PGP SIGNATURE----- --------------enig52B3B2557CD2DFE98B2DA3E8-- From nobody Mon Apr 13 09:00: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 D68771ACE4D for ; Mon, 13 Apr 2015 09:00: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 WdR1KsN_rUhy for ; Mon, 13 Apr 2015 09:00:02 -0700 (PDT) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::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 81A0F1ACE44 for ; Mon, 13 Apr 2015 09:00:02 -0700 (PDT) Received: by vnbf1 with SMTP id f1so21114644vnb.0 for ; Mon, 13 Apr 2015 09:00: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=3RRPVhQxQQAoYFC1LziG0U5+X0rltE5G/tWNzDRipgw=; b=dDi5owwtmUOh3qmBBbv+LGC5pcEmkGEyZEq4COoJGONVahGu9aUetQEgqeWH9KiLYk WFe47UnsDVAU/peOs/ttPhke2RiR6lXEbjAR2ihkPsxZSjPyeuNaL/8VpFxlTlyQpOUw KvRATS43WmkqizThvCwDVy3gy/ax28k+mjY8plrNdpRvgFdgB+kE32VPaTBWxc9ndwPN Bryb9xgUdaAUgSNbKxeoyoS1qMvAcXF3eqMpswPajKVUUbcsjPfASbn8UO0/y74Yy9eQ ZeBXQ9bGlI39bbvCu09KYniH71gWyOVLeFG/aeTgZ+WzOPef+xlcPWlrdOCsJVqsfRVQ 6RtQ== X-Received: by 10.140.97.203 with SMTP id m69mr18632548qge.39.1428940801763; Mon, 13 Apr 2015 09:00: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 187sm6094962qhv.8.2015.04.13.09.00.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 09:00:01 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Daniel Kahn Gillmor Date: Mon, 13 Apr 2015 12:00:00 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504130201.53432.davemgarrett@gmail.com> <87sic4v6sa.fsf@alice.fifthhorseman.net> In-Reply-To: <87sic4v6sa.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504131200.00384.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 16:00:04 -0000 On Monday, April 13, 2015 03:14:45 am Daniel Kahn Gillmor wrote: > On Mon 2015-04-13 02:01:52 -0400, Dave Garrett wrote: > > Assign points to NamedGroup and > > SignatureAlgorithm to negotiate PSK usage via the > > extensions. (e.g. NamedGroup=0 for plain PSK) > > I'm not convinced that we want to use 0 for PSK (this may be purely > aesthetic: it makes PSK sound like the "default", and if we later find > other non-DH key exchange we want to stuff in this registry, it'd be > nice to group them together, and there are no available neighbors close > to 0). I think i'd be ok using some other currently-unallocated > codepoint, though. The thought process was 0 for N/A in the case of PSK without (EC)DHE. I would much prefer that only (EC)DHE_PSK be permitted, which would make this a non-issue. Dave From nobody Mon Apr 13 09:50: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 B87D41ACECB for ; Mon, 13 Apr 2015 09:50:01 -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 6wkC5JyKIAk4 for ; Mon, 13 Apr 2015 09:49:59 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C62F51ACEDC for ; Mon, 13 Apr 2015 09:49:59 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 96370F984 for ; Mon, 13 Apr 2015 12:49:56 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1C11E20088; Mon, 13 Apr 2015 11:49:45 -0500 (CDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: <201504131200.00384.davemgarrett@gmail.com> References: <201504130201.53432.davemgarrett@gmail.com> <87sic4v6sa.fsf@alice.fifthhorseman.net> <201504131200.00384.davemgarrett@gmail.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 13 Apr 2015 12:49:45 -0400 Message-ID: <874mokug5y.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 16:50:02 -0000 On Mon 2015-04-13 12:00:00 -0400, Dave Garrett wrote: > On Monday, April 13, 2015 03:14:45 am Daniel Kahn Gillmor wrote: >> On Mon 2015-04-13 02:01:52 -0400, Dave Garrett wrote: >> > Assign points to NamedGroup and >> > SignatureAlgorithm to negotiate PSK usage via the >> > extensions. (e.g. NamedGroup=0 for plain PSK) >> >> I'm not convinced that we want to use 0 for PSK (this may be purely >> aesthetic: it makes PSK sound like the "default", and if we later find >> other non-DH key exchange we want to stuff in this registry, it'd be >> nice to group them together, and there are no available neighbors close >> to 0). I think i'd be ok using some other currently-unallocated >> codepoint, though. > > The thought process was 0 for N/A in the case of PSK without > (EC)DHE. I would much prefer that only (EC)DHE_PSK be permitted, which > would make this a non-issue. Hm, let's look at the representations of ((EC)DHE_)PSK in the scheme you propose. You've split the suite using these terms and mechanisms: "symmetric" (indicated by ciphersuite list) "handshake" (indicated by known_groups extension) "signature" (indicated by signature_algorithms extension) I'd recommend using slightly different terminology, since at least "handshake" is already overloaded to mean something broader in TLS. "symmetric" (ciphersuite list) "key agreement" (known_groups extension) "authentication" (signature_algorithms extension) In this model, ECDHE_PSK would have: key agreement: ECDHE authentication: PSK while non-(EC)DHE PSK would have: key agreement: PSK authentication: PSK right? we'd only need a key agreement codepoint for PSK in the case we have non-(EC)DHE, but i have heard some constrained-devices people arguing for that in the WG, so that seems like a likely outcome. So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer were to try to negotiate: key agreement: PSK authentication: RSA-PSS Do we just say "don't do that"? clients using existing RSA_PSK ciphersuites [0] use the server's RSA key to encrypt the, uh, pre-premaster secret, which is then mixed with the PSK to complete the key exchange. This is *not* an RSA signature, and we're getting rid of the encrypted premaster secret approach in TLS 1.3 entirely. So the above seems like a novel (and possibly useless) combination. As for placing the known_groups codepoint at 0: it's conceivable that in the future someone wants to resurrect SRP or add some other PAKE or any other non-DH key agreement scheme (with or without forward secrecy and with or without authentication), in which case it would be aesthetically nice to have a block of "neighbors" with similar properties -- using 0 doesn't let us do that grouping. --dkg [0] https://tools.ietf.org/html/rfc4279#section-4 From nobody Mon Apr 13 10:02: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 8E9261A1A15 for ; Mon, 13 Apr 2015 10:02:45 -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 lYRYVX2d-PAd for ; Mon, 13 Apr 2015 10:02:44 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1ED1A19E9 for ; Mon, 13 Apr 2015 10:02:43 -0700 (PDT) Received: by oiko83 with SMTP id o83so9534097oik.1 for ; Mon, 13 Apr 2015 10:02: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:date:message-id:subject:from:to :cc:content-type; bh=QGXUPBajTIFmUjDyRA5PCx0BXMSbYOyhtL4aYVmC6XA=; b=A1GZRI3lidu4XIP/YfjDsImzc/OrrVHLTB566EjlXh7cokCnjUZhY10OvLSRczXJqx HclXnJ16ecj0r5z7wuHbdYSiF8wEXYoKx9mr75yj+kMwz5/sxNS+bLHxh1uWzfMnMOd1 WtVs9dABlhxNGysjwtHT52BnkMvAI53WBw7+Yaji1PJvuLWLgQAkanNyPWaa/KPwolFP xPs5+jpaeTQvxvdaGjmlfQKPmfBP39HzI/l3KfilfvvAND9klqWsb28xeAgMgNP1xEYB K8jI15pEc2uYFiN3wgoZBAJLof90gn7OMkk7S4Km04igKR0qlf3otpK8GmJ/U9VJKVjH qjQA== MIME-Version: 1.0 X-Received: by 10.202.200.209 with SMTP id y200mr8041607oif.20.1428944563449; Mon, 13 Apr 2015 10:02:43 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Mon, 13 Apr 2015 10:02:43 -0700 (PDT) In-Reply-To: <20150412165542.GA19481@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> Date: Mon, 13 Apr 2015 10:02:43 -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: Mon, 13 Apr 2015 17:02:45 -0000 On 12 April 2015 at 09:55, Ilari Liusvaara wrote: > 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)? This would have to be similar to the client one, which if you recall was either: client.addReplayableData(replayable); client.connect(); or: client.addUnreliableData(unreliable); client.connect(); client.onunreliabledatalost = () => tls.send(unreliable); You would have to have the server opt in either with: server.enableReplayableData(true); server.accept(443); or: server.onunreliabledata = data => { /* handle it */ } server.accept(443); I hope my javascript isn't too obtuse. > 2) What are the semantics of successfully received 0-RTT transfer (especially considering the client-side autoretransmit on failure)? This is protocol-defined. But I imagine that this depends on the model we employ. Replayable data could just be consider the start of a stream. On the other hand, unreliable data doesn't work very well for a stream mode. Conversely, replayable data makes no sense in a datagram mode, but all data is unreliable there. > 3) How does 0-RTT interact with ALPN (especially considering potential for multiple protocol candidates)? I imagine that the ALPN from the previous session applies. If the client wants to change anything, it probably shouldn't use 0-RTT. Note that this includes cipher suites and maybe other extensions too. > 4) Can handshake with attempted 0-RTT be securely downgraded to v1.2 (obviously causes the 0-RTT to fail)? Not safely. The decision we made at the last meeting (or interim, I can't remember) was to require that the server make a commitment to support - or at least to ignore - TLS 1.3 handshake for at least the validity period of the 0-RTT information. The 0-RTT messages might be ignored in DTLS, but they are unlikely to be handled cleanly by a TLS 1.2 implementation. I would expect a fatal error. > 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? How is that materially different to other suites? > 6) The same as above, but when attempting to resume a session. with a client certificate (since cc is property of session)? As before, if the information is replayable, then it needs to be understood by both parties that it is replayable. And both need to understand how that is not a concern. The client certificate doesn't present a special risk here. At least not as far as I've been able to determine. > 7) What guidance to give regarding what data can be put to 0-RTT, considering its replayability? What guidance do you want? It's replayable. If it causes something to happen that you don't want to have happen twice (or more), then don't use 0-RTT. > 8) If resumption attempt has 0-RTT data, what keying material is used for the 0-RTT? That combination might not be valid. If it is, I'm guessing that the first client flight is encrypted and authenticated as a "normal" 0-RTT handshake. > 9) Can server roll over its 0-RTT keys without waiting for the previous ones to expire? Yes, there will need to be a key identifier in the clear that allows a server to identify which key to use to decrypt the client's flight. > 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? Well, the attacker presumably doesn't have the private keys used by either client or server. They might be able to cause a replay, but if we have decent crypto, they aren't able to decrypt anything, nor can they continue the session. From nobody Mon Apr 13 10:25: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 A27E81A8791 for ; Mon, 13 Apr 2015 10:25:26 -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 qR7VcwkYvuTF for ; Mon, 13 Apr 2015 10:25:25 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 1A2AE1ACF1C for ; Mon, 13 Apr 2015 10:25:24 -0700 (PDT) Received: by qkhg7 with SMTP id g7so190572689qkh.2 for ; Mon, 13 Apr 2015 10:25: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:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=/pVeEfFwBgfJhiTih6dKDHVNHwlWMqA/Am7WS+YtQqI=; b=q9It53Tpi5lo+3Rbhjty090nP/Q49ZF2FNOX39HIXSaYTlEI0PRvMWAqCDd3aPgQeE RPYe1zmpPB+00top1yKqLZ2bcQGi2uZ/TvjG+9cnnv7jfbxEMYymqIS78zbPK+VU3aJr XdBvxKIbyYPHan3YNMySDU93V6VDjDxMXftwJbkOG/Um/ubz/J/yqpoUd5IBFesjCQyk hJ9jx1iQuxndybLB5f4rz8AkpXKWxZmWa9/dL5lfBGTQ4lsTV9WE98W1cQzrv72aoHqo Kcn7Fv1f8QgmUQWr3csi+tgZnY/7MHiZwmPrD/b045V0hEwYl3Qwx1EAzzgKZBTzBcjj kisQ== X-Received: by 10.55.16.140 with SMTP id 12mr30898157qkq.39.1428945921806; Mon, 13 Apr 2015 10:25:21 -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 s7sm6293746qgd.4.2015.04.13.10.25.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 10:25:21 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Daniel Kahn Gillmor Date: Mon, 13 Apr 2015 13:25:20 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> In-Reply-To: <874mokug5y.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201504131325.20590.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 17:25:26 -0000 On Monday, April 13, 2015 12:49:45 pm Daniel Kahn Gillmor wrote: > On Mon 2015-04-13 12:00:00 -0400, Dave Garrett wrote: > > The thought process was 0 for N/A in the case of PSK without > > (EC)DHE. I would much prefer that only (EC)DHE_PSK be permitted, which > > would make this a non-issue. > > Hm, let's look at the representations of ((EC)DHE_)PSK in the scheme you > propose. You've split the suite using these terms and mechanisms: > > "symmetric" (indicated by ciphersuite list) > > "handshake" (indicated by known_groups extension) > > "signature" (indicated by signature_algorithms extension) > > I'd recommend using slightly different terminology, since at least > "handshake" is already overloaded to mean something broader in TLS. > > "symmetric" (ciphersuite list) > > "key agreement" (known_groups extension) > > "authentication" (signature_algorithms extension) Yes, this could avoid some miscommunication. The "handshake" includes both key agreement and authentication, so it would be better to be explicit. In fact, if we're already renaming the extension, elliptic_curves/supported_groups could be better named as key_agreement_algorithms to better align with the signature_algorithms naming and explain its purpose better. > In this model, ECDHE_PSK would have: > > key agreement: ECDHE > authentication: PSK > > while non-(EC)DHE PSK would have: > > key agreement: PSK > authentication: PSK > > right? Yes. > we'd only need a key agreement codepoint for PSK in the case we have > non-(EC)DHE, but i have heard some constrained-devices people arguing > for that in the WG, so that seems like a likely outcome. Yes. Not sure if allowing non-FS is a given, though. If they're really constrained, I think a much better alternative would be to define some (EC)DHE optimized for performance but only providing a minimum reasonable level of forward secrecy, even if not ideal. > So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer > were to try to negotiate: > > key agreement: PSK > authentication: RSA-PSS > > Do we just say "don't do that"? SGTM > As for placing the known_groups codepoint at 0: it's conceivable that in > the future someone wants to resurrect SRP or add some other PAKE or any > other non-DH key agreement scheme (with or without forward secrecy and > with or without authentication), in which case it would be aesthetically > nice to have a block of "neighbors" with similar properties -- using 0 > doesn't let us do that grouping. The codepoint is of course rather arbitrary, so picking some other value for future-proofing is fine. It's a 16-bit space so there's plenty of room. Dave From nobody Mon Apr 13 10:31: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 6DB581AD05F for ; Mon, 13 Apr 2015 10:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvaCJPu6svIQ for ; Mon, 13 Apr 2015 10:31:26 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8042C1AD05E for ; Mon, 13 Apr 2015 10:31:26 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 1C16BF984; Mon, 13 Apr 2015 13:31:23 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 072A3200F2; Mon, 13 Apr 2015 12:31:13 -0500 (CDT) From: Daniel Kahn Gillmor To: Dave Garrett , tls@ietf.org In-Reply-To: <201504131325.20590.davemgarrett@gmail.com> References: <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> <201504131325.20590.davemgarrett@gmail.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 13 Apr 2015 13:31:12 -0400 Message-ID: <871tjoue8v.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 17:31:27 -0000 On Mon 2015-04-13 13:25:20 -0400, Dave Garrett wrote: >> So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer >> were to try to negotiate: >> >> key agreement: PSK >> authentication: RSA-PSS >> >> Do we just say "don't do that"? > > SGTM This, i think, is one of the serious concerns about splitting the ciphersuite into orthogonal vectors. Once the full cartesian explosion is available by multidimensional enumeration, we have to mark out which corners of the space are actually bad ideas, and we have to make sure our implementations don't stumble into those corners by accident. This isn't impossible to do, but it seems ripe for subtle implementation bugs. --dkg From nobody Mon Apr 13 10:32: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 62BCB1AD05E for ; Mon, 13 Apr 2015 10:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uESMTWq2Z7Xg for ; Mon, 13 Apr 2015 10:32:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299C71ACF56 for ; Mon, 13 Apr 2015 10:32:50 -0700 (PDT) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (0.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (0.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 13 Apr 2015 17:32:30 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) with mapi id 15.01.0136.014; Mon, 13 Apr 2015 17:32:31 +0000 From: Andrei Popov To: Dave Garrett , "tls@ietf.org" Thread-Topic: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die) Thread-Index: AQHQda9fdjXdn4LJ2k69eyYuz+NEV51LMihw Date: Mon, 13 Apr 2015 17:32:31 +0000 Message-ID: References: <20150407063133.GA5877@LK-Perkele-VII> <201504130201.53432.davemgarrett@gmail.com> In-Reply-To: <201504130201.53432.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(979002)(6009001)(13464003)(24454002)(377454003)(33656002)(40100003)(46102003)(77156002)(92566002)(93886004)(87936001)(122556002)(106116001)(76576001)(19580405001)(19580395003)(107886001)(2656002)(86612001)(2501003)(54356999)(2950100001)(2900100001)(15975445007)(76176999)(102836002)(62966003)(99286002)(50986999)(74316001)(86362001)(4001410100001)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1251; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 0545EFAC9A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2015 17:32:31.1805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1251 Archived-At: Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 17:32:52 -0000 VGhlIGlkZWEgb2YgZml4aW5nIHRoZSBjb21iaW5hdG9yaWFsIG1lc3MgaXMgYXBwZWFsaW5nIHRv IG1lLCBmb3IgYSB2YXJpZXR5IG9mIHJlYXNvbnMuIEhvd2V2ZXIsIG5lZ290aWF0aW5nIHRoZSBr ZXkgZXhjaGFuZ2UgYWxnb3JpdGhtIHVzaW5nICJlbGxpcHRpY19jdXJ2ZXMiIChvciBldmVuICJz dXBwb3J0ZWRfZ3JvdXBzIikgc2VlbXMgYXdrd2FyZC4gRS5nLiBpZiBzb21lb25lIHdhbnRzIHRv IGFkZCBhIGtleSBleGNoYW5nZSB0aGF0IGlzIGRpZmZlcmVudCB0aGFuIERIRS9FQ0RIRSwgdGhl biB1c2luZyAic3VwcG9ydGVkX2dyb3VwcyIgdG8gbmVnb3RpYXRlIGl0IHdpbGwgbWFrZSBsaXR0 bGUgc2Vuc2UuIFRoaXMgaXMgYWxyZWFkeSBwcm9ibGVtYXRpYyB0b2RheSBmb3IgUFNLLg0KDQpD aGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExT IFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIEdhcnJldHQN ClNlbnQ6IFN1bmRheSwgQXByaWwgMTIsIDIwMTUgMTE6MDIgUE0NClRvOiB0bHNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbVExTXSBOZWdvdGlhdGUgb25seSBzeW1tZXRyaWMgY2lwaGVyIHZpYSBj aXBoZXIgc3VpdGVzICh3YXM6IEFsYSBDYXJ0ZSBDaXBoZXIgc3VpdGVzIC0gd2FzOiBEU0Egc2hv dWxkIGRpZSkNCg0KT24gVHVlc2RheSwgQXByaWwgMDcsIDIwMTUgMDI6MzE6MzMgYW0gSWxhcmkg TGl1c3ZhYXJhIHdyb3RlOg0KPiBBbHNvLCB0aGUgY2VydGlmaWNhdGUgZm9ybWF0IG5lZ290aWF0 aW9uIGlzIHN1cHBvc2VkbHkgYm90aCB2aWENCj4gY2lwaGVyc3VpdGVzIGFuZCBhbiBleHRlbnNp b24uIEFuZCB3aGVuIHlvdSBoYXZlIHRoZSBzYW1lIHRoaW5nIGluDQo+IHR3byBwbGFjZXMsIHRo ZSByZWxldmFudCBxdWVzdGlvbiBpcyAid2hpY2ggaXMgZGVmaW5pdGl2ZT8iLg0KDQpIZXJlJ3Mg YSBkaWZmZXJlbnQgaWRlYSBmb3IgZml4aW5nIHRoZSBjb21iaW5hdG9yaWFsIG1lc3M6IEZvciBU TFMgMS4zKywgb25seSB1c2UgY2lwaGVyIHN1aXRlcyB0byBuZWdvdGlhdGUgc3ltbWV0cmljIGNp cGhlcnMuIFJlbHkgZW50aXJlbHkgb24gdGhlIGV4dGVuc2lvbnMgZm9yIHRoZSBoYW5kc2hha2Uu DQoNCkZvciB0aGUgaGFuZHNoYWtlLCBtYW5kYXRlIHVzYWdlIG9mIHRoZSAic3VwcG9ydGVkX2dy b3VwcyIgZXh0ZW5zaW9uIChuw6llICJlbGxpcHRpY19jdXJ2ZXMiKSBhbmQgdGhlIOKAnHNpZ25h dHVyZV9hbGdvcml0aG1z4oCdIGV4dGVuc2lvbiBmb3IgYWxsIGNvbm5lY3Rpb24gYXR0ZW1wdHMu IChyZWplY3QgY29ubmVjdGlvbiBpZiBub3QgcHJlc2VudCBhbmQgdmFsaWQpIElmIFRMUyAxLjMr IGlzIG5lZ290aWF0ZWQsIHRoZW4gdGhlIERIRS9FQ0RIRSB3aWxsIGJlIHNlbGVjdGVkIGJhc2Vk IG9uIHRoZSBoaWdoZXN0IHByZWZlcnJlZCBzdXBwb3J0ZWQgTmFtZWRHcm91cCBhbmQgUlNBL0VD RFNBL2V0YyB3aWxsIGJlIHNlbGVjdGVkIGJhc2VkIG9uIHRoZSBoaWdoZXN0IHByZWZlcnJlZCBT aWduYXR1cmVBbmRIYXNoQWxnb3JpdGhtLiBBc3NpZ24gcG9pbnRzIHRvIE5hbWVkR3JvdXAgYW5k IFNpZ25hdHVyZUFsZ29yaXRobSB0byBuZWdvdGlhdGUgUFNLIHVzYWdlIHZpYSB0aGUgZXh0ZW5z aW9ucy4gKGUuZy4gTmFtZWRHcm91cD0wIGZvciBwbGFpbiBQU0spIFRoZSBzZXJ2ZXIgd291bGQg dGhlbiBpZ25vcmUgZXZlcnl0aGluZyBpbiBwcm9wb3NlZCBjaXBoZXIgc3VpdGVzIG90aGVyIHRo YW4gdGhlIHN5bW1ldHJpYyBjaXBoZXIgc3VpdGUgY29tcG9uZW50cy4gKGUuZy4gYWxsIG9mIHRo ZSBmb2xsb3dpbmcgd291bGQgYmUgY29uc2lkZXJlZCBlcXVpdmFsZW50IGZvciBUTFMgMS4zKzog VExTX0RIRV9SU0FfV0lUSF9BRVNfMTI4X0dDTV9TSEEyNTYsIFRMU19FQ0RIRV9SU0FfV0lUSF9B RVNfMTI4X0dDTV9TSEEyNTYsIFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18xMjhfR0NNX1NIQTI1 NikgTmV3IGNpcGhlcnMgdGhhdCBhcmUgc3VwcG9ydGVkIHZpYSBUTFMgMS4zKyB3b3VsZCBvbmx5 IG5lZWQgdG8gZGVmaW5lIHNvbWV0aGluZyBpbiB0aGUgZm9ybSBvZiBUTFNfRVhUX1dJVEhfeF95 X3ogd2l0aCB2YXJpYXRpb25zIG9mIHN5bW1ldHJpYyBwYXJhbWV0ZXJzIChmb3IgT0NCLCB0aGVy ZSdkIGJlIG9ubHkgMiBzdWl0ZXMpLiBOZXcgY2lwaGVycyB0aGF0IHdpc2ggdG8gc3VwcG9ydCBU TFMgMS4yIGJ1dCB3aXRob3V0IGFkZGluZyB0aGUgbGl0YW55IG9mIGNvbWJpbmF0aW9ucyBvZiBz dWl0ZXMgY291bGQgc2ltcGx5IGFsbG93IG5lZ290aWF0aW9uIG9mIGFueSBvZiB0aGUgbmV3IHN1 aXRlcyB0byBhc3N1bWUgREhFX1JTQSB1bmxlc3MgdGhlIG5lY2Vzc2FyeSBleHRlbnNpb25zIGFy ZSB1c2VkIHRvIHNheSBvdGhlcndpc2UuICh0aG91Z2gsIGp1c3QgcmVxdWlyaW5nIHRoZSBleHRl bnNpb25zIHRvIHVzZSB0aGVtIGlzIG5vdCB1bnJlYXNvbmFibGUpDQoNClRoaXMgcm91dGUgZG9l cyBub3QgY2hhbmdlIGNpcGhlciBzdWl0ZXMgaW4gYSBtYWpvciB3YXkgYW5kIHVzZXMgYWxyZWFk eSBpbi1kcmFmdCBleHRlbnNpb25zIHRvIGRvIHRoZSBuZWdvdGlhdGlvbiwgd2l0aG91dCBhbnkg bW9kaWZpY2F0aW9ucyBiZXlvbmQgbWFuZGF0aW5nIHRoZWlyIHVzZSBhbmQgYWJzb2x1dGUgcHJp b3JpdHkgb3ZlciB0aGUgcGFyYW1ldGVycyBzcGVjaWZpZWQgaW4gdGhlIGNpcGhlciBzdWl0ZS4g Tm90IG9ubHkgZG9lcyB0aGlzIG1ha2UgdGhlIGNpcGhlciBzdWl0ZSBzZWxlY3Rpb24gc2ltcGxl ciBhbmQgYXZvaWRzIGVuZHBvaW50cyBub3QgbmVnb3RpYXRpbmcgYSB2aWFibGUgY29tYmluYXRp b24gdGhhdCdzIGp1c3Qgbm90IG9mZmVyZWQgaW4gdGhlIGxpc3QsIGJ1dCBpdCByZW1vdmVzIGFu eSBleGlzdGluZyBhbWJpZ3VpdHkgb3ZlciB3aGljaCBzdXBwb3J0IGxpc3RpbmcgaXMgZGVmaW5p dGl2ZS4gQ2lwaGVyIHN1aXRlcyBuZWdvdGlhdGUgc3ltbWV0cmljIGFuZCB0aGVzZSB0d28gZXh0 ZW5zaW9uIG5lZ290aWF0ZSBhc3ltbWV0cmljLg0KDQoNCkRhdmUNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo= From nobody Mon Apr 13 10:35: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 0D7C21ACEAB for ; Mon, 13 Apr 2015 10:35:52 -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 22CCmh2Oktov for ; Mon, 13 Apr 2015 10:35:50 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 319511A0389 for ; Mon, 13 Apr 2015 10:35:49 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t3DHZhok009198; Mon, 13 Apr 2015 13:35:43 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Daniel Kahn Gillmor Thread-Topic: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die) Thread-Index: AQHQda9cnU9ktJlHUU27K74Bjjn7bp1KyriAgACSwQCAAA3ngIAACfEAgAABowD//74rAA== Date: Mon, 13 Apr 2015 17:35:42 +0000 Message-ID: References: <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> <201504131325.20590.davemgarrett@gmail.com> <871tjoue8v.fsf@alice.fifthhorseman.net> In-Reply-To: <871tjoue8v.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3511776934_272022" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-13_04:2015-04-10,2015-04-13,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-1504130148 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 17:35:52 -0000 --B_3511776934_272022 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 4/13/15, 13:31 , "Daniel Kahn Gillmor" wrote: >On Mon 2015-04-13 13:25:20 -0400, Dave Garrett wrote: >>> So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer >>> were to try to negotiate: >>>=20 >>> key agreement: PSK >>> authentication: RSA-PSS >>>=20 >>> Do we just say "don't do that"? >> >> SGTM > >=E2=80=A6=E2=80=A6... >Once the full cartesian explosion is available by multidimensional >enumeration, we have to mark out which corners of the space are actually >bad ideas, and we have to make sure our implementations don't stumble >into those corners by accident. > >This isn't impossible to do, but it seems ripe for subtle implementation >bugs. Cryptographically sound algorithms and protocols should be immune to this concern. And we should accept only cryptographically sound algorithms & protocols. :-) --B_3511776934_272022 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUQwYJKoZIhvcNAQcCoIIUNDCCFDACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EiYwggTqMIID0qADAgECAgoocmWKAAAAAC0IMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwMTIzMTc1MTM1WhcNMTYwMTIzMTc1MTM1WjBhMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOklcSXpjJctM4swQtIpkHVdKUdAV1ePMF26hYjs6vPGSHhi Ud2yNpphHz58wIYuQp7MdbnuC3tA9/u3LmDjgKoUEE+FMEwV1bRnI8T31OULqnM31EK4G6kQ 3PXL8AvgFKGlW4P9KMCi1rjzR510I4t8X9qDch1DBQRt6rrKyKygUikmdZ2Xlxohwbyp1Iex eaIzrkutRslHt4Ivw9uIjuXkuJa2W86zHDEOje70DScj8Y1tKG81qJBKfCpUyh+gLm46LmWf SUygeY29P/J0v+EO/gXBUYEPOAsVxBoaZkjsFWQbJa5N4PUA3yO/PdS7H6QLrc3vuJUCmRdT F+TeXL0CAwEAAaOCAbIwggGuMB0GA1UdDgQWBBSYMw3cMZSrQDIh1QeQ97yR7UrpMzAOBgNV HQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcB AQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAn BggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQw MC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pzAgFkAgEFMCIGA1Ud JQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgED AQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBz AGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAkzFCiBBS9mIYokb/iNnS0M5W rQD9s1WXqv+5bJfLBehbmgBMGOqofV0OulGTJdX38bi9ChCOmyXnmSKzeuVbFZ/ZRxjgAGIu pxKD+tzJAzBuCsj2TIkpEyJ4VfG9/73ZAIbPvZVmHg8+DPCwyQCfF1jbybP5D9e4VfOQ3Fth eKR+SMCiJymq03qrgkL6TJ8DFrVuvw+u589CkYhGMoCW1WhzH/0UyDLQ3cJavMdH2rNtUKFK HPHNnq7wNzOtSIWZ7wo4EWAu3LUeHVyHTa+NW02JKd8y+wyUIpgmflPDzP2DkGvxbShKjjh3 /hmHF4iyZSyP6ynGJt/GyCn1z/KOJzCCBLwwggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAw VDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNV BAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0xMzEyMTcwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0 b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gcKS9SlQRfqMW8F3yZ AjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUifSemk671G+mNZ KLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NPJs/oW6Yp HF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICaHIHO +VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mN dUwN/c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8B Af8EBAMCAYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUv b2NzcDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xM UkNBMIGSBgNVHSAEgYowgYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZI hvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQsw DQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcN AQEFBQADggEBACx/0cGfvapTtROCTFquMBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQ uM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF/M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5 YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsTkfrbLLErVY8+BwGKkZWe7XFIdtOId7sO p9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCipAwj3wzMNh4s6SOXMpGzvuv9oyw8 ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+DbavUxXxFHU+S2Myw06w98wggOD MIICa6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJv b3QgQ0EwHhcNMDgwOTIzMTIwMDAwWhcNMjkxMjMxMjM1OTU5WjBUMQswCQYDVQQGEwJVUzEf MB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQD Ew1NSVRMTCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxU4pF1iy JrL5rYq/XBAKg93kCTATG7Bw0NGFpEJ1A3Xsr6UIIq9/1VJBOgCwDqrVsAK1lRwy/lkrHzPk obiMr1wzjQ28SR/9sg5kAcmrMqBYbc302qtwCGKZxdNdhAh2nUOCO10AMpUsCNdpikPY9ukT 8lsA+eorM4Q1rc/L0J6AHRptOU7IuDBdZj+tdNb7gv+GKknr6wj9m2sVGawoaG7AAqhsWvQU M/q4h/H5FpYlwnVAEh2AzhqiG9bwl6uJJIzJ/8uUWldNkVwz1I5fR/vCaxiLXIW4oUydBuRK TG+ekEoxHGuD73yx5JtsSciS8HQL2oEM8tv+VAC+albqgwIDAQABo2AwXjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAfBgNVHSMEGDAWgBRnqnrP 9AqmuXK1iqDSnfIQw0PtKTALBgNVHQ8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAD4bbQVg 0Hh42EpYX4/JPkNS3OUAEWR/YgzZUY1QGi9rQZ4pfcjU1/TaoNT8Y7Yf0RO+e9NiG9+BDhQH /kQiZOQo9rv9NUb8xDtKCYCad7zEQtVsYsWuvK2XLw/Ji1m2eBvoOB4RS/5LAWfNws7W+DWt 2ayzeTCyrLSrx7ZVgBjzNOm0TPIkbfppdwgxuo7FZL8ts+M2492Al87d3VasevUS1pprRBEu pChmPTt1hjtajkQOpT4BQAzP1lVEYrWzlv+O/lbP9iujKpYWcfYqQ3FGf37YCvuDeues4xm+ nqmyraNsNeI8Gh3XDIwqfzHnLhy4Y80VyqN/Jj8df3SK9AAwggTtMIID1aADAgECAgoocHoy AAAAAC0HMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTUwMTIzMTc0OTI5WhcNMTYwMTIzMTc0OTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMW TUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVt ZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMX5 Fyz2E07mG+UTRh6W2p5cZRbW7dFUwbj/ZqDonYWByw4nE5nL+b7sV5h8Kjddis2rHr/chmYN JiWfcmfHM+KicNxsrZMn3EA6haWtTKQCGBSX48I7xqENXlhzS2YzN/kxcGuy5vSdTIl4OTE5 RjYh3nwPVRXPNeH0q+Nz5kJwFEWhWICCfszOee68rxjmbsuivWgtZLE01TKn3yALgSl0cucD zI/VaqY2vTH5iyyMmASIh9kWrHwa+/Y6q0doUYeHtjr5Y5YhlQsxoBz0kkSrxy2ez2YYhGV1 /YkwVw2xqFAkOGBSymY/pzVbP06tTGyDCcZDl94ir1z/hhlgRn8CAwEAAaOCAbUwggGxMB0G A1UdDgQWBBRHSF5uTiLrTrdiekQRVfJBTJ9IUzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgw FoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5s bC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0 dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29j c3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdm hq2HFYPq8EWFtqEfHYXr0HCD6+0gAgFkAgEEMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwME BgorBgEEAYI3CgMEMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJp QGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzAN BgkqhkiG9w0BAQsFAAOCAQEAOKbnONNv+Hd5r/roM0zrBKaLVOL0XZ/b8Ct7Zrtr0T8g9d+V 6Hf2VUbu5Nqd4QkxIfMOW2QHmToNgy/+3bye1CbaMsj1p0zBxwOUpJHa4gOyIDuOh2JPFuov 9pGL5YLjJtZaFe7NJuQx6xrK3lAAqm4osCvud7B9lpbHzM+dZTWdZkFslHtwsqBRNoSJC782 UJYgUkgL3JGHN74pHjW8hr7ueJCdQA2OhgIK7fZnzGDGEriRCvm15RVQ0OgKPTbHvzUYV/AK SfGmxYSb3k5YzWJpcoIYnxyKKi6UTOSxlSsgd0iYhJpBVX5d2Ztx3c4frLx82XWZl1efyzE0 lz7+DTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMwIKKHJligAA AAAtCDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFPhmVoJ4EVaTwuwTtDrZaB5vodz3 MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxMzE3MzUz NFowDQYJKoZIhvcNAQEBBQAEggEAWSOVU/w3PkiRwv7MhUcP2r85h3k6mmCaCbZb/zyAEbQN Iic1HLVzkDSFHgYDjUE0PH2ix+y6IkqPA3jrbIEqySwVyldVLVs2BM/GpJrmWDNmEUSl0uwn C8BIHwX+d8Tk+wWYEEaKEv3YGAb1WNTMKDo0Bd/WS0AdFbG2XiIBfiLo04ECiYZumNq+xfXA xEiU9TSyJN33N0aAb9F3BjlfH8gzUn6kWYthBxw8mq7Gi5mWOHROTj2slhMlmy3L6DtEJ2ru Yates2GQ1kUhXbmNpZh6OR2wy5bS+GRTA+OdwrXQ53YWllC8uzN7jDUg9pnKL5Hmo7axcUEd TG2MIaU7Hw== --B_3511776934_272022-- From nobody Mon Apr 13 10:41: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 B945F1AD0A3 for ; Mon, 13 Apr 2015 10:41:39 -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 tboPQwlYhLVH for ; Mon, 13 Apr 2015 10:41:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C9B1AD0A1 for ; Mon, 13 Apr 2015 10:41:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 78ED0283031; Mon, 13 Apr 2015 17:41:37 +0000 (UTC) Date: Mon, 13 Apr 2015 17:41:37 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150413174137.GT17637@mournblade.imrryr.org> References: <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> <201504131325.20590.davemgarrett@gmail.com> <871tjoue8v.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871tjoue8v.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die) 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, 13 Apr 2015 17:41:39 -0000 On Mon, Apr 13, 2015 at 01:31:12PM -0400, Daniel Kahn Gillmor wrote: > Once the full cartesian explosion is available by multidimensional > enumeration, we have to mark out which corners of the space are actually > bad ideas, and we have to make sure our implementations don't stumble > into those corners by accident. Is this actually a problem? Is it worse than the current multitude of suites (with some gaps yet to be filled)? -- Viktor. From nobody Mon Apr 13 10:45: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 6B4871AD0C5 for ; Mon, 13 Apr 2015 10:45:55 -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 I8G3HUJKJjQf for ; Mon, 13 Apr 2015 10:45:53 -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 B2C421AD0BC for ; Mon, 13 Apr 2015 10:45:53 -0700 (PDT) Received: by qkhg7 with SMTP id g7so191464287qkh.2 for ; Mon, 13 Apr 2015 10:45: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=7J9lL0c7kU+lag4IVLw5R17121KFHmS6+KgeRJaY4kk=; b=hZxrF3B0t7mgqSW3hvyi7FsZh0fP6UFty/lZsvT0MIyDp1G7YzIEnqRFRQ2eCtvQMA KC0smm1tfUUdniEFjVr8yKDPHdgOzsr9TbauJg8ZSPP7lAhhyuvmghL4pHcsxwAQJWT3 hNCSh8yYw7e1tNY29HeL0brkUpcN1B5hXstEMcAAspBVhu7JtAo7MDAVHaNHzLFblOm9 FcvTTSA1vKopMH0jsMN11pdAz74UQPOvH7id7P6RvfYaZ7wkI0UVGbCT/Fn9el/Fl/Fp atoCsSUo3BwoBVzycs1rtd4gjVxXY16lBr+tyZpGDxLApBYLAVv8eBUHMaeiZKYIdmt9 FoIw== X-Received: by 10.140.234.80 with SMTP id f77mr599842qhc.13.1428947152923; Mon, 13 Apr 2015 10:45:52 -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 g80sm6266932qkh.18.2015.04.13.10.45.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 10:45:52 -0700 (PDT) From: Dave Garrett To: Daniel Kahn Gillmor Date: Mon, 13 Apr 2015 13:45:51 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504131325.20590.davemgarrett@gmail.com> <871tjoue8v.fsf@alice.fifthhorseman.net> In-Reply-To: <871tjoue8v.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504131345.51699.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 17:45:55 -0000 On Monday, April 13, 2015 01:31:12 pm Daniel Kahn Gillmor wrote: > On Mon 2015-04-13 13:25:20 -0400, Dave Garrett wrote: > >> So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer > >> were to try to negotiate: > >> > >> key agreement: PSK > >> authentication: RSA-PSS > >> > >> Do we just say "don't do that"? > > > > SGTM > > This, i think, is one of the serious concerns about splitting the > ciphersuite into orthogonal vectors. > > Once the full cartesian explosion is available by multidimensional > enumeration, we have to mark out which corners of the space are actually > bad ideas, and we have to make sure our implementations don't stumble > into those corners by accident. Non-FS PSK adds some of those corners, which is one of the reasons why I think it should be prohibited. > This isn't impossible to do, but it seems ripe for subtle implementation > bugs. The current situation is already ripe for subtle implementation bugs. These extensions already exist and can conflict with the cipher suite if not configured/used properly. I think this route reduces the risk here, and prohibiting/restricting the more problematic methods/algorithms would help more. Dave From nobody Mon Apr 13 11:02: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 5CB041AD241; Mon, 13 Apr 2015 11:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rPafidz4F_X; Mon, 13 Apr 2015 11:02:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBC21AD2B2; Mon, 13 Apr 2015 11:02:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150413180246.22757.70956.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 11:02:46 -0700 Archived-At: Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'Deprecating Secure Sockets Layer Version 3.0' to Best Current Practice (draft-ietf-tls-sslv3-diediedie-03.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: Mon, 13 Apr 2015 18:02:49 -0000 The IESG has approved the following document: - 'Deprecating Secure Sockets Layer Version 3.0' (draft-ietf-tls-sslv3-diediedie-03.txt) as Best Current Practice This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ Technical Summary Secure Sockets Layer version 3.0 (SSLv3) is no longer secure. This document requires that SSLv3 not be used. The replacement versions, in particular Transport Layer Security (TLS) 1.2, are considerably more secure and capable protocols. This document updates the backward compatibility sections of the TLS RFCs to prohibit fallback to SSLv3. Working Group Summary This document has been actively reviewed by the TLS working group. There is strong community consensus behind the document. Document Quality Are there existing implementations of the protocol? Yes, and that's the problem;-) However, many deployments and implementations have already started disabling SSLv3. Personnel Joseph Salowey is the document shepherd. Stephen Farrell is the responsible AD for this document. From nobody Mon Apr 13 11:12: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 2DE061AD190 for ; Mon, 13 Apr 2015 11:12:05 -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 BhmzGFSVtILJ for ; Mon, 13 Apr 2015 11:11:54 -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 1C3B21B29AD for ; Mon, 13 Apr 2015 11:11:50 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 389311887CC; Mon, 13 Apr 2015 21:11:45 +0300 (EEST) Date: Mon, 13 Apr 2015 21:11:44 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150413181144.GA720@LK-Perkele-VII> References: <20150412165542.GA19481@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: Mon, 13 Apr 2015 18:12:05 -0000 On Mon, Apr 13, 2015 at 10:02:43AM -0700, Martin Thomson wrote: > On 12 April 2015 at 09:55, Ilari Liusvaara wrote: > > > 2) What are the semantics of successfully received 0-RTT transfer > (especially considering the client-side autoretransmit on > failure)? > > This is protocol-defined. > > But I imagine that this depends on the model we employ. Replayable > data could just be consider the start of a stream. On the other hand, > unreliable data doesn't work very well for a stream mode. Conversely, > replayable data makes no sense in a datagram mode, but all data is > unreliable there. I thought the recommended client-side interface called for auto- retransmit, which would mean that if application handled 0RTT as anything else than a prefix, it would now create two cases serverside. > > 3) How does 0-RTT interact with ALPN (especially considering > potential for multiple protocol candidates)? > > I imagine that the ALPN from the previous session applies. If the > client wants to change anything, it probably shouldn't use 0-RTT. Note > that this includes cipher suites and maybe other extensions too. You mean 0-RTT "KeyIDs" include the application? Note that ALPN is one of the very few extensions that is not invariant across resumption (might even be the only one that isn't resumption mechanism itself). Or guidance that one is to send at most one ALPN identifier if trying to send 0-RTT data? Also, there's the case 0-RTT is attempted without resumption. Or is 0-RTT intended only for session resumption attempts (which would cut quite a bit of complexity)? > > 4) Can handshake with attempted 0-RTT be securely downgraded to > v1.2 (obviously causes the 0-RTT to fail)? > > Not safely. The decision we made at the last meeting (or interim, I > can't remember) was to require that the server make a commitment to > support - or at least to ignore - TLS 1.3 handshake for at least the > validity period of the 0-RTT information. The 0-RTT messages might be > ignored in DTLS, but they are unlikely to be handled cleanly by a TLS > 1.2 implementation. I would expect a fatal error. There's the case where there are multiple servers behind a load- balancer (working at TCP or even IP level). Inability to gracefully fall back would imply that all servers serving something need to be upgraded at once. > > 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? > > How is that materially different to other suites? > > > 6) The same as above, but when attempting to resume a session. > with a client certificate (since cc is property of session)? > > As before, if the information is replayable, then it needs to be > understood by both parties that it is replayable. And both need to > understand how that is not a concern. The client certificate doesn't > present a special risk here. At least not as far as I've been able to > determine. Yeah, shouldn't be exploitable unless the client sends really dumb things in 0-RTT data. > > 8) If resumption attempt has 0-RTT data, what keying material is > used for the 0-RTT? > > That combination might not be valid. If it is, I'm guessing that the > first client flight is encrypted and authenticated as a "normal" 0-RTT > handshake. One can't attempt resumption with 0-RTT data? Also, if session is resumed, I think the server won't appreciate having to decode "normal" 0-RTT data transmission, since that is relatively expensive operation (much more expensive than symmetric decryption of reasonable amounts of data). There are three possible cases with respect to resumption: 1) Client does not try to resume (full handshake) 2) Client tries to resume, resume failed (fallback to full handshake). 3) Client tries to resume, resume successful (abbrevated hanshake) > > 9) Can server roll over its 0-RTT keys without waiting for the > previous ones to expire? > > Yes, there will need to be a key identifier in the clear that allows a > server to identify which key to use to decrypt the client's flight. OK (just that one knows that key exchange needs to deal with that case). > > 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? > > Well, the attacker presumably doesn't have the private keys used by > either client or server. They might be able to cause a replay, but if > we have decent crypto, they aren't able to decrypt anything, nor can > they continue the session. If one does 0-RTT with resume, then sure. But 0-RTT without resumption, it depends on specifics of the key exchange if that kind of attack is possible or not. -Ilari From nobody Mon Apr 13 11:24: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 E53271B2A43 for ; Mon, 13 Apr 2015 11:24:14 -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_82=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 IBhWa5r4meH0 for ; Mon, 13 Apr 2015 11:24:14 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003: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 D42BC1B29AD for ; Mon, 13 Apr 2015 11:24:13 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so43061204obb.3 for ; Mon, 13 Apr 2015 11:24: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=f9H7M+BBB0Z+1vwl8O1H8llOJjRoAwmB0MFKaSl3e9Y=; b=OofpfUhhFjZuDUn6+NMitBIBuW9pKS24UD+nG26IfqamGDK8U255uK16GIhMhpYavr WgRLmSbHGtpnb820cKYgLWcfwg5Dnm39inFJebfZG9ZTW45hd2dg66lgVrpmgY++aCux eJrqtB3Q4zh20IQZzRo7J4//x4QFFfEc342weFvrfx1tifh6soZVm3exCis9NpQ/RcVK tOYSZJAtbt4fe6qB+sPWCVEUO1bxNu1nl2v9YxRGJAYICv5Ygq6K8ME3zzor1RIbpxVl fK4gAbhTRPvaE/8l0JuGRzzdBec2RMnnsLqgxas3aDya/QDqyBwLceNX+V9hl1bdKvX0 Dv2A== MIME-Version: 1.0 X-Received: by 10.182.68.103 with SMTP id v7mr12423285obt.82.1428949453365; Mon, 13 Apr 2015 11:24:13 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Mon, 13 Apr 2015 11:24:13 -0700 (PDT) In-Reply-To: <20150413181144.GA720@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> <20150413181144.GA720@LK-Perkele-VII> Date: Mon, 13 Apr 2015 11:24:13 -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: Mon, 13 Apr 2015 18:24:15 -0000 On 13 April 2015 at 11:11, Ilari Liusvaara wrote: > I thought the recommended client-side interface called for auto- > retransmit, which would mean that if application handled 0RTT as anything > else than a prefix, it would now create two cases serverside. That retransmit doesn't make sense in DTLS. I believe that the current situation is "replayable in TLS", "unreliable in DTLS". > You mean 0-RTT "KeyIDs" include the application? Note that ALPN is one > of the very few extensions that is not invariant across resumption > (might even be the only one that isn't resumption mechanism itself). They probably need to include the application and more. > Or guidance that one is to send at most one ALPN identifier if trying > to send 0-RTT data? I wouldn't do that: if the 0-RTT state is rejected, then protocol negotiation is still possible. I would instead recommend that both peers remember(or encrypt) certain state to the key identifier and use that state. > Also, there's the case 0-RTT is attempted without resumption. Or is > 0-RTT intended only for session resumption attempts (which would cut > quite a bit of complexity)? I don't know how this is intended to work, but I always think of 0-RTT as resumption. Nothing much else makes sense. > There's the case where there are multiple servers behind a load- > balancer (working at TCP or even IP level). > > Inability to gracefully fall back would imply that all servers serving > something need to be upgraded at once. Yes, all servers in that farm would need to be upgraded at least to the level that they would be able to ignore the TLS 1.3 garbage. Before allowing any node to enable 0-RTT. >> > 8) If resumption attempt has 0-RTT data, what keying material is >> used for the 0-RTT? >> >> That combination might not be valid. If it is, I'm guessing that the >> first client flight is encrypted and authenticated as a "normal" 0-RTT >> handshake. > > One can't attempt resumption with 0-RTT data? I don't actually know the answer to this. > Also, if session is resumed, I think the server won't appreciate having > to decode "normal" 0-RTT data transmission, since that is relatively > expensive operation (much more expensive than symmetric decryption of > reasonable amounts of data). The server decided to allow that possibility; so it has to deal with the fallout from it. From nobody Mon Apr 13 11:30: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 26F171B2A6E for ; Mon, 13 Apr 2015 11:30: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 xw_zxCKzLHlf for ; Mon, 13 Apr 2015 11:30:02 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 85B821B2A6C for ; Mon, 13 Apr 2015 11:30:02 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 75DCBF984; Mon, 13 Apr 2015 14:30:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 57EA820088; Mon, 13 Apr 2015 13:29:49 -0500 (CDT) From: Daniel Kahn Gillmor To: "Blumenthal\, Uri - 0553 - MITLL" In-Reply-To: References: <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> <201504131325.20590.davemgarrett@gmail.com> <871tjoue8v.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 13 Apr 2015 14:29:49 -0400 Message-ID: <87vbgzubj6.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 18:30:04 -0000 On Mon 2015-04-13 13:35:42 -0400, Blumenthal, Uri - 0553 - MITLL wrote: > On 4/13/15, 13:31 , "Daniel Kahn Gillmor" wrote: > >>On Mon 2015-04-13 13:25:20 -0400, Dave Garrett wrote: >>>> So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer >>>> were to try to negotiate: >>>> >>>> key agreement: PSK >>>> authentication: RSA-PSS >>>> >>>> Do we just say "don't do that"? >>> >>> SGTM >> >>……... >>Once the full cartesian explosion is available by multidimensional >>enumeration, we have to mark out which corners of the space are actually >>bad ideas, and we have to make sure our implementations don't stumble >>into those corners by accident. >> >>This isn't impossible to do, but it seems ripe for subtle implementation >>bugs. > > Cryptographically sound algorithms and protocols should be immune to this > concern. And we should accept only cryptographically sound algorithms & > protocols. :-) What do you think an implementation should do when a peer tries to negotiate the combination above? Require an RSA-PSS signature from the server over some material derived in part from the PSK key agreement mechanism? --dkg From nobody Mon Apr 13 11:55: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 855551B2FC7 for ; Mon, 13 Apr 2015 11:55: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 tTDlMA8nvi0m for ; Mon, 13 Apr 2015 11:55:15 -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 42FA71B2FBB for ; Mon, 13 Apr 2015 11:55:14 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id A9DF11A25E0; Mon, 13 Apr 2015 21:55:05 +0300 (EEST) Date: Mon, 13 Apr 2015 21:55:05 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20150413185505.GA1016@LK-Perkele-VII> References: <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> <201504131325.20590.davemgarrett@gmail.com> <871tjoue8v.fsf@alice.fifthhorseman.net> <87vbgzubj6.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87vbgzubj6.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 18:55:17 -0000 On Mon, Apr 13, 2015 at 02:29:49PM -0400, Daniel Kahn Gillmor wrote: > On Mon 2015-04-13 13:35:42 -0400, Blumenthal, Uri - 0553 - MITLL wrote: > > On 4/13/15, 13:31 , "Daniel Kahn Gillmor" wrote: > > > >>On Mon 2015-04-13 13:25:20 -0400, Dave Garrett wrote: > >>>> So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer > >>>> were to try to negotiate: > >>>> > >>>> key agreement: PSK > >>>> authentication: RSA-PSS > >>>> > >>>> Do we just say "don't do that"? > >>> > >>> SGTM > >> > >>……... > >>Once the full cartesian explosion is available by multidimensional > >>enumeration, we have to mark out which corners of the space are actually > >>bad ideas, and we have to make sure our implementations don't stumble > >>into those corners by accident. > >> > >>This isn't impossible to do, but it seems ripe for subtle implementation > >>bugs. > > > > Cryptographically sound algorithms and protocols should be immune to this > > concern. And we should accept only cryptographically sound algorithms & > > protocols. :-) > > What do you think an implementation should do when a peer tries to > negotiate the combination above? Require an RSA-PSS signature from the > server over some material derived in part from the PSK key agreement > mechanism? To me it seems like that combo is quite insecure, unless one handles it as a special case (in which case it is just equivalent to PSK in security, just wastes time with a certificate). As list, the key exchange methods TLS v1.2 actually supports (after merging some non-significant distinctions) are: - RSA [going away] - RSA_EXPORT [you have deimplemented this already, right?] - DH_CERT [going away] - DHE_CERT [supported] - DHE_ANON [???] - KRB5 [going away] - PSK [???] - DHE_PSK [???] - RSA_PSK [going away] - SRP [???] - SRP_CERT [???] -Ilari From nobody Mon Apr 13 11:57: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 9E7C71ACDBC for ; Mon, 13 Apr 2015 11:57:09 -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 xod8J3TzFUI4 for ; Mon, 13 Apr 2015 11:57:06 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873161B2A2B for ; Mon, 13 Apr 2015 11:57:06 -0700 (PDT) Received: by laat2 with SMTP id t2so65116909laa.1 for ; Mon, 13 Apr 2015 11:57:04 -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=5DDQIJSwFfiLRqoElaU4WSdwuj8n9hY8Gm5LJ6SqJYE=; b=BmNw2eVP6jqSmsMhj+EtfLhybHPmBBJF++tKU5R11ErWYMmvmRJQ5d1tXJbDsuHcxR QoPs8ExFQWN+AXff8P1GEhKTMRGz9iwVdvvS1g56K1F8Z4lWB30x+YVKbjwcMr8+lee1 WB9z9V3d88P/5tcFWlHyKNxEK9BpzVgAgS4+skqamA5wYBXuO90ZFZcV4hwY/vCDDrSq 2/jMNf4vIOGykX3gDv741+YLl8r3JrvPVMVvnlgp4NTp5po3oGa8So0GxkFZ03uk4UWX XcAGh1WKbDX3hGMVKTsP5XSMReYelWZXGDxvSm1Fxoq32M3LBifC/rVvhgCMwPbCxyXZ ZbqA== MIME-Version: 1.0 X-Received: by 10.112.118.73 with SMTP id kk9mr14600711lbb.3.1428951424916; Mon, 13 Apr 2015 11:57:04 -0700 (PDT) Received: by 10.25.38.207 with HTTP; Mon, 13 Apr 2015 11:57:04 -0700 (PDT) In-Reply-To: <20150413185505.GA1016@LK-Perkele-VII> References: <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> <201504131325.20590.davemgarrett@gmail.com> <871tjoue8v.fsf@alice.fifthhorseman.net> <87vbgzubj6.fsf@alice.fifthhorseman.net> <20150413185505.GA1016@LK-Perkele-VII> Date: Mon, 13 Apr 2015 21:57:04 +0300 Message-ID: From: Dmitry Belyavsky To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7bfcf70e15624e05139faef1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 18:57:09 -0000 --047d7bfcf70e15624e05139faef1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Ilari, You missed GOST key exchange. Thank you! On Mon, Apr 13, 2015 at 9:55 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Mon, Apr 13, 2015 at 02:29:49PM -0400, Daniel Kahn Gillmor wrote: > > On Mon 2015-04-13 13:35:42 -0400, Blumenthal, Uri - 0553 - MITLL wrote: > > > On 4/13/15, 13:31 , "Daniel Kahn Gillmor" > wrote: > > > > > >>On Mon 2015-04-13 13:25:20 -0400, Dave Garrett wrote: > > >>>> So if we have to have non-(EC)DHE PSK, what would it mean if a TLS > peer > > >>>> were to try to negotiate: > > >>>> > > >>>> key agreement: PSK > > >>>> authentication: RSA-PSS > > >>>> > > >>>> Do we just say "don't do that"? > > >>> > > >>> SGTM > > >> > > >>=E2=80=A6=E2=80=A6... > > >>Once the full cartesian explosion is available by multidimensional > > >>enumeration, we have to mark out which corners of the space are > actually > > >>bad ideas, and we have to make sure our implementations don't stumble > > >>into those corners by accident. > > >> > > >>This isn't impossible to do, but it seems ripe for subtle > implementation > > >>bugs. > > > > > > Cryptographically sound algorithms and protocols should be immune to > this > > > concern. And we should accept only cryptographically sound algorithms= & > > > protocols. :-) > > > > What do you think an implementation should do when a peer tries to > > negotiate the combination above? Require an RSA-PSS signature from the > > server over some material derived in part from the PSK key agreement > > mechanism? > > To me it seems like that combo is quite insecure, unless one handles it a= s > a special case (in which case it is just equivalent to PSK in security, > just wastes time with a certificate). > > > As list, the key exchange methods TLS v1.2 actually supports (after mergi= ng > some non-significant distinctions) are: > - RSA [going away] > - RSA_EXPORT [you have deimplemented this already, right?] > - DH_CERT [going away] > - DHE_CERT [supported] > - DHE_ANON [???] > - KRB5 [going away] > - PSK [???] > - DHE_PSK [???] > - RSA_PSK [going away] > - SRP [???] > - SRP_CERT [???] > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 SY, Dmitry Belyavsky --047d7bfcf70e15624e05139faef1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ilari,

You missed GOST key exchan= ge.

Thank you!

On Mon, Apr 13, 2015 at 9:55 PM, Ilari Li= usvaara <ilari.liusvaara@elisanet.fi> wrote:
On Mon= , Apr 13, 2015 at 02:29:49PM -0400, Daniel Kahn Gillmor wrote:
> On Mon 2015-04-13 13:35:42 -0400, Blumenthal, Uri - 0553 - MITLL wrote= :
> > On 4/13/15, 13:31 , "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote:
> >
> >>On Mon 2015-04-13 13:25:20 -0400, Dave Garrett wrote:
> >>>> So if we have to have non-(EC)DHE PSK, what would it = mean if a TLS peer
> >>>> were to try to negotiate:
> >>>>
> >>>>=C2=A0 =C2=A0key agreement: PSK
> >>>>=C2=A0 authentication: RSA-PSS
> >>>>
> >>>> Do we just say "don't do that"?
> >>>
> >>> SGTM
> >>
> >>=E2=80=A6=E2=80=A6...
> >>Once the full cartesian explosion is available by multidimensi= onal
> >>enumeration, we have to mark out which corners of the space ar= e actually
> >>bad ideas, and we have to make sure our implementations don= 9;t stumble
> >>into those corners by accident.
> >>
> >>This isn't impossible to do, but it seems ripe for subtle = implementation
> >>bugs.
> >
> > Cryptographically sound algorithms and protocols should be immune= to this
> > concern. And we should accept only cryptographically sound algori= thms &
> > protocols. :-)
>
> What do you think an implementation should do when a peer tries to
> negotiate the combination above?=C2=A0 Require an RSA-PSS signature fr= om the
> server over some material derived in part from the PSK key agreement > mechanism?

To me it seems like that combo is quite insecure, unless one ha= ndles it as
a special case (in which case it is just equivalent to PSK in security,
just wastes time with a certificate).


As list, the key exchange methods TLS v1.2 actually supports (after merging=
some non-significant distinctions) are:
- RSA [going away]
- RSA_EXPORT [you have deimplemented this already, right?]
- DH_CERT [going away]
- DHE_CERT [supported]
- DHE_ANON [???]
- KRB5 [going away]
- PSK [???]
- DHE_PSK [???]
- RSA_PSK [going away]
- SRP [???]
- SRP_CERT [???]



-Ilari

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



--
=
SY, Dmitry Belyavsky
--047d7bfcf70e15624e05139faef1-- From nobody Mon Apr 13 11:58: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 232161B2FD5 for ; Mon, 13 Apr 2015 11:58:11 -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 vSZCBXahiKAX for ; Mon, 13 Apr 2015 11:58:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B765E1B2FC1 for ; Mon, 13 Apr 2015 11:58:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6D339BF25 for ; Mon, 13 Apr 2015 19:58:06 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrSzREhAVrab for ; Mon, 13 Apr 2015 19:58:05 +0100 (IST) Received: from [10.87.48.73] (unknown [86.41.51.113]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 19A8BBECA for ; Mon, 13 Apr 2015 19:58:05 +0100 (IST) Message-ID: <552C11BC.7030009@cs.tcd.ie> Date: Mon, 13 Apr 2015 19:58:04 +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: tls mailing list References: <20150413180246.22757.70956.idtracker@ietfa.amsl.com> In-Reply-To: <20150413180246.22757.70956.idtracker@ietfa.amsl.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Protocol Action: 'Deprecating Secure Sockets Layer Version 3.0' to Best Current Practice (draft-ietf-tls-sslv3-diediedie-03.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: Mon, 13 Apr 2015 18:58:11 -0000 Good job folks - thanks! Keep up the deprecating please:-) Cheers, S. On 13/04/15 19:02, The IESG wrote: > The IESG has approved the following document: > - 'Deprecating Secure Sockets Layer Version 3.0' > (draft-ietf-tls-sslv3-diediedie-03.txt) as Best Current Practice > > This document is the product of the Transport Layer Security Working > Group. > > The IESG contact persons are Stephen Farrell and Kathleen Moriarty. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ > > > > > > Technical Summary > > Secure Sockets Layer version 3.0 (SSLv3) is no longer secure. This > document requires that SSLv3 not be used. The replacement versions, > in particular Transport Layer Security (TLS) 1.2, are considerably > more secure and capable protocols. > > This document updates the backward compatibility sections of the TLS > RFCs to prohibit fallback to SSLv3. > > Working Group Summary > > This document has been actively reviewed by the TLS working > group. There is strong community consensus behind the document. > > Document Quality > > Are there existing implementations of the protocol? Yes, and > that's the problem;-) However, many deployments and > implementations have already started disabling SSLv3. > > Personnel > > Joseph Salowey is the document shepherd. > Stephen Farrell is the responsible AD for this document. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Apr 13 12:17: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 56C6C1B31E6 for ; Mon, 13 Apr 2015 12:17:43 -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 QH0CNFhsenjq for ; Mon, 13 Apr 2015 12:17:39 -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 62B5D1B31B2 for ; Mon, 13 Apr 2015 12:17:38 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 2F5941887BD; Mon, 13 Apr 2015 22:17:34 +0300 (EEST) Date: Mon, 13 Apr 2015 22:17:33 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150413191733.GB1016@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> <20150413181144.GA720@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: Mon, 13 Apr 2015 19:17:43 -0000 On Mon, Apr 13, 2015 at 11:24:13AM -0700, Martin Thomson wrote: > On 13 April 2015 at 11:11, Ilari Liusvaara wrote: > > > Also, there's the case 0-RTT is attempted without resumption. Or is > > 0-RTT intended only for session resumption attempts (which would cut > > quite a bit of complexity)? > > I don't know how this is intended to work, but I always think of 0-RTT > as resumption. Nothing much else makes sense. > > >> That combination might not be valid. If it is, I'm guessing that the > >> first client flight is encrypted and authenticated as a "normal" 0-RTT > >> handshake. > > > > One can't attempt resumption with 0-RTT data? > > I don't actually know the answer to this. There are three kinds of ClientHellos: 1) Those that attempt resumption (session-id or session-ticket) 2) Those that don't (no session-id, no session-ticket). 3) Some new type that doesn't currently exist (I presume TLS 1.3 won't add one). Is attempt to send 0-RTT data allowed with 1)? With 2)? -Ilari From nobody Mon Apr 13 12:30: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 0E7D71B3266 for ; Mon, 13 Apr 2015 12:30: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 CuLyp7pVOfFQ for ; Mon, 13 Apr 2015 12:30:04 -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 CBA6F1B3265 for ; Mon, 13 Apr 2015 12:30:04 -0700 (PDT) Received: by oica37 with SMTP id a37so12759770oic.0 for ; Mon, 13 Apr 2015 12:30:04 -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=6knhlx+wKbYP0e0n0dkyzvUYq2vpis5z35dEtf8e7sw=; b=nMHrRj1pQBklTX/VTF9B5fGcaBviUL4naIdywvGPmWZaSVIZInNFxs3IItWMHoyx3h TmqkIRPvzj+dmo2lAhSWBKWFuXUyG3qNEzTk6S040Ch1U0qYKYtH7LJnOpWQpM4EHOtA wX/O0hVKq18zzP0U0SEmjxtuprqGWoc7wP4f0vhrM9WcsRKKOGcY5765g23PJY4bItm7 uDPVc2zkX6Deb2esn4V5hx8FARJfcAooh7670AI/V8w7BXQEUD3MUCw5U+ZBY+zz+uOS IHtODDjrmKYkNsWX3Dx/dRVmd6QYTfU4sKpgSeXgh732/MQkftX5Eh2nUq0CvjU0zewS o81A== MIME-Version: 1.0 X-Received: by 10.182.91.106 with SMTP id cd10mr13496838obb.47.1428953404307; Mon, 13 Apr 2015 12:30:04 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Mon, 13 Apr 2015 12:30:04 -0700 (PDT) In-Reply-To: <20150413191733.GB1016@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> <20150413181144.GA720@LK-Perkele-VII> <20150413191733.GB1016@LK-Perkele-VII> Date: Mon, 13 Apr 2015 12:30:04 -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: Mon, 13 Apr 2015 19:30:06 -0000 On 13 April 2015 at 12:17, Ilari Liusvaara wrote: > There are three kinds of ClientHellos: > 1) Those that attempt resumption (session-id or session-ticket) > 2) Those that don't (no session-id, no session-ticket). > 3) Some new type that doesn't currently exist (I presume TLS 1.3 won't > add one). > > Is attempt to send 0-RTT data allowed with 1)? With 2)? You assume that 0-RTT doesn't fall into that third category. I hadn't. From nobody Mon Apr 13 12:46: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 DAA141A1A17 for ; Mon, 13 Apr 2015 12:46:13 -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 tBas8TamTfTe for ; Mon, 13 Apr 2015 12:46:11 -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 DA9C71A1A24 for ; Mon, 13 Apr 2015 12:46:09 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 379B09004D; Mon, 13 Apr 2015 22:46:05 +0300 (EEST) Date: Mon, 13 Apr 2015 22:46:05 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150413194605.GA1377@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> <20150413181144.GA720@LK-Perkele-VII> <20150413191733.GB1016@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: Mon, 13 Apr 2015 19:46:14 -0000 On Mon, Apr 13, 2015 at 12:30:04PM -0700, Martin Thomson wrote: > On 13 April 2015 at 12:17, Ilari Liusvaara wrote: > > There are three kinds of ClientHellos: > > 1) Those that attempt resumption (session-id or session-ticket) > > 2) Those that don't (no session-id, no session-ticket). > > 3) Some new type that doesn't currently exist (I presume TLS 1.3 won't > > add one). > > > > Is attempt to send 0-RTT data allowed with 1)? With 2)? > > 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. -Ilari From nobody Mon Apr 13 12:57: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 DDB9C1A1A64 for ; Mon, 13 Apr 2015 12:57:53 -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_12=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 JTGCRsfsANQQ for ; Mon, 13 Apr 2015 12:57:52 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761871A1A3B for ; Mon, 13 Apr 2015 12:57:52 -0700 (PDT) Received: by vnbf1 with SMTP id f1so23308652vnb.0 for ; Mon, 13 Apr 2015 12:57:51 -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=sutP4prJFYGdfWXTxXfJ3uN401whFkLxUg5/Rc2yCXY=; b=zEirZs0xRjFkhNVdhwG/Ng7SpLzKzjGWzPjxw2TO0Zm2/M2cd4xrvzaucPqtwuOfAO TrDw7gbZcaPHcAdLebK3rLwheeQYDvEFEiJfdVzWUqG/KLdfXsP1/0B9R+04/QcOtxe5 7YEc+d+/Jxpt6uPA2bk5Tw25MIzrm1AHXnLEDRj7oP3e6rjfmA+VdWg16PoNkhEAwz42 H3zanLs4HsjpIR21AFO2YsG4xDPZfAWi/pqnXUksNZIVOVdVupn8GM/6zSSLJz7/nL1i 8fy+y4pGNLtu1m984tG4WAaWpQmVe0N3JA9TUvT0BrAKGA0qvGsIyodGhBCRkcKuiA8W Pv4w== MIME-Version: 1.0 X-Received: by 10.60.155.135 with SMTP id vw7mr13570667oeb.62.1428955071444; Mon, 13 Apr 2015 12:57:51 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Mon, 13 Apr 2015 12:57:51 -0700 (PDT) In-Reply-To: <20150413194605.GA1377@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> <20150413181144.GA720@LK-Perkele-VII> <20150413191733.GB1016@LK-Perkele-VII> <20150413194605.GA1377@LK-Perkele-VII> Date: Mon, 13 Apr 2015 12:57:51 -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: Mon, 13 Apr 2015 19:57:54 -0000 On 13 April 2015 at 12:46, Ilari Liusvaara wrote: > On Mon, Apr 13, 2015 at 12:30:04PM -0700, Martin Thomson wrote: >> On 13 April 2015 at 12:17, Ilari Liusvaara wrote: >> > There are three kinds of ClientHellos: >> > 1) Those that attempt resumption (session-id or session-ticket) >> > 2) Those that don't (no session-id, no session-ticket). >> > 3) Some new type that doesn't currently exist (I presume TLS 1.3 won't >> > add one). >> > >> > Is attempt to send 0-RTT data allowed with 1)? With 2)? >> >> 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. From nobody Mon Apr 13 13:45: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 1D7541A7005 for ; Mon, 13 Apr 2015 13:45:41 -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 pdTc4QQJaetr for ; Mon, 13 Apr 2015 13:45:40 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DFE991A6EDC for ; Mon, 13 Apr 2015 13:45:39 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id ADB8FF984 for ; Mon, 13 Apr 2015 16:45:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 66A63200F2; Mon, 13 Apr 2015 15:45:25 -0500 (CDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: <20150413185505.GA1016@LK-Perkele-VII> References: <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> <201504131325.20590.davemgarrett@gmail.com> <871tjoue8v.fsf@alice.fifthhorseman.net> <87vbgzubj6.fsf@alice.fifthhorseman.net> <20150413185505.GA1016@LK-Perkele-VII> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 13 Apr 2015 16:45:25 -0400 Message-ID: <87mw2bu596.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 20:45:41 -0000 On Mon 2015-04-13 14:55:05 -0400, Ilari Liusvaara wrote: > On Mon, Apr 13, 2015 at 02:29:49PM -0400, Daniel Kahn Gillmor wrote: > >> What do you think an implementation should do when a peer tries to >> negotiate the combination above? Require an RSA-PSS signature from the >> server over some material derived in part from the PSK key agreement >> mechanism? > > To me it seems like that combo is quite insecure, unless one handles it as > a special case (in which case it is just equivalent to PSK in security, > just wastes time with a certificate). Can you explain why it's "quite insecure"? It doesn't seem any worse than normal (non-DHE) PSK other than the cost of signing and verifying. I suppose that it also proves that an attacker has access to both the PSK and the secret key material belonging to the cert. So, for example, you could give a dozen clients the same PSK (maybe to provide them with indistinguishability from each other to a network observer?), but clients that want to be sure they're talking to the server (instead of each other) can rely on the server's cert. > As list, the key exchange methods TLS v1.2 actually supports (after merging > some non-significant distinctions) are: > - RSA [going away] > - RSA_EXPORT [you have deimplemented this already, right?] > - DH_CERT [going away] > - DHE_CERT [supported] > - DHE_ANON [???] > - KRB5 [going away] > - PSK [???] > - DHE_PSK [???] > - RSA_PSK [going away] > - SRP [???] > - SRP_CERT [???] I think this list mixes up key exchange with authentication, which was what Dave was trying to tease apart. For key exchange, there is no difference between DHE_CERT and DHE_ANON and DHE_PSK -- they're all DHE. the ANON/CERT/PSK parts would be negotiated separately in the authentication side of things (via the signature_algorithms extension). (And if we're using supported_groups, the distinctions between different flavors of DHE (FFDHE2048, ECDHEP256, ECDHEX25519, etc) are hardly non-significant, but i guess that's a slightly different discussion.) --dkg From nobody Mon Apr 13 13:59: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 8CA071A7113 for ; Mon, 13 Apr 2015 13:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4F0LklDxV9f for ; Mon, 13 Apr 2015 13:59:56 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7831A710D for ; Mon, 13 Apr 2015 13:59:56 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 49FAFF984 for ; Mon, 13 Apr 2015 16:59:54 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3FBA420088; Mon, 13 Apr 2015 15:59:53 -0500 (CDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: <20150413181144.GA720@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> <20150413181144.GA720@LK-Perkele-VII> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 13 Apr 2015 16:59:53 -0400 Message-ID: <87k2xfu4l2.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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: Mon, 13 Apr 2015 20:59:57 -0000 On Mon 2015-04-13 14:11:44 -0400, Ilari Liusvaara wrote: > On Mon, Apr 13, 2015 at 10:02:43AM -0700, Martin Thomson wrote: > >> But I imagine that this depends on the model we employ. Replayable >> data could just be consider the start of a stream. On the other hand, >> unreliable data doesn't work very well for a stream mode. Conversely, >> replayable data makes no sense in a datagram mode, but all data is >> unreliable there. > > I thought the recommended client-side interface called for auto- > retransmit, which would mean that if application handled 0RTT as anything > else than a prefix, it would now create two cases serverside. Just because the data is replayable doesn't mean that it is replayable *in the same stream*. For TLS over TCP, both sides of the stream should be able to model the state of the other side of the connection in a way that the next piece of data sent depends on the understanding being correct. If we decide that the client will auto-retransmit the payload, that means that an attacker could cause *a second stream* to start in the same way, not that the existing stream might or might not have the initial payload loaded twice. --dkg From nobody Mon Apr 13 14:09: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 8E9EA1A8733 for ; Mon, 13 Apr 2015 14:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 dH9lMLNHLz-l for ; Mon, 13 Apr 2015 14:09:14 -0700 (PDT) Received: from dragaera.releasedominatrix.com (unknown [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 4945A1A874B for ; Mon, 13 Apr 2015 14:09:06 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 7CFDC33D223; Mon, 13 Apr 2015 21:09:05 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Martin Thomson References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> From: Geoffrey Keating Date: 13 Apr 2015 14:09:05 -0700 In-Reply-To: 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: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 21:09:16 -0000 Martin Thomson writes: > On 3 April 2015 at 17:05, Brian Smith wrote: > > I don't think the current mechanism is problematic > > enough (at all, really) to justify that effort. > > I think that I've the same view. > > Then you have to consider interaction problems where some > implementations have hardware for certain things, and software for > others. Not only does that produce strong preferences for some things > over others, it also can lead to holes in support tables, making a la > carte selection tricky. > > That was always the clincher for me. I agree. In particular I don't think we've simplified anything if implementations have to have a list of invalid combinations, or have to know that certain ciphers are to be used only with matching key exchange algorithms (for example, use the GOST key exchange with the GOST symmetric cipher). From nobody Mon Apr 13 14:18: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 3FF3D1A876A for ; Mon, 13 Apr 2015 14:18:16 -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 LREkQEFHxyrc for ; Mon, 13 Apr 2015 14:18:14 -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 483F31A875A for ; Mon, 13 Apr 2015 14:18:14 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 17152446DB for ; Mon, 13 Apr 2015 23:18:11 +0200 (CEST) X-purgate-ID: 152705::1428959892-0000765A-EED894C5/0/0 X-purgate-size: 600 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id C07F5434ED for ; Mon, 13 Apr 2015 23:18:11 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B62E21B281; Mon, 13 Apr 2015 23:18:11 +0200 (CEST) To: tls@ietf.org Date: Mon, 13 Apr 2015 23:18:11 +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: <20150413211811.B62E21B281@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned 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, 13 Apr 2015 21:18:16 -0000 I have only recently looked at the TLS extension ALPN spec (RFC7301) and it seems that there currently is no reserved character for the ALPN ID registry that could be used as seperator character if one wanted to facilitate the admin/user UI and tracing/logging. While I don't allowing UTF8, I would have really appreciated reserving at least one character (or octet value) for the obvious purpose of printing all currently offered protocols in a single line. I'm also puzzled why the octet value 0 was not banned from the ALPN ID either. That seems like calling for trouble. -Martin From nobody Mon Apr 13 14:32: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 DB7CE1A8855 for ; Mon, 13 Apr 2015 14:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 nZ1GvbHZI41B for ; Mon, 13 Apr 2015 14:32:24 -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 804071A8838 for ; Mon, 13 Apr 2015 14:32:24 -0700 (PDT) Received: from BN3PR0301MB1252.namprd03.prod.outlook.com (0.161.207.28) by BN3PR0301MB1185.namprd03.prod.outlook.com (0.160.156.147) with Microsoft SMTP Server (TLS) id 15.1.130.23; Mon, 13 Apr 2015 21:32:23 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (0.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (0.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 13 Apr 2015 21:32:22 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) with mapi id 15.01.0136.014; Mon, 13 Apr 2015 21:32:22 +0000 From: Andrei Popov To: "mrex@sap.com" , "tls@ietf.org" Thread-Topic: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned Thread-Index: AQHQdi9iiKNw4qTUUEOLU8cBaoI6OJ1LdMAA Date: Mon, 13 Apr 2015 21:32:22 +0000 Message-ID: References: <20150413211811.B62E21B281@ld9781.wdf.sap.corp> In-Reply-To: <20150413211811.B62E21B281@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sap.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1185; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(87936001)(46102003)(2501003)(122556002)(74316001)(106116001)(33656002)(76176999)(107886001)(2656002)(4001410100001)(40100003)(99286002)(19580405001)(19580395003)(86612001)(86362001)(76576001)(102836002)(77156002)(15975445007)(62966003)(92566002)(50986999)(2900100001)(2950100001)(54356999)(7059030)(3826002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1252; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; x-forefront-prvs: 0545EFAC9A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2015 21:32:22.3482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1252 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Apr 2015 21:32:26 -0000 Hi Martin, Although the currently defined ALPN IDs consist of printable characters (wh= ich admittedly helps when looking at network traces), generally speaking AL= PN IDs are octet strings and could contain arbitrary bytes. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex Sent: Monday, April 13, 2015 2:18 PM To: tls@ietf.org Subject: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 = no banned I have only recently looked at the TLS extension ALPN spec (RFC7301) and it= seems that there currently is no reserved character for the ALPN ID regist= ry that could be used as seperator character if one wanted to facilitate th= e admin/user UI and tracing/logging. While I don't allowing UTF8, I would have really appreciated reserving at l= east one character (or octet value) for the obvious purpose of printing all= currently offered protocols in a single line. I'm also puzzled why the octet value 0 was not banned from the ALPN ID eith= er. That seems like calling for trouble. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Apr 13 14:44: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 83D1D1A8909 for ; Mon, 13 Apr 2015 14:44:56 -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 QqO83jdtpYc4 for ; Mon, 13 Apr 2015 14:44: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 100D51A894B for ; Mon, 13 Apr 2015 14:44:55 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id BE4254473D; Mon, 13 Apr 2015 23:44:53 +0200 (CEST) X-purgate-ID: 152705::1428961493-0000765A-05140CCE/0/0 X-purgate-size: 888 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id B46D14358B; Mon, 13 Apr 2015 23:44:53 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AC7AB1B281; Mon, 13 Apr 2015 23:44:53 +0200 (CEST) In-Reply-To: To: Andrei Popov Date: Mon, 13 Apr 2015 23:44: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: <20150413214453.AC7AB1B281@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned 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, 13 Apr 2015 21:44:56 -0000 Andrei Popov wrote: > > Although the currently defined ALPN IDs consist of printable characters > (which admittedly helps when looking at network traces), generally > speaking ALPN IDs are octet strings and could contain arbitrary bytes. I do understand what the current specification (rfc7301) says. But I just fail to see a rationale why it needs to be that artificially awkward with no pressing need. Being able to handle (rather than being allowed to reject upfront) arbitrary octet string blobs here makes it extremely painful to implement APIs for this. You can not allow the pretty common 0-terminated strings API semantics if embedded 0 characters are permitted, and might get registered in the future. I'm wondering what specific rationale (other than calling for trouble) justifies making this extension extra painful to implement and use? -Martin From nobody Mon Apr 13 14: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 05C951A8A3D for ; Mon, 13 Apr 2015 14:51: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 5avFru6_4PtC for ; Mon, 13 Apr 2015 14:51:03 -0700 (PDT) Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::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 C5D741A8A06 for ; Mon, 13 Apr 2015 14:51:02 -0700 (PDT) Received: by vnbg7 with SMTP id g7so24301480vnb.11 for ; Mon, 13 Apr 2015 14:51:02 -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=YcuVLmhVTAqWCFcN1ws4/kVi0//qtVUaPCbG4FmNz/o=; b=lniuxzo9U2igBikORfe7OKVqwNY7WGJ23KZ+z/Q3EBuIRVaqkuuOTs0b1v7Hi9DSjv nUfciBMqSDDlp6JY/9dRcXGsto7G8tN/d2hkuTo+UoQxyNE/ZLt9xOtlmeUzVUvSNe1P 9RPU6eJp7sJ2XghPx1g7JiWURmlf0MaIULukN24/wUyWzS2RfKLPv8QpszlxV5m6QGuG ORdbnCu/0f7COAkH7mOd4irzYiCHuivfoOc8tEXa42MiRMcGqVwevc3wuuLtwr2fxgWD GtXQ4/DJKTzfDdhqJE5zyoYvfs5xagdvqTUcqmIfo0V+Nla2mj+nMX3M/hymviw7eATG mxcw== MIME-Version: 1.0 X-Received: by 10.60.158.202 with SMTP id ww10mr14091093oeb.18.1428961862066; Mon, 13 Apr 2015 14:51:02 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Mon, 13 Apr 2015 14:51:01 -0700 (PDT) In-Reply-To: <20150413214453.AC7AB1B281@ld9781.wdf.sap.corp> References: <20150413214453.AC7AB1B281@ld9781.wdf.sap.corp> Date: Mon, 13 Apr 2015 14:51:01 -0700 Message-ID: From: Martin Thomson To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Apr 2015 21:51:04 -0000 On 13 April 2015 at 14:44, Martin Rex wrote: > But I just fail to see a rationale why it needs to be that artificially > awkward with no pressing need. The rationale could be as simple as the fact that no one made any attempt to constrain the value-space when the RFC was discussed in the working group. Apparently, people who had NPN implementations were already doing the ugly API thing (the API in NSS is definitely not an examplar here) and so no one objected at the time. I agree that it's more painful than absolutely necessary. From nobody Mon Apr 13 14:57: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 BE34B1A902C for ; Mon, 13 Apr 2015 14:57:42 -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 1ggwbpRVZRtL for ; Mon, 13 Apr 2015 14:57:41 -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 C7AA71A9022 for ; Mon, 13 Apr 2015 14:57:40 -0700 (PDT) Received: by wizk4 with SMTP id k4so90501672wiz.1 for ; Mon, 13 Apr 2015 14:57: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=Jl41WzCyubLdOBUT25pDLk4RSUy6Q19i4E0AcE133Xk=; b=inJwSeRLdzj4sWK2eJ+dBO2h+rqsNp/byRGQcM9gakkqDbzVirLJ/zvarznAxiSo+5 eTmZJPDoaNYKGbAh51hHe62VKA+juDBhzNFYF0s1b4jMFj/CkZ0jq7NI5cHu1xBxiTsb hMTZLs5BWXu9Ln2u/JhH6BF1d7mMkntHV9e6oNJBvu6P/qyf9IaG9uY0DEQq9A8KpdLE cyxf7Hct6e6V72YOfySMRB/mXCEnLqwP45fc7ULPemfHYh+aJlXECORlbQx+7fAqpRbA N2pQu+JuvaLCKr73e0ZeLHvUbqZ0i9LNXqQZNhc1/qn4+H6ZiJlvq84gZf3s5k1SRlYe 7PgQ== X-Received: by 10.180.187.171 with SMTP id ft11mr26241630wic.0.1428962259556; Mon, 13 Apr 2015 14:57:39 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id fs9sm13202243wjc.34.2015.04.13.14.57.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Apr 2015 14:57:38 -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: Tue, 14 Apr 2015 00:57:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> To: Geoffrey Keating X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 21:57:42 -0000 > On Apr 14, 2015, at 12:09 AM, Geoffrey Keating = wrote: >=20 > Martin Thomson writes: >=20 >> On 3 April 2015 at 17:05, Brian Smith wrote: >>> I don't think the current mechanism is problematic >>> enough (at all, really) to justify that effort. >>=20 >> I think that I've the same view. >>=20 >> Then you have to consider interaction problems where some >> implementations have hardware for certain things, and software for >> others. Not only does that produce strong preferences for some = things >> over others, it also can lead to holes in support tables, making a la >> carte selection tricky. >>=20 >> That was always the clincher for me. >=20 > I agree. In particular I don't think we've simplified anything if > implementations have to have a list of invalid combinations, or have > to know that certain ciphers are to be used only with matching key > exchange algorithms (for example, use the GOST key exchange with the > GOST symmetric cipher). Why? There=E2=80=99s nothing invalid about using Curve25519 key = exchange with an RSA certificate and GOST symmetric ciphers, so TLS = should not provide this. Requiring all three things to be GOST is a = policy decision that can and should be part of server (and perhaps = client) configuration. If some standard in Russia demands that GOST algorithms be used for all = three, that should be configurable on the server. If OTOH the Russian = authorities decide that they are fine with ECDHE for key exchange, but = demand the GOST symmetric ciphers and authentication, that is also easy = to get working with a la carte, but now it=E2=80=99s impossible until = someone specifies such ciphersuites in a new document. Unless some combination creates an insecurity when each of its = components is secure when combined with other components, I don=E2=80=99t = think we have an issue.=20 Yoav= From nobody Mon Apr 13 14: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 A9FC11A90B0 for ; Mon, 13 Apr 2015 14:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 T08m7Yo8FzoJ for ; Mon, 13 Apr 2015 14:58:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0129.outbound.protection.outlook.com [207.46.100.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B42E1A9090 for ; Mon, 13 Apr 2015 14:58:13 -0700 (PDT) Received: from BN3PR0301MB1252.namprd03.prod.outlook.com (0.161.207.28) by BN3PR0301MB1265.namprd03.prod.outlook.com (0.161.209.145) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 13 Apr 2015 21:58:13 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (0.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (0.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 13 Apr 2015 21:58:12 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) with mapi id 15.01.0136.014; Mon, 13 Apr 2015 21:58:12 +0000 From: Andrei Popov To: Martin Thomson , "mrex@sap.com" Thread-Topic: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned Thread-Index: AQHQdjMVLAECbtqN1ke7Q3E3qycYJJ1Le3aAgAAAZTA= Date: Mon, 13 Apr 2015 21:58:11 +0000 Message-ID: References: <20150413214453.AC7AB1B281@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1265; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(87936001)(46102003)(122556002)(2501003)(74316001)(106116001)(33656002)(76176999)(2656002)(4001410100001)(99286002)(40100003)(19580405001)(19580395003)(86612001)(86362001)(76576001)(102836002)(77156002)(62966003)(92566002)(50986999)(2900100001)(2950100001)(54356999)(7059030)(3826002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1252; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; x-forefront-prvs: 0545EFAC9A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2015 21:58:11.9308 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1252 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Apr 2015 21:58:14 -0000 WWVzLCB0aGlzIGlzIGFuIGV4YW1wbGUgb2YgTlBOIGxlZ2FjeSBpbiBBTFBOLCBhbmQgeWVzIHRo ZXJlIGlzIHNvbWUgQVBJIHBhaW4gaW52b2x2ZWQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNv bV0gDQpTZW50OiBNb25kYXksIEFwcmlsIDEzLCAyMDE1IDI6NTEgUE0NClRvOiBtcmV4QHNhcC5j b20NCkNjOiBBbmRyZWkgUG9wb3Y7IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFRM UyBBTFBOIChyZmM3MzAxKSwgbm8gcmVzZXJ2ZWQgc2VwZXJhdG9yIGNoYXIgYW5kIHdoeSBpcyAw IG5vIGJhbm5lZA0KDQpPbiAxMyBBcHJpbCAyMDE1IGF0IDE0OjQ0LCBNYXJ0aW4gUmV4IDxtcmV4 QHNhcC5jb20+IHdyb3RlOg0KPiBCdXQgSSBqdXN0IGZhaWwgdG8gc2VlIGEgcmF0aW9uYWxlIHdo eSBpdCBuZWVkcyB0byBiZSB0aGF0IA0KPiBhcnRpZmljaWFsbHkgYXdrd2FyZCB3aXRoIG5vIHBy ZXNzaW5nIG5lZWQuDQoNClRoZSByYXRpb25hbGUgY291bGQgYmUgYXMgc2ltcGxlIGFzIHRoZSBm YWN0IHRoYXQgbm8gb25lIG1hZGUgYW55IGF0dGVtcHQgdG8gY29uc3RyYWluIHRoZSB2YWx1ZS1z cGFjZSB3aGVuIHRoZSBSRkMgd2FzIGRpc2N1c3NlZCBpbiB0aGUgd29ya2luZyBncm91cC4NCg0K QXBwYXJlbnRseSwgcGVvcGxlIHdobyBoYWQgTlBOIGltcGxlbWVudGF0aW9ucyB3ZXJlIGFscmVh ZHkgZG9pbmcgdGhlIHVnbHkgQVBJIHRoaW5nICh0aGUgQVBJIGluIE5TUyBpcyBkZWZpbml0ZWx5 IG5vdCBhbiBleGFtcGxhciBoZXJlKSBhbmQgc28gbm8gb25lIG9iamVjdGVkIGF0IHRoZSB0aW1l Lg0KDQpJIGFncmVlIHRoYXQgaXQncyBtb3JlIHBhaW5mdWwgdGhhbiBhYnNvbHV0ZWx5IG5lY2Vz c2FyeS4NCg== From nobody Mon Apr 13 15:18: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 179331ACE76 for ; Mon, 13 Apr 2015 15:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRk7bUe0hmIs for ; Mon, 13 Apr 2015 15:18:55 -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 C6EC31ACE75 for ; Mon, 13 Apr 2015 15:18:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C309E283031; Mon, 13 Apr 2015 22:18:54 +0000 (UTC) Date: Mon, 13 Apr 2015 22:18:54 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150413221854.GX17637@mournblade.imrryr.org> References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.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] Ala Carte Cipher suites - was: DSA should die 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, 13 Apr 2015 22:18:57 -0000 On Tue, Apr 14, 2015 at 12:57:36AM +0300, Yoav Nir wrote: > Unless some combination creates an insecurity when each of its > components is secure when combined with other components, I don't > think we have an issue. Yep, that's my view also. -- Viktor. From nobody Mon Apr 13 15:22: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 62E851ACE76 for ; Mon, 13 Apr 2015 15:22:29 -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 D3RonTJIPYYd for ; Mon, 13 Apr 2015 15:22:19 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id EB68C1AD2A4 for ; Mon, 13 Apr 2015 15:22:18 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t3DMMFcT030674; Mon, 13 Apr 2015 18:22:15 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "'ynir.ietf@gmail.com'" , "'geoffk@geoffk.org'" Thread-Topic: [TLS] Ala Carte Cipher suites - was: DSA should die Thread-Index: AQHQbatVG4ITsjPF1kmCUIQaIRqrT508PbaAgAAJxwCAD3xggIAADY4A///DvVw= Date: Mon, 13 Apr 2015 22:22:14 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC2712CF72@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-13_05:2015-04-10,2015-04-13,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-1504130190 Archived-At: Cc: "'tls@ietf.org'" Subject: Re: [TLS] Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 22:22:29 -0000 WWVzLiBNeSBleHBlY3RhdGlvbiBoZXJlIGlzIHRoYXQgImdvb2QiIGNvbnN0cnVjdHMgYXJlIGNv bXBvc2FibGUuICJDb21wb3NhYmxlIHdpdGggY2F2ZWF0cyIgYXJlIG5vdCBnb29kLCBhbmQgc2hv dWxkbid0IGJlIGluY2x1ZGVkIGluIGEtbGEgY2FydGUgc2VsZWN0aW9uLiANCg0KLS0NClJlZ2Fy ZHMsDQpVcmkgQmx1bWVudGhhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICBWb2ljZTogKDc4 MSkgOTgxLTE2MzgNCkN5YmVyIFN5c3RlbXMgYW5kIFRlY2hub2xvZ3kgICBGYXg6ICAgKDc4MSkg OTgxLTAxODYNCk1JVCBMaW5jb2xuIExhYm9yYXRvcnkgICAgICAgICAgICAgICAgQ2VsbDogICgz MzkpIDIyMy01MzYzDQoyNDQgV29vZCBTdHJlZXQsIExleGluZ3RvbiwgTUEgMDI0MjAtOTE4NSAg ICAgICANCg0KV2ViOiAgaHR0cDovL3d3dy5sbC5taXQuZWR1L0NTVC8NCk1JVCBMTCBSb290IENB OiAgPGh0dHBzOi8vd3d3LmxsLm1pdC5lZHUvbGFiY2VydGlmaWNhdGVhdXRob3JpdHkuaHRtbD4N Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogWW9hdiBOaXIgW21haWx0bzp5 bmlyLmlldGZAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxMywgMjAxNSAwNTo1NyBQ TQpUbzogR2VvZmZyZXkgS2VhdGluZyA8Z2VvZmZrQGdlb2Zmay5vcmc+DQpDYzogPHRsc0BpZXRm Lm9yZz4gPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBBbGEgQ2FydGUgQ2lwaGVy IHN1aXRlcyAtIHdhczogRFNBIHNob3VsZCBkaWUNCg0KCj4gT24gQXByIDE0LCAyMDE1LCBhdCAx MjowOSBBTSwgR2VvZmZyZXkgS2VhdGluZyA8Z2VvZmZrQGdlb2Zmay5vcmc+IHdyb3RlOgo+IAo+ IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+IHdyaXRlczoKPiAKPj4g T24gMyBBcHJpbCAyMDE1IGF0IDE3OjA1LCBCcmlhbiBTbWl0aCA8YnJpYW5AYnJpYW5zbWl0aC5v cmc+IHdyb3RlOgo+Pj4gSSBkb24ndCB0aGluayB0aGUgY3VycmVudCBtZWNoYW5pc20gaXMgcHJv YmxlbWF0aWMKPj4+IGVub3VnaCAoYXQgYWxsLCByZWFsbHkpIHRvIGp1c3RpZnkgdGhhdCBlZmZv cnQuCj4+IAo+PiBJIHRoaW5rIHRoYXQgSSd2ZSB0aGUgc2FtZSB2aWV3Lgo+PiAKPj4gVGhlbiB5 b3UgaGF2ZSB0byBjb25zaWRlciBpbnRlcmFjdGlvbiBwcm9ibGVtcyB3aGVyZSBzb21lCj4+IGlt cGxlbWVudGF0aW9ucyBoYXZlIGhhcmR3YXJlIGZvciBjZXJ0YWluIHRoaW5ncywgYW5kIHNvZnR3 YXJlIGZvcgo+PiBvdGhlcnMuICBOb3Qgb25seSBkb2VzIHRoYXQgcHJvZHVjZSBzdHJvbmcgcHJl ZmVyZW5jZXMgZm9yIHNvbWUgdGhpbmdzCj4+IG92ZXIgb3RoZXJzLCBpdCBhbHNvIGNhbiBsZWFk IHRvIGhvbGVzIGluIHN1cHBvcnQgdGFibGVzLCBtYWtpbmcgYSBsYQo+PiBjYXJ0ZSBzZWxlY3Rp b24gdHJpY2t5Lgo+PiAKPj4gVGhhdCB3YXMgYWx3YXlzIHRoZSBjbGluY2hlciBmb3IgbWUuCj4g Cj4gSSBhZ3JlZS4gIEluIHBhcnRpY3VsYXIgSSBkb24ndCB0aGluayB3ZSd2ZSBzaW1wbGlmaWVk IGFueXRoaW5nIGlmCj4gaW1wbGVtZW50YXRpb25zIGhhdmUgdG8gaGF2ZSBhIGxpc3Qgb2YgaW52 YWxpZCBjb21iaW5hdGlvbnMsIG9yIGhhdmUKPiB0byBrbm93IHRoYXQgY2VydGFpbiBjaXBoZXJz IGFyZSB0byBiZSB1c2VkIG9ubHkgd2l0aCBtYXRjaGluZyBrZXkKPiBleGNoYW5nZSBhbGdvcml0 aG1zIChmb3IgZXhhbXBsZSwgdXNlIHRoZSBHT1NUIGtleSBleGNoYW5nZSB3aXRoIHRoZQo+IEdP U1Qgc3ltbWV0cmljIGNpcGhlcikuCgpXaHk/ICBUaGVyZeKAmXMgbm90aGluZyBpbnZhbGlkIGFi b3V0IHVzaW5nIEN1cnZlMjU1MTkga2V5IGV4Y2hhbmdlIHdpdGggYW4gUlNBIGNlcnRpZmljYXRl IGFuZCBHT1NUIHN5bW1ldHJpYyBjaXBoZXJzLCBzbyBUTFMgc2hvdWxkIG5vdCBwcm92aWRlIHRo aXMuIFJlcXVpcmluZyBhbGwgdGhyZWUgdGhpbmdzIHRvIGJlIEdPU1QgaXMgYSBwb2xpY3kgZGVj aXNpb24gdGhhdCBjYW4gYW5kIHNob3VsZCBiZSBwYXJ0IG9mIHNlcnZlciAoYW5kIHBlcmhhcHMg Y2xpZW50KSBjb25maWd1cmF0aW9uLgoKSWYgc29tZSBzdGFuZGFyZCBpbiBSdXNzaWEgZGVtYW5k cyB0aGF0IEdPU1QgYWxnb3JpdGhtcyBiZSB1c2VkIGZvciBhbGwgdGhyZWUsIHRoYXQgc2hvdWxk IGJlIGNvbmZpZ3VyYWJsZSBvbiB0aGUgc2VydmVyLiBJZiBPVE9IIHRoZSBSdXNzaWFuIGF1dGhv cml0aWVzIGRlY2lkZSB0aGF0IHRoZXkgYXJlIGZpbmUgd2l0aCBFQ0RIRSBmb3Iga2V5IGV4Y2hh bmdlLCBidXQgZGVtYW5kIHRoZSBHT1NUIHN5bW1ldHJpYyBjaXBoZXJzIGFuZCBhdXRoZW50aWNh dGlvbiwgdGhhdCBpcyBhbHNvIGVhc3kgdG8gZ2V0IHdvcmtpbmcgd2l0aCBhIGxhIGNhcnRlLCBi dXQgbm93IGl04oCZcyBpbXBvc3NpYmxlIHVudGlsIHNvbWVvbmUgc3BlY2lmaWVzIHN1Y2ggY2lw aGVyc3VpdGVzIGluIGEgbmV3IGRvY3VtZW50LgoKVW5sZXNzIHNvbWUgY29tYmluYXRpb24gY3Jl YXRlcyBhbiBpbnNlY3VyaXR5IHdoZW4gZWFjaCBvZiBpdHMgY29tcG9uZW50cyBpcyBzZWN1cmUg d2hlbiBjb21iaW5lZCB3aXRoIG90aGVyIGNvbXBvbmVudHMsIEkgZG9u4oCZdCB0aGluayB3ZSBo YXZlIGFuIGlzc3VlLiAKCllvYXYKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KVExTIG1haWxpbmcgbGlzdApUTFNAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMK From nobody Mon Apr 13 15:30: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 0C7BC1ACE82 for ; Mon, 13 Apr 2015 15:30:54 -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 USImt0rg3Q-V for ; Mon, 13 Apr 2015 15:30:52 -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 B26D91ACE88 for ; Mon, 13 Apr 2015 15:30:51 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 779532ABE4; Tue, 14 Apr 2015 00:30:49 +0200 (CEST) X-purgate-ID: 152705::1428964249-00003099-693B1795/0/0 X-purgate-size: 827 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 6C3244359F; Tue, 14 Apr 2015 00:30:49 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 63EE81B281; Tue, 14 Apr 2015 00:30:49 +0200 (CEST) In-Reply-To: To: Andrei Popov Date: Tue, 14 Apr 2015 00:30:49 +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: <20150413223049.63EE81B281@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned 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, 13 Apr 2015 22:30:54 -0000 Andrei Popov wrote: > > Yes, this is an example of NPN legacy in ALPN, > and yes there is some API pain involved. I'm not trying to break things and I'm not advocating to change any existing APIs. But I've just been asked for support of this and am looking into newly implementing it, and I would appreciate if we (i.e. the IETF TLS working group) could restrict the TLS ALPN IDs at least by banning the character 0 from TLS ALPN ID registrations now. Being allowed to reject embedded NULs would facilitate some aspects (save me a few lines of code). I can live with UTF8. A single reserved character (such as colon ':' or pipe '|' or comma ',') would allow me to avoid a character escaping scheme for the API I'm trying to create, but I could live with this issue being a proprietary thing. -Martin From nobody Mon Apr 13 16:15: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 042EF1B2AF8 for ; Mon, 13 Apr 2015 16:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 Ysyz2KYOxPsf for ; Mon, 13 Apr 2015 16:15:40 -0700 (PDT) Received: from dragaera.releasedominatrix.com (unknown [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 6E08F1B2AEB for ; Mon, 13 Apr 2015 16:15:40 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id AA35E33D223; Mon, 13 Apr 2015 23:15:39 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Yoav Nir References: <20150401201221.163745c2@pc1.fritz.box> <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> From: Geoffrey Keating Date: 13 Apr 2015 16:15:39 -0700 In-Reply-To: Message-ID: Lines: 18 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: "" Subject: Re: [TLS] Ala Carte Cipher suites - 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: Mon, 13 Apr 2015 23:15:42 -0000 Yoav Nir writes: > > On Apr 14, 2015, at 12:09 AM, Geoffrey Keating wrot= e: > > In particular I don't think we've simplified anything if > > implementations have to have a list of invalid combinations, or have > > to know that certain ciphers are to be used only with matching key > > exchange algorithms (for example, use the GOST key exchange with the > > GOST symmetric cipher). >=20 > Why? There=E2=80=99s nothing invalid about using Curve25519 key exchange > with an RSA certificate and GOST symmetric ciphers, so TLS should > not provide this. Requiring all three things to be GOST is a policy > decision that can and should be part of server (and perhaps client) > configuration. It seems like that would be an interoperability issue if the server and client disagree on the policy to apply. From nobody Mon Apr 13 17:37: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 CA1C71B2B98 for ; Mon, 13 Apr 2015 17:37:00 -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_51=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 UmJA-YG_yxWx for ; Mon, 13 Apr 2015 17:36:59 -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 9B5261B2B96 for ; Mon, 13 Apr 2015 17:36:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A5841283031; Tue, 14 Apr 2015 00:36:58 +0000 (UTC) Date: Tue, 14 Apr 2015 00:36:58 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150414003658.GB17637@mournblade.imrryr.org> References: <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.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] Ala Carte Cipher suites - was: DSA should die 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, 14 Apr 2015 00:37:00 -0000 On Mon, Apr 13, 2015 at 04:15:39PM -0700, Geoffrey Keating wrote: > > Why? There?s nothing invalid about using Curve25519 key exchange > > with an RSA certificate and GOST symmetric ciphers, so TLS should > > not provide this. Requiring all three things to be GOST is a policy > > decision that can and should be part of server (and perhaps client) > > configuration. > > It seems like that would be an interoperability issue if the server > and client disagree on the policy to apply. If a client or server is willing to do non-GOST algorithms along some axis of the cipher-suite parameter space, it should be willing to accept mixed results. It is no less GOST-compliant when using a mixed suite than when using a suite that has no GOST features. But your point is valid, and can be taken to imply that policies which disallow valid combinations of parameters are to be avoided, if a server selects a combination from the choices offered by the client, the client SHOULD or MUST accept that combination, or else why were the choices in question offered by the client? So a key question is whether policies that rule out various corners of the product space are legitimately required??? -- Viktor. From nobody Mon Apr 13 17:46: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 8C8BE1A8758 for ; Mon, 13 Apr 2015 17:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 3-y7BkupvbPp for ; Mon, 13 Apr 2015 17:46:08 -0700 (PDT) Received: from mail-vn0-f48.google.com (mail-vn0-f48.google.com [209.85.216.48]) (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 1D1971A1ACA for ; Mon, 13 Apr 2015 17:46:08 -0700 (PDT) Received: by vnbf62 with SMTP id f62so25666407vnb.3 for ; Mon, 13 Apr 2015 17:46:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zh+1zXN0SSfMleeTCSjJOBcr9gawYpUVs4qLp911ghQ=; b=UTwijrh8bFhQUqWRYxQsUj3UOl12uG09awS2ve6O3OIUPn26BRYmVBIwlVNrrlj7Jd Z9IdfImhvwKnDTfxG62f2fOgTflb1LnKADvskHHwKJEfUSFUs31ypDh9vEoAr5e6oQaE 977bdmRn1vfUAqgKNipygegycIRmtpjzWjVG3cRgUnIHGtgo18228HmkoKQYuGG0Xxu+ AKahOwEiMgf0zpgtzjxoH19/z1yI4B1yl0Ie8D5JAgNW9r8VHfnmH1ePPKjf1M29eIi3 4JabPguW6/3DT9QI3WZrTprAMavkVWHTq9Bo+HwupJjjYK5999CZlRQa49y1d28e+Fs6 RTVA== X-Gm-Message-State: ALoCoQn3gaJ9sDswK0jc5StSIlb8KgxrONG0oJbEYRhydif6VbgNeRawBCqC4BF5xjos9Schb7yL MIME-Version: 1.0 X-Received: by 10.60.160.236 with SMTP id xn12mr14372054oeb.53.1428972367053; Mon, 13 Apr 2015 17:46:07 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Mon, 13 Apr 2015 17:46:06 -0700 (PDT) In-Reply-To: <20150414003658.GB17637@mournblade.imrryr.org> References: <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <20150414003658.GB17637@mournblade.imrryr.org> Date: Mon, 13 Apr 2015 14:46:06 -1000 Message-ID: From: Brian Smith To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Ala Carte Cipher suites - 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, 14 Apr 2015 00:46:09 -0000 Viktor Dukhovni wrote: > So a key question is whether policies that rule out various corners > of the product space are legitimately required??? One example: Firefox intentionally enabled TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 without enable the the TLS_RSA_* or TLS_DHE_* variants, partly to encourage people to move away from TLS_DHE and especially TLS_RSA key exchange, and partly because of security concerns regarding TLS_DHE and TLS_RSA key exchange. It wasn't able to disable all TLS_DHE_* and TLS_RSA_* cipher suites for compatibility reasons. TLS_RSA_* cipher suites won't be allowed in TLS 1.3 and later, but I think the need to be able to support only a subset of the cross product of all options will remain going forward as attacks against current (TLS 1.3 approved) algorithms improve and as replacements for current algorithms are developed. Cheers, Brian From nobody Mon Apr 13 17:50: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 5418B1B2BA9 for ; Mon, 13 Apr 2015 17:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 Tbu1JPSWRSqR for ; Mon, 13 Apr 2015 17:50:03 -0700 (PDT) Received: from mail-vn0-f51.google.com (mail-vn0-f51.google.com [209.85.216.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 5505D1B2BA8 for ; Mon, 13 Apr 2015 17:50:03 -0700 (PDT) Received: by vnbg62 with SMTP id g62so25683021vnb.7 for ; Mon, 13 Apr 2015 17:50:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7/X1fj4dNjHphWTtw6F1+IR6OeGJ3AQTIyU2tTi/lHg=; b=DvMUtdQzPyqYO+Zk+BpEEWXiy0cm9kDEbxkh53iIAFXUQNBGSEoN0VyGnqZtySpxZ4 w8up4JtczIeQvqBvV0MOwa0+z3u1/E7ERkZ6equTrt1xGhacZYRKtM9mmVVaRS7pzh9u FO2YRvw2b0BSr04Qhz3SYt6S9v7tE0AGgqvJR8c0pp4IbfJSMoaxeEQUTVgnu5k9+Fa2 yQZjNbC+xtL0cMMQOB376XArD+3x7jRbS3T4WcVvtNZCbf0yNMnOHQOb2S14+HU2507l t9Bxlh4NrmVpgAK27GVBIYliB4BcvfowK1GIGxAAET6ycEm6oD7QdsxRZDCB6PgqlUAq +2/w== X-Gm-Message-State: ALoCoQmEB83fbD71VB+TivrWPpNjkugzU2NDcR+xWV1LZ9pRtJZDjI9pRGJzEkqYIMMb6Keb/gOD MIME-Version: 1.0 X-Received: by 10.202.91.11 with SMTP id p11mr9393849oib.125.1428972602489; Mon, 13 Apr 2015 17:50:02 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Mon, 13 Apr 2015 17:50:02 -0700 (PDT) In-Reply-To: References: <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <20150414003658.GB17637@mournblade.imrryr.org> Date: Mon, 13 Apr 2015 14:50:02 -1000 Message-ID: From: Brian Smith To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Ala Carte Cipher suites - 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, 14 Apr 2015 00:50:05 -0000 Brian Smith wrote: > One example: Firefox intentionally enabled > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 without enable the the TLS_RSA_* > or TLS_DHE_* variants, partly to encourage people to move away from > TLS_DHE and especially TLS_RSA key exchange, and partly because of > security concerns regarding TLS_DHE and TLS_RSA key exchange. Also, some servers received an update that enabled only the TLS_DHE_* and TLS_RSA_* variants of those AES-GCM cipher suites, but that update was broken so that handshakes that used those cipher suites would fail. So, being able to have TLS_DHE_* and TLS_RSA_* variants of the AES-GCM cipher suites disabled while the TLS_ECDHE_* cipher suites stayed enabled has had interoperability benefits. (There is a patch available that fixes the bug in those servers, but even months later not all the servers have applied the patch.) Cheers, Brian From nobody Mon Apr 13 20:02: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 80FDA1B31CD for ; Mon, 13 Apr 2015 20:02:18 -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 dwg635Us7xYq for ; Mon, 13 Apr 2015 20:02:17 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 42FE31B31C7 for ; Mon, 13 Apr 2015 20:02:17 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 2A902F984 for ; Mon, 13 Apr 2015 23:02:14 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B8B9820088; Mon, 13 Apr 2015 22:02:13 -0500 (CDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: <20150414003658.GB17637@mournblade.imrryr.org> References: <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <20150414003658.GB17637@mournblade.imrryr.org> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 13 Apr 2015 23:02:13 -0400 Message-ID: <87oamrs98q.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Ala Carte Cipher suites - 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, 14 Apr 2015 03:02:18 -0000 On Mon 2015-04-13 20:36:58 -0400, Viktor Dukhovni wrote: > So a key question is whether policies that rule out various corners > of the product space are legitimately required??? Here's one (granted, contrived) policy: * i'm willing to talk to US Government peers (they all want Suite B) and Russian Government peers (they all want GOST). so my policy is that I want either an all-GOST collection or an all-suite-B collection. a la carte would suggest that i'd be OK with GOST key agreement combined with suite B symmetric crypto, though i would not consider that OK. --dkg From nobody Mon Apr 13 20:08: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 8D9A31B320F for ; Mon, 13 Apr 2015 20:08:33 -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 3AzHLBoB4rUP for ; Mon, 13 Apr 2015 20:08:32 -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 23C0A1B320E for ; Mon, 13 Apr 2015 20:08:31 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 23FF128547; Tue, 14 Apr 2015 03:08:31 +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 112532853C; Tue, 14 Apr 2015 03:08:31 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 045F72026; Tue, 14 Apr 2015 03:08:31 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 13 Apr 2015 23:06:29 -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.0913.011; Mon, 13 Apr 2015 23:06:23 -0400 From: "Salz, Rich" To: Daniel Kahn Gillmor , "tls@ietf.org" Thread-Topic: [TLS] Ala Carte Cipher suites - was: DSA should die Thread-Index: AQHQbatXX8opwuFX2UyJqmUeOB4HcZ08TnqAgAAJxgCAD2udgIAADY4AgAAVzoCAABa5AIAAKJWA//+9/pA= Date: Tue, 14 Apr 2015 03:06:23 +0000 Message-ID: <298ab44f77a84adda90125cd7bb4481d@usma1ex-dag1mb2.msg.corp.akamai.com> References: <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <20150414003658.GB17637@mournblade.imrryr.org> <87oamrs98q.fsf@alice.fifthhorseman.net> In-Reply-To: <87oamrs98q.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.58.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Ala Carte Cipher suites - 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, 14 Apr 2015 03:08:33 -0000 > Here's one (granted, contrived) policy: Or, say, you're hosting those kinds of organizations. Not contrived at all. /r$ From nobody Mon Apr 13 21:01: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 E013D1B32E6 for ; Mon, 13 Apr 2015 21:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bybOtZIql-s for ; Mon, 13 Apr 2015 21:01: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 CA3201B32DF for ; Mon, 13 Apr 2015 21:01:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 564D7283031; Tue, 14 Apr 2015 04:01:06 +0000 (UTC) Date: Tue, 14 Apr 2015 04:01:06 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150414040106.GF17637@mournblade.imrryr.org> References: <551DE914.4010804@nthpermutation.com> <20150414003658.GB17637@mournblade.imrryr.org> <87oamrs98q.fsf@alice.fifthhorseman.net> <298ab44f77a84adda90125cd7bb4481d@usma1ex-dag1mb2.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <298ab44f77a84adda90125cd7bb4481d@usma1ex-dag1mb2.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die 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, 14 Apr 2015 04:01:11 -0000 On Tue, Apr 14, 2015 at 03:06:23AM +0000, Salz, Rich wrote: > > Here's one (granted, contrived) policy: > > Or, say, you're hosting those kinds of organizations. > > Not contrived at all. It suffices for clients to not offer building blocks they don't implement. If servers choose to "bundle" certain algorithms, that's fine, so long as clients don't object to what they get. Picky clients can offer a smaller cross-product. Suite-B restrictions IIRC are triggered in part by certificate content, which in turn is selected via SNI. I am sure we can find corner cases where legacy TLS implementations warts and all needed various exclusions. If TLS 1.3 clients can only express cross-product suites, servers may be able to pick up the slack as appropriate. We need to be sure that the objections are really future requirements for 1.3, rather than work-arounds for legacy 1.2 and older stacks whose defects are not expected to be carried forward into 1.3. That said, finally we're finding plausible cases in which ala carte is less flexible. Are these sufficiently compelling? -- Viktor. From nobody Mon Apr 13 21:18: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 1ECA61B3315 for ; Mon, 13 Apr 2015 21:18: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 xBNwgi70Dk0A for ; Mon, 13 Apr 2015 21:18:02 -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 10DF01B3313 for ; Mon, 13 Apr 2015 21:18:02 -0700 (PDT) Received: by qku63 with SMTP id 63so218037797qku.3 for ; Mon, 13 Apr 2015 21:18: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:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=boHVuqQMKfe6r8ufzslekvSgUnc5b4OTMHMES0ftlGs=; b=o9AFxvRqwKH/gmXwhXlPGZufPc9By9tbqFdGxvYhfbc4VREe1xMXGUXK+KF38N6Xgq xIaxKKclinJs+m58ucPPMysa11zjWqHfNX6HwgTJsr+PolaWv+jebrrPJnkvwfwhYCY/ U5QrUFhD5dqbRuQtRhU3Nr6y8lLyJEjolL6Cdp/f8E1o4U9f8cKU6byydzxuD0x6yrcG QSVqsbLBDDT9CHNiKz2yWfgHjf0sG611aEDJJnDVqcnYYEct78KBemD9FJ1SkRoH6Q+G vSLOEzZ3XsRAzjzsrgpe35knROXF9elpsNLf3LxiWkDs2eZUZehdMgpGEUW8ryaanuxU oDDg== X-Received: by 10.55.20.139 with SMTP id 11mr35707446qku.28.1428985079751; Mon, 13 Apr 2015 21:17: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 j190sm7442005qhc.33.2015.04.13.21.17.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 21:17:59 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 14 Apr 2015 00:17:57 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <20150414003658.GB17637@mournblade.imrryr.org> <87oamrs98q.fsf@alice.fifthhorseman.net> In-Reply-To: <87oamrs98q.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201504140017.57848.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Ala Carte Cipher suites - 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, 14 Apr 2015 04:18:04 -0000 On Monday, April 13, 2015 11:02:13 pm Daniel Kahn Gillmor wrote: > On Mon 2015-04-13 20:36:58 -0400, Viktor Dukhovni wrote: > > So a key question is whether policies that rule out various corners > > of the product space are legitimately required??? > > Here's one (granted, contrived) policy: > > * i'm willing to talk to US Government peers (they all want Suite B) > and Russian Government peers (they all want GOST). so my policy is > that I want either an all-GOST collection or an all-suite-B > collection. a la carte would suggest that i'd be OK with GOST key > agreement combined with suite B symmetric crypto, though i would not > consider that OK. This scenario would be better served by a new extension that requests enforcement of specific sets of capabilities. The new proposals would make more unusual combinations negotiable, yes, but we are already in a situation where stuff from one can get negotiated in another. (e.g. authentication) So long as things are properly configured and prioritized, this shouldn't be an issue. (e.g. prioritize all of set A before all of set B at both endpoints, and ensure both sets are complete) Dave From nobody Mon Apr 13 22:46: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 401D11B33D3 for ; Mon, 13 Apr 2015 22:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rtWaUHf3ED_L for ; Mon, 13 Apr 2015 22:46:11 -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 3D4B01B33D2 for ; Mon, 13 Apr 2015 22:46:09 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 0E9B4402B; Tue, 14 Apr 2015 08:46:06 +0300 (EEST) Date: Tue, 14 Apr 2015 08:46:06 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150414054606.GA7053@LK-Perkele-VII> References: <20150412165542.GA19481@LK-Perkele-VII> <20150413181144.GA720@LK-Perkele-VII> <20150413191733.GB1016@LK-Perkele-VII> <20150413194605.GA1377@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: Tue, 14 Apr 2015 05:46:14 -0000 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). And furthermore, I don't think it is worth the trouble to introduce a different kind of handshake for 0RTT case. I think the idea was (for non-resumption) to derive the 0RTT key from DH result of client exchange key[1] (possibly with PSK) and cached medium- term server key. For resumption, one could derive the 0RTT key from resumption PMS. The trouble with actual session resumption attempts comes from the fact that these derive different keys (and at least in threat models I use, one can't assume key wrapping works). [1] To prevent that "replay and connect" attack mentioned previously, either this has to be the actual client exchange key (there can be only one), key exchange gets complicated since there is now a conditional input or server can't roll its keys properly. -Ilari From nobody Mon Apr 13 22: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 CCF801B33DB for ; Mon, 13 Apr 2015 22:49:08 -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 QU_7Y400cBSV for ; Mon, 13 Apr 2015 22:49:06 -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 5A7DA1B33DA for ; Mon, 13 Apr 2015 22:49:06 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 177F3699E1; Tue, 14 Apr 2015 08:49:04 +0300 (EEST) Date: Tue, 14 Apr 2015 08:49:03 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20150414054903.GA7186@LK-Perkele-VII> References: <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> <201504131325.20590.davemgarrett@gmail.com> <871tjoue8v.fsf@alice.fifthhorseman.net> <87vbgzubj6.fsf@alice.fifthhorseman.net> <20150413185505.GA1016@LK-Perkele-VII> <87mw2bu596.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87mw2bu596.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - 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, 14 Apr 2015 05:49:08 -0000 On Mon, Apr 13, 2015 at 04:45:25PM -0400, Daniel Kahn Gillmor wrote: > On Mon 2015-04-13 14:55:05 -0400, Ilari Liusvaara wrote: > > On Mon, Apr 13, 2015 at 02:29:49PM -0400, Daniel Kahn Gillmor wrote: > > > >> What do you think an implementation should do when a peer tries to > >> negotiate the combination above? Require an RSA-PSS signature from the > >> server over some material derived in part from the PSK key agreement > >> mechanism? > > > > To me it seems like that combo is quite insecure, unless one handles it as > > a special case (in which case it is just equivalent to PSK in security, > > just wastes time with a certificate). > > Can you explain why it's "quite insecure"? > > It doesn't seem any worse than normal (non-DHE) PSK other than the cost > of signing and verifying. I suppose that it also proves that an > attacker has access to both the PSK and the secret key material > belonging to the cert. If it is really PSK with RSA-PSS, then it is semi-OK (but see below). The problem here is: - If PSK is considered authentication algorithm, then pure PSK has NULL key agreement. Which is quite dangerous with any authentication that can't provode key material (like any signature algorithm). - If PSK is considered key agreement algorithm, then what is DHE-PSK (since DHE is key agreement). > So, for example, you could give a dozen clients the same PSK (maybe to > provide them with indistinguishability from each other to a network > observer?), but clients that want to be sure they're talking to the > server (instead of each other) can rely on the server's cert. Due to how key derivation works with pure PSK, the clients can MITM each other. And if it is supposed to be DHE-PSK+RSA-PSS, wouldn't something like using HMAC for client auth work? > > As list, the key exchange methods TLS v1.2 actually supports (after merging > > some non-significant distinctions) are: > > - RSA [going away] > > - RSA_EXPORT [you have deimplemented this already, right?] > > - DH_CERT [going away] > > - DHE_CERT [supported] > > - DHE_ANON [???] > > - KRB5 [going away] > > - PSK [???] > > - DHE_PSK [???] > > - RSA_PSK [going away] > > - SRP [???] > > - SRP_CERT [???] > > I think this list mixes up key exchange with authentication, which was > what Dave was trying to tease apart. For key exchange, there is no > difference between DHE_CERT and DHE_ANON and DHE_PSK -- they're all DHE. > the ANON/CERT/PSK parts would be negotiated separately in the > authentication side of things (via the signature_algorithms extension). TLS v1.2 also has PSK identity hint, in which server first gives a hint before client selects the final identity (which obviously is 2RTT process). To me it seems (DHE-)PSK is quite special. > (And if we're using supported_groups, the distinctions between different > flavors of DHE (FFDHE2048, ECDHEP256, ECDHEX25519, etc) are hardly > non-significant, but i guess that's a slightly different discussion.) What would the difference from TLS standpoint be (apart from some keysize parameters)? -Ilari From nobody Mon Apr 13 23: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 83D5D1B33FB for ; Mon, 13 Apr 2015 23:03: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 eZ45XcWHvK8a for ; Mon, 13 Apr 2015 23:03:33 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::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 DE2D01B33F9 for ; Mon, 13 Apr 2015 23:03:32 -0700 (PDT) Received: by wgso17 with SMTP id o17so103534984wgs.1 for ; Mon, 13 Apr 2015 23:03:31 -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=LodH8Wyu4hBhhDCF1G2oweA5utBeBGE721MS/Gy3xT4=; b=BjvCRwnI34kJogHIQVwqrnPBNFnWKO1opFBumH67CMBEL9z8rgHoOHnJXU0g93ujne JLlVdpp89pdUpOAsNfRsGddU2szdwIc8QrUxFkMFZSLbc9UoXZcIROnmvzMsPFKynyBG wQImzxX1+MBhX0uhKfmxh9Z03AEi7ybtVjaM2OMpv7rNjyABOdVjrySaFMpEO3mDwSES PsLmHYedm5352BbV62Jr0Er89s1QvzekOp6gEe1z5X70NCD9MoGzA2KSCxtazyHwVk3p da/NpqAzjvPHEpUilnomv++E4wJU8Gvnd6HFfO+XkcjQRcmNseLX69LiTrOULiM2hsnh uhlQ== X-Received: by 10.181.29.36 with SMTP id jt4mr11251907wid.21.1428991411712; Mon, 13 Apr 2015 23:03:31 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([176.12.143.32]) by mx.google.com with ESMTPSA id mc20sm1191279wic.15.2015.04.13.23.03.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Apr 2015 23:03:30 -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: <87oamrs98q.fsf@alice.fifthhorseman.net> Date: Tue, 14 Apr 2015 09:03:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6CF84798-4553-493B-9B6A-899336090D5A@gmail.com> References: <201504021257.09955.davemgarrett@gmail.com> <551DE914.4010804@nthpermutation.com> <20150414003658.GB17637@mournblade.imrryr.org> <87oamrs98q.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Ala Carte Cipher suites - 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, 14 Apr 2015 06:03:34 -0000 > On Apr 14, 2015, at 6:02 AM, Daniel Kahn Gillmor = wrote: >=20 > On Mon 2015-04-13 20:36:58 -0400, Viktor Dukhovni wrote: >> So a key question is whether policies that rule out various corners >> of the product space are legitimately required??? >=20 > Here's one (granted, contrived) policy: >=20 > * i'm willing to talk to US Government peers (they all want Suite B) > and Russian Government peers (they all want GOST). so my policy is > that I want either an all-GOST collection or an all-suite-B > collection. a la carte would suggest that i'd be OK with GOST key > agreement combined with suite B symmetric crypto, though i would not > consider that OK. >=20 IKE has a complex structure of multiple =E2=80=9Cproposals=E2=80=9D, = each a collection of several =E2=80=9Ctransforms=E2=80=9D, where a = =E2=80=9Ctransform=E2=80=9D is one algorithm and you can have more than = one algorithm of the same type in a single proposal, so you could have = for example: - proposal #1: GOST signature, GOST DH group, GOST encryption, GOST MAC - proposal #2: AES-128-CGC, AES-GCM-128, HMAC-SHA-1, HMAC-SHA-256, = 2048-bit DH group, P-256, RSA certificates. I haven=E2=80=99t found this construct to be particularly useful, and my = implementation only ever emits one proposal (but can be configured with = multiple algorithms). Back to TLS: Your contrived policy can be implemented in the server. = Your server (or Rich=E2=80=99s hosting) can be programmed to select only = certain combinations depending on SNI, and that does not require any = special support in the protocol. For a client it is more difficult. Do we have a use case where a client = connects to some site, and is fine with either GOST certificates and = GOST encryption, or with AES-GCM and ECDSA, but not a mix? If we accept = that such policies should be enforced by servers, I think the problem = goes away. Yoav From nobody Tue Apr 14 11: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 055B71A1B48 for ; Tue, 14 Apr 2015 11:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZgrPiEFhpxj for ; Tue, 14 Apr 2015 11:04:31 -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 0EFB21A1ABC for ; Tue, 14 Apr 2015 11:04:30 -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 t3EI4Tw4009842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 14 Apr 2015 14:04:29 -0400 Received: from pintsize.usersys.redhat.com (dhcp-0-236.brq.redhat.com [10.34.0.236]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3EI4Qvk028498 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2015 14:04:28 -0400 From: Hubert Kario To: tls@ietf.org, mrex@sap.com Date: Tue, 14 Apr 2015 20:04:20 +0200 Message-ID: <16060812.rZlCWar0gQ@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.4 (Linux/3.19.3-100.fc20.x86_64; KDE/4.14.6; x86_64; ; ) In-Reply-To: <20150413223049.63EE81B281@ld9781.wdf.sap.corp> References: <20150413223049.63EE81B281@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1524492.FzM0Kf4g20"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2015 18:04:33 -0000 --nextPart1524492.FzM0Kf4g20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 14 April 2015 00:30:49 Martin Rex wrote: > Andrei Popov wrote: > > Yes, this is an example of NPN legacy in ALPN, > > and yes there is some API pain involved. >=20 > I'm not trying to break things and I'm not advocating to change > any existing APIs. But I've just been asked for support of this > and am looking into newly implementing it, and I would appreciate > if we (i.e. the IETF TLS working group) could restrict the TLS ALPN I= Ds > at least by banning the character 0 from TLS ALPN ID registrations no= w. >=20 > Being allowed to reject embedded NULs would facilitate some aspects > (save me a few lines of code). >=20 > I can live with UTF8. >=20 > A single reserved character (such as colon ':' or pipe '|' or comma '= ,') > would allow me to avoid a character escaping scheme for the API I'm > trying to create, but I could live with this issue being a proprietar= y > thing. You don't prevent CVE-2009-2408-like exploits by banning nulls in field= s. If anything, the RFC could be updated to explicitly state that implemen= tations=20 MUST be able to handle the case where the IDs include null bytes. But this is the case for basically all fields both in TLS and X509... =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 --nextPart1524492.FzM0Kf4g20 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 iQIcBAABCgAGBQJVLVaqAAoJEJKo0bgB0vX1siUP/3eZOnDqK6lbJQExjlEreDdi A+yK/ePOllJY3C0Z+SzzCXCcgv9SgLTpl2mY7mgJhdVnPXK4/xl+gSx+SqgcUk8B 87XoLj4QQlF2C+u/QnPHnZC1RU+6XME8mUqNplZ52zdSPJsyUyTeT2+/J4hS4nRu 75hjpBioiEZirylreLNGx9LOXEYzLxxucNGouPVFUCnA5wGa1UzU3+RDGKVgVJEM iF1I/Qj4i3qhBOv2G/V05o1bvGTH/afxipDnGuMepM8K5NV6Pds0zj2KNTVuWRLb tXHgSwxwSZPr+kLr/KhVH3tAUmBKj2fj8MUr1UiwgBaP2h/eNt1BBJHxrGFAAJsk GVbygfx6evr1uKU5UI0SysToMzFlI6yT7YapscOyg07b9R0eRM5HPZfGd6DnanNk vy9lgyTI0MzUAE/BpmxOpHTE8nEYMa1tf8LW42N9hJQkcI/tFadVfvW4piAdKwIN csYK02GXXlVhHsdWbo0w5TXXibI4geZWY6kVDRh/j2RCP6MjsIY6oPAx58EV10xG zu1F8lEwqPvwwKKgWddTxz6qbKl0Y4EGsVclbob/6okouM52ccNS/GTOkytx3GIV DsNzoRNwc0llTy3j0/+smVTpNgRzRUfq06Ajr2ttuZSl+7ALIaohPlDflYMtXciF QmWwOVDaSDhARPpwT1Ie =srg7 -----END PGP SIGNATURE----- --nextPart1524492.FzM0Kf4g20-- From nobody Tue Apr 14 11:19: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 E58B71A870D for ; Tue, 14 Apr 2015 11:19:50 -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 geHOnABq24Tt for ; Tue, 14 Apr 2015 11:19:49 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::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 0BC111A86FC for ; Tue, 14 Apr 2015 11:19:49 -0700 (PDT) Received: by wgso17 with SMTP id o17so21541487wgs.1 for ; Tue, 14 Apr 2015 11:19:47 -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=2+Hv+YuonoPl+HuI8Ahkc8eO2vTy7nVOLsdRCPtwSeM=; b=GBAXAIWHAfH6hvz/oCstq8BcZCQqVM2nklyuHV0P8072kGjkQmg9QtoJZSk4EXKMwW 5t7I/KJ9k/qI/Dj764LIPrVH5vKBMJo2oLqlx2tbzDv61ZcG8Uwo/4MSP+kEZSSonGdA xQn2VqQYcXd8oAamLs94tuiiAOwHmq6uOP+1Zw02Dt06Vo5uJxaF6PiVPOiiaQFcPZ6R j+rAb5gOg4SgvoXUbtutP1C02MR8gUlWxJkIDUMrc80IXOhcanhb8GgrtNBl7I3KPTnr Ci1E8MQ8ITfWgXwWQpK9wkN9PWiW8lQ9S/lwtpt/dM4Jey310/D8/mAIp9+VBwTj6Odj zb/g== MIME-Version: 1.0 X-Received: by 10.180.82.97 with SMTP id h1mr21784735wiy.26.1429035587842; Tue, 14 Apr 2015 11:19:47 -0700 (PDT) Received: by 10.194.136.233 with HTTP; Tue, 14 Apr 2015 11:19:47 -0700 (PDT) Received: by 10.194.136.233 with HTTP; Tue, 14 Apr 2015 11:19:47 -0700 (PDT) In-Reply-To: <16060812.rZlCWar0gQ@pintsize.usersys.redhat.com> References: <20150413223049.63EE81B281@ld9781.wdf.sap.corp> <16060812.rZlCWar0gQ@pintsize.usersys.redhat.com> Date: Tue, 14 Apr 2015 11:19:47 -0700 Message-ID: From: Watson Ladd To: Hubert Kario Content-Type: multipart/alternative; boundary=f46d0442673095b9c10513b3465f Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2015 18:19:51 -0000 --f46d0442673095b9c10513b3465f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Apr 14, 2015 11:04 AM, "Hubert Kario" wrote: > > On Tuesday 14 April 2015 00:30:49 Martin Rex wrote: > > Andrei Popov wrote: > > > Yes, this is an example of NPN legacy in ALPN, > > > and yes there is some API pain involved. > > > > I'm not trying to break things and I'm not advocating to change > > any existing APIs. But I've just been asked for support of this > > and am looking into newly implementing it, and I would appreciate > > if we (i.e. the IETF TLS working group) could restrict the TLS ALPN IDs > > at least by banning the character 0 from TLS ALPN ID registrations now. > > > > Being allowed to reject embedded NULs would facilitate some aspects > > (save me a few lines of code). > > > > I can live with UTF8. > > > > A single reserved character (such as colon ':' or pipe '|' or comma ','= ) > > would allow me to avoid a character escaping scheme for the API I'm > > trying to create, but I could live with this issue being a proprietary > > thing. > > You don't prevent CVE-2009-2408-like exploits by banning nulls in fields. > > If anything, the RFC could be updated to explicitly state that implementations > MUST be able to handle the case where the IDs include null bytes. > > But this is the case for basically all fields both in TLS and X509... And this has been a continuous source of pain, leading to exploits. Moreso on the X.509 side. Sincerely, Watson Ladd > -- > 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 > --f46d0442673095b9c10513b3465f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 14, 2015 11:04 AM, "Hubert Kario" <hkario@redhat.com> wrote:
>
> On Tuesday 14 April 2015 00:30:49 Martin Rex wrote:
> > Andrei Popov wrote:
> > > Yes, this is an example of NPN legacy in ALPN,
> > > and yes there is some API pain involved.
> >
> > I'm not trying to break things and I'm not advocating to = change
> > any existing APIs.=C2=A0 But I've just been asked for support= of this
> > and am looking into newly implementing it, and I would appreciate=
> > if we (i.e. the IETF TLS working group) could restrict the TLS AL= PN IDs
> > at least by banning the character 0 from TLS ALPN ID registration= s now.
> >
> > Being allowed to reject embedded NULs would facilitate some aspec= ts
> > (save me a few lines of code).
> >
> > I can live with UTF8.
> >
> > A single reserved character (such as colon ':' or pipe &#= 39;|' or comma ',')
> > would allow me to avoid a character escaping scheme for the API I= 'm
> > trying to create, but I could live with this issue being a propri= etary
> > thing.
>
> You don't prevent CVE-2009-2408-like exploits by banning nulls in = fields.
>
> If anything, the RFC could be updated to explicitly state that impleme= ntations
> MUST be able to handle the case where the IDs include null bytes.
>
> But this is the case for basically all fields both in TLS and X509...<= /p>

And this has been a continuous source of pain, leading to ex= ploits. Moreso on the X.509 side.

Sincerely,
Watson Ladd
> --
> 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 Republ= ic
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--f46d0442673095b9c10513b3465f-- From nobody Tue Apr 14 11:23: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 342061A90AB for ; Mon, 13 Apr 2015 04:20:12 -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 VTX3cBfIHSuq for ; Mon, 13 Apr 2015 04:20:06 -0700 (PDT) Received: from mail-vn0-x230.google.com (mail-vn0-x230.google.com [IPv6:2607:f8b0:400c:c0f::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 D13371A90B6 for ; Mon, 13 Apr 2015 04:20:05 -0700 (PDT) Received: by vnbg7 with SMTP id g7so18459706vnb.10 for ; Mon, 13 Apr 2015 04:20:05 -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=wzi3KxEZJ3HEpbnyaYqIAj+GFzKhIs5t8F0O7EWv+CM=; b=aGV4Q5sXUCvwhnfYdMUgiB7uSYZdMqlluv9oHkZpsR/bAVgDVfI7GFAId/EXioIqIp urIMR8+dGqNbl56ZRQntSuMRBa4H8j36A1vXdYwpyuwdJP/IME9SIJWYWNZ6AnkhpfaS j4zeokgdo2ARxBOMg2RIb0RixJhS5mTYTITTOMacFiYOrGK/CGfsBlpB7o3Yt0tsMhjG Catwd5ZK2UOJoHtg5j5ogfDOVOR0PuEYu0rPurYJceZii4r4sQI2NbvDZHV2evEZR7Gt n0PBUluKl2M73iNk9qGZnZxSg+RCOdw5P3Se9psxjqzZ17FeJ0zBFVbxysg58NYVTW4V fI1g== 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=wzi3KxEZJ3HEpbnyaYqIAj+GFzKhIs5t8F0O7EWv+CM=; b=DAYbJY3celbfOubrHPVr/AuJ1w8z0olLY3WT0DdVdJBNa6QOX0Qw3PDuEUpcLmwwRl brwO99N11gl2yU7UVezNhGuIKh3a+K5NiIfRBCuCxkAeZJ+l5EN6SYpYER/Nwoz6mYS6 4Zl9j9HEgIcQA1P8/axtI+XX+3VSwwqvaJ/r/OqOO+0+WZq48ft1XQr33cS+W+4Ie5NG tAcM+apZGYSmR6hPJDjm0SCs3IIzZNw48La+PuUu9Im/P6YPFjqj2T1BGf5KJ+TSKJws Uaa/Y2o7Zn2yxzl/WQGB1U9hn6tX8kHyDhU9KSJ5PKcr7KyllK7tKzmS83hm7EZFPRDp 7pZQ== X-Gm-Message-State: ALoCoQks7h9UHlV03NraMOguuIj32yt3K8EQ+v6a2CWt+LVRhItz85KHdD1vNaONrxFcYH6Nh/3h X-Received: by 10.52.178.170 with SMTP id cz10mr17972236vdc.1.1428924005024; Mon, 13 Apr 2015 04:20:05 -0700 (PDT) MIME-Version: 1.0 References: <147002D3-4F04-4895-8826-C9FE3664D6BA@gmail.com> In-Reply-To: <147002D3-4F04-4895-8826-C9FE3664D6BA@gmail.com> From: Emilia Kasper Date: Mon, 13 Apr 2015 11:20:04 +0000 Message-ID: To: Karthikeyan Bhargavan , Martin Thomson Content-Type: multipart/alternative; boundary=bcaec5196461bb210a0513994b75 Archived-At: X-Mailman-Approved-At: Tue, 14 Apr 2015 11:23:14 -0700 Cc: "tls@ietf.org" , Bill Cox Subject: Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Apr 2015 11:20:12 -0000 --bcaec5196461bb210a0513994b75 Content-Type: text/plain; charset=UTF-8 On Mon, 13 Apr 2015 at 10:26 Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > How about the following: > 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 fall back to a full handshake by > sending a ServerHello that rejects session resumption and offers a > new session. > Falling back cannot always be indicated in the ServerHello. In particular, if the client is resuming with a ticket and without a session ID, then there is nothing special in the ServerHello that says "resuming/not resuming". So I think that David's wording is as precise as you can/need to be there. Emilia > > On 11 Apr 2015, at 03:42, Martin Thomson wrote: > > > On 10 April 2015 at 16:25, David Benjamin wrote: > >>> 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 reject the session and fall back to a full handshake. > > > > WFM. > > > > ... MUST reject the session *resumption* and fall back ... > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > --bcaec5196461bb210a0513994b75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, 13 Apr 2015 at = 10:26 Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
How about the following:
=C2=A0 =C2=A0 =C2=A0 If the original session did not use an extended master= secret but
=C2=A0 =C2=A0 =C2=A0 the new ClientHello does contain the "extended_ma= ster_secret"
=C2=A0 =C2=A0 =C2=A0 extension, the server MUST fall back to a full handsha= ke by
=C2=A0 =C2=A0 =C2=A0 sending a ServerHello that rejects session resumption = and offers a
=C2=A0 =C2=A0 =C2=A0 new session.

Falli= ng back cannot always be indicated in the ServerHello. In particular, if th= e client is resuming with a ticket and without a session ID, then there is = nothing special in the ServerHello that says "resuming/not resuming&qu= ot;.

So I think that David's wording is as pre= cise as you can/need to be there.

Emilia



On 11 Apr 2015, at 03:42, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 10 April 2015 at 16:25, David Benjamin <davidben@chromium.org> wrote:
>>> 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 reject the session and fall back to a full handshake.
>
> WFM.
>
> ... MUST reject the session *resumption* and fall back ...
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--bcaec5196461bb210a0513994b75-- From nobody Tue Apr 14 11:23: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 0DC001AC437; Mon, 13 Apr 2015 15:06:21 -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 WIUW6cwBXlar; Mon, 13 Apr 2015 15:06:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACFC1A924B; Mon, 13 Apr 2015 15:06:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150413220606.32229.85744.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 15:06:06 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 14 Apr 2015 11:23:14 -0700 Subject: [TLS] ID Tracker State Update Notice: 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: Mon, 13 Apr 2015 22:06:21 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ From nobody Tue Apr 14 15: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 260F21B303B for ; Tue, 14 Apr 2015 15:53:35 -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 GwyUSX28l_aV for ; Tue, 14 Apr 2015 15:53:32 -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 A9F321B3038 for ; Tue, 14 Apr 2015 15:53:31 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id EDEA1449F4; Wed, 15 Apr 2015 00:53:28 +0200 (CEST) X-purgate-ID: 152705::1429052009-000007DF-37C73035/0/0 X-purgate-size: 2717 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 9C6DE43DB2; Wed, 15 Apr 2015 00:53:28 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 924711B28A; Wed, 15 Apr 2015 00:53:28 +0200 (CEST) In-Reply-To: <16060812.rZlCWar0gQ@pintsize.usersys.redhat.com> To: Hubert Kario Date: Wed, 15 Apr 2015 00:53:28 +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: <20150414225328.924711B28A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned 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, 14 Apr 2015 22:53:35 -0000 Hubert Kario wrote: > Martin Rex wrote: >> Andrei Popov wrote: >>> >>> Yes, this is an example of NPN legacy in ALPN, >>> and yes there is some API pain involved. >> >> I'm not trying to break things and I'm not advocating to change >> any existing APIs. But I've just been asked for support of this >> and am looking into newly implementing it, and I would appreciate >> if we (i.e. the IETF TLS working group) could restrict the TLS ALPN IDs >> at least by banning the character 0 from TLS ALPN ID registrations now. >> >> Being allowed to reject embedded NULs would facilitate some aspects >> (save me a few lines of code). >> >> I can live with UTF8. >> >> A single reserved character (such as colon ':' or pipe '|' or comma ',') >> would allow me to avoid a character escaping scheme for the API I'm >> trying to create, but I could live with this issue being a proprietary >> thing. > > You don't prevent CVE-2009-2408-like exploits by banning nulls in fields. I was talking about *API* stuff, not about wire-level encoding and TLS protocol stuff. To be able to support the currently (unreasonably broad) set of what TLS ALPN IDs may be registered, you would have to create an API where the caller would have to supply the *input* (from application to TLS implementation) as an array-of-blobs, i.e. explicit length fields A concatenated flat-string representation would be *MUCH* simpler and nicer at the API level. > > If anything, the RFC could be updated to explicitly state that > implementations MUST be able to handle the case where the IDs > include null bytes. That would be insane. If anything, an implementation receiving a ALPN ID with embedded NUL characters should drop and ignore that bogus ALPN ID. > > But this is the case for basically all fields both in TLS and X509... That applies only to fields with unreasonable definitions. Look at the TLS Server Name Indication extension: https://tools.ietf.org/html/rfc6066#section-3 this has a reasonable definition for the "host_name(0)" is limited to "fully qualified DNS hostname", which means that not just embedded NULs are prohibited (and can be immediately dropped and ignored by the TLS ClientHello PDU parser), but also "host_name(0)" > 255 chars and there are several other constraints on DNS hostnames. Robust and conservative design means that you check and skip invalid data as early as possible, to limit the attack surface. With how TLS ALPN is currently defined, you can *ALWAYS* target the application on top of TLS with attacks, because the TLS implementation is not currently allowed to weed out obvious crap right away. -Martin From nobody Tue Apr 14 18:53: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 A3FE01B3095 for ; Tue, 14 Apr 2015 18:53:17 -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 dtkVMq8fEwKb for ; Tue, 14 Apr 2015 18:53:16 -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 B60DB1B3094 for ; Tue, 14 Apr 2015 18:53:15 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 49053445D8; Wed, 15 Apr 2015 03:53:13 +0200 (CEST) X-purgate-ID: 152705::1429062793-000007DF-8D45F0EC/0/0 X-purgate-size: 849 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3D16842E3A; Wed, 15 Apr 2015 03:53:13 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 357751B28A; Wed, 15 Apr 2015 03:53:13 +0200 (CEST) In-Reply-To: <147002D3-4F04-4895-8826-C9FE3664D6BA@gmail.com> To: Karthikeyan Bhargavan Date: Wed, 15 Apr 2015 03:53: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: <20150415015313.357751B28A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" , Bill Cox Subject: Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption 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, 15 Apr 2015 01:53:17 -0000 Karthikeyan Bhargavan wrote: > How about the following: > 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 fall back to a full handshake by > sending a ServerHello that rejects session resumption and offers a > new session. Too complicated for my taste. I do not see a need for words like fallback and reject, and these actually do not exist in the TLS protocol. 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 perform a full handshake to negotiate a new session (i.e. the server MUST NOT perform an abbreviated handshake aka session resume). -Martin From nobody Tue Apr 14 23: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 C03051B3186 for ; Tue, 14 Apr 2015 23:15:14 -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 qE3LQZo5aABJ for ; Tue, 14 Apr 2015 23:15:13 -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 C9FB81B3184 for ; Tue, 14 Apr 2015 23:15:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,580,1422918000"; d="scan'208";a="135014066" Received: from 166.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.166]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 15 Apr 2015 08:15:10 +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: <20150415015313.357751B28A@ld9781.wdf.sap.corp> Date: Wed, 15 Apr 2015 08:15:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <53BB8A96-8CFE-4275-9562-336D60B567B3@gmail.com> References: <20150415015313.357751B28A@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" , Bill Cox Subject: Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 06:15:14 -0000 I like Martin=92s text, and have edited it to the following: 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 continue the abbreviated handshake. Instead, it SHOULD perform a full handshake to negotiate a new = session. If this looks acceptable, I=92ll put out a new version of the draft = today. -K. On 15 Apr 2015, at 03:53, Martin Rex wrote: > Karthikeyan Bhargavan wrote: >> How about the following: >> 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 fall back to a full handshake by >> sending a ServerHello that rejects session resumption and offers = a >> new session. >=20 > Too complicated for my taste. I do not see a need for words like > fallback and reject, and these actually do not exist in the TLS = protocol. >=20 >=20 > 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 perform a full handshake to negotiate > a new session (i.e. the server MUST NOT perform an abbreviated > handshake aka session resume). >=20 >=20 > -Martin From nobody Wed Apr 15 00:38: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 5D7B81B3259 for ; Wed, 15 Apr 2015 00:38:31 -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 Fqzq_I-tpTCE for ; Wed, 15 Apr 2015 00:38:29 -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 0FD571B3245 for ; Wed, 15 Apr 2015 00:38:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,581,1422918000"; d="scan'208";a="135047691" Received: from wifi-auth-191208.inria.fr ([128.93.191.208]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 15 Apr 2015 09:38:21 +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: <53BB8A96-8CFE-4275-9562-336D60B567B3@gmail.com> Date: Wed, 15 Apr 2015 09:38:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56BA5F9C-E1CE-402F-831C-0D3AF3D336AE@gmail.com> References: <20150415015313.357751B28A@ld9781.wdf.sap.corp> <53BB8A96-8CFE-4275-9562-336D60B567B3@gmail.com> To: Karthikeyan Bhargavan X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" , Bill Cox Subject: Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 07:38:31 -0000 I guess my question is whether =93SHOULD perform a full handshake=94 is = strong enough, leaving the server the option of aborting the handshake, or is MUST = preferable as a clearer indication to implementers? On 15 Apr 2015, at 08:15, Karthikeyan Bhargavan = wrote: > I like Martin=92s text, and have edited it to the following: >=20 > 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 continue the abbreviated handshake. > Instead, it SHOULD perform a full handshake to negotiate a new = session. >=20 > If this looks acceptable, I=92ll put out a new version of the draft = today. >=20 > -K. >=20 > On 15 Apr 2015, at 03:53, Martin Rex wrote: >=20 >> Karthikeyan Bhargavan wrote: >>> How about the following: >>> 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 fall back to a full handshake by >>> sending a ServerHello that rejects session resumption and offers = a >>> new session. >>=20 >> Too complicated for my taste. I do not see a need for words like >> fallback and reject, and these actually do not exist in the TLS = protocol. >>=20 >>=20 >> 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 perform a full handshake to negotiate >> a new session (i.e. the server MUST NOT perform an abbreviated >> handshake aka session resume). >>=20 >>=20 >> -Martin >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 15 02:08: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 4C0271B339A for ; Wed, 15 Apr 2015 02:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh2G-RfJqTmm for ; Wed, 15 Apr 2015 02:08: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 D90441B339B for ; Wed, 15 Apr 2015 02:08:01 -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 2CC36330488; Wed, 15 Apr 2015 09:08:01 +0000 (UTC) Received: from pintsize.usersys.redhat.com (vpn1-7-69.ams2.redhat.com [10.36.7.69]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3F97w2M031601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2015 05:08:00 -0400 From: Hubert Kario To: mrex@sap.com Date: Wed, 15 Apr 2015 11:07:51 +0200 Message-ID: <1531163.KgFZIyykO4@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.4 (Linux/3.19.3-100.fc20.x86_64; KDE/4.14.6; x86_64; ; ) In-Reply-To: <20150414225328.924711B28A@ld9781.wdf.sap.corp> References: <20150414225328.924711B28A@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4865205.j5dlBgs6D6"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 09:08:04 -0000 --nextPart4865205.j5dlBgs6D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 15 April 2015 00:53:28 Martin Rex wrote: > Hubert Kario wrote: > > Martin Rex wrote: > >> Andrei Popov wrote: > >>> Yes, this is an example of NPN legacy in ALPN, > >>> and yes there is some API pain involved. > >>=20 > >> I'm not trying to break things and I'm not advocating to change > >> any existing APIs. But I've just been asked for support of this > >> and am looking into newly implementing it, and I would appreciate > >> if we (i.e. the IETF TLS working group) could restrict the TLS ALP= N IDs > >> at least by banning the character 0 from TLS ALPN ID registrations= now. > >>=20 > >> Being allowed to reject embedded NULs would facilitate some aspect= s > >> (save me a few lines of code). > >>=20 > >> I can live with UTF8. > >>=20 > >> A single reserved character (such as colon ':' or pipe '|' or comm= a ',') > >> would allow me to avoid a character escaping scheme for the API I'= m > >> trying to create, but I could live with this issue being a proprie= tary > >> thing. > >=20 > > You don't prevent CVE-2009-2408-like exploits by banning nulls in f= ields. >=20 > I was talking about *API* stuff, not about wire-level encoding and > TLS protocol stuff. and API needs to be able to handle all the stuff that can be sent over = the=20 wire > To be able to support the currently (unreasonably broad) set of > what TLS ALPN IDs may be registered, you would have to create an > API where the caller would have to supply the *input* (from applicati= on > to TLS implementation) as an array-of-blobs, i.e. explicit length fie= lds >=20 > A concatenated flat-string representation would be *MUCH* simpler > and nicer at the API level. even in C like languages you just need memory pointer and a length valu= e, I=20 wouldn't call that, compared to just memory pointer, to be "MUCH" simpl= er the first makes buffer overruns impossible - something C like languages= could=20 use more of In some languages, like Python, you can't even have a byte array of ind= efinite=20 length, making the embedded nulls a complete non-issue =20 > > If anything, the RFC could be updated to explicitly state that > > implementations MUST be able to handle the case where the IDs > > include null bytes. >=20 > That would be insane. So current RFC is insane...? The above is just implicit, not explicit. =20 > If anything, an implementation receiving a ALPN ID with embedded > NUL characters should drop and ignore that bogus ALPN ID. >=20 > > But this is the case for basically all fields both in TLS and X509.= .. >=20 > That applies only to fields with unreasonable definitions. >=20 > Look at the TLS Server Name Indication extension: >=20 > https://tools.ietf.org/html/rfc6066#section-3 >=20 > this has a reasonable definition for the "host_name(0)" is limited to= > "fully qualified DNS hostname", which means that not just embedded > NULs are prohibited (and can be immediately dropped and ignored by th= e TLS > ClientHello PDU parser), but also "host_name(0)" > 255 chars and > there are several other constraints on DNS hostnames. that's just in relation to host_name, not to SNI or TLS in general > Robust and conservative design means that you check and skip invalid = data > as early as possible, to limit the attack surface. With how TLS ALPN= > is currently defined, you can *ALWAYS* target the application on top > of TLS with attacks, because the TLS implementation is not currently > allowed to weed out obvious crap right away. It's true, it exposes the app on top. On the other hand, the values already passed between peers are non null= =20 terminated, so the API has to support non-null terminated strings anywa= y. ...please tell me you're not null terminating the ID before passing the= m to=20 application.... =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 --nextPart4865205.j5dlBgs6D6 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 iQIcBAABCgAGBQJVLiptAAoJEJKo0bgB0vX1NUgQAIhd4BWh8Skb3ZDvL8DiAgnD rqe5MszDqmOd0Nclj56a7Uy3g1zzxVSLCKTGdsWEY+3c8D+JyXwEpw6dSeEUPSoQ pvHSJFtyxaceY5aboUeet3jBKW/YaPT8XJbcQKHA/C5BpHdBTg3rLOaMM7SUeoJf s4ZaZWLWP/PUYoIGSxJvdSxDJU+lyWLe7umUdFPFA6RUdQpe/7X95D1Q9bPQT2v+ nlJ70pU+7fQbm5osPLFNyKWFjRpgG8pjvU5LM1nPXcpls8+QBbqS3t19HulM+H61 BOVIW9It/a8SG5E3NS7BrnlBLBTRgxzo2Dpf5zzaaQntUNgdSIaH1IcxD/KWGeyC //AReh6lza8+LlAtPxI+bY5H6WTo8dYzjdw2YY/QWf9fV2iEdjQ0Dr3hujavSmgh gCDnsh06px8ktECgBYmEnW6OBYqXnzkWXLRO/v2ZILEQK+wdm0WQLuc/pMGCTpIo HiXj2aRoaJgaNZ/S8Vz4SJMLTMOekKrltZhQsLvmSph8hFTBh8K/KSI61e5WY+J6 lYonD5hZvhcQmimMLNeXNm2Gv81O5M7NfLhksxSTwDPpYdeQdM7e+RB8eZIwcJoB NFG50mf6QVO+LgGPJWYZppNMSA0oU/ElwT5UlfYXKMiSrQw3xa9SfTe2+jSzBcvS /BlmoA2W5Sh1opScLqFj =V8np -----END PGP SIGNATURE----- --nextPart4865205.j5dlBgs6D6-- From nobody Wed Apr 15 07: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 EB9C81B356E for ; Wed, 15 Apr 2015 07:19: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 NoX_EGLkRtnX for ; Wed, 15 Apr 2015 07:18:59 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::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 6FA811B3567 for ; Wed, 15 Apr 2015 07:18:59 -0700 (PDT) Received: by lagv1 with SMTP id v1so33849640lag.3 for ; Wed, 15 Apr 2015 07:18:58 -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:cc:content-type; bh=BBmbMTBGKDRxQa/ZPPb0eDV1m+jXd8a/N2AI42OAdcU=; b=ADzPpSamMnTVWp7oNQDPDKorEvXbji3bXQOJ0KalVxwsCn8Psyc+5Euc/TK99T7CKD IhiuUq5D5TE+3TxRg3zCcuFW5eXHA/1sntRMpPsaB+0Xn6WxzKLrfjNYR1JTO+bzrtSP cHTMnmqNFK+MtPyyz+An/OONuvXjwqdFGHhAcFHnyIlK/L7FoiGPJCvv+Epp2NstfKat VYbjU25g4u7L2olUJxOY10CqlzIMmIPFzl8EQN1afysW8ZdWBxY+8Zl4MAl7CAYe6MJ8 2DQTdnTx1xZvTRR9yLsnAFtKy4voPeyVbH0zRahVwXqFuF13Ms5ytD2Q59fr4W3L8Ieb niuw== X-Received: by 10.112.242.8 with SMTP id wm8mr23772201lbc.69.1429107537942; Wed, 15 Apr 2015 07:18:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.172.196 with HTTP; Wed, 15 Apr 2015 07:18:17 -0700 (PDT) From: Santiago Zanella Date: Wed, 15 Apr 2015 16:18:17 +0200 Message-ID: To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 14:19:01 -0000 Some hard data that can be of interest. A current full IPv4 survey of groups used for FFDHE shows that the 2048-bit MODP group from RFC3526 is the 5th most common (and the most common with a modulus longer than 1024 bits): roughly 7.8% of over 10M hosts use it. For comparison, 8.7% use IKE 1024-bit MODP group. The other MODP groups in RFC3526 are used only marginally. So, there is a significant number of hosts using IKE 2048-bit MODP group, which is as strong as the weakest group in the draft. That said, I fully agree with the reasons given in the draft for not naming any existing groups*, but lack of common use should not be one of them. * https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08#section-9.5 --Santiago From nobody Wed Apr 15 07:43: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 BF7101B35C2 for ; Wed, 15 Apr 2015 07:43:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 L7dJZrFylMCE for ; Wed, 15 Apr 2015 07:43:36 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C331B35C1 for ; Wed, 15 Apr 2015 07:43:36 -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=1429109018; x=1460645018; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=a/cw3TyCWqZjf1TIxivENulbDnzI1a61W6PFSA2etqk=; b=my7j+r9dvYKl389XQ4h3VXCIYk1kuSP7m0NbWSZwmWtzX7bv+6wXvGhH Oa4HV757dPfg9N9JKgIBOxsrY9L1MduMRP5qBKxOulnTluNGnjagv/Ia7 YG4YJ4XuyH6aZYpW6TfPGZMgTbyBbBL04Bs+gCIGU+X3cIjd/FvUN8EuN 4=; X-IronPort-AV: E=Sophos;i="5.11,582,1422874800"; d="scan'208";a="320752162" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Apr 2015 02:43:37 +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, 16 Apr 2015 02:43:35 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 Thread-Index: AdB3io0RQkI2CK/nSDWUSCl2mNTLqw== Date: Wed, 15 Apr 2015 14:43:34 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFF967A@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] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 14:43:37 -0000 Santiago Zanella writes:=0A= =0A= >A current full IPv4 survey of groups used for FFDHE shows that the 2048-bi= t=0A= >MODP group from RFC3526 is the 5th most common (and the most common with a= =0A= >modulus longer than 1024 bits): roughly 7.8% of over 10M hosts use it. For= =0A= >comparison, 8.7% use IKE 1024-bit MODP group. The other MODP groups in=0A= >RFC3526 are used only marginally.=0A= =0A= So... if 8.7% is the most widely-used group (since you qualify the 7.8% one= =0A= with "the most common with a modulus longer than 1024 bits"), that means th= e=0A= most common group is one that the ff-dhe draft doesn't allow you to specify= ,=0A= and the most common group with a modulus longer than 1024 bits is... anothe= r=0A= one that the ff-dhe draft doesn't allow you to specify.=0A= =0A= Peter.=0A= From nobody Wed Apr 15 07:54: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 565AD1ACE74; Tue, 14 Apr 2015 15:56: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 hRNz8U02-0GY; Tue, 14 Apr 2015 15:56:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 422DA1ACC8B; Tue, 14 Apr 2015 15:56:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414225610.5642.97075.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 15:56:10 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Wed, 15 Apr 2015 07:54:05 -0700 Subject: [TLS] ID Tracker State Update Notice: 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, 14 Apr 2015 22:56:11 -0000 IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ From nobody Wed Apr 15 07:54: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 575391B3495 for ; Wed, 15 Apr 2015 06:32:01 -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 vcBwSPikcO9u for ; Wed, 15 Apr 2015 06:31:59 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 8F9581A90B4 for ; Wed, 15 Apr 2015 06:31:59 -0700 (PDT) Received: by oign205 with SMTP id n205so21966174oig.2 for ; Wed, 15 Apr 2015 06:31:59 -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=kWVRe82ncg6vBIGvKdehrnd9eKdrASSAITapnch0F3U=; b=Cf2/x23f4QG9u1yWaXV3ijHv08ni2aJs922kgBO3VsPsIKtrJ7tjolK7hwAgvh8hc3 BMkuislZkGXbiXyGsyz08xEW3dU72Av9LAPR41omp9DqcMrtOxpsZIIrR7FiNGoeWuyB G4Tx5cIzjrqlXoliOZnqjJSd01M69B/62FDEKOKW7XXgrcWMm441GCm/YNXY+znfkFGj Z60k4Lzz179zT8APfiqxeo0W+i+3lgWn4OSI6i/OA+Y8feRTnjoL7MgyGpFNNlYI9XHm stPoDo/hi8vMqhSVnQXvpYNfZVWlXxwto2u7OwjryHXs2UG4cpMq03ZQyCTtfmoQwgoO 1XLQ== 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=kWVRe82ncg6vBIGvKdehrnd9eKdrASSAITapnch0F3U=; b=Xvs2+AwnefMhyMsbMSygxpCQO8WBR5ek/Spa4Fhqqn4LZ0WQX04itaJOm953Zpvouj CiApaHPc7zsVny27PW5KdHXqizxyAyLd0tV3m6tvdE9OC5tWoamcTGx/v9UWBe3SREI0 7EY8iVbqVlHVZMUBGbXobAWn5QY7Vz+L82ePUrzPHBQqC9WCQrDXaD2M1qanRgwuTjwk b99NX7i2e0RZyr69Q4VGiBVw7TglQPi6Vl/Af1GhGwdRDbmt9yki+0ZiKdaYqHMa8+TP LnARUs2/HO6wDh/tsp3uRuWLp5lOPhw8xP6uzgZmDssB04tkSiF+u4ZJkI1zEV0u+bsd Q7PA== X-Gm-Message-State: ALoCoQksG5oq8iI4eWw2U4ALGmVhEDpDgM6tvBX+npgOogQpKBwtxPRbb0DJwqZ7e7nalsRPNZgQ X-Received: by 10.107.3.199 with SMTP id e68mr31701739ioi.92.1429104691902; Wed, 15 Apr 2015 06:31:31 -0700 (PDT) MIME-Version: 1.0 References: <20150415015313.357751B28A@ld9781.wdf.sap.corp> <53BB8A96-8CFE-4275-9562-336D60B567B3@gmail.com> <56BA5F9C-E1CE-402F-831C-0D3AF3D336AE@gmail.com> In-Reply-To: <56BA5F9C-E1CE-402F-831C-0D3AF3D336AE@gmail.com> From: David Benjamin Date: Wed, 15 Apr 2015 13:31:31 +0000 Message-ID: To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a113ed422821e5a0513c35d61 Archived-At: X-Mailman-Approved-At: Wed, 15 Apr 2015 07:54:05 -0700 Cc: "tls@ietf.org" , Bill Cox Subject: Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 13:32:01 -0000 --001a113ed422821e5a0513c35d61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Personally, I dislike unnecessary wiggle room in specs and mildly prefer MUST. I don't see a good reason to abort rather than do a full handshake. It'd be nice to have the confidence that (non-buggy) servers won't cause problems here and take a shortcut. (E.g., I can see aborting being simpler in OpenSSL since it parses most extensions after session resumption is resolved. The ticket is handled special.) Then again, one might read MUST to imply the server is obligated to perform a full handshake and isn't allowed to abort for other reasons, which would be poor. On Wed, Apr 15, 2015 at 3:38 AM Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > I guess my question is whether =E2=80=9CSHOULD perform a full handshake= =E2=80=9D is strong > enough, > leaving the server the option of aborting the handshake, or is MUST > preferable > as a clearer indication to implementers? > > > On 15 Apr 2015, at 08:15, Karthikeyan Bhargavan < > karthik.bhargavan@gmail.com> wrote: > > > I like Martin=E2=80=99s text, and have edited it to the following: > > > > 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 continue the abbreviated handshake. > > Instead, it SHOULD perform a full handshake to negotiate a new > session. > > > > If this looks acceptable, I=E2=80=99ll put out a new version of the dra= ft today. > > > > -K. > > > > On 15 Apr 2015, at 03:53, Martin Rex wrote: > > > >> Karthikeyan Bhargavan wrote: > >>> How about the following: > >>> 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 fall back to a full handshake by > >>> sending a ServerHello that rejects session resumption and offers = a > >>> new session. > >> > >> Too complicated for my taste. I do not see a need for words like > >> fallback and reject, and these actually do not exist in the TLS > protocol. > >> > >> > >> 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 perform a full handshake to negotiate > >> a new session (i.e. the server MUST NOT perform an abbreviated > >> handshake aka session resume). > >> > >> > >> -Martin > > > > _______________________________________________ > > 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 > --001a113ed422821e5a0513c35d61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Personally, I dislike unnecessary wiggle room in specs and= mildly prefer MUST. I don't see a good reason to abort rather than do = a full handshake. It'd be nice to have the confidence that (non-buggy) = servers won't cause problems here and take a shortcut. (E.g., I can see= aborting being simpler in OpenSSL since it parses most extensions after se= ssion resumption is resolved. The ticket is handled special.)

Then a= gain, one might read MUST to imply the server is obligated to perform a ful= l handshake and isn't allowed to abort for other reasons, which would b= e poor.

On Wed, Apr 15, 2015 at 3:38 AM= Karthikeyan Bhargavan <k= arthik.bhargavan@gmail.com> wrote:
I guess my question is whether =E2=80=9CSHOULD perform a full handshake=E2= =80=9D is strong enough,
leaving the server the option of aborting the handshake, or is MUST prefera= ble
as a clearer indication to implementers?


On 15 Apr 2015, at 08:15, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com&g= t; wrote:

> I like Martin=E2=80=99s text, and have edited it to the following:
>
>=C2=A0 =C2=A0 If the original session did not use an extended master se= cret but
>=C2=A0 =C2=A0 the new ClientHello does contain the "extended_maste= r_secret"
>=C2=A0 =C2=A0 extension, the server MUST NOT continue the abbreviated h= andshake.
>=C2=A0 =C2=A0 Instead, it SHOULD perform a full handshake to negotiate = a new session.
>
> If this looks acceptable, I=E2=80=99ll put out a new version of the dr= aft today.
>
> -K.
>
> On 15 Apr 2015, at 03:53, Martin Rex <mrex@sap.com> wrote:
>
>> Karthikeyan Bhargavan wrote:
>>> How about the following:
>>>=C2=A0 =C2=A0 =C2=A0If the original session did not use an exte= nded master secret but
>>>=C2=A0 =C2=A0 =C2=A0the new ClientHello does contain the "= extended_master_secret"
>>>=C2=A0 =C2=A0 =C2=A0extension, the server MUST fall back to a f= ull handshake by
>>>=C2=A0 =C2=A0 =C2=A0sending a ServerHello that rejects session = resumption and offers a
>>>=C2=A0 =C2=A0 =C2=A0new session.
>>
>> Too complicated for my taste.=C2=A0 I do not see a need for words = like
>> fallback and reject, and these actually do not exist in the TLS pr= otocol.
>>
>>
>>=C2=A0 =C2=A0 If the original session did not use an extended maste= r secret but
>>=C2=A0 =C2=A0 the new ClientHello does contain the "extended_m= aster_secret"
>>=C2=A0 =C2=A0 extension, the server MUST perform a full handshake t= o negotiate
>>=C2=A0 =C2=A0 a new session (i.e. the server MUST NOT perform an ab= breviated
>>=C2=A0 =C2=A0 handshake aka session resume).
>>
>>
>> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--001a113ed422821e5a0513c35d61-- From nobody Wed Apr 15 08:33: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 22ED21B35DE for ; Wed, 15 Apr 2015 08:32: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 RhPVyGyRifMu for ; Wed, 15 Apr 2015 08:32:58 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010: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 A6E5C1AC430 for ; Wed, 15 Apr 2015 08:32:57 -0700 (PDT) Received: by labbd9 with SMTP id bd9so35680273lab.2 for ; Wed, 15 Apr 2015 08:32: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:from:date:message-id:subject:to :cc:content-type; bh=NHSeJxr4sJ+bywSVBI+Sukg+/sF9QOMAZB53WzEwmDE=; b=UoBYqanH7apBqOsNyprILqxpQfWBzEdz+up8OnSuR21pgFp816ZxZTAp3tCdeQufEc 6lQAR42DZw3ETsmyfPOrlVgQasecWqaPKPYgkdpMeAhVd3L+1aFxy0pFCr73IRtcXyei y0ottVnbnZn+hASbkrA4KmlwSYyQV/VcMn6Z7QD1nAoaQn/UQYOcN3AQ7aMV9fRN2tqY m+A7NHzUpI8GqG1seuiuQhG448ycprVuejyCT09W76qqsoU9PjZnTq3D9LRclu64C+u8 mSzUKJVS1ttiM1juTHSOXwhhKDQyNuf4+Asyl6zXYeR74TJ+miTAr7ETz4Ei5l8v45S/ /aaA== X-Received: by 10.112.210.230 with SMTP id mx6mr24512433lbc.64.1429111975994; Wed, 15 Apr 2015 08:32:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.172.196 with HTTP; Wed, 15 Apr 2015 08:32:15 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFF967A@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFF967A@uxcn10-tdc05.UoA.auckland.ac.nz> From: Santiago Zanella Date: Wed, 15 Apr 2015 17:32:15 +0200 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 15:32:59 -0000 Peter Gutmann wrote: > So... if 8.7% is the most widely-used group (since you qualify the > 7.8% one with "the most common with a modulus longer than 1024 > bits") That does not follow from what I said. The 8.7% group is the 4th most common, the top 3 have also 1024-bit moduli. > that means the most common group is one that the ff-dhe draft > doesn't allow you to specify, and the most common group with a > modulus longer than 1024 bits is... another one that the ff-dhe > draft doesn't allow you to specify. Yes, and rightfully so because we want to get rid of 1024-bit groups and have good reasons not to reuse groups from other protocols. But note that the draft reserves codepoints for private use that can be used locally to specify other groups. The minimum acceptable size was set at 2048 bits was a result of a straw poll: http://www.ietf.org/mail-archive/web/tls/current/msg14438.html --Santiago From nobody Wed Apr 15 08:39: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 551771ACE27 for ; Wed, 15 Apr 2015 08:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 OpYOPzW-8BEA for ; Wed, 15 Apr 2015 08:39:01 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BF81ACE2D for ; Wed, 15 Apr 2015 08:39:00 -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=1429112342; x=1460648342; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=06nNHT+NM/tdHqMtV7Fsc9RoHR9lsKONiAyAen+hfwc=; b=FpzZkDHIzL7LURpSsYP94fF0Mhka2pnVxl6qXokOF44A5f/bh0W+qWgG lNgKn0bsIiPih8py4OvAxnSONgeZvXm06nLjYdafkPdAPKzU1M0ubiusf 6IOnHPxTph/FylRB3LwCTP2s1Hkp5WgSG8IjHXfNYrl4Rvs6QaEKd/dPX E=; X-IronPort-AV: E=Sophos;i="5.11,582,1422874800"; d="scan'208";a="320755481" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Apr 2015 03:39:00 +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, 16 Apr 2015 03:38:59 +1200 From: Peter Gutmann To: Santiago Zanella Thread-Topic: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 Thread-Index: AdB3io0RQkI2CK/nSDWUSCl2mNTLq///RG6AgADKTcM= Date: Wed, 15 Apr 2015 15:38:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFF98DE@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFF967A@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] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 15:39:04 -0000 Santiago Zanella writes:=0A= =0A= >That does not follow from what I said. The 8.7% group is the 4th most comm= on,=0A= >the top 3 have also 1024-bit moduli.=0A= =0A= Yeah, that was the puzzling bit, so just out of curiosity what were the oth= er=0A= 1024-bit groups if they weren't the RFC 2409 one?=0A= =0A= Peter.= From nobody Wed Apr 15 08:55: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 E95101B2CFC for ; Wed, 15 Apr 2015 08:55: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 T8riG7gPPmqV for ; Wed, 15 Apr 2015 08:55:21 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010: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 71B2F1B2CF7 for ; Wed, 15 Apr 2015 08:55:20 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so37517053lbb.2 for ; Wed, 15 Apr 2015 08:55: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=q6X82tQzmgFYUykimgnyXfR9jf3r3zNborJ8DVMh+mY=; b=HeNuM75l/E4i/Se+aLqXeDTwB+n1Myh4zISdEnbFfHWSDCtDk67L7yeKlaeAwm9BhJ bI0pl4MCDP6WxlbmcqI/sIAFLfIOxFeac+DBp72FLSl1DwFiBx+Zy92okZ9GK2LV4tZ3 ppTKuf+j8YSkiBYFbfu928DlTsKdLZKFuXorocl0FozDz1brkNUEL3sQBZSlejFhnUxj 3NzY7NFDEgTO8U0w9C7Xp/l4z4zVtmE3YudXl6woS9WO0r80YjrJ9aq/InGZMQD4avDR A4mFcsPpq39cDOSLlK64Y3CH4ajOAFQYjpOTyuf+k4v9dCVONCZf1HRImc+NliDCWeDE 9wXA== X-Received: by 10.112.242.8 with SMTP id wm8mr24164779lbc.69.1429113318771; Wed, 15 Apr 2015 08:55:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.172.196 with HTTP; Wed, 15 Apr 2015 08:54:38 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFF98DE@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFF967A@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AAFF98DE@uxcn10-tdc05.UoA.auckland.ac.nz> From: Santiago Zanella Date: Wed, 15 Apr 2015 17:54:38 +0200 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 15:55:23 -0000 The others are custom groups hardcoded in popular web servers (Apache, nginx). --Santiago From nobody Wed Apr 15 09:40: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 358651B360E for ; Wed, 15 Apr 2015 09:40: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 fzjJ4wAsYT0c for ; Wed, 15 Apr 2015 09:39:58 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003: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 14E3A1B2DE1 for ; Wed, 15 Apr 2015 09:39:58 -0700 (PDT) Received: by oblw8 with SMTP id w8so28076103obl.0 for ; Wed, 15 Apr 2015 09:39: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:content-transfer-encoding; bh=+Gtm9H7Yedpx+0N1licwcDJC93y13SeqH7H+4rrXG5w=; b=qfD4LuLvk6HT0cd/asP8sb4fJO4tpuGeqrTBtV88qLjAZlb6DrEtkJvvX103qgq11z XpJcnZ6840vNI458/Km1XsF/bNs39N7xdc8Kq5Cm4KkzpFsTCVg5gxf+N6CrYUF6L+3G cCQkwW7n7XHxKHI3ZnbYW056lYdLebLSOXdAvXhsbqLZEf3bcteSoOOfC2weHdw4iSxB BQVTbBfQyddYFjWXg5JJUKL13P8fn9EtgYb7p38JgUpiDk4u27Id76iD8OMtHHgdSpUb 5HXKr7ipf4hVoAhP76I0Cb4JjQAbEk/uelQKA0bR+tPVBomqVakJwNeBmywsfMbXNupA c1pg== MIME-Version: 1.0 X-Received: by 10.202.0.75 with SMTP id 72mr16529452oia.131.1429115971499; Wed, 15 Apr 2015 09:39:31 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Wed, 15 Apr 2015 09:39:31 -0700 (PDT) In-Reply-To: <56BA5F9C-E1CE-402F-831C-0D3AF3D336AE@gmail.com> References: <20150415015313.357751B28A@ld9781.wdf.sap.corp> <53BB8A96-8CFE-4275-9562-336D60B567B3@gmail.com> <56BA5F9C-E1CE-402F-831C-0D3AF3D336AE@gmail.com> Date: Wed, 15 Apr 2015 09:39:31 -0700 Message-ID: From: Martin Thomson To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" , Bill Cox Subject: Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 16:40:04 -0000 On 15 April 2015 at 00:38, Karthikeyan Bhargavan wrote: > I guess my question is whether =E2=80=9CSHOULD perform a full handshake= =E2=80=9D is strong enough, > leaving the server the option of aborting the handshake, or is MUST prefe= rable > as a clearer indication to implementers? This is fine with me. Though I think David's concerns are worth taking into account. You might instead say: Instead, it MUST either perform a full handshake or abort the connection= . That leaves plenty of options open. Given that this only arises if you have a busted client, we shouldn't worry too much about which option people take. If this were an expected situation somehow, I'd be arguing more strongly for the full handshake option. From nobody Wed Apr 15 09:52: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 0811C1B2DD3 for ; Wed, 15 Apr 2015 09:52:37 -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 DXpEYdRHeNmH for ; Wed, 15 Apr 2015 09:52:35 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 D874D1B2DC7 for ; Wed, 15 Apr 2015 09:52:22 -0700 (PDT) Received: by oiko83 with SMTP id o83so30311244oik.1 for ; Wed, 15 Apr 2015 09:52:22 -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=5eq5ALqEwgk3esoN90lSgWQYhqtkIuRLK7KYUh4958k=; b=IP0cIQyGUoMB9yiMKD2l+GfpQjOHS4hYFcwPPD76vkw5nPDBS6sR9xYeJgIJncbodx rNRAU8ZIgQCFWSyDgf6MqeLuI39NXH8kUMXTDD/w8h0Z3Aug9x2RsVHD8p7eQDJbshIM 95SzBfxcD2dtVjiBtfZonBv9SffEauUkK2qgc= 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=5eq5ALqEwgk3esoN90lSgWQYhqtkIuRLK7KYUh4958k=; b=dteIhTdubpccqhBXvKPKj5tDPacQdDf0biH1YpFz3ElT3FyqRiCwNJikicqR+YDrR0 Fpnf475us8NXaPB14iGjDIkEyJFHOijMxsuzax93WLvm6O6T1ZKdsV4gMjw5yEI39lIM Cah2gEmZj1TvA3lrEAsr31ondYR6irlht6oYr5MmP4UGemzo/VnV92Q7OfhpEgamWPtv R/CAwrcp6AQi6g8EFpCH+Qh2ftkmIkgIwet7oqgFcriExc0rBqAbVU0XL6T+faYAcael JPz+sME6Kdj0CCPMaRMAq8nc2oq/I37G9VnurjnBjDjjqITuYZVy7uYGjwFvNrssNtWj vqCA== X-Gm-Message-State: ALoCoQl1Ka2oThgmT3QMAzaBOed0uwY47J8z87bPTI0EpBlqXt7Gg/RUbPir4Vf4RywqZTERzm0c X-Received: by 10.43.72.138 with SMTP id yo10mr32856598icb.69.1429116741654; Wed, 15 Apr 2015 09:52:21 -0700 (PDT) MIME-Version: 1.0 References: <20150415015313.357751B28A@ld9781.wdf.sap.corp> <53BB8A96-8CFE-4275-9562-336D60B567B3@gmail.com> <56BA5F9C-E1CE-402F-831C-0D3AF3D336AE@gmail.com> In-Reply-To: From: David Benjamin Date: Wed, 15 Apr 2015 16:52:20 +0000 Message-ID: To: Martin Thomson , Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a11c204febaba6c0513c62bd7 Archived-At: Cc: "tls@ietf.org" , Bill Cox Subject: Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 16:52:37 -0000 --001a11c204febaba6c0513c62bd7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 15, 2015 at 12:40 PM Martin Thomson wrote: > On 15 April 2015 at 00:38, Karthikeyan Bhargavan > wrote: > > I guess my question is whether =E2=80=9CSHOULD perform a full handshake= =E2=80=9D is > strong enough, > > leaving the server the option of aborting the handshake, or is MUST > preferable > > as a clearer indication to implementers? > > > This is fine with me. Though I think David's concerns are worth > taking into account. You might instead say: > > Instead, it MUST either perform a full handshake or abort the > connection. > > That leaves plenty of options open. > > Given that this only arises if you have a busted client, we shouldn't > worry too much about which option people take. If this were an > expected situation somehow, I'd be arguing more strongly for the full > handshake option. > Not necessarily; it can also occur if the server changes configuration to add EMS support. Server deployments may not necessarily flush their session cache across upgrades (perhaps you configured SSLSessionTicketKeyFile in Apache to share your session cache between machines). It would be nice if they did, but not everyone running a server will know the nitty gritty details of what the latest software update included and the interactions with protocol subtleties. I agree it's not likely to be very common, so it's not actually that big a deal. But this is a case where the safer option is clear and not actually more complex, so the spec should nudge implementers toward that one. (From experience, interop problems around session resumption are a headache to diagnose and reason about. I prefer to actively avoid introducing them where possible.) David --001a11c204febaba6c0513c62bd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 15, 2015 at 12:40 P= M Martin Thomson <martin.tho= mson@gmail.com> wrote:
On 15 April= 2015 at 00:38, Karthikeyan Bhargavan
<karthi= k.bhargavan@gmail.com> wrote:
> I guess my question is whether =E2=80=9CSHOULD perform a full handshak= e=E2=80=9D is strong enough,
> leaving the server the option of aborting the handshake, or is MUST pr= eferable
> as a clearer indication to implementers?


This is fine with me.=C2=A0 Though I think David's concerns are worth taking into account.=C2=A0 You might instead say:

=C2=A0 =C2=A0Instead, it MUST either perform a full handshake or abort the = connection.

That leaves plenty of options open.

Given that this only arises if you have a busted client, we shouldn't worry too much about which option people take.=C2=A0 If this were an
expected situation somehow, I'd be arguing more strongly for the full handshake option.

Not necessarily; it can als= o occur if the server changes configuration to add EMS support. Server depl= oyments may not necessarily flush their session cache across upgrades (perh= aps you configured SSLSessionTicketKeyFile in Apache to share your session = cache between machines). It would be nice if they did, but not everyone run= ning a server will know the nitty gritty details of what the latest softwar= e update included and the interactions with protocol subtleties.
=
I agree it's not likely to be very common, so it's n= ot actually that big a deal. But this is a case where the safer option is c= lear and not actually more complex, so the spec should nudge implementers t= oward that one.

(From experience, interop problems around session re= sumption are a headache to diagnose and reason about. I prefer to actively = avoid introducing them where possible.)

David=C2=A0
--001a11c204febaba6c0513c62bd7-- From nobody Wed Apr 15 10:01: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 D0F231B2DAE for ; Wed, 15 Apr 2015 10:00: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 tf39VlWXJSP9 for ; Wed, 15 Apr 2015 10:00:58 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 AA5291B2DA6 for ; Wed, 15 Apr 2015 10:00:58 -0700 (PDT) Received: by oign205 with SMTP id n205so30954712oig.2 for ; Wed, 15 Apr 2015 10:00:58 -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=A0s9m7Gg8P/KJXuEs4kyw/0iKUqZgAR+VrDG+mSUVP8=; b=T/G9JGk19aRrG3zsZZNLnngE1hS8xkXko2fDzAbWYA129aYT1nrOVJEA3c/iOaeNRf xupj7bxnl5NipOnWiEF7TitUAMvR+r5oHyGdcsuzZiKet0U78ObCtCSyE+X0yuFfvrKD myN/sMGfPJHwwQ+W7tduSc/ineUtFBJ2hZUd7KCwWPzzAjgeiu0hOWvQiTCIuEv4MIXB 3wb9JGHqXqJ4eWtakQurPvhUWGMUsP66zHKUi1hXPu96EMUl/dmi35ccWo7g4dIQwr5f 39Wnwmd5zfXyVk6CFi4TppNIOwHMRLKEYxPF3xJMCIN8w082IFdiQ5S+LxsCd2LS1Bc8 RojQ== MIME-Version: 1.0 X-Received: by 10.182.68.103 with SMTP id v7mr21042111obt.82.1429117247621; Wed, 15 Apr 2015 10:00:47 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Wed, 15 Apr 2015 10:00:47 -0700 (PDT) In-Reply-To: References: <20150415015313.357751B28A@ld9781.wdf.sap.corp> <53BB8A96-8CFE-4275-9562-336D60B567B3@gmail.com> <56BA5F9C-E1CE-402F-831C-0D3AF3D336AE@gmail.com> Date: Wed, 15 Apr 2015 10:00:47 -0700 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" , Bill Cox Subject: Re: [TLS] draft-ietf-tls-session-hash-04 and session resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 17:01:00 -0000 On 15 April 2015 at 09:52, David Benjamin wrote: > Not necessarily; it can also occur if the server changes configuration to > add EMS support. Oh, of course. In which case, I am going to more strongly advocate for the SHOULD text. I understand that you might have some issue complying with that for various reasons related to your implementation or deployment, but this is exactly what SHOULD is for. I don't want to end up in a situation where the incentives are such that you resume a session that didn't have session hash, when both peers support fully support the feature. From nobody Wed Apr 15 11: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 A7E081A0108 for ; Wed, 15 Apr 2015 11:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 wZ4hpoQnLoxp for ; Wed, 15 Apr 2015 11:14:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0FD1A012D for ; Wed, 15 Apr 2015 11:14:58 -0700 (PDT) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (0.161.207.26) by BN3PR0301MB1250.namprd03.prod.outlook.com (0.161.207.26) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 15 Apr 2015 18:14:57 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) with mapi id 15.01.0136.026; Wed, 15 Apr 2015 18:14:57 +0000 From: Andrei Popov To: Hubert Kario , "mrex@sap.com" Thread-Topic: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned Thread-Index: AQHQdjMVLAECbtqN1ke7Q3E3qycYJJ1Le3aAgAAAZTCAAAq6gIABR+AAgABQyQCAAKuogIAAljgg Date: Wed, 15 Apr 2015 18:14:57 +0000 Message-ID: References: <20150414225328.924711B28A@ld9781.wdf.sap.corp> <1531163.KgFZIyykO4@pintsize.usersys.redhat.com> In-Reply-To: <1531163.KgFZIyykO4@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: redhat.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:BN3PR0301MB1250; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(50986999)(2501003)(76176999)(54356999)(46102003)(19580405001)(19580395003)(62966003)(77156002)(15975445007)(102836002)(15974865002)(87936001)(4001410100001)(74316001)(76576001)(40100003)(86612001)(86362001)(2656002)(2900100001)(99286002)(106116001)(33656002)(2950100001)(92566002)(122556002)(7059030)(3826002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1250; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1250; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1250; x-forefront-prvs: 0547116B72 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2015 18:14:57.1551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1250 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 18:15:00 -0000 TWFydGluJ3MgZGVzaXJlIGZvciBhIHNpbXBsZSBBUEkgdGhhdCB0YWtlcyBhIGxpc3Qgb2YgTlVM LXRlcm1pbmF0ZWQgQVNDSUkgc3RyaW5ncyBpcyB2ZXJ5IHVuZGVyc3RhbmRhYmxlLiBJJ3ZlIHNl ZW4gb3RoZXIgZGV2ZWxvcGVycyBhc2sgZm9yIHRoZSBzYW1lLiANCg0KSGF2aW5nIHNhaWQgdGhh dCwgQUxQTiBSRkMgYWxsb3dzIHRoZSB1c2Ugb2YgYXJiaXRyYXJ5IG9jdGV0IHN0cmluZ3MgYXMg QUxQTiBJRHMsIHNvIHVuZm9ydHVuYXRlbHkgdGhlIHNpbXBsZSBBUEkgdGhhdCBhc3N1bWVzIE5V TC10ZXJtaW5hdGVkIEFTQ0lJIElEcyBpcyBub3Qgc3VmZmljaWVudC4gQW5kIG9mIGNvdXJzZSBh bnkgY29kZSB0aGF0IG1hdGNoZXMgQUxQTiBJRHMgaGFzIHRvIHBlcmZvcm0gdGhlIGNvbXBhcmlz b24gb2YgYnl0ZSBhcnJheXMgcmF0aGVyIHRoYW4gc29tZSBmb3JtIG9mIHN0cmluZyBjb21wYXJp c29uLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogSHViZXJ0IEthcmlvIFttYWlsdG86aGthcmlvQHJlZGhhdC5jb21dIA0KU2VudDogV2Vk bmVzZGF5LCBBcHJpbCAxNSwgMjAxNSAyOjA4IEFNDQpUbzogbXJleEBzYXAuY29tDQpDYzogdGxz QGlldGYub3JnOyBBbmRyZWkgUG9wb3YNClN1YmplY3Q6IFJlOiBbVExTXSBUTFMgQUxQTiAocmZj NzMwMSksIG5vIHJlc2VydmVkIHNlcGVyYXRvciBjaGFyIGFuZCB3aHkgaXMgMCBubyBiYW5uZWQN Cg0KT24gV2VkbmVzZGF5IDE1IEFwcmlsIDIwMTUgMDA6NTM6MjggTWFydGluIFJleCB3cm90ZToN Cj4gSHViZXJ0IEthcmlvIHdyb3RlOg0KPiA+IE1hcnRpbiBSZXggd3JvdGU6DQo+ID4+IEFuZHJl aSBQb3BvdiB3cm90ZToNCj4gPj4+IFllcywgdGhpcyBpcyBhbiBleGFtcGxlIG9mIE5QTiBsZWdh Y3kgaW4gQUxQTiwgYW5kIHllcyB0aGVyZSBpcyANCj4gPj4+IHNvbWUgQVBJIHBhaW4gaW52b2x2 ZWQuDQo+ID4+IA0KPiA+PiBJJ20gbm90IHRyeWluZyB0byBicmVhayB0aGluZ3MgYW5kIEknbSBu b3QgYWR2b2NhdGluZyB0byBjaGFuZ2UgYW55IA0KPiA+PiBleGlzdGluZyBBUElzLiAgQnV0IEkn dmUganVzdCBiZWVuIGFza2VkIGZvciBzdXBwb3J0IG9mIHRoaXMgYW5kIGFtIA0KPiA+PiBsb29r aW5nIGludG8gbmV3bHkgaW1wbGVtZW50aW5nIGl0LCBhbmQgSSB3b3VsZCBhcHByZWNpYXRlIGlm IHdlIA0KPiA+PiAoaS5lLiB0aGUgSUVURiBUTFMgd29ya2luZyBncm91cCkgY291bGQgcmVzdHJp Y3QgdGhlIFRMUyBBTFBOIElEcyANCj4gPj4gYXQgbGVhc3QgYnkgYmFubmluZyB0aGUgY2hhcmFj dGVyIDAgZnJvbSBUTFMgQUxQTiBJRCByZWdpc3RyYXRpb25zIG5vdy4NCj4gPj4gDQo+ID4+IEJl aW5nIGFsbG93ZWQgdG8gcmVqZWN0IGVtYmVkZGVkIE5VTHMgd291bGQgZmFjaWxpdGF0ZSBzb21l IGFzcGVjdHMgDQo+ID4+IChzYXZlIG1lIGEgZmV3IGxpbmVzIG9mIGNvZGUpLg0KPiA+PiANCj4g Pj4gSSBjYW4gbGl2ZSB3aXRoIFVURjguDQo+ID4+IA0KPiA+PiBBIHNpbmdsZSByZXNlcnZlZCBj aGFyYWN0ZXIgKHN1Y2ggYXMgY29sb24gJzonIG9yIHBpcGUgJ3wnIG9yIGNvbW1hIA0KPiA+PiAn LCcpIHdvdWxkIGFsbG93IG1lIHRvIGF2b2lkIGEgY2hhcmFjdGVyIGVzY2FwaW5nIHNjaGVtZSBm b3IgdGhlIA0KPiA+PiBBUEkgSSdtIHRyeWluZyB0byBjcmVhdGUsIGJ1dCBJIGNvdWxkIGxpdmUg d2l0aCB0aGlzIGlzc3VlIGJlaW5nIGEgDQo+ID4+IHByb3ByaWV0YXJ5IHRoaW5nLg0KPiA+IA0K PiA+IFlvdSBkb24ndCBwcmV2ZW50IENWRS0yMDA5LTI0MDgtbGlrZSBleHBsb2l0cyBieSBiYW5u aW5nIG51bGxzIGluIGZpZWxkcy4NCj4gDQo+IEkgd2FzIHRhbGtpbmcgYWJvdXQgKkFQSSogc3R1 ZmYsIG5vdCBhYm91dCB3aXJlLWxldmVsIGVuY29kaW5nIGFuZCBUTFMgDQo+IHByb3RvY29sIHN0 dWZmLg0KDQphbmQgQVBJIG5lZWRzIHRvIGJlIGFibGUgdG8gaGFuZGxlIGFsbCB0aGUgc3R1ZmYg dGhhdCBjYW4gYmUgc2VudCBvdmVyIHRoZSB3aXJlDQoNCj4gVG8gYmUgYWJsZSB0byBzdXBwb3J0 IHRoZSBjdXJyZW50bHkgKHVucmVhc29uYWJseSBicm9hZCkgc2V0IG9mIHdoYXQgDQo+IFRMUyBB TFBOIElEcyBtYXkgYmUgcmVnaXN0ZXJlZCwgeW91IHdvdWxkIGhhdmUgdG8gY3JlYXRlIGFuIEFQ SSB3aGVyZSANCj4gdGhlIGNhbGxlciB3b3VsZCBoYXZlIHRvIHN1cHBseSB0aGUgKmlucHV0KiAo ZnJvbSBhcHBsaWNhdGlvbiB0byBUTFMgDQo+IGltcGxlbWVudGF0aW9uKSBhcyBhbiBhcnJheS1v Zi1ibG9icywgaS5lLiBleHBsaWNpdCBsZW5ndGggZmllbGRzDQo+IA0KPiBBIGNvbmNhdGVuYXRl ZCBmbGF0LXN0cmluZyByZXByZXNlbnRhdGlvbiB3b3VsZCBiZSAqTVVDSCogc2ltcGxlciBhbmQg DQo+IG5pY2VyIGF0IHRoZSBBUEkgbGV2ZWwuDQoNCmV2ZW4gaW4gQyBsaWtlIGxhbmd1YWdlcyB5 b3UganVzdCBuZWVkIG1lbW9yeSBwb2ludGVyIGFuZCBhIGxlbmd0aCB2YWx1ZSwgSSB3b3VsZG4n dCBjYWxsIHRoYXQsIGNvbXBhcmVkIHRvIGp1c3QgbWVtb3J5IHBvaW50ZXIsIHRvIGJlICJNVUNI IiBzaW1wbGVyDQoNCnRoZSBmaXJzdCBtYWtlcyBidWZmZXIgb3ZlcnJ1bnMgaW1wb3NzaWJsZSAt IHNvbWV0aGluZyBDIGxpa2UgbGFuZ3VhZ2VzIGNvdWxkIHVzZSBtb3JlIG9mDQoNCkluIHNvbWUg bGFuZ3VhZ2VzLCBsaWtlIFB5dGhvbiwgeW91IGNhbid0IGV2ZW4gaGF2ZSBhIGJ5dGUgYXJyYXkg b2YgaW5kZWZpbml0ZSBsZW5ndGgsIG1ha2luZyB0aGUgZW1iZWRkZWQgbnVsbHMgYSBjb21wbGV0 ZSBub24taXNzdWUNCiANCj4gPiBJZiBhbnl0aGluZywgdGhlIFJGQyBjb3VsZCBiZSB1cGRhdGVk IHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhhdCANCj4gPiBpbXBsZW1lbnRhdGlvbnMgTVVTVCBiZSBh YmxlIHRvIGhhbmRsZSB0aGUgY2FzZSB3aGVyZSB0aGUgSURzIA0KPiA+IGluY2x1ZGUgbnVsbCBi eXRlcy4NCj4gDQo+IFRoYXQgd291bGQgYmUgaW5zYW5lLg0KDQpTbyBjdXJyZW50IFJGQyBpcyBp bnNhbmUuLi4/DQoNClRoZSBhYm92ZSBpcyBqdXN0IGltcGxpY2l0LCBub3QgZXhwbGljaXQuDQog DQo+IElmIGFueXRoaW5nLCBhbiBpbXBsZW1lbnRhdGlvbiByZWNlaXZpbmcgYSBBTFBOIElEIHdp dGggZW1iZWRkZWQgTlVMIA0KPiBjaGFyYWN0ZXJzIHNob3VsZCBkcm9wIGFuZCBpZ25vcmUgdGhh dCBib2d1cyBBTFBOIElELg0KPiANCj4gPiBCdXQgdGhpcyBpcyB0aGUgY2FzZSBmb3IgYmFzaWNh bGx5IGFsbCBmaWVsZHMgYm90aCBpbiBUTFMgYW5kIFg1MDkuLi4NCj4gDQo+IFRoYXQgYXBwbGll cyBvbmx5IHRvIGZpZWxkcyB3aXRoIHVucmVhc29uYWJsZSBkZWZpbml0aW9ucy4NCj4gDQo+IExv b2sgYXQgdGhlIFRMUyBTZXJ2ZXIgTmFtZSBJbmRpY2F0aW9uIGV4dGVuc2lvbjoNCj4gDQo+ICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYwNjYjc2VjdGlvbi0zDQo+IA0KPiB0aGlz IGhhcyBhIHJlYXNvbmFibGUgZGVmaW5pdGlvbiBmb3IgdGhlICJob3N0X25hbWUoMCkiIGlzIGxp bWl0ZWQgdG8gDQo+ICJmdWxseSBxdWFsaWZpZWQgRE5TIGhvc3RuYW1lIiwgd2hpY2ggbWVhbnMg dGhhdCBub3QganVzdCBlbWJlZGRlZCANCj4gTlVMcyBhcmUgcHJvaGliaXRlZCAoYW5kIGNhbiBi ZSBpbW1lZGlhdGVseSBkcm9wcGVkIGFuZCBpZ25vcmVkIGJ5IHRoZSANCj4gVExTIENsaWVudEhl bGxvIFBEVSBwYXJzZXIpLCBidXQgYWxzbyAiaG9zdF9uYW1lKDApIiA+IDI1NSBjaGFycyBhbmQg DQo+IHRoZXJlIGFyZSBzZXZlcmFsIG90aGVyIGNvbnN0cmFpbnRzIG9uIEROUyBob3N0bmFtZXMu DQoNCnRoYXQncyBqdXN0IGluIHJlbGF0aW9uIHRvIGhvc3RfbmFtZSwgbm90IHRvIFNOSSBvciBU TFMgaW4gZ2VuZXJhbA0KDQo+IFJvYnVzdCBhbmQgY29uc2VydmF0aXZlIGRlc2lnbiBtZWFucyB0 aGF0IHlvdSBjaGVjayBhbmQgc2tpcCBpbnZhbGlkIA0KPiBkYXRhIGFzIGVhcmx5IGFzIHBvc3Np YmxlLCB0byBsaW1pdCB0aGUgYXR0YWNrIHN1cmZhY2UuICBXaXRoIGhvdyBUTFMgDQo+IEFMUE4g aXMgY3VycmVudGx5IGRlZmluZWQsIHlvdSBjYW4gKkFMV0FZUyogdGFyZ2V0IHRoZSBhcHBsaWNh dGlvbiBvbiANCj4gdG9wIG9mIFRMUyB3aXRoIGF0dGFja3MsIGJlY2F1c2UgdGhlIFRMUyBpbXBs ZW1lbnRhdGlvbiBpcyBub3QgDQo+IGN1cnJlbnRseSBhbGxvd2VkIHRvIHdlZWQgb3V0IG9idmlv dXMgY3JhcCByaWdodCBhd2F5Lg0KDQpJdCdzIHRydWUsIGl0IGV4cG9zZXMgdGhlIGFwcCBvbiB0 b3AuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCB0aGUgdmFsdWVzIGFscmVhZHkgcGFzc2VkIGJldHdl ZW4gcGVlcnMgYXJlIG5vbiBudWxsIHRlcm1pbmF0ZWQsIHNvIHRoZSBBUEkgaGFzIHRvIHN1cHBv cnQgbm9uLW51bGwgdGVybWluYXRlZCBzdHJpbmdzIGFueXdheS4NCg0KLi4ucGxlYXNlIHRlbGwg bWUgeW91J3JlIG5vdCBudWxsIHRlcm1pbmF0aW5nIHRoZSBJRCBiZWZvcmUgcGFzc2luZyB0aGVt IHRvIGFwcGxpY2F0aW9uLi4uLg0KLS0NClJlZ2FyZHMsDQpIdWJlcnQgS2FyaW8NClF1YWxpdHkg RW5naW5lZXIsIFFFIEJhc2VPUyBTZWN1cml0eSB0ZWFtDQpXZWI6IHd3dy5jei5yZWRoYXQuY29t DQpSZWQgSGF0IEN6ZWNoIHMuci5vLiwgUHVya3nFiG92YSA5OS83MSwgNjEyIDQ1LCBCcm5vLCBD emVjaCBSZXB1YmxpYw0K From nobody Wed Apr 15 11:22: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 A02651A0233 for ; Wed, 15 Apr 2015 11:22:22 -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_20=-0.001, GB_I_INVITATION=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdfLOB_it0wh for ; Wed, 15 Apr 2015 11:22:20 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 368A51A0318 for ; Wed, 15 Apr 2015 11:22:20 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 5F8D7F985; Wed, 15 Apr 2015 14:22:17 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 06F121FFC8; Wed, 15 Apr 2015 13:22:06 -0500 (CDT) From: Daniel Kahn Gillmor To: Martin Thomson , "tls\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 15 Apr 2015 14:22:05 -0400 Message-ID: <874mohqmk2.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] FFDHE and SHOULDs on usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 18:22:22 -0000 Hi Martin-- Thanks for the review! On Thu 2014-11-13 15:05:02 -0500, Martin Thomson wrote: > The thesis here is that strong groups (and 2048 isn't that strong) are > extremely expensive to verify, and folks are unlikely to do that > verification. Therefore, the pick-your-own-group method is not just a > bad idea, but an invitation to attack. agreed. > Clients who want to do PYOG can simply not support (or pretend to not > support) this draft. this also makes sense. > ## Details: > > The draft says that, for servers: > > If a compatible TLS server receives a Supported Groups extension from > a client that includes any FFDHE group (i.e. any codepoint between > 256 and 511 inclusive, even if unknown to the server), and if none of > the client-proposed FFDHE groups are known and acceptable to the > server, then the server SHOULD NOT select an FFDHE ciphersuite. > > I think that this needs to be a MUST. If the client is willing to > take the servers choice of group, then it would not be including the > fixed groups. > > > Similarly, all the SHOULDs in the client behaviour section needs to be hardened. > > OLD: > The compatible client that wants to be able to negotiate strong FFDHE > SHOULD send a "Supported Groups" extension > NEW: > The compatible client that wants to be able to negotiate strong FFDHE > sends a "Supported Groups" extension > Rationale: > This is purely axiomatic. The above two edits make sense to me, and i propose to reflect them with the following diff: diff --git a/tls-negotiated-ff-dhe.xml b/tls-negotiated-ff-dhe.xml index ef73355..3af4c30 100644 --- a/tls-negotiated-ff-dhe.xml +++ b/tls-negotiated-ff-dhe.xml @@ -242,7 +242,7 @@ mechanism. The compatible client that wants to be able to negotiate - strong FFDHE SHOULD send a "Supported Groups" extension + strong FFDHE sends a "Supported Groups" extension (identified by type elliptic_curves(10) in ) in the ClientHello, and include a list of known FFDHE groups in the extension data, ordered from most preferred to least preferred. @@ -295,13 +295,13 @@ extension from a client that includes any FFDHE group (i.e. any codepoint between 256 and 511 inclusive, even if unknown to the server), and if none of the client-proposed FFDHE groups are known and acceptable to the - server, then the server SHOULD NOT select an FFDHE ciphersuite. + server, then the server MUST NOT select an FFDHE ciphersuite. In this case, the server SHOULD select an acceptable non-FFDHE ciphersuite from the client's offered list. If the extension is present with FFDHE groups, none of the client's offered groups are acceptable by the server, and none of the client's proposed non-FFDHE ciphersuites are acceptable to the server, the server - SHOULD end the connection with a fatal TLS alert of type + MUST end the connection with a fatal TLS alert of type insufficient_security(71). The "In this case, the server SHOULD select..." part remains a SHOULD because of the possibility of the peer-incompatibility case outlined in the last sentence. I welcome concrete suggestions for other ways to word this decision process if anyone has a clearer proposal. > OLD: > A client that offers any of these values in the elliptic_curves > extension SHOULD ALSO include at least one FFDHE ciphersuite in the > Client Hello. > NEW: > A client that offers a NamedCurve extension containing a FFDHE group > cannot use > Rationale: > No need for normative language here, this is purely a (relevant) > observation. And "SHOULD ALSO" doesn't appear in RFC 2119 ;) The edit as phrased explicitly above makes no sense. At least the "OLD" had a complete sentence ;) I propose to address the identified normative language with the following change: diff --git a/tls-negotiated-ff-dhe.xml b/tls-negotiated-ff-dhe.xml index 3af4c30..e9202a3 100644 --- a/tls-negotiated-ff-dhe.xml +++ b/tls-negotiated-ff-dhe.xml @@ -252,9 +252,9 @@ ordering SHOULD be based on client preference, but see for more nuance. - A client that offers any of these values in the elliptic_curves - extension SHOULD ALSO include at least one FFDHE ciphersuite in - the Client Hello. + A client that offers a "Supported Groups" extension + containing an FFDHE group should also include at least one FFDHE + ciphersuite in the Client Hello. A client who offers a group MUST be able and willing to perform a DH key exchange using that group. WDYT? --dkg From nobody Wed Apr 15 11:38: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 3B3D61A19F4 for ; Wed, 15 Apr 2015 11:38:12 -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 xU3odOH-1X9Q for ; Wed, 15 Apr 2015 11:38:11 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04E71A19E9 for ; Wed, 15 Apr 2015 11:38:10 -0700 (PDT) Received: by vnbf1 with SMTP id f1so18520423vnb.5 for ; Wed, 15 Apr 2015 11:38:10 -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=/M5xKXs78/TaU87s5qTuKCp04iuw4d+VyUV0rEEo2rs=; b=LDz8SAcvbCMbIqr7usvhln8aAKTvFjNkybCiD4cZHvEn1vaizChQETEmxnm9WrmthU LMWcVRRqqAXAN6wU5qqGF0CMmEBJpITIEtudw3gvvYSTXDq9qnnmGKhNtPiPpEpBw2pq 90aoWNi7PVzH+SXxQiypAHWTOMIC9cl5KnjbDi2h0AxbL1WX0zXamSrXW/HNHBHKWwq+ mT3utdUsr2cwzTslYjXoe5wa0b6OLcV8vs1rTL1P0GWGnuySY3r4X7gufcN361ATSevx JFdsIwTi3C0ViVPGPsfRf64PatMoOSY7RJFWCmlyfOlCbNQZkyQaTcHWiYOsqRLEmJ3B AuvQ== MIME-Version: 1.0 X-Received: by 10.182.39.195 with SMTP id r3mr22223992obk.44.1429123090116; Wed, 15 Apr 2015 11:38:10 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Wed, 15 Apr 2015 11:38:10 -0700 (PDT) In-Reply-To: References: <20150414225328.924711B28A@ld9781.wdf.sap.corp> <1531163.KgFZIyykO4@pintsize.usersys.redhat.com> Date: Wed, 15 Apr 2015 11:38:10 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 18:38:12 -0000 On 15 April 2015 at 11:14, Andrei Popov wrote: > Having said that, ALPN RFC allows the use of arbitrary octet strings as A= LPN IDs, so unfortunately the simple API that assumes NUL-terminated ASCII = IDs is not sufficient. And of course any code that matches ALPN IDs has to = perform the comparison of byte arrays rather than some form of string compa= rison. Well, you *could* implement something that only took NUL-terminated ASCII labels. That could still work, even if it encountered junk as long as the implementation correctly checked lengths first. It would only fail to work if you actually need to talk to someone who wanted to include a crazy value. From nobody Wed Apr 15 12:00: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 DBA2B1A8899 for ; Wed, 15 Apr 2015 12:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6I3mHy0qzbl for ; Wed, 15 Apr 2015 12:00:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4811A8852 for ; Wed, 15 Apr 2015 12:00:16 -0700 (PDT) Received: from BN3PR0301MB1252.namprd03.prod.outlook.com (0.161.207.28) by BN3PR0301MB1267.namprd03.prod.outlook.com (0.161.209.147) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 15 Apr 2015 18:59:57 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (0.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (0.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 15 Apr 2015 18:59:55 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) with mapi id 15.01.0136.026; Wed, 15 Apr 2015 18:59:55 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned Thread-Index: AQHQdjMVLAECbtqN1ke7Q3E3qycYJJ1Le3aAgAAAZTCAAAq6gIABR+AAgABQyQCAAKuogIAAljgggAAJIACAAALpIA== Date: Wed, 15 Apr 2015 18:59:55 +0000 Message-ID: References: <20150414225328.924711B28A@ld9781.wdf.sap.corp> <1531163.KgFZIyykO4@pintsize.usersys.redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.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:BN3PR0301MB1252; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1267; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(19580395003)(93886004)(19580405001)(86612001)(76176999)(86362001)(54356999)(122556002)(99286002)(102836002)(50986999)(40100003)(2950100001)(2900100001)(77156002)(62966003)(33656002)(46102003)(74316001)(2656002)(110136001)(87936001)(92566002)(106116001)(76576001)(7059030)(3826002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1252; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; x-forefront-prvs: 0547116B72 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2015 18:59:55.2534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1252 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 19:00:24 -0000 U2luY2UgdGhlIEFMUE4gUkZDIGFsbG93cyB0aGUgdXNlIG9mIG9jdGV0IHN0cmluZ3MgYXMgQUxQ TiBJRHMsIGl0IHNlZW1zIHdyb25nIHRvIGNoYXJhY3Rlcml6ZSBub24tQVNDSUkgSURzIGFzICJq dW5rIiBvciAiY3JhenkiIHZhbHVlcy4gQUxQTiBJRHMgYXJlIG5vdCBpbnRlbmRlZCBmb3IgZGlz cGxheSB0byB0aGUgdXNlciwgYW5kIGRvbid0IGhhdmUgdG8gY29uc2lzdCBvZiBBU0NJSSBjaGFy YWN0ZXJzLg0KDQpJdCBpcyB0cnVlIHRoYXQgb25lIGNvdWxkIGltcGxlbWVudCBhbiBBUEkgdGhh dCBvbmx5IHRha2VzIE5VTC10ZXJtaW5hdGVkIEFTQ0lJIEFMUE4gSURzLiBTdWNoIGFuIEFQSSB3 b3VsZCBiZSBsaW1pdGVkIGluIHRoYXQgaXQncyBvbmx5IHVzZWFibGUgd2l0aCBhIHN1YnNldCBv ZiBhbGxvd2VkIEFMUE4gSURzIChidXQgYWRtaXR0ZWRseSBzb21lIHBlb3BsZSBjYW4gbGl2ZSB3 aXRoIHRoYXQpLiBJdCBpcyBtb3JlIGltcG9ydGFudCB0aGF0IHRoZSBBTFBOIEktRCBtYXRjaGlu ZyBjb2RlIHRyZWF0IHRoZSBJRHMgY29ycmVjdGx5LCBhcyBsZW5ndGgtcHJlZml4ZWQgYnl0ZSBh cnJheXMuDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0g DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE1LCAyMDE1IDExOjM4IEFNDQpUbzogQW5kcmVpIFBv cG92DQpDYzogSHViZXJ0IEthcmlvOyBtcmV4QHNhcC5jb207IHRsc0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtUTFNdIFRMUyBBTFBOIChyZmM3MzAxKSwgbm8gcmVzZXJ2ZWQgc2VwZXJhdG9yIGNo YXIgYW5kIHdoeSBpcyAwIG5vIGJhbm5lZA0KDQpPbiAxNSBBcHJpbCAyMDE1IGF0IDExOjE0LCBB bmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gSGF2aW5n IHNhaWQgdGhhdCwgQUxQTiBSRkMgYWxsb3dzIHRoZSB1c2Ugb2YgYXJiaXRyYXJ5IG9jdGV0IHN0 cmluZ3MgYXMgQUxQTiBJRHMsIHNvIHVuZm9ydHVuYXRlbHkgdGhlIHNpbXBsZSBBUEkgdGhhdCBh c3N1bWVzIE5VTC10ZXJtaW5hdGVkIEFTQ0lJIElEcyBpcyBub3Qgc3VmZmljaWVudC4gQW5kIG9m IGNvdXJzZSBhbnkgY29kZSB0aGF0IG1hdGNoZXMgQUxQTiBJRHMgaGFzIHRvIHBlcmZvcm0gdGhl IGNvbXBhcmlzb24gb2YgYnl0ZSBhcnJheXMgcmF0aGVyIHRoYW4gc29tZSBmb3JtIG9mIHN0cmlu ZyBjb21wYXJpc29uLg0KDQoNCldlbGwsIHlvdSAqY291bGQqIGltcGxlbWVudCBzb21ldGhpbmcg dGhhdCBvbmx5IHRvb2sgTlVMLXRlcm1pbmF0ZWQgQVNDSUkgbGFiZWxzLiAgVGhhdCBjb3VsZCBz dGlsbCB3b3JrLCBldmVuIGlmIGl0IGVuY291bnRlcmVkIGp1bmsgYXMgbG9uZyBhcyB0aGUgaW1w bGVtZW50YXRpb24gY29ycmVjdGx5IGNoZWNrZWQgbGVuZ3RocyBmaXJzdC4gIEl0IHdvdWxkIG9u bHkgZmFpbCB0byB3b3JrIGlmIHlvdSBhY3R1YWxseSBuZWVkIHRvIHRhbGsgdG8gc29tZW9uZSB3 aG8gd2FudGVkIHRvIGluY2x1ZGUgYSBjcmF6eSB2YWx1ZS4NCg== From nobody Wed Apr 15 12:05: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 E0BD91A883A for ; Wed, 15 Apr 2015 12:05: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 JqqbLvxKexhX for ; Wed, 15 Apr 2015 12:05:27 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3CA1A87C0 for ; Wed, 15 Apr 2015 12:05:27 -0700 (PDT) Received: by oica37 with SMTP id a37so32814845oic.0 for ; Wed, 15 Apr 2015 12:05:26 -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=fapPiouiKIjJwFZo8Jn4e4bkfBchlrdRmi7z/5KLkMs=; b=fof4+ouxLdFQMS5Ec/MiGvdgoUiH1FKRnrK6/RhwRUBSnWgYg8zkhrP8pPrAs8881W BoKlrVbxl+dJYej7rfmuK/gGWNYKep5DovaD1Ays9YqfWdPldoXpbwClFaRyWlvTrfV9 L9cXNgHfDTN0ysTSrkuzisKB3APDFRMLv+SMeuvO2GyGSi1qr0fu/DwJcoVdY92OWMN2 fFG4vCK5l0ptyXQ2YlRpaM2W379mBzVMB0HLIuQfEGOvWnX/UuzFWbjE1Z+VAPwVW4Zt EWvJH4U627Iadal9Eg5Yvx9ZgOMSrO29H1Uel4u2PpB4pmxjS/L3dybrmDnDgn0otyR4 9Y+A== MIME-Version: 1.0 X-Received: by 10.202.196.131 with SMTP id u125mr17140139oif.44.1429124726828; Wed, 15 Apr 2015 12:05:26 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Wed, 15 Apr 2015 12:05:26 -0700 (PDT) In-Reply-To: <874mohqmk2.fsf@alice.fifthhorseman.net> References: <874mohqmk2.fsf@alice.fifthhorseman.net> Date: Wed, 15 Apr 2015 12:05:26 -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] FFDHE and SHOULDs on usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 19:05:29 -0000 On 15 April 2015 at 11:22, Daniel Kahn Gillmor wrote: > - A client that offers any of these values in the elliptic_curves > - extension SHOULD ALSO include at least one FFDHE ciphersuite in > - the Client Hello. > + A client that offers a "Supported Groups" extension > + containing an FFDHE group should also include at least one FFDHE > + ciphersuite in the Client Hello. I apologize for not completing the It's been a while, so I went back and re-read this little bit, prompted largely by your choice to move to a lowercase should: The compatible client that wants to be able to negotiate strong FFDHE SHOULD send a "Supported Groups" extension (identified by type elliptic_curves(10) in [RFC4492]) in the ClientHello, and include a list of known FFDHE groups in the extension data, ordered from most preferred to least preferred. If the client also supports and wants to offer ECDHE key exchange, it MUST use a single "Supported Groups" extension to include all supported groups (both ECDHE and FFDHE groups). The ordering SHOULD be based on client preference, but see Section 6.1 for more nuance. A client that offers any of these values in the elliptic_curves extension SHOULD ALSO include at least one FFDHE ciphersuite in the Client Hello. This is a little over-2119-y for me. How about: """ A client that wants to negotiatiate strong FFDHE sends a ClientHello containing a cipher suite that uses DHE key exchange and a "Supported Groups" extension (identified by ...). The "Supported Groups" extension contains the FFDHE groups the client will accept. If the client also intends to accept ECDHE key exchange, the same "Supported Groups" extension is used for both FFDHE and ECDHE groups. Groups are ordered based on client preference, noting the additional ordering considerations in Section 6.1. """ From nobody Wed Apr 15 12:07: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 D39D31A87DE for ; Wed, 15 Apr 2015 12:07: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 GVCl-FNvAUJV for ; Wed, 15 Apr 2015 12:07:29 -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 74C5C1A87D1 for ; Wed, 15 Apr 2015 12:07:29 -0700 (PDT) Received: by oift201 with SMTP id t201so36793878oif.3 for ; Wed, 15 Apr 2015 12:07:29 -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=CjuD4iFd5Ij3fY2/Lms5rxkbKFfLqTOzFNldrcEOth0=; b=lE9/iTbkL4ftsrur44ZyN5Uemr4EtOMH97d43eDtjerUxnpvTvVEnEH1yOyUF4coh+ w6PlCtM7/APL8fC1j/7xjg631sXJH3XIgDxcOcKsqTdi5taFsAsNCDNmjvN0JoDCNuZN AbRQCUAkkLY1VrJVVYYS4CZlcGwHJoIvheN/2sst/UNMfTSngx7DYYcsoIdX5KdnDWEh 65z18q5sGla5poPRK1T+Jm06C1o+/CgQAi6IOkQeVBgYasOE8VVgXlUDnmH+rJdKalHc ChSLK++Klu993y/fMUlN0m85YMaYeI7QkdFGBVhcV3d5I2XWBWFrO6dtfsGZqIP3l/i7 j4jQ== MIME-Version: 1.0 X-Received: by 10.182.56.196 with SMTP id c4mr22653978obq.26.1429124848993; Wed, 15 Apr 2015 12:07:28 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Wed, 15 Apr 2015 12:07:28 -0700 (PDT) In-Reply-To: References: <20150414225328.924711B28A@ld9781.wdf.sap.corp> <1531163.KgFZIyykO4@pintsize.usersys.redhat.com> Date: Wed, 15 Apr 2015 12:07:28 -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] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 19:07:31 -0000 On 15 April 2015 at 11:59, Andrei Popov wrote: > Since the ALPN RFC allows the use of octet strings as ALPN IDs, it seems wrong to characterize non-ASCII IDs as "junk" or "crazy" values. ALPN IDs are not intended for display to the user, and don't have to consist of ASCII characters. I was only getting into character :) Obviously, "crazy" is subjective. I would hope that the IETF doesn't get into the business of using the whole expressive range provided by ALPN, because that only makes it harder to use. From nobody Wed Apr 15 12:24: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 B99F11A88FC for ; Wed, 15 Apr 2015 12:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHtmj3Utm75F for ; Wed, 15 Apr 2015 12:24:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0DD1A88F0 for ; Wed, 15 Apr 2015 12:24:39 -0700 (PDT) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (0.161.207.26) by BN3PR0301MB1249.namprd03.prod.outlook.com (0.161.207.25) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 15 Apr 2015 19:24:20 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([0.161.207.26]) with mapi id 15.01.0136.026; Wed, 15 Apr 2015 19:24:20 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned Thread-Index: AQHQdjMVLAECbtqN1ke7Q3E3qycYJJ1Le3aAgAAAZTCAAAq6gIABR+AAgABQyQCAAKuogIAAljgggAAJIACAAALpIIAABUcAgAADsFA= Date: Wed, 15 Apr 2015 19:24:20 +0000 Message-ID: References: <20150414225328.924711B28A@ld9781.wdf.sap.corp> <1531163.KgFZIyykO4@pintsize.usersys.redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.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:BN3PR0301MB1249; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(33656002)(76176999)(50986999)(74316001)(54356999)(102836002)(2656002)(62966003)(77156002)(46102003)(87936001)(76576001)(106116001)(99286002)(110136001)(2950100001)(122556002)(40100003)(86362001)(86612001)(19580405001)(92566002)(2900100001)(93886004)(19580395003)(7059030)(3826002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1249; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BN3PR0301MB1249; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249; x-forefront-prvs: 0547116B72 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2015 19:24:20.5141 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1249 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2015 19:24:40 -0000 VW5kZXJzdG9vZCwgYnV0IGlmIHlvdSB3YW50IHRvIHNhdmUgYnl0ZXMgaW4gdGhlIENsaWVudEhl bGxvIChlLmcuIHRvIGF2b2lkIGlzc3VlcyB3aXRoIGNlcnRhaW4gbWlkZGxlIGJveGVzKSwgdGhl biBzaG9ydCBBTFBOIElEcyBzdWNoIGFzIDB4MDEgYmVjb21lIGhpZ2hseSBhdHRyYWN0aXZlOiku DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE1 LCAyMDE1IDEyOjA3IFBNDQpUbzogQW5kcmVpIFBvcG92DQpDYzogSHViZXJ0IEthcmlvOyBtcmV4 QHNhcC5jb207IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFRMUyBBTFBOIChyZmM3 MzAxKSwgbm8gcmVzZXJ2ZWQgc2VwZXJhdG9yIGNoYXIgYW5kIHdoeSBpcyAwIG5vIGJhbm5lZA0K DQpPbiAxNSBBcHJpbCAyMDE1IGF0IDExOjU5LCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBt aWNyb3NvZnQuY29tPiB3cm90ZToNCj4gU2luY2UgdGhlIEFMUE4gUkZDIGFsbG93cyB0aGUgdXNl IG9mIG9jdGV0IHN0cmluZ3MgYXMgQUxQTiBJRHMsIGl0IHNlZW1zIHdyb25nIHRvIGNoYXJhY3Rl cml6ZSBub24tQVNDSUkgSURzIGFzICJqdW5rIiBvciAiY3JhenkiIHZhbHVlcy4gQUxQTiBJRHMg YXJlIG5vdCBpbnRlbmRlZCBmb3IgZGlzcGxheSB0byB0aGUgdXNlciwgYW5kIGRvbid0IGhhdmUg dG8gY29uc2lzdCBvZiBBU0NJSSBjaGFyYWN0ZXJzLg0KDQpJIHdhcyBvbmx5IGdldHRpbmcgaW50 byBjaGFyYWN0ZXIgOikgIE9idmlvdXNseSwgImNyYXp5IiBpcyBzdWJqZWN0aXZlLiAgSSB3b3Vs ZCBob3BlIHRoYXQgdGhlIElFVEYgZG9lc24ndCBnZXQgaW50byB0aGUgYnVzaW5lc3Mgb2YgdXNp bmcgdGhlIHdob2xlIGV4cHJlc3NpdmUgcmFuZ2UgcHJvdmlkZWQgYnkgQUxQTiwgYmVjYXVzZSB0 aGF0IG9ubHkgbWFrZXMgaXQgaGFyZGVyIHRvIHVzZS4NCg== From nobody Thu Apr 16 07:32:50 2015 Return-Path: X-Original-To: expand-draft-ietf-tls-session-hash.all@virtual.ietf.org Delivered-To: tls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 96E931A90EE; Wed, 15 Apr 2015 22:53:47 -0700 (PDT) X-Original-To: xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7122C1A90D4 for ; Wed, 15 Apr 2015 22:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 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_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 aHtWogYpljUk for ; Wed, 15 Apr 2015 22:53:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 16E691A90EC for ; Wed, 15 Apr 2015 22:53:39 -0700 (PDT) Received: from mail-lb0-x229.google.com ([2a00:1450:4010:c04::229]:35687) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yicjy-0001EY-Jz for draft-ietf-tls-session-hash.all@tools.ietf.org; Wed, 15 Apr 2015 22:53:38 -0700 Received: by lbbuc2 with SMTP id uc2so50501737lbb.2 for ; Wed, 15 Apr 2015 22:53:18 -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=VL8OdO5aAqgq0ETCKr15cuNppSszaeCLT7Sp3jN/USg=; b=fUqQQHPZWcAHS70CYm5t34CAPYqOSDJ+i1UIi50P6FNDhfgBga+z5eOwL9v6ADY9Fn y6Z5tMnKxodZr9pfu96n+GQm+cQ4zaDJ0/61CLXqy60iTW9v+6UUMLJpS+U0j7kSwRe5 2AvDN7zxPZdGmszUJjhmLMAD19pvGTBevPgbhBHJfwY13HUrPLAM8ND0mtKULofQnNZV 521YSLB9mCfSXv/wVFbTM9mvluEGMsYEGGMTId7Z6UIhiaTxbqPvxZd88Qpq0W9rlGBf Jkk9JmgFEbGYJFyU33bwlYAjc4tL652opGuMF41iPaVz0XXqTWDKMua5iiPa1Yemwo19 Q5AQ== MIME-Version: 1.0 X-Received: by 10.152.27.194 with SMTP id v2mr26562091lag.75.1429163598763; Wed, 15 Apr 2015 22:53:18 -0700 (PDT) Received: by 10.112.133.68 with HTTP; Wed, 15 Apr 2015 22:53:18 -0700 (PDT) Date: Wed, 15 Apr 2015 22:53:18 -0700 Message-ID: From: Radia Perlman To: "secdir@ietf.org" , The IESG , draft-ietf-tls-session-hash.all@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0158c2aca15e810513d1141d X-SA-Exim-Connect-IP: 2a00:1450:4010:c04::229 X-SA-Exim-Rcpt-To: draft-ietf-tls-session-hash.all@tools.ietf.org X-SA-Exim-Mail-From: radiaperlman@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-tls-session-hash.all@ietf.org Resent-Message-Id: <20150416055342.16E691A90EC@ietfa.amsl.com> Resent-Date: Wed, 15 Apr 2015 22:53:39 -0700 (PDT) Resent-From: radiaperlman@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 16 Apr 2015 07:32:49 -0700 Subject: [TLS] Secdir review of draft-ietf-tls-session-hash-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2015 05:53:47 -0000 --089e0158c2aca15e810513d1141d Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document proposes an extension and a small computation change to TLS to mitigate the "triple handshake" (and perhaps other related yet-to-be-discovered) vulnerabilities in TLS. For details of the attack, see: Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", IEEE Symposium on Security and Privacy (Oakland'14) , 2014. In my judgement, the proposed change does a fine job of addressing the vulnerability. I assume this has gotten lots of other eyes as well. I hope that someone has tested the major server implementations of TLS to assure that they follow the spec and will ignore the new unrecognized extension if a client presents it. The TLS spec clearly says that they MUST do so, but there has been a history of hacks done by implementers to get around bugs in legacy implementations. If there are a significant number of implementations that get this wrong, it would be worth considering implementing the extension in some different way (e.g. as an additional proposed cipher-suite). This vulnerability is subtle and would not affect the security of most uses of TLS, though evaluating whether it does or does not in any particular case is difficult so it makes sense to implement this change universally over time. This spec, however, takes a hard line in the trade-off between security and interoperability that I believe needs to be carefully considered. In particular, I believe lots of implementers will *not* follow this spec in implementing the feature in order to get greater interoperability with deployed systems. In particular, section 5.2 paragraph 4 & 5 say: "If the server receives a ClientHello without the extension, it SHOULD abort the handshake. If it chooses to continue, then it MUST NOT include the extension in the ServerHello." "If a client receives a ServerHello without the extension, it SHOULD abort the handshake." Implementations that follow these SHOULDs will not interoperate with any existing implementation of TLS, making a phased deployment of the new software impossible. I believe it would be preferable to say that implementations of TLS SHOULD be configurable to reject peers that do not implement the extension so that improved security at the expense of interoperability can be enabled after a critical mass of deployments exist. In section 5.3, there is similar language to disable session resumption when the extension is not present. While this may be more acceptable because it will not break interoperability, it *will* cause a significant performance degradation in some important scenarios. I would again recommend that it be a configuration parameter so that no one will refuse to deploy this change because of performance concerns. Section 5.4 also mandates breaking behavior (and here it is a MUST) in scenarios where there is most likely to be a triple handshake vulnerability. Given that there are cases with no such vulnerability and given that people will be reluctant to deploy software that turns a subtle security vulnerability into non-interoperability, I believe this should be a matter of configuration. Section 5.4 paragraph 4 seems to be undermining earlier requirements, saying that it MAY be safe (to break rules stated earlier). Taking this to heart, I would propose that the "MUST abort" clauses in sections 5.2 and 5.3 be softened to at least allow - and perhaps recommend - implementations to support this scenario. ------- Nits: In section 6.2, it is claimed that the security of TLS depends on the hash function used being collision resistant, use of MD5 and SHA1 is NOT RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1. While a worthy goal, I don't believe this enhancement makes migration away from TLS 1.0 and TLS 1.1 any more urgent. I also don't believe that TLS depends on the hash function being collision resistant (but only that it is second preimage resistant). P9: "each other identity" -> "each other's identities" P10: "that where hence" -> "that were hence" P11: "server/ Hence," -> "server. Hence, --089e0158c2aca15e810513d1141d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have review= ed this document as part of the security directorate's ongoingeffort to review all IETF documents being processed by the IESG.= These
comments were written primarily for the benefit o= f the security area
directors. Document editors and WG c= hairs should treat these comments just
like any other la= st call comments.

This document proposes an extension and a small computation change to = TLS to
mitigate the "triple handshake" (and pe= rhaps other related
yet-to-be-discovered) vulnerabilitie= s in TLS. For details of the attack,
see: Bhargavan, K.,= Delignat-Lavaud, A., Fournet, C., Pironti, A., and P.
S= trub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing
Authentication over TLS", IEEE Symposium on Security and= Privacy
(Oakland'14) , 2014.

In my judgement, the proposed chang= e does a fine job of addressing the
vulnerability. I ass= ume this has gotten lots of other eyes as well.

I hope that someone has tested the major= server implementations of TLS to
assure that they follo= w the spec and will ignore the new unrecognized
extensio= n if a client presents it. The TLS spec clearly says that they MUST<= br style=3D"font-size:12.8000001907349px">do so, but there has been a history of hacks done by implemente= rs to get
around bugs in legacy implementations. If ther= e are a significant number of
implementations that get t= his wrong, it would be worth considering
implementing th= e extension in some different way (e.g. as an additional
proposed cipher-suite).
<= br style=3D"font-size:12.8000001907349px">This vulnerability is subtle and would not affect the security = of most uses
of TLS, though evaluating whether it does= or does not in any particular case
is difficult so it m= akes sense to implement this change universally over
tim= e. This spec, however, takes a hard line in the trade-off betweensecurity and interoperability that I believe needs to be carefull= y
considered. In particular, I believe lots of implement= ers will *not* follow
this spec in implementing the feat= ure in order to get greater
interoperability with deploy= ed systems.

I= n particular, section 5.2 paragraph 4 & 5 say:

"If the server receives a Client= Hello without the extension, it SHOULD abort
the handsha= ke. If it chooses to continue, then it MUST NOT include the
extension in the ServerHello."

"If a client receives a ServerHello without= the extension, it SHOULD abort
the handshake."

Implementations = that follow these SHOULDs will not interoperate with any
existing implementation of TLS, making a phased deployment of the new
software impossible. I believe it would be preferable to say= that
implementations of TLS SHOULD be configurable to r= eject peers that do not
implement the extension so that = improved security at the expense of
interoperability can= be enabled after a critical mass of deployments exist.

In section 5.3, there is similar= language to disable session resumption when
the extensi= on is not present. While this may be more acceptable because it
will not break interoperability, it *will* cause a significant perf= ormance
degradation in some important scenarios. I would= again recommend that it be
a configuration parameter so= that no one will refuse to deploy this change
because o= f performance concerns.
Section 5.4 also mandates breaking behavior (and here it is a MU= ST) in
scenarios where there is most likely to be a trip= le handshake vulnerability.
Given that there are cases w= ith no such vulnerability and given that people
will be = reluctant to deploy software that turns a subtle security
vulnerability into non-interoperability, I believe this should be a mat= ter
of configuration.

Section 5.4 paragraph 4 seems to be undermining= earlier requirements, saying
that it MAY be safe (to br= eak rules stated earlier). Taking this to heart, I
would= propose that the "MUST abort" clauses in sections 5.2 and 5.3 be=
softened to at least allow - and perhaps recommend - im= plementations to
support this scenario.

-------

Nits:

In section 6.2, it is claimed that the s= ecurity of TLS depends on the hash
function used being c= ollision resistant, use of MD5 and SHA1 is NOT
RECOMMEND= ED. That would rule out use of TLS 1.0 and TLS 1.1. While a worthygoal, I don't believe this enhancement makes migration away = from TLS 1.0 and
TLS 1.1 any more urgent. I also don'= ;t believe that TLS depends on the hash
function being c= ollision resistant (but only that it is second preimage
= resistant).

P= 9: "each other identity" -> "each other's identities&= quot;
P10: "that where hence" -> "that= were hence"
P11: "server/ Hence," -> = "server. Hence,
--089e0158c2aca15e810513d1141d-- From nobody Thu Apr 16 07:32:51 2015 Return-Path: X-Original-To: expand-draft-ietf-tls-session-hash.all@virtual.ietf.org Delivered-To: tls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 841841B2AF2; Thu, 16 Apr 2015 00:07:12 -0700 (PDT) X-Original-To: xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9EB1B2AF1 for ; Thu, 16 Apr 2015 00:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.883 X-Spam-Level: X-Spam-Status: No, score=-0.883 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, 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 2U-q6G9anXek for ; Thu, 16 Apr 2015 00:07:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 371DB1B2AEF for ; Thu, 16 Apr 2015 00:07:11 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:41475) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YidtB-0000Kn-Uh for draft-ietf-tls-session-hash.all@tools.ietf.org; Thu, 16 Apr 2015 00:07:10 -0700 X-IronPort-AV: E=Sophos;i="5.11,586,1422918000"; d="scan'208";a="111699762" Received: from 166.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.166]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 16 Apr 2015 09:06:43 +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: Date: Thu, 16 Apr 2015 09:06:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Radia Perlman X-Mailer: Apple Mail (2.1878.6) X-SA-Exim-Connect-IP: 192.134.164.104 X-SA-Exim-Rcpt-To: draft-ietf-tls-session-hash.all@tools.ietf.org X-SA-Exim-Mail-From: karthik.bhargavan@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-tls-session-hash.all@ietf.org Resent-Message-Id: <20150416070711.371DB1B2AEF@ietfa.amsl.com> Resent-Date: Thu, 16 Apr 2015 00:07:11 -0700 (PDT) Resent-From: karthik.bhargavan@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 16 Apr 2015 07:32:49 -0700 Cc: draft-ietf-tls-session-hash.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [TLS] Secdir review of draft-ietf-tls-session-hash-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2015 07:07:12 -0000 Hi Radia, Thanks for the comments. I made many of the smaller changes, and have = some questions about the interop concerns. > In particular, section 5.2 paragraph 4 & 5 say: >=20 > "If the server receives a ClientHello without the extension, it SHOULD = abort > the handshake. If it chooses to continue, then it MUST NOT include the > extension in the ServerHello." >=20 > "If a client receives a ServerHello without the extension, it SHOULD = abort > the handshake.=94 The style we chose was to say that the client/server SHOULD abort the = handshake, but we also say in paragraph 7:=20 "If the client or server choose to continue a full handshake without the = extension, they use the legacy master secret derivation for the new = session. In this case, the considerations in section 5.4 apply.=94 That is, we do offer them the choice of opting out of this draft for = interoperability, by following the recommendations in 5.4. We could make this forward pointer more explicit by saying instead: =93In order to interoperate with legacy peers, some lients and servers = may choose to=20 to continue a full handshake without the extension. In this case, they = use the legacy master secret derivation for the new session, and the=20 considerations in section 5.4 apply.=94 Would this assuage the security/interoperability concern? > In section 5.3, there is similar language to disable session = resumption when > the extension is not present. While this may be more acceptable = because it > will not break interoperability, it *will* cause a significant = performance > degradation in some important scenarios. I would again recommend that = it be > a configuration parameter so that no one will refuse to deploy this = change > because of performance concerns. During resumption we use similar language to point forward to section = 5.2 if the client or server chooses to continue without the extension. > Section 5.4 also mandates breaking behavior (and here it is a MUST) in > scenarios where there is most likely to be a triple handshake = vulnerability. > Given that there are cases with no such vulnerability and given that = people > will be reluctant to deploy software that turns a subtle security > vulnerability into non-interoperability, I believe this should be a = matter > of configuration. This case seems most difficult, because section 5.4 is the defense of=20 last resort. Weakening the MUST requirements here would, in our mind, be tantamount to disabling the extension altogether.=20 Recall that in the triple handshake attack, the man-in-the-middle is a = valid peer who is trying to fool both the client and the server. Hence, we cannot rely on this man-in-the-middle sending the extension. If we allow handshakes without the extension, the attack cannot be prevented, only = mitigated. The MUSTs in this section try to enforce these mitigations. Best regards, Karthik >=20 > Section 5.4 paragraph 4 seems to be undermining earlier requirements, = saying > that it MAY be safe (to break rules stated earlier). Taking this to = heart, I > would propose that the "MUST abort" clauses in sections 5.2 and 5.3 be > softened to at least allow - and perhaps recommend - implementations = to > support this scenario. >=20 > ------- >=20 > Nits: >=20 > In section 6.2, it is claimed that the security of TLS depends on the = hash > function used being collision resistant, use of MD5 and SHA1 is NOT > RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1. While a = worthy > goal, I don't believe this enhancement makes migration away from TLS = 1.0 and > TLS 1.1 any more urgent. I also don't believe that TLS depends on the = hash > function being collision resistant (but only that it is second = preimage > resistant). >=20 > P9: "each other identity" -> "each other's identities" > P10: "that where hence" -> "that were hence" > P11: "server/ Hence," -> "server. Hence, From nobody Thu Apr 16 08:03: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 6D7441A1A50 for ; Thu, 16 Apr 2015 08:03: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, 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 h5_7xnqNZlWX for ; Thu, 16 Apr 2015 08:03:28 -0700 (PDT) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.149.101]) (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 ED7101A00E0 for ; Thu, 16 Apr 2015 08:03:08 -0700 (PDT) Received: by gateway34.websitewelcome.com (Postfix, from userid 500) id EFB31726CC16; Thu, 16 Apr 2015 09:59:05 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway34.websitewelcome.com (Postfix) with ESMTP id DFCD6726CBDF for ; Thu, 16 Apr 2015 09:59:05 -0500 (CDT) Received: from [96.231.227.6] (port=60667 helo=[192.168.1.10]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YilFw-0002bs-AL for tls@ietf.org; Thu, 16 Apr 2015 09:59:04 -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: Date: Thu, 16 Apr 2015 10:59:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39536882-3644-497B-94ED-520A8DEFAD0B@ieca.com> References: <874mohqmk2.fsf@alice.fifthhorseman.net> To: "tls@ietf.org" 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: 96.231.227.6 X-Exim-ID: 1YilFw-0002bs-AL X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.10]) [96.231.227.6]:60667 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] please review (was: Re: FFDHE and SHOULDs on usage) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2015 15:03:29 -0000 Top posting here to make sure folks not that Martin=92s de-2119ing some = of the text, but to me at least it looks like it expresses the same = requirements. Please let us know whether you disagree with this change = by the 2015-04-25. spt On Apr 15, 2015, at 15:05, Martin Thomson = wrote: > On 15 April 2015 at 11:22, Daniel Kahn Gillmor = wrote: >> - A client that offers any of these values in the = elliptic_curves >> - extension SHOULD ALSO include at least one FFDHE ciphersuite = in >> - the Client Hello. >> + A client that offers a "Supported Groups" extension >> + containing an FFDHE group should also include at least one = FFDHE >> + ciphersuite in the Client Hello. >=20 > I apologize for not completing the >=20 > It's been a while, so I went back and re-read this little bit, > prompted largely by your choice to move to a lowercase should: >=20 > The compatible client that wants to be able to negotiate strong = FFDHE > SHOULD send a "Supported Groups" extension (identified by type > elliptic_curves(10) in [RFC4492]) in the ClientHello, and include a > list of known FFDHE groups in the extension data, ordered from most > preferred to least preferred. If the client also supports and wants > to offer ECDHE key exchange, it MUST use a single "Supported Groups" > extension to include all supported groups (both ECDHE and FFDHE > groups). The ordering SHOULD be based on client preference, but see > Section 6.1 for more nuance. >=20 > A client that offers any of these values in the elliptic_curves > extension SHOULD ALSO include at least one FFDHE ciphersuite in the > Client Hello. >=20 > This is a little over-2119-y for me. How about: >=20 > """ > A client that wants to negotiatiate strong FFDHE sends a ClientHello > containing a cipher suite that uses DHE key exchange and a "Supported > Groups" extension (identified by ...). The "Supported Groups" > extension contains the FFDHE groups the client will accept. If the > client also intends to accept ECDHE key exchange, the same "Supported > Groups" extension is used for both FFDHE and ECDHE groups. >=20 > Groups are ordered based on client preference, noting the additional > ordering considerations in Section 6.1. > """ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Apr 16 08:36:11 2015 Return-Path: X-Original-To: expand-draft-ietf-tls-session-hash.all@virtual.ietf.org Delivered-To: tls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 740521A89C5; Thu, 16 Apr 2015 08:34:20 -0700 (PDT) X-Original-To: xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F031A89EF for ; Thu, 16 Apr 2015 08:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 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_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 uJtdbNJA0rgk for ; Thu, 16 Apr 2015 08:34:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 355491A8AB7 for ; Thu, 16 Apr 2015 08:33:27 -0700 (PDT) Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:33666) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yiln6-0005FT-8m for draft-ietf-tls-session-hash.all@tools.ietf.org; Thu, 16 Apr 2015 08:33:26 -0700 Received: by wiax7 with SMTP id x7so14450156wia.0 for ; Thu, 16 Apr 2015 08:33:10 -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=t5mvbI2/US9Pkr8lrV7I4jj+eqnwmUjFhRoS9aCD000=; b=hkNsITo8FpupbWJVCNE/H6NEZwNMseiAAgfeAidHqe6Av0A/TBNUCpNAvYaNRoVeV6 Jvv+nMeC2u+V2umgPpj0rXkMV5j7owytJGP60tOM3A9TN8U/63m5rbXuVWAaDMI/WINf xRnbiv+G85DNepPPYBOIqIIvVz1iNOJuPsxNcBUMCL44fxTyzaUstrn6kwyHxmYhaqmQ WQzaD8eqdqB3HH8ZLs7FGo/k57AbqJs23kpaFHhGcZ5B7ArllHN4JJksSmqUW7dUWj23 M4vsIGWW6iG7GqtrhJFhj+S4mGdGhkxxwaMcxTORFDRNcFJoZHfs/ZcPxtMLuGpWd4HN yqkQ== MIME-Version: 1.0 X-Received: by 10.194.9.98 with SMTP id y2mr62745068wja.85.1429198389460; Thu, 16 Apr 2015 08:33:09 -0700 (PDT) Received: by 10.194.136.233 with HTTP; Thu, 16 Apr 2015 08:33:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Apr 2015 08:33:09 -0700 Message-ID: From: Watson Ladd To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 2a00:1450:400c:c05::22e X-SA-Exim-Rcpt-To: draft-ietf-tls-session-hash.all@tools.ietf.org X-SA-Exim-Mail-From: watsonbladd@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-tls-session-hash.all@ietf.org Resent-Message-Id: <20150416153327.355491A8AB7@ietfa.amsl.com> Resent-Date: Thu, 16 Apr 2015 08:33:27 -0700 (PDT) Resent-From: watsonbladd@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 16 Apr 2015 08:36:08 -0700 Cc: "secdir@ietf.org" , draft-ietf-tls-session-hash.all@tools.ietf.org, Radia Perlman , The IESG Subject: Re: [TLS] Secdir review of draft-ietf-tls-session-hash-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2015 15:34:20 -0000 On Thu, Apr 16, 2015 at 12:06 AM, Karthikeyan Bhargavan wrote: > Hi Radia, > > Thanks for the comments. I made many of the smaller changes, and have som= e > questions about the interop concerns. > >> In particular, section 5.2 paragraph 4 & 5 say: >> >> "If the server receives a ClientHello without the extension, it SHOULD a= bort >> the handshake. If it chooses to continue, then it MUST NOT include the >> extension in the ServerHello." >> >> "If a client receives a ServerHello without the extension, it SHOULD abo= rt >> the handshake.=E2=80=9D > > The style we chose was to say that the client/server SHOULD abort the han= dshake, > but we also say in paragraph 7: > > "If the client or server choose to continue a full handshake without the = extension, they use the legacy master secret derivation for the new session= . In this case, the considerations in section 5.4 apply.=E2=80=9D > > That is, we do offer them the choice of opting out of this draft for inte= roperability, by following > the recommendations in 5.4. > > We could make this forward pointer more explicit by saying instead: > > =E2=80=9CIn order to interoperate with legacy peers, some lients and serv= ers may choose to > to continue a full handshake without the extension. In this case, they u= se > the legacy master secret derivation for the new session, and the > considerations in section 5.4 apply.=E2=80=9D > > Would this assuage the security/interoperability concern? > > >> In section 5.3, there is similar language to disable session resumption = when >> the extension is not present. While this may be more acceptable because = it >> will not break interoperability, it *will* cause a significant performan= ce >> degradation in some important scenarios. I would again recommend that it= be >> a configuration parameter so that no one will refuse to deploy this chan= ge >> because of performance concerns. I seem to recall a discussion about this, where my minority position was that breaking renegotiation instead was more acceptable. We need to break one, and renegotiation is not used nearly as commonly for browsers. > > During resumption we use similar language to point forward to section 5.2 > if the client or server chooses to continue without the extension. > >> Section 5.4 also mandates breaking behavior (and here it is a MUST) in >> scenarios where there is most likely to be a triple handshake vulnerabil= ity. >> Given that there are cases with no such vulnerability and given that peo= ple >> will be reluctant to deploy software that turns a subtle security >> vulnerability into non-interoperability, I believe this should be a matt= er >> of configuration. > > This case seems most difficult, because section 5.4 is the defense of > last resort. Weakening the MUST requirements here would, in our mind, > be tantamount to disabling the extension altogether. Web browsers have adopted a more minimal solution, namely not permitting renegotiation to change certificates. I doubt that the stricter defense in 5.4 will cause interoperability issues, and it may have been adopted by some of them. Input from browser writers would be greatly appreciated. Sincerely, Watson Ladd > > Recall that in the triple handshake attack, the man-in-the-middle is a v= alid peer > who is trying to fool both the client and the server. Hence, we cannot > rely on this man-in-the-middle sending the extension. If we allow > handshakes without the extension, the attack cannot be prevented, only mi= tigated. > The MUSTs in this section try to enforce these mitigations. > > Best regards, > Karthik > > >> >> Section 5.4 paragraph 4 seems to be undermining earlier requirements, sa= ying >> that it MAY be safe (to break rules stated earlier). Taking this to hear= t, I >> would propose that the "MUST abort" clauses in sections 5.2 and 5.3 be >> softened to at least allow - and perhaps recommend - implementations to >> support this scenario. >> >> ------- >> >> Nits: >> >> In section 6.2, it is claimed that the security of TLS depends on the ha= sh >> function used being collision resistant, use of MD5 and SHA1 is NOT >> RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1. While a wor= thy >> goal, I don't believe this enhancement makes migration away from TLS 1.0= and >> TLS 1.1 any more urgent. I also don't believe that TLS depends on the ha= sh >> function being collision resistant (but only that it is second preimage >> resistant). >> >> P9: "each other identity" -> "each other's identities" >> P10: "that where hence" -> "that were hence" >> P11: "server/ Hence," -> "server. Hence, > > _______________________________________________ > 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 schnabbel@inurbanus.nl Thu Apr 16 09:07: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 B41A61ACDEA for ; Thu, 16 Apr 2015 09:07:30 -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_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_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 cf8WqjW9HHte for ; Thu, 16 Apr 2015 09:07:29 -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 E47851A891D for ; Thu, 16 Apr 2015 09:07:28 -0700 (PDT) Received: by wgin8 with SMTP id n8so85958487wgi.0 for ; Thu, 16 Apr 2015 09:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inurbanus.nl; s=google-inurb; h=mime-version:date:message-id:subject:from:to:content-type; bh=bOzaDQtaGAkzaWICoXHgQgS253gLYtLWwfOu/Sgul9A=; b=VZ7dgidv/7sgJG8C5MA3+F0EF7QqKM8+IxNYp9HMPpxNt9ZuyhQ1ghUKyFlRO5hF71 1a7tw8uG4gwUetxpQRWi9UyDPHG/B8MA75huNdbYq3V1tl+mZT/bbJmNMkJBHHBrM78v z0ebbvi61+9m1pS/hf4boJk8GNnRXdQeZqCVM= 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=bOzaDQtaGAkzaWICoXHgQgS253gLYtLWwfOu/Sgul9A=; b=VEBO7RJP9KiHS2WZpkk0vEDIcCAjvBhp6w97Yu+wzzYIp8syeOV56sfg2Y+Il77pYQ Mtzt2qnJmyVxe7FbuiylVUEUN+hwq5T879s8KecVOzlf746G8KUKjwDrF3WVjzJE+FlX 8m2faI1LI7BPK+CK4G34ZSG7m/Xde6Ggpt+slb145ujntJz9CpYDbugwY3m/fhJrjX/7 wlf+MWJl6WDdO7lSHMNes6kNaEuOS+Mz4wAsgVaHBn2//u4zBwY3V/wfMRjtDW6kv30g ylTRU2WUItwiYoW5T2OBhpQfMO3A2bM1UsgTTws01HRuKjG3zSf94QQZNlkGF+tQsqYy snVw== X-Gm-Message-State: ALoCoQkGYBkmeNE9xtig0Y7tDeS7qCUIehHq8JjEZaI2bEG+4JAmn8CpCsaHDs5hHOq2mxeHcBS/ MIME-Version: 1.0 X-Received: by 10.194.159.105 with SMTP id xb9mr62114753wjb.156.1429200447619; Thu, 16 Apr 2015 09:07:27 -0700 (PDT) Received: by 10.28.104.138 with HTTP; Thu, 16 Apr 2015 09:07:27 -0700 (PDT) Date: Thu, 16 Apr 2015 18:07:27 +0200 Message-ID: From: Thijs van Dijk To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11c3aa58fe63030513d9a836 Archived-At: Subject: [TLS] Request for clarification: "in the same flight" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2015 16:11:00 -0000 --001a11c3aa58fe63030513d9a836 Content-Type: text/plain; charset=UTF-8 Dear all, I'm working on a hobby implementation of TLS1.3 as a way of vetting the spec draft, and I ran into an issue with sending the ClientKeyShare. The handshake spec (7.2) says it should be sent "in the same flight" as the ClientHello message, without specifying the correct encapsulation method. Maybe it's just me, but this phrase could be interpreted as either the following: TCP packet \- TLSPlaintext (content_type 22) |- Handshake (msg_type 1) | \- ClientHello \- Handshake (msg_type 5) \- ClientKeyShare or: TCP packet | TLSPlaintext (content_type 22) | \- Handshake (msg_type 1) | \- ClientHello \- TLSPlaintext (content_type 22) \- Handshake (msg_type 5) \- ClientKeyShare If I were to venture a guess, I'd say the two are equivalent, but it's also conceivable that some implementations require any TLSPlaintext to contain exactly one child struct. (Source: mine does; I'm trying to figure out if that's a bug or not.) I think that if we have a preference for either one, the spec should reflect that. If not, it may be wise to explicitly declare both options to be correct. Thoughts? -Thijs (I have also opened a Github issue to this effect: https://github.com/tlswg/tls13-spec/issues/164 ) --001a11c3aa58fe63030513d9a836 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

I'm working on a hobby implementation= of TLS1.3 as a way of vetting the spec draft, and I ran into an issue with= sending the ClientKeyShare.

The handshake spec (7.2) says it should= be sent "in the same flight" as the ClientHello message, without= specifying the correct encapsulation method. Maybe it's just me, but t= his phrase could be interpreted as either the following:

TCP packet
=C2=A0\- TLSPlaintext =C2=A0(conten= t_type 22)
=C2=A0 =C2=A0 =C2=A0|- Handshake (msg_type 1)
=C2=A0 =C2= =A0 =C2=A0| =C2=A0 \- ClientHello
=C2=A0 =C2=A0 =C2=A0\- Handshake (msg_= type 5)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\- ClientKeyShare
or:

TCP packet
=C2=A0| =C2= =A0TLSPlaintext =C2=A0(content_type 22)
=C2=A0| =C2=A0 \- Handshake (msg= _type 1)
=C2=A0| =C2=A0 =C2=A0 =C2=A0 \- ClientHello
=C2=A0\- TLSPlai= ntext =C2=A0(content_type 22)
=C2=A0 =C2=A0 =C2=A0\- Handshake (msg_type= 5)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\- ClientKeyShare

If= I were to venture a guess, I'd say the two are equivalent, but it'= s also conceivable that some implementations require any TLSPlaintext to co= ntain exactly one child struct. (Source: mine does; I'm trying to figur= e out if that's a bug or not.)

I think that if we have a prefere= nce for either one, the spec should reflect that. If not, it may be wise to= explicitly declare both options to be correct.

Thoughts?


-Thijs


(I h= ave also opened a Github issue to this effect:=C2=A0https://github.com/tlswg/tls13-spec/iss= ues/164 )

--001a11c3aa58fe63030513d9a836-- From nobody Thu Apr 16 09:21: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 C0AA11B3293 for ; Thu, 16 Apr 2015 09:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w7Kod52hrycI for ; Thu, 16 Apr 2015 09:21:06 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.15.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFD21B328F for ; Thu, 16 Apr 2015 09:21:06 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id CA14BF6B94D29; Thu, 16 Apr 2015 11:21:05 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id B91D4F6B94CE1 for ; Thu, 16 Apr 2015 11:21:05 -0500 (CDT) Received: from [96.231.227.6] (port=61494 helo=[192.168.1.10]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YimXG-0004zo-Tl; Thu, 16 Apr 2015 11:21:03 -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: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> Date: Thu, 16 Apr 2015 12:21:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <64FA6BC3-49D0-4EF6-8332-4ADBDB62BAA3@ieca.com> References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> To: "" 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: 96.231.227.6 X-Exim-ID: 1YimXG-0004zo-Tl X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.10]) [96.231.227.6]:61494 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: draft-bmoeller-tls-falsestart@tools.ietf.org Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2015 16:21:07 -0000 Based on list discussion we=92re going to go adopt this draft as a WG. Bodo please submit a WG version of this draft so we can begin addressing = Brian=92s comments in the WG -01 version. Thanks everybody! spt On Mar 31, 2015, at 12:20, Sean Turner wrote: > All, >=20 > There=92s been some interested expressed in having = http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted = as a TLS WG item. If you would like for this draft to become a WG = document, and you are willing to review drafts as it moves through the = process please indicate as much on this thread. If you are opposed to = this being a WG document, please say so (and say why). Thanks in = advance. >=20 > J&S From nobody Thu Apr 16 11:38:17 2015 Return-Path: X-Original-To: expand-draft-ietf-tls-negotiated-ff-dhe.all@virtual.ietf.org Delivered-To: tls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 073951B2EF4; Thu, 16 Apr 2015 11:11:27 -0700 (PDT) X-Original-To: xfilter-draft-ietf-tls-negotiated-ff-dhe.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-tls-negotiated-ff-dhe.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AFF1B2ED4 for ; Thu, 16 Apr 2015 11:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021] 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 gMa-tfBp70Vi for ; Thu, 16 Apr 2015 11:11:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 934C91B2EBD for ; Thu, 16 Apr 2015 11:11:26 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:59658 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YioG1-0002OF-FN for draft-ietf-tls-negotiated-ff-dhe.all@tools.ietf.org; Thu, 16 Apr 2015 11:11:25 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t3GIBDcN014244; Thu, 16 Apr 2015 18:11:13 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id E694CC20812; Thu, 16 Apr 2015 18:11:13 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <20150404020709.31136.95847.idtracker@ietfa.amsl.com> References: <20150404020709.31136.95847.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #817122 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 16 Apr 2015 18:11:13 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-tls-negotiated-ff-dhe.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-tls-negotiated-ff-dhe.all@ietf.org Resent-Message-Id: <20150416181126.934C91B2EBD@ietfa.amsl.com> Resent-Date: Thu, 16 Apr 2015 11:11:26 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 16 Apr 2015 11:38:15 -0700 Cc: draft-ietf-tls-negotiated-ff-dhe.all@tools.ietf.org, iesg@ietf.org Subject: [TLS] [IANA #817122] Last Call: (Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.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, 16 Apr 2015 18:11:28 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-tls-negotiated-ff-dhe-08. Please see below and report any inaccuracies as soon as possible. IANA's reviewer has the following comments: IANA understands that, upon approval of this document, there is a single action that IANA must complete. In the EC Named Curve Registry in the Transport Layer Security (TLS) Parameters registry at https://www.iana.org/assignments/tls-parameters/ A note will be added to the registry indicating that values from 256-511 (inclusive) are set aside for "Finite Field Diffie-Hellman groups," and that all other entries in the registry are "Elliptic curve groups." This document will be listed as an additional reference for the registry itself. In addition, the four highest codepoints in the Finite Field Diffie-Hellman group range (508-511, inclusive) will be marked "Reserved for Private Use." Finally, five new registration will be added the registry (along with the PRIVATE USE restriction) as follows: +---------------------+-------------+---------+-----------------+ | Value | Description | DTLS-OK | Reference | +---------------------+-------------+---------+-----------------+ | 256 | ffdhe2048 | Y | [ RFC-to-be ] | | 257 | ffdhe3072 | Y | [ RFC-to-be ] | | 258 | ffdhe4096 | Y | [ RFC-to-be ] | | 259 | ffdhe6144 | Y | [ RFC-to-be ] | | 260 | ffdhe8192 | Y | [ RFC-to-be ] | | 508-511 (inclusive) | Reserved for Private Use | - | [ RFC-to-be ] | +---------------------+-------------+---------+-----------------+ Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Amanda Baber IANA Request Specialist ICANN (END IANA LAST CALL COMMENTS) On Sat Apr 04 02:08:03 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > - 'Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-04-17. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > 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 file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Thu Apr 16 13:56: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 CC56C1A6F7A for ; Thu, 16 Apr 2015 13:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543] 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 garXUVwy3vZ9 for ; Thu, 16 Apr 2015 13:56:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CB6DF1A6EF0 for ; Thu, 16 Apr 2015 13:56:18 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 2A9D2F984 for ; Thu, 16 Apr 2015 16:56:17 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5F218209E8; Thu, 16 Apr 2015 10:44:08 -0400 (EDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: References: <874mohqmk2.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 16 Apr 2015 10:44:08 -0400 Message-ID: <87fv80nnev.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] FFDHE and SHOULDs on usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2015 20:56:20 -0000 On Wed 2015-04-15 15:05:26 -0400, Martin Thomson wrote: > On 15 April 2015 at 11:22, Daniel Kahn Gillmor wrote: >> - A client that offers any of these values in the elliptic_curves >> - extension SHOULD ALSO include at least one FFDHE ciphersuite in >> - the Client Hello. >> + A client that offers a "Supported Groups" extension >> + containing an FFDHE group should also include at least one FFDHE >> + ciphersuite in the Client Hello. > > I apologize for not completing the :) > It's been a while, so I went back and re-read this little bit, > prompted largely by your choice to move to a lowercase should: > > The compatible client that wants to be able to negotiate strong FFDHE > SHOULD send a "Supported Groups" extension (identified by type > elliptic_curves(10) in [RFC4492]) in the ClientHello, and include a > list of known FFDHE groups in the extension data, ordered from most > preferred to least preferred. If the client also supports and wants > to offer ECDHE key exchange, it MUST use a single "Supported Groups" > extension to include all supported groups (both ECDHE and FFDHE > groups). The ordering SHOULD be based on client preference, but see > Section 6.1 for more nuance. > > A client that offers any of these values in the elliptic_curves > extension SHOULD ALSO include at least one FFDHE ciphersuite in the > Client Hello. > > This is a little over-2119-y for me. How about: > > """ > A client that wants to negotiatiate strong FFDHE sends a ClientHello > containing a cipher suite that uses DHE key exchange and a "Supported > Groups" extension (identified by ...). The "Supported Groups" > extension contains the FFDHE groups the client will accept. If the > client also intends to accept ECDHE key exchange, the same "Supported > Groups" extension is used for both FFDHE and ECDHE groups. > > Groups are ordered based on client preference, noting the additional > ordering considerations in Section 6.1. > """ I'm willing to drop the 2119 language in this section if other people think that it is inappropriate. Some of it seems relevant for interop to me (e.g. 'MUST use a single "Supported Groups" extension' just echoes 5246's restriction 'There MUST NOT be more than one extension of the same type.') What do others think here? Also, this rewrite says "ordered based on client preferences" but doesn't indicate which order based on client preferences: most preferred to least preferred or the other way around. It may be pedantic, but this is exactly the sort of pedantry that RFCs should include. --dkg From nobody Thu Apr 16 13:59: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 8E2A81A6F7A for ; Thu, 16 Apr 2015 13:59: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 aofgCHVlNXis for ; Thu, 16 Apr 2015 13:59:44 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003: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 B116B1A7008 for ; Thu, 16 Apr 2015 13:59:43 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so51387070obb.2 for ; Thu, 16 Apr 2015 13:59: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:date:message-id:subject:from:to :cc:content-type; bh=AU0Vm8RcSm3DQqYx4NkI/T4ZsbCASG739X+Sa8KvSV0=; b=asamZTToP8Jj4aZFBOwwbGczP6XYNchZIeb3Djh5nhXsBFBxOeDlHIqeWVZnpWb0Mv Ej985CrBB/0vmRdNx9jxoUetpKxmOrBxkdIY881PhBkA0Yo8rsuEUfn3V7kSLmNOZCK3 6+hvD4Tb6mZXxj/SSgnmj4UPLXQQ/ANZMizDYBL9neWiEiy7ZiAgOC+Huri77LZdW11o VdjFP+/hvKBkZoj0fJ6nALZ0eqKgHYg9Q4iem+5clvkiCo682nhYMFGr0EYMNsCHye4x gfQnn1X+f+cLW53JGcH5KEgsd+KtD9p73Xcsx1yfiOINz4e4VUq2uB+lE2DKWpxx9cvD 2Mog== MIME-Version: 1.0 X-Received: by 10.182.68.103 with SMTP id v7mr26800615obt.82.1429217983294; Thu, 16 Apr 2015 13:59:43 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Thu, 16 Apr 2015 13:59:43 -0700 (PDT) In-Reply-To: <87fv80nnev.fsf@alice.fifthhorseman.net> References: <874mohqmk2.fsf@alice.fifthhorseman.net> <87fv80nnev.fsf@alice.fifthhorseman.net> Date: Thu, 16 Apr 2015 13:59:43 -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] FFDHE and SHOULDs on usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2015 20:59:45 -0000 On 16 April 2015 at 07:44, Daniel Kahn Gillmor wrote: > Also, this rewrite says "ordered based on client preferences" but > doesn't indicate which order based on client preferences: most preferred > to least preferred or the other way around. It may be pedantic, but > this is exactly the sort of pedantry that RFCs should include. I was merely being (over-)economical. By all means, add the qualification. From nobody Thu Apr 16 15:54: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 BE76A1A916A; Thu, 16 Apr 2015 15:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYEqDsY6ltBd; Thu, 16 Apr 2015 15:54:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E571A9143; Thu, 16 Apr 2015 15:54:31 -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.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416225431.22606.93480.idtracker@ietfa.amsl.com> Date: Thu, 16 Apr 2015 15:54:31 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-session-hash-05.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, 16 Apr 2015 22:54:32 -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) Session Hash and Extended Master Secret Extension Authors : Karthikeyan Bhargavan Antoine Delignat-Lavaud Alfredo Pironti Adam Langley Marsh Ray Filename : draft-ietf-tls-session-hash-05.txt Pages : 14 Date : 2015-04-16 Abstract: The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-session-hash-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-05 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 Fri Apr 17 05:35: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 9627B1B2BAA for ; Fri, 17 Apr 2015 05:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYCyE-pIMrzS for ; Fri, 17 Apr 2015 05:35:11 -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 8E0D41B2B9E for ; Fri, 17 Apr 2015 05:35:11 -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 EEF6F8E3EA; Fri, 17 Apr 2015 12:35:10 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3HCZ8pc027536 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 17 Apr 2015 08:35:09 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 17 Apr 2015 14:34:58 +0200 Message-ID: <57175023.AVSjdYu02a@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.4 (Linux/3.19.3-100.fc20.x86_64; KDE/4.14.6; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart23825295.ulLHm7Grgd"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] Request for clarification: "in the same flight" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 12:35:13 -0000 --nextPart23825295.ulLHm7Grgd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 16 April 2015 18:07:27 Thijs van Dijk wrote: > If I were to venture a guess, I'd say the two are equivalent, but it'= s also > conceivable that some implementations require any TLSPlaintext to con= tain > exactly one child struct. (Source: mine does; I'm trying to figure ou= t if > that's a bug or not.) It is a bug, see RFC 5246, section 6.2.1, specifically: Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records). =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 --nextPart23825295.ulLHm7Grgd 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 iQIcBAABCgAGBQJVMP38AAoJEJKo0bgB0vX19RgQAIGcG5XFznuQeYgZr870k+F4 tMUU916v0zS2qsNCqQIqKTMTWt9AP4U8YDJ52ozmzg8CRRz60IoVnN9zqzvGEryC ibV7ksKSXURMnpgGlKGHOHVnXXlRgDZLS0Rw0LaOHpLJ2AUk14HkYoAOtqWRphF8 xNNc+5WodXEN9yHTzpsDIjXzW6k98Unkw8emOI+uL24gNRl2efR02r9VpOBTnX/5 8yD3XEabbsziJNdrQW9dECm22D3hqZLNSngMYwzWmJN5KiTmJQaiZ27138mEdTgs N7W2WhmUW6flRGheOGWSwTrnie/ILX4OEyat6K+TWCn1X9NruaITxYVMm5Vd2Bb7 6nmNSI/GgL9gYpR5wIelwH7+JD/1s5dg+HvDOPejco35GIqdLkn/GGpgylEh/mcZ IhTuDx2FoQl5f0oaundPGuu3t/r/FsnutUI7IMeTn5GMo9efO5xIjNpIdd2cA5sT SaypZTRFvRTBB0OXS5JJpgckN+O/tzVa8Fcn/5lw9VGlxBL4PFbIlSL5omX6CUAw bPRnFVzuWG/0okx1b32aSeShtvzTQGKtBDolX3bid5E0jt1peYGEc5bBxqAMLw9u 10giv+4/UPiRsrqElhKML0gOEE7fCyO+3f0YSSnG09k+c1kknDnlusHzWkVBJNe9 62hftZnul3RoSvy8HR4l =QJEy -----END PGP SIGNATURE----- --nextPart23825295.ulLHm7Grgd-- From nobody Fri Apr 17 05:47: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 907291B2BEC for ; Fri, 17 Apr 2015 05:47:46 -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 YzAKg-0rqMmh for ; Fri, 17 Apr 2015 05:47:43 -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 C197D1B2BE7 for ; Fri, 17 Apr 2015 05:47:42 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 068C5412F; Fri, 17 Apr 2015 15:47:40 +0300 (EEST) Date: Fri, 17 Apr 2015 15:47:39 +0300 From: Ilari Liusvaara To: Joseph Salowey Message-ID: <20150417124739.GA30086@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] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 12:47:46 -0000 On Fri, Apr 03, 2015 at 01:34:15PM -0700, Joseph Salowey wrote: > In the interim meeting we had consensus to use an implicit IV for AEAD. > The proposal was to use the record sequence number and pad with zeros as > described in pull request 155 ( > https://github.com/tlswg/tls13-spec/pull/155/files). This was also > discussed in the IETF-92 meeting in Dallas along with options to change the > offset. The consensus was to stay with the original proposal. We are > posting to the mailing list to confirm this consensus. I really do not like padding with zeroes, since it would weaken encryption relative to TLS v1.2. And this is not just if the symmetric encryption is already broken, but applies to all[1]. This is especially prominent with AES-128[2]. And "Just use AES-256" does not solve the issue, since it will probably not be available in important environments[3]. None of TLS v1.2, IPSec nor SSH use AES-GCM this way, all have secret[4] fixed nonce-parts (SSH does use Chacha20 without per- connection nonce[5]). OTOH, the explicit per-record nonce field for AES-GCM seems really unnecressary. Everybody uses it sequentially anyway, so it just wastes 8 bytes per record. [1] If the algorithm is broken, if the zeroes or even just known nonce further help breaking depends on type of attack (but of course, one rather not use such broken algorithms).[6] [2] Substantial weakening happens far before collisions become likely. So much less than AGL's "2^60" mentioned in the meeting. [3] And I suppose nobody really likes AES-192 (despite the fact that seemingly just about every CPU with "AES acceleration" is able to accelerate that too). :-> [4] Secret meaning those are derived from the main key block. [5] The encrypted stream looks like random noise, which makes it harder to tell where packet boundaries are (and Chacha20 is 256-bit keys anyway). [6] SSLv3 had known nonces for EXPORT ciphers, but secret ones for strong ones. Hmm... -Ilari From nobody Fri Apr 17 07:00: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 649811B2D06 for ; Fri, 17 Apr 2015 07:00:45 -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_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_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 sYRswd0IA4dg for ; Fri, 17 Apr 2015 07:00:44 -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 73EA31B2D08 for ; Fri, 17 Apr 2015 07:00:43 -0700 (PDT) Received: by widdi4 with SMTP id di4so21539868wid.0 for ; Fri, 17 Apr 2015 07:00:42 -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=fkUhf4f2clFZUTIMcb0WH+lOk1/AOf+RD4p/o4b6i/Y=; b=I3H80sWRgjkCb3FaDW8xYWEhqZd34CyWANbX8Z2aUtSnSKMRgB72YaEU0Rds56bTZv bmlK9XEaqOeBOiV7gLwszs/1iA5i/5+u4lfGlUNkY11xGRxM738067YaZHJNvbYWlfOT TJMGrdNs405A9jcW+UQSKxIRS9M0YQZXYhJQo= 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=fkUhf4f2clFZUTIMcb0WH+lOk1/AOf+RD4p/o4b6i/Y=; b=H9iTQPkGA/n7rozlEnrL//Dp3kihMzlACLV9Dwj13T/nOlyzryglPAd+YEWLzT/5Hu 284nlKuhdyZsLCA06pl6x9LFPAl5f2ZhF70FfTRiWDerOhAwCbtZ16klaHQg8RqmV0rq mcSGDg+G6/uFtvGssxlD+bVjApGOvMra82rC4iidEmaGXwA8mp0vN4fWWedC+xCZ51Mk FEDCI5+ThtEv1+81qxSKKeZamdqOeeTKEgC/ZsYzRvk7crEWHhp+Tg0NQTDJYMBJK8aX IElijMIBP5Iy0OYRUNBERSyz6gYNDYaFuuD/AWvQ9+iMDKeFVNKhNVpRjRiBdIvEAE5W LVlA== X-Gm-Message-State: ALoCoQmCRSYE9tFj19lHZ3B+O4/3yohwHlJhBlPsByFvWdFIH9fShHl6YGcB4AIvrU86OPxcHl22 MIME-Version: 1.0 X-Received: by 10.194.192.167 with SMTP id hh7mr6305665wjc.151.1429279242084; Fri, 17 Apr 2015 07:00:42 -0700 (PDT) Received: by 10.28.104.138 with HTTP; Fri, 17 Apr 2015 07:00:42 -0700 (PDT) In-Reply-To: <57175023.AVSjdYu02a@pintsize.usersys.redhat.com> References: <57175023.AVSjdYu02a@pintsize.usersys.redhat.com> Date: Fri, 17 Apr 2015 16:00:42 +0200 Message-ID: From: Thijs van Dijk To: tls@ietf.org Content-Type: multipart/alternative; boundary=047d7b8743f8827bf30513ec0185 Archived-At: Subject: Re: [TLS] Request for clarification: "in the same flight" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 14:00:45 -0000 --047d7b8743f8827bf30513ec0185 Content-Type: text/plain; charset=UTF-8 On 17 April 2015 at 14:34, Hubert Kario wrote: > On Thursday 16 April 2015 18:07:27 Thijs van Dijk wrote: > > If I were to venture a guess, I'd say the two are equivalent, but it's > also > > conceivable that some implementations require any TLSPlaintext to contain > > exactly one child struct. (Source: mine does; I'm trying to figure out if > > that's a bug or not.) > > It is a bug, see RFC 5246, section 6.2.1 > Ah, yes. Thanks for pointing that out! -Thijs --047d7b8743f8827bf30513ec0185 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 7 April 2015 at 14:34, Hubert Kario <hkario@redhat.com> wrot= e:
On Thursday 16 April 2015 18:07:= 27 Thijs van Dijk wrote:
> If I were to venture a guess, I'd say the two are equivalent, but = it's also
> conceivable that some implementations require any TLSPlaintext to cont= ain
> exactly one child struct. (Source: mine does; I'm trying to figure= out if
> that's a bug or not.)

It is a bug, see RFC 5246, section 6.2.1

Ah, yes.=C2=A0 Thanks for pointing that out!

<= div>-Thijs

--047d7b8743f8827bf30513ec0185-- From nobody Fri Apr 17 11:00: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 A5A741B34EA; Thu, 16 Apr 2015 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCRYTbsr8u9y; Thu, 16 Apr 2015 12:05:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 876A61B34CC; Thu, 16 Apr 2015 12:05:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416190524.20524.91692.idtracker@ietfa.amsl.com> Date: Thu, 16 Apr 2015 12:05:24 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 17 Apr 2015 11:00:56 -0700 Subject: [TLS] ID Tracker State Update Notice: 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, 16 Apr 2015 19:05:27 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ From nobody Fri Apr 17 12:00: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 3F3F01B2FCE for ; Fri, 17 Apr 2015 12:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA3YJAA530ZP for ; Fri, 17 Apr 2015 12:00:17 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 457391B2F84 for ; Fri, 17 Apr 2015 12:00:13 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id F2F44F240E9 for ; Fri, 17 Apr 2015 15:00:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id ko0wavxbu9Ta for ; Fri, 17 Apr 2015 14:59:41 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 226B7F240E6 for ; Fri, 17 Apr 2015 14:59:42 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2015 14:59:30 -0400 Message-Id: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> To: IETF TLS Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 19:00:18 -0000 Section 6.3 of draft-ietf-tls-tls13-05 describes the key calculation = from the current master secret (MS). First a key block is computed: key_block =3D PRF(MS, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); Then, the key block is divided into keys and IVs: client_write_key[SecurityParameters.enc_key_length] server_write_key[SecurityParameters.enc_key_length] client_write_IV[SecurityParameters.fixed_iv_length] server_write_IV[SecurityParameters.fixed_iv_length] If one wants to implement the cryptographic functions in a Hardware = Security Module (HSM), this structure is far from ideal. In general I = would expect the client_write_key and server_write_key to stay inside = the protected boundary of the HSM, but the client_write_IV and = server_write_IV do not need this protection. Both of these coming from = the same key_block makes this separation very difficult to implement. Can we get these values from different invocations of the PRF? I'd like = to see one invocation for values that are expected to remain secret and = a separate invocation for values that do not need to remain secret. Russ From nobody Fri Apr 17 12:41: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 76F151A01D6 for ; Fri, 17 Apr 2015 12:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bhz6Ts-PUWFF for ; Fri, 17 Apr 2015 12:41:10 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (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 8364A1B2FE1 for ; Fri, 17 Apr 2015 12:41:07 -0700 (PDT) Received: by wgyo15 with SMTP id o15so123614099wgy.2 for ; Fri, 17 Apr 2015 12:41:06 -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=ceD90QhSwg3Fd91L5BMIRVYyQcMWKd+R64fbnNyTd9c=; b=Zpxt1DD/A0r7KVby41Q2JFM1wrE5Z+z5nIZ3kXdX4UTZZgDPsoDNwdiaZ8ypFdtfRC OZlJA+t+A2e1UEnizAyJg5gh9U+cGfSblvng2pIPPHcnIt3uTq1OeYCTfTJ7N8azoIuO uQTPdScYKHc4YL1I/s71f86SRudSuL2h5En5BZN6XlHHBA2SG0MHQ9rAZV3jktGW/Don rWoWB1oM/gRWbMVDH8d4Yr0fPJAKZU7bo4tQYAfAiq11qthvk/JaPxYG5nmbrTLBYmT8 Qkt5ZFkGdzSjj4m0Via+O3QPsyaFPT5MqMoCXyPWgfHhYrJxj5Y6j1vNiENmdqbcDLlp f/MA== X-Gm-Message-State: ALoCoQlbNmhz5S1LEcKi19p0svhu2ygnEAk0XrAzR7l0hWHUUlpvsrwWsalSBcKsyFrj64/iUtIS X-Received: by 10.180.84.67 with SMTP id w3mr4273960wiy.68.1429299666294; Fri, 17 Apr 2015 12:41:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Fri, 17 Apr 2015 12:40:25 -0700 (PDT) In-Reply-To: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> From: Eric Rescorla Date: Fri, 17 Apr 2015 12:40:25 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=f46d04440276e329e80513f0c251 Archived-At: Cc: IETF TLS Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 19:41:11 -0000 --f46d04440276e329e80513f0c251 Content-Type: text/plain; charset=UTF-8 We should defer this issue until we know whether we are generating an IV at all. -Ekr On Fri, Apr 17, 2015 at 11:59 AM, Russ Housley wrote: > Section 6.3 of draft-ietf-tls-tls13-05 describes the key calculation from > the current master secret (MS). First a key block is computed: > > key_block = PRF(MS, > "key expansion", > SecurityParameters.server_random + > SecurityParameters.client_random); > > Then, the key block is divided into keys and IVs: > > client_write_key[SecurityParameters.enc_key_length] > server_write_key[SecurityParameters.enc_key_length] > client_write_IV[SecurityParameters.fixed_iv_length] > server_write_IV[SecurityParameters.fixed_iv_length] > > If one wants to implement the cryptographic functions in a Hardware > Security Module (HSM), this structure is far from ideal. In general I > would expect the client_write_key and server_write_key to stay inside the > protected boundary of the HSM, but the client_write_IV and server_write_IV > do not need this protection. Both of these coming from the same key_block > makes this separation very difficult to implement. > > Can we get these values from different invocations of the PRF? I'd like > to see one invocation for values that are expected to remain secret and a > separate invocation for values that do not need to remain secret. > > Russ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d04440276e329e80513f0c251 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We should defer this issue until we know whether we a= re generating an IV
at all.

-Ekr


On Fri, Apr 17, 2015 at 11:59 AM, Russ Housley <housley@vigilsec.com<= /a>> wrote:
Section 6.3 of draf= t-ietf-tls-tls13-05 describes the key calculation from the current master s= ecret (MS).=C2=A0 First a key block is computed:

=C2=A0 =C2=A0 =C2=A0 key_block =3D PRF(MS,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "key expansion",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 SecurityParameters.server_random +
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 SecurityParameters.client_random);

Then, the key block is divided into keys and IVs:

=C2=A0 =C2=A0 =C2=A0 client_write_key[SecurityParameters.enc_key_length] =C2=A0 =C2=A0 =C2=A0 server_write_key[SecurityParameters.enc_key_length] =C2=A0 =C2=A0 =C2=A0 client_write_IV[SecurityParameters.fixed_iv_length] =C2=A0 =C2=A0 =C2=A0 server_write_IV[SecurityParameters.fixed_iv_length]
If one wants to implement the cryptographic functions in a Hardware Securit= y Module (HSM), this structure is far from ideal.=C2=A0 In general I would = expect the client_write_key and server_write_key to stay inside the protect= ed boundary of the HSM, but the client_write_IV and server_write_IV do not = need this protection.=C2=A0 Both of these coming from the same key_block ma= kes this separation very difficult to implement.

Can we get these values from different invocations of the PRF?=C2=A0 I'= d like to see one invocation for values that are expected to remain secret = and a separate invocation for values that do not need to remain secret.

Russ

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

--f46d04440276e329e80513f0c251-- From nobody Fri Apr 17 12:45: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 B872D1B2FE0 for ; Fri, 17 Apr 2015 12:45: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_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 8Rz18QArKQrz for ; Fri, 17 Apr 2015 12:44:59 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003: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 823811A0235 for ; Fri, 17 Apr 2015 12:44:59 -0700 (PDT) Received: by oblw8 with SMTP id w8so79467347obl.0 for ; Fri, 17 Apr 2015 12:44: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=0iFmP9qnXggInT268MRm+fG2iD2rEn8OQBntSjLV+XM=; b=xQ+MuzxYN96RpBlBbJv1xV4Zr5V6LOJjoVZWa563muoGbxemS7rPn/9BQCZspQhhAf mTQrMvd/OiOVO+EQLkldbotupgD94DZ6tk/BrBBhlVZv7AX4zkW/Y+6CrRKIhE6s985o 7Wydxtvq46n/nW5UI1QQ1nO6IKKvFTyDCdgUvFwOlhFROjaWlG5A/HOsmV4OSPoeD2ou vdVwVXuNTaReGzVLLdodjSOg5YAnDyMxhU4NoKnFTmLSPVPSvsJEaViDf0RGjcDKxMPs TBkzfw9BiftJEzN0nfBeNAISdJHFkUHWASHddB4JnGCXSVrNUczz3PzG5jLbfEC2USFA +YLQ== MIME-Version: 1.0 X-Received: by 10.60.15.133 with SMTP id x5mr4429844oec.80.1429299899101; Fri, 17 Apr 2015 12:44:59 -0700 (PDT) Received: by 10.202.212.212 with HTTP; Fri, 17 Apr 2015 12:44:59 -0700 (PDT) In-Reply-To: References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> Date: Fri, 17 Apr 2015 12:44:59 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF TLS Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 19:45:00 -0000 Note also that this is a known issue. Mike StJohns raised it previously. https://github.com/tlswg/tls13-spec/issues/5 On 17 April 2015 at 12:40, Eric Rescorla wrote: > We should defer this issue until we know whether we are generating an IV > at all. > > -Ekr > > > On Fri, Apr 17, 2015 at 11:59 AM, Russ Housley wrote: >> >> Section 6.3 of draft-ietf-tls-tls13-05 describes the key calculation from >> the current master secret (MS). First a key block is computed: >> >> key_block = PRF(MS, >> "key expansion", >> SecurityParameters.server_random + >> SecurityParameters.client_random); >> >> Then, the key block is divided into keys and IVs: >> >> client_write_key[SecurityParameters.enc_key_length] >> server_write_key[SecurityParameters.enc_key_length] >> client_write_IV[SecurityParameters.fixed_iv_length] >> server_write_IV[SecurityParameters.fixed_iv_length] >> >> If one wants to implement the cryptographic functions in a Hardware >> Security Module (HSM), this structure is far from ideal. In general I would >> expect the client_write_key and server_write_key to stay inside the >> protected boundary of the HSM, but the client_write_IV and server_write_IV >> do not need this protection. Both of these coming from the same key_block >> makes this separation very difficult to implement. >> >> Can we get these values from different invocations of the PRF? I'd like >> to see one invocation for values that are expected to remain secret and a >> separate invocation for values that do not need to remain secret. >> >> Russ >> >> _______________________________________________ >> 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 Apr 17 13:00: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 C9EEE1B3021 for ; Fri, 17 Apr 2015 13:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=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 1L32pGrG05qX for ; Fri, 17 Apr 2015 13:00:04 -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 C02EA1B3019 for ; Fri, 17 Apr 2015 13:00:03 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 116D19008F; Fri, 17 Apr 2015 23:00:00 +0300 (EEST) Date: Fri, 17 Apr 2015 23:00:00 +0300 From: Ilari Liusvaara To: Russ Housley Message-ID: <20150417200000.GA6274@LK-Perkele-VII> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: IETF TLS Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 20:00:06 -0000 On Fri, Apr 17, 2015 at 02:59:30PM -0400, Russ Housley wrote: > Section 6.3 of draft-ietf-tls-tls13-05 describes the key calculation from the current master secret (MS). First a key block is computed: > > key_block = PRF(MS, > "key expansion", > SecurityParameters.server_random + > SecurityParameters.client_random); > > Then, the key block is divided into keys and IVs: > > client_write_key[SecurityParameters.enc_key_length] > server_write_key[SecurityParameters.enc_key_length] > client_write_IV[SecurityParameters.fixed_iv_length] > server_write_IV[SecurityParameters.fixed_iv_length] > > If one wants to implement the cryptographic functions in a Hardware > Security Module (HSM), this structure is far from ideal. In general > I would expect the client_write_key and server_write_key to stay > inside the protected boundary of the HSM, but the client_write_IV > and server_write_IV do not need this protection. Both of these > coming from the same key_block makes this separation very difficult > to implement. While if the encryption algorithm is strong, there is no real difference between public and private nonces (if algorithm is not strong, then all bets are off), having untrusted parts pick nonces with non-MR AE (especially something so hair trigger as AES-GCM) seems like asking for trouble. > Can we get these values from different invocations of the PRF? > I'd like to see one invocation for values that are expected to > remain secret and a separate invocation for values that do not > need to remain secret. That would certainly work. Note that to implement full TLS, one already needs to derive "public" values out of "private" ones. On another thought, TLS library authors might not appreciate key expansion being changed (nor KDF changes)... -Ilari From nobody Fri Apr 17 13:32: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 BD47C1A017D for ; Fri, 17 Apr 2015 13:32: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 YTI0y_1Kqss8 for ; Fri, 17 Apr 2015 13:32:26 -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 6090A1A0104 for ; Fri, 17 Apr 2015 13:32:26 -0700 (PDT) Received: by widdi4 with SMTP id di4so32948075wid.0 for ; Fri, 17 Apr 2015 13:32: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=3HKJzQIituOu3nQs3BgPaD+iD+w2RFVWYhQl6u+cA5k=; b=MHzlbUJdNX6G6Jx73RfSNEgGxccZbbdi87uGq/BUfCU8K1pbq8PBD4QWqDxNf/qapk Ua5Qz11laK4MgPjRd67KL++e5YhmFpen4OSNE26Uttd4dWigJofn4VJW4KVjaylrN5yP zhPBSCXF5e0lwdY/C7569NQVYU6+WbdW6H1uIuFLbIH1rFmOge1AqT2f0k93f7W+JvdQ I8H5wXY8a0IR0NMaymFu3XCA4Y8sUhGTTc5ynzFBIaAl49fPah8040nqZ7ZD8i2EpvvW c5r6eOpf8njOWykKQuJp05aA/9HiM8fcMdxM7kG4U2UX+FoWOKr8YXpkQsJ6nbGkgSV+ P/cw== X-Received: by 10.180.73.180 with SMTP id m20mr4472958wiv.2.1429302745164; Fri, 17 Apr 2015 13:32:25 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id dz4sm4068086wib.17.2015.04.17.13.32.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Apr 2015 13:32: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: Fri, 17 Apr 2015 23:32:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> To: Eric Rescorla X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IETF TLS Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 20:32:27 -0000 > On Apr 17, 2015, at 10:40 PM, Eric Rescorla wrote: >=20 > We should defer this issue until we know whether we are generating an = IV > at all. >=20 The client_write_iv and server_write_iv are needed, and I=E2=80=99m not = aware of any contention about them. In AES-GCM they are used for the = =E2=80=9Csalt=E2=80=9D value, and the chacha20-poly1305 draft uses the = same terminology for a 32-bit fixed part of the nonce that is derived = from the key buffer. This is not the same as the per-record IV that we *are* considering = dropping. Yoav From nobody Fri Apr 17 14:04: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 0003A1B2CF7 for ; Fri, 17 Apr 2015 14:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, 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 tPA6ArHXb3fA for ; Fri, 17 Apr 2015 14:04:14 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F051B2CDA for ; Fri, 17 Apr 2015 14:04:14 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 2CC793AA3D; Fri, 17 Apr 2015 14:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1429304636; bh=GEJ3H9a44fW/6cCDpdzRNhRGPzrpBqMfsO3qWxKwd4o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MLqlny6cGRSygkB2dXKyPDprOJ8lFTWrEho8byRF/jR3W9MJMt4htmgo/JapcCPv0 uF71LIz3+UuJue1TLRVbe3TRHcAuXgM9znmaU2oDnye95n/no92dr2ot6+DemfpF4g rMH5mb7M/wPeuqWPitQJHHfkWWHb9yXZv3zH/MBw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Hamburg In-Reply-To: <20150417124739.GA30086@LK-Perkele-VII> Date: Fri, 17 Apr 2015 14:04:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150417124739.GA30086@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 21:04:17 -0000 > On Apr 17, 2015, at 5:47 AM, Ilari Liusvaara = wrote: >=20 > On Fri, Apr 03, 2015 at 01:34:15PM -0700, Joseph Salowey wrote: >> In the interim meeting we had consensus to use an implicit IV for = AEAD. >> The proposal was to use the record sequence number and pad with zeros = as >> described in pull request 155 ( >> https://github.com/tlswg/tls13-spec/pull/155/files). This was also >> discussed in the IETF-92 meeting in Dallas along with options to = change the >> offset. The consensus was to stay with the original proposal. We = are >> posting to the mailing list to confirm this consensus. >=20 > I really do not like padding with zeroes, since it would weaken > encryption relative to TLS v1.2. And this is not just if the > symmetric encryption is already broken, but applies to all[1]. >=20 > This is especially prominent with AES-128[2]. And "Just use AES-256" > does not solve the issue, since it will probably not be available > in important environments[3]. >=20 > None of TLS v1.2, IPSec nor SSH use AES-GCM this way, all have > secret[4] fixed nonce-parts (SSH does use Chacha20 without per- > connection nonce[5]). >=20 >=20 > OTOH, the explicit per-record nonce field for AES-GCM seems really > unnecressary. Everybody uses it sequentially anyway, so it just > wastes 8 bytes per record. >=20 >=20 >=20 > [1] If the algorithm is broken, if the zeroes or even just known > nonce further help breaking depends on type of attack (but of > course, one rather not use such broken algorithms).[6] >=20 > [2] Substantial weakening happens far before collisions become > likely. So much less than AGL's "2^60" mentioned in the meeting. Really? Can you provide a citation? Because if I=E2=80=99m reading it = correctly, this is a claim that AES-128 is not a secure PRP, with = significantly less than 2^60 known/chosen plaintexts, keys and compute = time. > [3] And I suppose nobody really likes AES-192 (despite the fact > that seemingly just about every CPU with "AES acceleration" is able > to accelerate that too). :-> =E2=80=A6 and this is a claim that AES-192 and AES-256 are somehow = substantially more secure than AES-128 as PRPs. > [4] Secret meaning those are derived from the main key block. =E2=80=A6 and this is a claim that adding an extra key, which is in the = nonce instead of an actual key to the cipher, makes it more secure. All this said, I agree that it=E2=80=99s wise to reduce the amount of = cribtext you give an attacker, so long as it doesn=E2=80=99t cost too = much complexity. If we are really providing a fatal amount of cribtext, = then we need to fix that, but then again, we should probably toss the = cipher out at that point. Cheers, =E2=80=94 Mike >=20 > [5] The encrypted stream looks like random noise, which makes it > harder to tell where packet boundaries are (and Chacha20 is > 256-bit keys anyway). >=20 > [6] SSLv3 had known nonces for EXPORT ciphers, but secret ones > for strong ones. Hmm... >=20 >=20 >=20 > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Apr 17 14:18: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 1CFE91B2EB1 for ; Fri, 17 Apr 2015 14:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 VY4LMN2N3duo for ; Fri, 17 Apr 2015 14:18:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.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 5A2911ACEA7 for ; Fri, 17 Apr 2015 14:18:13 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so80330010obb.3 for ; Fri, 17 Apr 2015 14:18: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 :content-transfer-encoding; bh=wzCrRIMJXWfpysNPSSXRvKNnwSGhob687Aq3b8O4xoI=; b=CazYTZig9t37sbInFB7bZL60zAhfxGvWjZSR4JIxuWsq9n9zO7Ht12vE4hR4V2ZGpI LSknmXMq7+Vs6J8w+zDLJ5WvkYM1KEwyj2dMUmDIb8zqu4BLK79D8H42If7888Y0zQJ8 D014imTLHNDae+bFjEUX4Vh22SJsciRcQfzXxvLZSnaa17/OzCQsTlnr/pdT/LMKPOJC L0jb3bssbSynD1WnEjxyHwDk5CeiFhYGXhkXmsx5fomaw4D3trw0yA6X6X+W0VuGucgK r6ookVzsAsG3EBoIxnbViIaZaz2HGqTU8jf1TMOr8fIow5Y0+SRC+6F/9IMecz/UMo4s Lq3w== X-Gm-Message-State: ALoCoQkMZ7VQNJuFiQrBSoYxxf2mcPEz764xa567I1TwEK+a3vhqobzGY3JJeDum7u43E45L5UEj MIME-Version: 1.0 X-Received: by 10.202.210.194 with SMTP id j185mr4492585oig.68.1429305492674; Fri, 17 Apr 2015 14:18:12 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Fri, 17 Apr 2015 14:18:12 -0700 (PDT) In-Reply-To: References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> Date: Fri, 17 Apr 2015 11:18:12 -1000 Message-ID: From: Brian Smith To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF TLS Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 21:18:15 -0000 Yoav Nir wrote: >> On Apr 17, 2015, at 10:40 PM, Eric Rescorla wrote: >> We should defer this issue until we know whether we are generating an IV >> at all. >> > The client_write_iv and server_write_iv are needed, and I=E2=80=99m not a= ware of any contention about them. In AES-GCM they are used for the =E2=80= =9Csalt=E2=80=9D value, and the chacha20-poly1305 draft uses the same termi= nology for a 32-bit fixed part of the nonce that is derived from the key bu= ffer. > > This is not the same as the per-record IV that we *are* considering dropp= ing. I think you're misunderstanding what is being discussed. As far as I know, nobody objects to using the record sequence number in a way that turns the nonce into a counter. The only thing being debated is whether client_write_iv and server_write_iv are used. See the actual pull request [1]. The proposal put forth in that pull request is that the nonce will consist *only* of the per-record sequence number, padded with zeros, and without the part that was comprised of client_write_iv and server_write_iv. Cheers, Brian [1] https://github.com/ekr/tls13-spec/commit/0c610a9453ca10bd12d3b979d2faa0= 14a0b12251 From nobody Fri Apr 17 14:30: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 D1AF91B2CE0 for ; Fri, 17 Apr 2015 14:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 JNfG2m3vqRb5 for ; Fri, 17 Apr 2015 14:30:32 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.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 DDE751B304C for ; Fri, 17 Apr 2015 14:30:31 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so78920257obb.2 for ; Fri, 17 Apr 2015 14:30: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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NP66597PJv3Qcj8F6oZPfKFY4o7ftg1fz4MHqif4nms=; b=Lr9IhOE/0HcC55slwGUZ2tpTticm/HewGXxS6tnk3o9xIK9A7ut2/LONf6TyqWYj1i bJFjX3TP6xJjeu9bTNuXeQYGkvSFp4LL1Nkew5XkApz78fNZfiY50lQHpalQH/gwAnco psW9DbS858yrBnpHjt7eDNTe0BOT5BVgjF4DWDgACqcCczcME6xuuwYsX5AGLFIR9HaX lz1sxz6VsdbleH7R+6+/32/62uqrupcgDaL88s1/nYNkhECUXtNdtIPhdDKSVHl+f11O LvgvuHfI/hYQwW8UsPy4Pl9oY84BSbfOqrEnLpFdOaZvV9KuvCAsq2vyhjRWS/iLEHxH JBEw== X-Gm-Message-State: ALoCoQnaosDQsmJTWjkyEMqGH3vZUtRXyESfyxY9EMZhgu7vkDFYOnZUzqIckbiIstseuj38Rxi9 MIME-Version: 1.0 X-Received: by 10.60.139.1 with SMTP id qu1mr4771180oeb.83.1429306231367; Fri, 17 Apr 2015 14:30:31 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Fri, 17 Apr 2015 14:30:31 -0700 (PDT) In-Reply-To: References: <20150417124739.GA30086@LK-Perkele-VII> Date: Fri, 17 Apr 2015 11:30:31 -1000 Message-ID: From: Brian Smith To: Michael Hamburg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 21:30:34 -0000 Michael Hamburg wrote: >> Ilari Liusvaara wrote: >> [2] Substantial weakening happens far before collisions become >> likely. So much less than AGL's "2^60" mentioned in the meeting. > > Really? Can you provide a citation? Because if I=E2=80=99m reading it c= orrectly, this is a claim that AES-128 is not a secure PRP, with significan= tly less than 2^60 known/chosen plaintexts, keys and compute time. It is a claim that AES-128-*GCM* *may* (emphasis on *GCM* and *may*) not be a perfectly secure PRP, and/or that the key agreement scheme to be used in TLS 1.3 *may* not not be perfect. I think those are reasonable things to doubt, absent a proof to the contrary. >> [4] Secret meaning those are derived from the main key block. > > =E2=80=A6 and this is a claim that adding an extra key, which is in the n= once instead of an actual key to the cipher, makes it more secure. > > All this said, I agree that it=E2=80=99s wise to reduce the amount of cri= btext you give an attacker, so long as it doesn=E2=80=99t cost too much com= plexity. If we are really providing a fatal amount of cribtext, then we ne= ed to fix that, but then again, we should probably toss the cipher out at t= hat point. The argument I was making is that (a) it seems unreasonable to assume AES-128-GCM is perfect and that they key agreement scheme is perfect, and (b) the cost of randomizing the starting point of the nonce counter is so low that it is worthwhile to do it just in case. I recently read the FIPS 140-2 implementer's guidance at [1]. I think it is worthwhile for people discussing this to read what it has to say about AES-GCM nonce handling, which starts on page 138. It recommends an even more stringent handling of nonces for AES-GCM, summarizing the approach proposed for TLS 1.3 as follows: It may be tempting to avoid meeting the IV generation requirements stated in this IG if it could be guaranteed that any key was used only once thus avoiding the (key, IV) collisions regardless of the method used to generate the IVs. The problem with this approach is that within the scope of the CMVP validation neither the module itself nor its Security Policy can enforce the single-use-key condition. The risk of introducing the identical (key, IV) pairs outweighs the possible benefits of relaxing the IV generation rules." Where the "IV generation rules" are paraphrasing, "do it the way TLS 1.2 does, or else ensure every peer uses a unique identifier as a prefix on nonces it uses for encryption." No matter what we do, we should address this concern in the security considerations of the TLS 1.3 spec by stating the assumptions we are making and guarantees we are providing regarding (key, IV) uniqueness. Cheers, Brian [1] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf From nobody Fri Apr 17 15:15: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 9A6DC1B309C for ; Fri, 17 Apr 2015 15:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpQXS7lOtr4J for ; Fri, 17 Apr 2015 15:15:09 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C038F1B309A for ; Fri, 17 Apr 2015 15:15:08 -0700 (PDT) Received: by wgsk9 with SMTP id k9so126335557wgs.3 for ; Fri, 17 Apr 2015 15:15: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=VEPJwmm4mkirffepMArWVJBJFGWW9uM8JTRp4kuzbro=; b=fOHAXU9CvTHwJ3N1fqWf8+qSLSyLmF7A95VbhczD+gASiqoMoHxCrZDOtTz1JEHw2H yW7uZei+S96z37YRtZ7CxLSGkSW07JQa1696rXC95R5qnjlqqWKPMeN+X5DjvBOZTT/y o7lg/VRWBsTyGi1Wd/37xJvAymjVCCYrv2+VCeBN4clQT4ra7wBfmhaltnsFTJjF6bfA 1yeyo71d3VprkLIdeggSa+0yOC3vjieaeL6vPtVhed+Blih2gVFZmDrFUwX1dmT1xKhs e9wF4HPb0QNAKn156pTYToF/TZNbtLoMUkpWws02VYTdH8Xiq8EoQz+H1VW0VSQA3o1E mwaQ== X-Gm-Message-State: ALoCoQkWhDncif3NKyErGzRqL2UsUWwQAeyMHy4dw4hRKUqhr+AN4N6W3CfSm4u8CLVPjMrgoVaG X-Received: by 10.180.82.135 with SMTP id i7mr5106337wiy.68.1429308907506; Fri, 17 Apr 2015 15:15:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Fri, 17 Apr 2015 15:14:27 -0700 (PDT) In-Reply-To: References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> From: Eric Rescorla Date: Fri, 17 Apr 2015 15:14:27 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=f46d04428da2b4e07a0513f2e90a Archived-At: Cc: IETF TLS Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2015 22:15:10 -0000 --f46d04428da2b4e07a0513f2e90a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's correct. Yoav, if you're sad about that, then now is the time to say that :) -Ekr On Fri, Apr 17, 2015 at 2:18 PM, Brian Smith wrote: > Yoav Nir wrote: > >> On Apr 17, 2015, at 10:40 PM, Eric Rescorla wrote: > >> We should defer this issue until we know whether we are generating an = IV > >> at all. > >> > > The client_write_iv and server_write_iv are needed, and I=E2=80=99m not= aware of > any contention about them. In AES-GCM they are used for the =E2=80=9Csalt= =E2=80=9D value, > and the chacha20-poly1305 draft uses the same terminology for a 32-bit > fixed part of the nonce that is derived from the key buffer. > > > > This is not the same as the per-record IV that we *are* considering > dropping. > > I think you're misunderstanding what is being discussed. As far as I > know, nobody objects to using the record sequence number in a way that > turns the nonce into a counter. The only thing being debated is > whether client_write_iv and server_write_iv are used. See the actual > pull request [1]. The proposal put forth in that pull request is that > the nonce will consist *only* of the per-record sequence number, > padded with zeros, and without the part that was comprised of > client_write_iv and server_write_iv. > > Cheers, > Brian > > > [1] > https://github.com/ekr/tls13-spec/commit/0c610a9453ca10bd12d3b979d2faa014= a0b12251 > --f46d04428da2b4e07a0513f2e90a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's correct. Yoav, if you're sad about that, th= en now is the time to say that :)

-Ekr


On Fri, Apr 17, 2015 at 2:18 PM, Brian Smith <brian@brian= smith.org> wrote:
Yoav Nir <ynir.ietf@gmail.com> wrote:
>> On Apr 17, 2015, at 10:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> We should defer this issue until we know whether we are generating= an IV
>> at all.
>>
> The client_write_iv and server_write_iv are needed, and I=E2=80=99m no= t aware of any contention about them. In AES-GCM they are used for the =E2= =80=9Csalt=E2=80=9D value, and the chacha20-poly1305 draft uses the same te= rminology for a 32-bit fixed part of the nonce that is derived from the key= buffer.
>
> This is not the same as the per-record IV that we *are* considering dr= opping.

I think you're misunderstanding what is being discussed. As= far as I
know, nobody objects to using the record sequence number in a way that
turns the nonce into a counter. The only thing being debated is
whether client_write_iv and server_write_iv are used. See the actual
pull request [1]. The proposal put forth in that pull request is that
the nonce will consist *only* of the per-record sequence number,
padded with zeros, and without the part that was comprised of
client_write_iv and server_write_iv.

Cheers,
Brian


[1] https://github.com/ekr/tls13-spec/= commit/0c610a9453ca10bd12d3b979d2faa014a0b12251

--f46d04428da2b4e07a0513f2e90a-- From nobody Fri Apr 17 20:10: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 C69CD1A88DA for ; Fri, 17 Apr 2015 20:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 JaOjN5BHizxi for ; Fri, 17 Apr 2015 20:10:54 -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 C17F81A8883 for ; Fri, 17 Apr 2015 20:10:54 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 53A8144865; Sat, 18 Apr 2015 05:10:52 +0200 (CEST) X-purgate-ID: 152705::1429326652-0000765A-A95EA3BC/0/0 X-purgate-size: 1080 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 309DD460A9; Sat, 18 Apr 2015 05:10:52 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 221221B2A1; Sat, 18 Apr 2015 05:10:52 +0200 (CEST) In-Reply-To: <87fv80nnev.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor Date: Sat, 18 Apr 2015 05:10: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: <20150418031052.221221B2A1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] FFDHE and SHOULDs on usage 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, 18 Apr 2015 03:10:56 -0000 Daniel Kahn Gillmor wrote: >> >> Groups are ordered based on client preference, noting the additional >> ordering considerations in Section 6.1. > > Also, this rewrite says "ordered based on client preferences" but > doesn't indicate which order based on client preferences: most preferred > to least preferred or the other way around. It may be pedantic, but > this is exactly the sort of pedantry that RFCs should include. Could we just scrap the "based on xxx preference" nonsense entirely? The sender of the list sends whatever it sees fit, and the receiver of the list has the privilege to pick what ever the receiver believes is most appropriate from the receivers point of view. I never understood why (a) such a silly suggestion was made for the ordering of cipher suites in ClientHello and (b) why any TLS server implementaion would care for the client's ordering rather than enforcing the server preference. If the client does not want something, it must not offer it. If the server does not want something, it must not pick it. -Martin From nobody Fri Apr 17 21:10: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 7297C1A89C4 for ; Fri, 17 Apr 2015 21:10:42 -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 ajzGpHXOmu-K for ; Fri, 17 Apr 2015 21:10:40 -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 3BBE11A8982 for ; Fri, 17 Apr 2015 21:10:40 -0700 (PDT) Received: by wiax7 with SMTP id x7so45983425wia.0 for ; Fri, 17 Apr 2015 21: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 :message-id:references:to; bh=UEJI45spYriZqrFlZJFbteH7xdlc1mLTi1UaJOwqC/w=; b=KUjdL0zK15YCKJEKjDuiXigHQYED+YXVT2IUpHlslb5QkrjxYWt8Q8VVdjW/sH8CaC WD6jk7/4msa08LQaL65o3XjWgnQW3Lq6Zohll9gGjCx1IBNd8hU/Ej/7KiCHwyHh2vnJ p8TDGJMBie7GNTdZEFlgmRhyCnF6/s6BFEQyeHv37D3iRidq5d6/kLElPrcOJEHci7WG rttodWIiBkrv57tgfdThHFiDHvsypO1BynA9AYYyUgajErFoXfVvQDdpeZPOLf98cjbu EoqPRDtjrGtKn8EHS58XLb61DP2r3Y4dxRsXJF4HRhT8ENinjz04AC61YxW7v5rQL38i +uEQ== X-Received: by 10.194.86.135 with SMTP id p7mr11507847wjz.89.1429330238967; Fri, 17 Apr 2015 21:10:38 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id fa8sm5245394wib.14.2015.04.17.21.10.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Apr 2015 21:10:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FF5AB20A-DEAE-4041-99B5-09F91BBD0EA0" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Sat, 18 Apr 2015 07:10:36 +0300 Message-Id: <29B76887-46EE-4AA1-9BD9-FB322D63C92D@gmail.com> References: To: Joseph Salowey X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call on Implicit IV for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2015 04:10:42 -0000 --Apple-Mail=_FF5AB20A-DEAE-4041-99B5-09F91BBD0EA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Making AEAD implicit on the record works for me. As far as using all = zeros for the salt, it doesn=E2=80=99t make a lot of difference for = ChaCha20-Poly1305, but it might make some for AES-GCM. Here=E2=80=99s a = link to a post on the ipsec list that explains it better than I can: http://www.ietf.org/mail-archive/web/ipsec/current/msg09751.html = Yoav > On Apr 3, 2015, at 11:34 PM, Joseph Salowey wrote: >=20 > In the interim meeting we had consensus to use an implicit IV for = AEAD. The proposal was to use the record sequence number and pad with = zeros as described in pull request 155 = (https://github.com/tlswg/tls13-spec/pull/155/files = ). This was also = discussed in the IETF-92 meeting in Dallas along with options to change = the offset. The consensus was to stay with the original proposal. We = are posting to the mailing list to confirm this consensus. If you have = comments, please reply by April 17, 2015. =20 >=20 > Thanks, >=20 > S&J > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_FF5AB20A-DEAE-4041-99B5-09F91BBD0EA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

Making = AEAD implicit on the record works for me. As far as using all zeros for = the salt, it doesn=E2=80=99t make a lot of difference for = ChaCha20-Poly1305, but it might make some for AES-GCM. Here=E2=80=99s a = link to a post on the ipsec list that explains it better than I = can:

http://www.ietf.org/mail-archive/web/ipsec/current/msg09751.htm= l

Yoav

On Apr 3, 2015, at 11:34 PM, = Joseph Salowey <joe@salowey.net> wrote:

In the interim meeting we had consensus to use an implicit IV = for AEAD.  The proposal was to use the record sequence number and = pad with zeros as described in pull request 155 (https://github.com/tlswg/tls13-spec/pull/155/files).  = This was also discussed in the IETF-92 meeting in Dallas along with = options to change the offset.  The consensus was to stay with the = original proposal.  We are posting to the mailing list to confirm = this consensus. If you have comments,  please reply by April 17, = 2015.  

Thanks,

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

= --Apple-Mail=_FF5AB20A-DEAE-4041-99B5-09F91BBD0EA0-- From nobody Fri Apr 17 22:21: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 DA3A01AC39D for ; Fri, 17 Apr 2015 22:21:15 -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 yZo4siIcCQa3 for ; Fri, 17 Apr 2015 22:21:14 -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 C6D4C1A92FB for ; Fri, 17 Apr 2015 22:21:10 -0700 (PDT) Received: from mail-ob0-f171.google.com ([209.85.214.171]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0M4voU-1ZZOaA3kcA-00zDiH for ; Sat, 18 Apr 2015 07:21:09 +0200 Received: by obbeb7 with SMTP id eb7so85209769obb.3 for ; Fri, 17 Apr 2015 22:21:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.212.86 with SMTP id l83mr5561308oig.50.1429334466906; Fri, 17 Apr 2015 22:21:06 -0700 (PDT) Received: by 10.76.144.225 with HTTP; Fri, 17 Apr 2015 22:21:06 -0700 (PDT) In-Reply-To: <64FA6BC3-49D0-4EF6-8332-4ADBDB62BAA3@ieca.com> References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> <64FA6BC3-49D0-4EF6-8332-4ADBDB62BAA3@ieca.com> Date: Sat, 18 Apr 2015 01:21:06 -0400 Message-ID: From: Bodo Moeller To: Sean Turner Content-Type: multipart/alternative; boundary=001a113d23ec2a55670513f8dd9b X-Provags-ID: V03:K0:CjMHZTUx5CbC2GmsCDTlbB71P6bNHnf6Z97soehWNPjaFV24/kN i37vBZV3UfXZdIUH7X6vkMP7IJi22xRcVyYnAw09Mv3PXpEMeNIDwpw86Cvr9zy1cKxSu0f XOx75d77U2qMWfpvprlJ/VCqP+onzEFrBV6VT21EgVVP5JMrsLq2dG55yT97bEU3K37JOJ+ 02EKfffSpfIwS66HdWAGw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: draft-bmoeller-tls-falsestart@tools.ietf.org, "" Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2015 05:21:16 -0000 --001a113d23ec2a55670513f8dd9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Sean. Just to confirm, the WG -00 I-D will be essentially identical to the lasted individual submission, and then we'll work on the changes for -01, right? I've actually just left for a vacation, so it will be around a week and a half before I can submit the -00 draft. But then we're not in any kind of rush for this one. Bodo 2015-04-16 12:21 GMT-04:00 Sean Turner : > Based on list discussion we=E2=80=99re going to go adopt this draft as a = WG. > > Bodo please submit a WG version of this draft so we can begin addressing > Brian=E2=80=99s comments in the WG -01 version. > > Thanks everybody! > > spt > > On Mar 31, 2015, at 12:20, Sean Turner wrote: > > > All, > > > > There=E2=80=99s been some interested expressed in having > http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted as > a TLS WG item. If you would like for this draft to become a WG document, > and you are willing to review drafts as it moves through the process plea= se > indicate as much on this thread. If you are opposed to this being a WG > document, please say so (and say why). Thanks in advance. > > > > J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113d23ec2a55670513f8dd9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Sean.

Just to confirm, the WG -= 00 I-D will be essentially identical to the lasted individual submission, a= nd then we'll work on the changes for -01, right?

<= div>I've actually just left for a vacation, so it will be around a week= and a half before I can submit the -00 draft. But then we're not in an= y kind of rush for this one.

Bodo



2015-04-16 12:21 GMT-04:00 Sean Turner <turners@ieca.com>:
Based on list discussion we=E2=80= =99re going to go adopt this draft as a WG.

Bodo please submit a WG version of this draft so we can begin addressing Br= ian=E2=80=99s comments in the WG -01 version.

Thanks everybody!

spt

On Mar 31, 2015, at 12:20, Sean Turner <turners@ieca.com> wrote:

> All,
>
> There=E2=80=99s been some interested expressed in having http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ ado= pted as a TLS WG item.=C2=A0 If you would like for this draft to become a W= G document, and you are willing to review drafts as it moves through the pr= ocess please indicate as much on this thread.=C2=A0 If you are opposed to t= his being a WG document, please say so (and say why). Thanks in advance. >
> J&S

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

--001a113d23ec2a55670513f8dd9b-- From nobody Fri Apr 17 23:31: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 463F01A0015 for ; Fri, 17 Apr 2015 23:31:05 -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 U3z_9IdID-6G for ; Fri, 17 Apr 2015 23:31:03 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3CE1A000F for ; Fri, 17 Apr 2015 23:31:02 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-12v.sys.comcast.net with comcast id HJX21q00458ss0Y01JX2t5; Sat, 18 Apr 2015 06:31:02 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-14v.sys.comcast.net with comcast id HJX01q00J4uhcbK01JX1Ww; Sat, 18 Apr 2015 06:31:01 +0000 Message-ID: <5531FA24.4030800@brainhub.org> Date: Fri, 17 Apr 2015 23:31:00 -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: <20150418031052.221221B2A1@ld9781.wdf.sap.corp> In-Reply-To: <20150418031052.221221B2A1@ld9781.wdf.sap.corp> 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=1429338662; bh=CA4hoWGls47hJjjaKQ6p9FM0vV7/64diBV5KZgKfxik=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TOp2h6zO0r95Lg6gzUP01edV3uQi99g75YE5kcY0szAUnCLfSE/mX6pP1wTA8oPAK /KFvRYVx+HQwZVuXK4oI6eFhLk0BRLfdSPumtJhEUUmHlQohEuLFnZSLhC1Ts06Hr8 9i+QfAbU+wEmYeZ/KVPPQTmMvKBR+xz8iFfPMggaglClDw1/JWs+fNu0sT8TVbQYFW my1XdGP27bDaNrbkf3WXRVW4PVxZqDeoSKsjl/Z71I4oNaBcxCYGNq9TQnpwN9lYSO rd5vWIqdLcW0y4LCwuE0bT1HHIoPbyxVS5voh6a1P7cOAk8Wrj5utUEQgsHDd2UFZ/ dDofPdDdHRK5w== Archived-At: Subject: Re: [TLS] FFDHE and SHOULDs on usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2015 06:31:05 -0000 On 04/17/2015 08:10 PM, Martin Rex wrote: ... > > Could we just scrap the "based on xxx preference" nonsense entirely? > > The sender of the list sends whatever it sees fit, and the receiver > of the list has the privilege to pick what ever the receiver believes > is most appropriate from the receivers point of view. > > I never understood why (a) such a silly suggestion was made for > the ordering of cipher suites in ClientHello and (b) why any TLS server > implementaion would care for the client's ordering rather than enforcing > the server preference. If the client does not want something, it must > not offer it. If the server does not want something, it must not pick it. On ClientHello: Presumably the existence of ordering of client preferences in the TLS spec provides a way for a client to tell that "I really prefer this ciphersuite, while I have these others mostly for interoperability". There are other benefits. A server should be able to follow its ordering. One issue with making the server rule is that current TLS negotiation mechanism makes a) what server supports invisible, b) the ordering of the server set invisible, so at least from visibility/troubleshooting/tie-breaking point of view there is a benefit to consider the client order. ( It's not too difficult to write a tool that discovers a) and b), but I am only aware of tools that report a). ). One model that can work for a server is to split all supported ciphersuites into categories, order by these server categories and by ClientHello order within a category. For a simple example consider secure and legacy categories. The server prefers any ciphersuite from secure category to any from legacy. In more realistic scenarios there are more categories and the ordering of categories can be controlled by a policy. After the server selects the top category that it prefers, inside each category the server selects ciphers according to the client order. This thread is about groups. Here, as Martin said, if the client offers, say only ECDHE groups, the client order may not be relevant. The ordering of the mix of ECDHE+DHE groups can be useful in theory, but I expect that most clients will put ECDHE before DHE and servers that care about performance order by strength and type, by policy or hardcoding these preferences, leaving no say to the client. > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Apr 17 23:31: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 2BC881A0027 for ; Fri, 17 Apr 2015 23:31:52 -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_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_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 DYEBBs7VK3B7 for ; Fri, 17 Apr 2015 23:31:50 -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 5D3811A0006 for ; Fri, 17 Apr 2015 23:31:50 -0700 (PDT) Received: by wiun10 with SMTP id n10so41049608wiu.1 for ; Fri, 17 Apr 2015 23:31:49 -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=Kpr7cxcYN/Zjes09wDKZxfj3x5uk3bO2FGv6sm/DYU4=; b=rNc1T2gVFDk4FKhvqG5NL3zKhZKIS8A2PSc2GSE4pE80HNmuWbzkqx0fhbEPjWA6sd ZeqUcD55Fen8UTKMkTdaUXos9lbGOVdh/awSORd9rRBer7iICW85wuugqHb7AQ9FwEeI b2b73mfZzPCCFG5mqtWWT1OugfDsT81kdxIp4= 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=Kpr7cxcYN/Zjes09wDKZxfj3x5uk3bO2FGv6sm/DYU4=; b=B8bt65BYxAYkwFrdY9IaPLWEfqCznxGjC4fM9yOn8jQWspQnWKAmslOMn1B+UnpgXX BpTI9MlSyfC/frIiUM6HB7LsvGYWiznO3EW2NCp+WUNgBElH9OzyEkG4isODIIPcV0D1 uICz/kzmVd300Hjc4YE+boQbUoyPRRPt2nftS/Tj1IZearXnwQdD/4W3YOMZ6RQ2llUP 1Vw5vVRHIcipsfA1goOyhDR4wVgLryM4R0Arq0f3O+/JK1UAubAmkAFsdl6sCsJ/VwP/ gb9gQZSMihydr5TOBlqNDnE1QfmPVjqPb/GLy4f36AUins2pDF8bVeLjnT/NQWtNpDfv ueWw== X-Gm-Message-State: ALoCoQlHWWGeijcfSGSWK79xfpO7hSIHfY5SqYrFxYO/Tf/nOBZV+kcwmpffbU+bquu4u+/YBEtu MIME-Version: 1.0 X-Received: by 10.180.230.226 with SMTP id tb2mr7241978wic.64.1429338709103; Fri, 17 Apr 2015 23:31:49 -0700 (PDT) Received: by 10.28.104.138 with HTTP; Fri, 17 Apr 2015 23:31:49 -0700 (PDT) In-Reply-To: <20150418031052.221221B2A1@ld9781.wdf.sap.corp> References: <87fv80nnev.fsf@alice.fifthhorseman.net> <20150418031052.221221B2A1@ld9781.wdf.sap.corp> Date: Sat, 18 Apr 2015 08:31:49 +0200 Message-ID: From: Thijs van Dijk To: mrex@sap.com Content-Type: multipart/alternative; boundary=001a113612bc05293a0513f9da14 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] FFDHE and SHOULDs on usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2015 06:31:52 -0000 --001a113612bc05293a0513f9da14 Content-Type: text/plain; charset=UTF-8 On 18 April 2015 at 05:10, Martin Rex wrote: > Could we just scrap the "based on xxx preference" nonsense entirely? > > The sender of the list sends whatever it sees fit, and the receiver > of the list has the privilege to pick what ever the receiver believes > is most appropriate from the receivers point of view. > > I never understood why (a) such a silly suggestion was made for > the ordering of cipher suites in ClientHello and (b) why any TLS server > implementaion would care for the client's ordering rather than enforcing > the server preference. If the client does not want something, it must > not offer it. If the server does not want something, it must not pick it. > I still think it's a reasonable safeguard against lazy server implementations (e.g. mine): The naive way of implementing cipher agreement is to loop through the client's suggestions and pick the first one both client and server suport. If that happens to be an EXPORT/RC4 combo you're out of luck. However if either the client or the server exhibits a preference, you're almost guaranteed to do better than both sides' worst case. Furthermore, I think that conceptually, dropping client preference would equate to making server preference a requirement. The TLS1.3 spec should reflect this in some way, so it's not very language-economic either. -Thijs --001a113612bc05293a0513f9da14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 8 April 2015 at 05:10, Martin Rex <mrex@sap.com> wrote:
Could we just scrap the "based on xxx prefere= nce" nonsense entirely?

The sender of the list sends whatever it sees fit, and the receiver
of the list has the privilege to pick what ever the receiver believes
is most appropriate from the receivers point of view.

I never understood why (a) such a silly suggestion was made for
the ordering of cipher suites in ClientHello and (b) why any TLS server
implementaion would care for the client's ordering rather than enforcin= g
the server preference.=C2=A0 If the client does not want something, it must=
not offer it.=C2=A0 If the server does not want something, it must not pick= it.

I still think it's a reasonabl= e safeguard against lazy server implementations (e.g. mine): The naive way = of implementing cipher agreement is to loop through the client's sugges= tions and pick the first one both client and server suport. If that happens= to be an EXPORT/RC4 combo you're out of luck.

However if either the client or the server exhibits a preference, you'= re almost guaranteed to do better than both sides' worst case.

Furthermore, I think that conceptually, dropping client pr= eference would equate to making server preference a requirement. The TLS1.3= spec should reflect this in some way, so it's not very language-econom= ic either.

-Thijs
--001a113612bc05293a0513f9da14-- From nobody Sat Apr 18 07:44: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 525871A874F for ; Sat, 18 Apr 2015 07:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 41iHOg1W9Tmz for ; Sat, 18 Apr 2015 07:44:14 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [67.18.62.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B33E1A874E for ; Sat, 18 Apr 2015 07:44:14 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 7AB61264DBE86; Sat, 18 Apr 2015 09:44:13 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 6C462264DBE3C for ; Sat, 18 Apr 2015 09:44:13 -0500 (CDT) Received: from [96.231.218.31] (port=55404 helo=[192.168.1.13]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YjTye-0006bq-K7; Sat, 18 Apr 2015 09:44:12 -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: Date: Sat, 18 Apr 2015 10:44:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58C4C442-6E91-4840-B235-EF911B77379D@ieca.com> References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> <64FA6BC3-49D0-4EF6-8332-4ADBDB62BAA3@ieca.com> To: Bodo Moeller 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: 96.231.218.31 X-Exim-ID: 1YjTye-0006bq-K7 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.13]) [96.231.218.31]:55404 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: draft-bmoeller-tls-falsestart@tools.ietf.org, "" Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2015 14:44:15 -0000 On Apr 18, 2015, at 01:21, Bodo Moeller wrote: > Thanks, Sean. >=20 > Just to confirm, the WG -00 I-D will be essentially identical to the = lasted individual submission, and then we'll work on the changes for = -01, right? I think that=92s probably the easiest way for folks to track the = changes. You can do one, get it posted and then follow up later in the = day with the known changes to keep the ball rolling.. > I've actually just left for a vacation, so it will be around a week = and a half before I can submit the -00 draft. But then we're not in any = kind of rush for this one. Thanks for the heads up, I=92ll ping you if I don=92t hear from you when = you get back. Enjoy your vacation. spt > Bodo >=20 >=20 >=20 > 2015-04-16 12:21 GMT-04:00 Sean Turner : > Based on list discussion we=92re going to go adopt this draft as a WG. >=20 > Bodo please submit a WG version of this draft so we can begin = addressing Brian=92s comments in the WG -01 version. >=20 > Thanks everybody! >=20 > spt >=20 > On Mar 31, 2015, at 12:20, Sean Turner wrote: >=20 > > All, > > > > There=92s been some interested expressed in having = http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted = as a TLS WG item. If you would like for this draft to become a WG = document, and you are willing to review drafts as it moves through the = process please indicate as much on this thread. If you are opposed to = this being a WG document, please say so (and say why). Thanks in = advance. > > > > J&S >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Sat Apr 18 21: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 5E74B1AD09D for ; Sat, 18 Apr 2015 21:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 fivGv0RsOlNA for ; Sat, 18 Apr 2015 21:23:06 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193681AD09C for ; Sat, 18 Apr 2015 21:23: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=uoa; t=1429417386; x=1460953386; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WtCkuLF+Qmg5C9iEUQdkIpdGAe88yCaBNdchtaY16nQ=; b=DWZTF8vPweqLGR9viZ4pDRoSgdVuwnKxYNeptYwezuX7835JNFB3Rnl1 nQ0XHLtYlwz+mExxY+SJJQAqaycDIg0saUnn57cZpOQB9EfHvdG3WJ1/c xuVUtTMpAdsQNAHxFS1njmdDE0cEJiXl/zgJ7pRBwyZOVyrjKNCbs31WY 4=; X-IronPort-AV: E=Sophos;i="5.11,602,1422874800"; d="scan'208";a="321134535" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Apr 2015 16:23:01 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Sun, 19 Apr 2015 16:23:01 +1200 From: Peter Gutmann To: Russ Housley , IETF TLS Thread-Topic: [TLS] HSM-friendly Key Computation Thread-Index: AQHQeUD/sI9Vub+bgUe0zBomNwpDNJ1Tvnox Date: Sun, 19 Apr 2015 04:22:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> In-Reply-To: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.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] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2015 04:23:08 -0000 Russ Housley writes:=0A= =0A= >If one wants to implement the cryptographic functions in a Hardware Securi= ty=0A= >Module (HSM), this structure is far from ideal.=0A= =0A= Weelll... it's far from ideal if you want to use traditional/historic PKCS = #11=0A= mechanisms, but since a new PRF will need updated HSM support anyway it=0A= shouldn't be any problem to accommodate it, and now that PKCS #11 is being= =0A= managed by OASIS rather than RSADSI/EMC and things have got moving again in= =0A= advancing the spec, it shouldn't be that big a deal. If you look at how=0A= CKM_TLS_PRF works, it's a significant change from how C_DeriveKey() normall= y=0A= functions that was made in order to accommodate how TLS wants to do things.= =0A= For the TLS 2.0 (a.k.a. 1.3) PRF the PKCS #11 folks can make the same=0A= accommodation. It's an issue for the HSM vendors to adapt, not the TLS spe= c=0A= to adapt.=0A= =0A= Peter.=0A= From nobody Sun Apr 19 01:27: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 7DF481A6F2A for ; Sun, 19 Apr 2015 01:27:19 -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 49fR66qRwWAE for ; Sun, 19 Apr 2015 01:27:17 -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 C21541B2A81 for ; Sun, 19 Apr 2015 01:27:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,602,1422918000"; d="scan'208";a="112027089" 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; 19 Apr 2015 10:27:14 +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: <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sun, 19 Apr 2015 10:27:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2098) Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2015 08:27:19 -0000 Hi, > On 19 Apr 2015, at 06:22, Peter Gutmann = wrote: >=20 > Russ Housley writes: >=20 >> If one wants to implement the cryptographic functions in a Hardware = Security >> Module (HSM), this structure is far from ideal. >=20 > Weelll... it's far from ideal if you want to use traditional/historic = PKCS #11 > mechanisms, but since a new PRF will need updated HSM support anyway = it > shouldn=E2=80=99t be any problem to accommodate it =E2=80=A6 > It's an issue for the HSM vendors to adapt, not the TLS spec > to adapt. I agree with Peter. Anyway, everyone will have to spend some time and = money to update their HSMs at some point. That said, if we can sync all major changes in a batch, we should try to = do so. But in general it should not be our concern, else we can never improve = the crypto and the protocol. Cheers, B.= From nobody Sun Apr 19 11:49: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 620331A8F39 for ; Sun, 19 Apr 2015 11:49:55 -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 LtQLzrItgB-c for ; Sun, 19 Apr 2015 11:49:53 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2F61A8F33 for ; Sun, 19 Apr 2015 11:49:53 -0700 (PDT) Received: by qgfi89 with SMTP id i89so43576542qgf.1 for ; Sun, 19 Apr 2015 11:49:52 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bawt2J2DbpIKSmA3iecHmVNx1k7LNjQ/sNFs+B0ZMS8=; b=j9Mfcpmzhz5B7KsqaQ3srJGFnsM5pypmy/C+KLNFBkLRAt6RTHkG/HgtNaJWt5xHwR Pwkc4+4+ZYXluTFpaWTHH4KFf0LvaxyLMXge5jtWnjpWEOsp/7fOFq5MgiAtAxrBei6f ReLK087aU4KZ6iuape1jdUfw1tIobB7YkffeBx8UqWJ4aTtSzCmu7u8GztEYtQ3WfkXb wh/kEMSMdlutAn/eN27Q/4H9RykSfcGOlVuQsVAiGcoSCqiuxiroUeUiWBQTtn9kqUci wxFDOs6l7Y4/EDY1aHTgt9GdcyxoYOzEu0zZu3xmWEieT9LAsMR4tUSS+65F+ecEmlpY TWug== X-Gm-Message-State: ALoCoQkJw/lXHi2Uu8HuPz5/az+PhlYEC+ydZXBRmhNNboZgH2NA+jJeknGx36FtoBDVqlcNixqC X-Received: by 10.55.25.34 with SMTP id k34mr22871227qkh.12.1429469392694; Sun, 19 Apr 2015 11:49:52 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:a9e1:16a3:552:1db4? ([2601:a:2a00:84:a9e1:16a3:552:1db4]) by mx.google.com with ESMTPSA id z14sm10313735qge.7.2015.04.19.11.49.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 11:49:52 -0700 (PDT) Message-ID: <5533F8D6.9070500@nthpermutation.com> Date: Sun, 19 Apr 2015 14:49:58 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2015 18:49:55 -0000 On 4/19/2015 12:22 AM, Peter Gutmann wrote: > Russ Housley writes: > >> If one wants to implement the cryptographic functions in a Hardware Security >> Module (HSM), this structure is far from ideal. > Weelll... it's far from ideal if you want to use traditional/historic PKCS #11 > mechanisms, but since a new PRF will need updated HSM support anyway And that's where we differ I think. > it > shouldn't be any problem to accommodate it, and now that PKCS #11 is being > managed by OASIS rather than RSADSI/EMC and things have got moving again in > advancing the spec, it shouldn't be that big a deal. If you look at how > CKM_TLS_PRF works, it's a significant change from how C_DeriveKey() normally > functions that was made in order to accommodate how TLS wants to do things. > For the TLS 2.0 (a.k.a. 1.3) PRF the PKCS #11 folks can make the same > accommodation. It's an issue for the HSM vendors to adapt, not the TLS spec > to adapt. It's not exactly that. If you go back and look at PKCS11 2.20 , you'll note that they just placed the TLS/SSL functionality in by rote - mainly by hacking the PKCS11 mechanism construct to provide a way of outputting multiple keys. There are actually SSL mechanisms: CKM_SSL3_MASTER_KEY_DERIVE CKM_SSL3_KEY_AND_MAC_DERIVE CKM_SSL3_PRE_MASTER_KEY_GEN CKM_SSL3_MASTER_KEY_DERIVE_DK And TLS mechanisms CKM_TLS_PRE_MASTER_KEY_GEN CKM_TLS_MASTER_KEY_DERIVE CKM_TLS_KEY_AND_MAC_DERIVE CKM_TLS_MASTER_KEY_DERIVE_DH They also handily provided the CKM_TLS_PRF mechanism which basically allowed you to extract ANY key stream material from a given master secret (since all the bytes from a call using this mechanism were provided nicely packaged in the place specified in the mechanism structure). But that was as was requested by TLS implementers and probably didn't get enough vetting by the security deep thinkers. CKM_SSL_KEY_AND_MAC_DERIVE, CKM_TLS_KEY_AND_MAC_DERIVE and CKM_TLS_PRF are insecure in that they allow trivial extraction of material from a derived key stream. That is an artifact of multiple things: how the TLS KDF function is currently defined, the use of key exporters with out a model for cryptographic separation; the use of TLS specific functions. PKCS11 tries to fix the worst of these in the new version when it added support for TLS1.2: 2.40 deprecates CKM_TLS_PRF, adds a CKM_TLS_MAC function for signing the finished messages, deprecates CKM_TLS_KEY_AND_MAC_DERIVE in favor of CKM_TL12_KEY_SAFE_DERIVE. There is a CKM_TLS12_KEY_AND_MAC_DERIVE, but it comes with a black box warning. Its there only because the current AEAD suites require a source of session nonce information and they get it from the IV production. What I would love to see for TLS1.3 is NO TLS specific mechanisms being added to PKCS11. That if we still sign the finished message, we use a true MAC function. That if we derive keys, we use a bog standard KDF. That we stomp on every TLS specific twist unless there is a specific security need to keep TLS secure. At this point the set of KDFs in PKCS11 is very protocol specific and constitute a good part of the non-common mechanisms. Most of the rest seem to relate to one family or another (e.g. suite b, GOST, etc). It would be great if we could pick a standardized KDF of family of KDFs for the IETF and not go through this again. Mike > > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Apr 19 23:42: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 A15551ACE74 for ; Sun, 19 Apr 2015 23:42:48 -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 OPxZnRT4cU1y for ; Sun, 19 Apr 2015 23:42:46 -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 9E3DF1ACE72 for ; Sun, 19 Apr 2015 23:42:46 -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 0DBF581867; Mon, 20 Apr 2015 09:42:43 +0300 (EEST) Date: Mon, 20 Apr 2015 09:42:43 +0300 From: Ilari Liusvaara To: Michael StJohns Message-ID: <20150420064243.GA7322@LK-Perkele-VII> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5533F8D6.9070500@nthpermutation.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2015 06:42:48 -0000 On Sun, Apr 19, 2015 at 02:49:58PM -0400, Michael StJohns wrote: > > What I would love to see for TLS1.3 is NO TLS specific mechanisms being > added to PKCS11. That if we still sign the finished message, we use a > true MAC function. That if we derive keys, we use a bog standard KDF. That > we stomp on every TLS specific twist unless there is a specific security > need to keep TLS secure. Not possible. There are features (e.g. extractor and resumption/unique interaction) that can't be feasibly removed (or even deprecated) and which need PRF'ing secret keys into public data. Also, true MAC functions just aren't enough for some places (such as deriving the various master secrets or unique value). -Ilari From nobody Mon Apr 20 05:42: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 0033F1A1BE7 for ; Mon, 20 Apr 2015 05:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.512 X-Spam-Level: X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OeukZ6ols42 for ; Mon, 20 Apr 2015 05:41:58 -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 BE51E1A1BF1 for ; Mon, 20 Apr 2015 05:41:54 -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 1A86FAC7A9; Mon, 20 Apr 2015 12:41:53 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-127.brq.redhat.com [10.34.0.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3KCfp4R005633 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 20 Apr 2015 08:41:53 -0400 From: Hubert Kario To: tls@ietf.org, mrex@sap.com Date: Mon, 20 Apr 2015 14:41:45 +0200 Message-ID: <6747577.524RCq2GsE@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.4 (Linux/3.19.3-100.fc20.x86_64; KDE/4.14.6; x86_64; ; ) In-Reply-To: <20150418031052.221221B2A1@ld9781.wdf.sap.corp> References: <20150418031052.221221B2A1@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3449153.6U6TQhFFqa"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] FFDHE and SHOULDs on usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2015 12:42:00 -0000 --nextPart3449153.6U6TQhFFqa Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Saturday 18 April 2015 05:10:52 Martin Rex wrote: > Daniel Kahn Gillmor wrote: > >> Groups are ordered based on client preference, noting the addition= al > >> ordering considerations in Section 6.1. > >=20 > > Also, this rewrite says "ordered based on client preferences" but > > doesn't indicate which order based on client preferences: most pref= erred > > to least preferred or the other way around. It may be pedantic, bu= t > > this is exactly the sort of pedantry that RFCs should include. >=20 > Could we just scrap the "based on xxx preference" nonsense entirely? >=20 > The sender of the list sends whatever it sees fit, and the receiver > of the list has the privilege to pick what ever the receiver believes= > is most appropriate from the receivers point of view. >=20 > I never understood why (a) such a silly suggestion was made for > the ordering of cipher suites in ClientHello and (b) why any TLS serv= er > implementaion would care for the client's ordering rather than enforc= ing > the server preference. If the client does not want something, it mus= t > not offer it. If the server does not want something, it must not pic= k it. If you have a relatively recent desktop CPU you don't care if you're us= ing AES=20 or ChaCha20. But if you're on a CPU which doesn't have a hardware accel= eration=20 for AES and is relatively slow (think mobile ARM), then you really woul= d=20 prefer ChaCha20 cipher over AES. So server should _consider_ client preference. And the clients should h= ave an=20 order which is sane. =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 --nextPart3449153.6U6TQhFFqa 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 iQIcBAABCgAGBQJVNPQPAAoJEJKo0bgB0vX1lFQP/1lAuUtbQWcd7657XaCj9ETd YflKerSlMVQQd3Ar/P/FJgOFNWv4W+ptP17gIekQN4J015nYk1ZYXwx0Tb+lk/Xf TOWYs1rPMkRsoY2iv4S/5jc4qfmDbAkoM02+eKnMak8E+e55CP2tWAFt3ZGJuLwo tTJ86jIfQmelg5dbreLOwlg/c2gYTgnlVx1JiOR/DPJ/3yfqlkfWGfiRg7YlgFCg 4jgxfanTAyNJ5B3eqY4tWVvfzWJhApgY3dhK47W1471rn1xx6CW/spEepaKORC8R deT763JEMXPtK9qWQ0AkRezaM0ABoRDugx3rgBPwn3nV9aifCBtuW54aRJgNigBf TPF+PuuJmzFb2c2WskkozOSGCrI/0+55QVf8v44pAToxr5NliiLrHG8mlZSUms+C 14tWHqqALffIy0HvNTPDRAk2kcESB9f/cLpQ7sfTzYBBHEFi24iwB6G5avBus0Jc K8CeNmQ4smANo8k2zDq0S3d8cTfEadqWUCqO9cPmK7Bxf4YoS0FQZYxn+udzR48t /ID0yc47JcI7xH4sr2hn9Opf0KUOCYbYWwF5rw87MYb7AZQVNRiRICR6dLvXEoMs yhOZT7ZV2v6z7wtDQQzTojWi2ejN30wvai3y0cRvTBa7CK2L6m68z0u9dNKXlmrg oRX77calDj/JksMsb7hr =Hgid -----END PGP SIGNATURE----- --nextPart3449153.6U6TQhFFqa-- From nobody Mon Apr 20 09:10: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 D20841B2F47 for ; Mon, 20 Apr 2015 09:09: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 FJOhCeqrOUem for ; Mon, 20 Apr 2015 09:09:57 -0700 (PDT) Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A5D1B2F45 for ; Mon, 20 Apr 2015 09:09:57 -0700 (PDT) Received: by qkgx75 with SMTP id x75so184305277qkg.1 for ; Mon, 20 Apr 2015 09:09: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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8zdb/LtMhFL8yBNoXRskt0oM1xijecogqHJygAqYbDc=; b=CRjGN/QhbRoriJDx6OgUfLKQMoDHsQrBcMEvE8xYxMzeLu2BSQM6U8hA5KA1c+PZMD Vzb1qR/8zMLQUQodb4REw39RVGQoU+5t0e0TdRWdE+yL/UeMY0LDimyFdTkLbxBFVZDy OsLYuJUXoc3C/VtjguCZD6D7NX1djme0ciNGSyAycNVyiLWurmkJXDFcVoBWPeGCig3V i/K0O9szjMM8FXAeCr2++WSS+4AeabCqmiNMxLuu581FVHFyOHlcrhjI+jcvoRZClJ+F NbdxTTg1qTYP0ZCPG9iGXFKd+5hHbJUticEn6Oy03Rlw7Lr4NyyGzpyykOgsLF5YdRSD gSQA== X-Gm-Message-State: ALoCoQmPRHxBFADkJ6QnJSC1ZwLuTUL8NIifBRsIFjNLtZEpz4H5v4W/dS/CFr6nuG+KM0ZP1miL MIME-Version: 1.0 X-Received: by 10.229.193.69 with SMTP id dt5mr4452187qcb.3.1429546196452; Mon, 20 Apr 2015 09:09:56 -0700 (PDT) Received: by 10.140.80.165 with HTTP; Mon, 20 Apr 2015 09:09:56 -0700 (PDT) X-Originating-IP: [172.56.3.80] In-Reply-To: <20150420064243.GA7322@LK-Perkele-VII> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> Date: Mon, 20 Apr 2015 12:09:56 -0400 Message-ID: From: "StJohns, Michael" To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c24efe3ae11505142a2954 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2015 16:09:59 -0000 --001a11c24efe3ae11505142a2954 Content-Type: text/plain; charset=UTF-8 On Monday, April 20, 2015, Ilari Liusvaara wrote: > On Sun, Apr 19, 2015 at 02:49:58PM -0400, Michael StJohns wrote: > > > > What I would love to see for TLS1.3 is NO TLS specific mechanisms being > > added to PKCS11. That if we still sign the finished message, we use a > > true MAC function. That if we derive keys, we use a bog standard KDF. > That > > we stomp on every TLS specific twist unless there is a specific security > > need to keep TLS secure. > > Not possible. There are features (e.g. extractor and resumption/unique > interaction) that can't be feasibly removed (or even deprecated) and which > need PRF'ing secret keys into public data. > > Also, true MAC functions just aren't enough for some places (such as > deriving the various master secrets or unique value). > > > I'm not quite sure how you've come to this conclusion. The underlying function for a KDF is generally a MAC function which by definition produces public data. It's only when bound into a KDF that it by definition produces secret data. The main problem we've encountered is that we use the same key to produce public (IV) data and private key material. Fixing this is more an issue of how to cryptographically isolate products of the diverse operations in a way that enhances security. Replacing the current functions with off the shelf ones along with a few tweaks to the key derivation mixins and key tree can be done without removing any functionality. Mike > > -Ilari > --001a11c24efe3ae11505142a2954 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, April 20, 2015, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Sun, Apr 19, 2015 at 02:49:58PM -0400, Mich= ael StJohns wrote:
>
> What I would love to see for TLS1.3 is NO TLS specific mechanisms bein= g
> added to PKCS11.=C2=A0 =C2=A0 That if we still sign the finished messa= ge, we use a
> true MAC function.=C2=A0 That if we derive keys, we use a bog standard= KDF.=C2=A0 That
> we stomp on every TLS specific twist unless there is a specific securi= ty
> need to keep TLS secure.

Not possible. There are features (e.g. extractor and resumption/unique
interaction) that can't be feasibly removed (or even deprecated) and wh= ich
need PRF'ing secret keys into public data.

Also, true MAC functions just aren't enough for some places (such as deriving the various master secrets or unique value).




I'm not quite sure = how you've come to this conclusion.=C2=A0 The underlying function for a= KDF is generally a MAC function which by definition produces public data.= =C2=A0 It's only when bound into a KDF that it by definition produces s= ecret data.=C2=A0 The main=C2=A0problem we've encountered is that we us= e the same key to produce public (IV) data and private key material. =C2=A0= Fixing this is more an issue of how to cryptographically isolate products = of the diverse operations in a way that enhances security. =C2=A0=C2=A0

Replacing the current functions with off the shelf on= es along with a few tweaks to the key derivation mixins and key tree=C2=A0c= an be done without removing any functionality. =C2=A0

Mike

-Ilari
--001a11c24efe3ae11505142a2954-- From nobody Mon Apr 20 09:38: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 132E91A1A39 for ; Mon, 20 Apr 2015 09:38:00 -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 kMMEf_HyMhAG for ; Mon, 20 Apr 2015 09:37:57 -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 B83101A1A33 for ; Mon, 20 Apr 2015 09:37:57 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 5020A90040; Mon, 20 Apr 2015 19:37:55 +0300 (EEST) Date: Mon, 20 Apr 2015 19:37:55 +0300 From: Ilari Liusvaara To: "StJohns, Michael" Message-ID: <20150420163755.GA15511@LK-Perkele-VII> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@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] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2015 16:38:00 -0000 On Mon, Apr 20, 2015 at 12:09:56PM -0400, StJohns, Michael wrote: > On Monday, April 20, 2015, Ilari Liusvaara > wrote: > > > On Sun, Apr 19, 2015 at 02:49:58PM -0400, Michael StJohns wrote: > > > > > > What I would love to see for TLS1.3 is NO TLS specific mechanisms being > > > added to PKCS11. That if we still sign the finished message, we use a > > > true MAC function. That if we derive keys, we use a bog standard KDF. > > That > > > we stomp on every TLS specific twist unless there is a specific security > > > need to keep TLS secure. > > > > Not possible. There are features (e.g. extractor and resumption/unique > > interaction) that can't be feasibly removed (or even deprecated) and which > > need PRF'ing secret keys into public data. > > I'm not quite sure how you've come to this conclusion. The underlying > function for a KDF is generally a MAC function which by definition produces > public data. It's only when bound into a KDF that it by definition > produces secret data. The main problem we've encountered is that we use > the same key to produce public (IV) data and private key material. Fixing > this is more an issue of how to cryptographically isolate products of the > diverse operations in a way that enhances security. Maybe I used bad terminology, but... There are other places in TLS that fundamentally need to (indirectly) derive public data out of secret key material. E.g. extractor and unique/resumption-interaction. There might be others as well. -Ilari From nobody Wed Apr 22 10:03: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 C371A1B380F for ; Wed, 22 Apr 2015 10:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sziTqPehvxIv for ; Wed, 22 Apr 2015 10:03: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 274EA1B3866 for ; Wed, 22 Apr 2015 10:02:52 -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 C5FE8AC7A3 for ; Wed, 22 Apr 2015 17:02:51 +0000 (UTC) Received: from rrelyea-laptop.usersys.redhat.com (dhcp-16-202.sjc.redhat.com [10.14.16.202]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3MH2peH005569 for ; Wed, 22 Apr 2015 13:02:51 -0400 Message-ID: <5537D43A.9080802@REDHAT.COM> Date: Wed, 22 Apr 2015 10:02:50 -0700 From: Robert Relyea User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> In-Reply-To: <20150420163755.GA15511@LK-Perkele-VII> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030005080708030707040608" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2015 17:03:10 -0000 This is a cryptographically signed message in MIME format. --------------ms030005080708030707040608 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 04/20/2015 09:37 AM, Ilari Liusvaara wrote: > On Mon, Apr 20, 2015 at 12:09:56PM -0400, StJohns, Michael wrote: >> On Monday, April 20, 2015, Ilari Liusvaara >> wrote: >> >>> On Sun, Apr 19, 2015 at 02:49:58PM -0400, Michael StJohns wrote: >>>> What I would love to see for TLS1.3 is NO TLS specific mechanisms be= ing >>>> added to PKCS11. That if we still sign the finished message, we u= se a >>>> true MAC function. That if we derive keys, we use a bog standard KD= F. >>> That >>>> we stomp on every TLS specific twist unless there is a specific secu= rity >>>> need to keep TLS secure. >>> Not possible. There are features (e.g. extractor and resumption/uniqu= e >>> interaction) that can't be feasibly removed (or even deprecated) and = which >>> need PRF'ing secret keys into public data. >> I'm not quite sure how you've come to this conclusion. The underlying= >> function for a KDF is generally a MAC function which by definition pro= duces >> public data. It's only when bound into a KDF that it by definition >> produces secret data. The main problem we've encountered is that we u= se >> the same key to produce public (IV) data and private key material. F= ixing >> this is more an issue of how to cryptographically isolate products of = the >> diverse operations in a way that enhances security. > Maybe I used bad terminology, but... > > There are other places in TLS that fundamentally need to (indirectly) d= erive > public data out of secret key material. That's not a a problem. The problem is using the same mechanism to=20 derive the public data that we use to derive the keys. It's even OK to use the same secret key for both (from an HSM POV). What Michael is saying is that there are existing functions for both KDF = (secret material -> key) and Mac (secret material-> unique public data). = He's requesting that TLS not have it's own versions of these functions. So there are really 3 things being discussed here and there is some=20 conflation: 1) The use of the same mechanism to create both secret and public data.=20 This is the most serious issue because there is no work around for=20 HSM's, today people with access to HSM's can use the existing mechanism=20 for IV to leak actual keys protected by the HSM. 2) The use of a single mechanism to generate multiple keys (and IVs) in=20 a single operation. This isn't HSM pain, it's more a PKCS #11 pain. I=20 think this is more of a 'cleanliness' issue. PKCS #11 may still choose=20 to provide a single mechanism for performance reasons. 3) The use of yet another KDF and MAC. The world has lots of KDF's and=20 MAC's out there, we does TLS need another. I'm a bit ambivalent about=20 this. In an ideal world we would all use the same KDFs rather than=20 inventing a new one for each protocol. On the other hand TLS is a big=20 enough fish I don't see a big issue having it's own. I'd rather someone=20 propose exactly what other KDF TLS would use. Currently I don't support=20 many KDF's myself, TLS being the main one. For me 1) is the only show stopper, 2 and 3 are basically bike shedding=20 (though I admit we are talking some pretty ugly bike sheds;). bob > > E.g. extractor and unique/resumption-interaction. There might be others= as > well. > > > -Ilari > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------ms030005080708030707040608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMkDCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGVDCCBTygAwIBAgICUgMwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDA4MTgxNzM2NTZa Fw0xNjA4MTgyMDIyMTZaMHExCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIw EAYDVQQHEwlTdW5ueXZhbGUxFjAUBgNVBAMTDVJvYmVydCBSZWx5ZWExITAfBgkqhkiG9w0B CQEWEnJyZWx5ZWFAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALaHdxkUfIMsevBCIhC9bc7W/ewubBApILdiV8nATR61ZTLRzL5cbxy5WVXzH2RaV/ZPVIiK QYhIybxQe5Se2m4f/QJbOJ994X22Y7ql3kz5z/OT6LuCSC8/F/ZSou8oTSrvfqMnI+agI8G7 yNHvjG1nCAjG4dAHHnu5VXz/j9V49vcR/YTypoM31XxF2fnULKvI6h3+mknSyjzxF5YLmqYM Ln8XcPeS7b1b9mpVbzj/kXQko5q07t2ohR1GDH4tawa+z+DBKU2qx0nv1x2dcMaZYc5rib6p Spu88V5gtdGucXFAmh7M+6pxgqZ0WZKPZXKTHKZ1q4WhB8I6kbXthxkCAwEAAaOCAtgwggLU MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAdBgNVHQ4EFgQUwcvdwzpAypC2eMSbGqWVJ5t1f88wHwYDVR0jBBgwFoAUrlWDb+wxyrn3 HfqvazHzyB3jrLswHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQuY29tMIIBTAYDVR0gBIIB QzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg YWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRo ZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMu MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5j cmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3Ns LmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFy dHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQsFAAOCAQEAV7W9/gOTxbEgaos3 TmT/ywzujSDWJI9Gb76RdogMZdrCh2dEF723VfHYW/C5D8CW98vLSHky3p1C7WEq3ymbufjt 7v5tRY+JIP+NbykC4qJcNWJH2cI+IhpbeFowlTbd0beV4PaUibk2679mkpP0nGyePK6LTF8v KkgKkeJC2pdIM+msveJSCI3c4rq+ALzQ6CXsYd39KoMc1fXEZmk5mAo84ZwviGPQE+oG3EgJ 2Kb5wYsAeCdWbqaMPR93ZaJKve1hCtzyeBp8ZZDEVDddZrCKZjmQugURkjbKCKPvAWplXMOh mJxpIQgiAYkCQpjqc66pHx31esajFB0x5yCR7TGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlIDMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyMjE3MDI1MFowIwYJKoZIhvcN AQkEMRYEFIUFCMAmgvOQI+Izj+Ram894PnqLMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUD BAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJSAzCBpgYLKoZIhvcNAQkQAgsxgZag gZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICUgMwDQYJKoZIhvcNAQEB BQAEggEABTUMSPwoQNxuf7C3nUT737egRU50nY6BeH18BA7tRAeOsROe5NcSEpDA+eZO/1SM LYEvmskdPpspHoxOeyp+kCfDlXR5BcWjjlOvfC5qEJ0bHkZrPkDSLqGqNv6uFDqf4+aqpHON L890EFEmVys6f/n4IGSyobIeCSzybLsuYG9sFtcmkkA+bPwoG5JrEjBzdbHeyid1RSveuTaQ zifmD0VfwCKh+B7tNrbxeDzIiu6ZCWSAVI3kNqJfFNTnjbuqDFB+uo+YaBcNNXMtg3z6RRSa OiUGNk4h9DFcxuASOWNFP3y8NJsfi0JaqTzyjCwYwUsJSWE+bFMIvdtVV2ozngAAAAAAAA== --------------ms030005080708030707040608-- From nobody Wed Apr 22 10:35: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 DA4F51B38EA for ; Wed, 22 Apr 2015 10:35:32 -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 wMFHC0vjHXw0 for ; Wed, 22 Apr 2015 10:35:31 -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 598A81B38EF for ; Wed, 22 Apr 2015 10:35:29 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id BE9B1699A6; Wed, 22 Apr 2015 20:35:26 +0300 (EEST) Date: Wed, 22 Apr 2015 20:35:26 +0300 From: Ilari Liusvaara To: Robert Relyea Message-ID: <20150422173526.GA14496@LK-Perkele-VII> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5537D43A.9080802@REDHAT.COM> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2015 17:35:33 -0000 On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote: > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote: > > > >There are other places in TLS that fundamentally need to (indirectly) derive > >public data out of secret key material. > That's not a a problem. The problem is using the same mechanism to derive > the public data that we use to derive the keys. > It's even OK to use the same secret key for both (from an HSM POV). > > What Michael is saying is that there are existing functions for both KDF > (secret material -> key) and Mac (secret material-> unique public data). > He's requesting that TLS not have it's own versions of these functions. So would using two different PRF functions, one for parts that don't downgrade and another for parts that do downgrade (e.g. IV derivation, unique / finished calculations, exporter calculations, etc..) solve the issue? (Of course, the two functions should be closely related, so not to annoy software implementations too much)... -Ilari From nobody Wed Apr 22 10:38: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 1A3201B3901 for ; Wed, 22 Apr 2015 10:38: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 lCvvLaAbveW8 for ; Wed, 22 Apr 2015 10:38:31 -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 BF4FA1B3904 for ; Wed, 22 Apr 2015 10:38:26 -0700 (PDT) Received: by widdi4 with SMTP id di4so186876450wid.0 for ; Wed, 22 Apr 2015 10:38: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=pI3ms748oD6iislx/hXFETiLpVZLq+VHsmXttUx+/5s=; b=jg0WgRiruQpDKaJn7otKCOrt3MRmoMLk6LmpuULxum+zNM1UPNLRb9yyErXDCH+eAb b7zHXMzPtk1Ew2+cLd2u+N/g+O9bYZYjeUlp/Uu8yE0F4JSm97ATD1mkgwlshMRtUou/ hEtI+7rKIfeRvbYAOefpNhJwkgAV3+H3TqX0cgzPncqN0ydGT+ShABKn5ZDk/2obecXH uTMUVm65dqL8PO/9swp28QTWkMMeD8G0HFuifV/m3O7WexBEc5LnnUL9dB27JtSHlRKL jT5tW6Tuj2grbDyqtCb2HSZ+kirnQ+Lqy9Q6/W0hK6AZCmZ5OYv+F4GSRGsvjOQtbgUe c6yQ== X-Gm-Message-State: ALoCoQnNhy6BDRSENsd9ocxenhnR93EZ5HToD5wmb+gLH5PFfd5xPuHj0KtRgrLyw8gWUddz0p/h X-Received: by 10.180.74.208 with SMTP id w16mr7958014wiv.31.1429724305504; Wed, 22 Apr 2015 10:38:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Wed, 22 Apr 2015 10:37:45 -0700 (PDT) In-Reply-To: <20150422173526.GA14496@LK-Perkele-VII> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 22 Apr 2015 13:37:45 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d043892175b5147051453a1ab Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2015 17:38:33 -0000 --f46d043892175b5147051453a1ab Content-Type: text/plain; charset=UTF-8 If we're using HKDF-Extract, can we just key off different labels? -Ekr On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote: > > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote: > > > > > >There are other places in TLS that fundamentally need to (indirectly) > derive > > >public data out of secret key material. > > That's not a a problem. The problem is using the same mechanism to derive > > the public data that we use to derive the keys. > > It's even OK to use the same secret key for both (from an HSM POV). > > > > What Michael is saying is that there are existing functions for both KDF > > (secret material -> key) and Mac (secret material-> unique public data). > > He's requesting that TLS not have it's own versions of these functions. > > So would using two different PRF functions, one for parts that don't > downgrade and another for parts that do downgrade (e.g. IV derivation, > unique / finished calculations, exporter calculations, etc..) solve the > issue? > > (Of course, the two functions should be closely related, so not to > annoy software implementations too much)... > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043892175b5147051453a1ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we're using HKDF-Extract, can we just key off diffe= rent labels?

-Ekr


On Wed, Apr 22, 2015 at 1:3= 5 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Wed, Apr 22,= 2015 at 10:02:50AM -0700, Robert Relyea wrote:
> On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
> >
> >There are other places in TLS that fundame= ntally need to (indirectly) derive
> >public data out of secret key material.
> That's not a a problem. The problem is using the same mechanism to= derive
> the public data that we use to derive the keys.
> It's even OK to use the same secret key for both (from an HSM POV)= .
>
> What Michael is saying is that there are existing functions for both K= DF
> (secret material -> key) and Mac (secret material-> unique publi= c data).
> He's requesting that TLS not have it's own versions of these f= unctions.

So would using two different PRF functions, one for parts that don&#= 39;t
downgrade and another for parts that do downgrade (e.g. IV derivation,
unique / finished calculations, exporter calculations, etc..) solve the
issue?

(Of course, the two functions should be closely related, so not to
annoy software implementations too much)...


-Ilari

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

--f46d043892175b5147051453a1ab-- From nobody Wed Apr 22 14:31: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 C0EF71B2A1A for ; Wed, 22 Apr 2015 14:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HkTBts1YCW87 for ; Wed, 22 Apr 2015 14:30:56 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5131B2A1B for ; Wed, 22 Apr 2015 14:30:55 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so284943303pdb.1 for ; Wed, 22 Apr 2015 14:30:54 -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 :subject:references:in-reply-to:content-type; bh=IAah5Q3F34eI9SVJZAYfUn2YMv98B+HV5PBmRlb8K2Y=; b=hzpNiwtn7oFgxE3J1L8B4vig6FqDvQVtHwPYf1FI4Ua0hpAd4lbIqPQvI35egJ5Pmi WPBm2XUv11DXI22nfzS+LVHEfnA+QaNI/VaqnNpHp091OWfDkIQ9Sd91TItRnVmmcXBT mNjh42OKan0V5kiqN4VIqF8bjSsr+aMYsDTHICzRqu8QsOgjwkEFPc1ZvPmxan7vcWc4 NghQapfRjlm/OSyO4eZyhm4edPr2Hs436ir1V6+KGGmA37IH1Kvt2ou8avl8ziQ9H3/y uLagibaNHyMBWR7ofX+bY3wuxn/qQlsTSpcpfRffuKWKByxVgWmZKe7Pph8QAAwamXzd 7D9Q== X-Gm-Message-State: ALoCoQks8RpJioS0U8j/1qlr1dhgZUM5CVU8b0JTUDIciS6bQLicItWDI46mf3e6zrORL0bkFOFC X-Received: by 10.68.69.16 with SMTP id a16mr46674592pbu.49.1429738254847; Wed, 22 Apr 2015 14:30:54 -0700 (PDT) Received: from [10.90.197.114] (edge-gw-rwc.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id rd7sm5991851pdb.64.2015.04.22.14.30.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 14:30:54 -0700 (PDT) Message-ID: <55381302.5030307@nthpermutation.com> Date: Wed, 22 Apr 2015 17:30:42 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070108020204020306080602" Archived-At: Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2015 21:30:58 -0000 This is a multi-part message in MIME format. --------------070108020204020306080602 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 4/22/2015 1:37 PM, Eric Rescorla wrote: > If we're using HKDF-Extract, can we just key off different labels? > > -Ekr > Basically, no. The Extract function is really not designed to be used standalone but as a way of concentrating entropy for input to the expansion phase. Its dangerous to talk of these functions as separately callable. They are steps not separate functions. The extract step's only non-key input - salt - is not the same as the "info" input used in the expand phase - 'salt' is supposed to be missing or random, not a fixed string like a label. "info" is where the various labels go and that's only present in the expand phase. What you want to do is specify as part of the mixins (e.g. 'info' - e.g. the collection of label and context) a set of fields that describe 1) how the key stream is going to be broken up (eg. lengths of the sub keys), 2) what algorithms will use each of the parts of the key stream, and 3) whether or not those parts are allowed to be exported/extracted. A software module will basically ignore these because - really - its all the same memory although it should really make sure the key lengths and types matc. An HSM will look at these and be able to make policy decisions for protection of the segments (e.g. preventing export of material that was created to be non-exportable). Having all of these in the mixins means that the key stream expansion completely changes if ANY of these mixins change which in turn means that the various ways you can use to extract truly secret key material (as differentiated from exportable material) from an HSM using the currently defined mechanism can be eliminated. (I can explain my reasoning if necessary). Mike > > On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara > > wrote: > > On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote: > > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote: > > > > > >There are other places in TLS that fundamentally need to (indirectly) derive > > >public data out of secret key material. > > That's not a a problem. The problem is using the same mechanism > to derive > > the public data that we use to derive the keys. > > It's even OK to use the same secret key for both (from an HSM POV). > > > > What Michael is saying is that there are existing functions for > both KDF > > (secret material -> key) and Mac (secret material-> unique > public data). > > He's requesting that TLS not have it's own versions of these > functions. > > So would using two different PRF functions, one for parts that don't > downgrade and another for parts that do downgrade (e.g. IV derivation, > unique / finished calculations, exporter calculations, etc..) > solve the > issue? > > (Of course, the two functions should be closely related, so not to > annoy software implementations too much)... > > > -Ilari > > _______________________________________________ > 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 --------------070108020204020306080602 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 4/22/2015 1:37 PM, Eric Rescorla wrote:
If we're using HKDF-Extract, can we just key off different labels?

-Ekr


Basically, no.

The Extract function is really not designed to be used standalone but as a way of concentrating entropy for input to the expansion phase. Its dangerous to talk of these functions as separately callable. They are steps not separate functions.

The extract step's only non-key input - salt - is not the same as the "info" input used in the expand phase - 'salt' is supposed to be missing or random, not a fixed string like a label.

"info" is where the various labels go and that's only present in the expand phase.


What you want to do is specify as part of the mixins (e.g. 'info' - e.g. the collection of label and context) a set of fields that describe 1) how the key stream is going to be broken up (eg. lengths of the sub keys), 2) what algorithms will use each of the parts of the key stream, and 3) whether or not those parts are allowed to be exported/extracted.

A software module will basically ignore these because - really - its all the same memory although it should really make sure the key lengths and types matc. An HSM will look at these and be able to make policy decisions for protection of the segments (e.g. preventing export of material that was created to be non-exportable).

Having all of these in the mixins means that the key stream expansion completely changes if ANY of these mixins change which in turn means that the various ways you can use to extract truly secret key material (as differentiated from exportable material) from an HSM using the currently defined mechanism can be eliminated. (I can explain my reasoning if necessary).


Mike



On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote:
> On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
> >
> >There are other places in TLS that fundamentally need to (indirectly) derive
> >public data out of secret key material.
> That's not a a problem. The problem is using the same mechanism to derive
> the public data that we use to derive the keys.
> It's even OK to use the same secret key for both (from an HSM POV).
>
> What Michael is saying is that there are existing functions for both KDF
> (secret material -> key) and Mac (secret material-> unique public data).
> He's requesting that TLS not have it's own versions of these functions.

So would using two different PRF functions, one for parts that don't
downgrade and another for parts that do downgrade (e.g. IV derivation,
unique / finished calculations, exporter calculations, etc..) solve the
issue?

(Of course, the two functions should be closely related, so not to
annoy software implementations too much)...


-Ilari

_______________________________________________
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

--------------070108020204020306080602-- From nobody Wed Apr 22 14:49: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 C81821B2A8A for ; Wed, 22 Apr 2015 14:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 jNpzF0Ic77jw for ; Wed, 22 Apr 2015 14:49:22 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (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 3D6AD1B2A82 for ; Wed, 22 Apr 2015 14:49:20 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so284096023pac.1 for ; Wed, 22 Apr 2015 14:49:19 -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=xAVPej94INsZ7WLAeL4BosNH6p59pM+S2cPfsh5yza4=; b=O/nJ2Gfx3HKmRpRBCJqmyEigWjIQg6l3ylmTo0kJvPd9lrlqgU95UiAkcX4FrHUU+Q WJu0AL9h1t1gIfWRY2r7q/JvAoUEtK1irhw2vdxho6SLL+kNdgpMgJXRHGWB+P7haSTe Lcit1V6T+wHcjRE0IKAK0N+7doIyYUWXPHiXeJ4hk4aXU6kaLAJcJ+LkYGJLgS5k6r7V N/ohKL6MOHkvP7A2QeRmRINbZf2JeH9WsKTZpNhVhm571f07SbjPDu53rT4KSj+3tPP2 eEaLzEsiIGc9KlbdjlvhdaVcmYclOPNHEQUF1lXKAmvn3nnXui0UismTVQ68K8bEbAwB XMcw== X-Gm-Message-State: ALoCoQn90TPjCuvtyDgoG2e4uJlkaT3NY71q1EtQRt5iqgNf3Cp+x8W+WpkJnrMV8M+DHAvQVdAN X-Received: by 10.70.98.171 with SMTP id ej11mr19539835pdb.72.1429739359856; Wed, 22 Apr 2015 14:49:19 -0700 (PDT) Received: from [10.90.197.114] (soi.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id xm7sm6083453pac.28.2015.04.22.14.49.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 14:49:19 -0700 (PDT) Message-ID: <55381768.8010402@nthpermutation.com> Date: Wed, 22 Apr 2015 17:49:28 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sean Turner References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> In-Reply-To: <551E290D.7020207@nthpermutation.com> Content-Type: multipart/alternative; boundary="------------090207060204070302060304" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2015 21:49:25 -0000 This is a multi-part message in MIME format. --------------090207060204070302060304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I'm top posting my own post.... Sean et al: After spending a bit more time looking at things from the view point of HSMs and cryptographic isolation, I'm now of the opinion that HKDF shouldn't be specified. The specific issue is the difference between HDKF step 2 and the SP800-108 expansion functions. Cryptographically, these specifications are close to identical except for the inclusion of a mandatory length term in the mixin values. Without this term, a key stream produced from the same mixins (e.g. same label, randoms etc) for the same master key will be identical regardless of the length of the output key(s). E.g. if one call to the KDF has a target key of AES128 and another call to the KDF using the same master key and mixins has a target key of a single octet HMAC key, the first octet of the AES key will be identical to that single octet HMAC key. Using this construct with increasingly longer HMAC keys (thanks to HMAC's impedance matching function) will eventually reveal each and every byte of the AES key. In an HSM, there is no way to differentiate these two different KDF calls for legitimacy. If the KDF mixes in the length of the to be output key material, then any change in the length of the requested key changes the entire key stream. I see three different approaches to fix this - 1) specify the SP800-56C with SP800-108 HMAC, 2) add the length term to the HKDF RFC and republish it, 3) ensure one or more length terms are included in the "info" for ALL KDF calls for TLS and document why. Mike On 4/3/2015 1:45 AM, Michael StJohns wrote: > On 4/2/2015 10:04 PM, Sean Turner wrote: >> On Apr 02, 2015, at 20:22, Michael StJohns wrote: >> >>> I will note that the author claimed in his paper that the IETF was standardizing this, but I can't find any data suggesting this actually went through the IETF standardization process (vs independent informational RFC submission process). It did garner some review on the CFRG mailing list, but not to what I normally think of as comprehensive and resolving all comments. >> The pre-5869 draft was AD sponsored by Tim Polk. The IETF LC can be found here: >> >> https://mailarchive.ietf.org/arch/msg/ietf-announce/8rYOi-6zUEljAX4XprWbjP7on0s > I saw that, but that's for Informational, not Standard. Different bar. > >> We can refer to it normatively if we want to, we just have to make sure the DOWNREF is explicitly cited, as per RFC 3647. > Yup. But considering that the difference between HKDF vs the > combination of SP800-56C plus SP800-108 section 5.2 is the placement > of the iteration value in what gets HMAC'd and the fact that _the HDKF > doesn't mix in the total length of the data to be output_, I'd rather > use the latter cites if we could even if they require an extra > paragraph to describe the selected sizes of L and i and what goes in > to Label and Context (basically "info" by another name). > > AFAICT, the addition of the L of the output to the data HMAC'd is > there to force a change to the key stream if the length of the output > key stream changes and that's probably a good additional security > property. Other than that, I would say that these are pretty much > identical in cryptographic composition. > > Lastly, I still have hopes one day to remove the requirement for the > dependency on a HASH function in the handshake and this construct > allows for a CMAC based MAC. > > > Again - I can live with HKDF, but I'm unclear of why citing the RFC is > a better choice given the above comparison. > > Thanks - Mike > > ps - I will write the paragraph for SP800-56C/108 inclusion if you > want if we go that way. > > >> spt > --------------090207060204070302060304 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I'm top posting my own post....


Sean et al:

After spending a bit more time looking at things from the view point of HSMs and cryptographic isolation, I'm now of the opinion that HKDF shouldn't be specified.

The specific issue is the difference between HDKF step 2 and the SP800-108 expansion functions. Cryptographically, these specifications are close to identical except for the inclusion of a mandatory length term in the mixin values. Without this term, a key stream produced from the same mixins (e.g. same label, randoms etc) for the same master key will be identical regardless of the length of the output key(s).

E.g. if one call to the KDF has a target key of AES128 and another call to the KDF using the same master key and mixins has a target key of a single octet HMAC key, the first octet of the AES key will be identical to that single octet HMAC key. Using this construct with increasingly longer HMAC keys (thanks to HMAC's impedance matching function) will eventually reveal each and every byte of the AES key.

In an HSM, there is no way to differentiate these two different KDF calls for legitimacy.

If the KDF mixes in the length of the to be output key material, then any change in the length of the requested key changes the entire key stream.

I see three different approaches to fix this - 1) specify the SP800-56C with SP800-108 HMAC, 2) add the length term to the HKDF RFC and republish it, 3) ensure one or more length terms are included in the "info" for ALL KDF calls for TLS and document why.


Mike



On 4/3/2015 1:45 AM, Michael StJohns wrote:
On 4/2/2015 10:04 PM, Sean Turner wrote:
On Apr 02, 2015, at 20:22, Michael StJohns <msj@nthpermutation.com> wrote:


 I will note that the author claimed in his paper that the IETF was standardizing this, but I can't find any data suggesting this actually went through the IETF standardization process (vs independent informational RFC submission process).  It did garner some review on the CFRG mailing list, but not to what I normally think of as comprehensive and resolving all comments.

The pre-5869 draft was AD sponsored by Tim Polk.  The IETF LC can be found here:

https://mailarchive.ietf.org/arch/msg/ietf-announce/8rYOi-6zUEljAX4XprWbjP7on0s
I saw that, but that's for Informational, not Standard. Different bar.

We can refer to it normatively if we want to, we just have to make sure the DOWNREF is explicitly cited, as per RFC 3647.
Yup. But considering that the difference between HKDF vs the combination of SP800-56C plus SP800-108 section 5.2 is the placement of the iteration value in what gets HMAC'd and the fact that the HDKF doesn't mix in the total length of the data to be output, I'd rather use the latter cites if we could even if they require an extra paragraph to describe the selected sizes of L and i and what goes in to Label and Context (basically "info" by another name).

AFAICT, the addition of the L of the output to the data HMAC'd is there to force a change to the key stream if the length of the output key stream changes and that's probably a good additional security property. Other than that, I would say that these are pretty much identical in cryptographic composition.

Lastly, I still have hopes one day to remove the requirement for the dependency on a HASH function in the handshake and this construct allows for a CMAC based MAC.


Again - I can live with HKDF, but I'm unclear of why citing the RFC is a better choice given the above comparison.

Thanks - Mike

ps - I will write the paragraph for SP800-56C/108 inclusion if you want if we go that way. 


spt


--------------090207060204070302060304-- From nobody Wed Apr 22 15:00: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 3D5E41B2AD3 for ; Wed, 22 Apr 2015 15:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlz-Kqo75ys3 for ; Wed, 22 Apr 2015 15:00:16 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::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 A443F1B2AD4 for ; Wed, 22 Apr 2015 15:00:15 -0700 (PDT) Received: by wgyo15 with SMTP id o15so261288610wgy.2 for ; Wed, 22 Apr 2015 15:00:14 -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=TBr+RSuRvN3wdXi+13Y4vD+KtNmywsYjM0FnbCWtYd4=; b=DyxL9ELwr0q+u/BANr42gOex0HZ/FKLSf5DwABNgnyVdxbE/k9TY8xE5XUYFzphSqk jBxkl8G/UM3ZMYtEH08WjEe656+5S0D3KXrCl8ENTW8n73JtPsQnCKl2DMUKbWozQLVT 7En4yvfD1h/TAVqVCCIzu68LvVDKMu1oqrnJKEfBesGbxvJ52V0JLgxi9mHOhTkuHspo +5YwniDTSSfnyF8QfmLA2InVzzT7TkLK6wlBmaXEi44l2KSUUYqPVpXXju8ciI4xc/2Y 73lfpJCc/teVw1vlPbbP9e9kO+ny/HwwtaJZNzke/PQfENW3R+Sfr++G12FtDVYf+QlP QOdA== MIME-Version: 1.0 X-Received: by 10.180.105.233 with SMTP id gp9mr9899231wib.83.1429740014368; Wed, 22 Apr 2015 15:00:14 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Wed, 22 Apr 2015 15:00:13 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Wed, 22 Apr 2015 15:00:13 -0700 (PDT) In-Reply-To: <55381768.8010402@nthpermutation.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> Date: Wed, 22 Apr 2015 15:00:13 -0700 Message-ID: From: Watson Ladd To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d0442883ead7d780514574973 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2015 22:00:18 -0000 --f46d0442883ead7d780514574973 Content-Type: text/plain; charset=UTF-8 On Apr 22, 2015 2:49 PM, "Michael StJohns" wrote: > > I'm top posting my own post.... > > > Sean et al: > > After spending a bit more time looking at things from the view point of HSMs and cryptographic isolation, I'm now of the opinion that HKDF shouldn't be specified. > > The specific issue is the difference between HDKF step 2 and the SP800-108 expansion functions. Cryptographically, these specifications are close to identical except for the inclusion of a mandatory length term in the mixin values. Without this term, a key stream produced from the same mixins (e.g. same label, randoms etc) for the same master key will be identical regardless of the length of the output key(s). > > E.g. if one call to the KDF has a target key of AES128 and another call to the KDF using the same master key and mixins has a target key of a single octet HMAC key, the first octet of the AES key will be identical to that single octet HMAC key. Using this construct with increasingly longer HMAC keys (thanks to HMAC's impedance matching function) will eventually reveal each and every byte of the AES key. What if the first call for the HMAC key is 128 bits, and we use a broken variant? Your example demonstrates why the sane data shouldn't be used for two different purposes. In fact, it's not clear to me that we can make an HSM friendly design without telling the HSM which derived values are exportable and which not. If we ensured that no value derived by HKDF ever is not used as an encryption key, this would solve the problem at the cost of some pain with channel binding. But this would be a very large change. > > In an HSM, there is no way to differentiate these two different KDF calls for legitimacy. > > If the KDF mixes in the length of the to be output key material, then any change in the length of the requested key changes the entire key stream. > > I see three different approaches to fix this - 1) specify the SP800-56C with SP800-108 HMAC, 2) add the length term to the HKDF RFC and republish it, 3) ensure one or more length terms are included in the "info" for ALL KDF calls for TLS and document why. > > > Mike > > > > > On 4/3/2015 1:45 AM, Michael StJohns wrote: >> >> On 4/2/2015 10:04 PM, Sean Turner wrote: >>> >>> On Apr 02, 2015, at 20:22, Michael StJohns wrote: >>> >>>> I will note that the author claimed in his paper that the IETF was standardizing this, but I can't find any data suggesting this actually went through the IETF standardization process (vs independent informational RFC submission process). It did garner some review on the CFRG mailing list, but not to what I normally think of as comprehensive and resolving all comments. >>> >>> The pre-5869 draft was AD sponsored by Tim Polk. The IETF LC can be found here: >>> >>> https://mailarchive.ietf.org/arch/msg/ietf-announce/8rYOi-6zUEljAX4XprWbjP7on0s >> >> I saw that, but that's for Informational, not Standard. Different bar. >> >>> >>> We can refer to it normatively if we want to, we just have to make sure the DOWNREF is explicitly cited, as per RFC 3647. >> >> Yup. But considering that the difference between HKDF vs the combination of SP800-56C plus SP800-108 section 5.2 is the placement of the iteration value in what gets HMAC'd and the fact that the HDKF doesn't mix in the total length of the data to be output, I'd rather use the latter cites if we could even if they require an extra paragraph to describe the selected sizes of L and i and what goes in to Label and Context (basically "info" by another name). >> >> AFAICT, the addition of the L of the output to the data HMAC'd is there to force a change to the key stream if the length of the output key stream changes and that's probably a good additional security property. Other than that, I would say that these are pretty much identical in cryptographic composition. >> >> Lastly, I still have hopes one day to remove the requirement for the dependency on a HASH function in the handshake and this construct allows for a CMAC based MAC. >> >> >> Again - I can live with HKDF, but I'm unclear of why citing the RFC is a better choice given the above comparison. >> >> Thanks - Mike >> >> ps - I will write the paragraph for SP800-56C/108 inclusion if you want if we go that way. >> >> >>> >>> spt >> >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d0442883ead7d780514574973 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 22, 2015 2:49 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> I'm top posting my own post....
>
>
> Sean et al:
>
> After spending a bit more time looking at things from the view point o= f HSMs and cryptographic isolation, I'm now of the opinion that HKDF sh= ouldn't be specified.
>
> The specific issue is the difference between HDKF step 2 and the SP800= -108 expansion functions.=C2=A0=C2=A0 Cryptographically, these specificatio= ns are close to identical except for the inclusion of a mandatory length te= rm in the mixin values.=C2=A0=C2=A0 Without this term, a key stream produce= d from the same mixins (e.g. same label, randoms etc) for the same master k= ey will be identical regardless of the length of the output key(s).
>
> E.g. if one call to the KDF has a target key of AES128 and another cal= l to the KDF using the same master key and mixins has a target key of a sin= gle octet HMAC key, the first octet of the AES key will be identical to tha= t single octet HMAC key.=C2=A0=C2=A0=C2=A0 Using this construct with increa= singly longer HMAC keys (thanks to HMAC's impedance matching function) = will eventually reveal each and every byte of the AES key.

What if the first call for the HMAC key is 128 bits, and we = use a broken variant?

Your example demonstrates why the sane data shouldn't be= used for two different purposes. In fact, it's not clear to me that we= can make an HSM friendly design without telling the HSM which derived valu= es are exportable and which not.

If we ensured that no value derived by HKDF ever is not used= as an encryption key, this would solve the problem at the cost of some pai= n with channel binding. But this would be a very large change.

>
> In an HSM, there is no way to differentiate these two different KDF ca= lls for legitimacy.
>
> If the KDF mixes in the length of the to be output key material, then = any change in the length of the requested key changes the entire key stream= .
>
> I see three different approaches to fix this - 1) specify the SP800-56= C with SP800-108 HMAC, 2) add the length term to the HKDF RFC and republish= it, 3) ensure one or more length terms are included in the "info"= ; for ALL KDF calls for TLS and document why.=C2=A0
>
>
> Mike
>
>
>
>
> On 4/3/2015 1:45 AM, Michael StJohns wrote:
>>
>> On 4/2/2015 10:04 PM, Sean Turner wrote:
>>>
>>> On Apr 02, 2015, at 20:22, Michael StJohns <msj@nthpermutation.com> wrote:
>>>
>>>>=C2=A0 I will note that the author claimed in his paper tha= t the IETF was standardizing this, but I can't find any data suggesting= this actually went through the IETF standardization process (vs independen= t informational RFC submission process).=C2=A0 It did garner some review on= the CFRG mailing list, but not to what I normally think of as comprehensiv= e and resolving all comments.
>>>
>>> The pre-5869 draft was AD sponsored by Tim Polk.=C2=A0 The IET= F LC can be found here:
>>>
>>> https://mailarchive.ietf.org/arch/msg/ietf-an= nounce/8rYOi-6zUEljAX4XprWbjP7on0s
>>
>> I saw that, but that's for Informational, not Standard.=C2=A0 = Different bar.
>>
>>>
>>> We can refer to it normatively if we want to, we just have to = make sure the DOWNREF is explicitly cited, as per RFC 3647.
>>
>> Yup.=C2=A0 But considering that the difference between HKDF vs the= combination of SP800-56C plus SP800-108 section 5.2 is the placement of th= e iteration value in what gets HMAC'd and the fact that the HDKF doesn&= #39;t mix in the total length of the data to be output,=C2=A0 I'd rathe= r use the latter cites if we could even if they require an extra paragraph = to describe the selected sizes of L and i and what goes in to Label and Con= text (basically "info" by another name).
>>
>> AFAICT, the addition of the L of the output to the data HMAC'd= is there to force a change to the key stream if the length of the output k= ey stream changes and that's probably a good additional security proper= ty.=C2=A0 Other than that, I would say that these are pretty much identical= in cryptographic composition.
>>
>> Lastly, I still have hopes one day to remove the requirement for t= he dependency on a HASH function in the handshake and this construct allows= for a CMAC based MAC.
>>
>>
>> Again - I can live with HKDF, but I'm unclear of why citing th= e RFC is a better choice given the above comparison.
>>
>> Thanks - Mike
>>
>> ps - I will write the paragraph for SP800-56C/108 inclusion if you= want if we go that way.=C2=A0
>>
>>
>>>
>>> spt
>>
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--f46d0442883ead7d780514574973-- From nobody Wed Apr 22 16:03: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 154FE1B2CD1 for ; Wed, 22 Apr 2015 16:03:50 -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 bz5mFWrt7sND for ; Wed, 22 Apr 2015 16:03:47 -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 17E141B2C8C for ; Wed, 22 Apr 2015 16:03:47 -0700 (PDT) Received: by wiun10 with SMTP id n10so73915466wiu.1 for ; Wed, 22 Apr 2015 16:03:45 -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=nhuEiLV/I8BfdUbGXN5GYcUE5WRVqC0aKG1Ig8cYIjI=; b=gy053F/CvwiMyOEj5UosA2AL8xOgVpAikd90iolNQmPw+BShEZxWgl+8STaSbbwytC 8qP41pMVnAYHIHEJgI74qtJ1XsMFPVE6h2JgFDZeoCwPE4LNVnzz3BYMyE1UdhgTgkPF 1JQ7072BlvicyyaBCuoqqOW2HsfO6C0EvP0pMYQDS0LEAHiHiMZ4Y2Ls0dirvXN9kZ97 Bj/WtxmmdoVEim9ECC3Ggw2MPOcfVGyHp6zfZ/AJWlx3kvKF5ioz4N9kV2AOXpaE0h+L NCsexHih8cOPIsKC3XtwYc0J0fq/tQEk/p7hFnKCp9oHFhJydxlv/LOd+iHRNOnmNj5G rnMg== X-Gm-Message-State: ALoCoQmnimRKteXMw+5gmifJs1pOUlKH8hBXjggOofjatL3NBjWjGyfZjUYp+PCJdPJQkw4TKVDM X-Received: by 10.180.84.67 with SMTP id w3mr660022wiy.68.1429743825833; Wed, 22 Apr 2015 16:03:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Wed, 22 Apr 2015 16:03:05 -0700 (PDT) In-Reply-To: <55381302.5030307@nthpermutation.com> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> From: Eric Rescorla Date: Wed, 22 Apr 2015 19:03:05 -0400 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d04440276dbe3810514582cbf Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2015 23:03:50 -0000 --f46d04440276dbe3810514582cbf Content-Type: text/plain; charset=UTF-8 On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns wrote: > On 4/22/2015 1:37 PM, Eric Rescorla wrote: > > If we're using HKDF-Extract, can we just key off different labels? > > -Ekr > > Sorry, read that as "HKD-Expand". -Ekr > Basically, no. > > The Extract function is really not designed to be used standalone but as a > way of concentrating entropy for input to the expansion phase. Its > dangerous to talk of these functions as separately callable. They are > steps not separate functions. > > The extract step's only non-key input - salt - is not the same as the > "info" input used in the expand phase - 'salt' is supposed to be missing or > random, not a fixed string like a label. > > "info" is where the various labels go and that's only present in the > expand phase. > > > What you want to do is specify as part of the mixins (e.g. 'info' - e.g. > the collection of label and context) a set of fields that describe 1) how > the key stream is going to be broken up (eg. lengths of the sub keys), 2) > what algorithms will use each of the parts of the key stream, and 3) > whether or not those parts are allowed to be exported/extracted. > > A software module will basically ignore these because - really - its all > the same memory although it should really make sure the key lengths and > types matc. An HSM will look at these and be able to make policy decisions > for protection of the segments (e.g. preventing export of material that was > created to be non-exportable). > > Having all of these in the mixins means that the key stream expansion > completely changes if ANY of these mixins change which in turn means that > the various ways you can use to extract truly secret key material (as > differentiated from exportable material) from an HSM using the currently > defined mechanism can be eliminated. (I can explain my reasoning if > necessary). > > > Mike > > > > > On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > >> On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote: >> > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote: >> > > >> > >There are other places in TLS that fundamentally need to (indirectly) >> derive >> > >public data out of secret key material. >> > That's not a a problem. The problem is using the same mechanism to >> derive >> > the public data that we use to derive the keys. >> > It's even OK to use the same secret key for both (from an HSM POV). >> > >> > What Michael is saying is that there are existing functions for both KDF >> > (secret material -> key) and Mac (secret material-> unique public data). >> > He's requesting that TLS not have it's own versions of these functions. >> >> So would using two different PRF functions, one for parts that don't >> downgrade and another for parts that do downgrade (e.g. IV derivation, >> unique / finished calculations, exporter calculations, etc..) solve the >> issue? >> >> (Of course, the two functions should be closely related, so not to >> annoy software implementations too much)... >> >> >> -Ilari >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f46d04440276dbe3810514582cbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns <= msj@nthpermutat= ion.com> wrote:
=20 =20 =20
On 4/22/2015 1:37 PM, Eric Rescorla wrote:
If we're using HKDF-Extract, can we just key off different labels?

-Ekr
Sorry, read that as "HKD-Expand".

-Ekr


Basically, no.

The Extract function is really not designed to be used standalone but as a way of concentrating entropy for input to the expansion phase.=C2=A0 Its dangerous to talk of these functions as separately callable.=C2=A0 They are steps not separate functions.

=C2=A0The extract step's only non-key input - salt - is not the sam= e as the "info" input used in the expand phase - 'salt' is= supposed to be missing or random,=C2=A0 not a fixed string like a label.=C2=A0

"info" is where the various labels go and that's only pre= sent in the expand phase.


What you want to do is specify as part of the mixins (e.g. 'info= 9; - e.g. the collection of label and context)=C2=A0 a set of fields that describe 1) how the key stream is going to be broken up (eg. lengths of the sub keys), 2) what algorithms will use each of the parts of the key stream, and 3) whether or not those parts are allowed to be exported/extracted.

A software module will basically ignore these because - really - its all the same memory although it should really make sure the key lengths and types matc.=C2=A0 An HSM will look at these and be able to make policy decisions for protection of the segments (e.g. preventing export of material that was created to be non-exportable).

Having all of these in the mixins means that the key stream expansion completely changes if ANY of these mixins change which in turn means=C2=A0 that the various ways you can use to extract truly secret key material (as differentiated from exportable material) from an HSM using the currently defined mechanism can be eliminated.=C2=A0 (I can explain my reasoning if necessary).


Mike




On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Wed, Apr 22, 2015 at 10:0= 2:50AM -0700, Robert Relyea wrote:
> On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
> >
> >There are other places in TLS that fundamentally need to (indirectly) derive
> >public data out of secret key material.
> That's not a a problem. The problem is using the sam= e mechanism to derive
> the public data that we use to derive the keys.
> It's even OK to use the same secret key for both (from an HSM POV).
>
> What Michael is saying is that there are existing functions for both KDF
> (secret material -> key) and Mac (secret material-> unique public data).
> He's requesting that TLS not have it's own versi= ons of these functions.

So would using two different PRF functions, one for parts that don't
downgrade and another for parts that do downgrade (e.g. IV derivation,
unique / finished calculations, exporter calculations, etc..) solve the
issue?

(Of course, the two functions should be closely related, so not to
annoy software implementations too much)...


-Ilari

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



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


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


--f46d04440276dbe3810514582cbf-- From nobody Thu Apr 23 01:42: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 88B851A8951 for ; Thu, 23 Apr 2015 01:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0eFqZpZNFiDZ for ; Thu, 23 Apr 2015 01:42:09 -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 9AB131A894F for ; Thu, 23 Apr 2015 01:42:04 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 17CE19005C; Thu, 23 Apr 2015 11:42:01 +0300 (EEST) Date: Thu, 23 Apr 2015 11:42:01 +0300 From: Ilari Liusvaara To: Michael StJohns Message-ID: <20150423084201.GA21246@LK-Perkele-VII> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55381302.5030307@nthpermutation.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2015 08:42:11 -0000 On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote: > On 4/22/2015 1:37 PM, Eric Rescorla wrote: > >If we're using HKDF-Extract, can we just key off different labels? > > > >-Ekr > > > > Basically, no. > > What you want to do is specify as part of the mixins (e.g. 'info' - e.g. the > collection of label and context) a set of fields that describe 1) how the > key stream is going to be broken up (eg. lengths of the sub keys), 2) what > algorithms will use each of the parts of the key stream, and 3) whether or > not those parts are allowed to be exported/extracted. In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding field is seed, right? So inside that (or whatever the equivalent), serialize: - Label - Lengths, types and exportable flags of subkeys - Context ? Properly serializing that would avoid the well-known TLS 1.2 screwup in PRF defintion (which got copied to "dh based key exchange" draft). One possible structure in TLS notation: struct prf_output { /* 0x0000 => For key derivation 0x0001 => For AEAD keying 0x8002 => For AEAD IV 0x8003 => For octet string (exporters, unique) */ uint16 type; uint16 length; /* In bytes. */ }; struct prf_seed { opaque label<0..65535> prf_output outputs<4..65532> opaque context<0..65535> }; Fixed expansion is 6 bytes and each subkey is 4 bytes. The key expansion for AES-256-GCM a'la TLS 1.2 would look like: 00 0d 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e 00 10 00 01 00 20 00 01 00 20 80 02 00 04 80 02 00 04 00 40 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX Where XX is the random data. One can see this extracts total of 72 bytes. TLS 1.2 extended master secret with SHA-256 prf-hash looks like: 00 16 65 78 74 65 6e 64 65 64 20 6d 61 73 74 65 72 20 73 65 63 72 65 74 00 04 00 00 00 30 00 20 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX Where XX is the session hash up to that point. Output size can be seen to be 48 bytes. Also, it occurs to me that if PRF has salt input (like HKDF), one should stick something non-secret but variable there (e.g. client random, or suitable handshake hash, or something). Some outputs share a (key,salt) pair. Keys should be combined by serialization. -Ilari From nobody Thu Apr 23 02: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 8FBA11A905C for ; Thu, 23 Apr 2015 02:54:47 -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 iNuDCS_mygJb for ; Thu, 23 Apr 2015 02:54:45 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (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 A48B91A9083 for ; Thu, 23 Apr 2015 02:54:44 -0700 (PDT) Received: by wgin8 with SMTP id n8so12648044wgi.0 for ; Thu, 23 Apr 2015 02:54: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KB8JI9jy+ytu55QDfBHFwL2sx/q3v+5Uch7IVlYlmh4=; b=XKCiR7BIvSwNklbrZN4SH4c2Dwo4U1c3MrKeYjyxd1EI3jwA3L1DKChMR9qKLLBbYn oCKB2wOr8GX68dglIuuUJsraCYnjI2BKfUMuJ4DnzgUeSV4ctnziyF4wFjUumiu3SRW7 IGkYXr8aPgn6OKAMNmOTB/IDL1qAf2zP9WCFp0F0FhtCbUGK10XAvvFMvwf2tAC9C/4s 1cxprp9Vu8W7Sb2I4pz/nTJFUhbBBBxSQRMpOi3VGOiAB2sAr7ZyHtTsulqsW11l/4ld a2s3q9kqyhQGEmxJyE3HAX0KL/70mwUzM9BHW1lzlx0zIHu3Y5VcUkxkh31egTJb59i1 Y1vQ== X-Gm-Message-State: ALoCoQmMZFKtTmdepfOZmeUI0G2wbLV+rKkSPk38uNcc5FUg0xW6FpVn+RZeb8ODV78fQJ9vi4Sk X-Received: by 10.194.173.226 with SMTP id bn2mr3823960wjc.148.1429782883421; Thu, 23 Apr 2015 02:54:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Thu, 23 Apr 2015 02:54:02 -0700 (PDT) In-Reply-To: <20150423084201.GA21246@LK-Perkele-VII> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> From: Eric Rescorla Date: Thu, 23 Apr 2015 05:54:02 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e013c66a0df69df0514614450 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2015 09:54:47 -0000 --089e013c66a0df69df0514614450 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 23, 2015 at 4:42 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote: > > On 4/22/2015 1:37 PM, Eric Rescorla wrote: > > >If we're using HKDF-Extract, can we just key off different labels? > > > > > >-Ekr > > > > > > > Basically, no. > > > > What you want to do is specify as part of the mixins (e.g. 'info' - e.g. > the > > collection of label and context) a set of fields that describe 1) how > the > > key stream is going to be broken up (eg. lengths of the sub keys), 2) > what > > algorithms will use each of the parts of the key stream, and 3) whether > or > > not those parts are allowed to be exported/extracted. > > In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding field is > seed, > right? > > So inside that (or whatever the equivalent), serialize: > - Label > - Lengths, types and exportable flags of subkeys > - Context > > ? > > Properly serializing that would avoid the well-known TLS 1.2 screwup in > PRF defintion (which got copied to "dh based key exchange" draft). > Can elaborate on this? The DH-based key exchange draft uses HKDF and uses separate labels for each use of HKDF-Expand so that (for instance) exporters and key generation have different labels. > Also, it occurs to me that if PRF has salt input (like HKDF), one should > stick something non-secret but variable there (e.g. client random, or > suitable handshake hash, or something). Based on talking to Hugo, my understanding is that the best way to do this is by incorporating the handshake hash at the HKDF-Expand stage, as in: client_write_key = HKDF-Expand(Secret, "client write key" + session_hash, SecurityParameters.enc_key_length) Some outputs share a (key,salt) > pair. Keys should be combined by serialization. If you're referring to how we combine (say) the static DH and the ephemeral DH, what we had discussed was running K1 through HKDF-Extract to generate PRK1 and then using PRK1 as the salt for HKDF-Extract on PRK2. I.e., PRK1 = HKDF-Extract(0, K1) PRK2 = HKDF-Extract(0, K2) -Ekr --089e013c66a0df69df0514614450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 23, 2015 at 4:42 AM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote:
> On 4/22/2015 1:37 PM, Eric Rescorla wrote:
> >If we're using HKDF-Extract, can we just key off different lab= els?
> >
> >-Ekr
> >
>
> Basically, no.
>
> What you want to do is specify as part of the = mixins (e.g. 'info' - e.g. the
> collection of label and context)=C2=A0 a set of fields that describe 1= ) how the
> key stream is going to be broken up (eg. lengths of the sub keys), 2) = what
> algorithms will use each of the parts of the key stream, and 3) whethe= r or
> not those parts are allowed to be exported/extracted.

In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding field= is seed,
right?

So inside that (or whatever the equivalent), serialize:
- Label
- Lengths, types and exportable flags of subkeys
- Context

?

Properly serializing that would avoid the well-known TLS 1.2 screwup in
PRF defintion (which got copied to "dh based key exchange" draft)= .

Can elaborate on this?

=
The DH-based key exchange draft uses HKDF and uses separate
labels for each use of HKDF-Expand so that (for instance) exporters
and key generation have different labels.

=C2=A0
Also, it occurs to me that if PRF has salt in= put (like HKDF), one should
stick something non-secret but variable there (e.g. client random, or
suitable handshake hash, or something).

Ba= sed on talking to Hugo, my understanding is that the best way
to = do this is by incorporating the handshake hash at the HKDF-Expand
stage, as in:
=C2=A0
client_write_key =3D HKDF-Ex= pand(Secret, "client write key" + session_hash,
=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0SecurityParameters.enc_key_length)


Some outputs share = a (key,salt)
pair. Keys should be combined by serialization.

=
If you're referring to how we combine (say) the static DH and the = ephemeral
DH, what we had discussed was running K1 through HKDF-E= xtract to
generate PRK1 and then using PRK1 as the salt for HKDF-= Extract on
PRK2. I.e.,

=C2=A0 =C2=A0PRK1= =3D HKDF-Extract(0, K1)
=C2=A0 =C2=A0PRK2 =3D HKDF-Extract(0, K2= )

-Ekr
--089e013c66a0df69df0514614450-- From nobody Thu Apr 23 04:02: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 AE6491ACE17 for ; Thu, 23 Apr 2015 04:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=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 DvQLkmGYgmV7 for ; Thu, 23 Apr 2015 04:02:38 -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 59AF31B2D58 for ; Thu, 23 Apr 2015 04:02:17 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 22E3A699B0; Thu, 23 Apr 2015 14:02:15 +0300 (EEST) Date: Thu, 23 Apr 2015 14:02:14 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150423110214.GA21716@LK-Perkele-VII> References: <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@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] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2015 11:02:40 -0000 On Thu, Apr 23, 2015 at 05:54:02AM -0400, Eric Rescorla wrote: > On Thu, Apr 23, 2015 at 4:42 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote: > > > On 4/22/2015 1:37 PM, Eric Rescorla wrote: > > > >If we're using HKDF-Extract, can we just key off different labels? > > > > > > > >-Ekr > > > > > > > > > > Basically, no. > > > > > > What you want to do is specify as part of the mixins (e.g. 'info' - e.g. > > the > > > collection of label and context) a set of fields that describe 1) how > > the > > > key stream is going to be broken up (eg. lengths of the sub keys), 2) > > what > > > algorithms will use each of the parts of the key stream, and 3) whether > > or > > > not those parts are allowed to be exported/extracted. > > > > In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding field is > > seed, > > right? > > > > So inside that (or whatever the equivalent), serialize: > > - Label > > - Lengths, types and exportable flags of subkeys > > - Context > > > > ? > > > > Properly serializing that would avoid the well-known TLS 1.2 screwup in > > PRF defintion (which got copied to "dh based key exchange" draft). > > > > Can elaborate on this? > > The DH-based key exchange draft uses HKDF and uses separate > labels for each use of HKDF-Expand so that (for instance) exporters > and key generation have different labels. The label+seed thing. > > Also, it occurs to me that if PRF has salt input (like HKDF), one should > > stick something non-secret but variable there (e.g. client random, or > > suitable handshake hash, or something). > > > Based on talking to Hugo, my understanding is that the best way > to do this is by incorporating the handshake hash at the HKDF-Expand > stage, as in: > > client_write_key = HKDF-Expand(Secret, "client write key" + session_hash, > SecurityParameters.enc_key_length) Except that now nothing preturbs the secret extraction. Even HKDF RFC says things like "adds significantly to the strength" and "strengthening the analytical results that back[...]design". Also, in where I try to work the simplest key derivation that I think will work at all (supports 0RTT and (DHE-)PSK, but not fixedDH), I have: [...] master_secret = PRF(premaster_secret, "TLS1.3 master secret", hash_1) [...] client_hs_key = PRF(master_secret, "Client Key expansion") [...] client_app_key = PRF(master_secret, "Client Key expansion", hash_5) [...] hash_1 is hash of unencrypted parts, hash_5 is hash of the entiere handshake. One can stick hash_1 into client_hs_key derivation if one wants to (but it is still needed in master_secret). (the rekeying is to deal with kp attacks from key exchange or if somebody does dumb things with DTLS). Also, if it had client_application_master_secret, then derivation of that would have the hash_5. > Some outputs share a (key,salt) > > pair. Keys should be combined by serialization. Ah, I just remembered what the "Keys should be combined by serialization." meant: If one has multiple keys one needs to feed in, one should serialize those into a block and then feed that as a key input (not doing things like feeding secret keys as salts). The "Some outputs share a (key,salt) pair." means that there may be places where multiple keys are derived at the same point out of the same master key. E.g. on the thingy I was working on, there are 3 keys using (MS,hash3) and 2 using (MS,hash5). And if there is no client certificate, hash3=hash5. > If you're referring to how we combine (say) the static DH and the ephemeral > DH, what we had discussed was running K1 through HKDF-Extract to > generate PRK1 and then using PRK1 as the salt for HKDF-Extract on > PRK2. I.e., > > PRK1 = HKDF-Extract(0, K1) > PRK2 = HKDF-Extract(0, K2) AFAIK, nobody really uses FixedDH. And I think it was Adrei Popov who described how to do 0RTT in simpler way. Also, maybe the only interesting application of FixedDH is deniable key exchange. Except that supporting that would cause major issues elsewhere (and "DH based key exchange" is not deniable). -Ilari From nobody Thu Apr 23 10:03: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 99FC31ACD08 for ; Thu, 23 Apr 2015 10:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OWqaJ8dSlUgS for ; Thu, 23 Apr 2015 10:03:53 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (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 6B36B1ACD81 for ; Thu, 23 Apr 2015 10:03:41 -0700 (PDT) Received: by pdea3 with SMTP id a3so23425425pde.3 for ; Thu, 23 Apr 2015 10:03:41 -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=CSoyLZvBEJ1Oe70wWrRzdMyCXFNFzMZesklAmdxpbfU=; b=O43wIgGpYkRabahelxbj4fuHwHgp26YbMO2oPj54KtLtkhVJC1xzi9jRP7gJEtNiIx uYYGUJCrFhsD2UiefyHZVxjsBkomeP2kH6QFY3XjyjtMu+Zg9Blm3O4GYKiesunKqdUD aI1WWKxImXgxhJEx/+BfUDnBgen0Xkv5EBpKfqWzZYfL26ZvGITInBjc+mdPh2CPoRmQ KHY+oupLDwbEaDYCq/zwcpVmptk8h6iU4hvJgqNeD0u8h6WzTbnDurlOkJsFuVFlAYmK NEOTji1mTJuTVOJ+o6Ip8GW+u2jdviQWKUOGq2gQ/RiGtoqwkAm1rFTMl5P3z/2oCEcj KfkA== X-Gm-Message-State: ALoCoQk4aD3F3MZZyVaiN1UyIDfmnpK0IcYU49bLdc1oW/4/MFak/O4SB3lv186l/vKNIYog6FO5 X-Received: by 10.68.212.41 with SMTP id nh9mr6958370pbc.166.1429808621101; Thu, 23 Apr 2015 10:03:41 -0700 (PDT) Received: from [10.90.197.114] (soi.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id oh2sm8585063pbb.45.2015.04.23.10.03.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 10:03:40 -0700 (PDT) Message-ID: <553925F7.5010704@nthpermutation.com> Date: Thu, 23 Apr 2015 13:03:51 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Eric Rescorla References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000204050604020601070708" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2015 17:03:55 -0000 This is a multi-part message in MIME format. --------------000204050604020601070708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/22/2015 7:03 PM, Eric Rescorla wrote: > > > On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns > > wrote: > > On 4/22/2015 1:37 PM, Eric Rescorla wrote: >> If we're using HKDF-Extract, can we just key off different labels? >> >> -Ekr > > > Sorry, read that as "HKD-Expand". Actually, use HKDF as the term with no expand or extract suffix. Mike > > -Ekr > > > Basically, no. > > The Extract function is really not designed to be used standalone > but as a way of concentrating entropy for input to the expansion > phase. Its dangerous to talk of these functions as separately > callable. They are steps not separate functions. > > The extract step's only non-key input - salt - is not the same as > the "info" input used in the expand phase - 'salt' is supposed to > be missing or random, not a fixed string like a label. > > "info" is where the various labels go and that's only present in > the expand phase. > > > What you want to do is specify as part of the mixins (e.g. 'info' > - e.g. the collection of label and context) a set of fields that > describe 1) how the key stream is going to be broken up (eg. > lengths of the sub keys), 2) what algorithms will use each of the > parts of the key stream, and 3) whether or not those parts are > allowed to be exported/extracted. > > A software module will basically ignore these because - really - > its all the same memory although it should really make sure the > key lengths and types matc. An HSM will look at these and be able > to make policy decisions for protection of the segments (e.g. > preventing export of material that was created to be non-exportable). > > Having all of these in the mixins means that the key stream > expansion completely changes if ANY of these mixins change which > in turn means that the various ways you can use to extract truly > secret key material (as differentiated from exportable material) > from an HSM using the currently defined mechanism can be > eliminated. (I can explain my reasoning if necessary). > > > Mike > > > >> >> On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara >> > > wrote: >> >> On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote: >> > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote: >> > > >> > >There are other places in TLS that fundamentally need to (indirectly) derive >> > >public data out of secret key material. >> > That's not a a problem. The problem is using the same >> mechanism to derive >> > the public data that we use to derive the keys. >> > It's even OK to use the same secret key for both (from an >> HSM POV). >> > >> > What Michael is saying is that there are existing functions >> for both KDF >> > (secret material -> key) and Mac (secret material-> unique >> public data). >> > He's requesting that TLS not have it's own versions of >> these functions. >> >> So would using two different PRF functions, one for parts >> that don't >> downgrade and another for parts that do downgrade (e.g. IV >> derivation, >> unique / finished calculations, exporter calculations, etc..) >> solve the >> issue? >> >> (Of course, the two functions should be closely related, so >> not to >> annoy software implementations too much)... >> >> >> -Ilari >> >> _______________________________________________ >> 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 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --------------000204050604020601070708 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/22/2015 7:03 PM, Eric Rescorla wrote:


On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 4/22/2015 1:37 PM, Eric Rescorla wrote:
If we're using HKDF-Extract, can we just key off different labels?

-Ekr

Sorry, read that as "HKD-Expand".
Actually, use HKDF as the term with no expand or extract suffix.

Mike




-Ekr


 Basically, no.

The Extract function is really not designed to be used standalone but as a way of concentrating entropy for input to the expansion phase.  Its dangerous to talk of these functions as separately callable.  They are steps not separate functions.

 The extract step's only non-key input - salt - is not the same as the "info" input used in the expand phase - 'salt' is supposed to be missing or random,  not a fixed string like a label. 

"info" is where the various labels go and that's only present in the expand phase.


What you want to do is specify as part of the mixins (e.g. 'info' - e.g. the collection of label and context)  a set of fields that describe 1) how the key stream is going to be broken up (eg. lengths of the sub keys), 2) what algorithms will use each of the parts of the key stream, and 3) whether or not those parts are allowed to be exported/extracted.

A software module will basically ignore these because - really - its all the same memory although it should really make sure the key lengths and types matc.  An HSM will look at these and be able to make policy decisions for protection of the segments (e.g. preventing export of material that was created to be non-exportable).

Having all of these in the mixins means that the key stream expansion completely changes if ANY of these mixins change which in turn means  that the various ways you can use to extract truly secret key material (as differentiated from exportable material) from an HSM using the currently defined mechanism can be eliminated.  (I can explain my reasoning if necessary).


Mike




On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote:
> On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
> >
> >There are other places in TLS that fundamentally need to (indirectly) derive
> >public data out of secret key material.
> That's not a a problem. The problem is using the same mechanism to derive
> the public data that we use to derive the keys.
> It's even OK to use the same secret key for both (from an HSM POV).
>
> What Michael is saying is that there are existing functions for both KDF
> (secret material -> key) and Mac (secret material-> unique public data).
> He's requesting that TLS not have it's own versions of these functions.

So would using two different PRF functions, one for parts that don't
downgrade and another for parts that do downgrade (e.g. IV derivation,
unique / finished calculations, exporter calculations, etc..) solve the
issue?

(Of course, the two functions should be closely related, so not to
annoy software implementations too much)...


-Ilari

_______________________________________________
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


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



--------------000204050604020601070708-- From nobody Thu Apr 23 10:25: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 ADDBD1ACDCA for ; Thu, 23 Apr 2015 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 InW0K4gdJXh7 for ; Thu, 23 Apr 2015 10:25:49 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.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 607791ABB1A for ; Thu, 23 Apr 2015 10:25:39 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so23550087pab.2 for ; Thu, 23 Apr 2015 10:25:39 -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=iil8uJMT5pzNWnGHcAgp+Td+RjJyJ8PejtgSWhIPBrE=; b=XBX55gmsSLVnROCpCUZ/SkM8hSR9P/FtGKm6N2kYy6hlwj+oouQY+XM6PdNPhIg5CL WamZaFm+Fotz7/tBjY9nKM5cVHtJlcWStL2DArjefYeshpNmDp0+EZ9DZPWEnSLrEw+U EVhMV6BfeBXpNniCpHhkbOVtTN/RVlQ4NO7fSiCz9K3BUO1qoUD2WfVO+e73lrgWFc/o B8/8rSN56biRB3Nf4gr81h3rawo+vgVyAT+aS7ZIrgXEW5AbkvqsatjQ0GcgU+ee/kd5 xrqhTl2ukpR6eZ2BAwjs4segOELOnqz5osLFj03xMKujWRQZLGwhRQ0YjW8JlNvYKFbN /Ibw== X-Gm-Message-State: ALoCoQlqTsxDoiBNyN3lhsUNer4uUqYa2lillsfmcCg1Q61dvIlFIuSUsoQjGkuIk1+TkTILqVoZ X-Received: by 10.68.65.106 with SMTP id w10mr7086914pbs.75.1429809939072; Thu, 23 Apr 2015 10:25:39 -0700 (PDT) Received: from [10.90.197.114] (soi.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id by13sm8688898pdb.37.2015.04.23.10.25.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 10:25:38 -0700 (PDT) Message-ID: <55392B08.6020304@nthpermutation.com> Date: Thu, 23 Apr 2015 13:25:28 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Watson Ladd References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060602050604080805030104" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2015 17:25:51 -0000 This is a multi-part message in MIME format. --------------060602050604080805030104 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Inline On 4/22/2015 6:00 PM, Watson Ladd wrote: > > > On Apr 22, 2015 2:49 PM, "Michael StJohns" > wrote: > > > > I'm top posting my own post.... > > > > > > Sean et al: > > > > After spending a bit more time looking at things from the view point > of HSMs and cryptographic isolation, I'm now of the opinion that HKDF > shouldn't be specified. > > > > The specific issue is the difference between HDKF step 2 and the > SP800-108 expansion functions. Cryptographically, these > specifications are close to identical except for the inclusion of a > mandatory length term in the mixin values. Without this term, a key > stream produced from the same mixins (e.g. same label, randoms etc) > for the same master key will be identical regardless of the length of > the output key(s). > > > > E.g. if one call to the KDF has a target key of AES128 and another > call to the KDF using the same master key and mixins has a target key > of a single octet HMAC key, the first octet of the AES key will be > identical to that single octet HMAC key. Using this construct with > increasingly longer HMAC keys (thanks to HMAC's impedance matching > function) will eventually reveal each and every byte of the AES key. > > What if the first call for the HMAC key is 128 bits, and we use a > broken variant? > > Your example demonstrates why the sane data shouldn't be used for two > different purposes. In fact, it's not clear to me that we can make an > HSM friendly design without telling the HSM which derived values are > exportable and which not. > You are exactly correct. This needs to be part of the derivation information mixins. > > If we ensured that no value derived by HKDF ever is not used as an > encryption key, this would solve the problem at the cost of some pain > with channel binding. But this would be a very large change. > Not quite. There are two things you have to be able to enforce: 1) that the same key can't be used with a KDF and a MAC function. (Since the underlying function for the KDF is generally a MAC function, and the MAC function is public data where the KDF is private....). That requires strong key typing at the time the key is created along with a mechanism that can prevent "master keys" from being used as "integrity keys" (and trivially doing the same crypto functions as a MAC function and extracting the key stream that way). and 2) That the same (parts of the) key expansion key stream can't be used for different purposes. So I need to mix in the target types and lengths for the key material being produced and I ideally include information about whether or not the key material is extractable. So say I'm generating a master secret from a master secret (e.g. pre-master to master). I include in the KDF mixins an indication that the key material being produced is for a single master secret of length N. If I decide instead to produce symmetric operational key material (e.g. AES, HMAC, CMAC), then I change the mixins to indicate 2 AES-CCM keys of length 128 that are non-extractable (for example) The key expansion stream for the first call is completely disjoint from that produced by the second call and an HSM can use the mixin values to set its own policy bits. But those mixins have to be well known and standardized. By the way It turns out that you *can* safely derive both public and non public data from a key stream, but not with the current definitions. What you do is just add an exportable public data type as a mixin constant. So you do KDF (masterKey, "generic derive", 3 items, [AES-CCM, AES-CCM, RANDOM_DATA], [16, 16, 32], [0,0,EXPORTABLE]) .... KDF (Key masterKey, byte[] label, int itemcount, int[] keytypes, int[] keyLengths, int[] flags, Key[] keys) The info section marshalls the three different "key requests" as a concatention of 10 integers (count plus 3*3) and and adds that to the context or "info" passed in on each pass of the key expansion. All of these values passed in provide enforceable policy for the HSM, but result in a complete change in the underlying key stream if even one bit changes. Mike > > > > In an HSM, there is no way to differentiate these two different KDF > calls for legitimacy. > "no currently implemented way to differentiate" is closer to the truth. We can actually make the math work to cryptographically isolate these two cases in a meaningful way. > > > > If the KDF mixes in the length of the to be output key material, > then any change in the length of the requested key changes the entire > key stream. > > > > I see three different approaches to fix this - 1) specify the > SP800-56C with SP800-108 HMAC, 2) add the length term to the HKDF RFC > and republish it, 3) ensure one or more length terms are included in > the "info" for ALL KDF calls for TLS and document why. > > > > > > Mike > > > > > > > > > > > --------------060602050604080805030104 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Inline

On 4/22/2015 6:00 PM, Watson Ladd wrote:


On Apr 22, 2015 2:49 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> I'm top posting my own post....
>
>
> Sean et al:
>
> After spending a bit more time looking at things from the view point of HSMs and cryptographic isolation, I'm now of the opinion that HKDF shouldn't be specified.
>
> The specific issue is the difference between HDKF step 2 and the SP800-108 expansion functions.   Cryptographically, these specifications are close to identical except for the inclusion of a mandatory length term in the mixin values.   Without this term, a key stream produced from the same mixins (e.g. same label, randoms etc) for the same master key will be identical regardless of the length of the output key(s).
>
> E.g. if one call to the KDF has a target key of AES128 and another call to the KDF using the same master key and mixins has a target key of a single octet HMAC key, the first octet of the AES key will be identical to that single octet HMAC key.    Using this construct with increasingly longer HMAC keys (thanks to HMAC's impedance matching function) will eventually reveal each and every byte of the AES key.

What if the first call for the HMAC key is 128 bits, and we use a broken variant?

Your example demonstrates why the sane data shouldn't be used for two different purposes. In fact, it's not clear to me that we can make an HSM friendly design without telling the HSM which derived values are exportable and which not.


You are exactly correct.  This needs to be part of the derivation information mixins.

If we ensured that no value derived by HKDF ever is not used as an encryption key, this would solve the problem at the cost of some pain with channel binding. But this would be a very large change.



Not quite.  There are two things you have to be able to enforce:

1) that the same key can't be used with a KDF and a MAC function.  (Since the underlying function for the KDF is generally a MAC function, and the MAC function is public data where the KDF is private....).   That requires strong key typing at the time the key is created along with a mechanism that can prevent "master keys" from being used as "integrity keys" (and trivially doing the same crypto functions as a MAC function and extracting the key stream that way).

and

2) That the same (parts of the) key expansion key stream can't be used for different purposes.   So I need to mix in the target types and lengths for the key material being produced and I ideally include information about whether or not the key material is extractable.

So say I'm generating a master secret from a master secret (e.g. pre-master to master).  I include in the KDF mixins an indication that the key material being produced is for a single master secret of length N.  If I decide instead to produce symmetric operational key material (e.g. AES, HMAC, CMAC), then I change the mixins to indicate 2 AES-CCM keys of length 128 that are non-extractable (for example)  The key expansion stream for the first call is completely disjoint from that produced by the second call and an HSM can use the mixin values to set its own policy bits.  But those mixins have to be well known and standardized.


By the way It turns out that you *can* safely derive both public and non public data from a key stream, but not with the current definitions.

What you do is just add an exportable public data type as a mixin constant.   So you do


KDF (masterKey, "generic derive", 3 items, [AES-CCM, AES-CCM, RANDOM_DATA], [16, 16, 32], [0,0,EXPORTABLE])

....

KDF (Key masterKey, byte[] label, int itemcount, int[] keytypes, int[] keyLengths, int[] flags, Key[] keys)


The info section marshalls the three different "key requests" as a concatention of 10 integers (count plus 3*3) and and adds that to the context or "info" passed in on each pass of the key expansion.   All of these values passed in provide enforceable policy for the HSM, but result in a complete change in the underlying key stream if even one bit changes.

Mike






>
> In an HSM, there is no way to differentiate these two different KDF calls for legitimacy.


"no currently implemented way to differentiate" is closer to the truth.  We can actually make the math work to cryptographically isolate these two cases in a meaningful way.

>
> If the KDF mixes in the length of the to be output key material, then any change in the length of the requested key changes the entire key stream.
>
> I see three different approaches to fix this - 1) specify the SP800-56C with SP800-108 HMAC, 2) add the length term to the HKDF RFC and republish it, 3) ensure one or more length terms are included in the "info" for ALL KDF calls for TLS and document why. 
>
>
> Mike
>
>
>
>
>


--------------060602050604080805030104-- From nobody Thu Apr 23 10:35: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 13FEE1ACDFD for ; Thu, 23 Apr 2015 10:35: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, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZTrMK3r9ypg for ; Thu, 23 Apr 2015 10:35:49 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (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 BE8171B30DF for ; Thu, 23 Apr 2015 10:34:43 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so23771052pac.1 for ; Thu, 23 Apr 2015 10:34: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 :content-transfer-encoding; bh=FfZaBI7MsxbJ3CN9a+FnTaqpYLd2zDA/jumr6zx26EU=; b=A4yTa0ioECF4wfEK7SM461zqDf5Jx+vYQkTaT3xKz1mfzlrGUYrsyELgtmJv5tWW86 JqGiNOdEt0b2ftc3T5YB7soaUsTeAwzy/eLywTp0piqmOOsb6a7IZxdw0kJwjH44REoR VoYGvSM6jshDTUCrgNvf4GAp4Fyjc+xUt4cvYXDdl+KgC1z4JnbeWmAk/wVP1oyS//B2 qSq+BEQzafL3/PUxAmvEbbUEYPSo5NIkhxbxxyhF3RkoxO0+/JsUqHmKpYiaDPmkHvwq uq23mFs0zN70TwQ8JFF4WA8u/oMEjaJ+U8KQcuPCzCpTI1HfaVAftfcFtsZPbU+lba8s GXgA== X-Gm-Message-State: ALoCoQleBoHks02QP6OqtxD5OzOvlc0PSrALYETeJ5X7X01E0DBrKnIbUdaa7oc7v7c9sGk7fJO7 X-Received: by 10.70.41.165 with SMTP id g5mr7228537pdl.143.1429810483382; Thu, 23 Apr 2015 10:34:43 -0700 (PDT) Received: from [10.90.197.114] (edge-gw-rwc.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id gj9sm5169189pbc.77.2015.04.23.10.34.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 10:34:42 -0700 (PDT) Message-ID: <55392D3D.1020101@nthpermutation.com> Date: Thu, 23 Apr 2015 13:34:53 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ilari Liusvaara References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> In-Reply-To: <20150423084201.GA21246@LK-Perkele-VII> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2015 17:35:51 -0000 On 4/23/2015 4:42 AM, Ilari Liusvaara wrote: > On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote: >> On 4/22/2015 1:37 PM, Eric Rescorla wrote: >>> If we're using HKDF-Extract, can we just key off different labels? >>> >>> -Ekr >>> >> Basically, no. >> >> What you want to do is specify as part of the mixins (e.g. 'info' - e.g. the >> collection of label and context) a set of fields that describe 1) how the >> key stream is going to be broken up (eg. lengths of the sub keys), 2) what >> algorithms will use each of the parts of the key stream, and 3) whether or >> not those parts are allowed to be exported/extracted. > In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding field is seed, > right? > > So inside that (or whatever the equivalent), serialize: > - Label > - Lengths, types and exportable flags of subkeys > - Context > > ? Pretty much. > > Properly serializing that would avoid the well-known TLS 1.2 screwup in > PRF defintion (which got copied to "dh based key exchange" draft). > > > One possible structure in TLS notation: > > struct prf_output > { > /* > 0x0000 => For key derivation > 0x0001 => For AEAD keying > 0x8002 => For AEAD IV > 0x8003 => For octet string (exporters, unique) > */ > uint16 type; > uint16 length; /* In bytes. */ > }; I ended up with a bit larger set of key types: Master Secret (can only be used with KDFs) AES-CMAC AES-AEAD AES-ENCRYPT HMAC-SHA1 HMAC-SHA2 GENERIC-DATA (different that PKCS11 generic secret - could be IV material for example). as a starting point. It turns out that you want to subdivide AES AEAD uses from non AEAD AES functions because you don't want to be able to use AES-CTR to get around the AES-CCM and GCM "don't let the data come out unless its been verified" policy. > > struct prf_seed > { > opaque label<0..65535> > prf_output outputs<4..65532> > opaque context<0..65535> > }; > > Fixed expansion is 6 bytes and each subkey is 4 bytes. > > The key expansion for AES-256-GCM a'la TLS 1.2 would look like: > > 00 0d 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e > 00 10 00 01 00 20 00 01 00 20 80 02 00 04 80 02 00 04 > 00 40 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > > Where XX is the random data. One can see this extracts total of 72 > bytes. > > TLS 1.2 extended master secret with SHA-256 prf-hash looks like: > > 00 16 65 78 74 65 6e 64 65 64 20 6d 61 73 74 65 72 20 73 65 63 72 65 74 > 00 04 00 00 00 30 > 00 20 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX > > Where XX is the session hash up to that point. Output size can be seen > to be 48 bytes. > > > > Also, it occurs to me that if PRF has salt input (like HKDF), one should > stick something non-secret but variable there (e.g. client random, or > suitable handshake hash, or something). Some outputs share a (key,salt) > pair. Keys should be combined by serialization. > > > -Ilari > From nobody Thu Apr 23 10:53: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 254821B2CEC for ; Thu, 23 Apr 2015 10:53:12 -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 tqaO69GxV7lh for ; Thu, 23 Apr 2015 10:53:10 -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 86B9F1B30DD for ; Thu, 23 Apr 2015 10:52:46 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 4342A69968; Thu, 23 Apr 2015 20:52:44 +0300 (EEST) Date: Thu, 23 Apr 2015 20:52:44 +0300 From: Ilari Liusvaara To: Michael StJohns Message-ID: <20150423175244.GA26942@LK-Perkele-VII> References: <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> <55392D3D.1020101@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55392D3D.1020101@nthpermutation.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2015 17:53:12 -0000 On Thu, Apr 23, 2015 at 01:34:53PM -0400, Michael StJohns wrote: > On 4/23/2015 4:42 AM, Ilari Liusvaara wrote: > >On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote: > > > >One possible structure in TLS notation: > > > >struct prf_output > >{ > > /* > > 0x0000 => For key derivation > > 0x0001 => For AEAD keying > > 0x8002 => For AEAD IV > > 0x8003 => For octet string (exporters, unique) > > */ > > uint16 type; > > uint16 length; /* In bytes. */ > >}; > > I ended up with a bit larger set of key types: > > Master Secret (can only be used with KDFs) Right. > AES-CMAC Not used anywhere (insufficient security). > AES-AEAD Is there ment to be XXX-AEAD for different encryption algorithms? Do AES-CCM and AES-GCM share a key type? What about AES-CCM8? > AES-ENCRYPT Not used. Encryption always pairs with authentication (AEAD). > HMAC-SHA1 A NULL cipher key? That one wouldn't be directly used for anything else. > HMAC-SHA2 NULL cipher keys are per algorithm? > GENERIC-DATA (different that PKCS11 generic secret - could be IV material > for example). This is "octet string" above (except IVs are "AEAD IV"). > as a starting point. Depending on view, you also need special type for exporter secret, since it behaves somewhat unlike others. > It turns out that you want to subdivide AES AEAD uses from non AEAD AES > functions because you don't want to be able to use AES-CTR to get around the > AES-CCM and GCM "don't let the data come out unless its been verified" > policy. As said, encryption always pairs with authentication. -Ilari From nobody Thu Apr 23 12:02: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 C5E8B1A0004 for ; Thu, 23 Apr 2015 12:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TSKwgf80E1K for ; Thu, 23 Apr 2015 12:02:42 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (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 A066E1A0039 for ; Thu, 23 Apr 2015 12:01:27 -0700 (PDT) Received: by pdbqd1 with SMTP id qd1so26036135pdb.2 for ; Thu, 23 Apr 2015 12:01:27 -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 :content-transfer-encoding; bh=MwCtVO4mt0Ul6mOXC0rR8AwFb7OEa1c8k+jr7y21rlQ=; b=WRkub0YdDVmDuh5tUsYIDLoDDpLJkj0hLIj66AXu8ybSQY/jVIw6wzxG/t1EcjqPY6 sazDVblGqXYvSirfyfnik7dZINDanREuLYRgpZGM/b7UblRlPPpf9t0OYwKZtKBgu+gf ARqK9QFAnPZA/NeL0ibgCKTbDcxtvlIPavULVlX289MmVWNXr1TrW4zFBehWt9sp8f6B b4gV9yknA9q8K+cQP+17T0fc0Upi9/YPh66js9hs20uAFeQSJ3tr0SpgkJ7V/Bdnlf6K aDd9drYGoErggWT6DrmWHbC3lfJeUWZyL/BBruXoOWpruUOj4OtcgQVk7LpykF9dMEHC iIPA== X-Gm-Message-State: ALoCoQlZx4WwzpKyYWU2t+al/d1Lsbqz3QevHfehi57WMalRHjA3eqovys+mOsxfkZt23NLxHUcH X-Received: by 10.66.150.196 with SMTP id uk4mr8082160pab.54.1429815687306; Thu, 23 Apr 2015 12:01:27 -0700 (PDT) Received: from [10.90.197.114] (soi.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id cy5sm8825004pdb.85.2015.04.23.12.01.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 12:01:26 -0700 (PDT) Message-ID: <55394191.1050203@nthpermutation.com> Date: Thu, 23 Apr 2015 15:01:37 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ilari Liusvaara References: <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> <55392D3D.1020101@nthpermutation.com> <20150423175244.GA26942@LK-Perkele-VII> In-Reply-To: <20150423175244.GA26942@LK-Perkele-VII> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2015 19:02:43 -0000 On 4/23/2015 1:52 PM, Ilari Liusvaara wrote: > On Thu, Apr 23, 2015 at 01:34:53PM -0400, Michael StJohns wrote: >> On 4/23/2015 4:42 AM, Ilari Liusvaara wrote: >>> On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote: >>> >>> One possible structure in TLS notation: >>> >>> struct prf_output >>> { >>> /* >>> 0x0000 => For key derivation >>> 0x0001 => For AEAD keying >>> 0x8002 => For AEAD IV >>> 0x8003 => For octet string (exporters, unique) >>> */ >>> uint16 type; >>> uint16 length; /* In bytes. */ >>> }; >> I ended up with a bit larger set of key types: >> >> Master Secret (can only be used with KDFs) > Right. > >> AES-CMAC > Not used anywhere (insufficient security). For this and the comment below..... I'm not just thinking about TLS. And I am thinking about how to retrofit this to TLS1.2 which doesn't require this to be an AEAD function. And then there's the composed AEAD suites (e.g. AES-CBC with AES-CMAC wrapped as an AEAD function). So while they may not be used by TLS directly, I want to get code points for all the possibilities. > >> AES-AEAD > Is there ment to be XXX-AEAD for different encryption algorithms? > Do AES-CCM and AES-GCM share a key type? What about AES-CCM8? Generally yes for xxx-aead having different types per algorithm. Because you don't want to (for example) be able to use material for both AES and say GOST. For modes, AEAD modes are mostly supersets or combinations of non-AEAD modes and there's an attempt to enforce "releasability only after verification" type policies on the CCM and GCM modes. It would be good to have different codes for CCM and GCM (or even other modes), but I don't know that adds markedly to security. > >> AES-ENCRYPT > Not used. Encryption always pairs with authentication (AEAD). See above - one of the questions is how does a composed AEAD suite derive subkeys. Generically it seems to be "split the stream wherever you want" and as noted, that has a few problems. > >> HMAC-SHA1 > A NULL cipher key? That one wouldn't be directly used for anything else. For TLS1.2 and before, being able to tag that you're deriving an integrity key... ditto for below. > >> HMAC-SHA2 > NULL cipher keys are per algorithm? > >> GENERIC-DATA (different that PKCS11 generic secret - could be IV material >> for example). > This is "octet string" above (except IVs are "AEAD IV"). Not quite. ( :-) ) One of the problems we have is a lack of common language. And IV is one of those that's very slippery. TLS - incorrectly - called what's being produced by the master secret expansion an "IV". What it actually was was the "first IV" of the session for cipher suites that included CBC as a mode and a "session nonce" for suites with counter based ciphers. An IV is the common data injected by both sender and receiver to ensure that the same data doesn't encrypt the same way if identical data happens to occur in the plaintext stream multiple times. For counter based ciphers, the IV is used with the block counter to form the block nonce(s) that (is/are) encrypted to form the XOR key stream. An counter-based IV (e.g. for CTR, CCM and GCM) is generally composed of the concatenation of the session nonce (or as we've been discussing a fixed length of zeros) plus a per-message value (and we've been discussing always using the message sequence number as that per-message value). Due to the way TLS is constructed, what comes out of the master secret expansion can only be a "first IV" or a session nonce. It would be possible to change this so an expansion is done with each message (e.g. same master secret, different mixins such as the sequence number) to generate a true per-message IV, but that's expensive and provides little security benefit. > >> as a starting point. > Depending on view, you also need special type for exporter secret, since > it behaves somewhat unlike others. I think the easiest way to accomplish this is to use a flag saying whether or not its exportable (generally removable from an HSM) that gets mixed in. That way you have the common language of what you want to generate and then only have to decide on handling criteria. > >> It turns out that you want to subdivide AES AEAD uses from non AEAD AES >> functions because you don't want to be able to use AES-CTR to get around the >> AES-CCM and GCM "don't let the data come out unless its been verified" >> policy. > As said, encryption always pairs with authentication. > > > > -Ilari > > From nobody Thu Apr 23 13: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 522391B3279 for ; Thu, 23 Apr 2015 13:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIF3SSTHSo97 for ; Thu, 23 Apr 2015 13:06:50 -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 ED31D1B326B for ; Thu, 23 Apr 2015 13:06:33 -0700 (PDT) Received: by wiun10 with SMTP id n10so104881753wiu.1 for ; Thu, 23 Apr 2015 13:06: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=vWu975+24lPlECqQduenP9tt/VlcAqWRYHuYQXS90FM=; b=UBkT4gUh3lo3WA8kznotw8BQNFdCwULMcpEK3hDsjX1wG8u4zNshjZlU0ABIwkDDRk 4vOUaN6k4ofXp83mFN92w/rMnsht12kr5x3Vq4Nluo/KusJDbtYX2BeE1QGaVoRhZpds wgTHHLvxHZr+TeT1TK74PiLP2gkA5SEwKTeqFjHuoXdOB+Lysihtk2IHpPlliALe8i1c 3ZckX6MHQS29M4sO82mjadwzHhYINV298+LwnGyAO0auzv65mfl1bxpjLO2vZeNGjGkA 2LVyVscb+iIirNRNVmTsBtjwVKgHVDK7uW9DZ4EGSsZEEtT7Rz8MLhBRGLqCHplRUP5r Oy1A== X-Gm-Message-State: ALoCoQmBrtykVfDyJIevccPRwf64WmHlDuyOmebdW6AcRB26N9tsp0bes0CW5+BJqlhtWbh9F4zc X-Received: by 10.194.59.79 with SMTP id x15mr8662063wjq.81.1429819592673; Thu, 23 Apr 2015 13:06:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Thu, 23 Apr 2015 13:05:52 -0700 (PDT) In-Reply-To: <20150423110214.GA21716@LK-Perkele-VII> References: <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> <20150423110214.GA21716@LK-Perkele-VII> From: Eric Rescorla Date: Thu, 23 Apr 2015 16:05:52 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7b8737aeea1fa2051469d0ef Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2015 20:06:52 -0000 --047d7b8737aeea1fa2051469d0ef Content-Type: text/plain; charset=UTF-8 On Thu, Apr 23, 2015 at 7:02 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Thu, Apr 23, 2015 at 05:54:02AM -0400, Eric Rescorla wrote: > > On Thu, Apr 23, 2015 at 4:42 AM, Ilari Liusvaara < > > ilari.liusvaara@elisanet.fi> wrote: > > > > > On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote: > > > > On 4/22/2015 1:37 PM, Eric Rescorla wrote: > > > > >If we're using HKDF-Extract, can we just key off different labels? > > > > > > > > > >-Ekr > > > > > > > > > > > > > Basically, no. > > > > > > > > What you want to do is specify as part of the mixins (e.g. 'info' - > e.g. > > > the > > > > collection of label and context) a set of fields that describe 1) > how > > > the > > > > key stream is going to be broken up (eg. lengths of the sub keys), 2) > > > what > > > > algorithms will use each of the parts of the key stream, and 3) > whether > > > or > > > > not those parts are allowed to be exported/extracted. > > > > > > In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding field is > > > seed, > > > right? > > > > > > So inside that (or whatever the equivalent), serialize: > > > - Label > > > - Lengths, types and exportable flags of subkeys > > > - Context > > > > > > ? > > > > > > Properly serializing that would avoid the well-known TLS 1.2 screwup in > > > PRF defintion (which got copied to "dh based key exchange" draft). > > > > > > > Can elaborate on this? > > > > The DH-based key exchange draft uses HKDF and uses separate > > labels for each use of HKDF-Expand so that (for instance) exporters > > and key generation have different labels. > > The label+seed thing. My proposal for HKDF is to have null-terminated labels (in the same way as for the signing contexts. > > > Also, it occurs to me that if PRF has salt input (like HKDF), one > should > > > stick something non-secret but variable there (e.g. client random, or > > > suitable handshake hash, or something). > > > > > > Based on talking to Hugo, my understanding is that the best way > > to do this is by incorporating the handshake hash at the HKDF-Expand > > stage, as in: > > > > client_write_key = HKDF-Expand(Secret, "client write key" + session_hash, > > SecurityParameters.enc_key_length) > > Except that now nothing preturbs the secret extraction. Can you explain what you mean by "perturbs"? If you include the session hash it includes the randoms. > If you're referring to how we combine (say) the static DH and the > ephemeral > > DH, what we had discussed was running K1 through HKDF-Extract to > > generate PRK1 and then using PRK1 as the salt for HKDF-Extract on > > PRK2. I.e., > > > > PRK1 = HKDF-Extract(0, K1) > > PRK2 = HKDF-Extract(0, K2) > > AFAIK, nobody really uses FixedDH. And I think it was Adrei Popov who > described how to do 0RTT in simpler way. > > Also, maybe the only interesting application of FixedDH is deniable > key exchange. Except that supporting that would cause major issues > elsewhere (and "DH based key exchange" is not deniable). It's not FixedDH, it's the servers semi-static DH and the client's ephemeral. -Ekr > -Ilari > --047d7b8737aeea1fa2051469d0ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 23, 2015 at 7:02 AM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
<= div class=3D"HOEnZb">
On Thu, Apr 23, 2015 at 05:54:02AM -= 0400, Eric Rescorla wrote:
> On Thu, Apr 23, 2015 at 4:42 AM, Ilari Liusvaara <
> ilari.liusvaara@elisane= t.fi> wrote:
>
> > On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote:<= br> > > > On 4/22/2015 1:37 PM, Eric Rescorla wrote:
> > > >If we're using HKDF-Extract, can we just key off dif= ferent labels?
> > > >
> > > >-Ekr
> > > >
> > >
> > > Basically, no.
> > >
> > > What you want to do is specify as part of the mixins (e.g. &= #39;info' - e.g.
> > the
> > > collection of label and context)=C2=A0 a set of fields that = describe 1) how
> > the
> > > key stream is going to be broken up (eg. lengths of the sub = keys), 2)
> > what
> > > algorithms will use each of the parts of the key stream, and= 3) whether
> > or
> > > not those parts are allowed to be exported/extracted.
> >
> > In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding fi= eld is
> > seed,
> > right?
> >
> > So inside that (or whatever the equivalent), serialize:
> > - Label
> > - Lengths, types and exportable flags of subkeys
> > - Context
> >
> > ?
> >
> > Properly serializing that would avoid the well-known TLS 1.2 scre= wup in
> > PRF defintion (which got copied to "dh based key exchange&qu= ot; draft).
> >
>
> Can elaborate on this?
>
> The DH-based key exchange draft uses HKDF and uses separate
> labels for each use of HKDF-Expand so that (for instance) exporters > and key generation have different labels.

The label+seed thing.

My propos= al for HKDF is to have null-terminated labels (in the same
way as= for the signing contexts.




> > Also, it occurs to me that if PRF has salt input (like HKDF), one= should
> > stick something non-secret but variable there (e.g. client random= , or
> > suitable handshake hash, or something).
>
>
> Based on talking to Hugo, my understanding is that the best way
> to do this is by incorporating the handshake hash at the HKDF-Expand > stage, as in:
>
> client_write_key =3D HKDF-Expand(Secret, "client write key" = + session_hash,
>=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SecurityParameters.enc_key= _length)

Except that now nothing preturbs the secret extraction.
=

Can you explain what you mean by "perturbs"? = If you include the session hash
it includes the randoms.


> If you're referring to how we combine (say) the static DH and the = ephemeral
> DH, what we had discussed was running K1 through HKDF-Extract to
> generate PRK1 and then using PRK1 as the salt for HKDF-Extract on
> PRK2. I.e.,
>
>=C2=A0 =C2=A0 PRK1 =3D HKDF-Extract(0, K1)
>=C2=A0 =C2=A0 PRK2 =3D HKDF-Extract(0, K2)

AFAIK, nobody really uses FixedDH. And I think it was Adrei Popov wh= o
described how to do 0RTT in simpler way.

Also, maybe the only interesting application of FixedDH is deniable
key exchange. Except that supporting that would cause major issues
elsewhere (and "DH based key exchange" is not deniable).

It's not FixedDH, it's the servers semi-sta= tic DH and the client's ephemeral.

-Ekr


-Ilari

--047d7b8737aeea1fa2051469d0ef-- From nobody Thu Apr 23 13:08: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 1224F1B3296 for ; Thu, 23 Apr 2015 13:08: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 QF-K-7ZTEyim for ; Thu, 23 Apr 2015 13:08:10 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809681B3292 for ; Thu, 23 Apr 2015 13:07:59 -0700 (PDT) Received: by wiun10 with SMTP id n10so104919530wiu.1 for ; Thu, 23 Apr 2015 13:07:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XFp98P8roTMOGqgfomr7C4HnkmDjv9FBpQGdvKkqqso=; b=eEXv5j+87B0hRryqRm8oRopsX4p7e87ZF0vz/guKylh4tFs8zqEgmQaEN2Ux+bCvTw GeaEHzNUblD2NU5a616tBE7vc4dkJaE6ZceSQlutxSHUa1IAdanO7NKqC61Eo0LIJgjp HdfuHyWomUBpYLza6BStPi7D2xKmwDyTs+3H0K4YZr6DlE3nntZ3LD72ndK1xwazRhW1 hC1Bopuz9BzpXdhehfKdiTFQ8pvcDBgKRw4HYiP6wZ2PlS2ix1/BqC1H1ysMqbnw2aGJ i0N1RpgLWMLqJIUHz6h2XL+cHtLYDk6jhXrbPli+k71HVSmECmEiASU04Q629NcXdwGm +siw== X-Gm-Message-State: ALoCoQlD+lrjvYkZL5Amy+XXsMvcAXmJo2OjsB8+kgaBJ96ZE39GRJvgLiCs8eB+/BIIkHmHxNa+ X-Received: by 10.194.86.101 with SMTP id o5mr9106293wjz.8.1429819678254; Thu, 23 Apr 2015 13:07:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Thu, 23 Apr 2015 13:07:17 -0700 (PDT) In-Reply-To: <553925F7.5010704@nthpermutation.com> References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <553925F7.5010704@nthpermutation.com> From: Eric Rescorla Date: Thu, 23 Apr 2015 16:07:17 -0400 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=089e0102f35203fec0051469d638 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2015 20:08:13 -0000 --089e0102f35203fec0051469d638 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 23, 2015 at 1:03 PM, Michael StJohns wrote: > On 4/22/2015 7:03 PM, Eric Rescorla wrote: > > > > On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns > wrote: > >> On 4/22/2015 1:37 PM, Eric Rescorla wrote: >> >> If we're using HKDF-Extract, can we just key off different labels? >> >> -Ekr >> >> > Sorry, read that as "HKD-Expand". > > Actually, use HKDF as the term with no expand or extract suffix. > I discussed this extensively with Hugo and Hoeteck and their advice was to use them separately in a similar way to what's here (though they suggested a slightly different hierarchy which I have to edit in). Perhaps Hugo will weigh in as to the reasoning. -Ekr > Mike > > > > > > -Ekr > > >> Basically, no. >> >> The Extract function is really not designed to be used standalone but as >> a way of concentrating entropy for input to the expansion phase. Its >> dangerous to talk of these functions as separately callable. They are >> steps not separate functions. >> >> The extract step's only non-key input - salt - is not the same as the >> "info" input used in the expand phase - 'salt' is supposed to be missing or >> random, not a fixed string like a label. >> >> "info" is where the various labels go and that's only present in the >> expand phase. >> >> >> What you want to do is specify as part of the mixins (e.g. 'info' - e.g. >> the collection of label and context) a set of fields that describe 1) how >> the key stream is going to be broken up (eg. lengths of the sub keys), 2) >> what algorithms will use each of the parts of the key stream, and 3) >> whether or not those parts are allowed to be exported/extracted. >> >> A software module will basically ignore these because - really - its all >> the same memory although it should really make sure the key lengths and >> types matc. An HSM will look at these and be able to make policy decisions >> for protection of the segments (e.g. preventing export of material that was >> created to be non-exportable). >> >> Having all of these in the mixins means that the key stream expansion >> completely changes if ANY of these mixins change which in turn means that >> the various ways you can use to extract truly secret key material (as >> differentiated from exportable material) from an HSM using the currently >> defined mechanism can be eliminated. (I can explain my reasoning if >> necessary). >> >> >> Mike >> >> >> >> >> On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara < >> ilari.liusvaara@elisanet.fi> wrote: >> >>> On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote: >>> > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote: >>> > > >>> > >There are other places in TLS that fundamentally need to (indirectly) >>> derive >>> > >public data out of secret key material. >>> > That's not a a problem. The problem is using the same mechanism to >>> derive >>> > the public data that we use to derive the keys. >>> > It's even OK to use the same secret key for both (from an HSM POV). >>> > >>> > What Michael is saying is that there are existing functions for both >>> KDF >>> > (secret material -> key) and Mac (secret material-> unique public >>> data). >>> > He's requesting that TLS not have it's own versions of these functions. >>> >>> So would using two different PRF functions, one for parts that don't >>> downgrade and another for parts that do downgrade (e.g. IV derivation, >>> unique / finished calculations, exporter calculations, etc..) solve the >>> issue? >>> >>> (Of course, the two functions should be closely related, so not to >>> annoy software implementations too much)... >>> >>> >>> -Ilari >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> >> _______________________________________________ >> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > --089e0102f35203fec0051469d638 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 23, 2015 at 1:03 PM, Michael StJohns <= msj@nthpermutat= ion.com> wrote:
=20 =20 =20
On 4/22/2015 7:03 PM, Eric Rescorla wrote:


On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 4/22/2015 1:37 PM, Eric Rescorla wrote:
If we're using HKDF-Extract, can w= e just key off different labels?

-Ekr

Sorry, read that as "HKD-Expand".
 Actually, use HKDF as the term with no expand or extract suffix.

I discussed this extensively with Hugo = and Hoeteck and their advice was to use
them separately in a simi= lar way to what's here (though they suggested a slightly
diff= erent hierarchy which I have to edit in). Perhaps Hugo will weigh in as to<= /div>
the reasoning.

-Ekr
=C2=A0
Mike





-Ekr


 Basically, no.

The Extract function is really not designed to be used standalone but as a way of concentrating entropy for input to the expansion phase.=C2=A0 Its dangerous to talk o= f these functions as separately callable.=C2=A0 They are step= s not separate functions.

=C2=A0The extract step's only non-key input - salt - is= not the same as the "info" input used in the expand p= hase - 'salt' is supposed to be missing or random,=C2=A0 n= ot a fixed string like a label.=C2=A0

"info" is where the various labels go and that= 9;s only present in the expand phase.


What you want to do is specify as part of the mixins (e.g. 'info' - e.g. the collection of label and context)=C2=A0 a set of fields that describe 1) how the key stream is going to be broken up (eg. lengths of the sub keys), 2) what algorithms will use each of the parts of the key stream, and 3) whether or not those parts are allowed to be exported/extracted.

A software module will basically ignore these because - really - its all the same memory although it should really make sure the key lengths and types matc.=C2=A0 An H= SM will look at these and be able to make policy decisions for protection of the segments (e.g. preventing export of material that was created to be non-exportable).

Having all of these in the mixins means that the key stream expansion completely changes if ANY of these mixins change which in turn means=C2=A0 that the various wa= ys you can use to extract truly secret key material (as differentiated from exportable material) from an HSM using the currently defined mechanism can be eliminated.=C2=A0 (I can explain my reasoning if necessary)= .


Mike




On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara <ilari.liusva= ara@elisanet.fi> wrote:
On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote:
> On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
> >
> >There are other places in TLS that fundamentally need to (indirectly) derive
> >public data out of secret key material.
> That's not a a problem. The problem is using the same mechanism to derive
> the public data that we use to derive the keys.
> It's even OK to use the same secret key for both (from an HSM POV).
>
> What Michael is saying is that there are existing functions for both KDF
> (secret material -> key) and Mac (secret material-> unique public data). > He's requesting that TLS not have it's own versions of these functions.

So would using two different PRF functions, one for parts that don't
downgrade and another for parts that do downgrade (e.g. IV derivation,
unique / finished calculations, exporter calculations, etc..) solve the
issue?

(Of course, the two functions should be closely related, so not to
annoy software implementations too much)...


-Ilari

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



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


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




--089e0102f35203fec0051469d638-- From nobody Thu Apr 23 22:19: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 3B83E1B2CE3 for ; Thu, 23 Apr 2015 22:19:05 -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 bXC3HpgMYhzA for ; Thu, 23 Apr 2015 22:19:02 -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 A1A751B2CBA for ; Thu, 23 Apr 2015 22:18:32 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id E4A0F410E; Fri, 24 Apr 2015 08:18:29 +0300 (EEST) Date: Fri, 24 Apr 2015 08:18:29 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150424051829.GA3821@LK-Perkele-VII> References: <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> <20150423110214.GA21716@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] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2015 05:19:05 -0000 On Thu, Apr 23, 2015 at 04:05:52PM -0400, Eric Rescorla wrote: > On Thu, Apr 23, 2015 at 7:02 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > On Thu, Apr 23, 2015 at 05:54:02AM -0400, Eric Rescorla wrote: > > Can you explain what you mean by "perturbs"? If you include the session hash > it includes the randoms. HKDF RFC seems to essentially say 'if you can use salt, do so' > > If you're referring to how we combine (say) the static DH and the > > ephemeral > > > DH, what we had discussed was running K1 through HKDF-Extract to > > > generate PRK1 and then using PRK1 as the salt for HKDF-Extract on > > > PRK2. I.e., > > > > > > PRK1 = HKDF-Extract(0, K1) > > > PRK2 = HKDF-Extract(0, K2) > > > > AFAIK, nobody really uses FixedDH. And I think it was Adrei Popov who > > described how to do 0RTT in simpler way. > > > > Also, maybe the only interesting application of FixedDH is deniable > > key exchange. Except that supporting that would cause major issues > > elsewhere (and "DH based key exchange" is not deniable). > > > It's not FixedDH, it's the servers semi-static DH and the client's > ephemeral. Which semi-static DH (x client's ephemeral)? - Current - Previous (may not be available!) - Both For current, the only even semi-sane use I can come up with is server fixedDH certs (this input not a good place to stick PSKs if one wants "unified" something). For previous, it is useful if 0RTT group can differ from main exchange group (but server has to signal if this is to be included or not, since it may not be computable). (And both for when both of above apply). Also, it occurs to me that trying to stick keying data into non-key PRF inputs may not be a good idea... And the signature looks more complicated in draft "DH based key exchange", because the params are in the same message as certificate verify, instead of separate message (where hash would get it instead of having to be included separatedly). -Ilari From nobody Fri Apr 24 00:34: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 B4D471B354E for ; Fri, 24 Apr 2015 00:34:11 -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 V8zhqog4O45U for ; Fri, 24 Apr 2015 00:34:08 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002171B356B for ; Fri, 24 Apr 2015 00:32:50 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-05v.sys.comcast.net with comcast id KjYg1q001516pyw01jYqhU; Fri, 24 Apr 2015 07:32:50 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-08v.sys.comcast.net with comcast id KjYp1q0024uhcbK01jYpar; Fri, 24 Apr 2015 07:32:50 +0000 Message-ID: <5539F1A1.6030009@brainhub.org> Date: Fri, 24 Apr 2015 00:32:49 -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: <20150403205046.26518.89784.idtracker@ietfa.amsl.com> In-Reply-To: <20150403205046.26518.89784.idtracker@ietfa.amsl.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=1429860770; bh=SPfcN4mJIlJORhLONc3VWkSQaomhQUZ2UC35RFPZhoM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HCeQpsABa+WCVzH83jBH6M4cYO28rvGBpOlrPVr2nDJfejRo9eXEBIMTpFG0ylAtj tjsa5BFiLjgdGjKSLWvTfRpwV3aEPKUzfoChwdrBnSpSbI8hq0fJmhQvwqHrRm92Hq ENGsQEUo1KkiA96+h3WsBdzWUv/eSpx4SdR/LRGrVNlhzJRy1CgxvtCtrcfxjNPr/b sNh487VC9t4lIMDUfWa4AKUWfraOsqLkZKenbZfETrKFSKqLRNTNe3/UiqCS+W0txg QeR1bR/VkjJxbuURxsSY6c4AENwecmTCrpjDi4Dab6burRre8nWaYpmcz/r3LVxpAL 6C/SnIO82qZsw== Archived-At: Subject: Re: [TLS] ID Tracker State Update Notice: X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2015 07:34:11 -0000 I have a mostly editorial comment for sec 1. The document calls the composite group with p-1 elements a "group" in sec 5. The document calls the the 2-element group in sec 5.1 a "small subgroup". The document calls the prime group with q=(p-1)/2 elements a "group" in sec. A. Let's say we continue to call the q-element subset of p-1-element group a group, and continue to call the 2-element subset of p-1-element group a subgroup. My concern is that the sec. 1 may be interpreted as that by virtue of using groups from this document a client avoids the issue of small subgroups. In reality, the main benefit of groups in this document is that they give us the minimal small subgroup and there is an efficient check for the membership in the large (sub)group. This check is correctly specified in sec 5.1, but it should not be skipped. 1. The sentences with two first occurrences of "subgroup", both in section 1, should be reworded to not suggest that this document avoids small subgroups. 2. One can go further and try to clear the terminology about the group by assuming that the - _group_ has p-1 - _prime group_ has q - _small subgroup_ has 2 elements. i.e. insert "prime" in front of some "group", where appropriate. BTW, I like the ability for the client to indicate the support for the DH group size. From nobody Fri Apr 24 10: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 104E41B37BE for ; Fri, 24 Apr 2015 10:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 aaR9stb-C70R for ; Fri, 24 Apr 2015 10:10:29 -0700 (PDT) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.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 C0D9E1B37BC for ; Fri, 24 Apr 2015 10:10:28 -0700 (PDT) Received: by qkx62 with SMTP id 62so33935704qkx.0 for ; Fri, 24 Apr 2015 10:10: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:date:message-id:subject:from:to :content-type; bh=suLlgGm9881WjWfku4yh7xrddnVyMsCaA1QkDDGR0TE=; b=JmEj4l7bTirtu1iXkC9silO5dP/0nw2qpn3xEoxDm763YdcU8q6ZiKuLxZLDgaXYQL g0X7NAn4PSkK/ovmETvhu9JYCpebfrhWRCNNWiv42VsnqyEjTtqkOOfLGbO7wNwQS8XH RKoUoGrYovZm2jAsyXO4mGLB94SAwdfCGjwNr9ekTGrmf22bMBmzKRI701Y600mjxZUm Kvjnwj2uAVkJCA59LZpaMVP+4qCbjR5Jksbujx7YXNgPN5epKQTTe6O/12TpXkvVDwjt JfLLnMTtpKVwnJyWPpBQZf+PysvAzpMCscTI8GRpT8C2DWfbGtfyzmJoCtjiZd+co0By ykCw== X-Gm-Message-State: ALoCoQkt4YT5Z4xb2bHIqZg64XtbddEbwi2GNw0PC9OuVUnTYACQLBiBOfn6MXHmSZgmgtLrVll5 MIME-Version: 1.0 X-Received: by 10.55.21.12 with SMTP id f12mr17207511qkh.87.1429895428100; Fri, 24 Apr 2015 10:10:28 -0700 (PDT) Received: by 10.96.121.104 with HTTP; Fri, 24 Apr 2015 10:10:28 -0700 (PDT) X-Originating-IP: [2601:8:b300:a5:1443:ca81:e5b1:e93e] Date: Fri, 24 Apr 2015 10:10:28 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1147f3f40ee96b05147b79d6 Archived-At: Subject: [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: Fri, 24 Apr 2015 17:10:30 -0000 --001a1147f3f40ee96b05147b79d6 Content-Type: text/plain; charset=UTF-8 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 --001a1147f3f40ee96b05147b79d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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. =C2= =A0 =C2=A0In Dallas, there was significant support for using the derived &q= uot;IV" as a per session XOR mask for the counter.=C2=A0 If you have o= bjections to this approach please respond on the list by May 1, 2015 .=C2= =A0

Cheers,

Joe=C2=A0
--001a1147f3f40ee96b05147b79d6-- From nobody Fri Apr 24 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 8D9031B37C2 for ; Fri, 24 Apr 2015 10:13:28 -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 qhxhsohEms3P for ; Fri, 24 Apr 2015 10:13:25 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF001B37C8 for ; Fri, 24 Apr 2015 10:13:25 -0700 (PDT) Received: by qcrf4 with SMTP id f4so29188916qcr.0 for ; Fri, 24 Apr 2015 10:13:24 -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=Qrz2ii5hrs/8KJe1NYyX2JuEBYpi/oM1V3o6TlMcmxk=; b=BKi/ZPcCnJKa8R2c9Rh81wrPpvLQkJLshin1HKW959DrOdfSu9k2FWotBCUg+nP/VY 7bz7dsM+OjPc7DMa/pSbiq2rkKyGbg9RefFmfml0eiXSPHr/pUaKguXpbmgJFwHP9IJz DcB25cznzfXNA1bBJKHP/F08sgy0geXcA+kPKhsFdJs6Md7U6b++6jJKgUHFqd2m2HOO r+pzFLagxM8eZbZaggWVC/3zAyoNsKKCX2crz18bPf5Ku3rlS5O6uV6MU1LUC5KU79fH VML3ICcunfCf3/1+3XMkqsmCXwEJrpK3AAT+M2edmB5fjUets5l4ZaEKXnoQFGcjKj5w OQDA== X-Gm-Message-State: ALoCoQmZNZhArMMIh8JVLC3zw6SyEXQU/YMTusP5UvakfzCSngA/8kEca+ymc6dxOEoBcM2FSDe8 MIME-Version: 1.0 X-Received: by 10.55.21.93 with SMTP id f90mr17469297qkh.7.1429895604658; Fri, 24 Apr 2015 10:13:24 -0700 (PDT) Received: by 10.96.121.104 with HTTP; Fri, 24 Apr 2015 10:13:24 -0700 (PDT) X-Originating-IP: [2601:8:b300:a5:1443:ca81:e5b1:e93e] In-Reply-To: <55394191.1050203@nthpermutation.com> References: <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> <55392D3D.1020101@nthpermutation.com> <20150423175244.GA26942@LK-Perkele-VII> <55394191.1050203@nthpermutation.com> Date: Fri, 24 Apr 2015 10:13:24 -0700 Message-ID: From: Joseph Salowey To: Michael StJohns Content-Type: multipart/alternative; boundary=001a1147efc894ef9505147b83b0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2015 17:13:28 -0000 --001a1147efc894ef9505147b83b0 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 23, 2015 at 12:01 PM, Michael StJohns wrote: > On 4/23/2015 1:52 PM, Ilari Liusvaara wrote: > >> On Thu, Apr 23, 2015 at 01:34:53PM -0400, Michael StJohns wrote: >> >>> On 4/23/2015 4:42 AM, Ilari Liusvaara wrote: >>> >>>> On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote: >>>> >>>> One possible structure in TLS notation: >>>> >>>> struct prf_output >>>> { >>>> /* >>>> 0x0000 => For key derivation >>>> 0x0001 => For AEAD keying >>>> 0x8002 => For AEAD IV >>>> 0x8003 => For octet string (exporters, unique) >>>> */ >>>> uint16 type; >>>> uint16 length; /* In bytes. */ >>>> }; >>>> >>> I ended up with a bit larger set of key types: >>> >>> Master Secret (can only be used with KDFs) >>> >> Right. >> >> AES-CMAC >>> >> Not used anywhere (insufficient security). >> > > For this and the comment below..... I'm not just thinking about TLS. And > I am thinking about how to retrofit this to TLS1.2 which doesn't require > this to be an AEAD function. And then there's the composed AEAD suites > (e.g. AES-CBC with AES-CMAC wrapped as an AEAD function). So while they > may not be used by TLS directly, I want to get code points for all the > possibilities. > >> >> AES-AEAD >>> >> Is there ment to be XXX-AEAD for different encryption algorithms? >> Do AES-CCM and AES-GCM share a key type? What about AES-CCM8? >> > > Generally yes for xxx-aead having different types per algorithm. Because > you don't want to (for example) be able to use material for both AES and > say GOST. For modes, AEAD modes are mostly supersets or combinations of > non-AEAD modes and there's an attempt to enforce "releasability only after > verification" type policies on the CCM and GCM modes. It would be good to > have different codes for CCM and GCM (or even other modes), but I don't > know that adds markedly to security. > >> >> AES-ENCRYPT >>> >> Not used. Encryption always pairs with authentication (AEAD). >> > > See above - one of the questions is how does a composed AEAD suite derive > subkeys. Generically it seems to be "split the stream wherever you want" > and as noted, that has a few problems. > >> >> HMAC-SHA1 >>> >> A NULL cipher key? That one wouldn't be directly used for anything else. >> > > For TLS1.2 and before, being able to tag that you're deriving an integrity > key... ditto for below. > >> >> HMAC-SHA2 >>> >> NULL cipher keys are per algorithm? >> >> GENERIC-DATA (different that PKCS11 generic secret - could be IV material >>> for example). >>> >> This is "octet string" above (except IVs are "AEAD IV"). >> > > Not quite. ( :-) ) > > One of the problems we have is a lack of common language. And IV is one > of those that's very slippery. > > TLS - incorrectly - called what's being produced by the master secret > expansion an "IV". What it actually was was the "first IV" of the session > for cipher suites that included CBC as a mode and a "session nonce" for > suites with counter based ciphers. > > An IV is the common data injected by both sender and receiver to ensure > that the same data doesn't encrypt the same way if identical data happens > to occur in the plaintext stream multiple times. For counter based > ciphers, the IV is used with the block counter to form the block nonce(s) > that (is/are) encrypted to form the XOR key stream. > > An counter-based IV (e.g. for CTR, CCM and GCM) is generally composed of > the concatenation of the session nonce (or as we've been discussing a fixed > length of zeros) plus a per-message value (and we've been discussing always > using the message sequence number as that per-message value). > > Due to the way TLS is constructed, what comes out of the master secret > expansion can only be a "first IV" or a session nonce. It would be > possible to change this so an expansion is done with each message (e.g. > same master secret, different mixins such as the sequence number) to > generate a true per-message IV, but that's expensive and provides little > security benefit. > > > > >> as a starting point. >>> >> Depending on view, you also need special type for exporter secret, since >> it behaves somewhat unlike others. >> > > I think the easiest way to accomplish this is to use a flag saying whether > or not its exportable (generally removable from an HSM) that gets mixed > in. That way you have the common language of what you want to generate and > then only have to decide on handling criteria. > > [Joe] I've having trouble understanding what exactly you are designing here, is it the interface to a specific HSM or is it the TLS 1.3 key derivation or is it something else? I think we need to make sure that we have the requirements defined for the TLS 1.3 key derivation. Its not clear to me what the problem is with just including the context label, session hash and possibly length. The context label would differentiate between derived key material for different purposes. For example, public and private data would use different context labels. One would also probably want to include the cipher suite ID in the context label for keys derived for encryption. > > > >> It turns out that you want to subdivide AES AEAD uses from non AEAD AES >>> functions because you don't want to be able to use AES-CTR to get around >>> the >>> AES-CCM and GCM "don't let the data come out unless its been verified" >>> policy. >>> >> As said, encryption always pairs with authentication. >> >> >> >> -Ilari >> >> >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1147efc894ef9505147b83b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 23, 2015 at 12:01 PM, Michael StJohns <= ;msj@nthpermuta= tion.com> wrote:
On= 4/23/2015 1:52 PM, Ilari Liusvaara wrote:
On Thu, Apr 23, 2015 at 01:34:53PM -0400, Michael StJohns wrote:
On 4/23/2015 4:42 AM, Ilari Liusvaara wrote:
On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote:

One possible structure in TLS notation:

struct prf_output
{
=C2=A0 =C2=A0 =C2=A0 /*
=C2=A0 =C2=A0 =C2=A0 0x0000 =3D> For key derivation
=C2=A0 =C2=A0 =C2=A0 0x0001 =3D> For AEAD keying
=C2=A0 =C2=A0 =C2=A0 0x8002 =3D> For AEAD IV
=C2=A0 =C2=A0 =C2=A0 0x8003 =3D> For octet string (exporters, unique) =C2=A0 =C2=A0 =C2=A0 */
=C2=A0 =C2=A0 =C2=A0 uint16 type;
=C2=A0 =C2=A0 =C2=A0 uint16 length;=C2=A0 /* In bytes. */
};
I ended up with a bit larger set of key types:

Master Secret (can only be used with KDFs)
Right.

AES-CMAC
Not used anywhere (insufficient security).

 For this and the comment below..... I'm not just thinking about TLS.=C2= =A0 And I am thinking about how to retrofit this to TLS1.2 which doesn'= t require this to be an AEAD function.=C2=A0 And then there's the compo= sed AEAD suites (e.g. AES-CBC with AES-CMAC wrapped as an AEAD function).= =C2=A0 =C2=A0So while they may not be used by TLS directly, I want to get c= ode points for all the possibilities.

AES-AEAD
Is there ment to be XXX-AEAD for different encryption algorithms?
Do AES-CCM and AES-GCM share a key type? What about AES-CCM8?

 Generally yes for xxx-aead having different types per algorithm. Because yo= u don't want to (for example) be able to use material for both AES and = say GOST.=C2=A0 =C2=A0For modes, AEAD modes are mostly supersets or combina= tions of non-AEAD modes and there's an attempt to enforce "releasa= bility only after verification" type policies on the CCM and GCM modes= .=C2=A0 =C2=A0It would be good to have different codes for CCM and GCM (or = even other modes), but I don't know that adds markedly to security.

AES-ENCRYPT
Not used. Encryption always pairs with authentication (AEAD).

See above - one of the questions is how does a composed AEAD suite derive s= ubkeys.=C2=A0 Generically it seems to be "split the stream wherever yo= u want" and as noted, that has a few problems.

HMAC-SHA1
A NULL cipher key? That one wouldn't be directly used for anything else= .

 For TLS1.2 and before, being able to tag that you're deriving an integr= ity key...=C2=A0 ditto for below.

HMAC-SHA2
NULL cipher keys are per algorithm?

GENERIC-DATA (different that PKCS11 generic secret - could be IV material for example).
This is "octet string" above (except IVs are "AEAD IV")= .

 Not quite. (<begin pedantic mode>=C2=A0 :-) )

One of the problems we have is a lack of common language.=C2=A0 And IV is o= ne of those that's very slippery.

TLS - incorrectly - called what's being produced by the master secret e= xpansion an "IV".=C2=A0 =C2=A0What it actually was was the "= first IV" of the session for cipher suites that included=C2=A0 CBC as = a mode and a "session nonce" for suites with counter based cipher= s.

An IV is the common data injected by both sender and receiver to ensure tha= t the same data doesn't encrypt the same way if identical data happens = to occur in the plaintext stream multiple times.=C2=A0 For counter based ci= phers, the IV is used with the block counter to form the block nonce(s) tha= t (is/are) encrypted to form the XOR key stream.

An counter-based IV=C2=A0 (e.g. for CTR, CCM and GCM) is generally composed= of the concatenation of the session nonce (or as we've been discussing= a fixed length of zeros) plus a per-message value (and we've been disc= ussing always using the message sequence number as that per-message value).=

Due to the way TLS is constructed, what comes out of the master secret expa= nsion can only be a "first IV" or a session nonce.=C2=A0 It would= be possible to change this so an expansion is done with each message (e.g.= same master secret, different mixins such as the sequence number) to gener= ate a true per-message IV, but that's expensive and provides little sec= urity benefit.

</pedantic mode>


as a starting point.
Depending on view, you also need special type for exporter secret, since it behaves somewhat unlike others.

 I think the easiest way to accomplish this is to use a flag saying whether = or not its exportable (generally removable from an HSM) that gets mixed in.= =C2=A0 That way you have the common language of what you want to generate a= nd then only have to decide on handling criteria.

=

[Joe] I've having trouble understandin= g what exactly you are designing here, is it the interface to a specific HS= M or is it the TLS 1.3 key derivation or is it something else? I think we n= eed to make sure that we have the requirements defined for the TLS 1.3 key = derivation. =C2=A0

Its not clear to me what the pr= oblem is with just including the context label, session hash and possibly l= ength. =C2=A0 The context label would differentiate between derived key mat= erial for different purposes.=C2=A0 For example, public and private data wo= uld use different context labels.=C2=A0 One would also probably want to inc= lude the cipher suite ID in the context label for keys derived for encrypti= on.=C2=A0

=C2=A0



It turns out that you want to subdivide AES AEAD uses from non AEAD AES
functions because you don't want to be able to use AES-CTR to get aroun= d the
AES-CCM and GCM "don't let the data come out unless its been verif= ied"
policy.
As said, encryption always pairs with authentication.



-Ilari



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

--001a1147efc894ef9505147b83b0-- From nobody Fri Apr 24 10:28: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 825471B380C for ; Fri, 24 Apr 2015 10:28:37 -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 M5O7VYQKCbUS for ; Fri, 24 Apr 2015 10:28:34 -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 EE0121B380B for ; Fri, 24 Apr 2015 10:28:33 -0700 (PDT) Received: by wiun10 with SMTP id n10so27858152wiu.1 for ; Fri, 24 Apr 2015 10:28: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=8twaLUTZVyI49l95lFlV4aqyNSZ+v8C31KTGJRtq/Mo=; b=Ic72Ft8B4TfApuxfwOji7WvvhQbmQqSAx0UtRC2cfyk/qAtdGZp770iLava4wN/VKZ zGos6hoJEBjEX60sndy20M2LRYHIiFvLZKqltTNTvyLoe2E3slXud3Tvh5wdNFtEfKir YcWOux1lQHe/S+Hg3XPU/srL+/gPfNk0GiG+is1eBOR1xHBGNlqm1JaHfy4hJjfPOvvX NA11v2o+LLJdnOiU43W6YW+3s0ZPuEFdob/Q45gdeF/ftNrBWiDk8sxYoK6rziTgobGk jF6arl1AFA3YaI8Q0rAUGsONyhG7r/njGNkc9IkRG9iasnZo3T1rhD5uWXqZxTWvnQZJ CMhg== MIME-Version: 1.0 X-Received: by 10.180.99.42 with SMTP id en10mr102472wib.83.1429896512712; Fri, 24 Apr 2015 10:28:32 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Fri, 24 Apr 2015 10:28:32 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Fri, 24 Apr 2015 10:28:32 -0700 (PDT) In-Reply-To: References: <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> <55392D3D.1020101@nthpermutation.com> <20150423175244.GA26942@LK-Perkele-VII> <55394191.1050203@nthpermutation.com> Date: Fri, 24 Apr 2015 10:28:32 -0700 Message-ID: From: Watson Ladd To: Joseph Salowey Content-Type: multipart/alternative; boundary=f46d04428100b4b75b05147bb953 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2015 17:28:37 -0000 --f46d04428100b4b75b05147bb953 Content-Type: text/plain; charset=UTF-8 On Apr 24, 2015 10:13 AM, "Joseph Salowey" wrote: > > > > On Thu, Apr 23, 2015 at 12:01 PM, Michael StJohns wrote: >> >> On 4/23/2015 1:52 PM, Ilari Liusvaara wrote: >>> >>> On Thu, Apr 23, 2015 at 01:34:53PM -0400, Michael StJohns wrote: >>>> >>>> On 4/23/2015 4:42 AM, Ilari Liusvaara wrote: >>>>> >>>>> On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote: >>>>> >>>>> One possible structure in TLS notation: >>>>> >>>>> struct prf_output >>>>> { >>>>> /* >>>>> 0x0000 => For key derivation >>>>> 0x0001 => For AEAD keying >>>>> 0x8002 => For AEAD IV >>>>> 0x8003 => For octet string (exporters, unique) >>>>> */ >>>>> uint16 type; >>>>> uint16 length; /* In bytes. */ >>>>> }; >>>> >>>> I ended up with a bit larger set of key types: >>>> >>>> Master Secret (can only be used with KDFs) >>> >>> Right. >>> >>>> AES-CMAC >>> >>> Not used anywhere (insufficient security). >> >> >> For this and the comment below..... I'm not just thinking about TLS. And I am thinking about how to retrofit this to TLS1.2 which doesn't require this to be an AEAD function. And then there's the composed AEAD suites (e.g. AES-CBC with AES-CMAC wrapped as an AEAD function). So while they may not be used by TLS directly, I want to get code points for all the possibilities. >>> >>> >>>> AES-AEAD >>> >>> Is there ment to be XXX-AEAD for different encryption algorithms? >>> Do AES-CCM and AES-GCM share a key type? What about AES-CCM8? >> >> >> Generally yes for xxx-aead having different types per algorithm. Because you don't want to (for example) be able to use material for both AES and say GOST. For modes, AEAD modes are mostly supersets or combinations of non-AEAD modes and there's an attempt to enforce "releasability only after verification" type policies on the CCM and GCM modes. It would be good to have different codes for CCM and GCM (or even other modes), but I don't know that adds markedly to security. >>> >>> >>>> AES-ENCRYPT >>> >>> Not used. Encryption always pairs with authentication (AEAD). >> >> >> See above - one of the questions is how does a composed AEAD suite derive subkeys. Generically it seems to be "split the stream wherever you want" and as noted, that has a few problems. >>> >>> >>>> HMAC-SHA1 >>> >>> A NULL cipher key? That one wouldn't be directly used for anything else. >> >> >> For TLS1.2 and before, being able to tag that you're deriving an integrity key... ditto for below. >>> >>> >>>> HMAC-SHA2 >>> >>> NULL cipher keys are per algorithm? >>> >>>> GENERIC-DATA (different that PKCS11 generic secret - could be IV material >>>> for example). >>> >>> This is "octet string" above (except IVs are "AEAD IV"). >> >> >> Not quite. ( :-) ) >> >> One of the problems we have is a lack of common language. And IV is one of those that's very slippery. >> >> TLS - incorrectly - called what's being produced by the master secret expansion an "IV". What it actually was was the "first IV" of the session for cipher suites that included CBC as a mode and a "session nonce" for suites with counter based ciphers. >> >> An IV is the common data injected by both sender and receiver to ensure that the same data doesn't encrypt the same way if identical data happens to occur in the plaintext stream multiple times. For counter based ciphers, the IV is used with the block counter to form the block nonce(s) that (is/are) encrypted to form the XOR key stream. >> >> An counter-based IV (e.g. for CTR, CCM and GCM) is generally composed of the concatenation of the session nonce (or as we've been discussing a fixed length of zeros) plus a per-message value (and we've been discussing always using the message sequence number as that per-message value). >> >> Due to the way TLS is constructed, what comes out of the master secret expansion can only be a "first IV" or a session nonce. It would be possible to change this so an expansion is done with each message (e.g. same master secret, different mixins such as the sequence number) to generate a true per-message IV, but that's expensive and provides little security benefit. >> >> >> >>> >>>> as a starting point. >>> >>> Depending on view, you also need special type for exporter secret, since >>> it behaves somewhat unlike others. >> >> >> I think the easiest way to accomplish this is to use a flag saying whether or not its exportable (generally removable from an HSM) that gets mixed in. That way you have the common language of what you want to generate and then only have to decide on handling criteria. >> > > [Joe] I've having trouble understanding what exactly you are designing here, is it the interface to a specific HSM or is it the TLS 1.3 key derivation or is it something else? I think we need to make sure that we have the requirements defined for the TLS 1.3 key derivation. > > Its not clear to me what the problem is with just including the context label, session hash and possibly length. The context label would differentiate between derived key material for different purposes. For example, public and private data would use different context labels. One would also probably want to include the cipher suite ID in the context label for keys derived for encryption. The issue is the hardware has to enforce the usage of the derived keys. I think this will restrict our encoding significantly, perhaps turning it into some bitfields. Asking hardware to understand context labels is going to make it not hardware anymore. Of course, there are other approaches that offer most of the gains without these costs like separate fixed function terminators, or keeping only a few keys secret. Sincerely, Watson Ladd > > >> >> >> >>> >>>> It turns out that you want to subdivide AES AEAD uses from non AEAD AES >>>> functions because you don't want to be able to use AES-CTR to get around the >>>> AES-CCM and GCM "don't let the data come out unless its been verified" >>>> policy. >>> >>> As said, encryption always pairs with authentication. >>> >>> >>> >>> -Ilari >>> >>> >> >> _______________________________________________ >> 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 > --f46d04428100b4b75b05147bb953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 24, 2015 10:13 AM, "Joseph Salowey" <joe@salowey.net> wrote:
>
>
>
> On Thu, Apr 23, 2015 at 12:01 PM, Michael StJohns <msj@nthpermutation.com> wrote:
>>
>> On 4/23/2015 1:52 PM, Ilari Liusvaara wrote:
>>>
>>> On Thu, Apr 23, 2015 at 01:34:53PM -0400, Michael StJohns wrot= e:
>>>>
>>>> On 4/23/2015 4:42 AM, Ilari Liusvaara wrote:
>>>>>
>>>>> On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJo= hns wrote:
>>>>>
>>>>> One possible structure in TLS notation:
>>>>>
>>>>> struct prf_output
>>>>> {
>>>>> =C2=A0 =C2=A0 =C2=A0 /*
>>>>> =C2=A0 =C2=A0 =C2=A0 0x0000 =3D> For key derivation=
>>>>> =C2=A0 =C2=A0 =C2=A0 0x0001 =3D> For AEAD keying >>>>> =C2=A0 =C2=A0 =C2=A0 0x8002 =3D> For AEAD IV
>>>>> =C2=A0 =C2=A0 =C2=A0 0x8003 =3D> For octet string (= exporters, unique)
>>>>> =C2=A0 =C2=A0 =C2=A0 */
>>>>> =C2=A0 =C2=A0 =C2=A0 uint16 type;
>>>>> =C2=A0 =C2=A0 =C2=A0 uint16 length;=C2=A0 /* In bytes.= */
>>>>> };
>>>>
>>>> I ended up with a bit larger set of key types:
>>>>
>>>> Master Secret (can only be used with KDFs)
>>>
>>> Right.
>>>
>>>> AES-CMAC
>>>
>>> Not used anywhere (insufficient security).
>>
>>
>> For this and the comment below..... I'm not just thinking abou= t TLS.=C2=A0 And I am thinking about how to retrofit this to TLS1.2 which d= oesn't require this to be an AEAD function.=C2=A0 And then there's = the composed AEAD suites (e.g. AES-CBC with AES-CMAC wrapped as an AEAD fun= ction).=C2=A0 =C2=A0So while they may not be used by TLS directly, I want t= o get code points for all the possibilities.
>>>
>>>
>>>> AES-AEAD
>>>
>>> Is there ment to be XXX-AEAD for different encryption algorith= ms?
>>> Do AES-CCM and AES-GCM share a key type? What about AES-CCM8?<= br> >>
>>
>> Generally yes for xxx-aead having different types per algorithm. B= ecause you don't want to (for example) be able to use material for both= AES and say GOST.=C2=A0 =C2=A0For modes, AEAD modes are mostly supersets o= r combinations of non-AEAD modes and there's an attempt to enforce &quo= t;releasability only after verification" type policies on the CCM and = GCM modes.=C2=A0 =C2=A0It would be good to have different codes for CCM and= GCM (or even other modes), but I don't know that adds markedly to secu= rity.
>>>
>>>
>>>> AES-ENCRYPT
>>>
>>> Not used. Encryption always pairs with authentication (AEAD).<= br> >>
>>
>> See above - one of the questions is how does a composed AEAD suite= derive subkeys.=C2=A0 Generically it seems to be "split the stream wh= erever you want" and as noted, that has a few problems.
>>>
>>>
>>>> HMAC-SHA1
>>>
>>> A NULL cipher key? That one wouldn't be directly used for = anything else.
>>
>>
>> For TLS1.2 and before, being able to tag that you're deriving = an integrity key...=C2=A0 ditto for below.
>>>
>>>
>>>> HMAC-SHA2
>>>
>>> NULL cipher keys are per algorithm?
>>>
>>>> GENERIC-DATA (different that PKCS11 generic secret - could= be IV material
>>>> for example).
>>>
>>> This is "octet string" above (except IVs are "A= EAD IV").
>>
>>
>> Not quite. (<begin pedantic mode>=C2=A0 :-) )
>>
>> One of the problems we have is a lack of common language.=C2=A0 An= d IV is one of those that's very slippery.
>>
>> TLS - incorrectly - called what's being produced by the master= secret expansion an "IV".=C2=A0 =C2=A0What it actually was was t= he "first IV" of the session for cipher suites that included=C2= =A0 CBC as a mode and a "session nonce" for suites with counter b= ased ciphers.
>>
>> An IV is the common data injected by both sender and receiver to e= nsure that the same data doesn't encrypt the same way if identical data= happens to occur in the plaintext stream multiple times.=C2=A0 For counter= based ciphers, the IV is used with the block counter to form the block non= ce(s) that (is/are) encrypted to form the XOR key stream.
>>
>> An counter-based IV=C2=A0 (e.g. for CTR, CCM and GCM) is generally= composed of the concatenation of the session nonce (or as we've been d= iscussing a fixed length of zeros) plus a per-message value (and we've = been discussing always using the message sequence number as that per-messag= e value).
>>
>> Due to the way TLS is constructed, what comes out of the master se= cret expansion can only be a "first IV" or a session nonce.=C2=A0= It would be possible to change this so an expansion is done with each mess= age (e.g. same master secret, different mixins such as the sequence number)= to generate a true per-message IV, but that's expensive and provides l= ittle security benefit.
>>
>> </pedantic mode>
>>
>>>
>>>> as a starting point.
>>>
>>> Depending on view, you also need special type for exporter sec= ret, since
>>> it behaves somewhat unlike others.
>>
>>
>> I think the easiest way to accomplish this is to use a flag saying= whether or not its exportable (generally removable from an HSM) that gets = mixed in.=C2=A0 That way you have the common language of what you want to g= enerate and then only have to decide on handling criteria.
>>
>
> [Joe] I've having trouble understanding what exactly you are desig= ning here, is it the interface to a specific HSM or is it the TLS 1.3 key d= erivation or is it something else? I think we need to make sure that we hav= e the requirements defined for the TLS 1.3 key derivation. =C2=A0
>
> Its not clear to me what the problem is with just including the contex= t label, session hash and possibly length. =C2=A0 The context label would d= ifferentiate between derived key material for different purposes.=C2=A0 For= example, public and private data would use different context labels.=C2=A0= One would also probably want to include the cipher suite ID in the context= label for keys derived for encryption.=C2=A0

The issue is the hardware has to enforce the usage of the de= rived keys. I think this will restrict our encoding significantly,=C2=A0 pe= rhaps turning it into some bitfields. Asking hardware to understand context= labels is going to make it not hardware anymore.

Of course, there are other approaches that offer most of the= gains without these costs like separate fixed function terminators, or kee= ping only a few keys secret.

Sincerely,
Watson Ladd

>
> =C2=A0
>>
>>
>>
>>>
>>>> It turns out that you want to subdivide AES AEAD uses from= non AEAD AES
>>>> functions because you don't want to be able to use AES= -CTR to get around the
>>>> AES-CCM and GCM "don't let the data come out unle= ss its been verified"
>>>> policy.
>>>
>>> As said, encryption always pairs with authentication.
>>>
>>>
>>>
>>> -Ilari
>>>
>>>
>>
>> _______________________________________________
>> 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
>

--f46d04428100b4b75b05147bb953-- From nobody Fri Apr 24 10:53: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 E6F8F1B310E for ; Fri, 24 Apr 2015 10:53:51 -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 SHqzLxAXPYDK for ; Fri, 24 Apr 2015 10:53:49 -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 7550A1ACDDC for ; Fri, 24 Apr 2015 10:53:49 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 276094011; Fri, 24 Apr 2015 20:53:47 +0300 (EEST) Date: Fri, 24 Apr 2015 20:53:46 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20150424175346.GA25396@LK-Perkele-VII> References: <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> <55392D3D.1020101@nthpermutation.com> <20150423175244.GA26942@LK-Perkele-VII> <55394191.1050203@nthpermutation.com> 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] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2015 17:53:52 -0000 On Fri, Apr 24, 2015 at 10:28:32AM -0700, Watson Ladd wrote: > On Apr 24, 2015 10:13 AM, "Joseph Salowey" wrote: > > > > > > > > [Joe] I've having trouble understanding what exactly you are designing > > here, is it the interface to a specific HSM or is it the TLS 1.3 key > > derivation or is it something else? I think we need to make sure that we > > have the requirements defined for the TLS 1.3 key derivation. It looks to boil down to designing how to encode inputs to the underlying KDF. ("looks", because I think I am just beginning to figure out what the heck is actually wanted). > > Its not clear to me what the problem is with just including the context > > label, session hash and possibly length. The context label would > > differentiate between derived key material for different purposes. For > > example, public and private data would use different context labels. One > > would also probably want to include the cipher suite ID in the context > > label for keys derived for encryption. Well, in one mail, Mike says that context labels are not enough. He apparently wants for KDF to take type(s), export flag(s) and length(s) of key(s) to generate as parameters. And then stuff those to info/seed field (along label and such). Also, looks like he would prefer that different encryption algorithms have different types (e.g. AES-GCM vs. Chacha20-Poly1305). (Again, the comment above applies). > The issue is the hardware has to enforce the usage of the derived keys. I > think this will restrict our encoding significantly, perhaps turning it > into some bitfields. Asking hardware to understand context labels is going > to make it not hardware anymore. Well, most of the "Hardware" here is actually "software", just running on special-purpose hardware. > Of course, there are other approaches that offer most of the gains without > these costs like separate fixed function terminators, or keeping only a few > keys secret. Fixed function terminators? Also, what keys to keep secret does not fix things, since there are some fundamential secret->public derivations. -Ilari From nobody Fri Apr 24 13:00: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 670A31A1A6D for ; Fri, 24 Apr 2015 13:00: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 chgOtEhE8bZF for ; Fri, 24 Apr 2015 13:00:51 -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 2007D1A1A66 for ; Fri, 24 Apr 2015 13:00:51 -0700 (PDT) Received: by ykec202 with SMTP id c202so9245224yke.2 for ; Fri, 24 Apr 2015 13:00:50 -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=VIkGRGTzO6OdNN9NjRwPrlyNHQtBqwQbZxMFlwRKZM4=; b=nwPyj8EkMfJ9Aw1jvT26HdD0F5HlDchE4ltRaM4eWmw0Rujg8pn1vSuKqYtlRioNIH uK69eXVbfsGip0zh6q+jDTUKihKccVVCF4MyxhFEmpkcQOGT1GzJtxQ6Na2pHGaKQmsY LGK7tiDGIFELyn7lnamGa+q6xfocFrSw5zLo6deyJtbJ0o1d6/zOeD+lC9cxAKRTiC9+ zIl7uKSvWMqcDlK9pNUvtPulyNgqsYeTTmM9PFTGFEO80UY2suH6LaeKkqZefzLp6D5W OPmDtDyCpzvJJuy7tzeZvX2YuP0q4kUDtXDF2tbVt+tAHyLLLOhqViHqfBODMp0ar/sG pF/w== MIME-Version: 1.0 X-Received: by 10.236.106.74 with SMTP id l50mr46922yhg.143.1429905650503; Fri, 24 Apr 2015 13:00:50 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 24 Apr 2015 13:00:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Apr 2015 13:00:50 -0700 Message-ID: From: Martin Thomson To: Joseph Salowey Content-Type: text/plain; charset=UTF-8 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: Fri, 24 Apr 2015 20:00:52 -0000 On 24 April 2015 at 10:10, 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 . You aren't being particularly precise about the process here. I believe that these were the two options that were most debated: a) nonce = zeroes(N_MIN) XOR counter b) nonce = HKDF(...., N_MIN) XOR counter Did you mean the latter option? From nobody Fri Apr 24 13:44: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 7DE231A895D for ; Fri, 24 Apr 2015 13:44:56 -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 puC8HNjiBBcr for ; Fri, 24 Apr 2015 13:44:55 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F821A876A for ; Fri, 24 Apr 2015 13:44:55 -0700 (PDT) Received: by qcrf4 with SMTP id f4so32254921qcr.0 for ; Fri, 24 Apr 2015 13:44:54 -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=SrR48xNEbeGbr/R/rAOrml8laqiBpOe7gx32C2wVo+w=; b=cj+f/WY859/WNmyBHHNs5PTEusCle9E5p5xQlTl272Ag4UVfn1yb03OPETjygTJVxk mW3oNujItJii9qBuNVATzvbS2saR2NCuwUtyA0yTvTeIFqhoLKlXzFOL+rUUZttoveKz oNfp5beiV3fJAXOWWW70EEw21N6cim9W34s7oaCq+qJFmd8fXk+CEyXTYrRhUy5NgzVu z1WSEoYhU6M0Vincgr9czQnDUHpLLkKHkDUl6N4CGSsGsuBYfwYgHes8p+8V29l1oP0k HrXIkMrQfy/29/TTwogg4OHOFYzCCPtney+0wePJ5Y5gKKpdtQ7H/Umcb4P5DTkye35z Ov4g== X-Gm-Message-State: ALoCoQmtCcjFxJTghWLgJclQcL7taHfTaE107bulKspjWG0Zrzz7krRMdHAAdz3Jnvr857EU0NRC MIME-Version: 1.0 X-Received: by 10.140.151.131 with SMTP id 125mr294491qhx.41.1429908294391; Fri, 24 Apr 2015 13:44:54 -0700 (PDT) Received: by 10.96.121.104 with HTTP; Fri, 24 Apr 2015 13:44:54 -0700 (PDT) X-Originating-IP: [67.168.161.122] In-Reply-To: References: Date: Fri, 24 Apr 2015 13:44:54 -0700 Message-ID: From: Joseph Salowey To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113769a8f2ef7d05147e7732 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: Fri, 24 Apr 2015 20:44:56 -0000 --001a113769a8f2ef7d05147e7732 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson wrote: > On 24 April 2015 at 10:10, 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 . > > > You aren't being particularly precise about the process here. > > I believe that these were the two options that were most debated: > > a) nonce = zeroes(N_MIN) XOR counter > b) nonce = HKDF(...., N_MIN) XOR counter > > Did you mean the latter option? > [Joe] Yes, the later where the quantity XORed with the counter is derived during the handshake. --001a113769a8f2ef7d05147e7732 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 24 April 2015 at 10:10, Joseph Salowey &= lt;joe@salowey.net> wrote:
> The general consensus on the list seems to prefer to derive "IV&q= uot; and use it
> to make the AEAD nonce less predictable. Most folks seemed to be OK wi= th
> this approach.=C2=A0 =C2=A0 In Dallas, there was significant support f= or using the
> derived "IV" as a per session XOR mask for the counter.=C2= =A0 If you have
> objections to this approach please respond on the list by May 1, 2015 = .


You aren't being particularly precise about the process her= e.

I believe that these were the two options that were most debated:

a)=C2=A0 nonce =3D zeroes(N_MIN) XOR counter
b)=C2=A0 nonce =3D HKDF(...., N_MIN) XOR counter

Did you mean the latter option?

[Joe] Yes, the late= r where the quantity XORed with the counter is derived during the handshake= . =C2=A0
--001a113769a8f2ef7d05147e7732-- From nobody Fri Apr 24 13:52: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 1869B1A92EC for ; Fri, 24 Apr 2015 13:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0dIs3HajKAx for ; Fri, 24 Apr 2015 13:52:39 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 0D45F1A92E7 for ; Fri, 24 Apr 2015 13:52:39 -0700 (PDT) Received: by ykep21 with SMTP id p21so9446142yke.3 for ; Fri, 24 Apr 2015 13:52:38 -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=P5cKwsA8Vi103feN2+HY/J8IvxuXkciylY3iV5G6nhU=; b=DqQMopv00GCSAyKm4YvTxBpTDb/wCTes+m7yay2RUapR8EqtEtSifDdedEIJIMN8M3 lSGUn6rKxgk/SQwqTUdgsgt1+EAM/duL/6sgx382o/+fBiUpF+m1oAu3543puka3DfLF el0EvhKvZlQxb2mH6vgOpNI+LwkJtnc4OpKMx8gpQm4ML45PqLTjjhYCZ5UFSN24IjZV 3s5jHaPM9z23FGhf9OUE0sHl4KdQcvQiPVAFNCEs4AAfSktwmHyAGiXdtPslRj1wtaTV dbaCohQEomCjg+JVQB2S4xQN2hLHORIr2NCQzoe5NaMeClJzFgBFHwP3QRNmesiml466 CDoA== MIME-Version: 1.0 X-Received: by 10.236.106.74 with SMTP id l50mr310556yhg.143.1429908758461; Fri, 24 Apr 2015 13:52:38 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 24 Apr 2015 13:52:38 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Apr 2015 13:52:38 -0700 Message-ID: From: Martin Thomson To: Joseph Salowey Content-Type: text/plain; charset=UTF-8 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: Fri, 24 Apr 2015 20:52:40 -0000 On 24 April 2015 at 13:44, Joseph Salowey wrote: > [Joe] Yes, the later where the quantity XORed with the counter is derived > during the handshake. Sounds good. We'll be guided by the concurrent HSM-friendly discussion on what to do precisely. From nobody Fri Apr 24 14:01: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 057901A92FD for ; Fri, 24 Apr 2015 14:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY7ZR7FQiw8c for ; Fri, 24 Apr 2015 14:01:09 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE041A8A7E for ; Fri, 24 Apr 2015 14:01:09 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id A9E729A4020; Fri, 24 Apr 2015 17:00:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 5+lm3LB-tHMP; Fri, 24 Apr 2015 17:00:37 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-145-93.washdc.fios.verizon.net [96.255.145.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B8EE19A400D; Fri, 24 Apr 2015 17:00:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-65-630461104 From: Russ Housley In-Reply-To: Date: Fri, 24 Apr 2015 17:00:26 -0400 Message-Id: <6DF16074-2C87-416B-9C0D-0C7797984B5E@vigilsec.com> References: To: Joseph Salowey X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF TLS 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: Fri, 24 Apr 2015 21:01:11 -0000 --Apple-Mail-65-630461104 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Joe: > On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson = wrote: > On 24 April 2015 at 10:10, 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 . >=20 >=20 > You aren't being particularly precise about the process here. >=20 > I believe that these were the two options that were most debated: >=20 > a) nonce =3D zeroes(N_MIN) XOR counter > b) nonce =3D HKDF(...., N_MIN) XOR counter >=20 > Did you mean the latter option? >=20 > [Joe] Yes, the later where the quantity XORed with the counter is = derived during the handshake. =20 If the computation is done in an HSM-friendly fashion, I am supportive. Russ --Apple-Mail-65-630461104 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Joe:

On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 24 April 2015 at 10:10, Joseph Salowey <joe@salowey.net> 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 .


You aren't being particularly precise about the process here.

I believe that these were the two options that were most debated:

a)  nonce = zeroes(N_MIN) XOR counter
b)  nonce = HKDF(...., N_MIN) XOR counter

Did you mean the latter option?

[Joe] Yes, the later where the quantity XORed with the counter is derived during the handshake.  

If the computation is done in an HSM-friendly fashion, I am supportive.

Russ


--Apple-Mail-65-630461104-- From nobody Fri Apr 24 14:32: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 4BBF71AC3FF for ; Fri, 24 Apr 2015 14:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.645 X-Spam-Level: ** X-Spam-Status: No, score=2.645 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, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_36=0.6, MALFORMED_FREEMAIL=0.001, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.021, 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 mfdVjEUj8F6L for ; Fri, 24 Apr 2015 14:32:23 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010: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 38ECA1ACD09 for ; Fri, 24 Apr 2015 14:32:23 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so45751054lbb.3 for ; Fri, 24 Apr 2015 14:32:21 -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:from:date:message-id :subject:cc:content-type; bh=nTD256U5xvA2EJjKSEFrNKLmLHlWRNQjncOMet6th5I=; b=xZ6gyL6KUsk/XwioNfWRintoiiv1/xmDnmS2OtBElkCKv8Mzg30OACbfP2sZicaTwV cUsB1toyQGbQ0JOHKJKiEpfxmw2MvvpxVn5/Q3jxCvja3p+MQKTY6og/0WYO4VpQ9eDn 5hEbh7+kk3Z1VGI3ABNKu8cID9OD7E7C6NmT+5VEqMhuZCqC3OWQo5R6fjUbPDkfU+g8 vQXs2eAg3wYFwdxpxB7PvezxCItBj95JPoQV6WFcPBJw3TSmrqcl0AUaPzh0zPKx4ITh i1vkX4m+KbauSMCDe+q/i3+2tmvL9ntrKZ25tTKFauyWxLHuUeeA0ems3lqeW0eOGQtw i+1Q== X-Received: by 10.112.185.100 with SMTP id fb4mr308788lbc.79.1429911141711; Fri, 24 Apr 2015 14:32:21 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.66 with HTTP; Fri, 24 Apr 2015 14:31:51 -0700 (PDT) In-Reply-To: <55392B08.6020304@nthpermutation.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> From: Hugo Krawczyk Date: Fri, 24 Apr 2015 17:31:51 -0400 X-Google-Sender-Auth: yAasUgciFkwuj438yPWYvb_h_Rk Message-ID: Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3ca22a9861905147f21e2 Archived-At: Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2015 21:32:26 -0000 --001a11c3ca22a9861905147f21e2 Content-Type: text/plain; charset=UTF-8 Here are a few clarifications regarding HKDF and its use in TLS 1.3 in response to recent emails (including those under the "HSM-friendly Key Computation" thread). I will not touch on anything specific to HSM or PKCS11 since I know little about these and the recent exchange on these issues has not helped me understanding these things any better (but rather confuse me more). Let me start with the issue of whether we should be using the HKDF-Extract and HKDF-Expand separately or only use HKDF as a single function (which internally operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for the latter approach (single function) as it deals with HKDF as a black box. But there are also advantages to calling these two components separately, and TLS 1.3 provides some good examples for that. First, HKDF is built to output as many keys as needed from a single HKDF operation, but in TLS we are deriving multiple keys from the same keying material through separate applications of the expand part. In such a case it is more natural to apply extract once and apply expand several times (with different info fields!). For example, Master Secret is derived using a single Extract operation but it is then used in three different Expand operations for deriving other keys (application traffic keys, export master secret, and resumption master secret). Second, when one starts with a strong key then the Extract step can be skipped making it convenient to be able to call Expand directly. Third, it is convenient to call Expand directly as a PRF for computing the Finished message. Lastly, and not least, it makes the key derivation logic more explicit which helps conveying the rationale of each operation and helps those analyzing the protocol (now and in the future). My recommendation is to keep the Extract and Expand separation for the moment, in particular due to the last point, so we can see more clearly the logic while still setting the missing details of the protocol. When the whole picture is clear we can revisit this point. On other issues: - This should be obvious but worth repeating: All calls to HKDF-Expand MUST use a non-empty info field binding the derived key(s) to a unique context (in the case of TLS this is usually a label and a cumulative session-hash). - It was suggested that the length of derived keys should be part of the input to key expansion. If desired, this length can be entered through the info field of HKDF but I would be very careful not to derive two different keys where the only difference in the 'info' values is the key length. If the two keys happen to be of the same length one would end up with two keys that are identical. - One of the emails raises the issue of using random salt, as recommended by RFC 5869. Note that the RFC recommendation also indicates that the salt value should be something that is authenticated during the protocol, or otherwise it can be selected by the adversary. This authentication needs to happen independently of the key being derived using this salt. For example, one should be careful not to incur in a circular logic, e.g. deriving a key mackey=HKDF(salt, info) and then using mackey to authenticate the salt by computing MAC(mackey, salt). This is why the proposed TLS 1.3 key derivation scheme does not use nonces as salt. - Someone said: "In an ideal world we would all use the same KDFs rather than inventing a new one for each protocol." This was exactly the goal of HKDF, namely, provide a single KDF that can serve different protocols, requirements and settings. The interested reader can consult my Crypto 2010 paper https://eprint.iacr.org/2010/264 for a very detailed treatment of key derivation in general and HKDF in particular,and why this one design fits many different uses. TLS 1.3 is a perfect demonstration of the versatility of HKDF as it is used as a random oracle, randomness extractor and PRF, depending on the key material being derived. See the next item for an example. - Another issue raised in recent email exchange is the way to merge the semi-static value g^xs (where s is the semi-static server's private key and x the ephemeral client's private key) with the ephemeral value g^xy. This is done by first extracting a key from g^xs as PRK1=HKDF-extract(0,g^xs) and then extracting PRK2=HKDF-extract(PRK1,g^xy). Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as a random oracle as needed in the proof of security. Then PRK2 is derived with salt=PRK2 for the following reason. If g^xs is not exposed (the typical case) then this HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially the less demanding property from HKDF). If g^xs is revealed by compromise of the server's semi static private key s (after the conclusion of the handshake, as in the forward-secrecy setting), then PRK1 is actually an authenticated random and non-secret salt so you use HKDF as a randomness extractor. In other words, each use of HKDF uses the minimal cryptographic assumption one can have depending on the context of derivation. - Finally, there has been a long discussion related to the derivation of both secret and non-secret material (the latter for IVs). I can't say how this works with HSMs, PKCS11 or other standards, but from the cryptographic point of view doing this "mixed" derivation of secret and non-secret values is not a problem as long as HMAC is not broken as a PRF. Hugo --001a11c3ca22a9861905147f21e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Here are a few clarifications regarding HKD= F and its use in TLS 1.3 in response
to recent emails (including those u= nder the "HSM-friendly Key Computation"
thread). I will not to= uch on anything specific to HSM or PKCS11 since I know
little about thes= e and the recent exchange on these issues has not helped me
understandin= g these things any better (but rather confuse me more).

Let me start= with the issue of whether we should be using the HKDF-Extract and
HKDF-= Expand separately or only use HKDF as a single function (which internallyoperates HKDF-Extract and HKDF-Expand). There is an obvious advantage for= the
latter approach (single function) as it deals with HKDF as a black = box.
But there are also advantages to calling these two components sepa= rately, and
TLS 1.3 provides some good examples for that. First, HKDF is= built to output as
many keys as needed from a single HKDF operation, bu= t in TLS we are deriving
multiple keys from the same keying material thr= ough separate applications of the
expand part. In such a case it is more= natural to apply extract once and apply
expand several times (with diff= erent info fields!). For example, Master Secret
is derived using a singl= e Extract operation but it is then used in three
different Expand operat= ions for deriving other keys (application traffic keys,
export master se= cret, and resumption master secret). Second, when one starts with
a stro= ng key then the Extract step can be skipped making it convenient to be
a= ble to call Expand directly. Third, it is convenient to call Expand directl= y as
a PRF for computing the Finished message. Lastly, and not least, it= makes the
key derivation logic more explicit which helps conveying the = rationale of each
operation and helps those analyzing the protocol (now = and in the future).

My recommendation is to keep the Extract and Exp= and separation for the moment,
in particular due to the last point, so w= e can see more clearly the logic while
still setting the missing details= of the protocol. When the whole picture is
clear we can revisit this po= int.

On other issues:

- This should be obvious but worth rep= eating: All calls to HKDF-Expand MUST use
=C2=A0 a non-empty info field = binding the derived key(s) to a unique context (in the
=C2=A0 case of T= LS this is usually a label and a cumulative session-hash).
=C2=A0
- = It was suggested that the length of derived keys should be part of the inpu= t
=C2=A0 to key expansion. If desired, this length can be entered throug= h the info
=C2=A0 field of HKDF but I would be very careful not to deriv= e two different keys
=C2=A0 where the only difference in the 'info&#= 39; values is the key length. If the two
=C2=A0 keys happen to be of the= same length one would end up with two keys that are
=C2=A0 identical.
- One of the emails raises the issue of using random salt, as recomme= nded by RFC
=C2=A0 5869. Note that the RFC recommendation also indicates= that the salt value
=C2=A0 should be something that is authenticated du= ring the protocol, or otherwise it
=C2=A0 can be selected by the adversa= ry. This authentication needs to happen
=C2=A0 independently of the key = being derived using this salt. For example, one
=C2=A0 should be careful= not to incur in a circular logic, e.g. deriving a key
=C2=A0 mackey=3DH= KDF(salt, info) and then using mackey to authenticate the salt by
=C2=A0= computing MAC(mackey, salt). This is why the proposed TLS 1.3 key derivati= on
=C2=A0 scheme does not use nonces as salt.

- Someone said: &qu= ot;In an ideal world we would all use the same KDFs rather than
=C2=A0 i= nventing a new one for each protocol." This was exactly the goal of HK= DF,
=C2=A0 namely, provide a single KDF that can serve different protoco= ls, requirements
=C2=A0 and settings. The interested reader can consult = my Crypto 2010 paper
=C2=A0 https://eprint.iacr.org/2010/264
=C2=A0 for a very detailed treatme= nt of key derivation in general and HKDF in
=C2=A0 particular,and why th= is one design fits many different uses. TLS 1.3 is a
=C2=A0 perfect demo= nstration of the versatility of HKDF as it is used as a random
=C2=A0 or= acle, randomness extractor and PRF, depending on the key material being
= =C2=A0 derived. See the next item for an example.

- Another issue ra= ised in recent email exchange is the way to merge the
=C2=A0 semi-static= value g^xs (where s is the semi-static server's private key and x
= =C2=A0 the ephemeral client's private key) with the ephemeral value g^x= y.
=C2=A0 This is done by first extracting a key from g^xs as PRK1=3DHK= DF-extract(0,g^xs)
=C2=A0 and then extracting PRK2=3DHKDF-extract(PRK1,g= ^xy).
=C2=A0 Here is the logic: PRK1 is extracted from g^xs using HKDF(= 0,...) as a random
=C2=A0 oracle as needed in the proof of security. The= n PRK2 is derived with salt=3DPRK2
=C2=A0 for the following reason. If g= ^xs is not exposed (the typical case) then this
=C2=A0 HKDF use only req= uires treating HKDF(PRK1,...) as a PRF (essentially the less
=C2=A0 dema= nding property from HKDF).=C2=A0 If g^xs is revealed by compromise of the=C2=A0 server's semi static private key s (after the conclusion of th= e handshake, as
=C2=A0 in the forward-secrecy setting), then PRK1 is act= ually an authenticated random
=C2=A0 and non-secret salt so you use HKDF= as a randomness extractor.
=C2=A0 In other words, each use of HKDF use= s the minimal cryptographic assumption one
=C2=A0 can have depending on = the context of derivation.

- Finally, there has been a long discussi= on related to the derivation of both
=C2=A0 secret and non-secret materi= al (the latter for IVs). I can't say how this
=C2=A0 works with HSMs= , PKCS11 or other standards, but from the cryptographic point
=C2=A0 of = view doing this "mixed" derivation of secret and non-secret value= s is not a
=C2=A0 problem as long as HMAC is not broken as a PRF.
=C2= =A0
Hugo

--001a11c3ca22a9861905147f21e2-- From nobody Fri Apr 24 14: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 A526B1A1B3F for ; Fri, 24 Apr 2015 14:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYT0E-aG_R2v for ; Fri, 24 Apr 2015 14:37:18 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010: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 DB7291A1B12 for ; Fri, 24 Apr 2015 14:37:17 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so45817627lbb.2 for ; Fri, 24 Apr 2015 14:37:16 -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:from:date:message-id :subject:to:cc:content-type; bh=Vn6FosxI7R9Ldfc1E9uULgXSv6Ky4dO+UVUxqaLoh7g=; b=sJ3yxgTOyEuLDC4iywDYsoTmLtKzp9KePsmoLDib3nUqquLuA6SlIadJJ2/Iqs9FdY dZjysFIT+BwjpS7inzLRctnJTkg/rOn3UFf827kQlhwpM4+CEfiQoFsgKw4l5wasxuOD KR5Rs/M6SzSzPDdUrH2630WD2dF/uBUOXl87mKXFSjWAVuslEOb3oELqHGkDFOsoyI0p WzJE0TJRbV3XGqE7IXKJEIgJHhUkwZfpWC4hsvOa7gw/m/b64QpS+JnD4KgQGsU1RUxR o7BaAx7aVa5zwPFdwWM0FoEHsijcQHK5ssGyjPFj94FRJygVDidjHUpCAPITorVq6URw Bksw== X-Received: by 10.152.88.1 with SMTP id bc1mr318556lab.79.1429911436428; Fri, 24 Apr 2015 14:37:16 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.66 with HTTP; Fri, 24 Apr 2015 14:36:45 -0700 (PDT) In-Reply-To: References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <55381302.5030307@nthpermutation.com> <553925F7.5010704@nthpermutation.com> From: Hugo Krawczyk Date: Fri, 24 Apr 2015 17:36:45 -0400 X-Google-Sender-Auth: RiHolBBPUaIekVypdLY3-Uq4ZkE Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c3540c3a8c7305147f338e Archived-At: Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] HSM-friendly Key Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2015 21:37:20 -0000 --001a11c3540c3a8c7305147f338e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 23, 2015 at 4:07 PM, Eric Rescorla wrote: > > > On Thu, Apr 23, 2015 at 1:03 PM, Michael StJohns > wrote: > >> On 4/22/2015 7:03 PM, Eric Rescorla wrote: >> >> >> >> On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns >> wrote: >> >>> On 4/22/2015 1:37 PM, Eric Rescorla wrote: >>> >>> If we're using HKDF-Extract, can we just key off different labels? >>> >>> -Ekr >>> >>> >> Sorry, read that as "HKD-Expand". >> >> Actually, use HKDF as the term with no expand or extract suffix. >> > > I discussed this extensively with Hugo and Hoeteck and their advice was t= o > use > them separately in a similar way to what's here (though they suggested a > slightly > different hierarchy which I have to edit in). Perhaps Hugo will weigh in > as to > the reasoning. > =E2=80=8BI've just addressed this issue in an email in the "confirming the room=E2=80=99s consensus: adopt HKDF PRF for TLS 1.3" threa= d (it's the first point in the list of issues in that email). Hugo > -Ekr > > >> Mike >> >> >> >> >> >> -Ekr >> >> >>> Basically, no. >>> >>> The Extract function is really not designed to be used standalone but a= s >>> a way of concentrating entropy for input to the expansion phase. Its >>> dangerous to talk of these functions as separately callable. They are >>> steps not separate functions. >>> >>> The extract step's only non-key input - salt - is not the same as the >>> "info" input used in the expand phase - 'salt' is supposed to be missin= g or >>> random, not a fixed string like a label. >>> >>> "info" is where the various labels go and that's only present in the >>> expand phase. >>> >>> >>> What you want to do is specify as part of the mixins (e.g. 'info' - e.g= . >>> the collection of label and context) a set of fields that describe 1) = how >>> the key stream is going to be broken up (eg. lengths of the sub keys), = 2) >>> what algorithms will use each of the parts of the key stream, and 3) >>> whether or not those parts are allowed to be exported/extracted. >>> >>> A software module will basically ignore these because - really - its al= l >>> the same memory although it should really make sure the key lengths and >>> types matc. An HSM will look at these and be able to make policy decis= ions >>> for protection of the segments (e.g. preventing export of material that= was >>> created to be non-exportable). >>> >>> Having all of these in the mixins means that the key stream expansion >>> completely changes if ANY of these mixins change which in turn means t= hat >>> the various ways you can use to extract truly secret key material (as >>> differentiated from exportable material) from an HSM using the currentl= y >>> defined mechanism can be eliminated. (I can explain my reasoning if >>> necessary). >>> >>> >>> Mike >>> >>> >>> >>> >>> On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara < >>> ilari.liusvaara@elisanet.fi> wrote: >>> >>>> On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote: >>>> > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote: >>>> > > >>>> > >There are other places in TLS that fundamentally need to >>>> (indirectly) derive >>>> > >public data out of secret key material. >>>> > That's not a a problem. The problem is using the same mechanism to >>>> derive >>>> > the public data that we use to derive the keys. >>>> > It's even OK to use the same secret key for both (from an HSM POV). >>>> > >>>> > What Michael is saying is that there are existing functions for both >>>> KDF >>>> > (secret material -> key) and Mac (secret material-> unique public >>>> data). >>>> > He's requesting that TLS not have it's own versions of these >>>> functions. >>>> >>>> So would using two different PRF functions, one for parts that don't >>>> downgrade and another for parts that do downgrade (e.g. IV derivation, >>>> unique / finished calculations, exporter calculations, etc..) solve th= e >>>> issue? >>>> >>>> (Of course, the two functions should be closely related, so not to >>>> annoy software implementations too much)... >>>> >>>> >>>> -Ilari >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> >>> >>> >>> _______________________________________________ >>> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls >>> >>> >>> >>> _______________________________________________ >>> 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 > > --001a11c3540c3a8c7305147f338e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 23, 2015 at 4:07 PM, Eric Rescorla <ekr@rtfm.c= om> wrote:


On Thu, Apr 23, 2015 at 1:03 PM, Michael StJohns <msj@nt= hpermutation.com> wrote:
=20 =20 =20
On 4/22/2015 7:03 PM, Eric Rescorla wrote:


On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 4/22/2015 1:37 PM, Eric Rescorla wrote:
If we're using HKDF-Extract, can w= e just key off different labels?

-Ekr

Sorry, read that as "HKD-Expand".
 Actually, use HKDF as the term with no expand or extract suffix.

I discussed this extensively wit= h Hugo and Hoeteck and their advice was to use
them separately in= a similar way to what's here (though they suggested a slightly
different hierarchy which I have to edit in). Perhaps Hugo will weigh in= as to
the reasoning.
=E2=80=8BI've just addressed this issue in = an email in the
"confirming the room=E2=80=99s consensus: adopt HK= DF PRF for TLS 1.3" thread
(it'= ;s the first point in the list of issues in that email).

Hugo


-Ekr
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Mike





-Ekr


 Basically, no.

The Extract function is really not designed to be used standalone but as a way of concentrating entropy for input to the expansion phase.=C2=A0 Its dangerous to talk o= f these functions as separately callable.=C2=A0 They are step= s not separate functions.

=C2=A0The extract step's only non-key input - salt - is= not the same as the "info" input used in the expand p= hase - 'salt' is supposed to be missing or random,=C2=A0 n= ot a fixed string like a label.=C2=A0

"info" is where the various labels go and that= 9;s only present in the expand phase.


What you want to do is specify as part of the mixins (e.g. 'info' - e.g. the collection of label and context)=C2=A0 a set of fields that describe 1) how the key stream is going to be broken up (eg. lengths of the sub keys), 2) what algorithms will use each of the parts of the key stream, and 3) whether or not those parts are allowed to be exported/extracted.

A software module will basically ignore these because - really - its all the same memory although it should really make sure the key lengths and types matc.=C2=A0 An H= SM will look at these and be able to make policy decisions for protection of the segments (e.g. preventing export of material that was created to be non-exportable).

Having all of these in the mixins means that the key stream expansion completely changes if ANY of these mixins change which in turn means=C2=A0 that the various wa= ys you can use to extract truly secret key material (as differentiated from exportable material) from an HSM using the currently defined mechanism can be eliminated.=C2=A0 (I can explain my reasoning if necessary)= .


Mike




On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara <ilari.liusva= ara@elisanet.fi> wrote:
On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote:
> On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
> >
> >There are other places in TLS that fundamentally need to (indirectly) derive
> >public data out of secret key material.
> That's not a a problem. The problem is using the same mechanism to derive
> the public data that we use to derive the keys.
> It's even OK to use the same secret key for both (from an HSM POV).
>
> What Michael is saying is that there are existing functions for both KDF
> (secret material -> key) and Mac (secret material-> unique public data). > He's requesting that TLS not have it's own versions of these functions.

So would using two different PRF functions, one for parts that don't
downgrade and another for parts that do downgrade (e.g. IV derivation,
unique / finished calculations, exporter calculations, etc..) solve the
issue?

(Of course, the two functions should be closely related, so not to
annoy software implementations too much)...


-Ilari

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



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


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





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


--001a11c3540c3a8c7305147f338e-- From nobody Fri Apr 24 15:20: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 82B411AD0B4; Fri, 24 Apr 2015 15:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 p1IZSNp6DzRF; Fri, 24 Apr 2015 15:20:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1841E1AD0B3; Fri, 24 Apr 2015 15:20:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C4DB7180208; Fri, 24 Apr 2015 15:19:18 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150424221918.C4DB7180208@rfc-editor.org> Date: Fri, 24 Apr 2015 15:19:18 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7507 on TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2015 22:20:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7507 Title: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks Author: B. Moeller, A. Langley Status: Standards Track Stream: IETF Date: April 2015 Mailbox: bmoeller@acm.org, agl@google.com Pages: 8 Characters: 17165 Updates: RFC 2246, RFC 4346, RFC 4347, RFC 5246, RFC 6347 I-D Tag: draft-ietf-tls-downgrade-scsv-05.txt URL: https://www.rfc-editor.org/info/rfc7507 This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Apr 24 22:35: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 15B191A01AE for ; Fri, 24 Apr 2015 22:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, 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 PW5GzXCqJI5Z for ; Fri, 24 Apr 2015 22:35:02 -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 6D5871A90A7 for ; Fri, 24 Apr 2015 22:35:01 -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 C4AE281811; Sat, 25 Apr 2015 08:34:58 +0300 (EEST) Date: Sat, 25 Apr 2015 08:34:58 +0300 From: Ilari Liusvaara To: Hugo Krawczyk Message-ID: <20150425053458.GA28576@LK-Perkele-VII> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> 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] =?utf-8?q?confirming_the_room=E2=80=99s__consensus=3A_adopt?= =?utf-8?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2015 05:35:05 -0000 On Fri, Apr 24, 2015 at 05:31:51PM -0400, Hugo Krawczyk wrote: > Here are a few clarifications regarding HKDF and its use in TLS 1.3 in response > to recent emails (including those under the "HSM-friendly Key Computation" > thread). I will not touch on anything specific to HSM or PKCS11 since I know > little about these and the recent exchange on these issues has not helped me > understanding these things any better (but rather confuse me more). Actually, for me, that HSM thread actually clarified what the actual requirements are (which lets one minimize distruption). > Let me start with the issue of whether we should be using the HKDF-Extract and > HKDF-Expand separately or only use HKDF as a single function (which internally > operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for the > latter approach (single function) as it deals with HKDF as a black box. > But there are also advantages to calling these two components separately, and > TLS 1.3 provides some good examples for that. First, HKDF is built to output as > many keys as needed from a single HKDF operation, but in TLS we are deriving > multiple keys from the same keying material through separate applications of the > expand part. In such a case it is more natural to apply extract once and apply > expand several times (with different info fields!). For example, Master Secret > is derived using a single Extract operation but it is then used in three > different Expand operations for deriving other keys (application traffic keys, > export master secret, and resumption master secret). Second, when one starts with > a strong key then the Extract step can be skipped making it convenient to be > able to call Expand directly. Third, it is convenient to call Expand directly as > a PRF for computing the Finished message. Lastly, and not least, it makes the > key derivation logic more explicit which helps conveying the rationale of each > operation and helps those analyzing the protocol (now and in the future). Some models derive even more things out of (handshake) MS, e.g. one model does: - s2c_appMS. - eMS - Unique - c2s_appMS. - rPMS > My recommendation is to keep the Extract and Expand separation for the moment, > in particular due to the last point, so we can see more clearly the logic while > still setting the missing details of the protocol. When the whole picture is > clear we can revisit this point. > > On other issues: > > - This should be obvious but worth repeating: All calls to HKDF-Expand MUST use > a non-empty info field binding the derived key(s) to a unique context (in the > case of TLS this is usually a label and a cumulative session-hash). > > - It was suggested that the length of derived keys should be part of the input > to key expansion. If desired, this length can be entered through the info > field of HKDF but I would be very careful not to derive two different keys > where the only difference in the 'info' values is the key length. If the two > keys happen to be of the same length one would end up with two keys that are > identical. Well, there would still be string input of what the key is (otherwise e.g. rPMS and eMS might up ending being the same, which isn't desirable). > - One of the emails raises the issue of using random salt, as recommended by RFC > 5869. Note that the RFC recommendation also indicates that the salt value > should be something that is authenticated during the protocol, or otherwise it > can be selected by the adversary. This authentication needs to happen > independently of the key being derived using this salt. For example, one > should be careful not to incur in a circular logic, e.g. deriving a key > mackey=HKDF(salt, info) and then using mackey to authenticate the salt by > computing MAC(mackey, salt). This is why the proposed TLS 1.3 key derivation > scheme does not use nonces as salt. With fixed salts, the HKDF extract function is essentially H1(H2(x)), where H1 and H2 are H, but with different (pseudorandom) IVs. Also, handshake hashes are very hard to control to any significant degree (or invoking HKDF with bad salt is the least of your worries). E.g. Suppose prf-hash is 256-bit MD5-equivalent-security. The handshake security just breaks catastrophically against active attacks (passive attacks are another matter). > - Another issue raised in recent email exchange is the way to merge the > semi-static value g^xs (where s is the semi-static server's private key and x > the ephemeral client's private key) with the ephemeral value g^xy. "the semi-static server's private key"??? There is no "the key". There's the old semi-static key (which may not be available), and the new semi-static key. And the two may or may not be the same key, and those keys may not even be available. Also, in certain conditions, not mixing in DH result with the old key actually leads to an attack (mixing the new one does not help here). Also, I heard some implementers complaining about mixing the new one, and after calculating the time penalty, I can easily understand (it is pretty sizable). > This is done by first extracting a key from g^xs as PRK1=HKDF-extract(0,g^xs) > and then extracting PRK2=HKDF-extract(PRK1,g^xy). > Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as a random > oracle as needed in the proof of security. Then PRK2 is derived with salt=PRK2 > for the following reason. If g^xs is not exposed (the typical case) then this > HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially the less > demanding property from HKDF). If g^xs is revealed by compromise of the > server's semi static private key s (after the conclusion of the handshake, as > in the forward-secrecy setting), then PRK1 is actually an authenticated random > and non-secret salt so you use HKDF as a randomness extractor. > In other words, each use of HKDF uses the minimal cryptographic assumption one > can have depending on the context of derivation. If it is the new one, it is not properly authenticated (have I mentioned how nasty even capturing the proper assumptions is?). > - Finally, there has been a long discussion related to the derivation of both > secret and non-secret material (the latter for IVs). I can't say how this > works with HSMs, PKCS11 or other standards, but from the cryptographic point > of view doing this "mixed" derivation of secret and non-secret values is > not a problem as long as HMAC is not broken as a PRF. Well, looks like that problem got sorted out (by getting the "HSM folks" to actually state the actual requirements). -Ilari From nobody Fri Apr 24 22:59: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 AC4651ACF1D for ; Fri, 24 Apr 2015 22:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAY1HtdxPY59 for ; Fri, 24 Apr 2015 22:59:55 -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 77EF61ACF1A for ; Fri, 24 Apr 2015 22:59:55 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-02v.sys.comcast.net with comcast id L5zu1q0015AAYLo015zuKp; Sat, 25 Apr 2015 05:59:54 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-15v.sys.comcast.net with comcast id L5zt1q00M4uhcbK015zuP1; Sat, 25 Apr 2015 05:59:54 +0000 Message-ID: <553B2D59.3030407@brainhub.org> Date: Fri, 24 Apr 2015 22:59:53 -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: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <20150425053458.GA28576@LK-Perkele-VII> In-Reply-To: <20150425053458.GA28576@LK-Perkele-VII> 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=1429941594; bh=1cSK6WM9E6cQ4fNOMiceYW1JW4qlhtN59cTKQ7hsvDY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mCcBgURFw9BZc7WCz6nJ+GxfXoGL8E37sUffFATUAuD7qYf5Jixb8gv27xs32BNmc HpNAxg8ikX6f9Z0LSkeRMqt5bFYJh6khmEkKhD/1Tr3prAPRRA9MzN5/p8U1gpEsgi FRYODJaQFgn1ZdXnvsEbwNTISUhllZD049AdkF2x11uiELl6Kf91orcgVvQlxmzDcz 9od4PFIbGnZNkCzaYTQ+cG93X0UcpPOsBgaTo4WxvuasQHnVVu6m96dwo7Eao00uiM 3pno6dt+ujG97JHMGRh0NH3CEVIzLnTs4KIJ+v9jZr4CgMheWCQA5G+DhutIPB43WT 9ThudpX7IMt0Q== Archived-At: Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s__consensus=3A_adop?= =?windows-1252?q?t_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2015 05:59:57 -0000 On 04/24/2015 10:34 PM, Ilari Liusvaara wrote: > On Fri, Apr 24, 2015 at 05:31:51PM -0400, Hugo Krawczyk wrote: >> Here are a few clarifications regarding HKDF and its use in TLS 1.3 in response >> to recent emails (including those under the "HSM-friendly Key Computation" >> thread). I will not touch on anything specific to HSM or PKCS11 since I know >> little about these and the recent exchange on these issues has not helped me >> understanding these things any better (but rather confuse me more). > > Actually, for me, that HSM thread actually clarified what the actual requirements > are (which lets one minimize distruption). > >> Let me start with the issue of whether we should be using the HKDF-Extract and >> HKDF-Expand separately or only use HKDF as a single function (which internally >> operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for the >> latter approach (single function) as it deals with HKDF as a black box. >> But there are also advantages to calling these two components separately, and >> TLS 1.3 provides some good examples for that. First, HKDF is built to output as >> many keys as needed from a single HKDF operation, but in TLS we are deriving >> multiple keys from the same keying material through separate applications of the >> expand part. In such a case it is more natural to apply extract once and apply >> expand several times (with different info fields!). For example, Master Secret >> is derived using a single Extract operation but it is then used in three >> different Expand operations for deriving other keys (application traffic keys, >> export master secret, and resumption master secret). Second, when one starts with >> a strong key then the Extract step can be skipped making it convenient to be >> able to call Expand directly. Third, it is convenient to call Expand directly as >> a PRF for computing the Finished message. Lastly, and not least, it makes the >> key derivation logic more explicit which helps conveying the rationale of each >> operation and helps those analyzing the protocol (now and in the future). > > Some models derive even more things out of (handshake) MS, e.g. one model does: > - s2c_appMS. > - eMS > - Unique > - c2s_appMS. > - rPMS > >> My recommendation is to keep the Extract and Expand separation for the moment, >> in particular due to the last point, so we can see more clearly the logic while >> still setting the missing details of the protocol. When the whole picture is >> clear we can revisit this point. >> >> On other issues: >> >> - This should be obvious but worth repeating: All calls to HKDF-Expand MUST use >> a non-empty info field binding the derived key(s) to a unique context (in the >> case of TLS this is usually a label and a cumulative session-hash). >> >> - It was suggested that the length of derived keys should be part of the input >> to key expansion. If desired, this length can be entered through the info >> field of HKDF but I would be very careful not to derive two different keys >> where the only difference in the 'info' values is the key length. If the two >> keys happen to be of the same length one would end up with two keys that are >> identical. > > Well, there would still be string input of what the key is (otherwise e.g. rPMS > and eMS might up ending being the same, which isn't desirable). > >> - One of the emails raises the issue of using random salt, as recommended by RFC >> 5869. Note that the RFC recommendation also indicates that the salt value >> should be something that is authenticated during the protocol, or otherwise it >> can be selected by the adversary. This authentication needs to happen >> independently of the key being derived using this salt. For example, one >> should be careful not to incur in a circular logic, e.g. deriving a key >> mackey=HKDF(salt, info) and then using mackey to authenticate the salt by >> computing MAC(mackey, salt). This is why the proposed TLS 1.3 key derivation >> scheme does not use nonces as salt. > > With fixed salts, the HKDF extract function is essentially H1(H2(x)), where > H1 and H2 are H, but with different (pseudorandom) IVs. Ilari beat me on this, but I also made this observation. In more details: According to intended use of HKDF, HKDF-Extract is this: HMS = HKDF-Extract( salt=0, IKM=g^xy ) Which is: A. HMAC( 0, g^xy ) = Hash( opad || Hash( ipad || g^xy ) ). The two invocations of the Hash() begin with hashing fixed values, so one can re-write the A as A1: Hash1( Hash2( g^xy ) ), which can be rewritten as A2: Hash3( g^xy ) = Hash( opad || Hash( ipad || g^xy ) ) Therefore, HKDF-Extract( 0, g^xy ) should be viewed as deterministic hash of g^xy and that's the only contribution of g^xy in HKDF. For comparison, TLS 1.2 does the following in the first step: B. Hash(g^xy ^ opad || Hash( (g^xy ^ ipad) || "master secret" + ClientHello.random + ServerHello.random) ) ); It would be amusing to see a case when A2 is secure, while B is not. > > Also, handshake hashes are very hard to control to any significant degree (or > invoking HKDF with bad salt is the least of your worries). > > E.g. Suppose prf-hash is 256-bit MD5-equivalent-security. The handshake > security just breaks catastrophically against active attacks (passive attacks > are another matter). > >> - Another issue raised in recent email exchange is the way to merge the >> semi-static value g^xs (where s is the semi-static server's private key and x >> the ephemeral client's private key) with the ephemeral value g^xy. > > "the semi-static server's private key"??? There is no "the key". There's the old > semi-static key (which may not be available), and the new semi-static key. And > the two may or may not be the same key, and those keys may not even be available. > > Also, in certain conditions, not mixing in DH result with the old key actually > leads to an attack (mixing the new one does not help here). > > Also, I heard some implementers complaining about mixing the new one, and after > calculating the time penalty, I can easily understand (it is pretty sizable). > >> This is done by first extracting a key from g^xs as PRK1=HKDF-extract(0,g^xs) >> and then extracting PRK2=HKDF-extract(PRK1,g^xy). >> Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as a random >> oracle as needed in the proof of security. Then PRK2 is derived with salt=PRK2 >> for the following reason. If g^xs is not exposed (the typical case) then this >> HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially the less >> demanding property from HKDF). If g^xs is revealed by compromise of the >> server's semi static private key s (after the conclusion of the handshake, as >> in the forward-secrecy setting), then PRK1 is actually an authenticated random >> and non-secret salt so you use HKDF as a randomness extractor. >> In other words, each use of HKDF uses the minimal cryptographic assumption one >> can have depending on the context of derivation. > > If it is the new one, it is not properly authenticated (have I mentioned how nasty > even capturing the proper assumptions is?). > >> - Finally, there has been a long discussion related to the derivation of both >> secret and non-secret material (the latter for IVs). I can't say how this >> works with HSMs, PKCS11 or other standards, but from the cryptographic point >> of view doing this "mixed" derivation of secret and non-secret values is >> not a problem as long as HMAC is not broken as a PRF. > > Well, looks like that problem got sorted out (by getting the "HSM folks" to > actually state the actual requirements). > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Apr 24 23:16: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 BAF1C1B2A3E for ; Fri, 24 Apr 2015 23:16:18 -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_00=-1.9, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, 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 mBMwbdMI2x3O for ; Fri, 24 Apr 2015 23:16:18 -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 DF23C1B2A3D for ; Fri, 24 Apr 2015 23:16:17 -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 D9C3681881; Sat, 25 Apr 2015 09:16:15 +0300 (EEST) Date: Sat, 25 Apr 2015 09:16:15 +0300 From: Ilari Liusvaara To: Andrey Jivsov Message-ID: <20150425061615.GA29512@LK-Perkele-VII> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <20150425053458.GA28576@LK-Perkele-VII> <553B2D59.3030407@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <553B2D59.3030407@brainhub.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s__consensus=3A_adopt?= =?utf-8?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2015 06:16:18 -0000 On Fri, Apr 24, 2015 at 10:59:53PM -0700, Andrey Jivsov wrote: > On 04/24/2015 10:34 PM, Ilari Liusvaara wrote: > > Ilari beat me on this, but I also made this observation. In more details: > > According to intended use of HKDF, HKDF-Extract is this: > > HMS = HKDF-Extract( salt=0, IKM=g^xy ) > > Which is: > > A. HMAC( 0, g^xy ) = Hash( opad || Hash( ipad || g^xy ) ). > > The two invocations of the Hash() begin with hashing fixed values, so one > can re-write the A as > > A1: Hash1( Hash2( g^xy ) ), > > which can be rewritten as > > A2: Hash3( g^xy ) = Hash( opad || Hash( ipad || g^xy ) ) > > Therefore, HKDF-Extract( 0, g^xy ) should be viewed as deterministic hash of > g^xy and that's the only contribution of g^xy in HKDF. > > For comparison, TLS 1.2 does the following in the first step: > > B. Hash(g^xy ^ opad || Hash( (g^xy ^ ipad) || "master secret" + > ClientHello.random + ServerHello.random) ) ); > > It would be amusing to see a case when A2 is secure, while B is not. Actually, in TLS 1.2, if one uses FFDHE, or if one somehow manages to use excessively large ECC keys (most likely P-521 with SHA-256), then the g^xy is replaced by Hash(g^xy). Also, with extended master secret (needed to fix all sorts of security problems from lack of CRK): Hash(g^xy ^ opad || Hash( (g^xy ^ ipad) || "extended master secret" + handshake_hash) ) ); -Ilari From nobody Sat Apr 25 20:21: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 87E291B34CE for ; Sat, 25 Apr 2015 20:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 x68PxewgynKC for ; Sat, 25 Apr 2015 20:21:09 -0700 (PDT) Received: from mail-vn0-f48.google.com (mail-vn0-f48.google.com [209.85.216.48]) (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 9C22A1B34CD for ; Sat, 25 Apr 2015 20:21:09 -0700 (PDT) Received: by vnbg129 with SMTP id g129so8130448vnb.4 for ; Sat, 25 Apr 2015 20:21:08 -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 :subject:references:in-reply-to:content-type; bh=K+cAeVwCePgYlXmjHgkaMrPkJA/fjJvoKJ2sdrLQW8c=; b=BCydp02kLRm7jFPw75sGP62/FZJW6OYdPwPfsO1JgLsFErMTIMv1jUuP415ViXyEQx 9zxQ0n+7HL8bhvmy+g2luRS7AeIai+4boBoR/eeYpvOiOzqSzI8uPTuI9vl9+Hee04Zh 9CFp86VSHLqtfYUoij5YwbkrsgNPb9aRza3pux4lDda9uyEc+04VrR0MaM4SN3hTyp7C MRxik711XVNqrKKtIlbhuKTTiNByu3BldlqKcJs5ybAuZU4sQMKzliGu3jxzSQdIZTNs SCRrcAb7uu6DTSBQEXuzUd1F9/iYYoe80UyajjZ6941OjQTEFplipS6d4+7XpQxxBfm7 wt2Q== X-Gm-Message-State: ALoCoQk5pXDrprGz7sKlP3K2DIi6aqTyX20C/giRyzkptZwYIIABYE+ukUS3V/ZQHNJXJUQ3Q/+c X-Received: by 10.52.65.38 with SMTP id u6mr13235221vds.24.1430018468761; Sat, 25 Apr 2015 20:21:08 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id wp5sm14905730vdb.18.2015.04.25.20.21.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2015 20:21:08 -0700 (PDT) Message-ID: <553C59B2.6050000@nthpermutation.com> Date: Sat, 25 Apr 2015 23:21:22 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090704080308030002070500" Archived-At: 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, 26 Apr 2015 03:21:12 -0000 This is a multi-part message in MIME format. --------------090704080308030002070500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 4/24/2015 4:44 PM, Joseph Salowey wrote: > > > On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson > > wrote: > > On 24 April 2015 at 10:10, 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 . > > > You aren't being particularly precise about the process here. > > I believe that these were the two options that were most debated: > > a) nonce = zeroes(N_MIN) XOR counter > b) nonce = HKDF(...., N_MIN) XOR counter > > Did you mean the latter option? > > > [Joe] Yes, the later where the quantity XORed with the counter is > derived during the handshake. In general, APIs for hardware (and software) encryption are set up as init, multiple updates and finalize. The arguments to init are generally a handle pointing to the key, a selection of the encryption mode and the initialization parameters specific to that mode. The initialization parameters generally include material for the IV (obviously not used in ECB), and other mode specific items. For CCM, most implementations use the block formatting function described in appendix A of the NIST spec and that function uses as input to the initialization a "nonce" as well as information about the length of the AAD. All of the Init data is non-secret information (note that I said handle to key, and not key above - the handle is non-secret, the key material is secret) and must be shared implicitly or explicitly between sender and receiver. All of that is a long way of saying that making the nonce be some sort of output of the HKDF is probably a bad idea as the general use for a KDF is to produce secret key material. A zero session nonce combined with the message sequence number to form unique per-key value is acceptable cryptographically - at least for GCM and CCM. (and that's really the same thing as 0 XOR counter as far as I can tell). A randomly generated session nonce concatenated with the message sequence number to produce a message nonce is acceptable cryptographically and provides no less protection than generating a long session nonce and xor'ing the sequence number in to produce the message nonce. AFAICT b) provides no additional security over a). The security of CCM and GCM is NOT dependent on the secrecy of the IV/Nonce/sequence number, only in its uniqueness for a given key, and (b) appears to be trying to make the IV secret. Doing (b) will make it difficult to implement TLS using generic HSM functions as there will probably need to be some way of piping the secret output of HKDF to be the per message IV. So I'd prefer (a) - zero session nonce. If a random session nonce is required (why?), then instead use the impedance matching function (e.g. the HKDF-Extract or the equivalent) against the client and server randoms: session_nonce = LTRUNCATE (HMAC-HASH ("0", client_random | server_ random)); message_nonce = session_nonce | sequence_number Mike > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------090704080308030002070500 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 4/24/2015 4:44 PM, Joseph Salowey wrote:


On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 24 April 2015 at 10:10, Joseph Salowey <joe@salowey.net> 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 .


You aren't being particularly precise about the process here.

I believe that these were the two options that were most debated:

a) nonce = zeroes(N_MIN) XOR counter
b) nonce = HKDF(...., N_MIN) XOR counter

Did you mean the latter option?

[Joe] Yes, the later where the quantity XORed with the counter is derived during the handshake.

In general, APIs for hardware (and software) encryption are set up as init, multiple updates and finalize. The arguments to init are generally a handle pointing to the key, a selection of the encryption mode and the initialization parameters specific to that mode. The initialization parameters generally include material for the IV (obviously not used in ECB), and other mode specific items. For CCM, most implementations use the block formatting function described in appendix A of the NIST spec and that function uses as input to the initialization a "nonce" as well as information about the length of the AAD.

All of the Init data is non-secret information (note that I said handle to key, and not key above - the handle is non-secret, the key material is secret) and must be shared implicitly or explicitly between sender and receiver.

All of that is a long way of saying that making the nonce be some sort of output of the HKDF is probably a bad idea as the general use for a KDF is to produce secret key material.


A zero session nonce combined with the message sequence number to form unique per-key value is acceptable cryptographically - at least for GCM and CCM. (and that's really the same thing as 0 XOR counter as far as I can tell).


A randomly generated session nonce concatenated with the message sequence number to produce a message nonce is acceptable cryptographically and provides no less protection than generating a long session nonce and xor'ing the sequence number in to produce the message nonce.

AFAICT b) provides no additional security over a). The security of CCM and GCM is NOT dependent on the secrecy of the IV/Nonce/sequence number, only in its uniqueness for a given key, and (b) appears to be trying to make the IV secret.

Doing (b) will make it difficult to implement TLS using generic HSM functions as there will probably need to be some way of piping the secret output of HKDF to be the per message IV.


So I'd prefer (a) - zero session nonce. If a random session nonce is required (why?), then instead use the impedance matching function (e.g. the HKDF-Extract or the equivalent) against the client and server randoms:

session_nonce = LTRUNCATE (HMAC-HASH ("0", client_random | server_ random));

message_nonce = session_nonce | sequence_number


Mike






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

--------------090704080308030002070500-- From nobody Sat Apr 25 20:47: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 DC48D1B34F4 for ; Sat, 25 Apr 2015 20:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 5C__m8e0ie5A for ; Sat, 25 Apr 2015 20:47:14 -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 B34291B34F3 for ; Sat, 25 Apr 2015 20:47:13 -0700 (PDT) Received: by wiun10 with SMTP id n10so56950578wiu.1 for ; Sat, 25 Apr 2015 20:47:12 -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=PntXWEyrkfCdixlfyuXpaJf3wleVhzrr4A6fGGCZY/A=; b=ziWFz/jiVORU8TN7ndIws2ktGn++w8/5AwuGtWYIR/kTD3O3qBMFPdNatCKVuVuEuZ P4dslaXlNqsy0044Ga8BLsM9cD1mqPyjispBChAtbGABHPlryIPej9s+WDeutQfadBVi cV+sas6PKGG6sB29O/dyyU4oCihW53jGdtojwFDPBCy2Jo/uJdgfjWxJB+AGrz4M3lNQ jaJ8slEGQCFS9uHcBCCnm1f0zyQoh7lVsK2ejjXj3UERmPyMOtsyt+8ff9KUMfQ/uttp Pi1He5rBgeDASfQO/BeoSgNhGgfCkyS6kRF1/cRBhou3geH4SDMzUAMWrLV0vspzw63W WJZA== X-Received: by 10.180.86.234 with SMTP id s10mr9439222wiz.50.1430020032523; Sat, 25 Apr 2015 20:47:12 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id dz4sm5684794wib.17.2015.04.25.20.47.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Apr 2015 20:47:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B6F81507-1420-4B72-A849-0BAB99F552E3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <553C59B2.6050000@nthpermutation.com> Date: Sun, 26 Apr 2015 06:47:09 +0300 Message-Id: <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> References: <553C59B2.6050000@nthpermutation.com> To: Michael StJohns 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, 26 Apr 2015 03:47:16 -0000 --Apple-Mail=_B6F81507-1420-4B72-A849-0BAB99F552E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Apr 26, 2015, at 6:21 AM, Michael StJohns = wrote: >=20 > On 4/24/2015 4:44 PM, Joseph Salowey wrote: >>=20 >>=20 >> On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson = > wrote: >> On 24 April 2015 at 10:10, 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 . >>=20 >>=20 >> You aren't being particularly precise about the process here. >>=20 >> I believe that these were the two options that were most debated: >>=20 >> a) nonce =3D zeroes(N_MIN) XOR counter >> b) nonce =3D HKDF(...., N_MIN) XOR counter >>=20 >> Did you mean the latter option? >>=20 >> [Joe] Yes, the later where the quantity XORed with the counter is = derived during the handshake. =20 >=20 > In general, APIs for hardware (and software) encryption are set up as = init, multiple updates and finalize. The arguments to init are = generally a handle pointing to the key, a selection of the encryption = mode and the initialization parameters specific to that mode. The = initialization parameters generally include material for the IV = (obviously not used in ECB), and other mode specific items. For CCM, = most implementations use the block formatting function described in = appendix A of the NIST spec and that function uses as input to the = initialization a "nonce" as well as information about the length of the = AAD. >=20 > All of the Init data is non-secret information (note that I said = handle to key, and not key above - the handle is non-secret, the key = material is secret) and must be shared implicitly or explicitly between = sender and receiver. >=20 > All of that is a long way of saying that making the nonce be some sort = of output of the HKDF is probably a bad idea as the general use for a = KDF is to produce secret key material. >=20 >=20 > A zero session nonce combined with the message sequence number to form = unique per-key value is acceptable cryptographically - at least for GCM = and CCM. (and that's really the same thing as 0 XOR counter as far as = I can tell). >=20 >=20 > A randomly generated session nonce concatenated with the message = sequence number to produce a message nonce is acceptable = cryptographically and provides no less protection than generating a long = session nonce and xor'ing the sequence number in to produce the message = nonce.=20 >=20 > AFAICT b) provides no additional security over a). The security of = CCM and GCM is NOT dependent on the secrecy of the IV/Nonce/sequence = number, only in its uniqueness for a given key, and (b) appears to be = trying to make the IV secret. >=20 > Doing (b) will make it difficult to implement TLS using generic HSM = functions as there will probably need to be some way of piping the = secret output of HKDF to be the per message IV. I don=92t see why. Make the 128- or 256-bit key one part of the keying = material, and the 96-bit quantity another part of the keying material. A = single handle references a structure containing both. Now you pass the encryption function the handle, the data to be = encrypted (and protected) and a message counter. The function (hardware = or software) converts the counter into a nonce by XOR-ing with the = quantity, and proceeds from there. There is no reason not to treat the = 96-bit quantity as anything but secret. Doesn=92t this solve you API issue? Yoav --Apple-Mail=_B6F81507-1420-4B72-A849-0BAB99F552E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 26, 2015, at 6:21 AM, Michael StJohns <msj@nthpermutation.com> wrote:

=20 =20
On 4/24/2015 4:44 PM, Joseph Salowey wrote:


On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 24 April 2015 at 10:10, Joseph Salowey <joe@salowey.net> 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 .


You aren't being particularly precise about the process here.

I believe that these were the two options that were most debated:

a)  nonce =3D zeroes(N_MIN) XOR counter
b)  nonce =3D HKDF(...., N_MIN) XOR counter

Did you mean the latter option?

[Joe] Yes, the later where the = quantity XORed with the counter is derived during the handshake.  =

In general, APIs for hardware (and software) encryption are set up as init, multiple updates and finalize.  The arguments to init = are generally a handle pointing to the key, a selection of the encryption mode and the initialization parameters specific to that mode.  The initialization parameters generally include material = for the IV (obviously not used in ECB), and other mode specific = items.  For CCM, most implementations use the block formatting function described in appendix A of the NIST spec and that function uses as input to the initialization a "nonce" as well as information about the length of the AAD.

All of the Init data is non-secret information (note that I said handle to key, and not key above - the handle is non-secret, the key material is secret) and must be shared implicitly or explicitly between sender and receiver.

All of that is a long way of saying that making the nonce be some sort of output of the HKDF is probably a bad idea as the general use for a KDF is to produce secret key material.


A zero session nonce combined with the message sequence number to form unique per-key value is acceptable cryptographically - at least for GCM and CCM.    (and that's really the same thing = as 0 XOR counter as far as I can tell).


A randomly generated session nonce concatenated with the message sequence number to produce a message nonce is acceptable cryptographically and provides no less protection than generating a long session nonce and xor'ing the sequence number in to produce the message nonce.

AFAICT b) provides no additional security over a).   The = security of CCM and GCM is NOT dependent on the secrecy of the IV/Nonce/sequence number, only in its uniqueness for a given key, and (b) appears to be trying to make the IV secret.

Doing (b) will make it difficult to implement TLS using generic HSM functions as there will probably need to be some way of piping the secret output of HKDF to be the per message IV.

I don=92t = see why. Make the 128- or 256-bit key one part of the keying material, = and the 96-bit quantity another part of the keying material. A single = handle references a structure containing both.

Now you pass the encryption function the handle, = the data to be encrypted (and protected) and a message counter. The = function (hardware or software) converts the counter into a nonce by = XOR-ing with the quantity, and proceeds from there. There is no reason = not to treat the 96-bit quantity as anything but secret.

Doesn=92t this solve you API issue?

Yoav


= --Apple-Mail=_B6F81507-1420-4B72-A849-0BAB99F552E3-- From nobody Sun Apr 26 11:00: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 6FEDB1ACAD4 for ; Sun, 26 Apr 2015 11:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 uAQ_i3fs0dtM for ; Sun, 26 Apr 2015 11:00:51 -0700 (PDT) Received: from mail-vn0-f42.google.com (mail-vn0-f42.google.com [209.85.216.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739C61AC443 for ; Sun, 26 Apr 2015 11:00:51 -0700 (PDT) Received: by vnbg190 with SMTP id g190so9340866vnb.12 for ; Sun, 26 Apr 2015 11:00: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=hObKgwCiJRftNyiwatwdO7v81JhqIq8tfha9KFCBFQw=; b=JEVA04NM3EcnxKzP88PhRUkLgqutqAoJ25yXx65dpnSFtTSEsNrsVEIF05SaHTV9S5 Lheg8NHfnQ8YJlzUdhP1GjSfNxM8cZzDjxgwxKy0iDf8c8wk1g4+6WuX5KJsbkNgDGNr z9yBWvXcYnsrQckbx0onRVV8Ldv0ta4XqW2BZ9tyoHczq+CdGgyD2Z7MYEffqCyc/6O7 Vc52NXQlvjci2zOe/pzebYsmLdrxh40w1W7AfSmOS712IQZIVGbR9mM13V12xoNgEEDD f4l2B6F9wKL8IBgJoKNjfLAkEYP2akmYDssnrSV+QJcd9/xcgcmxUDQdd0L5Y7JwNfgn g7UA== X-Gm-Message-State: ALoCoQlhL9B4qlgIl8VqJ0vB2ucYICThWSU2YhvbrwqxGStFNW2alj+jXHIpK6/owir7kWZBWyvK X-Received: by 10.52.163.202 with SMTP id yk10mr18920129vdb.76.1430071250507; Sun, 26 Apr 2015 11:00:50 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id ug16sm19416111vdb.14.2015.04.26.11.00.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 11:00:49 -0700 (PDT) Message-ID: <553D27D0.7040209@nthpermutation.com> Date: Sun, 26 Apr 2015 14:00:48 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yoav Nir References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> In-Reply-To: <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> Content-Type: multipart/alternative; boundary="------------030207000909070506070906" 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, 26 Apr 2015 18:00:53 -0000 This is a multi-part message in MIME format. --------------030207000909070506070906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 4/25/2015 11:47 PM, Yoav Nir wrote: > >> On Apr 26, 2015, at 6:21 AM, Michael StJohns > > wrote: >> >> On 4/24/2015 4:44 PM, Joseph Salowey wrote: >>> >>> >>> On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson >>> > wrote: >>> >>> On 24 April 2015 at 10:10, 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 . >>> >>> >>> You aren't being particularly precise about the process here. >>> >>> I believe that these were the two options that were most debated: >>> >>> a) nonce = zeroes(N_MIN) XOR counter >>> b) nonce = HKDF(...., N_MIN) XOR counter >>> >>> Did you mean the latter option? >>> >>> >>> [Joe] Yes, the later where the quantity XORed with the counter is >>> derived during the handshake. >> >> In general, APIs for hardware (and software) encryption are set up as >> init, multiple updates and finalize. The arguments to init are >> generally a handle pointing to the key, a selection of the encryption >> mode and the initialization parameters specific to that mode. The >> initialization parameters generally include material for the IV >> (obviously not used in ECB), and other mode specific items. For CCM, >> most implementations use the block formatting function described in >> appendix A of the NIST spec and that function uses as input to the >> initialization a "nonce" as well as information about the length of >> the AAD. >> >> All of the Init data is non-secret information (note that I said >> handle to key, and not key above - the handle is non-secret, the key >> material is secret) and must be shared implicitly or explicitly >> between sender and receiver. >> >> All of that is a long way of saying that making the nonce be some >> sort of output of the HKDF is probably a bad idea as the general use >> for a KDF is to produce secret key material. >> >> >> A zero session nonce combined with the message sequence number to >> form unique per-key value is acceptable cryptographically - at least >> for GCM and CCM. (and that's really the same thing as 0 XOR >> counter as far as I can tell). >> >> >> A randomly generated session nonce concatenated with the message >> sequence number to produce a message nonce is acceptable >> cryptographically and provides no less protection than generating a >> long session nonce and xor'ing the sequence number in to produce the >> message nonce. >> >> AFAICT b) provides no additional security over a). The security of >> CCM and GCM is NOT dependent on the secrecy of the IV/Nonce/sequence >> number, only in its uniqueness for a given key, and (b) appears to be >> trying to make the IV secret. >> >> Doing (b) will make it difficult to implement TLS using generic HSM >> functions as there will probably need to be some way of piping the >> secret output of HKDF to be the per message IV. > > I dont see why. Make the 128- or 256-bit key one part of the keying > material, and the 96-bit quantity another part of the keying material. > A single handle references a structure containing both. So what you're suggesting is requiring each cipher mode that uses TLS have both the generic - pass in the IV etc - and the TLS specific - pass in a handle to material that has to be retained within the HSM and managed in some way to make sure that you delete when your done? Seriously - no. You're actually going to make it impossible to use TLS1.3 with generic hardware modules. > > Now you pass the encryption function the handle, the data to be > encrypted (and protected) and a message counter. The function > (hardware or software) converts the counter into a nonce by XOR-ing > with the quantity, and proceeds from there. There is no reason not to > treat the 96-bit quantity as anything but secret. There is no reason to treat the 96 bit quantity as secret and no one else does. TLS should use generic interfaces rather than inventing stuff that can't. > > Doesnt this solve you API issue? No. > > Yoav > > --------------030207000909070506070906 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 4/25/2015 11:47 PM, Yoav Nir wrote:

On Apr 26, 2015, at 6:21 AM, Michael StJohns <msj@nthpermutation.com> wrote:

On 4/24/2015 4:44 PM, Joseph Salowey wrote:


On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 24 April 2015 at 10:10, Joseph Salowey <joe@salowey.net> 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 .


You aren't being particularly precise about the process here.

I believe that these were the two options that were most debated:

a) nonce = zeroes(N_MIN) XOR counter
b) nonce = HKDF(...., N_MIN) XOR counter

Did you mean the latter option?

[Joe] Yes, the later where the quantity XORed with the counter is derived during the handshake.

In general, APIs for hardware (and software) encryption are set up as init, multiple updates and finalize. The arguments to init are generally a handle pointing to the key, a selection of the encryption mode and the initialization parameters specific to that mode. The initialization parameters generally include material for the IV (obviously not used in ECB), and other mode specific items. For CCM, most implementations use the block formatting function described in appendix A of the NIST spec and that function uses as input to the initialization a "nonce" as well as information about the length of the AAD.

All of the Init data is non-secret information (note that I said handle to key, and not key above - the handle is non-secret, the key material is secret) and must be shared implicitly or explicitly between sender and receiver.

All of that is a long way of saying that making the nonce be some sort of output of the HKDF is probably a bad idea as the general use for a KDF is to produce secret key material.


A zero session nonce combined with the message sequence number to form unique per-key value is acceptable cryptographically - at least for GCM and CCM. (and that's really the same thing as 0 XOR counter as far as I can tell).


A randomly generated session nonce concatenated with the message sequence number to produce a message nonce is acceptable cryptographically and provides no less protection than generating a long session nonce and xor'ing the sequence number in to produce the message nonce.

AFAICT b) provides no additional security over a). The security of CCM and GCM is NOT dependent on the secrecy of the IV/Nonce/sequence number, only in its uniqueness for a given key, and (b) appears to be trying to make the IV secret.

Doing (b) will make it difficult to implement TLS using generic HSM functions as there will probably need to be some way of piping the secret output of HKDF to be the per message IV.

I dont see why. Make the 128- or 256-bit key one part of the keying material, and the 96-bit quantity another part of the keying material. A single handle references a structure containing both.

So what you're suggesting is requiring each cipher mode that uses TLS have both the generic - pass in the IV etc - and the TLS specific - pass in a handle to material that has to be retained within the HSM and managed in some way to make sure that you delete when your done?

Seriously - no.

You're actually going to make it impossible to use TLS1.3 with generic hardware modules.



Now you pass the encryption function the handle, the data to be encrypted (and protected) and a message counter. The function (hardware or software) converts the counter into a nonce by XOR-ing with the quantity, and proceeds from there. There is no reason not to treat the 96-bit quantity as anything but secret.

There is no reason to treat the 96 bit quantity as secret and no one else does.

TLS should use generic interfaces rather than inventing stuff that can't.



Doesnt this solve you API issue?

No.


Yoav



--------------030207000909070506070906-- From nobody Sun Apr 26 11:20: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 CD1E31B2C07 for ; Sun, 26 Apr 2015 11:20:30 -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 r_PTLUBvf4y6 for ; Sun, 26 Apr 2015 11:20:29 -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 D83421B2C09 for ; Sun, 26 Apr 2015 11:20:28 -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 4D6D9817E2; Sun, 26 Apr 2015 21:20:26 +0300 (EEST) Date: Sun, 26 Apr 2015 21:20:25 +0300 From: Ilari Liusvaara To: Michael StJohns Message-ID: <20150426182025.GA3549@LK-Perkele-VII> References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <553D27D0.7040209@nthpermutation.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara 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, 26 Apr 2015 18:20:30 -0000 On Sun, Apr 26, 2015 at 02:00:48PM -0400, Michael StJohns wrote: > On 4/25/2015 11:47 PM, Yoav Nir wrote: > > > >>On Apr 26, 2015, at 6:21 AM, Michael StJohns >>> wrote: > > You're actually going to make it impossible to use TLS1.3 with generic > hardware modules. Define "generic hardware module". What key derivation operations it supports? Both secret->secret and secret->public (and yes, the latter _will_ be needed). > >Now you pass the encryption function the handle, the data to be encrypted > >(and protected) and a message counter. The function (hardware or software) > >converts the counter into a nonce by XOR-ing with the quantity, and > >proceeds from there. There is no reason not to treat the 96-bit quantity > >as anything but secret. > > There is no reason to treat the 96 bit quantity as secret and no one else > does. Oh, except SSH. The session nonce is 96 bits and secret. (To lesser extent, IPSEC, there the session nonce is 32 bits and secret). > TLS should use generic interfaces rather than inventing stuff that can't. Well, given that one needs to derive public data out of secret keys, that sure can also derive per-connection IVs out of secrets. -Ilari From nobody Sun Apr 26 11:44: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 A09C61B2C45 for ; Sun, 26 Apr 2015 11:44:46 -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 7whwP-tsdfo8 for ; Sun, 26 Apr 2015 11:44:45 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (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 15D851B2C41 for ; Sun, 26 Apr 2015 11:44:45 -0700 (PDT) Received: by obcux3 with SMTP id ux3so69357829obc.2 for ; Sun, 26 Apr 2015 11:44: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1mdzs3RaI+mtf0mmHNrtUgKHPdKbnUDByzL6w801/2Y=; b=IknjhXtGf6redtT+r/wOHo3KeW30Pwifd1ojwG7YYtdkJjWRh1quI4+bdog5PsamJ9 6TuAFKbvCC80RTBu3LHgaRb4ZF16iWqPfujZkcHSxphSCZqPWz/LV9KV7XdkVUU7vcXP rMoXuMnLLYa7mrwyNU8eFGVBHAJ42eVlt5uGqeT6n2SNwpvsrAZdFElWXtZkZUTqeDTc my3Rxn1eA5ST6JKNvrOpg2ui6banyn2/9h+zz4+Z3dOQAtNXnGOa/acSNUcCfZ4jjdDz jq1/TiB03AYMzq9oJW5ZKjhd3oRX8cra1Vq9V0aRhY1CRulR+/dQbbehoBbkF6nHKcBc +TGA== X-Gm-Message-State: ALoCoQmjl1cxCrRZ7dKhGhHkrxgmeLeDGmbYCKPZyjBkKkMTgzzme9xqeB0Vd9Bw4XeXdlCvxtwt MIME-Version: 1.0 X-Received: by 10.60.94.165 with SMTP id dd5mr7055473oeb.53.1430073884426; Sun, 26 Apr 2015 11:44:44 -0700 (PDT) Received: by 10.76.90.97 with HTTP; Sun, 26 Apr 2015 11:44:44 -0700 (PDT) In-Reply-To: <553D27D0.7040209@nthpermutation.com> References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> Date: Sun, 26 Apr 2015 08:44:44 -1000 Message-ID: From: Brian Smith To: Michael StJohns Content-Type: multipart/alternative; boundary=089e01228218e258770514a505f0 Archived-At: Cc: "" 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, 26 Apr 2015 18:44:46 -0000 --089e01228218e258770514a505f0 Content-Type: text/plain; charset=UTF-8 Michael StJohns wrote: > So what you're suggesting is requiring each cipher mode that uses TLS have > both the generic - pass in the IV etc - and the TLS specific - pass in a > handle to material that has to be retained within the HSM and managed in > some way to make sure that you delete when your done? > No, it isn't TLS-specific. As others noted, SSH can use it too. And, future protocols can use it as well. Regardless of the particulars if the TLS discussion, the pass-in-the-IV approach is terrible because the module cannot guarantee the uniqueness of the IVs. So, actually, everybody should be using the pass-in-the-handle-to-material-that-can-be-*PROPERLY*-maintained-by-the-module approach. The FIPS 140 implementation guidance agrees, as far as I understand it. > You're actually going to make it impossible to use TLS1.3 with generic > hardware modules. > No, one can still create a generic module that doesn't know anything about TLS, that can provide this type of interface. And, one should do so. > There is no reason to treat the 96 bit quantity as secret and no one else > does. > Others already refuted the "no one else does." As for there being "no reason to treat the 96 bit quantity as secret," there's also no reason to make it public. The working group already decided when there is no compelling reason to make a handshake value public, then it should be made private. (The charter says "Develop a mode that encrypts as much of the handshake as is possible to reduce the amount of observable data to both passive and active attackers.") Further, I believe you actually mean "there is no *known* reason" to treat the IV as secret. That doesn't mean there aren't *unknown* reasons for doing so. > TLS should use generic interfaces rather than inventing stuff that can't. > Again, this can use a generic interface. It can't use the generic interfaces that are currently exposed by certain crypto modules, but that's a problem with those crypto modules' interfaces, not with what is being proposed here. Cheers, Brian --089e01228218e258770514a505f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mich= ael StJohns <msj@nthpermutation.com> wrote:
=20 =20 =20
So what you're suggesting is requiring each= cipher mode that uses TLS have both the generic - pass in the IV etc - and the TLS specific - pass in a handle to material that has to be retained within the HSM and managed in some way to make sure that you delete when your done?

No, it isn't TLS-specific. As others noted, SSH can use it too. And, = future protocols can use it as well. Regardless of the particulars if the T= LS discussion, the pass-in-the-IV approach is terrible because the module c= annot guarantee the uniqueness of the IVs. So, actually, everybody should b= e using the pass-in-the-handle-to-material-that-can-be-*PROPERLY*-maintaine= d-by-the-module approach. The FIPS 140 implementation guidance agrees, as f= ar as I understand it.
=C2=A0
You're actually going to make it impossible to use TLS1.3= with generic hardware modules.
No, one can still create a generic module that doesn't know= anything about TLS, that can provide this type of interface. And, one shou= ld do so.
=C2=A0
There is no reason to treat the 96 bit quantity as secret a= nd no one else does.

Others already ref= uted the "no one else does." As for there being "no reason t= o treat the 96 bit quantity as secret," there's also no reason to = make it public. The working group already decided when there is no compelli= ng reason to make a handshake value public, then it should be made private.= (The charter says=C2=A0"Develop a mode that encrypts as much of the h= andshake as is possible to reduce the amount of observable data to both pas= sive and active attackers.")

Further, I belie= ve you actually mean "there is no *known* reason" to treat the IV= as secret. That doesn't mean there aren't *unknown* reasons for do= ing so.
=C2=A0
TLS should use generic interfaces rather than inventing= stuff that can't.

Again, this can use a = generic interface. It can't use the generic interfaces that are current= ly exposed by certain crypto modules, but that's a problem with those c= rypto modules' interfaces, not with what is being proposed here.
<= div>
Cheers,
Brian
--089e01228218e258770514a505f0-- From nobody Sun Apr 26 11:59: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 074201B2AAA for ; Sun, 26 Apr 2015 11:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.601 X-Spam-Level: * X-Spam-Status: No, score=1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHqAw_l51RoK for ; Sun, 26 Apr 2015 11:59:01 -0700 (PDT) Received: from mail-vn0-f41.google.com (mail-vn0-f41.google.com [209.85.216.41]) (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 2834D1B2C8D for ; Sun, 26 Apr 2015 11:59:01 -0700 (PDT) Received: by vnbf1 with SMTP id f1so9470332vnb.5 for ; Sun, 26 Apr 2015 11:59: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=TuJzslATjBjJxXdORswzJYmHuyrxVitXqcPgCEgF/gc=; b=bHv2lw9Il+sn4qSsuKFFmrTIcH5qiUmR9k8uv2qhxHJMka5Zv1Z8JCLpjrollP5nCn gRtNuCrtf8G0FLLWqbFVn86ZOBOGQAZ8DBF7Zs4NXfC1vOK+QFSPvB5Pk7BcrHRDZ8lq 8DJ4plrNGH/OyGjbQiQuThtXeMLhH+1SWNf7dmHlsH0J/8Nrze+eNGw2tYArpkSB0Cjy r4UHqS4WIk/HKnypE0jVMrVOLhBUWkXmQKvxOZfo7X1Kl89jSeIxGghHlRCG0RilyNhh 5dy2ZSozn7ftgH0ePq3YR1NXqfxNGuhAMxQiMx7e68X0vU06hVWvSyyoZJsJrPvemQdp HkQQ== X-Gm-Message-State: ALoCoQmSsVFSt0xKoA9b4AR+8uet9Ohnsq3L1nJbO2qGWcIC7/QBQN3DpEsDKBjGG94EA+HQupK2 X-Received: by 10.52.176.103 with SMTP id ch7mr19592275vdc.68.1430074740156; Sun, 26 Apr 2015 11:59:00 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id fi9sm19737259vdb.27.2015.04.26.11.58.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 11:58:59 -0700 (PDT) Message-ID: <553D3572.6040408@nthpermutation.com> Date: Sun, 26 Apr 2015 14:58:58 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050805020400080402020009" Archived-At: Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2015 18:59:04 -0000 This is a multi-part message in MIME format. --------------050805020400080402020009 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Inline below. On 4/24/2015 5:31 PM, Hugo Krawczyk wrote: > > Here are a few clarifications regarding HKDF and its use in TLS 1.3 in > response > to recent emails (including those under the "HSM-friendly Key Computation" > thread). I will not touch on anything specific to HSM or PKCS11 since > I know > little about these and the recent exchange on these issues has not > helped me > understanding these things any better (but rather confuse me more). > > Let me start with the issue of whether we should be using the > HKDF-Extract and > HKDF-Expand separately or only use HKDF as a single function (which > internally > operates HKDF-Extract and HKDF-Expand). There is an obvious advantage > for the > latter approach (single function) as it deals with HKDF as a black box. > But there are also advantages to calling these two components > separately, and > TLS 1.3 provides some good examples for that. First, HKDF is built to > output as > many keys as needed from a single HKDF operation, but in TLS we are > deriving > multiple keys from the same keying material through separate > applications of the > expand part. In such a case it is more natural to apply extract once > and apply > expand several times (with different info fields!). For example, > Master Secret > is derived using a single Extract operation but it is then used in three > different Expand operations for deriving other keys (application > traffic keys, > export master secret, and resumption master secret). Second, when one > starts with > a strong key then the Extract step can be skipped making it convenient > to be > able to call Expand directly. Third, it is convenient to call Expand > directly as > a PRF for computing the Finished message. Lastly, and not least, it > makes the > key derivation logic more explicit which helps conveying the rationale > of each > operation and helps those analyzing the protocol (now and in the future). What you're doing as far as I can tell is optimizing implementation at the cost of requiring special interfaces. One of the ways we've gotten to the point where TLS key material can't actually be kept secret in an HSM is by generalizing the concept of a PRF into a KDF and a MAC. What we need to do is have a MAC function and a KDF function and understand what the inputs to those are. TLS1.2 uses the Master secret as a key for both the MAC and KDF functions and that needs to change. Those can't be the same key - and hence your comment about using the same master secret for different derives becomes problematic especially if one of the outputs is to an exporter. Internally, an HSM MAY choose to retain the output of the extract phase as cached material (and in fact taking the master secret, doing the impedance match of the extract phase and replacing the master secret with the reduction still pointed to the master secret handle may be what a particular implementation does). But that's an implementation discussion, not a KDF input/output discussion. > > My recommendation is to keep the Extract and Expand separation for the > moment, > in particular due to the last point, so we can see more clearly the > logic while > still setting the missing details of the protocol. When the whole > picture is > clear we can revisit this point. > > On other issues: > > - This should be obvious but worth repeating: All calls to HKDF-Expand > MUST use > a non-empty info field binding the derived key(s) to a unique > context (in the > case of TLS this is usually a label and a cumulative session-hash). All calls to HKDF *should* use a non-empty label and context field, but that's tied more to the specific use than anything else. This isn't something that needs to be enforced by the security module as the crypto will cause different streams to be generated with different labels and contexts. Except for the problem of the Length term. Same label and context but with different output lengths will have the same prefixed key stream. > > - It was suggested that the length of derived keys should be part of > the input > to key expansion. If desired, this length can be entered through the > info > field of HKDF but I would be very careful not to derive two > different keys > where the only difference in the 'info' values is the key length. If > the two > keys happen to be of the same length one would end up with two keys > that are > identical. > The term you use in your paper and the RFC is T(N) = HMAC-Hash(PRK, T(N-1) | info | N) where N is expressed as a single octet in the concatenation operation. You can include the length term in info, but it won't be enforced by the HSM and depending on the format of the INFO field could actually be spoofed as this is all user supplied info that isn't known to be related to the actual desired output length. Instead HKDF should be updated to: T(N) = HMAC-Hash (PRK, T(N-1) | info | N | L) where L is the number of bits of desired key stream expressed as a UINT32 in NBO *is* enforceable by the HSM as it is a known field (size and position). NIST SP800-56C (which was standardized after the RFC and references your paper) describes the equivalent of your extract phase and then refers to SP800-108 and allows any of those to be used in the expansion phase. ALL of the possible alternatives - counter, feed back (and the evil double pipeline) include the length term in the per-block expansion. E.g. the feedback expansion uses: K(i) := PRF (KI, K(i-1) {|| [i]2 }|| Label || 0x00 || Context || [L]2) Where PRF is equivalent to your HMAC-HASH, KI is the PRK, [i]2 is the same as N, "Label || 0x00 || context" is equivalent to info and L[2] is the length of the desired output. HKDF is equivalent to NISTSP800-56C with an expansion phase of NIST SP800-108, section 5.2 where the length of i is a single octet, where the ordering of the terms is slightly different and where the L term is omitted. The inclusion of L as a mandatory term in the expansion means that any change in L changes the entire key stream. That is NOT the case with HKDF as defined in the RFC. See section 7.5 of SP800-108 for a discussion of key separation especially paragraph (2) and why this is important. > - One of the emails raises the issue of using random salt, as > recommended by RFC > 5869. Note that the RFC recommendation also indicates that the salt > value > should be something that is authenticated during the protocol, or > otherwise it > can be selected by the adversary. This authentication needs to happen > independently of the key being derived using this salt. For example, one > should be careful not to incur in a circular logic, e.g. deriving a key > mackey=HKDF(salt, info) and then using mackey to authenticate the > salt by > computing MAC(mackey, salt). This is why the proposed TLS 1.3 key > derivation > scheme does not use nonces as salt. I believe that is the correct approach. > > - Someone said: "In an ideal world we would all use the same KDFs > rather than > inventing a new one for each protocol." That was me. But what I said was that we should use standard KDFs, not reinvent new ones. > This was exactly the goal of HKDF, > namely, provide a single KDF that can serve different protocols, > requirements > and settings. The interested reader can consult my Crypto 2010 paper > https://eprint.iacr.org/2010/264 > for a very detailed treatment of key derivation in general and HKDF in > particular,and why this one design fits many different uses. TLS 1.3 > is a > perfect demonstration of the versatility of HKDF as it is used as a > random > oracle, randomness extractor and PRF, depending on the key material > being > derived. See the next item for an example. Given SP800-108 and SP800-56C were published before your paper and the RFC and have pretty much identical math (except as I noted), why shouldn't we use those cites instead of the RFC? E.g. is there any cryptographic improvement in RFC5869 vs the other two? > > - Another issue raised in recent email exchange is the way to merge the > semi-static value g^xs (where s is the semi-static server's private > key and x > the ephemeral client's private key) with the ephemeral value g^xy. > This is done by first extracting a key from g^xs as > PRK1=HKDF-extract(0,g^xs) > and then extracting PRK2=HKDF-extract(PRK1,g^xy). > Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as > a random > oracle as needed in the proof of security. Then PRK2 is derived with > salt=PRK2 > for the following reason. If g^xs is not exposed (the typical case) > then this > HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially > the less > demanding property from HKDF). If g^xs is revealed by compromise of the > server's semi static private key s (after the conclusion of the > handshake, as > in the forward-secrecy setting), then PRK1 is actually an > authenticated random > and non-secret salt so you use HKDF as a randomness extractor. > In other words, each use of HKDF uses the minimal cryptographic > assumption one > can have depending on the context of derivation. > > - Finally, there has been a long discussion related to the derivation > of both > secret and non-secret material (the latter for IVs). I can't say how > this > works with HSMs, PKCS11 or other standards, but from the > cryptographic point > of view doing this "mixed" derivation of secret and non-secret > values is not a > problem as long as HMAC is not broken as a PRF. Umm.... I don't actually understand what you said here. The issue is that you can't use the same key for different purposes if you want to enforce key security. Even though the underlying construct for a KDF is an HMAC function, if you can ensure - in an enforceable manner - that a master secret can only be used for key expansion and an integrity key is only used for a MAC function (including the HMAC over data) and that pseudo-random data does not depend on either of these keys (i.e. they are cryptographic isolated) then you can build an HSM that can actually do its job. There are other related issues (e.g. the outputs of a KDF getting tagged with appropriate key types, lengths and exportability). All that means is that you want three different functions: KDF (key expansion), MAC (finished message signature) and RBG (IV/Nonce production), and that you enforce the type of inputs to them. The underlying cryptographic constructs can be the same or similar, but we need to stop conflating them as needing to be identical. Mike > > Hugo > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------050805020400080402020009 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Inline below.


On 4/24/2015 5:31 PM, Hugo Krawczyk wrote:

Here are a few clarifications regarding HKDF and its use in TLS 1.3 in response
to recent emails (including those under the "HSM-friendly Key Computation"
thread). I will not touch on anything specific to HSM or PKCS11 since I know
little about these and the recent exchange on these issues has not helped me
understanding these things any better (but rather confuse me more).

Let me start with the issue of whether we should be using the HKDF-Extract and
HKDF-Expand separately or only use HKDF as a single function (which internally
operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for the
latter approach (single function) as it deals with HKDF as a black box.
But there are also advantages to calling these two components separately, and
TLS 1.3 provides some good examples for that. First, HKDF is built to output as
many keys as needed from a single HKDF operation, but in TLS we are deriving
multiple keys from the same keying material through separate applications of the
expand part. In such a case it is more natural to apply extract once and apply
expand several times (with different info fields!). For example, Master Secret
is derived using a single Extract operation but it is then used in three
different Expand operations for deriving other keys (application traffic keys,
export master secret, and resumption master secret). Second, when one starts with
a strong key then the Extract step can be skipped making it convenient to be
able to call Expand directly. Third, it is convenient to call Expand directly as
a PRF for computing the Finished message. Lastly, and not least, it makes the
key derivation logic more explicit which helps conveying the rationale of each
operation and helps those analyzing the protocol (now and in the future).

What you're doing as far as I can tell is optimizing implementation at the cost of requiring special interfaces.

One of the ways we've gotten to the point where TLS key material can't actually be kept secret in an HSM is by generalizing the concept of a PRF into a KDF and a MAC. What we need to do is have a MAC function and a KDF function and understand what the inputs to those are.

TLS1.2 uses the Master secret as a key for both the MAC and KDF functions and that needs to change. Those can't be the same key - and hence your comment about using the same master secret for different derives becomes problematic especially if one of the outputs is to an exporter.

Internally, an HSM MAY choose to retain the output of the extract phase as cached material (and in fact taking the master secret, doing the impedance match of the extract phase and replacing the master secret with the reduction still pointed to the master secret handle may be what a particular implementation does). But that's an implementation discussion, not a KDF input/output discussion.




My recommendation is to keep the Extract and Expand separation for the moment,
in particular due to the last point, so we can see more clearly the logic while
still setting the missing details of the protocol. When the whole picture is
clear we can revisit this point.

On other issues:

- This should be obvious but worth repeating: All calls to HKDF-Expand MUST use
a non-empty info field binding the derived key(s) to a unique context (in the
case of TLS this is usually a label and a cumulative session-hash).

All calls to HKDF *should* use a non-empty label and context field, but that's tied more to the specific use than anything else. This isn't something that needs to be enforced by the security module as the crypto will cause different streams to be generated with different labels and contexts.

Except for the problem of the Length term. Same label and context but with different output lengths will have the same prefixed key stream.

- It was suggested that the length of derived keys should be part of the input
to key expansion. If desired, this length can be entered through the info
field of HKDF but I would be very careful not to derive two different keys
where the only difference in the 'info' values is the key length. If the two
keys happen to be of the same length one would end up with two keys that are
identical.


The term you use in your paper and the RFC is

T(N) = HMAC-Hash(PRK, T(N-1) | info | N) where N is expressed as a single octet in the concatenation operation.

You can include the length term in info, but it won't be enforced by the HSM and depending on the format of the INFO field could actually be spoofed as this is all user supplied info that isn't known to be related to the actual desired output length.

Instead HKDF should be updated to:

T(N) = HMAC-Hash (PRK, T(N-1) | info | N | L) where L is the number of bits of desired key stream expressed as a UINT32 in NBO *is* enforceable by the HSM as it is a known field (size and position).

NIST SP800-56C (which was standardized after the RFC and references your paper) describes the equivalent of your extract phase and then refers to SP800-108 and allows any of those to be used in the expansion phase. ALL of the possible alternatives - counter, feed back (and the evil double pipeline) include the length term in the per-block expansion.

E.g. the feedback expansion uses:

K(i) := PRF (KI, K(i-1) {|| [i]2 }|| Label || 0x00 || Context || [L]2)

Where PRF is equivalent to your HMAC-HASH, KI is the PRK, [i]2 is the same as N, "Label || 0x00 || context" is equivalent to info and L[2] is the length of the desired output.

HKDF is equivalent to NISTSP800-56C with an expansion phase of NIST SP800-108, section 5.2 where the length of i is a single octet, where the ordering of the terms is slightly different and where the L term is omitted.

The inclusion of L as a mandatory term in the expansion means that any change in L changes the entire key stream. That is NOT the case with HKDF as defined in the RFC.

See section 7.5 of SP800-108 for a discussion of key separation especially paragraph (2) and why this is important.

- One of the emails raises the issue of using random salt, as recommended by RFC
5869. Note that the RFC recommendation also indicates that the salt value
should be something that is authenticated during the protocol, or otherwise it
can be selected by the adversary. This authentication needs to happen
independently of the key being derived using this salt. For example, one
should be careful not to incur in a circular logic, e.g. deriving a key
mackey=HKDF(salt, info) and then using mackey to authenticate the salt by
computing MAC(mackey, salt). This is why the proposed TLS 1.3 key derivation
scheme does not use nonces as salt.

I believe that is the correct approach.

- Someone said: "In an ideal world we would all use the same KDFs rather than
inventing a new one for each protocol."
That was me. But what I said was that we should use standard KDFs, not reinvent new ones.

This was exactly the goal of HKDF,
namely, provide a single KDF that can serve different protocols, requirements
and settings. The interested reader can consult my Crypto 2010 paper
https://eprint.iacr.org/2010/264
for a very detailed treatment of key derivation in general and HKDF in
particular,and why this one design fits many different uses. TLS 1.3 is a
perfect demonstration of the versatility of HKDF as it is used as a random
oracle, randomness extractor and PRF, depending on the key material being
derived. See the next item for an example.

Given SP800-108 and SP800-56C were published before your paper and the RFC and have pretty much identical math (except as I noted), why shouldn't we use those cites instead of the RFC? E.g. is there any cryptographic improvement in RFC5869 vs the other two?




- Another issue raised in recent email exchange is the way to merge the
semi-static value g^xs (where s is the semi-static server's private key and x
the ephemeral client's private key) with the ephemeral value g^xy.
This is done by first extracting a key from g^xs as PRK1=HKDF-extract(0,g^xs)
and then extracting PRK2=HKDF-extract(PRK1,g^xy).
Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as a random
oracle as needed in the proof of security. Then PRK2 is derived with salt=PRK2
for the following reason. If g^xs is not exposed (the typical case) then this
HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially the less
demanding property from HKDF). If g^xs is revealed by compromise of the
server's semi static private key s (after the conclusion of the handshake, as
in the forward-secrecy setting), then PRK1 is actually an authenticated random
and non-secret salt so you use HKDF as a randomness extractor.
In other words, each use of HKDF uses the minimal cryptographic assumption one
can have depending on the context of derivation.

- Finally, there has been a long discussion related to the derivation of both
secret and non-secret material (the latter for IVs). I can't say how this
works with HSMs, PKCS11 or other standards, but from the cryptographic point
of view doing this "mixed" derivation of secret and non-secret values is not a
problem as long as HMAC is not broken as a PRF.

Umm.... I don't actually understand what you said here.

The issue is that you can't use the same key for different purposes if you want to enforce key security. Even though the underlying construct for a KDF is an HMAC function, if you can ensure - in an enforceable manner - that a master secret can only be used for key expansion and an integrity key is only used for a MAC function (including the HMAC over data) and that pseudo-random data does not depend on either of these keys (i.e. they are cryptographic isolated) then you can build an HSM that can actually do its job. There are other related issues (e.g. the outputs of a KDF getting tagged with appropriate key types, lengths and exportability).

All that means is that you want three different functions: KDF (key expansion), MAC (finished message signature) and RBG (IV/Nonce production), and that you enforce the type of inputs to them. The underlying cryptographic constructs can be the same or similar, but we need to stop conflating them as needing to be identical.

Mike


Hugo



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

--------------050805020400080402020009-- From nobody Sun Apr 26 13:21: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 403531A8AA6 for ; Sun, 26 Apr 2015 13:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.823 X-Spam-Level: X-Spam-Status: No, score=0.823 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, J_CHICKENPOX_12=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W6POs4xg1qj for ; Sun, 26 Apr 2015 13:21:22 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010: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 F3F891A8851 for ; Sun, 26 Apr 2015 13:21:21 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so68737549lbc.1 for ; Sun, 26 Apr 2015 13:21:20 -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:from:date:message-id :subject:to:cc:content-type; bh=povnA4BhJ+XCjNr+hkkv4j9txeZQmK7yEgEDgagV4jc=; b=nQKCDvp7qzoAaP5+zdNUyWMxKChtpLzGND0cFXyv0zfKxu7MOyyzMheGTMXazjjmCb msaQjIuV9Y7StBjmH1rCNAB2jJGLAM7IIfL9usnK0WpmJDIeCpAK+HU7GaTj6FAIwhLz Cx9CvFJKSfzm7CyN/j35ZtD27Ph012d4isK/2EgYejaBgSeBUWS6EYKCSE3/hg4wd0GC ZG3EPwGDz03lDlV2LcsDVMeeEH1P67HWcQwxwaJQ/QCZJFT3XL8E60QIZAPtrcoNb7QF GaGtqXW7qT1JoIAKzfy/hjCrzh2TXrFAsAMpkmipMDzDdD4Xc41IIzL1wMVBQa8YkbOT py/w== X-Received: by 10.152.43.110 with SMTP id v14mr6488515lal.4.1430079680395; Sun, 26 Apr 2015 13:21:20 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.66 with HTTP; Sun, 26 Apr 2015 13:20:49 -0700 (PDT) In-Reply-To: <553D3572.6040408@nthpermutation.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> From: Hugo Krawczyk Date: Sun, 26 Apr 2015 16:20:49 -0400 X-Google-Sender-Auth: 6tn98oFwit3ZA_1MFw5ICZVV9j0 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=001a11c3515259be700514a65fc7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2015 20:21:26 -0000 --001a11c3515259be700514a65fc7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 26, 2015 at 2:58 PM, Michael StJohns wrote: > Inline below. > > > On 4/24/2015 5:31 PM, Hugo Krawczyk wrote: > > > Here are a few clarifications regarding HKDF and its use in TLS 1.3 in > response > to recent emails (including those under the "HSM-friendly Key Computation= " > thread). I will not touch on anything specific to HSM or PKCS11 since I > know > little about these and the recent exchange on these issues has not helped > me > understanding these things any better (but rather confuse me more). > > Let me start with the issue of whether we should be using the HKDF-Extrac= t > and > HKDF-Expand separately or only use HKDF as a single function (which > internally > operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for > the > latter approach (single function) as it deals with HKDF as a black box. > But there are also advantages to calling these two components separately, > and > TLS 1.3 provides some good examples for that. First, HKDF is built to > output as > many keys as needed from a single HKDF operation, but in TLS we are > deriving > multiple keys from the same keying material through separate applications > of the > expand part. In such a case it is more natural to apply extract once and > apply > expand several times (with different info fields!). For example, Master > Secret > is derived using a single Extract operation but it is then used in three > different Expand operations for deriving other keys (application traffic > keys, > export master secret, and resumption master secret). Second, when one > starts with > a strong key then the Extract step can be skipped making it convenient to > be > able to call Expand directly. Third, it is convenient to call Expand > directly as > a PRF for computing the Finished message. Lastly, and not least, it makes > the > key derivation logic more explicit which helps conveying the rationale of > each > operation and helps those analyzing the protocol (now and in the future). > > > What you're doing as far as I can tell is optimizing implementation at th= e > cost of requiring special interfaces. > > One of the ways we've gotten to the point where TLS key material can't > actually be kept secret in an HSM is by generalizing the concept of a PRF > into a KDF and a MAC. What we need to do is have a MAC function and a > KDF function and understand what the inputs to those are. > > TLS1.2 uses the Master secret as a key for both the MAC and KDF functions > and that needs to change. Those can't be the same key - and hence your > comment about using the same master secret for different derives becomes > problematic especially if one of the outputs is to an exporter. > =E2=80=8BThe same Master Secret is used to derive multiple keys but these a= re derived with unique label+context input.=E2=80=8B =E2=80=8B =E2=80=8BDifferent derivations *never* use the same label+context.=E2=80=8B > Internally, an HSM MAY choose to retain the output of the extract phase a= s > cached material (and in fact taking the master secret, doing the impedanc= e > match of the extract phase and replacing the master secret with the > reduction still pointed to the master secret handle may be what a > particular implementation does). But that's an implementation discussion= , > not a KDF input/output discussion. > =E2=80=8BIs this discussion geared to define the KDF mechanism for TLS 1.3? If so, can you say what exactly you are proposing to do? =E2=80=8B > > > > > My recommendation is to keep the Extract and Expand separation for the > moment, > in particular due to the last point, so we can see more clearly the logic > while > still setting the missing details of the protocol. When the whole picture > is > clear we can revisit this point. > > On other issues: > > - This should be obvious but worth repeating: All calls to HKDF-Expand > MUST use > a non-empty info field binding the derived key(s) to a unique context > (in the > case of TLS this is usually a label and a cumulative session-hash). > > > All calls to HKDF *should* use a non-empty label and context field, but > that's tied more to the specific use than anything else. > =E2=80=8BAgreed. All calls to HKDF that produce cryptographic keys for use = in the protocol MUST use a non-empty label and context field and that's what we do. =E2=80=8B > This isn't something that needs to be enforced by the security module as > the crypto will cause different streams to be generated with different > labels and contexts. > > Except for the problem of the Length term. Same label and context but > with different output lengths will have the same prefixed key stream. > =E2=80=8BI am completely lost on this length issue. Can you give me a concr= ete example where TLS 1.3 derives different keys with same label and context but with different output lengths? As said, in TLS 1.3 each label and context is used exactly once. I must be missing something in your argument but I just can't figure what's that. =E2=80=8B > > - It was suggested that the length of derived keys should be part of the > input > to key expansion. If desired, this length can be entered through the in= fo > field of HKDF but I would be very careful not to derive two different > keys > where the only difference in the 'info' values is the key length. If th= e > two > keys happen to be of the same length one would end up with two keys tha= t > are > identical. > > > The term you use in your paper and the RFC is > > T(N) =3D HMAC-Hash(PRK, T(N-1) | info | N) where N is expressed as a sing= le > octet in the concatenation operation. > > You can include the length term in info, but it won't be enforced by the > HSM and depending on the format of the INFO field could actually be spoof= ed > as this is all user supplied info that isn't known to be related to the > actual desired output length. > Adding the length is not a solution to spoofing attacks- it will not differentiate between keys of the same length. You cannot compensate via the KDF for unauthorized access to the HSM. If the HSM doesn't enforce an access policy, it is the HSM problem, not something to solve via the KDF or via TLS 1.3 spec. =E2=80=8B > > Instead HKDF should be updated to: > > T(N) =3D HMAC-Hash (PRK, T(N-1) | info | N | L) where L is the number of > bits of desired key stream expressed as a UINT32 in NBO *is* enforceable = by > the HSM as it is a known field (size and position). > > NIST SP800-56C (which was standardized after the RFC and references your > paper) describes the equivalent of your extract phase and then refers to > SP800-108 and allows any of those to be used in the expansion phase. ALL > of the possible alternatives - counter, feed back (and the evil double > pipeline) include the length term in the per-block expansion. > > E.g. the feedback expansion uses: > > K(i) :=3D PRF (KI, K(i-1) {|| [i]2 }|| Label || 0x00 || Context || [L]2) > > Where PRF is equivalent to your HMAC-HASH, KI is the PRK, [i]2 is the > same as N, "Label || 0x00 || context" is equivalent to info and L[2] is t= he > length of the desired output. > > HKDF is equivalent to NISTSP800-56C with an expansion phase of NIST > SP800-108, section 5.2 where the length of i is a single octet, where the > ordering of the terms is slightly different and where the L term is > omitted. > > The inclusion of L as a mandatory term in the expansion means that any > change in L changes the entire key stream. That is NOT the case with HKD= F > as defined in the RFC. > > See section 7.5 of > =E2=80=8B=E2=80=8B > SP800-108 for a discussion of key separation especially paragraph (2) and > why this is important. > > =E2=80=8BI agree with section 7.5 and HKDF, and its use in TLS 1.3, fully= complies with it. There is no mandatory use of length as input. It is certainly allowed but not mandated. And when allowing it, it is accommodated via the equivalent of the 'info' =E2=80=8B =E2=80=8Bfield: *"different input data strings (e.g. Label || 0x00 || Context || [L]2) shall be used for different executions".*Length is an example and not even listed in the explicit examples at the top of page 19. =E2=80=8B > - One of the emails raises the issue of using random salt, as > recommended by RFC > 5869. Note that the RFC recommendation also indicates that the salt val= ue > should be something that is authenticated during the protocol, or > otherwise it > can be selected by the adversary. This authentication needs to happen > independently of the key being derived using this salt. For example, on= e > should be careful not to incur in a circular logic, e.g. deriving a key > mackey=3DHKDF(salt, info) and then using mackey to authenticate the sal= t by > computing MAC(mackey, salt). This is why the proposed TLS 1.3 key > derivation > scheme does not use nonces as salt. > > > I believe that is the correct approach. > > > - Someone said: "In an ideal world we would all use the same KDFs rather > than > inventing a new one for each protocol." > > That was me. But what I said was that we should use standard KDFs, not > reinvent new ones. > > This was exactly the goal of HKDF, > namely, provide a single KDF that can serve different protocols, > requirements > and settings. The interested reader can consult my Crypto 2010 paper > https://eprint.iacr.org/2010/264 > for a very detailed treatment of key derivation in general and HKDF in > particular,and why this one design fits many different uses. TLS 1.3 is= a > perfect demonstration of the versatility of HKDF as it is used as a > random > oracle, randomness extractor and PRF, depending on the key material bei= ng > derived. See the next item for an example. > > > Given SP800-108 and SP800-56C were published before your paper and the > RFC and have pretty much identical math (except as I noted), why shouldn'= t > we use those cites instead of the RFC? E.g. is there any cryptographic > improvement in RFC5869 vs the other two? > =E2=80=8BSP 800-108 is a framework and set of recommendations, not a specif= ic, unique KDF function. HKDF follows this framework and NIST found this sufficiently important to document this in a separate document SP 800-56C (which explicitly includes HKDF as an instantiation)=E2=80=8B =E2=80=8B.=E2=80=8B > > > - Another issue raised in recent email exchange is the way to merge the > semi-static value g^xs (where s is the semi-static server's private key > and x > the ephemeral client's private key) with the ephemeral value g^xy. > This is done by first extracting a key from g^xs as > PRK1=3DHKDF-extract(0,g^xs) > and then extracting PRK2=3DHKDF-extract(PRK1,g^xy). > Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as a > random > oracle as needed in the proof of security. Then PRK2 is derived with > salt=3DPRK2 > for the following reason. If g^xs is not exposed (the typical case) the= n > this > HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially th= e > less > demanding property from HKDF). If g^xs is revealed by compromise of th= e > server's semi static private key s (after the conclusion of the > handshake, as > in the forward-secrecy setting), then PRK1 is actually an authenticated > random > and non-secret salt so you use HKDF as a randomness extractor. > In other words, each use of HKDF uses the minimal cryptographic > assumption one > can have depending on the context of derivation. > > - Finally, there has been a long discussion related to the derivation of > both > secret and non-secret material (the latter for IVs). I can't say how th= is > works with HSMs, PKCS11 or other standards, but from the cryptographic > point > of view doing this "mixed" derivation of secret and non-secret values i= s > not a > problem as long as HMAC is not broken as a PRF. > > > Umm.... I don't actually understand what you said here. > =E2=80=8BWe are definitely having difficulties understanding each other. I'= m trying my best. Hugo =E2=80=8B > > The issue is that you can't use the same key for different purposes if yo= u > want to enforce key security. Even though the underlying construct for a > KDF is an HMAC function, if you can ensure - in an enforceable manner - > that a master secret can only be used for key expansion and an integrity > key is only used for a MAC function (including the HMAC over data) and th= at > pseudo-random data does not depend on either of these keys (i.e. they are > cryptographic isolated) then you can build an HSM that can actually do it= s > job. There are other related issues (e.g. the outputs of a KDF getting > tagged with appropriate key types, lengths and exportability). > > All that means is that you want three different functions: KDF (key > expansion), MAC (finished message signature) and RBG (IV/Nonce > production), and that you enforce the type of inputs to them. The > underlying cryptographic constructs can be the same or similar, but we ne= ed > to stop conflating them as needing to be identical. > > Mike > > > Hugo > > > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c3515259be700514a65fc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 26, 2015 at 2:58 PM, Michael StJohns <msj@nthpermutation.com> wrote:
=20 =20 =20
Inline below.


On 4/24/2015 5:31 PM, Hugo Krawczyk wrote:

Here are a few clarifications regarding HKDF and its use in TLS 1.3 in response
to recent emails (including those under the "HSM-friendly Ke= y Computation"
thread). I will not touch on anything specific to HSM or PKCS11 since I know
little about these and the recent exchange on these issues has not helped me
understanding these things any better (but rather confuse me more).

Let me start with the issue of whether we should be using the HKDF-Extract and
HKDF-Expand separately or only use HKDF as a single function (which internally
operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for the
latter approach (single function) as it deals with HKDF as a black box.
But there are also advantages to calling these two components separately, and
TLS 1.3 provides some good examples for that. First, HKDF is built to output as
many keys as needed from a single HKDF operation, but in TLS we are deriving
multiple keys from the same keying material through separate applications of the
expand part. In such a case it is more natural to apply extract once and apply
expand several times (with different info fields!). For example, Master Secret
is derived using a single Extract operation but it is then used in three
different Expand operations for deriving other keys (application traffic keys,
export master secret, and resumption master secret). Second, when one starts with
a strong key then the Extract step can be skipped making it convenient to be
able to call Expand directly. Third, it is convenient to call Expand directly as
a PRF for computing the Finished message. Lastly, and not least, it makes the
key derivation logic more explicit which helps conveying the rationale of each
operation and helps those analyzing the protocol (now and in the future).

 What you're doing as far as I can tell is optimizing implementation at the cost of requiring special interfaces.

One of the ways we've gotten to the point where TLS key material can't actually be kept secret in an HSM is by generalizing the concept of a PRF into a KDF and a MAC.=C2=A0=C2=A0=C2=A0 What we need t= o do is have a MAC function and a KDF function and understand what the inputs to those are.

TLS1.2 uses the Master secret as a key for both the MAC and KDF functions and that needs to change.=C2=A0 Those can't be the same k= ey - and hence your comment about using the same master secret for different derives becomes problematic especially if one of the outputs is to an exporter.

=E2=80=8BThe same Master Secret is used to derive multiple key= s but these are derived with unique label+context input.=E2=80=8B
=E2= =80=8B
=E2=80=8BDifferent derivations *never* use= the same label+context.=E2=80=8B



Internally, an HSM MAY choose to retain the output of the extract phase as cached material (and in fact taking the master secret, doing the impedance match of the extract phase and replacing the master secret with the reduction still pointed to the master secret handle may be what a particular implementation does).=C2=A0 But that= 9;s an implementation discussion, not a KDF input/output discussion.

=E2= =80=8BIs this discussion geared to define the KDF mechanism for TLS 1.3?
If so, can you say what exactly you are pr= oposing to do?
=E2=80=8B
=C2=A0




My recommendation is to keep the Extract and Expand separation for the moment,
in particular due to the last point, so we can see more clearly the logic while
still setting the missing details of the protocol. When the whole picture is
clear we can revisit this point.

On other issues:

- This should be obvious but worth repeating: All calls to HKDF-Expand MUST use
=C2=A0 a non-empty info field binding the derived key(s) to a unique context (in the
=C2=A0 case of TLS this is usually a label and a cumulative session-hash).

 All calls to HKDF *should* use a non-empty label and context field, but that's tied more to the specific use than anything else.=C2=A0<= /div>

=E2=80=8BAgreed. All c= alls to HKDF that produce cryptographic keys for use in the protocol MUST u= se a non-empty label and context field and that's what we do.
=E2= =80=8B
=C2=A0
<= div bgcolor=3D"#FFFFFF" text=3D"#000000"> This isn't something that needs to be enforced by the security module as the crypto will cause different streams to be generated with different labels and contexts.

Except for the problem of the Length term.=C2=A0=C2=A0 Same label and c= ontext but with different output lengths will have the same prefixed key stream.

=E2=80=8BI am completely lost on this length issue. Can y= ou give me a concrete example where TLS 1.3 derives different keys with sam= e label and context but with different output lengths? As said, in TLS 1.3 = each label and context is used exactly once. I must be missing something in= your argument but I just can't figure what's that.
=E2=80=8B=C2=A0
=C2= =A0
- It was suggested that the length of derived keys should be part of the input
=C2=A0 to key expansion. If desired, this length can be entered through the info
=C2=A0 field of HKDF but I would be very careful not to derive tw= o different keys
=C2=A0 where the only difference in the 'info' values is = the key length. If the two
=C2=A0 keys happen to be of the same length one would end up with two keys that are
=C2=A0 identical.


The term you use in your paper and the RFC is

T(N) =3D HMAC-Hash(PRK, T(N-1) | info | N) where N is expressed as a single octet in the concatenation operation.

You can include the length term in info, but it won't be enforced b= y the HSM and depending on the format of the INFO field could actually be spoofed as this is all user supplied info that isn't known to be related to the actual desired output length.
=C2=A0Adding the length is not a solution to spo= ofing attacks- it will not differentiate between keys of the same length.
You cannot compensate via the KDF for una= uthorized access to the HSM. If the HSM doesn't enforce an access polic= y, it is the HSM problem, not something to solve via the KDF or via TLS 1.3= spec.
=E2=80=8B
=C2=A0

Instead HKDF should be updated to:

T(N) =3D HMAC-Hash (PRK, T(N-1) | info | N | L) where L is the number of bits of desired key stream expressed as a UINT32 in NBO *is* enforceable by the HSM as it is a known field (size and position).

NIST SP800-56C (which was standardized after the RFC and references your paper) describes the equivalent of your extract phase and then refers to SP800-108 and allows any of those to be used in the expansion phase.=C2=A0 ALL of the possible alternatives - counter, feed back (and the evil double pipeline) include the length term in the per-block expansion.

E.g.=C2=A0 the feedback expansion uses:

K(i) :=3D PRF (KI, K(i-1) {|| [i]2 }|| Label || 0x00 || Context || [L]2)

Where PRF is equivalent to your HMAC-HASH,=C2=A0 KI is the PRK, [i]2 is the same as N, "Label || 0x00 || context" is equivalent to in= fo and L[2] is the length of the desired output.

HKDF is equivalent to NISTSP800-56C with an expansion phase of NIST SP800-108, section 5.2 where the length of i is a single octet, where the ordering of the terms is slightly different and where the L term is omitted.=C2=A0

The inclusion of L as a mandatory term in the expansion means that any change in L changes the entire key stream.=C2=A0 That is NOT the ca= se with HKDF as defined in the RFC.

See section 7.5 of
=E2=80=8B=E2=80=8B
SP= 800-108 for a discussion of key separation especially paragraph (2) and why this is important.
=E2=80= =8BI agree with section 7.5 and HKDF, and its use in TLS 1.3, fully complie= s with it. There is no mandatory use of length as input. It is certainly al= lowed but not mandated. And when allowing it, it is accommodated via the eq= uivalent of the 'info' =E2=80=8B
=C2=A0
=E2=80=8Bfield:
"different input data strings (e.g. Label || = 0x00 || Context || [L]2) shall be used for different executions".
<= /i>Length is an example and not even listed in the explicit examples at the= top of page 19.
=E2=80=8B
- One of the emails raises the issue of using random salt, as recommended by RFC
=C2=A0 5869. Note that the RFC recommendation also indicates that the salt value
=C2=A0 should be something that is authenticated during the protocol, or otherwise it
=C2=A0 can be selected by the adversary. This authentication need= s to happen
=C2=A0 independently of the key being derived using this salt. Fo= r example, one
=C2=A0 should be careful not to incur in a circular logic, e.g. deriving a key
=C2=A0 mackey=3DHKDF(salt, info) and then using mackey to authenticate the salt by
=C2=A0 computing MAC(mackey, salt). This is why the proposed TLS 1.3 key derivation
=C2=A0 scheme does not use nonces as salt.

 I believe that is the correct approach.=C2=A0

- Someone said: "In an ideal world we would all use the same KDFs rather than
=C2=A0 inventing a new one for each protocol."
That was me.=C2=A0 But what I said was that we should use standard KDFs= , not reinvent new ones.=C2=A0
=
This was exactly the goal of HKDF,
=C2=A0 namely, provide a single KDF that can serve different protocols, requirements
=C2=A0 and settings. The interested reader can consult my Crypto 2010 paper
=C2=A0 https://eprint.iacr.org/2010/264
=C2=A0 for a very detailed treatment of key derivation in general and HKDF in
=C2=A0 particular,and why this one design fits many different use= s. TLS 1.3 is a
=C2=A0 perfect demonstration of the versatility of HKDF as it is used as a random
=C2=A0 oracle, randomness extractor and PRF, depending on the key material being
=C2=A0 derived. See the next item for an example.

 Given SP800-108 and SP800-56C were published before your paper=C2=A0 an= d the RFC and have pretty much identical math (except as I noted), why shouldn't we use those cites instead of the RFC?=C2=A0 E.g. is ther= e any cryptographic improvement in RFC5869 vs the other two?=

=E2=80= =8BSP 800-108 is a framework and set of recommendations, not a specific, un= ique KDF function. HKDF follows this framework and NIST found this sufficie= ntly important to document this in a separate document SP 800-56C (which ex= plicitly includes HKDF as an instantiation)=E2=80=8B
=E2=80=8B.=E2=80=8B
=C2=A0




- Another issue raised in recent email exchange is the way to merge the
=C2=A0 semi-static value g^xs (where s is the semi-static server&= #39;s private key and x
=C2=A0 the ephemeral client's private key) with the ephemeral= value g^xy.
=C2=A0 This is done by first extracting a key from g^xs as PRK1=3DHKDF-extract(0,g^xs)
=C2=A0 and then extracting PRK2=3DHKDF-extract(PRK1,g^xy).
=C2=A0 Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as a random
=C2=A0 oracle as needed in the proof of security. Then PRK2 is derived with salt=3DPRK2
=C2=A0 for the following reason. If g^xs is not exposed (the typical case) then this
=C2=A0 HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially the less
=C2=A0 demanding property from HKDF).=C2=A0 If g^xs is revealed b= y compromise of the
=C2=A0 server's semi static private key s (after the conclusi= on of the handshake, as
=C2=A0 in the forward-secrecy setting), then PRK1 is actually an authenticated random
=C2=A0 and non-secret salt so you use HKDF as a randomness extractor.
=C2=A0 In other words, each use of HKDF uses the minimal cryptographic assumption one
=C2=A0 can have depending on the context of derivation.

- Finally, there has been a long discussion related to the derivation of both
=C2=A0 secret and non-secret material (the latter for IVs). I can= 't say how this
=C2=A0 works with HSMs, PKCS11 or other standards, but from the cryptographic point
=C2=A0 of view doing this "mixed" derivation of secret = and non-secret values is not a
=C2=A0 problem as long as HMAC is not broken as a PRF.

 Umm....=C2=A0 I don't actually understand what you said here.=C2=A0=

=E2=80=8BWe are = definitely having difficulties understanding each other. I'm trying my = best.

Hugo

=E2=80=8B
=C2= =A0

The issue is that you can't use the same key for different purposes if you want to enforce key security.=C2=A0 Even though the underlying construct for a KDF is an HMAC function, if you can ensure - in an enforceable manner - that a master secret can only be used for key expansion and an integrity key is only used for a MAC function (including the HMAC over data) and that pseudo-random data does not depend on either of these keys (i.e. they are=C2=A0 cryptographic isolated) then you can build an HSM that can actually do its job.=C2=A0 There are other related issues (e.g. the outputs of a KDF getting tagged with appropriate key types, lengths and exportability).

All that means is that you want three different functions: KDF (key expansion), MAC (finished message signature)=C2=A0 and RBG (IV/Nonce production), and that you enforce the type of inputs to them.=C2=A0 The underlying cryptographic constructs can be the same or similar, but we need to stop conflating them as needing to be identical.

Mike

=C2= =A0
Hugo



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


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


--001a11c3515259be700514a65fc7-- From nobody Sun Apr 26 13:26: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 CF42A1A8F42 for ; Sun, 26 Apr 2015 13:26:35 -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 nw3PnWU1_GhY for ; Sun, 26 Apr 2015 13:26:34 -0700 (PDT) Received: from mail-vn0-f47.google.com (mail-vn0-f47.google.com [209.85.216.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 A86671A8F3C for ; Sun, 26 Apr 2015 13:26:34 -0700 (PDT) Received: by vnbf190 with SMTP id f190so9637656vnb.1 for ; Sun, 26 Apr 2015 13:26:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UFYQeINcuni+1zqCEsv5KPyMlG0BSNc5yHwYW71hnfg=; b=YmjXKogmt/3Sn1u2eN6H+ceBkZdf5QGECh10h9ISsLWyxKccEGIujT5/HYvXD39PT0 gZpMLDLJ5dunx1MQQW8zlafIgzc8wc5YNd/9Y8+BdU4xAACrT3WYPEk+OAMprskCRg6P sytVdqO1NRFcHKEhPKBc3AVKwTH9gd/Boz4sKUaOFTMcrw1XSgaXWiyIzKCnv+YGC69B RjlU3/+nMBKHapu8ZWoJmyz8iuVUBAQLY9qoYVjXlqeglCjm61cEMljjAZb3Ja/87F/z 17h55IVq9lO2clr/fUika7HaPlv/A3VI2FgoLw75y7+IKt9ki/0MtsMoNffPf00gFgP7 fQjg== X-Gm-Message-State: ALoCoQnHnKNulDCajfbMggmoHRubwPB78ZAXKt/BEWP7L8xayajrlb6sTgYRwunslcBRBnJN01nG X-Received: by 10.52.135.231 with SMTP id pv7mr20236792vdb.21.1430079993675; Sun, 26 Apr 2015 13:26:33 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id h14sm20228343vdj.0.2015.04.26.13.26.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 13:26:33 -0700 (PDT) Message-ID: <553D49F8.10209@nthpermutation.com> Date: Sun, 26 Apr 2015 16:26:32 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ilari Liusvaara References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> <20150426182025.GA3549@LK-Perkele-VII> In-Reply-To: <20150426182025.GA3549@LK-Perkele-VII> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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, 26 Apr 2015 20:26:36 -0000 On 4/26/2015 2:20 PM, Ilari Liusvaara wrote: >> There is no reason to treat the 96 bit quantity as secret and no one else >> >does. > Oh, except SSH. The session nonce is 96 bits and secret. (I'll get back to the rest of your message later, but let me dispose of the above first). Not exactly. It turns out that the IV of each SSH message is the Cipher text of the last block of the previous message. Which - since it's cipher text - is transmitted and known to everyone who can intercept the message stream. SSH uses CBC exclusively as far as I can tell. The fact that the mixin of the first block of the first message (AKA the initial IV) is generated via keyed material from the negotiated shared secret is actually a problem (similar to the problems in TLS 1.2 and before) and doesn't actually provide any security. Let me be blunt: IVs are NOT secrets and you should not impute additional security by encrypting them or otherwise deriving them in a non-public manner. Mike From nobody Sun Apr 26 13:28: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 BA2951A9006 for ; Sun, 26 Apr 2015 13:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.223 X-Spam-Level: X-Spam-Status: No, score=0.223 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, J_CHICKENPOX_12=0.6, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbuGWHoGY9_X for ; Sun, 26 Apr 2015 13:28:54 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::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 0446D1A8FD5 for ; Sun, 26 Apr 2015 13:28:54 -0700 (PDT) Received: by lagv1 with SMTP id v1so66758404lag.3 for ; Sun, 26 Apr 2015 13:28:52 -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:from:date:message-id :subject:to:cc:content-type; bh=T2q5d2AXYgGmMmxSnAMM6mowVpVrOBpxnV2eRCSvzWs=; b=pSCcRM7tMYVoowzVi0Zbq3qxzqB4YuhMU61ithLgu4yK858biMIi3Pbl9L+0uV4DyI pb9qcsKvb369/cExKfNx9H7bTpyp9z/oMLxLNzfvfAA1XfnFgGNGJczxqY94Don2DPkv cZepD+ZVO/rO0s9ZoFGn7/7fKFncx0pdY2BfrIzmX4OGbjdM5bp+qxXiC0mIU5JWVbV1 z7Qrv41KMSq7/wOPImYN6R9B9Tw+HhAlMW4JqK+Ak5vvA/BtE7DEAv5EP9pF4AUT8L8O rJ4PFwZW0tjtIOzFl5KapfbJmWqBRq+IF2cUq5a23QPJSTb4p68BbCrcFH9R3F812+jz S+8A== X-Received: by 10.152.28.97 with SMTP id a1mr7456870lah.9.1430080132448; Sun, 26 Apr 2015 13:28:52 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.66 with HTTP; Sun, 26 Apr 2015 13:28:21 -0700 (PDT) In-Reply-To: <553B2D59.3030407@brainhub.org> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <20150425053458.GA28576@LK-Perkele-VII> <553B2D59.3030407@brainhub.org> From: Hugo Krawczyk Date: Sun, 26 Apr 2015 16:28:21 -0400 X-Google-Sender-Auth: uOWxSfuI8dGKD8A_UFnk0VQbGpo Message-ID: To: Andrey Jivsov , Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e0160b7d44b87dc0514a67aa4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2015 20:28:57 -0000 --089e0160b7d44b87dc0514a67aa4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Indeed, HKDF-extract(0, g^xy) is equivalent to =E2=80=8BHash( opad || Hash(= ipad || g^xy ) ) but that is only for computing an intermediate key which is then used to key HKDF-expand for actual key derivation where the input to this derivation includes the 'info' field (label + digest of handshake messages)= . You are right that in the case of Master Secret, the key derivation in TLS 1.2 is more complicated-looking (actually, it is very similar to deriving Master Secret using full HKDF instead of HKDF_Extract only) but just being complicated-looking is not a guarantee of additional security (*). A well structured uniform scheme as HKDF that serves multiple purposes in a single design is much cleaner and amenable to analysis. Security by obscurity (or by "complicatity") is never a good idea. And the multi-purpose properties of HKDF are not just academic advantages, but a property of HKDF that serves TLS 1.3 very well, for example to strengthen the application keys by making them depend on both long-term and ephemeral keying material. Hugo (*) Just for fun, if you compare Hash( opad || Hash( ipad || g^xy ) ) to your preferred =E2=80=8B =E2=80=8B Hash(g^xy ^ opad || Hash( (g^xy ^ ipad) =E2=80=8B ) you can note that if g^xy is longer than the hash block, your s= ecurity gets limited to that block length while in the former this is not necessarily the case. I am not suggesting that this is a practical advantage of the former, just giving it as an example of why complicating things do not necessarily help and many times can actually hurt. The more structural issue here is not to use a non-uniform key, as g^xy may be, as a HMAC key directly.=E2=80=8B On Sat, Apr 25, 2015 at 1:59 AM, Andrey Jivsov wrote: > On 04/24/2015 10:34 PM, Ilari Liusvaara wrote: > >> On Fri, Apr 24, 2015 at 05:31:51PM -0400, Hugo Krawczyk wrote: >> >>> Here are a few clarifications regarding HKDF and its use in TLS 1.3 in >>> response >>> to recent emails (including those under the "HSM-friendly Key >>> Computation" >>> thread). I will not touch on anything specific to HSM or PKCS11 since I >>> know >>> little about these and the recent exchange on these issues has not >>> helped me >>> understanding these things any better (but rather confuse me more). >>> >> >> Actually, for me, that HSM thread actually clarified what the actual >> requirements >> are (which lets one minimize distruption). >> >> Let me start with the issue of whether we should be using the >>> HKDF-Extract and >>> HKDF-Expand separately or only use HKDF as a single function (which >>> internally >>> operates HKDF-Extract and HKDF-Expand). There is an obvious advantage >>> for the >>> latter approach (single function) as it deals with HKDF as a black box. >>> But there are also advantages to calling these two components >>> separately, and >>> TLS 1.3 provides some good examples for that. First, HKDF is built to >>> output as >>> many keys as needed from a single HKDF operation, but in TLS we are >>> deriving >>> multiple keys from the same keying material through separate >>> applications of the >>> expand part. In such a case it is more natural to apply extract once an= d >>> apply >>> expand several times (with different info fields!). For example, Master >>> Secret >>> is derived using a single Extract operation but it is then used in thre= e >>> different Expand operations for deriving other keys (application traffi= c >>> keys, >>> export master secret, and resumption master secret). Second, when one >>> starts with >>> a strong key then the Extract step can be skipped making it convenient >>> to be >>> able to call Expand directly. Third, it is convenient to call Expand >>> directly as >>> a PRF for computing the Finished message. Lastly, and not least, it >>> makes the >>> key derivation logic more explicit which helps conveying the rationale >>> of each >>> operation and helps those analyzing the protocol (now and in the future= ). >>> >> >> Some models derive even more things out of (handshake) MS, e.g. one mode= l >> does: >> - s2c_appMS. >> - eMS >> - Unique >> - c2s_appMS. >> - rPMS >> >> My recommendation is to keep the Extract and Expand separation for the >>> moment, >>> in particular due to the last point, so we can see more clearly the >>> logic while >>> still setting the missing details of the protocol. When the whole >>> picture is >>> clear we can revisit this point. >>> >>> On other issues: >>> >>> - This should be obvious but worth repeating: All calls to HKDF-Expand >>> MUST use >>> a non-empty info field binding the derived key(s) to a unique contex= t >>> (in the >>> case of TLS this is usually a label and a cumulative session-hash). >>> >>> - It was suggested that the length of derived keys should be part of th= e >>> input >>> to key expansion. If desired, this length can be entered through the >>> info >>> field of HKDF but I would be very careful not to derive two differen= t >>> keys >>> where the only difference in the 'info' values is the key length. If >>> the two >>> keys happen to be of the same length one would end up with two keys >>> that are >>> identical. >>> >> >> Well, there would still be string input of what the key is (otherwise >> e.g. rPMS >> and eMS might up ending being the same, which isn't desirable). >> >> - One of the emails raises the issue of using random salt, as >>> recommended by RFC >>> 5869. Note that the RFC recommendation also indicates that the salt >>> value >>> should be something that is authenticated during the protocol, or >>> otherwise it >>> can be selected by the adversary. This authentication needs to happe= n >>> independently of the key being derived using this salt. For example, >>> one >>> should be careful not to incur in a circular logic, e.g. deriving a >>> key >>> mackey=3DHKDF(salt, info) and then using mackey to authenticate the >>> salt by >>> computing MAC(mackey, salt). This is why the proposed TLS 1.3 key >>> derivation >>> scheme does not use nonces as salt. >>> >> >> With fixed salts, the HKDF extract function is essentially H1(H2(x)), >> where >> H1 and H2 are H, but with different (pseudorandom) IVs. >> > > Ilari beat me on this, but I also made this observation. In more details: > > According to intended use of HKDF, HKDF-Extract is this: > > HMS =3D HKDF-Extract( salt=3D0, IKM=3Dg^xy ) > > Which is: > > A. HMAC( 0, g^xy ) =3D Hash( opad || Hash( ipad || g^xy ) ). > > The two invocations of the Hash() begin with hashing fixed values, so one > can re-write the A as > > A1: Hash1( Hash2( g^xy ) ), > > which can be rewritten as > > A2: Hash3( g^xy ) =3D > =E2=80=8B=E2=80=8B > Hash( opad || Hash( ipad || g^xy ) ) > > Therefore, HKDF-Extract( 0, g^xy ) should be viewed as deterministic hash > of g^xy and that's the only contribution of g^xy in HKDF. > > For comparison, TLS 1.2 does the following in the first step: > > B. > =E2=80=8B=E2=80=8B > Hash(g^xy ^ opad || Hash( (g^xy ^ ipad) || "master secret" + > ClientHello.random + ServerHello.random) ) ); > > It would be amusing to see a case when A2 is secure, while B is not. > > >> Also, handshake hashes are very hard to control to any significant degre= e >> (or >> invoking HKDF with bad salt is the least of your worries). >> >> E.g. Suppose prf-hash is 256-bit MD5-equivalent-security. The handshake >> security just breaks catastrophically against active attacks (passive >> attacks >> are another matter). >> >> - Another issue raised in recent email exchange is the way to merge the >>> semi-static value g^xs (where s is the semi-static server's private >>> key and x >>> the ephemeral client's private key) with the ephemeral value g^xy. >>> >> >> "the semi-static server's private key"??? There is no "the key". There's >> the old >> semi-static key (which may not be available), and the new semi-static >> key. And >> the two may or may not be the same key, and those keys may not even be >> available. >> >> Also, in certain conditions, not mixing in DH result with the old key >> actually >> leads to an attack (mixing the new one does not help here). >> >> Also, I heard some implementers complaining about mixing the new one, an= d >> after >> calculating the time penalty, I can easily understand (it is pretty >> sizable). >> >> This is done by first extracting a key from g^xs as >>> PRK1=3DHKDF-extract(0,g^xs) >>> and then extracting PRK2=3DHKDF-extract(PRK1,g^xy). >>> Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as = a >>> random >>> oracle as needed in the proof of security. Then PRK2 is derived with >>> salt=3DPRK2 >>> for the following reason. If g^xs is not exposed (the typical case) >>> then this >>> HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially >>> the less >>> demanding property from HKDF). If g^xs is revealed by compromise of >>> the >>> server's semi static private key s (after the conclusion of the >>> handshake, as >>> in the forward-secrecy setting), then PRK1 is actually an >>> authenticated random >>> and non-secret salt so you use HKDF as a randomness extractor. >>> In other words, each use of HKDF uses the minimal cryptographic >>> assumption one >>> can have depending on the context of derivation. >>> >> >> If it is the new one, it is not properly authenticated (have I mentioned >> how nasty >> even capturing the proper assumptions is?). >> >> - Finally, there has been a long discussion related to the derivation o= f >>> both >>> secret and non-secret material (the latter for IVs). I can't say how >>> this >>> works with HSMs, PKCS11 or other standards, but from the >>> cryptographic point >>> of view doing this "mixed" derivation of secret and non-secret value= s >>> is >>> not a problem as long as HMAC is not broken as a PRF. >>> >> >> Well, looks like that problem got sorted out (by getting the "HSM folks" >> to >> actually state the actual requirements). >> >> >> -Ilari >> >> _______________________________________________ >> 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 > --089e0160b7d44b87dc0514a67aa4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Indeed, HKDF-extract(0, g^xy) is equivalent= to =E2=80=8BHash( opad || Hash( ipad || g^xy ) )
but t= hat is only for computing an intermediate key which is then used to key HKD= F-expand for actual key derivation where the input to this derivation inclu= des the 'info' field (label + digest of handshake messages).
You are right that in the case of Master Secret, the key = derivation in TLS 1.2 is more complicated-looking (actually, it is very sim= ilar to deriving Master Secret using full HKDF instead of HKDF_Extract only= ) but just being complicated-looking is not a guarantee of additional secur= ity (*). A well structured uniform scheme as HKDF that serves multiple purp= oses in a single design is much cleaner and amenable to analysis. Security = by obscurity (or by "complicatity") is never a good idea. And the= multi-purpose properties of HKDF are not just academic advantages, but=C2= =A0 a property of HKDF that serves TLS 1.3 very well, for example to streng= then the application keys by making them depend on both long-term and ephem= eral keying material.

Hugo

=
(*) Just for fun, if you compare Hash( opa= d || Hash( ipad || g^xy ) ) to your preferred
=E2= =80=8B =E2=80=8B
Hash(g^xy ^ opad || Hash( (g^xy ^ ipad)
=E2=80=8B ) you can note that if g^xy is longer than the hash b= lock, your security gets limited to that block length while in the former t= his is not necessarily the case. I am not suggesting that this is a practic= al advantage of the former, just giving it as an example of why complicatin= g things do not necessarily help and many times can actually hurt. The more= structural issue here is not to use a non-uniform key, as=C2=A0 g^xy may b= e, as a HMAC key directly.=E2=80=8B


On Sat, Apr 25, 2015 at 1:59 AM, Andrey Jivsov <crypto@brainhub.org= > wrote:
On 04/24/2015 10:34 PM, Ilari Liusvaara wrot= e:
On Fri, Apr 24, 2015 at 05:31:51PM -0400, Hugo Krawczyk wrote:
Here are a few clarifications regarding HKDF and its use in TLS 1.3 in resp= onse
to recent emails (including those under the "HSM-friendly Key Computat= ion"
thread). I will not touch on anything specific to HSM or PKCS11 since I kno= w
little about these and the recent exchange on these issues has not helped m= e
understanding these things any better (but rather confuse me more).

Actually, for me, that HSM thread actually clarified what the actual requir= ements
are (which lets one minimize distruption).

Let me start with the issue of whether we should be using the HKDF-Extract = and
HKDF-Expand separately or only use HKDF as a single function (which interna= lly
operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for t= he
latter approach (single function) as it deals with HKDF as a black box.
But there are also advantages to calling these two components separately, a= nd
TLS 1.3 provides some good examples for that. First, HKDF is built to outpu= t as
many keys as needed from a single HKDF operation, but in TLS we are derivin= g
multiple keys from the same keying material through separate applications o= f the
expand part. In such a case it is more natural to apply extract once and ap= ply
expand several times (with different info fields!). For example, Master Sec= ret
is derived using a single Extract operation but it is then used in three different Expand operations for deriving other keys (application traffic ke= ys,
export master secret, and resumption master secret). Second, when one start= s with
a strong key then the Extract step can be skipped making it convenient to b= e
able to call Expand directly. Third, it is convenient to call Expand direct= ly as
a PRF for computing the Finished message. Lastly, and not least, it makes t= he
key derivation logic more explicit which helps conveying the rationale of e= ach
operation and helps those analyzing the protocol (now and in the future).

Some models derive even more things out of (handshake) MS, e.g. one model d= oes:
- s2c_appMS.
- eMS
- Unique
- c2s_appMS.
- rPMS

My recommendation is to keep the Extract and Expand separation for the mome= nt,
in particular due to the last point, so we can see more clearly the logic w= hile
still setting the missing details of the protocol. When the whole picture i= s
clear we can revisit this point.

On other issues:

- This should be obvious but worth repeating: All calls to HKDF-Expand MUST= use
=C2=A0 =C2=A0a non-empty info field binding the derived key(s) to a unique = context (in the
=C2=A0 =C2=A0case of TLS this is usually a label and a cumulative session-h= ash).

- It was suggested that the length of derived keys should be part of the in= put
=C2=A0 =C2=A0to key expansion. If desired, this length can be entered throu= gh the info
=C2=A0 =C2=A0field of HKDF but I would be very careful not to derive two di= fferent keys
=C2=A0 =C2=A0where the only difference in the 'info' values is the = key length. If the two
=C2=A0 =C2=A0keys happen to be of the same length one would end up with two= keys that are
=C2=A0 =C2=A0identical.

Well, there would still be string input of what the key is (otherwise e.g. = rPMS
and eMS might up ending being the same, which isn't desirable).

- One of the emails raises the issue of using random salt, as recommended b= y RFC
=C2=A0 =C2=A05869. Note that the RFC recommendation also indicates that the= salt value
=C2=A0 =C2=A0should be something that is authenticated during the protocol,= or otherwise it
=C2=A0 =C2=A0can be selected by the adversary. This authentication needs to= happen
=C2=A0 =C2=A0independently of the key being derived using this salt. For ex= ample, one
=C2=A0 =C2=A0should be careful not to incur in a circular logic, e.g. deriv= ing a key
=C2=A0 =C2=A0mackey=3DHKDF(salt, info) and then using mackey to authenticat= e the salt by
=C2=A0 =C2=A0computing MAC(mackey, salt). This is why the proposed TLS 1.3 = key derivation
=C2=A0 =C2=A0scheme does not use nonces as salt.

With fixed salts, the HKDF extract function is essentially H1(H2(x)), where=
H1 and H2 are H, but with different (pseudorandom) IVs.

Ilari beat me on this, but I also made this observation. In more details:
According to intended use of HKDF, HKDF-Extract is this:

=C2=A0 =C2=A0HMS =3D HKDF-Extract( salt=3D0, IKM=3Dg^xy )

Which is:

=C2=A0 =C2=A0A. HMAC( 0, g^xy ) =3D Hash( opad || Hash( ipad || g^xy ) ).
The two invocations of the Hash() begin with hashing fixed values, so one c= an re-write the A as

=C2=A0 =C2=A0A1: Hash1( Hash2( g^xy ) ),

which can be rewritten as

=C2=A0 =C2=A0A2: Hash3( g^xy ) =3D
=E2=80=8B=E2= =80=8B
Hash( opad || Hash( ipad || g^xy ) )

Therefore, HKDF-Extract( 0, g^xy ) should be viewed as deterministic hash o= f g^xy and that's the only contribution of g^xy in HKDF.

For comparison, TLS 1.2 does the following in the first step:

=C2=A0 =C2=A0B.
=E2=80=8B=E2=80=8B
Hash(g^xy= ^ opad || Hash( (g^xy ^ ipad) || "master secret" + ClientHello.r= andom + ServerHello.random) ) );

It would be amusing to see a case when A2 is secure, while B is not.


Also, handshake hashes are very hard to control to any significant degree (= or
invoking HKDF with bad salt is the least of your worries).

E.g. Suppose prf-hash is 256-bit MD5-equivalent-security. The handshake
security just breaks catastrophically against active attacks (passive attac= ks
are another matter).

- Another issue raised in recent email exchange is the way to merge the
=C2=A0 =C2=A0semi-static value g^xs (where s is the semi-static server'= s private key and x
=C2=A0 =C2=A0the ephemeral client's private key) with the ephemeral val= ue g^xy.

"the semi-static server's private key"??? There is no "t= he key". There's the old
semi-static key (which may not be available), and the new semi-static key. = And
the two may or may not be the same key, and those keys may not even be avai= lable.

Also, in certain conditions, not mixing in DH result with the old key actua= lly
leads to an attack (mixing the new one does not help here).

Also, I heard some implementers complaining about mixing the new one, and a= fter
calculating the time penalty, I can easily understand (it is pretty sizable= ).

=C2=A0 =C2=A0This is done by first extracting a key from g^xs as PRK1=3DHKD= F-extract(0,g^xs)
=C2=A0 =C2=A0and then extracting PRK2=3DHKDF-extract(PRK1,g^xy).
=C2=A0 =C2=A0Here is the logic: PRK1 is extracted from g^xs using HKDF(0,..= .) as a random
=C2=A0 =C2=A0oracle as needed in the proof of security. Then PRK2 is derive= d with salt=3DPRK2
=C2=A0 =C2=A0for the following reason. If g^xs is not exposed (the typical = case) then this
=C2=A0 =C2=A0HKDF use only requires treating HKDF(PRK1,...) as a PRF (essen= tially the less
=C2=A0 =C2=A0demanding property from HKDF).=C2=A0 If g^xs is revealed by co= mpromise of the
=C2=A0 =C2=A0server's semi static private key s (after the conclusion o= f the handshake, as
=C2=A0 =C2=A0in the forward-secrecy setting), then PRK1 is actually an auth= enticated random
=C2=A0 =C2=A0and non-secret salt so you use HKDF as a randomness extractor.=
=C2=A0 =C2=A0In other words, each use of HKDF uses the minimal cryptographi= c assumption one
=C2=A0 =C2=A0can have depending on the context of derivation.

If it is the new one, it is not properly authenticated (have I mentioned ho= w nasty
even capturing the proper assumptions is?).

- Finally, there has been a long discussion related to the derivation of bo= th
=C2=A0 =C2=A0secret and non-secret material (the latter for IVs). I can'= ;t say how this
=C2=A0 =C2=A0works with HSMs, PKCS11 or other standards, but from the crypt= ographic point
=C2=A0 =C2=A0of view doing this "mixed" derivation of secret and = non-secret values is
=C2=A0 =C2=A0not a=C2=A0 problem as long as HMAC is not broken as a PRF.

Well, looks like that problem got sorted out (by getting the "HSM folk= s" to
actually state the actual requirements).


-Ilari

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


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

--089e0160b7d44b87dc0514a67aa4-- From nobody Sun Apr 26 13:34: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 0A59B1A1E0B for ; Sun, 26 Apr 2015 13:34: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 ugpod_KEO4fj for ; Sun, 26 Apr 2015 13:34:27 -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 243A51A8FD5 for ; Sun, 26 Apr 2015 13:34:26 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id EE9903FF5; Sun, 26 Apr 2015 23:34:23 +0300 (EEST) Date: Sun, 26 Apr 2015 23:34:23 +0300 From: Ilari Liusvaara To: Michael StJohns Message-ID: <20150426203423.GA6935@LK-Perkele-VII> References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> <20150426182025.GA3549@LK-Perkele-VII> <553D49F8.10209@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <553D49F8.10209@nthpermutation.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara 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, 26 Apr 2015 20:34:29 -0000 On Sun, Apr 26, 2015 at 04:26:32PM -0400, Michael StJohns wrote: > On 4/26/2015 2:20 PM, Ilari Liusvaara wrote: > >>There is no reason to treat the 96 bit quantity as secret and no one else > >>>does. > >Oh, except SSH. The session nonce is 96 bits and secret. > > SSH uses CBC exclusively as far as I can tell. The fact that the mixin of > the first block of the first message (AKA the initial IV) is generated via > keyed material from the negotiated shared secret is actually a problem > (similar to the problems in TLS 1.2 and before) and doesn't actually provide > any security. SSH can also use: - CTR (start from 128-bit secret initial IV, no packet boundaries) - AES-GCM (96 bit secret initial IV, increments per packet) - Chacha20-Poly1305 (uses message sequence as nonce) (In fact, I think the semi-offical recommendation is "don't use CBC in SSH"). -Ilari From nobody Sun Apr 26 13:52: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 508831A90EC for ; Sun, 26 Apr 2015 13:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 efAqZwU7-1zb for ; Sun, 26 Apr 2015 13:52:09 -0700 (PDT) Received: from mail-vn0-f45.google.com (mail-vn0-f45.google.com [209.85.216.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 7AAC91A90CD for ; Sun, 26 Apr 2015 13:52:09 -0700 (PDT) Received: by vnbg62 with SMTP id g62so9673687vnb.6 for ; Sun, 26 Apr 2015 13:52:08 -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=VT3IA+q6MfJL9FBznjYXcXxHj/LkRft10ZqHawGH31E=; b=B9s52WsHtHE3H3g3pQTh14nwKb9qwiSjTJLypOeu5AzAR7iZoR+c+TsiLEZ7Cjyhcd Xx2vnY/rcKIjyXwc/bzuehUbN1eWHAuNGj8/4IuxqHPcLTSoAzmdtzCCyX1d/j5HOmmS upbkYGy+wXGrO1Y8NOtFtwkpnwGayCcwhevA1iVxxkhrQVEPKqxqBbnnwvNRFr0GKz9U k4Db+E2v8qJE2u1+eDn7qYfuF4asuTOZEsoYQ9iHlMCw7Ms4sqDIRgkftlLKUYScWnyd 8VOZbQywZQLPKsRwRJHdb1YDeWAxWr7iO30TG3/scqgFfM05AqqnvUeiZeXoQoUjoe+q DXGw== X-Gm-Message-State: ALoCoQkTZ79DeYyEc1WcJSXVUPJ8lpTewkiu0DQTbrelry0OzgKq4Kts+u7dm8PGBEr9P9mV1m/v X-Received: by 10.52.136.66 with SMTP id py2mr20248427vdb.75.1430081528636; Sun, 26 Apr 2015 13:52:08 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id x11sm20375714vds.25.2015.04.26.13.52.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 13:52:08 -0700 (PDT) Message-ID: <553D4FF7.8080700@nthpermutation.com> Date: Sun, 26 Apr 2015 16:52:07 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Hugo Krawczyk References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090500020809070600000109" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2015 20:52:11 -0000 This is a multi-part message in MIME format. --------------090500020809070600000109 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'm going to slice this up a bit and answer in pieces. Sorry - the messages are getting too long. On 4/26/2015 4:20 PM, Hugo Krawczyk wrote: > ​I am completely lost on this length issue. Can you give me a concrete > example where TLS 1.3 derives different keys with same label and > context but with different output lengths? As said, in TLS 1.3 each > label and context is used exactly once. I must be missing something in > your argument but I just can't figure what's that. Hi Hugo - This isn't about TLS specifically, but about how an HSM makes sure an attacker can't extract TLS keys. Assume that you implement your function in an HSM as you've defined in the RFC - without the length term. Consider that the HSM keys may be USED by the attacker but the HSM is set up to prevent extraction - the keys can't be directly extracted . (See below for a discussion of how this might happen). And note that for a generic KDF interface, you can't ensure that the attacker doesn't use the same label and context in his call to use the master key as we define for TLS. Consider that the derivation of the master secret from the pre-master secret can be done by both the user and the attacker, but that the attacker can request a key length of 1, but with the same label and context terms using the same pre-master secret. Consider that the attacker designates this Length 1 key as an HMAC key. The attacker now uses his version of the derived key as an HMAC key and uses it to generate an HMAC tag over a fixed value. He then compares this to 256 generated HMACs over the same fixed value but using the 256 different possible values of the derived key from above. When he finds a match between one of his 256 HMACs and the HMAC using the derived key, he now knows that the value of that derived key. Consider that _without the length term, a key of length 1 has as its key value the same first byte of any key stream of longer length generated from the same master key with the same label and context_. By repeating the steps above, you can extract the master secret in O(1). If the L term is mixed in by internal mechanism, there is no user accessible mechanism to accomplish this. I.e. using the same secret with identical labels and contexts with differing requested output lengths produce cryptographically disjoint key material. If you only pass this in as user specified material you don't get this protection. If you ask me how an attacker can "use" the keys of someone else, consider that most versions of PKCS11 support only a PIN based authentication, or authentication is done because the HSM is embedded in the system. The thing I'm trying to get to is a model where I can demonstrate that key material may not be extracted from an HSM by an attacker, even if the attacker has credentials to "use" the keys. Mike --------------090500020809070600000109 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I'm going to slice this up a bit and answer in pieces.  Sorry - the messages are getting too long.

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
​I am completely lost on this length issue. Can you give me a concrete example where TLS 1.3 derives different keys with same label and context but with different output lengths? As said, in TLS 1.3 each label and context is used exactly once. I must be missing something in your argument but I just can't figure what's that.

Hi Hugo -

This isn't about TLS specifically, but about how an HSM makes sure an attacker can't extract TLS keys. 

Assume that you implement your function in an HSM as you've defined in the RFC - without the length term.

Consider that the HSM keys may be USED by the attacker but the HSM is set up to prevent extraction - the keys can't be directly extracted . (See below for a discussion of how this might happen).  And note that for a generic KDF interface, you can't ensure that the attacker doesn't use the same label and context in his call to use the master key as we define for TLS. 

Consider that the derivation of the master secret from the pre-master secret can be done by both the user and the attacker, but that the attacker can request a key length of 1, but with the same label and context terms using the same pre-master secret.  Consider that the attacker designates this Length 1 key as an HMAC key.

The attacker now uses his version of the derived key as an HMAC key and uses it to generate an HMAC tag over a fixed value.  He then compares this to 256 generated HMACs over the same fixed value but using the 256 different possible values of the derived key from above.  When he finds a match between one of his 256 HMACs and the HMAC using the derived key, he now knows that the value of that derived key.

Consider that without the length term, a key of length 1 has as its key value the same first byte of any key stream of longer length generated from the same master key with the same label and context.

By repeating the steps above, you can extract the master secret in O(1).

If the L term is mixed in by internal mechanism, there is no user accessible mechanism to accomplish this.  I.e. using the same secret with identical labels and contexts with differing requested output lengths produce cryptographically disjoint key material.    If you only pass this in as user specified material you don't get this protection.

If you ask me how an attacker can "use" the keys of someone else, consider that most versions of PKCS11 support only a PIN based authentication, or authentication is done because the HSM is embedded in the system.  The thing I'm trying to get to is a model where I can demonstrate that key material may not be extracted from an HSM by an attacker, even if the attacker has credentials to "use" the keys.

Mike

--------------090500020809070600000109-- From nobody Sun Apr 26 14:18: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 BF6E71A1B89 for ; Sun, 26 Apr 2015 14:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyPII3UKh29e for ; Sun, 26 Apr 2015 14:18:41 -0700 (PDT) Received: from mail-vn0-f45.google.com (mail-vn0-f45.google.com [209.85.216.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 A1FDB1A1B57 for ; Sun, 26 Apr 2015 14:18:41 -0700 (PDT) Received: by vnbg190 with SMTP id g190so9710759vnb.8 for ; Sun, 26 Apr 2015 14:18:41 -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 :content-transfer-encoding; bh=myh3mGECi3pzyYR4leyBK7jtGDxDN/poF10BrRTv+a4=; b=Hlpvd4WVMAqsxqUKWzQyRrza4z+nufrqgqTjEYL/awB0VtelUEo/2gjVeMT0GjulgP hHdw5TanRgimjM7djLCPkhQ0BiM7tWoyOVIPhrxfWfA8IDpJs6AZ2L4LOy/g4mTeD06l Hito8Sk+T2DyEROZo2yOXroWUF90tm/xBtD/o/UxqPfTK5pjbziK6873Li13jdaNVswR P2OdwQzUg1RA0KT3i3CmicApdu7VxLh3FL8oDBmscYbexRA6YtHbNyhEcoNobrpK0kUE NJ7Hgur95mn38+jFpSByCcRXX1r7dWx8wahVZHiGXjJuntD4j0jfvqAVFL7YlK0b78pn q9Fw== X-Gm-Message-State: ALoCoQk6xIIzYJ+dRfGP/LpJQ+yN+RUnhZioNHu67oJx504atGse70jix5Q85BhhmsYvRGzB9EU5 X-Received: by 10.52.103.48 with SMTP id ft16mr20497735vdb.81.1430083120925; Sun, 26 Apr 2015 14:18:40 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id q9sm20532340vdb.20.2015.04.26.14.18.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 14:18:40 -0700 (PDT) Message-ID: <553D562F.3090704@nthpermutation.com> Date: Sun, 26 Apr 2015 17:18:39 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ilari Liusvaara References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> <20150426182025.GA3549@LK-Perkele-VII> <553D49F8.10209@nthpermutation.com> <20150426203423.GA6935@LK-Perkele-VII> In-Reply-To: <20150426203423.GA6935@LK-Perkele-VII> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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, 26 Apr 2015 21:18:42 -0000 On 4/26/2015 4:34 PM, Ilari Liusvaara wrote: > On Sun, Apr 26, 2015 at 04:26:32PM -0400, Michael StJohns wrote: >> On 4/26/2015 2:20 PM, Ilari Liusvaara wrote: >>>> There is no reason to treat the 96 bit quantity as secret and no one else >>>>> does. >>> Oh, except SSH. The session nonce is 96 bits and secret. >> SSH uses CBC exclusively as far as I can tell. *sigh* I looked at the original SSH rfc and for some reason none of the new modes were added to that RFC as "Updates". >> The fact that the mixin of >> the first block of the first message (AKA the initial IV) is generated via >> keyed material from the negotiated shared secret is actually a problem >> (similar to the problems in TLS 1.2 and before) and doesn't actually provide >> any security. > SSH can also use: > - CTR (start from 128-bit secret initial IV, no packet boundaries) > - AES-GCM (96 bit secret initial IV, increments per packet) > - Chacha20-Poly1305 (uses message sequence as nonce) > > (In fact, I think the semi-offical recommendation is "don't use CBC in SSH"). The fact that SSH was designed with CBC and that you got no security from CBC by doing it this way is the key point. The fact that new modes have come along and just used what they were handed doesn't really add to the "the IV must be secret" argument. In other words, it wasn't done this way originally to increase security so using it as an example for good practice is probably somewhat bogus. > > > -Ilari > > From nobody Sun Apr 26 14: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 BFE9E1A6EF1 for ; Sun, 26 Apr 2015 14:28:59 -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 KleLRNSl_ubq for ; Sun, 26 Apr 2015 14:28:58 -0700 (PDT) Received: from mail-vn0-f52.google.com (mail-vn0-f52.google.com [209.85.216.52]) (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 86F4A1A1A4B for ; Sun, 26 Apr 2015 14:28:58 -0700 (PDT) Received: by vnbf62 with SMTP id f62so9740433vnb.13 for ; Sun, 26 Apr 2015 14:28:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3Hze+ue6C2nWWzbzsOrUQcBIe7fscRYz3/QqoQPuDPw=; b=DTp5HIqE9kXM/anirilfZCCQc61aoPkpmjNl1CykAl1lTEAdFUxraXqpNQVi0ySOlc g0j85G3gR7AiZetnlMHPBliT54TI4YHfWGicNgY6ewco1iOC0596XLQNcrzpSifvz83P 9iWPvfwdht0L6HBT5iT4BdAboZTjSyTBqqLO2+T/d2h89bwgXDsGG4X04IaOUn6yPUz0 iTTG04oUM7HXpLFLvN/wQvU7eN1D+vm7Gc7Xrw81DIZcGe3X7DZHcyO/foOaldHCqPEh 7CeUVNdIEFH5SEjnJ4zneLfF7VDE/GsVdgZsPEN/Yv3qviGB+ucCKn4ugvHXpNZvy52q tEwA== X-Gm-Message-State: ALoCoQnps3VqybcGF395L3YmXLdJksQouRg3GjcqrxXm9xED+ML3hmghIyCwQ7LDC5gpalUBbFWQ X-Received: by 10.52.252.74 with SMTP id zq10mr20667158vdc.18.1430083737764; Sun, 26 Apr 2015 14:28:57 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id hq1sm20593845vdb.24.2015.04.26.14.28.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 14:28:57 -0700 (PDT) Message-ID: <553D5898.3090902@nthpermutation.com> Date: Sun, 26 Apr 2015 17:28:56 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ilari Liusvaara References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> <20150426182025.GA3549@LK-Perkele-VII> In-Reply-To: <20150426182025.GA3549@LK-Perkele-VII> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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, 26 Apr 2015 21:28:59 -0000 On 4/26/2015 2:20 PM, Ilari Liusvaara wrote: >> There is no reason to treat the 96 bit quantity as secret and no one else >> >does. > (To lesser extent, IPSEC, there the session nonce is 32 bits and secret). > This is directly from section 2.3 of the IPSec ESP RFC 4303 > With regard to ensuring the alignment of the (real) ciphertext in the > presence of an IV, note the following: > > o For some IV-based modes of operation, the receiver treats > the IV as the start of the ciphertext, feeding it into the > algorithm directly. In these modes, alignment of the start > of the (real) ciphertext is not an issue at the receiver. > > > o In some cases, the receiver reads the IV in separately from > the ciphertext. In these cases, the algorithm specification > MUST address how alignment of the (real) ciphertext is to be > achieved. And RFC4309 - CCM mode has this: > ESP Payload > > The ESP payload is composed of the IV followed by the ciphertext. > The payload field, as defined in [ESP], is structured as shown in > Figure 1. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Initialization Vector | > | (8 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Encrypted Payload (variable) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Authentication Data (variable) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Again, newer modes may have done something else, but the above is strong indication that IVs were not generated as secrets as a general matter. Later, Mike From nobody Sun Apr 26 15:26: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 3C6BC1A1B28 for ; Sun, 26 Apr 2015 15:26: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 dDhjIgjRpM3V for ; Sun, 26 Apr 2015 15:26:11 -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 D3C5A1A1A82 for ; Sun, 26 Apr 2015 15:26:10 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so71254470wic.1 for ; Sun, 26 Apr 2015 15:26:09 -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=UntRRlmPf1LdKpzJJMn1f4WTKdPeJmQkElOhyT/YbRw=; b=z6B24uSj5yTlU+SqjhoFTo/jC6sI84H969n5cdX5JUPRNmbU+PnaQcL0KbwNQNasWu kxYsmmRiP/9jWifRN2rI8iHnBAKllra6Q7cqQFZPLz9sZPOlMQdrINUhiHxA7YwcDpOI P/tVoTBj2BBngQo0W3XCM3PflJb/9c2nr4iNL0S4ICBQO0TfKKzhkIlGhU/J4mtSM/N4 fBiqkr7uwLTzhbyDanwg0AIja+YsSopgNOV1jv9mGU0pklddDKBSkKasu14xpVojE8kn Y9nK1fscFib5QKW2X9PTKBU8ZgUhikwcABsO5u9bxFPpKl09z98cAQXnglE5Dip0X6Pf Gpgg== X-Received: by 10.180.105.233 with SMTP id gp9mr15483138wib.83.1430087169587; Sun, 26 Apr 2015 15:26:09 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id g11sm316005wjr.25.2015.04.26.15.26.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Apr 2015 15:26:08 -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: <553D5898.3090902@nthpermutation.com> Date: Mon, 27 Apr 2015 01:26:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3E5464E9-80BF-4D2E-A6C1-EF4E47A99268@gmail.com> References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> <20150426182025.GA3549@LK-Perkele-VII> <553D5898.3090902@nthpermutation.com> To: Michael StJohns 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, 26 Apr 2015 22:26:13 -0000 Both CCM and GCM use a concatenation of the explicit IV (which is = obviously not secret and allowed to be predictable) with a salt that is = derived from the keying material. This concatenation forms the nonce = which is input to the AEAD. RFC 4309 (CCM) says "The salt value need not be secret, but it MUST NOT = be predictable prior to the beginning of the security association.=E2=80=9D= RFC 4106 (GCM) says "The salt SHOULD be unpredictable (i.e., chosen at = random) before it is selected, but need not be secret.=E2=80=9D The ChaCha20-Poly1305 for IPsec draft does the same thing, and in fact = so does RFC 5288 (AES-GCM for TLS 1.2) So no, that salt (and by extension, the proposed 96-bit value) need not = be secret, but it=E2=80=99s never transmitted. This also shows that = there is good precedent for generating such a = doesn=E2=80=99t-really-need-to-be-secret value from the key_block or = KEYMAT. Yoav > On Apr 27, 2015, at 12:28 AM, Michael StJohns = wrote: >=20 > On 4/26/2015 2:20 PM, Ilari Liusvaara wrote: >>> There is no reason to treat the 96 bit quantity as secret and no one = else >>> >does. >> (To lesser extent, IPSEC, there the session nonce is 32 bits and = secret). >>=20 >=20 > This is directly from section 2.3 of the IPSec ESP RFC 4303 >=20 >=20 >> With regard to ensuring the alignment of the (real) ciphertext in the >> presence of an IV, note the following: >>=20 >> o For some IV-based modes of operation, the receiver treats >> the IV as the start of the ciphertext, feeding it into the >> algorithm directly. In these modes, alignment of the = start >> of the (real) ciphertext is not an issue at the receiver. >>=20 >>=20 >> o In some cases, the receiver reads the IV in separately = from >> the ciphertext. In these cases, the algorithm = specification >> MUST address how alignment of the (real) ciphertext is to = be >> achieved. >=20 > And RFC4309 - CCM mode has this: >=20 >> ESP Payload >>=20 >> The ESP payload is composed of the IV followed by the ciphertext. >> The payload field, as defined in [ESP], is structured as shown in >> Figure 1. >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Initialization Vector = | >> | (8 octets) = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> ~ Encrypted Payload (variable) = ~ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> ~ Authentication Data (variable) = ~ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 >=20 > Again, newer modes may have done something else, but the above is = strong indication that IVs were not generated as secrets as a general = matter. >=20 > Later, Mike >=20 From nobody Sun Apr 26 16:24: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 0C89D1ACD39 for ; Sun, 26 Apr 2015 16:24:11 -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 XBCdaRRaT2jY for ; Sun, 26 Apr 2015 16:24:09 -0700 (PDT) Received: from mail-vn0-f45.google.com (mail-vn0-f45.google.com [209.85.216.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 7903F1ACD38 for ; Sun, 26 Apr 2015 16:24:09 -0700 (PDT) Received: by vnbf190 with SMTP id f190so9959193vnb.1 for ; Sun, 26 Apr 2015 16:24:08 -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 :content-transfer-encoding; bh=KHJNTuaeRWBDDvhz7meo+w4N+Xwi81xJioqSWTcqsHk=; b=S5xkcCWDe29l/+OgVhdSHUrvTGr68GPop/UTwd2Aop8YLG3ZGIDJHKmNPcaDUfw6Fk 7iQvs5GYgBTeBlWRXKZ2w7qV3l7OKsDB2w67+WQEshEesquSjDrxZ3t5pXwFUhOSAxh9 KOAUtNrqbuGQs77WSvvpmV6giipOhU06m+wO2FVbn+X5Y2ChWTc77SCD0ecflWshnQKb WmitHhb6XO7Xr8RQpAEoFbCifU3X9J6LPYe6QdOV8n8qDItRYxYg6qpNqmCEoacJXUbi k93kHQr+gVELcpFLaZbRmeBbmjVtf9q3IBeGcwh/7WioQJAEGJubDL3CwqQBvrgfeLgz pmYA== X-Gm-Message-State: ALoCoQkwGgTUJto7gaIVHajQT42ty8DuLTQkt/c8TT4hnsx7pFLtXP7B9LqRH+01uxqKH7MbF42T X-Received: by 10.52.143.233 with SMTP id sh9mr21544599vdb.26.1430090648514; Sun, 26 Apr 2015 16:24:08 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id mk16sm21237196vdb.12.2015.04.26.16.24.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 16:24:08 -0700 (PDT) Message-ID: <553D7397.9090000@nthpermutation.com> Date: Sun, 26 Apr 2015 19:24:07 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yoav Nir References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> <20150426182025.GA3549@LK-Perkele-VII> <553D5898.3090902@nthpermutation.com> <3E5464E9-80BF-4D2E-A6C1-EF4E47A99268@gmail.com> In-Reply-To: <3E5464E9-80BF-4D2E-A6C1-EF4E47A99268@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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, 26 Apr 2015 23:24:11 -0000 On 4/26/2015 6:26 PM, Yoav Nir wrote: > Both CCM and GCM use a concatenation of the explicit IV (which is obviously not secret and allowed to be predictable) with a salt that is derived from the keying material. This concatenation forms the nonce which is input to the AEAD. Which protocol are we talking about? CCM and GCM - as generic functions - use a per message Nonce. CCM defines a block formatting function (Appendix A of the Nist Document) that takes a nonce of 1-15 octets. David Mc Grew's RFC on AEAD functions APIs fixes the length of that nonce to 12 bytes because that's the most common length for GCM. That per message nonce (back to the generic again) can be created from the combination of a per-session nonce and a sequence number, randomly generated or derived from key material. HSMs generally implement the generic interfaces described in the base CCM and GCM documents, and David Mc Grew's RFC on AEAD is a subset of those possibilities and is therefor usable with the generic interfaces. > > RFC 4309 (CCM) says "The salt value need not be secret, but it MUST NOT be predictable prior to the beginning of the security association.” > RFC 4106 (GCM) says "The salt SHOULD be unpredictable (i.e., chosen at random) before it is selected, but need not be secret.” In IPSEC GCM, the IV is explicitly included in each packet (see section 3.1 of RFC4106) and hence is not secret in any way shape or form. In IPSEC CCM, the IV is also explicitly included in each packet - see section 3 and 3.1 of RFC 4309. Hence, also never secret in any way shape or form. > The ChaCha20-Poly1305 for IPsec draft does the same thing, and in fact so does RFC 5288 (AES-GCM for TLS 1.2) Citing your own draft as proof of your own argument is a bit.... well... In any event, I note that your IPSEC draft doesn't actually describe the ESP payload format, so without that, I'd make the assumption that the IV is included before the payload as is described in the IPSEC ESP document. > > So no, that salt (and by extension, the proposed 96-bit value) need not be secret, but it’s never transmitted. In which of the above? Maybe in the chacha20 draft... but not in the other two. And RFC5288 does it the wrong way - getting IV (session nonce) material from the same key stream as key material. That hopefully will be fixed with TLS1.3. It would have been much more preferable to use a zero session nonce than extract it from the key stream. > This also shows that there is good precedent for generating such a doesn’t-really-need-to-be-secret value from the key_block or KEYMAT. I'm pretty sure it doesn't. It just shows a continuous misunderstanding of the problems with doing it this way. There are ways to mitigate this a bit - but they require ensuring complete cryptographic isolation from key generation and a method of non-secret but not disclosed information that can still be used with the generic interfaces. There was a good precedence for using RC4 and MD5 because they were fast and in wide use, but we've learned. Later, Mike > > Yoav > >> On Apr 27, 2015, at 12:28 AM, Michael StJohns wrote: >> >> On 4/26/2015 2:20 PM, Ilari Liusvaara wrote: >>>> There is no reason to treat the 96 bit quantity as secret and no one else >>>>> does. >>> (To lesser extent, IPSEC, there the session nonce is 32 bits and secret). >>> >> This is directly from section 2.3 of the IPSec ESP RFC 4303 >> >> >>> With regard to ensuring the alignment of the (real) ciphertext in the >>> presence of an IV, note the following: >>> >>> o For some IV-based modes of operation, the receiver treats >>> the IV as the start of the ciphertext, feeding it into the >>> algorithm directly. In these modes, alignment of the start >>> of the (real) ciphertext is not an issue at the receiver. >>> >>> >>> o In some cases, the receiver reads the IV in separately from >>> the ciphertext. In these cases, the algorithm specification >>> MUST address how alignment of the (real) ciphertext is to be >>> achieved. >> And RFC4309 - CCM mode has this: >> >>> ESP Payload >>> >>> The ESP payload is composed of the IV followed by the ciphertext. >>> The payload field, as defined in [ESP], is structured as shown in >>> Figure 1. >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Initialization Vector | >>> | (8 octets) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> ~ Encrypted Payload (variable) ~ >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> ~ Authentication Data (variable) ~ >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Again, newer modes may have done something else, but the above is strong indication that IVs were not generated as secrets as a general matter. >> >> Later, Mike >> > > From nobody Sun Apr 26 16:50: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 BA17A1ACDDF for ; Sun, 26 Apr 2015 16:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv1I6129uu2F for ; Sun, 26 Apr 2015 16:50:41 -0700 (PDT) Received: from mail-vn0-f41.google.com (mail-vn0-f41.google.com [209.85.216.41]) (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 198F61ACDFF for ; Sun, 26 Apr 2015 16:50:41 -0700 (PDT) Received: by vnbg7 with SMTP id g7so9983376vnb.11 for ; Sun, 26 Apr 2015 16:50:40 -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=B7sSD9wn+qdUu94oUrG679pza6Uw1h0mmiJPJJlkj9E=; b=XGel7/nzle7jR2DA8ytMRlwcRsmVDBn/1AvHQrFLHMplMzjpKtAbyl3Du14JtGNbPm dh0cCjHVPUDNW8+uiOzLRJQdDyv5/wSudBHHcl7ByJbGupF2je0EHQLdJ4R0JdP4q6Dv 3g4a+KvmVTlljYy6jBdWrvj3R5D0UqBLmvKn6PZ0FPvHpsORMQ0sV5pxg0OFAF4xevNe ki/e0cZrObC9Tx7HAvUbRBWPdiMz5WTzOb2xYZ60FTxpy9gN8velP61SRLG5zcQbEwVa +Q0t2HehNZmv/g6UDzMpgwcGW8SNbNkprM+78Lwi9py1NI19G6INRBTLioIyDjpSqVt/ k3Zg== X-Gm-Message-State: ALoCoQn4YN5y7nORB0tz8eXz9If75ZiPmgiXMPFMYCM4rOfVVuGBLnrCoI0CKZ+4b7NkLGtR0eQ5 X-Received: by 10.52.3.10 with SMTP id 10mr21612883vdy.74.1430092240286; Sun, 26 Apr 2015 16:50:40 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id j9sm21418066vdi.28.2015.04.26.16.50.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 16:50:39 -0700 (PDT) Message-ID: <553D79CE.1030504@nthpermutation.com> Date: Sun, 26 Apr 2015 19:50:38 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Hugo Krawczyk References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000801010009020508020903" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2015 23:50:42 -0000 This is a multi-part message in MIME format. --------------000801010009020508020903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/26/2015 4:20 PM, Hugo Krawczyk wrote: > > TLS1.2 uses the Master secret as a key for both the MAC and KDF > functions and that needs to change. Those can't be the same key - > and hence your comment about using the same master secret for > different derives becomes problematic especially if one of the > outputs is to an exporter. > > > ​ The same Master Secret is used to derive multiple keys but these are > derived with unique label+context input.​ > ​ > ​ Different derivations *never* use the same label+context.​ Next part of the discussion. Pretend you're implementing this in an HSM. How does the HSM enforce the "never use same label and context"? Answer is that it can't and there isn't anything currently defined in the label or context that allows the HSM to do proper policy protection. What needs to happen here is to include in the calculation of the key stream sufficient values to ensure the key stream is completely different if the requested output (e.g. target keys and types) of the key stream is different. Consider as an HSM input to the TLS KDF the label "key expansion", the handle for a specific master_secret key and the client and server randoms concatenated as the context. Internally, the HSM will concatenate the label and context into what you call "info". The last set of inputs to the "key expansion" call to the KDF are the types and output lengths of the key material, but those aren't involved in the calculation of the key stream. If you call the HSM version of the KDF with a key, context and label and tell it to break things into 2 keys (for AES-CCM) of length 256 bits each you will produce a key stream of length 64 bytes. If I call the HSM version of the same KDF with the same key, context and label and tell it to produce a single HMAC-SHA256 key of length 8 bits I will get a single byte of key stream which is identical to your call above. Using the TLS 1.2 KDF I can even tell it to not produce any key material but to provide me with IVs - which have the same key stream material as from your call. All because the length and types of the keys to be produced are not mixed into the key stream production calculation. If I define the TLS KDF as HKDF with a context consisting of (from my now expired draft): struct { uint8 clientRandom[32]; /* ClientHello.random */ uint8 serverRandom[32]; /* ServerHello.random */ uint32 keyCount; /* Num keys to derive */ KeyType keyTypes[keycount]; uint16 keyLengths[keycount]; /* Key lengths in bits */ } KeyExpansionContext; the HSM can use the key types and lengths to enforce policy of key assignment. An attacker can no longer assign a part of the key stream to shorter keys since the key stream changes if the length of any subkey changes. It can no longer assign a strong mechanism key to a weaker mechanism because if the key type changes so does the key stream. After discussions on the list, I'd probably also add a uint16 of flags per key to allow for some keys to be exported (and allow the HSM to know which ones are exportable). There are other issues, but this gets us closer. Mike --------------000801010009020508020903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
TLS1.2 uses the Master secret as a key for both the MAC and KDF functions and that needs to change.  Those can't be the same key - and hence your comment about using the same master secret for different derives becomes problematic especially if one of the outputs is to an exporter.

​ The same Master Secret is used to derive multiple keys but these are derived with unique label+context input.​
​
​ Different derivations *never* use the same label+context.​


Next part of the discussion.

Pretend you're implementing this in an HSM.  How does the HSM enforce the "never use same label and context"?  Answer is that it can't and there isn't anything currently defined in the label or context that allows the HSM to do proper policy protection.

What needs to happen here is to include in the calculation of the key stream sufficient values to ensure the key stream is completely different if the requested output (e.g. target keys and types) of the key stream is different.

Consider as an HSM input to the TLS KDF the label "key expansion", the handle for a specific master_secret key and the client and server randoms concatenated as the context. Internally, the HSM will concatenate the label and context into what you call "info".   The last set of inputs to the "key expansion" call to the KDF are the types and output lengths of the key material, but those aren't involved in the calculation of the key stream.

If you call the HSM version of the KDF with a key, context and label and tell it to break things into 2 keys (for AES-CCM) of length 256 bits each you will produce a key stream of length 64 bytes.

If I call the HSM version of the same KDF with the same key, context and label and tell it to produce a single HMAC-SHA256 key of length 8 bits I will get a single byte of key stream which is identical to your call above.   Using the TLS 1.2 KDF I can even tell it to not produce any key material but to provide me with IVs - which have the same key stream material as from your call.  All because the length and types of the keys to be produced are not mixed into the key stream production calculation.


If I define the TLS KDF as HKDF with a context consisting of (from my now expired draft):
   struct {
       uint8    clientRandom[32];      /* ClientHello.random */
       uint8    serverRandom[32];      /* ServerHello.random */
       uint32   keyCount;              /* Num keys to derive */
       KeyType  keyTypes[keycount];
       uint16   keyLengths[keycount];  /* Key lengths in bits */
   } KeyExpansionContext;

the HSM can use the key types and lengths to enforce policy of key assignment.  An attacker can no longer assign a part of the key stream to shorter keys since the key stream changes if the length of any subkey changes.  It can no longer assign a strong mechanism key to a weaker mechanism because if the key type changes so does the key stream.    After discussions on the list, I'd probably also add a uint16 of flags per key to allow for some keys to be exported (and allow the HSM to know which ones are exportable).

There are other issues, but this gets us closer.

Mike






--------------000801010009020508020903-- From nobody Sun Apr 26 16:55: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 46FBF1ACE11 for ; Sun, 26 Apr 2015 16:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 UOWOPdMGrOPV for ; Sun, 26 Apr 2015 16:55:47 -0700 (PDT) Received: from mail-vn0-f48.google.com (mail-vn0-f48.google.com [209.85.216.48]) (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 F1B461ACE0D for ; Sun, 26 Apr 2015 16:55:46 -0700 (PDT) Received: by vnbf129 with SMTP id f129so10002327vnb.9 for ; Sun, 26 Apr 2015 16:55:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=hTWfgrt7bY1/Aeny2mvEkrZxmf05gtK/QpcmkJChZVw=; b=Nejcpo/93e4HVJ+pEC86cFTi+oFz9PGmkqSA+HWU+/vcGmX3rRfwbBcIpQjNoqaE/b tvXzGjZjwMYgg1H9wYbfyu3V5cexoCv1x/FyJyMKKwGKE0qECxG9tURzVojx0V9OoaO3 0fWjwuZgJ0JR/7P+l+KW75p1iYPe4cDJqckUmM5XMG6Exj7M5+AdTXQFnB84Qu8aIFPd d5OfskM24X3RDpiKSP3DUNWEi7v/3N8jLKKtoaEWxLvsCp+XTveShUqGInpTTg1cSIOw Qe/SU7VBqFR/yyEevuS7pxcC+WCHhX8SSz9wUg+kzKkp5h1eTFDRqKb5bSKbqCX5CchY kFoQ== X-Gm-Message-State: ALoCoQkKNBqkO3meJDCyDPSCSHVKnH7z22GPx18mN+0BDh5qxJ438NxLhFP9bfLh71+MrX7dkOj7 X-Received: by 10.52.33.132 with SMTP id r4mr21738950vdi.0.1430092546157; Sun, 26 Apr 2015 16:55:46 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id cc10sm21451673vdc.3.2015.04.26.16.55.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 16:55:45 -0700 (PDT) Message-ID: <553D7B00.90600@nthpermutation.com> Date: Sun, 26 Apr 2015 19:55:44 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Hugo Krawczyk References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040007020802020204080707" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2015 23:55:48 -0000 This is a multi-part message in MIME format. --------------040007020802020204080707 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/26/2015 4:20 PM, Hugo Krawczyk wrote: > > > All calls to HKDF *should* use a non-empty label and context > field, but that's tied more to the specific use than anything else. > > > ​ Agreed. All calls to HKDF that produce cryptographic keys for use in > the protocol MUST use a non-empty label and context field and that's > what we do. Some clarification here: For HKDF as a generic function, I meant "SHOULD" in its normal meaning. Implementations of HKDF can permit a null label and context field and will get what they expect from that. For HKDF as a the KDF for TLS, TLS will assign labels and associate contexts for specific usages and those are going to be non-null. Mike --------------040007020802020204080707 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:

 All calls to HKDF *should* use a non-empty label and context field, but that's tied more to the specific use than anything else. 

​ Agreed. All calls to HKDF that produce cryptographic keys for use in the protocol MUST use a non-empty label and context field and that's what we do.

Some clarification here:


For HKDF as a generic function, I meant "SHOULD" in its normal meaning.  Implementations of HKDF can permit a null label and context field and will get what they expect from that.

For HKDF as a the KDF for TLS, TLS will assign labels and associate contexts for specific usages and those are going to be non-null.

Mike

--------------040007020802020204080707-- From nobody Sun Apr 26 17:01: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 0FC461ACEED for ; Sun, 26 Apr 2015 17:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 k5K2Pj1BRF1E for ; Sun, 26 Apr 2015 17:01:50 -0700 (PDT) Received: from mail-vn0-f52.google.com (mail-vn0-f52.google.com [209.85.216.52]) (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 B2A911ACEFB for ; Sun, 26 Apr 2015 17:01:50 -0700 (PDT) Received: by vnbf190 with SMTP id f190so10033498vnb.1 for ; Sun, 26 Apr 2015 17:01: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=+OQtW2mClIf2p5CXmETXXLRr6jC9TukacvFH90KxHwM=; b=CzMxwuO8nro7a8fKJj2EMwLjgvBhTcuSLUkVjkoYb6zVUh8WryVH3uTaHEyvH0onaa 2wlMpXNFGfPqAiYoVcy/D9jCIjLwjU1enn4urW027RT4jkdrG6tBDZaYd+O0BxmOfpe9 T4fqPFsNZG+D70SKdAk3LApTFKlJ9ZxLP4X7WeTnnztaOVAVShVgT1xzOMq2lwqdUiEg SU/wTTP1Gcf41QY3UzsECJoTduhXc0kMlZk16XqPYE5bGveBGoCHVUTCim+FnOki9ems I6qIUj9VTmjuaqEYatyB+EOkVRcdMI9rZONvJYx+k3BkZPR2Dt6Z00W8YcSRDGmBBtrO h6XA== X-Gm-Message-State: ALoCoQnmtztBk7/WdrkaW8kMLzfu8xGWGFGV/0HPr8GXJA9/z2tZ+k/kxY5F06QrvyQDZjs15NfJ X-Received: by 10.52.240.14 with SMTP id vw14mr21599836vdc.29.1430092910012; Sun, 26 Apr 2015 17:01:50 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id mk16sm21456013vdb.12.2015.04.26.17.01.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 17:01:49 -0700 (PDT) Message-ID: <553D7C6C.7010903@nthpermutation.com> Date: Sun, 26 Apr 2015 20:01:48 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Hugo Krawczyk References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050901030100020508060000" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2015 00:01:52 -0000 This is a multi-part message in MIME format. --------------050901030100020508060000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/26/2015 4:20 PM, Hugo Krawczyk wrote: > > You can include the length term in info, but it won't be enforced > by the HSM and depending on the format of the INFO field could > actually be spoofed as this is all user supplied info that isn't > known to be related to the actual desired output length. > > > Adding the length is not a solution to spoofing attacks- it will not > differentiate between keys of the same length. > You cannot compensate via the KDF for unauthorized access to the HSM. > If the HSM doesn't enforce an access policy, it is the HSM problem, > not something to solve via the KDF or via TLS 1.3 spec. > ​ Adding the length is not a solution to spoofing attacks and does not differentiate between keys of the same length, but it will differentiate between keys of _different_ lengths which is where the attack comes in. The problem is not in the math of the KDF, but in the HSMs ability to determine how to convert key stream material into concrete keys in a manner that doesn't subject them to attack. If I have a key that's derived from another key, I would like that it not be trivial for an attacker who has access to the HSM to extract that derived key. I believe that making the change to add the length makes it difficult to do such extraction and apparently(?) so did the reviewers of SP800-108(?). Mike --------------050901030100020508060000 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
You can include the length term in info, but it won't be enforced by the HSM and depending on the format of the INFO field could actually be spoofed as this is all user supplied info that isn't known to be related to the actual desired output length.

 Adding the length is not a solution to spoofing attacks- it will not differentiate between keys of the same length.
You cannot compensate via the KDF for unauthorized access to the HSM. If the HSM doesn't enforce an access policy, it is the HSM problem, not something to solve via the KDF or via TLS 1.3 spec.
​
 

Adding the length is not a solution to spoofing attacks and does not differentiate between keys of the same length, but it will differentiate between keys of different lengths which is where the attack comes in.   The problem is not in the math of the KDF, but in the HSMs ability to determine how to convert key stream material into concrete keys in a manner that doesn't subject them to attack.

If I have a key that's derived from another key, I would like that it not be trivial for an attacker who has access to the HSM to extract that derived key.  I believe that making the change to add the length makes it difficult to do such extraction and apparently(?) so did the reviewers of SP800-108(?).

Mike

--------------050901030100020508060000-- From nobody Sun Apr 26 17:06: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 42CFB1AD1FE for ; Sun, 26 Apr 2015 17:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 DUd7g_xErF2P for ; Sun, 26 Apr 2015 17:06:49 -0700 (PDT) Received: from mail-vn0-f51.google.com (mail-vn0-f51.google.com [209.85.216.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 C6D571AD1EC for ; Sun, 26 Apr 2015 17:06:48 -0700 (PDT) Received: by vnbf1 with SMTP id f1so10061755vnb.0 for ; Sun, 26 Apr 2015 17:06:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=2Ictzz4OSofGjPsaOC1dE3BcZ3LM9YrJgXfVHs7Q/og=; b=da8bnXQnKdT3xamf/oXe/Ql2YA/+lrjzTqR49tPVs+wsvkPwlzW/JmjJcyX1hXhXf0 ZXligNx+dgsb8m5Ac6ygHQESGY2WF+WQB2s2Gr/uiUk4zAyRWClRPSmFVvgArmEvsJer laLMMw+dh10jlowdmjyCuRctFAvZLwC5oqE7uCZnGc2v3HfejPn0g7raktkSCGbBktgp C9xtJDJ3yxdvOPr0zpwc1j9a5jyN4i1jY1MrcLbP/YFiqjEF1GPc8bPHtvP0QRdLAZ5N +Y/NBmH1N1u2K/uefuph7mWTk8iUptV2qbWi67xGWTV8102A50lZewyJyzM9PuhfYt8Y rIrA== X-Gm-Message-State: ALoCoQkzNySuhsJuwqcWoGvaqIWhuYbjl/hjBspryyt9DIqneaBwdO08uYXuyYQxIItwIEe3rPHX X-Received: by 10.52.109.229 with SMTP id hv5mr21654226vdb.91.1430093208045; Sun, 26 Apr 2015 17:06:48 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id de3sm21513640vdc.17.2015.04.26.17.06.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 17:06:47 -0700 (PDT) Message-ID: <553D7D96.8020908@nthpermutation.com> Date: Sun, 26 Apr 2015 20:06:46 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Hugo Krawczyk References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000000080307000904070902" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2015 00:06:50 -0000 This is a multi-part message in MIME format. --------------000000080307000904070902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/26/2015 4:20 PM, Hugo Krawczyk wrote: > > See section 7.5 of > ​ ​ > SP800-108 for a discussion of key separation especially paragraph > (2) and why this is important. > > ​ I agree with section 7.5 and HKDF, and its use in TLS 1.3, fully > complies with it. There is no mandatory use of length as input. It is > certainly allowed but not mandated. And when allowing it, it is > accommodated via the equivalent of the 'info' ​ > ​ field: > /"different input data strings (e.g. Label || 0x00 || Context || [L]2) > shall be used for different executions". > /Length is an example and not even listed in the explicit examples at > the top of page 19. You missed: > The compromise of the keying material output from one of the > executions of the KDF must not degrade the security of any of the > keying material output from the other executions of the KDF, Two calls to the KDF that are designed to produce the same key material with the same exact characteristics is fine. But when you can call the KDF multiple times with the same input data and assign the output key stream to different lengths of keys, you have a problem. I can do what I said - call and compromise the single byte generation of a key with the same input master key and INFO, and repeat it with increasing lengths to extract the entire key stream. I think that counts as cross compromise. Later, Mike --------------000000080307000904070902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
See section 7.5 of
​ ​
SP800-108 for a discussion of key separation especially paragraph (2) and why this is important.

​ I agree with section 7.5 and HKDF, and its use in TLS 1.3, fully complies with it. There is no mandatory use of length as input. It is certainly allowed but not mandated. And when allowing it, it is accommodated via the equivalent of the 'info' ​
 
​ field:
"different input data strings (e.g. Label || 0x00 || Context || [L]2) shall be used for different executions".
Length is an example and not even listed in the explicit examples at the top of page 19.


You missed:

The compromise of the keying material output from one of the executions of the KDF must not degrade the security of any of the keying material output from the other executions of the KDF,

Two calls to the KDF that are designed to produce the same key material with the same exact characteristics is fine.  But when you can call the KDF multiple times with the same input data and assign the output key stream to different lengths of keys, you have a problem.

I can do what I said - call and compromise the single byte generation of a key with the same input master key and INFO, and repeat it with increasing lengths to extract the entire key stream.  I think that counts as cross compromise.

Later, Mike


--------------000000080307000904070902-- From nobody Sun Apr 26 17:23: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 AF2031AD09D for ; Sun, 26 Apr 2015 17:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 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, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl06qsl365L4 for ; Sun, 26 Apr 2015 17:23:53 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E001AD084 for ; Sun, 26 Apr 2015 17:23:53 -0700 (PDT) Received: by wizk4 with SMTP id k4so80476872wiz.1 for ; Sun, 26 Apr 2015 17:23:51 -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=wlMJzccPp9+QHBlHBjtOgc3VpM+imOXODR1LLGhUjZY=; b=PTsYCfBOOdqqs2HS/CvIch3uWikEgPEfsp9ZHP6erv6oF0SVX45UJTSt6lEl1ZJn0e MTPMW9r0oB3TKEvtT5awRG+SwEaYO9D3DGOIgo+zIouVl3ziV5XePGzg8X/Oe+h8AyEw jvTd4/hR6V50w16oDVNe1PsAxNu0GHvdw0AELAZNT+k49gdjExuMRAE8m6SQZQumKsvI SkTvO9GDpsFyTZ4QW+EqOkg8Bwa2QvVr20xQft3xpKtcWeZaLMeYszdd8exT7okqgc4o Zwa0B8xth48WYcVq1kpc570Iw7FguPuG4WNjs3FWapspAmeO2AUpcIthOFDmgZqXidfU oC0g== MIME-Version: 1.0 X-Received: by 10.180.82.97 with SMTP id h1mr15930405wiy.26.1430094231644; Sun, 26 Apr 2015 17:23:51 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Sun, 26 Apr 2015 17:23:51 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Sun, 26 Apr 2015 17:23:51 -0700 (PDT) In-Reply-To: <553D79CE.1030504@nthpermutation.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> <553D79CE.1030504@nthpermutation.com> Date: Sun, 26 Apr 2015 17:23:51 -0700 Message-ID: From: Watson Ladd To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d04426730ac2fe50514a9c27e Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2015 00:23:55 -0000 --f46d04426730ac2fe50514a9c27e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Apr 26, 2015 4:50 PM, "Michael StJohns" wrote: > > On 4/26/2015 4:20 PM, Hugo Krawczyk wrote: >>> >>> TLS1.2 uses the Master secret as a key for both the MAC and KDF functions and that needs to change. Those can't be the same key - and hence your comment about using the same master secret for different derives becomes problematic especially if one of the outputs is to an exporter. >> >> >> =E2=80=8B The same Master Secret is used to derive multiple keys but the= se are derived with unique label+context input.=E2=80=8B >> =E2=80=8B >> =E2=80=8B Different derivations *never* use the same label+context.=E2= =80=8B > > > > Next part of the discussion. > > Pretend you're implementing this in an HSM. How does the HSM enforce the "never use same label and context"? Answer is that it can't and there isn't anything currently defined in the label or context that allows the HSM to do proper policy protection. > > What needs to happen here is to include in the calculation of the key stream sufficient values to ensure the key stream is completely different if the requested output (e.g. target keys and types) of the key stream is different. > > Consider as an HSM input to the TLS KDF the label "key expansion", the handle for a specific master_secret key and the client and server randoms concatenated as the context. Internally, the HSM will concatenate the label and context into what you call "info". The last set of inputs to the "key expansion" call to the KDF are the types and output lengths of the key material, but those aren't involved in the calculation of the key stream. > > If you call the HSM version of the KDF with a key, context and label and tell it to break things into 2 keys (for AES-CCM) of length 256 bits each you will produce a key stream of length 64 bytes. > > If I call the HSM version of the same KDF with the same key, context and label and tell it to produce a single HMAC-SHA256 key of length 8 bits I will get a single byte of key stream which is identical to your call above. Using the TLS 1.2 KDF I can even tell it to not produce any key material but to provide me with IVs - which have the same key stream material as from your call. All because the length and types of the keys to be produced are not mixed into the key stream production calculation. > But the context told you what key I wanted, and how I was going to use it. Why is that easier to enforce then one time use? I'm also not sure why we want to protect non cert keys in an HSM: the attacker can always use the HSM to decrypt. > > If I define the TLS KDF as HKDF with a context consisting of (from my now expired draft): > struct { > uint8 clientRandom[32]; /* ClientHello.random */ > uint8 serverRandom[32]; /* ServerHello.random */ > uint32 keyCount; /* Num keys to derive */ > KeyType keyTypes[keycount]; > uint16 keyLengths[keycount]; /* Key lengths in bits */ > } KeyExpansionContext; > > the HSM can use the key types and lengths to enforce policy of key assignment. An attacker can no longer assign a part of the key stream to shorter keys since the key stream changes if the length of any subkey changes. It can no longer assign a strong mechanism key to a weaker mechanism because if the key type changes so does the key stream. After discussions on the list, I'd probably also add a uint16 of flags per key to allow for some keys to be exported (and allow the HSM to know which ones are exportable). > > There are other issues, but this gets us closer. > > Mike > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d04426730ac2fe50514a9c27e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 26, 2015 4:50 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
>>>
>>> TLS1.2 uses the Master secret as a key for both the MAC and KD= F functions and that needs to change.=C2=A0 Those can't be the same key= - and hence your comment about using the same master secret for different = derives becomes problematic especially if one of the outputs is to an expor= ter.
>>
>>
>> =E2=80=8B The same Master Secret is used to derive multiple keys b= ut these are derived with unique label+context input.=E2=80=8B
>> =E2=80=8B
>> =E2=80=8B Different derivations *never* use the same label+context= .=E2=80=8B
>
>
>
> Next part of the discussion.
>
> Pretend you're implementing this in an HSM.=C2=A0 How does the HSM= enforce the "never use same label and context"?=C2=A0 Answer is = that it can't and there isn't anything currently defined in the lab= el or context that allows the HSM to do proper policy protection.
>
> What needs to happen here is to include in the calculation of the key = stream sufficient values to ensure the key stream is completely different i= f the requested output (e.g. target keys and types) of the key stream is di= fferent.
>
> Consider as an HSM input to the TLS KDF the label "key expansion&= quot;, the handle for a specific master_secret key and the client and serve= r randoms concatenated as the context. Internally, the HSM will concatenate= the label and context into what you call "info".=C2=A0=C2=A0 The= last set of inputs to the "key expansion" call to the KDF are th= e types and output lengths of the key material, but those aren't involv= ed in the calculation of the key stream.
>
> If you call the HSM version of the KDF with a key, context and label a= nd tell it to break things into 2 keys (for AES-CCM) of length 256 bits eac= h you will produce a key stream of length 64 bytes.
>
> If I call the HSM version of the same KDF with the same key, context a= nd label and tell it to produce a single HMAC-SHA256 key of length 8 bits I= will get a single byte of key stream which is identical to your call above= .=C2=A0=C2=A0 Using the TLS 1.2 KDF I can even tell it to not produce any k= ey material but to provide me with IVs - which have the same key stream mat= erial as from your call.=C2=A0 All because the length and types of the keys= to be produced are not mixed into the key stream production calculation. >

But the context told you what key I wanted, and how I was go= ing to use it. Why is that easier to enforce then one time use? I'm als= o not sure why we want to protect non cert keys in an HSM: the attacker can= always use the HSM to decrypt.

>
> If I define the TLS KDF as HKDF with a context consisting of (from my = now expired draft):
> =C2=A0=C2=A0 struct {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint8=C2=A0=C2=A0=C2=A0 clientRan= dom[32];=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* ClientHello.random */
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint8=C2=A0=C2=A0=C2=A0 serverRan= dom[32];=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* ServerHello.random */
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint32=C2=A0=C2=A0 keyCount;=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= /* Num keys to derive */
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 KeyType=C2=A0 keyTypes[keycount];=
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint16=C2=A0=C2=A0 keyLengths[key= count];=C2=A0 /* Key lengths in bits */
> =C2=A0=C2=A0 } KeyExpansionContext;
>
> the HSM can use the key types and lengths to enforce policy of key ass= ignment.=C2=A0 An attacker can no longer assign a part of the key stream to= shorter keys since the key stream changes if the length of any subkey chan= ges.=C2=A0 It can no longer assign a strong mechanism key to a weaker mecha= nism because if the key type changes so does the key stream.=C2=A0=C2=A0=C2= =A0 After discussions on the list, I'd probably also add a uint16 of fl= ags per key to allow for some keys to be exported (and allow the HSM to kno= w which ones are exportable).
>
> There are other issues, but this gets us closer.
>
> Mike
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--f46d04426730ac2fe50514a9c27e-- From nobody Sun Apr 26 17:30: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 776461B2AAE for ; Sun, 26 Apr 2015 17:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 6QHN_9wizzmk for ; Sun, 26 Apr 2015 17:29:59 -0700 (PDT) Received: from mail-vn0-f46.google.com (mail-vn0-f46.google.com [209.85.216.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 885181B2AAC for ; Sun, 26 Apr 2015 17:29:59 -0700 (PDT) Received: by vnbg62 with SMTP id g62so10076204vnb.7 for ; Sun, 26 Apr 2015 17:29:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=yq50hbU/m+1rDDC7ejPC5HSxXSeRJlTBtTPZWWXZbxY=; b=beW/uinrS8qdM+SEo5ZIK0/HYs9WIgI93c9WbgQOvYi2NUyH6S9V6puydjsayh+pqO 2qyc6bLz6VCKctT19rCONSbY5cy0xfGsY6asZeKT5AXXYgl3Hjn3v7oxhnXmpOGoRJcH d4nTLVz8i5Py7Ed4sZXf5ynoHzZiVVXqFNFpCDP5i6bq7fPhl2e90UUWlVWudKjO3DuE 8Yw/dfrYeclyO95e2E90kEL9Sx8nz4SgQfZfdadto8+Iv7cXquqBjzw9nhgYSlpUc9O4 3mr7O4eVON2S9/R2cBftl3YDkyMjpWnc6aOhj8ip7Bafu5vZel5CvB8wbte/g1nnpvXr Ctmw== X-Gm-Message-State: ALoCoQn/NIzhAXVYNUd5PFUF3TMvj90AoV2JyWXLG1T99+DUUU4Z1Bv3+vabGGlcFuOI34kvW8iP X-Received: by 10.52.3.10 with SMTP id 10mr21864737vdy.74.1430094598712; Sun, 26 Apr 2015 17:29:58 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id cl11sm21636380vdb.15.2015.04.26.17.29.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 17:29:58 -0700 (PDT) Message-ID: <553D8305.7030806@nthpermutation.com> Date: Sun, 26 Apr 2015 20:29:57 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Hugo Krawczyk References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090301090009090109000609" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2015 00:30:01 -0000 This is a multi-part message in MIME format. --------------090301090009090109000609 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/26/2015 4:20 PM, Hugo Krawczyk wrote: > > Given SP800-108 and SP800-56C were published before your paper > and the RFC and have pretty much identical math (except as I > noted), why shouldn't we use those cites instead of the RFC? E.g. > is there any cryptographic improvement in RFC5869 vs the other two? > > > ​ SP 800-108 is a framework and set of recommendations, not a > specific, unique KDF function. HKDF follows this framework and NIST > found this sufficiently important to document this in a separate > document SP 800-56C (which explicitly includes HKDF as an instantiation)​ > ​ .​ You didn't actually answer the base question of "is there any cryptographic improvement...."? With respect to the above, SP800-56C says to use one of the SP800-108 expansions. Third paragraph of section 4 of SP800-56C: > The key expansion step uses the key derivation key KDK and other > information exchanged and/or pre-shared, such as identifiers for the > involved parties, protocol identifiers, and the labels of the derived > keys, as the input to an approved key derivation function specified in > SP 800-108 [4] to produce secret keying material KM of a desired length L. What I think you're referring to is (last paragraph of the same section): > IETF RFC 5869 [10] describes an instantiation of the above > extraction-then-expansion key derivation procedure using HMAC for the > extraction and expansion steps. For extensive rationale on the key > derivation through the extraction-then-expansion procedure specified > in this Recommendation see [11]. But that appears to be a reference to base material rather than an endorsement of it as an approved function. Cryptographically, there isn't any difference I can see except the L term. If I were to do this I would say in TLS: "The TLS KDF is the extraction function specified in SP800-56C combined with the "KDF in Feedback Mode" mode (Section 5.1) of SP800-108 with the following specifications: For SP800-56C, the shall be no salt and the extraction function shall be as appropriate for the selected TLS PRF. For SP800-108, the KDF PRF shall be the MAC function of the selected TLS PRF with a default of HMAC-SHA256. The L and i terms shall be expressed as network byte order 32 bit unsigned integers. The Label shall be the defined TLS label expressed as ASCII bytes, and the Context shall be the context defined for that specific Label encoded as per normal TLS rules. The ordering of the terms processed by the PRF in step 4a is as indicated in SP800-108 section 5.1." Later, Mike --------------090301090009090109000609 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
Given SP800-108 and SP800-56C were published before your paper  and the RFC and have pretty much identical math (except as I noted), why shouldn't we use those cites instead of the RFC?  E.g. is there any cryptographic improvement in RFC5869 vs the other two?

​ SP 800-108 is a framework and set of recommendations, not a specific, unique KDF function. HKDF follows this framework and NIST found this sufficiently important to document this in a separate document SP 800-56C (which explicitly includes HKDF as an instantiation)​
​ .​
 

You didn't actually answer the base question of "is there any cryptographic improvement...."?

With respect to the above, SP800-56C says to use one of the SP800-108 expansions. 

Third paragraph of section 4 of SP800-56C:
The key expansion step uses the key derivation key KDK and other information exchanged and/or pre-shared, such as identifiers for the involved parties, protocol identifiers, and the labels of the derived keys, as the input to an approved key derivation function specified in SP 800-108 [4] to produce secret keying material KM of a desired length L.

What I think you're referring to is (last paragraph of the same section):
IETF RFC 5869 [10] describes an instantiation of the above extraction-then-expansion key derivation procedure using HMAC for the extraction and expansion steps. For extensive rationale on the key derivation through the extraction-then-expansion procedure specified in this Recommendation see [11].

But that appears to be a reference to base material rather than an endorsement of it as an approved function.

Cryptographically, there isn't any difference I can see except the L term.


If I were to do this I would say in TLS:


"The TLS KDF is the extraction function specified in SP800-56C combined with the "KDF in Feedback Mode" mode (Section 5.1) of SP800-108 with the following specifications:  For SP800-56C, the shall be no salt and the extraction function shall be as appropriate for the selected TLS PRF.  For SP800-108, the KDF PRF shall be the MAC function of the selected TLS PRF with a default of HMAC-SHA256.  The L and i terms shall be expressed as network byte order 32 bit unsigned integers.  The Label shall be the defined TLS label expressed as ASCII bytes, and the Context shall be the context defined for that specific Label encoded as per normal TLS rules.  The ordering of the terms processed by the PRF in step 4a is as indicated in SP800-108 section 5.1."

Later, Mike



--------------090301090009090109000609-- From nobody Sun Apr 26 17:59: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 EBE441B2CB2 for ; Sun, 26 Apr 2015 17:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 FUVoJkkWniCg for ; Sun, 26 Apr 2015 17:59:23 -0700 (PDT) Received: from mail-vn0-f46.google.com (mail-vn0-f46.google.com [209.85.216.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 884721B2CAD for ; Sun, 26 Apr 2015 17:59:23 -0700 (PDT) Received: by vnbf1 with SMTP id f1so10174748vnb.0 for ; Sun, 26 Apr 2015 17:59:22 -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 :content-transfer-encoding; bh=DhbdtjkKJd3BCAgzju0TICP/tHOzSk/qJdmVZDaZO+g=; b=esajAdA0GwBAyv80ChsNjYc1jbNOMr2ZqyscouuEI4ia+KmzEkBhAc4aim1zJB0L7d E5gW4flDfD+9c5fqpCgM0ZGxXUNT0eMeDdfaDRqA+DURDbGA2QitaCCzDdEr5EjhsRyu cn/0vpWIYQlDjvhtxSc6ZyEwD2FYhRJPJG7Ezivx/ZPqK/ze4PX70Nb+hwyz+lyt8u2f WS6JGDXgafl9LhfBO1fM2DBtNnyx0haaoBLoXRthHNmMO/P9VYI/hxKZna6gIGLkRaC8 S8iT9FPhDRSn73s6l5ghRNlNT8qYbppurHqx2DGoNAisu7KM2oYOzZWGAZzqWYerlkqM cIfQ== X-Gm-Message-State: ALoCoQlJFsNcXLWOPQdqrDM4l7qdo4mLVh1Tdsv+FuZQIwiSKWPQCV1cBY0+OK2NjQ7YZVcQ75By X-Received: by 10.52.134.115 with SMTP id pj19mr19280503vdb.94.1430096362834; Sun, 26 Apr 2015 17:59:22 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id ms8sm21793287vdb.21.2015.04.26.17.59.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 17:59:22 -0700 (PDT) Message-ID: <553D89E8.30100@nthpermutation.com> Date: Sun, 26 Apr 2015 20:59:20 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Watson Ladd References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> <553D79CE.1030504@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2015 00:59:25 -0000 On 4/26/2015 8:23 PM, Watson Ladd wrote: > > > If I call the HSM version of the same KDF with the same key, context > and label and tell it to produce a single HMAC-SHA256 key of length 8 > bits I will get a single byte of key stream which is identical to your > call above. Using the TLS 1.2 KDF I can even tell it to not produce > any key material but to provide me with IVs - which have the same key > stream material as from your call. All because the length and types > of the keys to be produced are not mixed into the key stream > production calculation. > > > > But the context told you what key I wanted, and how I was going to use > it. Why is that easier to enforce then one time use? I'm also not sure > why we want to protect non cert keys in an HSM: the attacker can > always use the HSM to decrypt. > This is a good question from a different direction. In general, HSMs don't do "one time use" except as buried inside compound functions (e.g. the fake key pair inside an ECDSA signature). And it may be difficult to ensure the key is zeroized before an attacker can use it. I'd rather not depend on ephemeralness as I expect different HSM implementations to deal with that differently. Doing it by getting the derivation process correct stands a better chance of getting good implementations in HSMs. In the current model, the context says how the user wants to use the key, but it doesn't constrain the HSM to use it that way or even to constrain it to produce a specific type and length of key - those are user inputs. And in TLS1.2 and before the master_secret is used multiple times. To the HSM, current TLS context is opaque unstructured data that gets mixed in without affecting the key stream to key assignment process. With respect to protecting non-cert keys: think about extracting the master secret and using steganography to hide it inside a picture on non-encrypted side of the server (or even the encrypted side if publicly available). An attacker can retrieve that, capture the traffic stream externally, derive the session keys and capture the traffic safely remote without the betraying large amount of stolen data wandering past the server interface. The attack can even forge data in the stream. This is obviously a made up example, but it was the first way I thought of using this - but consider that if an attacker can extract the master secret he can send it off to someone who can read the stream externally either in real time or later. Later, Mike From nobody Sun Apr 26 23:06: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 944641B2E97 for ; Sun, 26 Apr 2015 23:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.909 X-Spam-Level: X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 3plMpvB25CZs for ; Sun, 26 Apr 2015 23:06:08 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4DB1B2E96 for ; Sun, 26 Apr 2015 23:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1430114769; x=1461650769; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L/5ft0CKnk3HFNTZSfdbGGEftx12rmh/DfddN7CDkB0=; b=bW1/So3ONTRZThwl56Ea//PxCva16CJhVrUHo6UOq70zTBfVASHIjB3Y cLecFEB/+g5f0xtPG7pY/3oeh6eBr9adzcJs+WldHnyqxRucEw8dSSzBv hqAiLcGOnm+TukfCzCMdvrp1ezLTV6GDD6lsDmCsJe8nr+Vzweuu3d/ON A=; X-IronPort-AV: E=Sophos;i="5.11,655,1422874800"; d="scan'208,217";a="321458680" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 27 Apr 2015 18:06:05 +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; Mon, 27 Apr 2015 18:06:04 +1200 From: Peter Gutmann To: Michael StJohns , Hugo Krawczyk Thread-Topic: =?Windows-1252?Q?[TLS]_confirming_the_room=92s_consensus:_adopt_HKDF_PRF_?= =?Windows-1252?Q?for_TLS_1.3?= Thread-Index: AQHQfUY+XGJjjqO7sUqFueKgZO+tjZ1Yy7OAgAFFkQCAAdcsgIAC+fIAgAAW34CAAAi+gIABY96D Date: Mon, 27 Apr 2015 06:06:02 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB0084CA@uxcn10-tdc05.UoA.auckland.ac.nz> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> , <553D4FF7.8080700@nthpermutation.com> In-Reply-To: <553D4FF7.8080700@nthpermutation.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: multipart/alternative; boundary="_000_9A043F3CF02CD34C8E74AC1594475C73AB0084CAuxcn10tdc05UoAa_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2015 06:06:11 -0000 --_000_9A043F3CF02CD34C8E74AC1594475C73AB0084CAuxcn10tdc05UoAa_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Michael StJohns writes: >This isn't about TLS specifically, but about how an HSM makes sure an >attacker can't extract TLS keys. Stepping back a bit in order to actually see the woods here, why is this an issue? Anyone who's using hardware for performance reasons will offload everything to an SSL terminator, almost everyone else who doesn't want to d= o that will do the crypto on the host, those worried about private-key securi= ty will store the server key in an HSM but not do the bulk crypto there becaus= e doing it on the host is typically much faster, and even if you do use PKCS = #11 to do your bulk crypto for TLS, any attacker who's in a position to extract the session keys from an HSM via a PKCS #11 mechanism has to control the ho= st it's talking to, in which case they've got direct access to the plaintext anyway. I realise that it's always possible to invent some scenario in which this i= s an issue, but how much of a real-world impact does it actually have? Bob Relyea suggested TLS 1.2 PRF mechanisms in 2007 on the old Cryptoki list (a= nd it seemed his motivation for that was the need to be able to support it in Mozilla's softoken implementation, for which he needed a defined PKCS #11 mechanism), and OASIS is just getting around to finalising the standard for them now, seven years later. This would seem to indicate that the actual industry demand for this (not the hypothesised need but the real-world dema= nd) is a giant who-cares. So as I've already said earlier in this discussion, create the best mechani= sm that's a combination of good crypto design principles and ease of implementation/deployment for existing implementations, and if someone specifically wants to do it in an HSM they'll have to accept that they're t= he odd corner case and deal with it. Peter. --_000_9A043F3CF02CD34C8E74AC1594475C73AB0084CAuxcn10tdc05UoAa_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Michael StJohns <msj@nthpermutation.com> writes:

>This isn't about TLS specifically, but about how an HSM makes sure an >attacker can't extract TLS keys.

Stepping back a bit in order to actually see the woods here, why is this an=
issue?  Anyone who's using hardware for performance reasons will offlo= ad
everything to an SSL terminator, almost everyone else who doesn't want to d= o
that will do the crypto on the host, those worried about private-key securi= ty
will store the server key in an HSM but not do the bulk crypto there becaus= e
doing it on the host is typically much faster, and even if you do use PKCS = #11
to do your bulk crypto for TLS, any attacker who's in a position to extract=
the session keys from an HSM via a PKCS #11 mechanism has to control the ho= st
it's talking to, in which case they've got direct access to the plaintext anyway.

I realise that it's always possible to invent some scenario in which this i= s
an issue, but how much of a real-world impact does it actually have?  = Bob
Relyea suggested TLS 1.2 PRF mechanisms in 2007 on the old Cryptoki list (a= nd
it seemed his motivation for that was the need to be able to support it in<= br> Mozilla's softoken implementation, for which he needed a defined PKCS #11 mechanism), and OASIS is just getting around to finalising the standard for=
them now, seven years later.  This would seem to indicate that the act= ual
industry demand for this (not the hypothesised need but the real-world dema= nd)
is a giant who-cares.

So as I've already said earlier in this discussion, create the best mechani= sm
that's a combination of good crypto design principles and ease of
implementation/deployment for existing implementations, and if someone
specifically wants to do it in an HSM they'll have to accept that they're t= he
odd corner case and deal with it.

Peter.
--_000_9A043F3CF02CD34C8E74AC1594475C73AB0084CAuxcn10tdc05UoAa_-- From nobody Mon Apr 27 00:51: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 694181B2EC9 for ; Mon, 27 Apr 2015 00:51: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 moNDKxB-Tmin for ; Mon, 27 Apr 2015 00:51:18 -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 3BB271B2A48 for ; Mon, 27 Apr 2015 00:51:18 -0700 (PDT) Received: by wizk4 with SMTP id k4so88732051wiz.1 for ; Mon, 27 Apr 2015 00:51:17 -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=z2kKD2n2R0JE2y/Bs0q3WUy7VfDt7kKGaXDYJl1QW14=; b=xbhEPqo6Q0xSS8VPTx6V9WlKt0g1HOzGA10KbxJaM5SzcXvNaIqek5Zw2hhoewjORY e4+O+hK755vUmMvft++9fkDBBQ6HLX1sIXHRmMTDqQoigiGC8hJKuhQIrXG+uPDDdfoF bU98jURwqBRHW48Uk8lOkCINOZyBC+tAr1QnKLXz6Qraxozo0+698VziS2RRX1GqQQRi JMNQrsXM0YhjK/gG9IZXPGpovNOud+JGb9F5QRbKhQf2ElJzMRNHPWEi50G/N2hQ5V6O JVPSnxiH5BHJ6dcVzbD2ysl6LWYhmQyzzk/eMAtmoNP88tLztQJxGL3UueYmS/3qrVzG /v+A== X-Received: by 10.195.17.196 with SMTP id gg4mr858524wjd.109.1430121076995; Mon, 27 Apr 2015 00:51:16 -0700 (PDT) Received: from [172.24.248.247] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id z12sm28199755wjw.39.2015.04.27.00.51.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 00:51:16 -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: <553D7397.9090000@nthpermutation.com> Date: Mon, 27 Apr 2015 10:51:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <25BAE048-8AF0-4F36-88FD-CFB4D577265E@gmail.com> References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> <20150426182025.GA3549@LK-Perkele-VII> <553D5898.3090902@nthpermutation.com> <3E5464E9-80BF-4D2E-A6C1-EF4E47A99268@gmail.com> <553D7397.9090000@nthpermutation.com> To: Michael StJohns 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: Mon, 27 Apr 2015 07:51:20 -0000 > On Apr 27, 2015, at 2:24 AM, Michael StJohns = wrote: >=20 > On 4/26/2015 6:26 PM, Yoav Nir wrote: >> Both CCM and GCM use a concatenation of the explicit IV (which is = obviously not secret and allowed to be predictable) with a salt that is = derived from the keying material. This concatenation forms the nonce = which is input to the AEAD. >=20 > Which protocol are we talking about? I thought it was clear from context that we were talking about how IPsec = does it. > CCM and GCM - as generic functions - use a per message Nonce. CCM = defines a block formatting function (Appendix A of the Nist Document) = that takes a nonce of 1-15 octets. David Mc Grew's RFC on AEAD = functions APIs fixes the length of that nonce to 12 bytes because that's = the most common length for GCM. That per message nonce (back to the = generic again) can be created from the combination of a per-session = nonce and a sequence number, randomly generated or derived from key = material. >=20 > HSMs generally implement the generic interfaces described in the base = CCM and GCM documents, and David Mc Grew's RFC on AEAD is a subset of = those possibilities and is therefor usable with the generic interfaces. >=20 >=20 >>=20 >> RFC 4309 (CCM) says "The salt value need not be secret, but it MUST = NOT be predictable prior to the beginning of the security = association.=E2=80=9D >> RFC 4106 (GCM) says "The salt SHOULD be unpredictable (i.e., chosen = at random) before it is selected, but need not be secret.=E2=80=9D >=20 > In IPSEC GCM, the IV is explicitly included in each packet (see = section 3.1 of RFC4106) and hence is not secret in any way shape or = form. >=20 > In IPSEC CCM, the IV is also explicitly included in each packet - see = section 3 and 3.1 of RFC 4309. Hence, also never secret in any way = shape or form. The IV is explicit. The nonce is not. In both cases the 96-bit nonce is = composed of 32 implicit salt bits and 64 explicit IV bits. >> The ChaCha20-Poly1305 for IPsec draft does the same thing, and in = fact so does RFC 5288 (AES-GCM for TLS 1.2) >=20 > Citing your own draft as proof of your own argument is a bit.... = well=E2=80=A6 That WG draft is in WGLC now, so it it=E2=80=99s doing something that is = wrong, now would be a good time to say why. It=E2=80=99s also doing the = exact same thing that IPsec has been doing with AEADs since 4106 and TLS = since 5288. All of these combined a 64-bit explicit IV with a 32-bit = salt that is derived as part of the keying materials (KEYMAT for IPsec, = key_block for TLS) and never ever transmitted. > In any event, I note that your IPSEC draft doesn't actually describe = the ESP payload format, so without that, I'd make the assumption that = the IV is included before the payload as is described in the IPSEC ESP = document. >=20 >>=20 >> So no, that salt (and by extension, the proposed 96-bit value) need = not be secret, but it=E2=80=99s never transmitted. > In which of the above? Maybe in the chacha20 draft... but not in the = other two. >=20 > And RFC5288 does it the wrong way - getting IV (session nonce) = material from the same key stream as key material. That hopefully will = be fixed with TLS1.3. It would have been much more preferable to use a = zero session nonce than extract it from the key stream. You are saying that this is wrong. Why? >> This also shows that there is good precedent for generating such a = doesn=E2=80=99t-really-need-to-be-secret value from the key_block or = KEYMAT. >=20 > I'm pretty sure it doesn't. It just shows a continuous = misunderstanding of the problems with doing it this way. =20 And those problems are=E2=80=A6? > There are ways to mitigate this a bit - but they require ensuring = complete cryptographic isolation from key generation and a method of = non-secret but not disclosed information that can still be used with the = generic interfaces. >=20 > There was a good precedence for using RC4 and MD5 because they were = fast and in wide use, but we've learned. >=20 > Later, Mike From nobody Mon Apr 27 04:22: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 C1C461B308B for ; Mon, 27 Apr 2015 04:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 Kq_iSZzwZyn3 for ; Mon, 27 Apr 2015 04:22:28 -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 62DB71A90DD for ; Mon, 27 Apr 2015 04:22:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 92A6D47839; Mon, 27 Apr 2015 11:22:27 +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 74FAA4783D; Mon, 27 Apr 2015 11:22:27 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 70DF52039; Mon, 27 Apr 2015 11:22:27 +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.913.22; Mon, 27 Apr 2015 07:22:26 -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.0913.011; Mon, 27 Apr 2015 07:22:26 -0400 From: "Salz, Rich" To: Peter Gutmann , Michael StJohns , Hugo Krawczyk Thread-Topic: =?Windows-1252?Q?[TLS]_confirming_the_room=92s_consensus:_adopt_HKDF_PRF_?= =?Windows-1252?Q?for_TLS_1.3?= Thread-Index: AQHQbKXN8/D/NKk0mESK2GGc9srrDJ06wxoAgAAchYCAAD3HgIAe2MYAgAADAICAAUWSAIAB1yuAgAL58wCAABbegIAACL+AgACawwCAABUNMA== Date: Mon, 27 Apr 2015 11:22:25 +0000 Message-ID: <025c9d266ef24cfcb720b7b3a9ecfc0c@usma1ex-dag1mb2.msg.corp.akamai.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> , <553D4FF7.8080700@nthpermutation.com> <9A043F3CF02CD34C8E74AC1594475C73AB0084CA@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB0084CA@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: [172.19.42.51] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2015 11:22:29 -0000 > Stepping back a bit in order to actually see the woods here, why is this = an issue? +1. I skipped quoting, but the whole message is a good one. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Mon Apr 27 09:40: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 CE33E1B311A for ; Mon, 27 Apr 2015 05:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 cI-2NFPnqdib for ; Mon, 27 Apr 2015 05:28:19 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0C41B3119 for ; Mon, 27 Apr 2015 05:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430137698; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=/dhgbPbPvZjqECl29iasT/ZczpQxP4oUZ4mwL2F0ruA=; b=Y3s/K1hvvA+rXfMHxBPAVo/xoTy5Fjmb4qxSlhoxiVgPQKM+OgwuirHdsg+rYpYvL9/z/Q4imwSm3Pn9fmxR3BjCHctgT7EUQRURYeou7pD0vcMHN7YYGDs0UKDpwzQB1FAxdu+4tYO/0E2lTrlPPBS2dGgMw8BScbc34K6RsjM= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R261e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05022; 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.158) by smtp.aliyun-inc.com(127.0.0.1); Mon, 27 Apr 2015 20:28:16 +0800 From: "=?GBK?B?zuSx/tX9KNTK1tAp?=" To: References: <20150427023926.28938.22369.idtracker@ietfa.amsl.com> In-Reply-To: <20150427023926.28938.22369.idtracker@ietfa.amsl.com> Date: Mon, 27 Apr 2015 20:28:16 +0800 Message-ID: <008e01d080e5$a2db6de0$e89249a0$@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: AQINWeqB9X5GafILLq6JDjmchKPzTJznFb9g Content-Language: zh-cn Archived-At: X-Mailman-Approved-At: Mon, 27 Apr 2015 09:40:07 -0700 Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: =?GBK?B?zuSx/tX9KNTK1tAp?= List-Id: "This is the mailing list 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, 27 Apr 2015 12:28:21 -0000 Hi All, A new TLS extension draft has been posted to IETF repository https://datatracker.ietf.org/doc/draft-bzwu-tls-ecdhe-keyshare/ This extension allows a TLS client to carry ECDHE keyshare in = ClientHello message, so as to reduce the full handshake latency of 1RTT. Please kindly review it. Any comments are welcomed. Thanks and best regards, Bingzheng Wu -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, April 27, 2015 10:39 AM To: =E6=AD=A6=E7=82=B3=E6=AD=A3(=E5=85=81=E4=B8=AD); = =E6=AD=A6=E7=82=B3=E6=AD=A3(=E5=85=81=E4=B8=AD) Subject: New Version Notification for = draft-bzwu-tls-ecdhe-keyshare-00.txt A new version of I-D, draft-bzwu-tls-ecdhe-keyshare-00.txt has been successfully submitted by Bingzheng Wu and posted to the IETF = repository. Name: draft-bzwu-tls-ecdhe-keyshare Revision: 00 Title: Transport Layer Security (TLS) ECDHE Keyshare Extension Document date: 2015-04-24 Group: Individual Submission Pages: 6 URL: = http://www.ietf.org/internet-drafts/draft-bzwu-tls-ecdhe-keyshare-00.txt Status: = https://datatracker.ietf.org/doc/draft-bzwu-tls-ecdhe-keyshare/ Htmlized: = http://tools.ietf.org/html/draft-bzwu-tls-ecdhe-keyshare-00 Abstract: This document defines an extension that allows a TLS client to carry Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) keyshare in ClientHello message, so as to reduce the full handshake latency of one network round-trip times (RTT). = =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. The IETF Secretariat From nobody Mon Apr 27 10:18: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 6E1911A8AC2 for ; Mon, 27 Apr 2015 10:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.228 X-Spam-Level: X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, URI_NO_WWW_INFO_CGI=2.071] 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 rKXH1-WFPfqc for ; Mon, 27 Apr 2015 10:18:08 -0700 (PDT) Received: from mail-vn0-f47.google.com (mail-vn0-f47.google.com [209.85.216.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 ECA031A8A60 for ; Mon, 27 Apr 2015 10:18:03 -0700 (PDT) Received: by vnbf190 with SMTP id f190so12791594vnb.1 for ; Mon, 27 Apr 2015 10:18: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=G5CsAZDwx4Ldul6gRt81YTlANq4FIQJab66BXoldUw0=; b=lyRtswp+bqB9cpEc2OJdnqnByrgGkBZwrNFkuAhB7gFyvZzpdfDHq6z4FWPe0fA3Av BSTy78rffiyaXped4OMZRr4j51MsWLU1RZWo6/TN+ljFQB7t4lbENw3ENJtyyFe5IZDb JT6rICU2Y6J6YMjY2NFwhb5RcRfs03O0VxckI58MlHhGh0ySM4xYRTGouJcnoz2nrvHK 0uWdAIzqfTtl3suVGIEXxarSN0XNFRkq53cuCot1yEKwD+S5/fu2DXNzoKJtk+7aPGky f31SVqzSIFr6L0G/AAU7JxolGHmLoYmCuQPR0Dbau4HPHSDukzhCSSET6Fw7WiodfP1u YoEA== X-Gm-Message-State: ALoCoQnJ1Lqc4N5AaqgtPToLiDnGuZTRBKljfpjqkJMSBPQHV0AQqtgzo2v51W9L5MXWe/cdgZTC X-Received: by 10.52.114.42 with SMTP id jd10mr28805467vdb.90.1430155083109; Mon, 27 Apr 2015 10:18:03 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:8d57:b850:1714:c34a? ([2601:a:2a00:84:8d57:b850:1714:c34a]) by mx.google.com with ESMTPSA id c7sm26925304vdw.16.2015.04.27.10.18.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 10:18:02 -0700 (PDT) Message-ID: <553E6F4A.6080103@nthpermutation.com> Date: Mon, 27 Apr 2015 13:18:02 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Peter Gutmann , Hugo Krawczyk References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> , <553D4FF7.8080700@nthpermutation.com> <9A043F3CF02CD34C8E74AC1594475C73AB0084CA@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB0084CA@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: multipart/alternative; boundary="------------090300010509050801060705" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?windows-1252?q?confirming_the_room=92s_consensus=3A_adopt?= =?windows-1252?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2015 17:18:11 -0000 This is a multi-part message in MIME format. --------------090300010509050801060705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 4/27/2015 2:06 AM, Peter Gutmann wrote: > Michael StJohns writes: > > >This isn't about TLS specifically, but about how an HSM makes sure an > >attacker can't extract TLS keys. > > Stepping back a bit in order to actually see the woods here, why is > this an > issue? Anyone who's using hardware for performance reasons will offload > everything to an SSL terminator, almost everyone else who doesn't want > to do > that will do the crypto on the host, those worried about private-key > security > will store the server key in an HSM but not do the bulk crypto there > because > doing it on the host is typically much faster, and even if you do use > PKCS #11 > to do your bulk crypto for TLS, any attacker who's in a position to > extract > the session keys from an HSM via a PKCS #11 mechanism has to control > the host > it's talking to, in which case they've got direct access to the plaintext > anyway. > > I realise that it's always possible to invent some scenario in which > this is > an issue, but how much of a real-world impact does it actually have? Bob > Relyea suggested TLS 1.2 PRF mechanisms in 2007 on the old Cryptoki > list (and > it seemed his motivation for that was the need to be able to support it in > Mozilla's softoken implementation, for which he needed a defined PKCS #11 > mechanism), and OASIS is just getting around to finalising the > standard for > them now, seven years later. This would seem to indicate that the actual > industry demand for this (not the hypothesised need but the real-world > demand) > is a giant who-cares. > > So as I've already said earlier in this discussion, create the best > mechanism > that's a combination of good crypto design principles and ease of > implementation/deployment for existing implementations, and if someone > specifically wants to do it in an HSM they'll have to accept that > they're the > odd corner case and deal with it. > > Peter. All of these are fair points - but miss the point that only small changes to what we do in TLS will permit securing all of the key material in the HSM and will not add to the cost of a software implementation. Whereas, if you don't do anything, (or you do things like generating IVs as secret material), then the only choice is for the HSM to implement a highly specific TLS crypto system and mark keys as only for use in TLS. Even then, I can't see how to reconcile security between that and the need for exporters given the current definitions. With respect to TLS1.2 PRF et al in PKCS11 - imputing the delay in adding TLS1.2 to the spec to a general lack of a desire to do this in hardware is probably at best only partially correct. A more correct assignment of blame is probably due to the small uptake of TLS1.2 deployments. See https://jve.linuxwall.info/blog/index.php?post/TLS_Survey - I'm not sure how valid the methodology is, but that's 33% in January 2014 and apparently a lot less in 2010 - see page 37 of http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf. I have this suspicion that Heartbleed is at least a substantial driver for the increase. Currently (TLS1.2 and before), generic HSMs can protect the server key pair and, once inserted in the HSM, the session keys. What they can't protect are the steps between. That's an artifact of: use of the same key for both MAC and key expansion and pseudorandom bit generation (e.g. Initial IV and Session Nonce generation); the lack of cryptographic binding between the length and type of the output keys and the key stream generation in the key expansion formation. In any event, there's something of a chicken and egg problem. People don't implement TLS using hardware because the hardware doesn't exist. HSM vendors don't implement TLS (or only implement PKCS11's definition of TLS) because the user base isn't there. Both wait for the other. That also applies between versions - finding a good implementation of TLS1.2 was dependent on there being a market for it and that market took a while to develop as TLS1.0 and 1.1 were working fine for the generic customer (until they weren't....). Finally, someone somewhere has figured out that they don't need to break into a system and steal the plain text if they can just get the system to send it the keys as they generate them. I have no idea if anyone has accomplished such attack successfully, but it's one that bothers me because of how hard it might be to detect and ultimately protect against. The only real defense against such an attack is a security module hardened against over the air attacks - hardening the system only gets you so far. I've pushed hard on this because if it isn't fixed in TLS1.3, it will be at least 10 years to the next deployment iteration. It seems silly to do something that can't be secured if it's relatively easy to do something that can be secured. Later, Mike --------------090300010509050801060705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 4/27/2015 2:06 AM, Peter Gutmann wrote:
Michael StJohns <msj@nthpermutation.com> writes:

>This isn't about TLS specifically, but about how an HSM makes sure an
>attacker can't extract TLS keys.

Stepping back a bit in order to actually see the woods here, why is this an
issue? Anyone who's using hardware for performance reasons will offload
everything to an SSL terminator, almost everyone else who doesn't want to do
that will do the crypto on the host, those worried about private-key security
will store the server key in an HSM but not do the bulk crypto there because
doing it on the host is typically much faster, and even if you do use PKCS #11
to do your bulk crypto for TLS, any attacker who's in a position to extract
the session keys from an HSM via a PKCS #11 mechanism has to control the host
it's talking to, in which case they've got direct access to the plaintext
anyway.

I realise that it's always possible to invent some scenario in which this is
an issue, but how much of a real-world impact does it actually have? Bob
Relyea suggested TLS 1.2 PRF mechanisms in 2007 on the old Cryptoki list (and
it seemed his motivation for that was the need to be able to support it in
Mozilla's softoken implementation, for which he needed a defined PKCS #11
mechanism), and OASIS is just getting around to finalising the standard for
them now, seven years later. This would seem to indicate that the actual
industry demand for this (not the hypothesised need but the real-world demand)
is a giant who-cares.

So as I've already said earlier in this discussion, create the best mechanism
that's a combination of good crypto design principles and ease of
implementation/deployment for existing implementations, and if someone
specifically wants to do it in an HSM they'll have to accept that they're the
odd corner case and deal with it.

Peter.


All of these are fair points - but miss the point that only small changes to what we do in TLS will permit securing all of the key material in the HSM and will not add to the cost of a software implementation. Whereas, if you don't do anything, (or you do things like generating IVs as secret material), then the only choice is for the HSM to implement a highly specific TLS crypto system and mark keys as only for use in TLS. Even then, I can't see how to reconcile security between that and the need for exporters given the current definitions.

With respect to TLS1.2 PRF et al in PKCS11 - imputing the delay in adding TLS1.2 to the spec to a general lack of a desire to do this in hardware is probably at best only partially correct. A more correct assignment of blame is probably due to the small uptake of TLS1.2 deployments. See https://jve.linuxwall.info/blog/index.php?post/TLS_Survey - I'm not sure how valid the methodology is, but that's 33% in January 2014 and apparently a lot less in 2010 - see page 37 of http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf. I have this suspicion that Heartbleed is at least a substantial driver for the increase.

Currently (TLS1.2 and before), generic HSMs can protect the server key pair and, once inserted in the HSM, the session keys. What they can't protect are the steps between. That's an artifact of: use of the same key for both MAC and key expansion and pseudorandom bit generation (e.g. Initial IV and Session Nonce generation); the lack of cryptographic binding between the length and type of the output keys and the key stream generation in the key expansion formation.

In any event, there's something of a chicken and egg problem. People don't implement TLS using hardware because the hardware doesn't exist. HSM vendors don't implement TLS (or only implement PKCS11's definition of TLS) because the user base isn't there. Both wait for the other. That also applies between versions - finding a good implementation of TLS1.2 was dependent on there being a market for it and that market took a while to develop as TLS1.0 and 1.1 were working fine for the generic customer (until they weren't....).

Finally, someone somewhere has figured out that they don't need to break into a system and steal the plain text if they can just get the system to send it the keys as they generate them. I have no idea if anyone has accomplished such attack successfully, but it's one that bothers me because of how hard it might be to detect and ultimately protect against. The only real defense against such an attack is a security module hardened against over the air attacks - hardening the system only gets you so far.

I've pushed hard on this because if it isn't fixed in TLS1.3, it will be at least 10 years to the next deployment iteration. It seems silly to do something that can't be secured if it's relatively easy to do something that can be secured.



Later, Mike

--------------090300010509050801060705-- From nobody Mon Apr 27 10:35: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 9677C1A903F for ; Mon, 27 Apr 2015 10:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 q2oF0DCBRXgv for ; Mon, 27 Apr 2015 10:35:36 -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 969DA1A902B for ; Mon, 27 Apr 2015 10:35:36 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id C00C81887F0; Mon, 27 Apr 2015 20:35:33 +0300 (EEST) Date: Mon, 27 Apr 2015 20:35:33 +0300 From: Ilari Liusvaara To: =?utf-8?B?5q2m54Kz5q2jKOWFgeS4rSk=?= Message-ID: <20150427173533.GA910@LK-Perkele-VII> References: <20150427023926.28938.22369.idtracker@ietfa.amsl.com> <008e01d080e5$a2db6de0$e89249a0$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <008e01d080e5$a2db6de0$e89249a0$@alibaba-inc.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-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: Mon, 27 Apr 2015 17:35:38 -0000 On Mon, Apr 27, 2015 at 08:28:16PM +0800, 武炳正(允中) wrote: > > https://datatracker.ietf.org/doc/draft-bzwu-tls-ecdhe-keyshare/ > > This extension allows a TLS client to carry ECDHE keyshare in ClientHello message, so as to reduce the full handshake latency of 1RTT. > > Please kindly review it. Any comments are welcomed. Taking a quick look (not considering if this a good idea or not): > In fact the new version, TLS verion 1.3 > [draft] which works in progress, supports only ECDHE for key > exchange. This is just wrong. In TLS 1.3 editor's copy and in latest draft, non-ECC DHE is supported (2k, 3k, 4k and 8k). (The value list seems to be out-of-sync with ffdhe draft, which also has 6k). > ECParameters curve_params; I consider supporting arbitrary curves here a bad idea. Why not just use values out of EC Named Curve Registry (16-bit)? (That's the way TLS 1.3 does it). > So I have not find any security problem about this extension > yet. Another problem: Defintion of extended_master_secret (security fix!) refers to ClientKeyExchange. The relevant part would have to be redefined (I guess taking session_hash after ServerKeyExchange would work). (Let's not get into working around THS by key checks). -Ilari From nobody Mon Apr 27 11:48: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 8F6AD1A90BF for ; Mon, 27 Apr 2015 11:48:11 -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 nVqf3bE3i4sM for ; Mon, 27 Apr 2015 11:48:09 -0700 (PDT) Received: from mail-vn0-f42.google.com (mail-vn0-f42.google.com [209.85.216.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9755F1A6F17 for ; Mon, 27 Apr 2015 11:48:09 -0700 (PDT) Received: by vnbg7 with SMTP id g7so13141891vnb.11 for ; Mon, 27 Apr 2015 11:48:08 -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 :content-transfer-encoding; bh=0keAlSQgDmSFOwUqETgkNq60JoHOtt0eXaUcBQEAK2g=; b=GP5Ct/tqdn1472qMyfawCiRITNOta/kBfuhmuz050K9h8BMrK30Ua5sFPIn6J9fvDJ 18hYvYhgVyNrYfMhD/j7UO4hk69Km3NmI+60D74spINlJ7l4Wqm3LQnGErulzOMkKG5O j4teG4fyL9xInZck5z5t+NM3nMwG3TbU+gZf0qRXLngB/2XV2IaPc+Z+28CYYjf+K5Pu CAzTl3mEqvsZI6s8rmOa80nUq7JCLCfqn3XeriHjzFFvj6dyUx+JYsrIJTJDs13jRHsn 2b793ZLlrTP996bO2HopwuQ+xGuyEB2dao5AXk46bCwSZ6W/pNamgZR06mVzlQ5wTSyM 8bUQ== X-Gm-Message-State: ALoCoQkGbbXiRXhQTQN6mXoABtHPRPiXlzjXG8vPFE5OqLolrPZpVzuTHdLFT882CSodv0yncJcg X-Received: by 10.52.228.130 with SMTP id si2mr11521820vdc.13.1430160488692; Mon, 27 Apr 2015 11:48:08 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:84:8d57:b850:1714:c34a? ([2601:a:2a00:84:8d57:b850:1714:c34a]) by mx.google.com with ESMTPSA id jk10sm27211314vdb.13.2015.04.27.11.48.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 11:48:08 -0700 (PDT) Message-ID: <553E8468.6070205@nthpermutation.com> Date: Mon, 27 Apr 2015 14:48:08 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yoav Nir References: <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> <20150426182025.GA3549@LK-Perkele-VII> <553D5898.3090902@nthpermutation.com> <3E5464E9-80BF-4D2E-A6C1-EF4E47A99268@gmail.com> <553D7397.9090000@nthpermutation.com> <25BAE048-8AF0-4F36-88FD-CFB4D577265E@gmail.com> In-Reply-To: <25BAE048-8AF0-4F36-88FD-CFB4D577265E@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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, 27 Apr 2015 18:48:11 -0000 On 4/27/2015 3:51 AM, Yoav Nir wrote: >>> The ChaCha20-Poly1305 for IPsec draft does the same thing, and in fact so does RFC 5288 (AES-GCM for TLS 1.2) >> > >> >Citing your own draft as proof of your own argument is a bit.... well… > That WG draft is in WGLC now, so it it’s doing something that is wrong, now would be a good time to say why. It’s also doing the exact same thing that IPsec has been doing with AEADs since 4106 and TLS since 5288. All of these combined a 64-bit explicit IV with a 32-bit salt that is derived as part of the keying materials (KEYMAT for IPsec, key_block for TLS) and never ever transmitted. See below: Basically getting your nonce/IV material from the same key stream production of your keys is problematic. You'd be better off specifying a different mechanism for producing such material, even if it differs from what is done throughout IPSEC. But that's a side show and rat hole we need not go down for TLS. > >> >In any event, I note that your IPSEC draft doesn't actually describe the ESP payload format, so without that, I'd make the assumption that the IV is included before the payload as is described in the IPSEC ESP document. >> > >>> >> >>> >>So no, that salt (and by extension, the proposed 96-bit value) need not be secret, but it’s never transmitted. >> >In which of the above? Maybe in the chacha20 draft... but not in the other two. >> > >> >And RFC5288 does it the wrong way - getting IV (session nonce) material from the same key stream as key material. That hopefully will be fixed with TLS1.3. It would have been much more preferable to use a zero session nonce than extract it from the key stream. > You are saying that this is wrong. Why? Because TLS1.2 had eliminated the IV production as part of the key expansion from the master secret phase. The AEAD suites added it back in. Without the IV production, it would have been somewhat easier to secure some of the TLS HSM functionality. And given that zero session nonces are completely acceptable and secure, that would have been a fine fixed choice instead of the one that was made. > >>> >> This also shows that there is good precedent for generating such a doesn’t-really-need-to-be-secret value from the key_block or KEYMAT. >> > >> >I'm pretty sure it doesn't. It just shows a continuous misunderstanding of the problems with doing it this way. > And those problems are…? > Let me try this one last time. I must just not be speaking the same language as the rest of you. The generic definition of a KDF both in TLS and IPSEC looks something like: Key_Stream = KDF (MasterSecret, Mixins, Length Of KeyStream) The above is deterministic - if you call the same KDF repeatedly with the same master secret, mixins and length, you will get the exact same key stream. The details of how you get that key stream differ between the two, but you still end up get a block of pseudo-random bytes of a certain length. E.g. pretend I've derived a keystream of 20 octets for IPSEC: 0x112233445566778899aabbccddeeff0011223344 In both TLS and IPSEC, the key stream is then broken down into parts that are assigned to secret keys, and unfortunately to values that are not secret (e.g. IV's nonces, etc). For example, a new KEYMAT is generated for each GCM key and broken down into the key and salt (per RFC4106 section 8.1). However, the split in the key stream is under user control. For both TLS and the IPSEC, I can call the appropriate function and assign any part of the key stream to secret or public status. While the IPSEC spec says to generate 20 octets for a 128 bit GCM key, and to assign 4 octets of that to the salt, if I instead assign 0 octets to a key and 20 octets to a salt, I've managed to move what I thought was secret into a public part. E.g. the first call gets me an AES key of 0x112233445566778899aabbccddeeff00 with a salt of 0x11223344; the second call by the attacker gets him only a salt of 0x112233445566778899aabbccddeeff0011223344 which coincidentally has the exact same value as the generated key stream. This is important because calling sequences for HSM versions of these KDFs have no way of knowing - FOR A SPECIFIC CALL - the *real* purpose of a desired key. The user may make a call to do the split along the 16/4 lines, but an attacker can use the same exact call with different key targets to get the 0/20 split and extract the derived AES key. Mixing the production of secret and not-secret data in the same call to a KDF without a way of cryptographically isolating the result means that you can never be sure of the secrecy of the derived keys in an HSM. There are ways to mitigate this: mandatory mixins of the length and types of material to be produced to the key stream production phase. That way, changes to the keystream to key assignments result in completely different keystream material and avoid this problem. An HSM can enforce the keystream to key assignments and even allow non-key material to be produced IF that is appropriately mixed in. All of this is generally not a big issue for software only implementations because all memory is outside of any assurance boundary and the treatment of any stream of bytes as public or secret are matters of convention rather than enforced policy. I'm going to stop talking on this set of threads now. My head hurts. Mike From nobody Mon Apr 27 19:53: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 40F931ACE27 for ; Mon, 27 Apr 2015 19:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Dk82U1AwhzLr for ; Mon, 27 Apr 2015 19:53:19 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id AB1C51ACE26 for ; Mon, 27 Apr 2015 19:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430189597; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=J+lTpbOMZ9Gn/PbxydsZ1aqrVOZEeRhTyP/1UOAxNP4=; b=xAJjmJXt6b/IMRtyU1O2siHvh9rFbK28xDi/njNvFNvktvcGtJNabOiuq/6tqrKmj0/PmSTzl6E63mwsRoJQcDuiHm29+6BSPeIErURZkX242Grw91qGmCq8Za/xILXMdN15hS3lmpxKkNT/1pRhOzKv6qjaudvmtlgSLJQJ2Cc= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R281e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03048; MF=bingzheng.wbz@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from ali074145n(mailfrom:bingzheng.wbz@alibaba-inc.com ip:42.120.74.185) by smtp.aliyun-inc.com(127.0.0.1); Tue, 28 Apr 2015 10:53:13 +0800 From: "=?GBK?B?zuSx/tX9KNTK1tAp?=" To: "'Ilari Liusvaara'" References: <20150427023926.28938.22369.idtracker@ietfa.amsl.com> <008e01d080e5$a2db6de0$e89249a0$@alibaba-inc.com> <20150427173533.GA910@LK-Perkele-VII> In-Reply-To: <20150427173533.GA910@LK-Perkele-VII> Date: Tue, 28 Apr 2015 10:53:13 +0800 Message-ID: <001c01d0815e$783cbde0$68b639a0$@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: AQINWeqB9X5GafILLq6JDjmchKPzTALdk8vxAddxaV6cwlu5sA== Content-Language: zh-cn Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: =?GBK?B?zuSx/tX9KNTK1tAp?= List-Id: "This is the mailing list 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, 28 Apr 2015 02:53:20 -0000 > -----Original Message----- > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > Sent: Tuesday, April 28, 2015 1:36 AM > To: =E6=AD=A6=E7=82=B3=E6=AD=A3(=E5=85=81=E4=B8=AD) > Cc: tls@ietf.org > Subject: Re: [TLS] New Version Notification for > draft-bzwu-tls-ecdhe-keyshare-00.txt >=20 > On Mon, Apr 27, 2015 at 08:28:16PM +0800, = =E6=AD=A6=E7=82=B3=E6=AD=A3(=E5=85=81=E4=B8=AD) wrote: > > > > https://datatracker.ietf.org/doc/draft-bzwu-tls-ecdhe-keyshare/ > > > > This extension allows a TLS client to carry ECDHE keyshare in = ClientHello > message, so as to reduce the full handshake latency of 1RTT. > > > > Please kindly review it. Any comments are welcomed. >=20 > Taking a quick look (not considering if this a good idea or not): >=20 > > In fact the new version, TLS verion 1.3 [draft] which works in > > progress, supports only ECDHE for key exchange. >=20 > This is just wrong. In TLS 1.3 editor's copy and in latest draft, = non-ECC DHE is > supported (2k, 3k, 4k and 8k). Thanks for reminding. Maybe a 'type' should be added in each ClientKeyShareOffer, to indicate = different Diffie-Hellman exchange. And change this extension's name from ECDHE-keyshare to DH-keyshare. >=20 > (The value list seems to be out-of-sync with ffdhe draft, which also = has 6k). >=20 > > ECParameters curve_params; >=20 > I consider supporting arbitrary curves here a bad idea. Why not just = use values > out of EC Named Curve Registry (16-bit)? >=20 > (That's the way TLS 1.3 does it). I tried to change as less as possible, to avoid unnecessary trouble, = both in protocol or implementation. >=20 > > So I have not find any security problem about this extension yet. >=20 > Another problem: >=20 > Defintion of extended_master_secret (security fix!) refers to > ClientKeyExchange. The relevant part would have to be redefined (I = guess > taking session_hash after ServerKeyExchange would work). I think so too. I will add this in the draft after reading this extension carefully. >=20 > (Let's not get into working around THS by key checks). >=20 >=20 >=20 > -Ilari Thanks for your comments again Bingzheng Wu From nobody Mon Apr 27 21:54: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 EB55E1A0027 for ; Mon, 27 Apr 2015 21:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 KLrLcoU9YzHp for ; Mon, 27 Apr 2015 21:54:43 -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 9484F1A0011 for ; Mon, 27 Apr 2015 21:54:43 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 227401887BE; Tue, 28 Apr 2015 07:54:41 +0300 (EEST) Date: Tue, 28 Apr 2015 07:54:40 +0300 From: Ilari Liusvaara To: =?utf-8?B?5q2m54Kz5q2jKOWFgeS4rSk=?= Message-ID: <20150428045440.GA7907@LK-Perkele-VII> References: <20150427023926.28938.22369.idtracker@ietfa.amsl.com> <008e01d080e5$a2db6de0$e89249a0$@alibaba-inc.com> <20150427173533.GA910@LK-Perkele-VII> <001c01d0815e$783cbde0$68b639a0$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <001c01d0815e$783cbde0$68b639a0$@alibaba-inc.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-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, 28 Apr 2015 04:54:46 -0000 On Tue, Apr 28, 2015 at 10:53:13AM +0800, 武炳正(允中) wrote: > > > > -----Original Message----- > > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > > Sent: Tuesday, April 28, 2015 1:36 AM > > To: 武炳正(允中) > > Cc: tls@ietf.org > > Subject: Re: [TLS] New Version Notification for > > draft-bzwu-tls-ecdhe-keyshare-00.txt > > > > On Mon, Apr 27, 2015 at 08:28:16PM +0800, 武炳正(允中) wrote: > > > > > > https://datatracker.ietf.org/doc/draft-bzwu-tls-ecdhe-keyshare/ > > > > > > This extension allows a TLS client to carry ECDHE keyshare in ClientHello > > message, so as to reduce the full handshake latency of 1RTT. > > > > > > Please kindly review it. Any comments are welcomed. > > > > Taking a quick look (not considering if this a good idea or not): > > > > > In fact the new version, TLS verion 1.3 [draft] which works in > > > progress, supports only ECDHE for key exchange. > > > > This is just wrong. In TLS 1.3 editor's copy and in latest draft, non-ECC DHE is > > supported (2k, 3k, 4k and 8k). > > Thanks for reminding. > Maybe a 'type' should be added in each ClientKeyShareOffer, to indicate different Diffie-Hellman exchange. > And change this extension's name from ECDHE-keyshare to DH-keyshare. Well, there is a draft in pipeline (IETF LC complete, waiting for writeup) that assigns a range of group IDs for finite-field Diffie- Hellman (the TLS 1.3 group ids come from there). Basically, the MSB of group ID being 0x01 means DHE (others are ECDHE). > > > ECParameters curve_params; > > > > I consider supporting arbitrary curves here a bad idea. Why not just use values > > out of EC Named Curve Registry (16-bit)? > > > > (That's the way TLS 1.3 does it). > > I tried to change as less as possible, to avoid unnecessary trouble, both in protocol or implementation. Well, the difference between ECParameters and NamedCurve when non-named groups are disallowed is extra 0x03 prefix (to designate NamedCurve). Also, I consider using non-named groups to bring more security problems than it is worth (e.g. currently known ways to exploit THS for (EC)DHE rely on those). > > > So I have not find any security problem about this extension yet. > > > > Another problem: > > > > Defintion of extended_master_secret (security fix!) refers to > > ClientKeyExchange. The relevant part would have to be redefined (I guess > > taking session_hash after ServerKeyExchange would work). > > I think so too. > I will add this in the draft after reading this extension carefully. Basically, the point needs to be after ServerKeyExchange (security) but before ChangeCipherSpec (possible to implement). (Without extensions, there is only one such point, but certain extensions can add extra messages). -Ilari From nobody Mon Apr 27 22:49: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 B82861A00F1 for ; Mon, 27 Apr 2015 22:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfq-BfUgfmnN for ; Mon, 27 Apr 2015 22:49:08 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010: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 285811A00CF for ; Mon, 27 Apr 2015 22:49:08 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so98915010lbc.1 for ; Mon, 27 Apr 2015 22:49:06 -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:from:date:message-id :subject:to:cc:content-type; bh=3hg8ITCoZYQFZF2A1c38MIOxRFRMCQkjkFkwby6HlCM=; b=TNwOp8pTyhu6hUsBrY+cfgNdrA/Dn4+iSf/yVpR0/2UcNO6yWKX/MgreLK4vxqt2sS tpkqbtfLyw9bsipU5tZTC427/WYb9bkChr3+jetbzhzHsniuknuYc4bqgjhEuI0BjYZq U/QTWmAdh8kchS+uwuvH1PjrwyU9SYc6a4Fqnzr0N5/LUxEoaPwr37btHBSmS8izAQlE Hri0dI0IyCZuqRW2fd5Kb/wOkm2X0YoaqhYUf0dl8Mp4djaqTiH4LGPYYI47Tm2FBLr8 4NPMISSDHhp/d66j9s2ol2Yh5xGy0dNXCXMAlUVkhnFQIZgk0k2/jZ59o+Y/8c64+EHP A7VA== X-Received: by 10.152.28.97 with SMTP id a1mr13286945lah.9.1430200146472; Mon, 27 Apr 2015 22:49:06 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.66 with HTTP; Mon, 27 Apr 2015 22:48:35 -0700 (PDT) In-Reply-To: <553D4FF7.8080700@nthpermutation.com> References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> <553D4FF7.8080700@nthpermutation.com> From: Hugo Krawczyk Date: Tue, 28 Apr 2015 01:48:35 -0400 X-Google-Sender-Auth: HKLRc2ymbMXBPPq1bTDaBJlOAD0 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=089e0160b7d4b035be0514c26b8d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?= =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2015 05:49:10 -0000 --089e0160b7d4b035be0514c26b8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike, thanks a lot for the clear explanation! I think I can now understand the issues you were raising. Sorry for my ignorance. One thing I (think I) understand now is that this discussion had little to do with HKDF (specifically) but rather has to do with the inputs to the KDF function defined by the calling protocol, say TLS 1.3. We can define TLS 1.3 so that calls to HKDF will always include a info string composed of: label, context (say, session-hash) and the length L of the output key material. Now, in the HSM implementation you will read the values label and context from the user's input but L will be added by the HSM itself by calculating the length of the required key. In non-HSM implementations the software will add L. I am perfectly ok with adding L, or any other value, to the HKDF info input in the TLS 1.3 spec if the WG is interested in doing so. Hugo On Sun, Apr 26, 2015 at 4:52 PM, Michael StJohns wrote: > I'm going to slice this up a bit and answer in pieces. Sorry - the > messages are getting too long. > > On 4/26/2015 4:20 PM, Hugo Krawczyk wrote: > > =E2=80=8BI am completely lost on this length issue. Can you give me a con= crete > example where TLS 1.3 derives different keys with same label and context > but with different output lengths? As said, in TLS 1.3 each label and > context is used exactly once. I must be missing something in your argumen= t > but I just can't figure what's that. > > > Hi Hugo - > > This isn't about TLS specifically, but about how an HSM makes sure an > attacker can't extract TLS keys. > > Assume that you implement your function in an HSM as you've defined in th= e > RFC - without the length term. > > Consider that the HSM keys may be USED by the attacker but the HSM is set > up to prevent extraction - the keys can't be directly extracted . (See > below for a discussion of how this might happen). And note that for a > generic KDF interface, you can't ensure that the attacker doesn't use the > same label and context in his call to use the master key as we define for > TLS. > > Consider that the derivation of the master secret from the pre-master > secret can be done by both the user and the attacker, but that the attack= er > can request a key length of 1, but with the same label and context terms > using the same pre-master secret. Consider that the attacker designates > this Length 1 key as an HMAC key. > > The attacker now uses his version of the derived key as an HMAC key and > uses it to generate an HMAC tag over a fixed value. He then compares thi= s > to 256 generated HMACs over the same fixed value but using the 256 > different possible values of the derived key from above. When he finds a > match between one of his 256 HMACs and the HMAC using the derived key, he > now knows that the value of that derived key. > > Consider that *without the length term, a key of length 1 has as its key > value the same first byte of any key stream of longer length generated fr= om > the same master key with the same label and context*. > > By repeating the steps above, you can extract the master secret in O(1). > > If the L term is mixed in by internal mechanism, there is no user > accessible mechanism to accomplish this. I.e. using the same secret with > identical labels and contexts with differing requested output lengths > produce cryptographically disjoint key material. If you only pass this > in as user specified material you don't get this protection. > > If you ask me how an attacker can "use" the keys of someone else, conside= r > that most versions of PKCS11 support only a PIN based authentication, or > authentication is done because the HSM is embedded in the system. The > thing I'm trying to get to is a model where I can demonstrate that key > material may not be extracted from an HSM by an attacker, even if the > attacker has credentials to "use" the keys. > > Mike > > --089e0160b7d4b035be0514c26b8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike, thanks a lot for the clear explanation!
I think I can now understand the issues you were raising= . Sorry for my ignorance.

One thing I (think I) u= nderstand now is that this discussion had little to do with HKDF (specifica= lly) but rather has to do with the inputs to the KDF function defined by th= e calling protocol, say TLS 1.3.

We can define TLS 1.3 so that call= s to HKDF will always include a info string composed of:
label, context = (say, session-hash) and the length L of the output key material.
=
Now, in the HSM implementation you will read the values label an= d context from the user's input but L will=C2=A0 be added by the HSM it= self by calculating the length of the required key. In non-HSM implementati= ons the software will add L.

I am perfectly ok with= adding L, or any other value, to the HKDF info input in the TLS 1.3 spec i= f the WG is interested in doing so.

Hugo

<= br>

On Sun, = Apr 26, 2015 at 4:52 PM, Michael StJohns <msj@nthpermutation.com&= gt; wrote:
=20 =20 =20
I'm going to slice this up a bit and answer in pieces.=C2=A0 Sorry - the messages are getting too long.

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
=E2=80=8BI am completely lost on this length = issue. Can you give me a concrete example where TLS 1.3 derives different keys with same label and context but with different output lengths? As said, in TLS 1.3 each label and context is used exactly once. I must be missing something in your argument but I just can't figur= e what's that.

 Hi Hugo -

This isn't about TLS specifically, but about how an HSM makes sure an attacker can't extract TLS keys.=C2=A0

Assume that you implement your function in an HSM as you've defined in the RFC - without the length term.

Consider that the HSM keys may be USED by the attacker but the HSM is set up to prevent extraction - the keys can't be directly extracted . (See below for a discussion of how this might happen).=C2= =A0 And note that for a generic KDF interface, you can't ensure that th= e attacker doesn't use the same label and context in his call to use the master key as we define for TLS.=C2=A0

Consider that the derivation of the master secret from the pre-master secret can be done by both the user and the attacker, but that the attacker can request a key length of 1, but with the same label and context terms using the same pre-master secret.=C2=A0 Conside= r that the attacker designates this Length 1 key as an HMAC key.

The attacker now uses his version of the derived key as an HMAC key and uses it to generate an HMAC tag over a fixed value.=C2=A0 He then compares this to 256 generated HMACs over the same fixed value but using the 256 different possible values of the derived key from above.=C2=A0 When he finds a match between one of his 256 HMACs and the HMAC using the derived key, he now knows that the value of that derived key.

Consider that without the length term, a key of length 1 has as its key value the same first byte of any key stream of longer length generated from the same master key with the same label and context.

By repeating the steps above, you can extract the master secret in O(1).

If the L term is mixed in by internal mechanism, there is no user accessible mechanism to accomplish this.=C2=A0 I.e. using the same secr= et with identical labels and contexts with differing requested output lengths produce cryptographically disjoint key material.=C2=A0=C2=A0=C2= =A0 If you only pass this in as user specified material you don't get this protection.

If you ask me how an attacker can "use" the keys of someone e= lse, consider that most versions of PKCS11 support only a PIN based authentication, or authentication is done because the HSM is embedded in the system.=C2=A0 The thing I'm trying to get to is a m= odel where I can demonstrate that key material may not be extracted from an HSM by an attacker, even if the attacker has credentials to "us= e" the keys.

Mike


--089e0160b7d4b035be0514c26b8d-- From nobody Mon Apr 27 23: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 532CA1A026A for ; Mon, 27 Apr 2015 23:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 nAAM1tvfIXKj for ; Mon, 27 Apr 2015 23:34:50 -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 F38031A0354 for ; Mon, 27 Apr 2015 23:34:28 -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 6018981976; Tue, 28 Apr 2015 09:34:26 +0300 (EEST) Date: Tue, 28 Apr 2015 09:34:25 +0300 From: Ilari Liusvaara To: Hugo Krawczyk Message-ID: <20150428063425.GA9647@LK-Perkele-VII> References: <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <55392B08.6020304@nthpermutation.com> <553D3572.6040408@nthpermutation.com> <553D4FF7.8080700@nthpermutation.com> 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] =?utf-8?q?confirming_the_room=E2=80=99s__consensus=3A_adopt?= =?utf-8?q?_HKDF_PRF_for_TLS_1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2015 06:34:52 -0000 On Tue, Apr 28, 2015 at 01:48:35AM -0400, Hugo Krawczyk wrote: > Mike, thanks a lot for the clear explanation! > I think I can now understand the issues you were raising. Sorry for my > ignorance. > > One thing I (think I) understand now is that this discussion had little to > do with HKDF (specifically) but rather has to do with the inputs to the KDF > function defined by the calling protocol, say TLS 1.3. > > We can define TLS 1.3 so that calls to HKDF will always include a info > string composed of: > label, context (say, session-hash) and the length L of the output key > material. > Now, in the HSM implementation you will read the values label and context > from the user's input but L will be added by the HSM itself by calculating > the length of the required key. In non-HSM implementations the software > will add L. I think some proposals also had key usage for derived key as an input. Some examples of possible usages: - KDF input key (e.g. handshake master secret) - AES-GCM key - AES-CCM key - AES-CCM8 key - Chacha20-Poly1305 key - HMAC-SHA256 key (MAC-only key) - Initial IV (you have other exportables anyway) - Exportable octet string (e.g. the unique output) This doesn't look too difficult to add (e.g. just stick as two first octets of info or something). -Ilari From nobody Mon Apr 27 23:41: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 81CC71A0371 for ; Mon, 27 Apr 2015 23:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 G_Rd5xueQZaC for ; Mon, 27 Apr 2015 23:41:21 -0700 (PDT) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB321A0354 for ; Mon, 27 Apr 2015 23:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430203280; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=YLwdWtWafsX+vQafbplD8nQITEheE23R0510Vux8v5c=; b=NkcfTjYb/5gK0aX1to3mwd02gNl+fGXYo9ZO6SCLh35VP7I1VcfQthLH9WmDyWwEnANSI82SLxawwW89hcJWXWQn6ApDe6OFFomAK0RWrjhGuzYlQcyh01vyEjr1tn+jt4rHedSkzGuyCi4ozTNF30jGGUC7loSc2VxAwJGyezs= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03025; MF=bingzheng.wbz@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from ali074145n(mailfrom:bingzheng.wbz@alibaba-inc.com ip:42.120.74.158) by smtp.aliyun-inc.com(127.0.0.1); Tue, 28 Apr 2015 14:41:19 +0800 From: "=?GBK?B?zuSx/tX9KNTK1tAp?=" To: "'Ilari Liusvaara'" References: <20150427023926.28938.22369.idtracker@ietfa.amsl.com> <008e01d080e5$a2db6de0$e89249a0$@alibaba-inc.com> <20150427173533.GA910@LK-Perkele-VII> <001c01d0815e$783cbde0$68b639a0$@alibaba-inc.com> <20150428045440.GA7907@LK-Perkele-VII> In-Reply-To: <20150428045440.GA7907@LK-Perkele-VII> Date: Tue, 28 Apr 2015 14:41:18 +0800 Message-ID: <004c01d0817e$55580a80$00081f80$@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: AQINWeqB9X5GafILLq6JDjmchKPzTALdk8vxAddxaV4BIDadsAG0ZDKLnKvzU0A= Content-Language: zh-cn Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: =?GBK?B?zuSx/tX9KNTK1tAp?= List-Id: "This is the mailing list 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, 28 Apr 2015 06:41:22 -0000 > > Thanks for reminding. > > Maybe a 'type' should be added in each ClientKeyShareOffer, to = indicate > different Diffie-Hellman exchange. > > And change this extension's name from ECDHE-keyshare to DH-keyshare. >=20 > Well, there is a draft in pipeline (IETF LC complete, waiting for > writeup) that assigns a range of group IDs for finite-field Diffie- = Hellman (the > TLS 1.3 group ids come from there). >=20 > Basically, the MSB of group ID being 0x01 means DHE (others are = ECDHE). Thanks again. I find it in = http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ . So it seems that the 'type' is not need. I only need to change the extension's name and description. > > > I consider supporting arbitrary curves here a bad idea. Why not = just > > > use values out of EC Named Curve Registry (16-bit)? > > > > > > (That's the way TLS 1.3 does it). > > > > I tried to change as less as possible, to avoid unnecessary trouble, = both in > protocol or implementation. >=20 > Well, the difference between ECParameters and NamedCurve when > non-named groups are disallowed is extra 0x03 prefix (to designate > NamedCurve). It's still easier to reuse tls1_check_curve() in OpenSSL if keeping the = extra prefix. >=20 > Also, I consider using non-named groups to bring more security = problems than > it is worth (e.g. currently known ways to exploit THS for (EC)DHE rely = on those). This extension aims to reduce the handshake's latency only. I think it's more clear that this extension behaves the same as normal = handshake, both for SSL library's developer and web server = administrator. If someone thinks non-named curve is not safe, he should find a way to = disable it for normal handshake; and this extension will not use non-named curves then. For example, a web server administrator may prefer the instructions that = "non-named curve is not safe. disable it in configure file", than " non-named curve is not safe. but there is an extension which = disable it automatically. However you still need to disable it in = configure file". expect for your recommendation Bingzheng Wu From nobody Tue Apr 28 01:17: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 5C3AE1A1A6A for ; Tue, 28 Apr 2015 01:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 dkpKiAGS862u for ; Tue, 28 Apr 2015 01:17:19 -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 071C01A1A60 for ; Tue, 28 Apr 2015 01:17:16 -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 1E1C9817EE; Tue, 28 Apr 2015 11:17:14 +0300 (EEST) Date: Tue, 28 Apr 2015 11:17:13 +0300 From: Ilari Liusvaara To: =?utf-8?B?5q2m54Kz5q2jKOWFgeS4rSk=?= Message-ID: <20150428081713.GA10271@LK-Perkele-VII> References: <20150427023926.28938.22369.idtracker@ietfa.amsl.com> <008e01d080e5$a2db6de0$e89249a0$@alibaba-inc.com> <20150427173533.GA910@LK-Perkele-VII> <001c01d0815e$783cbde0$68b639a0$@alibaba-inc.com> <20150428045440.GA7907@LK-Perkele-VII> <004c01d0817e$55580a80$00081f80$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <004c01d0817e$55580a80$00081f80$@alibaba-inc.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-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, 28 Apr 2015 08:17:21 -0000 On Tue, Apr 28, 2015 at 02:41:18PM +0800, 武炳正(允中) wrote: > > > > > Also, I consider using non-named groups to bring more security problems than > > it is worth (e.g. currently known ways to exploit THS for (EC)DHE rely on those). > > This extension aims to reduce the handshake's latency only. > I think it's more clear that this extension behaves the same as normal handshake, both for SSL library's developer and web server administrator. > If someone thinks non-named curve is not safe, he should find a way to disable it for normal handshake; > and this extension will not use non-named curves then. > > For example, a web server administrator may prefer the instructions that "non-named curve is not safe. disable it in configure file", > than " non-named curve is not safe. but there is an extension which disable it automatically. However you still need to disable it in configure file". Actually, I think I figured out a nasty exploit. By choosing a suitable curve (assuming both server and client accept it), one can ECDL the server's exchange key and thus impersonate the server. Extended_master_secret will not save you. This exploit won't work with named groups (even without key order check). This is because client's premaster secret is too hard to compute. Also, TLS 1.3 server auth is different, so the same exploit won't work there either (even if it allowed non-named groups, which it doesn't). -Ilari From nobody Tue Apr 28 04:42: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 1EAFC1A8A1B for ; Tue, 28 Apr 2015 04:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 D2DWegojZ5uW for ; Tue, 28 Apr 2015 04:42:41 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5559C1A89C7 for ; Tue, 28 Apr 2015 04:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430221358; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=O5MIEgLfJhW66SKj8yDK9I2tlozTwm/y5LdZECSPDDI=; b=LuEsU1enDtiAz4adC2KriA62SxSVgtv4OZOU4aJRAVn6aMPOf3OZo7radJu/df82hfrRMyMo0theM2jLmqHzylsDDpqgZ37tTv8UMO3Ts04s/h7scPrxt21AW57H4GpHKF774Ka/R2NPm1aMAXpSwXa94NbPfkFPikk2m8JbDng= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g08145; MF=bingzheng.wbz@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from ali074145n(mailfrom:bingzheng.wbz@alibaba-inc.com ip:42.120.74.180) by smtp.aliyun-inc.com(127.0.0.1); Tue, 28 Apr 2015 19:42:37 +0800 From: "=?GBK?B?zuSx/tX9KNTK1tAp?=" To: "'Ilari Liusvaara'" References: <20150427023926.28938.22369.idtracker@ietfa.amsl.com> <008e01d080e5$a2db6de0$e89249a0$@alibaba-inc.com> <20150427173533.GA910@LK-Perkele-VII> <001c01d0815e$783cbde0$68b639a0$@alibaba-inc.com> <20150428045440.GA7907@LK-Perkele-VII> <004c01d0817e$55580a80$00081f80$@alibaba-inc.com> <20150428081713.GA10271@LK-Perkele-VII> In-Reply-To: <20150428081713.GA10271@LK-Perkele-VII> Date: Tue, 28 Apr 2015 19:42:36 +0800 Message-ID: <006801d081a8$6c9c0f00$45d42d00$@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: AQINWeqB9X5GafILLq6JDjmchKPzTALdk8vxAddxaV4BIDadsAG0ZDKLALAwPGEBMG+Ad5ydR36w Content-Language: zh-cn Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: =?GBK?B?zuSx/tX9KNTK1tAp?= List-Id: "This is the mailing list 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, 28 Apr 2015 11:42:42 -0000 I understand that non-named curve is not safe. But I think that, this extension aims to reduce the handshake's latency = only. The safety should be considered by the TLS protocol, but not this = extension. Whatever, I decide to remove support for non-named curve in the draft's = new version, because it's a litter troublesome to explain the extension_data format = compatible with Negotiated FF Parameters. While it's easier if remove non-named curve, and the extension_data = becomes: struct { NamedGroup group_id; select (typeof(group_id)) { case FF: ClientDiffieHellmanPublic; case EC: ECPoint; } public_key; } ClientKeyShareOffer; =20 Besides, I have changed my draft's name into TLS client-keyshare = extension. So should I submit the new draft now? I am not familiar with the workflow. Thanks again for you valuable recommends. Bingzheng Wu > -----Original Message----- > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > Sent: Tuesday, April 28, 2015 4:17 PM > To: =E6=AD=A6=E7=82=B3=E6=AD=A3(=E5=85=81=E4=B8=AD) > Cc: tls@ietf.org > Subject: Re: [TLS] New Version Notification for > draft-bzwu-tls-ecdhe-keyshare-00.txt >=20 > On Tue, Apr 28, 2015 at 02:41:18PM +0800, = =E6=AD=A6=E7=82=B3=E6=AD=A3(=E5=85=81=E4=B8=AD) wrote: > > > > > > > > Also, I consider using non-named groups to bring more security > > > problems than it is worth (e.g. currently known ways to exploit = THS for > (EC)DHE rely on those). > > > > This extension aims to reduce the handshake's latency only. > > I think it's more clear that this extension behaves the same as = normal > handshake, both for SSL library's developer and web server = administrator. > > If someone thinks non-named curve is not safe, he should find a way = to > > disable it for normal handshake; and this extension will not use = non-named > curves then. > > > > For example, a web server administrator may prefer the instructions > > that "non-named curve is not safe. disable it in configure file", = than " > non-named curve is not safe. but there is an extension which disable = it > automatically. However you still need to disable it in configure = file". >=20 > Actually, I think I figured out a nasty exploit. >=20 > By choosing a suitable curve (assuming both server and client accept = it), one > can ECDL the server's exchange key and thus impersonate the server. > Extended_master_secret will not save you. >=20 > This exploit won't work with named groups (even without key order = check). This > is because client's premaster secret is too hard to compute. >=20 > Also, TLS 1.3 server auth is different, so the same exploit won't work = there > either (even if it allowed non-named groups, which it doesn't). >=20 >=20 > -Ilari From nobody Tue Apr 28 19:48: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 E4E601A8701 for ; Tue, 28 Apr 2015 19:48: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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 x0i0geuCU7rl for ; Tue, 28 Apr 2015 19:48:13 -0700 (PDT) Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com [42.120.133.82]) by ietfa.amsl.com (Postfix) with ESMTP id AF0801A870C for ; Tue, 28 Apr 2015 19:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430275691; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=fn/LEzTD2JnIwKMoN35PwtjWR9qguwZTVRMvj6apJ8M=; b=wUuMF6UhZWlKITdCTBIZfW5Vng5fThw0PGKYrvYGKopMKhc5e+iaPSoylvLAPG9QWMy9xznQ/k2J7E451ujRAT9PovHVmR6+c4V9MfWeg+5PQ4M22ZZ/hzWR2uAZ7Xv/7sGnGvupqoVW8PKAS0DNYEB5lEexJPZsNnYlkGyjNmo= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02009; MF=bingzheng.wbz@alibaba-inc.com; PH=DW; RN=1; RT=1; SR=0; Received: from WS-web (bingzheng.wbz@alibaba-inc.com[42.120.74.157]) by r41g03006.xy2.aliyun.com at Wed, 29 Apr 2015 10:48:09 +0800 Date: Wed, 29 Apr 2015 10:48:09 +0800 From: "Bingzheng Wu" To: "tls" Message-ID: X-Mailer: Alimail-Mailagent revision 2692143 MIME-Version: 1.0 References: 20150429023006.30489.70916.idtracker@ietfa.amsl.com In-Reply-To: 20150429023006.30489.70916.idtracker@ietfa.amsl.com x-aliyun-mail-creator: W4_2692101_IChTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgNi4xOyBXT1c2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzQyLjAuMjMxMS45MCBTYWZhcmkvNTM3LjM2jM Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_7334_4e33f940_55404669_5c3b" Archived-At: Subject: Re: [TLS] =?utf-8?q?New_Version_Notification_for_draft-bzwu-tls-clien?= =?utf-8?q?t-keyshare-00=2Etxt?= 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: Wed, 29 Apr 2015 02:48:15 -0000 ------=ALIBOUNDARY_7334_4e33f940_55404669_5c3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All,=0A=0AA new TLS extension draft has been posted to IETF repository=0A=0A= https://datatracker.ietf.org/doc/draft-bzwu-tls-client-keyshare/=0A=0AThis ext= ension is an update version of https://datatracker.ietf.org/doc/draft-bzwu-tls= -ecdhe-keyshare/ , which was posted last week.=0A=0AUpdate (thanks for Ilari L= iusvaara's advice):=0A - add support for finite-field-based DH=0A - remove sup= port for non-named curves for ECDH=0A=0A=0APlease kindly review it. Any commen= ts are welcomed.=0A=0AThanks and best regards,=0ABingzheng Wu=0A--------------= ----------------------------------------------------From:internet-drafts Send Time:2015 Apr 29 (Wed) 10:30To:=E6=AD=A6=E7=82=B3=E6= =AD=A3(=E5=85=81=E4=B8=AD) Subject:New Version = Notification for draft-bzwu-tls-client-keyshare-00.txt=0A=0AA new version of I= -D, draft-bzwu-tls-client-keyshare-00.txthas been successfully submitted by Bi= ngzheng Wu and posted to theIETF repository.=0AName: draft-bzwu-tls-client-ke= yshareRevision: 00Title: Transport Layer Security (TLS) Client Keyshare Exten= sionDocument date: 2015-04-28Group: Individual SubmissionPages: 7URL: = https://www.ietf.org/internet-drafts/draft-bzwu-tls-client-keyshare-00.tx= tStatus: https://datatracker.ietf.org/doc/draft-bzwu-tls-client-keysha= re/Htmlized: https://tools.ietf.org/html/draft-bzwu-tls-client-keyshare-= 00=0A=0AAbstract: This document defines an extension that allows a TLS clien= t to carry Diffie-Hellman (DH) keyshare in ClientHello message, replacing = ClientKeyExchange message in the 2nd round-trip, so as to reduce the full ha= ndshake latency of one network round-trip time (RTT).=0A=0A=0A=0APlease note t= hat it may take a couple of minutes from the time of submissionuntil the htmli= zed version and diff are available at tools.ietf.org.=0AThe IETF Secretariat ------=ALIBOUNDARY_7334_4e33f940_55404669_5c3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi All,

A new TLS extension draft has been posted to IETF repo= sitory

https://datatracker.ietf.org/doc/draft-bzwu-tls-client-keyshare/=

This extension is an update version of https://datatracker.ietf.org/do= c/draft-bzwu-tls-ecdhe-keyshare/ , which was posted last week.

Update (= thanks for Ilari Liusvaara's advice):
- add support for finite-field-based= DH
- remove support for non-named curves for ECDH


Please kindl= y review it. Any comments are welcomed.

Thanks and best regards,
Bin= gzheng Wu


<= /p>

-----------------------------= -------------------------------------

From:internet-drafts <internet-drafts@ietf.org>

Send Time:2015 Apr 29 (Wed) 10= :30

To:=E6=AD=A6=E7=82= =B3=E6=AD=A3(=E5=85=81=E4=B8=AD) <bingzheng.wbz@alibaba-inc.com><= /p>

Subject:New Version Notificat= ion for draft-bzwu-tls-client-keyshare-00.txt


=

A new version of I-D, draft-bzw= u-tls-client-keyshare-00.txt

has bee= n successfully submitted by Bingzheng Wu and posted to the

IETF repository.


Name: draft-bzwu-tls-clien= t-keyshare

Revision: 00

Title: Transport Layer Security (TLS) Client Keys= hare Extension

Document date: 2015-0= 4-28

Group: Individual Submission

Pages: 7

URL: https://www.ietf.org/internet-drafts/draft-bzwu= -tls-client-keyshare-00.txt

Status: = https://datatracker.ietf.org/doc/draft-bzwu-tls-client-keyshare/

Htmlized: https://tools.ietf.org/ht= ml/draft-bzwu-tls-client-keyshare-00



Abstract:

This d= ocument defines an extension that allows a TLS client to carry

Diffie-Hellman (DH) keyshare in ClientHello mess= age, replacing

ClientKeyExchange = message in the 2nd round-trip, so as to reduce the

full handshake latency of one network round-trip time (RTT).=





Ple= ase note that it may take a couple of minutes from the time of submission

<= p style=3D"margin: 0px; clear: both;">until the htmlized version and diff are = available at tools.ietf.org.


The IETF Secretariat

<= /div> ------=ALIBOUNDARY_7334_4e33f940_55404669_5c3b-- From nobody Wed Apr 29 17:35: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 1A2F31A8A63 for ; Wed, 29 Apr 2015 17:35:26 -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 BOmv2ZDJLOM8 for ; Wed, 29 Apr 2015 17:35:24 -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 498F21A8A55 for ; Wed, 29 Apr 2015 17:35:24 -0700 (PDT) Received: by qkgx75 with SMTP id x75so25243114qkg.1 for ; Wed, 29 Apr 2015 17:35: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:mime-version:content-type :content-transfer-encoding:message-id; bh=FK1Sf3fnYzJn+mWEarVmKTkn8F/EkYMTAtV6R0P5kuE=; b=YMqlarOwEYVmfDDGWz4i1DSgZJ6OIJy2A/Acd2ymc1LTZ6bc3jX96XFywToakFEfQN v6h0ou0OQ1QxMasX+AoixG8PhbrbG4c4U3W0u54+2HBbGx6kZuszORMazkjqIxW3U+Fj i+I0L1rJ51Kc/q8yi3U7TsryiIWuwDMssOlT3cn96ST6suPs8nSLPPw5HvXME9pjIp65 GZ9qilNHesm9W2qQ6Lv2pfMKNhn+3W17FyVHPRsFX+hQxudpmSqsds0cUz8xdadfln5v NNYbIoHPXw0WzYDEhauq7OLuPdJnlC4v7wkCKSWJEUfEAJB5AScHhpV/8YQKNxE/gx5X nD9A== X-Received: by 10.140.194.65 with SMTP id p62mr1973292qha.76.1430354123579; Wed, 29 Apr 2015 17:35: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 n62sm395976qge.27.2015.04.29.17.35.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 29 Apr 2015 17:35:22 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 29 Apr 2015 20:35:21 -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: <201504292035.21721.davemgarrett@gmail.com> Archived-At: Subject: [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: Thu, 30 Apr 2015 00:35:26 -0000 https://tlswg.github.io/tls13-spec/ https://tools.ietf.org/html/draft-ietf-tls-tls13-05 Where does the "Status of This Memo" and "Copyright Notice" text get pulled from? There seems to be some black magic involved in the build process, and I don't see where that text lives. I'd like to request the two URLs be updated, but I don't know where to ask. status has: http://datatracker.ietf.org/drafts/current/ which redirects to: http://datatracker.ietf.org/doc/active/ which does support TLS, and should be: https://datatracker.ietf.org/doc/active/ copyright has: http://trustee.ietf.org/license-info which redirects to: http://trustee.ietf.org/trust-legal-provisions.html which does support TLS, and should be: https://trustee.ietf.org/trust-legal-provisions.html the initial URL also supports TLS, so this works: https://trustee.ietf.org/license-info however that redirects to HTTP, not HTTPS (...sigh) So, yeah... I'd like the new TLS spec to actually attempt to use TLS in its URLs, where possible. To do this needs: 1) Update those two URLs in the template for these sections to use the HTTPS equivalent (in the case of "status", also change "current" to "active"). 2) Get someone to fix the redirects on trustee.ietf.org to redirect to HTTPS, at minimum when already coming from HTTPS. Actually using TLS by default might also be a plan... As to other URLs in the document, I added a couple 's'es in my minor fixes branch/PR. There are additional domains that do support HTTPS, technically, but they get cert errors... because of course they do. The RFC references have an odd inconsistency here. In the numbered working group drafts, they properly generate with HTTPS links: https://tools.ietf.org/html/draft-ietf-tls-tls13-05#section-13.1 However, in the editor's copy (draft-ietf-tls-tls13-latest), they generate with HTTP links: https://tlswg.github.io/tls13-spec/#rfc.references.1 That needs fixing if just for consistency. Also, tools.ietf.org should of course be using HTTPS by default, but it's not. Dave From nobody Thu Apr 30 01:06: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 B7FA71ACEF0 for ; Thu, 30 Apr 2015 01:06:34 -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 tvqRSurn_hjE for ; Thu, 30 Apr 2015 01:06:33 -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 2ED8F1ACEEE for ; Thu, 30 Apr 2015 01:06:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 046AFBE3E; Thu, 30 Apr 2015 09:06:32 +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 eSIZuqG6XuPE; Thu, 30 Apr 2015 09:06:30 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.22]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6742FBE2F; Thu, 30 Apr 2015 09:06:30 +0100 (IST) Message-ID: <5541E286.2090001@cs.tcd.ie> Date: Thu, 30 Apr 2015 09:06:30 +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: Dave Garrett , tls@ietf.org References: <201504292035.21721.davemgarrett@gmail.com> In-Reply-To: <201504292035.21721.davemgarrett@gmail.com> 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: Thu, 30 Apr 2015 08:06:34 -0000 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. On 30/04/15 01:35, Dave Garrett wrote: > https://tlswg.github.io/tls13-spec/ > https://tools.ietf.org/html/draft-ietf-tls-tls13-05 > > Where does the "Status of This Memo" and "Copyright Notice" text get pulled from? There seems to be some black magic involved in the build process, and I don't see where that text lives. I'd like to request the two URLs be updated, but I don't know where to ask. > > status has: > http://datatracker.ietf.org/drafts/current/ > which redirects to: > http://datatracker.ietf.org/doc/active/ > which does support TLS, and should be: > https://datatracker.ietf.org/doc/active/ > > copyright has: > http://trustee.ietf.org/license-info > which redirects to: > http://trustee.ietf.org/trust-legal-provisions.html > which does support TLS, and should be: > https://trustee.ietf.org/trust-legal-provisions.html > the initial URL also supports TLS, so this works: > https://trustee.ietf.org/license-info > however that redirects to HTTP, not HTTPS (...sigh) > > So, yeah... I'd like the new TLS spec to actually attempt to use TLS in its URLs, where possible. To do this needs: > 1) Update those two URLs in the template for these sections to use the HTTPS equivalent (in the case of "status", also change "current" to "active"). > 2) Get someone to fix the redirects on trustee.ietf.org to redirect to HTTPS, at minimum when already coming from HTTPS. > > Actually using TLS by default might also be a plan... > > As to other URLs in the document, I added a couple 's'es in my minor fixes branch/PR. There are additional domains that do support HTTPS, technically, but they get cert errors... because of course they do. > > The RFC references have an odd inconsistency here. In the numbered working group drafts, they properly generate with HTTPS links: > https://tools.ietf.org/html/draft-ietf-tls-tls13-05#section-13.1 > However, in the editor's copy (draft-ietf-tls-tls13-latest), they generate with HTTP links: > https://tlswg.github.io/tls13-spec/#rfc.references.1 > > That needs fixing if just for consistency. > > Also, tools.ietf.org should of course be using HTTPS by default, but it's not. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Thu Apr 30 06:33: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 0A6391B29F4 for ; Thu, 30 Apr 2015 06:33: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 oBdu01jtHpTz for ; Thu, 30 Apr 2015 06:33:52 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 189DA1B29F0 for ; Thu, 30 Apr 2015 06:33:52 -0700 (PDT) Received: by qkgx75 with SMTP id x75so32915907qkg.1 for ; Thu, 30 Apr 2015 06:33:51 -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=L/qHeFFKxarTHaTEDZqC+dvwbk6TKKnS8366tsjAAM8=; b=S85PMxsJawEakzJG48v55pb5a/b3Q149i7Ng28PGulq8ddCHuPefj900OR2c+YO3aS 3klDWyT/G23B37Zk19/u1F/5w1y+tyK+Wlw2qTCK6hNux9OOQEG29JOe+iyVDiVIvkFM cQuxOfF+45NQPSPS3nkB0vYMkc6UOeDwibrOmVe+VBx7avZxuE/qv7MLkevv0vvQvlAv kQsFRkdhiBMbb4t2EFllD4/AnpYIM0TASBa08TZlimJdkxTzMg3Qt5mso3sHzK0Xwufd J8DbuwYT3cjCaCIGZ7/MNlaIGPhdDoChit8d0dJRSNHIko8FX+i/kmLl+hyu8s3bjl9n C75w== X-Received: by 10.140.235.16 with SMTP id g16mr4648513qhc.55.1430400831364; Thu, 30 Apr 2015 06:33:51 -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 a82sm1193186qka.0.2015.04.30.06.33.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 30 Apr 2015 06:33:50 -0700 (PDT) From: Dave Garrett To: Stephen Farrell Date: Thu, 30 Apr 2015 09:33:49 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504292035.21721.davemgarrett@gmail.com> <5541E286.2090001@cs.tcd.ie> In-Reply-To: <5541E286.2090001@cs.tcd.ie> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201504300933.49582.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org 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: Thu, 30 Apr 2015 13:33:54 -0000 Thanks. Note that while I am asking about policy, in that I think having HTTPS used for all IETF servers by default is a good idea, that is not the primary issue I'm bringing up here. At the moment, I'd just like the URLs updated to use HTTPS for what already supports it. As to the normative & informative references, the I-D uses relative URLs and the Editor's Copy uses absolute HTTP URLs, which is what seems to cause the inconsistency of not using the same scheme when loading the pages over HTTPS. The Editor's Copy could use double-slash relative URLs to get the same effect, at minimum. Just using HTTPS links for everything would be simpler, though. Dave On Thursday, April 30, 2015 04:06:30 am 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. > > On 30/04/15 01:35, Dave Garrett wrote: > > https://tlswg.github.io/tls13-spec/ > > https://tools.ietf.org/html/draft-ietf-tls-tls13-05 > > > > Where does the "Status of This Memo" and "Copyright Notice" text get pulled from? There seems to be some black magic involved in the build process, and I don't see where that text lives. I'd like to request the two URLs be updated, but I don't know where to ask. > > > > status has: > > http://datatracker.ietf.org/drafts/current/ > > which redirects to: > > http://datatracker.ietf.org/doc/active/ > > which does support TLS, and should be: > > https://datatracker.ietf.org/doc/active/ > > > > copyright has: > > http://trustee.ietf.org/license-info > > which redirects to: > > http://trustee.ietf.org/trust-legal-provisions.html > > which does support TLS, and should be: > > https://trustee.ietf.org/trust-legal-provisions.html > > the initial URL also supports TLS, so this works: > > https://trustee.ietf.org/license-info > > however that redirects to HTTP, not HTTPS (...sigh) > > > > So, yeah... I'd like the new TLS spec to actually attempt to use TLS in its URLs, where possible. To do this needs: > > 1) Update those two URLs in the template for these sections to use the HTTPS equivalent (in the case of "status", also change "current" to "active"). > > 2) Get someone to fix the redirects on trustee.ietf.org to redirect to HTTPS, at minimum when already coming from HTTPS. > > > > Actually using TLS by default might also be a plan... > > > > As to other URLs in the document, I added a couple 's'es in my minor fixes branch/PR. There are additional domains that do support HTTPS, technically, but they get cert errors... because of course they do. > > > > The RFC references have an odd inconsistency here. In the numbered working group drafts, they properly generate with HTTPS links: > > https://tools.ietf.org/html/draft-ietf-tls-tls13-05#section-13.1 > > However, in the editor's copy (draft-ietf-tls-tls13-latest), they generate with HTTP links: > > https://tlswg.github.io/tls13-spec/#rfc.references.1 > > > > That needs fixing if just for consistency. > > > > Also, tools.ietf.org should of course be using HTTPS by default, but it's not. > > > > > > Dave > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Apr 30 06:38: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 9B6F01A92B1 for ; Thu, 30 Apr 2015 06:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] 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 R3pspYRxTWdJ for ; Thu, 30 Apr 2015 06:38:09 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (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 5BE051A9131 for ; Thu, 30 Apr 2015 06:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1430401086; l=3189; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=1TP2rJkwCZPlvdHJYx56MvCNSFyI0BOR54TNEBkmggE=; b=Aca0TiNZlS4EUL9338+QzjoT6DL36cGNhNyQCcb2fBqPxn8sN8Lk7qpUukvllzEi9Wp c9ufdeMsXp74Tw4ziYuxnZ1g+6akzvjsDzU29ScCuxHoWEg2Kq5N4Ib3ddHeW9OjQaoxB jXMQadP2rVEqpgRCsdG1ho/XPyOkZBj0mGI= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyH+N7khuG2X0VPtfp0A2vnA8nurA== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:607a:32b3:447b:12c3] ([2001:4dd0:ff67:0:607a:32b3:447b:12c3]) by smtp.strato.de (RZmta 37.5 AUTH) with ESMTPSA id V06074r3UDc36hS (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 30 Apr 2015 15:38:03 +0200 (CEST) Message-ID: <5542303D.2080604@zinks.de> Date: Thu, 30 Apr 2015 15:38:05 +0200 From: Roland Zink User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <201504292035.21721.davemgarrett@gmail.com> <5541E286.2090001@cs.tcd.ie> In-Reply-To: <5541E286.2090001@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Thu, 30 Apr 2015 13:38:11 -0000 Hi Stephen, does this mean that in order to implement TLS (read the specification) you need to use TLS (know how it is working)? Is it possible to let the client decide and offer alternate services when the client does not use https? Regards, Roland 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. > > On 30/04/15 01:35, Dave Garrett wrote: >> https://tlswg.github.io/tls13-spec/ >> https://tools.ietf.org/html/draft-ietf-tls-tls13-05 >> >> Where does the "Status of This Memo" and "Copyright Notice" text get pulled from? There seems to be some black magic involved in the build process, and I don't see where that text lives. I'd like to request the two URLs be updated, but I don't know where to ask. >> >> status has: >> http://datatracker.ietf.org/drafts/current/ >> which redirects to: >> http://datatracker.ietf.org/doc/active/ >> which does support TLS, and should be: >> https://datatracker.ietf.org/doc/active/ >> >> copyright has: >> http://trustee.ietf.org/license-info >> which redirects to: >> http://trustee.ietf.org/trust-legal-provisions.html >> which does support TLS, and should be: >> https://trustee.ietf.org/trust-legal-provisions.html >> the initial URL also supports TLS, so this works: >> https://trustee.ietf.org/license-info >> however that redirects to HTTP, not HTTPS (...sigh) >> >> So, yeah... I'd like the new TLS spec to actually attempt to use TLS in its URLs, where possible. To do this needs: >> 1) Update those two URLs in the template for these sections to use the HTTPS equivalent (in the case of "status", also change "current" to "active"). >> 2) Get someone to fix the redirects on trustee.ietf.org to redirect to HTTPS, at minimum when already coming from HTTPS. >> >> Actually using TLS by default might also be a plan... >> >> As to other URLs in the document, I added a couple 's'es in my minor fixes branch/PR. There are additional domains that do support HTTPS, technically, but they get cert errors... because of course they do. >> >> The RFC references have an odd inconsistency here. In the numbered working group drafts, they properly generate with HTTPS links: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-05#section-13.1 >> However, in the editor's copy (draft-ietf-tls-tls13-latest), they generate with HTTP links: >> https://tlswg.github.io/tls13-spec/#rfc.references.1 >> >> That needs fixing if just for consistency. >> >> Also, tools.ietf.org should of course be using HTTPS by default, but it's not. >> >> >> Dave >> >> _______________________________________________ >> 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 Thu Apr 30 06:50: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 F38B21B2A89 for ; Thu, 30 Apr 2015 06:50:11 -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 IzykAU1MQ9Cl for ; Thu, 30 Apr 2015 06:50:06 -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 31DEB1B2A86 for ; Thu, 30 Apr 2015 06:50:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6EAD6BE64; Thu, 30 Apr 2015 14:50:04 +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 nhFVHCTCo3F8; Thu, 30 Apr 2015 14:50:02 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.22]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 82357BE53; Thu, 30 Apr 2015 14:50:02 +0100 (IST) Message-ID: <5542330A.3060605@cs.tcd.ie> Date: Thu, 30 Apr 2015 14:50:02 +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: Roland Zink , tls@ietf.org References: <201504292035.21721.davemgarrett@gmail.com> <5541E286.2090001@cs.tcd.ie> <5542303D.2080604@zinks.de> In-Reply-To: <5542303D.2080604@zinks.de> 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: Thu, 30 Apr 2015 13:50:13 -0000 Hiya, On 30/04/15 14:38, Roland Zink wrote: > Hi Stephen, > > does this mean Well, no there is no "this" that means anything yet:-) Like I said, I'll bring it to the IESG and bring any conclusions back (probably not to this list but somewhere more appropriate though I'll send a pointer here so those who care can follow up.) > that in order to implement TLS (read the specification) > you need to use TLS (know how it is working)? No. For RFCs and I-Ds there are many mirrors and we just finished a discussion on the main IETF list (about ftp) where I think it was clear that we have a bunch of folks who want things available in cleartext even if the defaults become to access things via TLS. (There wasn't a consensus call on exactly that though, so that's just my synopsis.) > Is it possible to let the > client decide and offer alternate services when the client does not use > https? It is quite possible. I'd even not be surprised if the outcome were to default to https URIs but to ensure http equivalents are available. But the main thing is that nobody ought get scared that we'll make some mad change without chatting with the community about that first. We (the IESG) know exactly how badly beaten up we'd deserve to be if we did that. Cheers, S. > > Regards, > Roland > > > 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. >> >> On 30/04/15 01:35, Dave Garrett wrote: >>> https://tlswg.github.io/tls13-spec/ >>> https://tools.ietf.org/html/draft-ietf-tls-tls13-05 >>> >>> Where does the "Status of This Memo" and "Copyright Notice" text get >>> pulled from? There seems to be some black magic involved in the build >>> process, and I don't see where that text lives. I'd like to request >>> the two URLs be updated, but I don't know where to ask. >>> >>> status has: >>> http://datatracker.ietf.org/drafts/current/ >>> which redirects to: >>> http://datatracker.ietf.org/doc/active/ >>> which does support TLS, and should be: >>> https://datatracker.ietf.org/doc/active/ >>> >>> copyright has: >>> http://trustee.ietf.org/license-info >>> which redirects to: >>> http://trustee.ietf.org/trust-legal-provisions.html >>> which does support TLS, and should be: >>> https://trustee.ietf.org/trust-legal-provisions.html >>> the initial URL also supports TLS, so this works: >>> https://trustee.ietf.org/license-info >>> however that redirects to HTTP, not HTTPS (...sigh) >>> >>> So, yeah... I'd like the new TLS spec to actually attempt to use TLS >>> in its URLs, where possible. To do this needs: >>> 1) Update those two URLs in the template for these sections to use >>> the HTTPS equivalent (in the case of "status", also change "current" >>> to "active"). >>> 2) Get someone to fix the redirects on trustee.ietf.org to redirect >>> to HTTPS, at minimum when already coming from HTTPS. >>> >>> Actually using TLS by default might also be a plan... >>> >>> As to other URLs in the document, I added a couple 's'es in my minor >>> fixes branch/PR. There are additional domains that do support HTTPS, >>> technically, but they get cert errors... because of course they do. >>> >>> The RFC references have an odd inconsistency here. In the numbered >>> working group drafts, they properly generate with HTTPS links: >>> https://tools.ietf.org/html/draft-ietf-tls-tls13-05#section-13.1 >>> However, in the editor's copy (draft-ietf-tls-tls13-latest), they >>> generate with HTTP links: >>> https://tlswg.github.io/tls13-spec/#rfc.references.1 >>> >>> That needs fixing if just for consistency. >>> >>> Also, tools.ietf.org should of course be using HTTPS by default, but >>> it's not. >>> >>> >>> Dave >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Thu Apr 30 07:54: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 9CF331A9144 for ; Thu, 30 Apr 2015 07:54:24 -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 CL7ZKspeCbn1 for ; Thu, 30 Apr 2015 07:54:23 -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 623061B29F9 for ; Thu, 30 Apr 2015 07:54:23 -0700 (PDT) Received: by qcbii10 with SMTP id ii10so30114475qcb.2 for ; Thu, 30 Apr 2015 07:54:22 -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=a2BD4Y9E2yhCLapFJgQLcob8e0KWWOyLzRXo6gyX+v4=; b=v7p6FWuq0orqTR/mFDkcZo1K+ttTjtT0G8SMLMlSt0G/yHGtklFRHVqcpirCIvYnEC zutwkMqTh7Jpp6eS3/N1DvxSXldcp9z/97dj5eMuM3h2GgdeuqHSJi6aoAhowHQlNO1w GoF9gmlGF7lsDQHmTM0hrCW1JWtHLuwUkstlqId/6mDLNWSy2T7lyBoEP8C+kkSWSdWo MwmuhpL7ypyz8WDCFvFoXs/ZodS7PdT/uqEV0v/vnwoSx5Tloi/HY16WwCR/x3oXspjJ 2Q/2rybiXeZkKH6s4NE4a+xEt2hD1X+loTbI6UGEEPxk3bFX4bh2LRtM7O2Lu37IFuou jzYg== X-Received: by 10.55.21.221 with SMTP id 90mr8093238qkv.44.1430405662752; Thu, 30 Apr 2015 07:54:22 -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 t32sm1303470qgd.21.2015.04.30.07.54.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 30 Apr 2015 07:54:22 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Stephen Farrell Date: Thu, 30 Apr 2015 10:54:20 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; ) References: <201504292035.21721.davemgarrett@gmail.com> <5542303D.2080604@zinks.de> <5542330A.3060605@cs.tcd.ie> In-Reply-To: <5542330A.3060605@cs.tcd.ie> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201504301054.21169.davemgarrett@gmail.com> 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: Thu, 30 Apr 2015 14:54:24 -0000 On Thursday, April 30, 2015 09:50:02 am Stephen Farrell wrote: > For RFCs and I-Ds there are many mirrors and we just finished a > discussion on the main IETF list (about ftp) where I think it was > clear that we have a bunch of folks who want things available in > cleartext even if the defaults become to access things via TLS. > (There wasn't a consensus call on exactly that though, so that's > just my synopsis.) That sounds like it would be a reasonable consensus, IMO. HTTPS by default everywhere is a good thing, but I agree that the IETF should probably have all documents also available in cleartext somewhere too. (preferably with hashes that can be verified via some secure channel) Dave From nobody Thu Apr 30 07:57: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 F3F581A6EDA for ; Thu, 30 Apr 2015 07:57:23 -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 7FTuX1qoLU_L for ; Thu, 30 Apr 2015 07:57:21 -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 62E7C1A1BB8 for ; Thu, 30 Apr 2015 07:57:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 11667BE64; Thu, 30 Apr 2015 15:57:16 +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 i6PqmO_nDRwk; Thu, 30 Apr 2015 15:57:14 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.30.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B8AA0BE59; Thu, 30 Apr 2015 15:57:14 +0100 (IST) Message-ID: <554242CA.6030004@cs.tcd.ie> Date: Thu, 30 Apr 2015 15:57:14 +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: Dave Garrett , tls@ietf.org References: <201504292035.21721.davemgarrett@gmail.com> <5542303D.2080604@zinks.de> <5542330A.3060605@cs.tcd.ie> <201504301054.21169.davemgarrett@gmail.com> In-Reply-To: <201504301054.21169.davemgarrett@gmail.com> 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: Thu, 30 Apr 2015 14:57:24 -0000 On 30/04/15 15:54, Dave Garrett wrote: > preferably with hashes that can be verified via some secure channel See [1] and mostly thank Russ Housley if you like that:-) S. [1] https://www.ietf.org/id-info/idsignatures.html