Re: [TLS] 32 byte randoms in TLS1.3 hello's
Dan Brown <danibrown@blackberry.com> Mon, 24 July 2017 16:40 UTC
Return-Path: <danibrown@blackberry.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D75F129AC4 for <tls@ietfa.amsl.com>; Mon, 24 Jul 2017 09:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5puJjAWZR6PX for <tls@ietfa.amsl.com>; Mon, 24 Jul 2017 09:40:28 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAD8129ADD for <tls@ietf.org>; Mon, 24 Jul 2017 09:40:27 -0700 (PDT)
Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs212cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jul 2017 12:40:25 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0319.002; Mon, 24 Jul 2017 12:40:25 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI+yUHLG+hMivEObnVpzx6wh/KJjLfkf
Date: Mon, 24 Jul 2017 16:40:24 +0000
Message-ID: <20170724164022.8573013.93422.16108@blackberry.com>
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
In-Reply-To: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/56N_-KDN0LuWyEvAhmFnm7g8p6A>
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jul 2017 16:40:30 -0000
Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, given that ephemeral DH is mandated, if anybody has the time/patience. (* ok, not that I truly ever knew). I assume that the risk of misusing the nonces, to exfiltrate keys etc, is small enough compared to other side channels to justify their added value. Original Message From: Stephen Farrell Sent: Monday, July 24, 2017 11:15 AM To: tls@ietf.org Subject: [TLS] 32 byte randoms in TLS1.3 hello's Hiya, I'm guessing many folks interested in TLS may have been at the QUIC session in Prague and hence missed out on the excellent talk by Stephen Checkoway on the juniper dual-ec incident. (I highly recommend taking a peek at the slides [1] or reading the paper [2] or watching the video wherever that may be;-). Anyway, in TLS1.3 we've gotten rid of the gmt time option in the client and server hello, which is good, (and I do recall that discussion) but we've also changed from: // RFC5246 struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random; to: // tls1.3 -21 opaque Random[32]; Now if some TLS1.3 deployment were affected by a dual-ec attack, it'd seem like the -21 version of Random might be even better than the TLS1.2 version, for the attacker. I tried to see where that 28->32 change came from but didn't find it (apologies if I missed that). I guess it just ensures that the overall length of the struct is the same. So, a question and a possible suggestion: Q: Why do we need 32 bytes of Random? Suggestion: if we don't need that much, maybe we could change the length there, (I can see that might trigger bugs and middlebox issues) or encourage/require folks to mask out some of those bits (e.g. with zeros or some catchy hex encoded message about dual-ec:-). Cheers, S. [1] https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf [2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf
- [TLS] 32 byte randoms in TLS1.3 hello's Stephen Farrell
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Watson Ladd
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Dan Brown
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Ilari Liusvaara
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Russ Housley
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Colm MacCárthaigh
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Colm MacCárthaigh
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Dan Brown
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Peter Gutmann
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Stephen Farrell
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Joseph Lorenzo Hall
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Christian Huitema
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Peter Gutmann
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Christian Huitema
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Watson Ladd
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Peter Gutmann
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Martin Rex
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Colm MacCárthaigh
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Jeffrey Walton
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Martin Rex
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Colm MacCárthaigh
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Martin Rex
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Watson Ladd
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Colm MacCárthaigh
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Stephen Farrell
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Eric Rescorla
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Dan Brown
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Eric Rescorla
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Stephen Farrell
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Dan Brown
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Ilari Liusvaara
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Dan Brown
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Stephen Farrell
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Salz, Rich
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Ilari Liusvaara
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Dan Brown
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Colm MacCárthaigh
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Dan Brown
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Colm MacCárthaigh
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Dan Brown
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] 32 byte randoms in TLS1.3 hello's Stephen Farrell