IETF Logo Mail Archive

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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 31 July 2017 15:24 UTC

Return-Path: <prvs=938588fa2c=uri@ll.mit.edu>
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 5534413252B for <tls@ietfa.amsl.com>; Mon, 31 Jul 2017 08:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 TTeqnBmPvmqc for <tls@ietfa.amsl.com>; Mon, 31 Jul 2017 08:24:14 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 92E54132515 for <tls@ietf.org>; Mon, 31 Jul 2017 08:24:13 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6VFO6K8008431; Mon, 31 Jul 2017 11:24:06 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Dan Brown <danibrown@blackberry.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Eric Rescorla <ekr@rtfm.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] 32 byte randoms in TLS1.3 hello's
Thread-Index: AQHTBI/QFdXms6d7jEaZNtjFKD2eRqJjeSwAgAC0BYCAAI15AIAAcHmAgABSRwCAABeRgIAAta2AgAATyICAAC25AIAAMDsAgAANUgCAABPRAIAABQKAgAAkyYCAAYN3AIAAELAAgAACowCAAAIWAIAAleMAgABRLoCAACSpAIAElxGA///V+oA=
Date: Mon, 31 Jul 2017 15:24:05 +0000
Message-ID: <C61414C9-D620-46A5-8990-9964E7B273C1@ll.mit.edu>
References: <CAAF6GDcSb3jqirTRW7_Udr4u6QJtFpmFug02pMuX-CjEiyNPfg@mail.gmail.com> <20170726205732.784F41A6CB@ld9781.wdf.sap.corp> <CAAF6GDcQCCeq1JosMTpQrh7MZLG1iN-xcOfsXC0LvSZRx+oQjQ@mail.gmail.com> <046ad800-351b-3a79-3f56-7883f5d9ceea@cs.tcd.ie> <CABcZeBMyY0f9D9VEmkKNkLB2OY3TRG7UO-B48xOrA3JSP5xRkw@mail.gmail.com> <20170727233335.8573013.91860.16216@blackberry.com> <2DB2CA47-5121-4B3E-BE0E-116A76F4870E@ll.mit.edu> <CABcZeBNF3WjY6AKoDY4drB+XjMS9LLZ5DmhR=DFX+-0YtKO71g@mail.gmail.com> <726e6666-8af4-384a-95f7-45cb68a331f7@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B745D8@XMB116CNC.rim.net> <0698b5f7-3dd7-ee4f-5464-6a7e98a20240@cs.tcd.ie> <810C31990B57ED40B2062BA10D43FBF501B78355@XMB116CNC.rim.net>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B78355@XMB116CNC.rim.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.24.1.170721
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3584345045_1457748084"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310261
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qUTrk5W37THCuOBqOp872JFTCck>
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, 31 Jul 2017 15:24:18 -0000

       My guess is many TLS implementations don't have visibility into how the CSPRNG operates.
       That code does however, know which output values will be public and which not. For me, that
       implies that any good separation scheme applied within the TLS code that differentiates
       between public and non public outputs is a good plan. 

Hasn’t this been the whole point of the discussion?! The proposal to separate PRNGs into those that supply publicly-visible randomness (nonces, etc), and those that supply “secret” randomness (keying material and such)? Thus, having *two* PRNGs, each (hopefully) properly seeded?

I’m glad you’re now agreeing that the above is a good plan.

v2.23.0 | Report a Bug | By Email