IETF Logo Mail Archive

Re: [TLS] 32 byte randoms in TLS1.3 hello's

Christian Huitema <huitema@huitema.net> Wed, 26 July 2017 01:21 UTC

Return-Path: <huitema@huitema.net>
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 86ECA131ECE for <tls@ietfa.amsl.com>; Tue, 25 Jul 2017 18:21:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LEYX7Eg3oesZ for <tls@ietfa.amsl.com>; Tue, 25 Jul 2017 18:21:42 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 C6695124B0A for <tls@ietf.org>; Tue, 25 Jul 2017 18:21:42 -0700 (PDT)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1daB1B-000406-9D for tls@ietf.org; Wed, 26 Jul 2017 03:21:42 +0200
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1daB19-0007HP-PU for tls@ietf.org; Tue, 25 Jul 2017 21:21:40 -0400
Received: (qmail 11939 invoked from network); 26 Jul 2017 01:21:39 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.66]) (envelope-sender <huitema@huitema.net>) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 26 Jul 2017 01:21:38 -0000
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "tls@ietf.org" <tls@ietf.org>
References: <67679ecc-1043-a70a-6d57-8807f78e1afa@cs.tcd.ie> <CAAF6GDejyu7+ApbG-drMOSW3M=nc1MJJeA45O40RDbEedk15kA@mail.gmail.com> <1500954833319.1033@cs.auckland.ac.nz> <f328d15e-6eed-e257-5cc3-51e9af2f4bfe@cs.tcd.ie> <2467f973-392a-f579-8b2f-e7cc5332fc49@huitema.net> <1501027031926.45701@cs.auckland.ac.nz>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <d1092f04-444d-57fd-ae68-d3ca1998a34b@huitema.net>
Date: Tue, 25 Jul 2017 18:21:37 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1501027031926.45701@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="------------D18CDEDE89054A2EE85A8166"
X-Originating-IP: 168.144.250.223
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.22)
X-Recommended-Action: accept
X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbFuHJrd6q7ImwszS9kW0E9ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23qYF5SOz/jkeylAndJeBcYkNu6nlvxXcLqtzf A/BCZeU9UcoRT1aqEQHi9PYSv8V2YOEkjsX7F8KmpUaZQHV+Sf+k51CV8HOoCp+bWB2rXxO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpGhWDl86FRLsucalajANCRP6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyeEeE8v7xjAF2H09SsIttNbeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17qTMtQxOaK6fM/m9QpOzdoC2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe93qlFit1PvkPF7Ua1AOSWcb0i13zjCiwPgdt77s k1WBMw==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/u-LpGt6PLscPY7DAYzjsi5-ZuXg>
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: Wed, 26 Jul 2017 01:21:44 -0000


On 7/25/2017 4:57 PM, Peter Gutmann wrote:
>> Also, when we make such a recommendation in the TLS spec, we can hope that it
>> will be heeded by the TLS developers, but what about the developers of
>> applications and protocols sitting on top of TLS, such DTLS, QUIC or HTTP?
> They don't need to know or care about this, it's being used to generate the
> TLS nonce which is invisible to anything running over TLS.
>
> Are we talking about the same thing here?

Not sure. I am looking at the implementations of QUIC. QUIC needs its
own set of random numbers for things like connection ID or initial
sequence number. The most natural thing to do is do get them from the OS
API, /dev/random or cryptogenrandom(), but that requires platform
specific code. The next natural thing to do is to reuse the random
number generator configured for the TLS context, because it is not OS
dependent. If that is not OK, then developers will need lots of explaining.

-- 
Christian Huitema

v2.23.0 | Report a Bug | By Email