Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
Eric Rescorla <ekr@rtfm.com> Tue, 12 July 2016 21:21 UTC
Return-Path: <ekr@rtfm.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 23A7212D947 for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 14:21:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf6GEwD7lhqL for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 14:21:15 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858F512D969 for <tls@ietf.org>; Tue, 12 Jul 2016 14:21:01 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id j17so26168980ywg.0 for <tls@ietf.org>; Tue, 12 Jul 2016 14:21:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2xM1DsNvl0VfJXRZ6nfg2QFr2PWA1UBxoIfNhu08c8o=; b=qtkRO1Feh0jwuQhJfzakKJwbhBfinwQ6zxrzewKsGiDp7ndGvwodFGrchpD7DuUIY4 s8G5Bt72IEjkj587+yZ9ru3uIoHGFCQVkCrM4l1oIA4cTka2KsvpCHZP/sK3eziIdj+t lQ6LIPiSmFPNXICJOhTqaf4WhSDw5h4LXROwINoahGdL1icYG0qwxCPMrufKaKExPGzo PZYAsKvOZvcemaGwKW/Hgxio6NVxXcbKcVFkmKroL3zfikftQND2fYrJ//H32xe4x9sh ILBSImxJ1mMBzcx23awiXifBymL9qeamXJlL3jUPw7XsqqBCbNh6Dz1kbvBLf5IlkIRb 8Dnw==
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; bh=2xM1DsNvl0VfJXRZ6nfg2QFr2PWA1UBxoIfNhu08c8o=; b=gvKvuj+D/h8duebWjV67pdpZy2KFziPU0y5Zj53giXnsNTJM9BdOabZnFNLeaQVItJ 5NRoKrzvFA01crhOYHko2SJeJHtm6MJ5jDLXDSytnk67bY8cmE1An7z6T1BW4UFQ1lgw YkJ405/gthaET581N+PD7TpQZUqpOM7T08r9h9ItC2W5PqHyM8qtMUWB9T2+5ysG+iwN 4f4/lyffYpfyBvHZIjqWsV1lOT6R/TJZKBx7Bw/gTZsCrgk8nTovp8uB1wqKBmaMWa+r iuSPlonv8Ia3BgfZh/LSWPILm76+PH2A2i6qUudyxaU4Zrog6aDVMBK+RLjY2u2wNSJX FeYw==
X-Gm-Message-State: ALyK8tJeB10E3HR5BPUanVoa4P3Js8y+MsRLwsHE3GRbt6MU6Xamqo4NSyL8MINAkRGU4Rr6yzh7Q15FkHK+Lw==
X-Received: by 10.37.80.141 with SMTP id e135mr3096982ybb.162.1468358460773; Tue, 12 Jul 2016 14:21:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.152.13 with HTTP; Tue, 12 Jul 2016 14:20:21 -0700 (PDT)
In-Reply-To: <57855399.70201@akamai.com>
References: <CABcZeBMiLmwBeuLt=v4qdcJwe5rdsK_9R4-2TUXYC=sttmwH-g@mail.gmail.com> <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <57855399.70201@akamai.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 12 Jul 2016 14:20:21 -0700
Message-ID: <CABcZeBPZf32EQMYqhC+Pu4gd_1kAiu7ijmTbHfj5KCjp3wfwBQ@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Content-Type: multipart/alternative; boundary="001a1141308c754cc0053776d840"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0NK7-S28g7rAbHisz2GZmHzQdsA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 12 Jul 2016 21:21:18 -0000
On Tue, Jul 12, 2016 at 1:31 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote: > On 07/11/2016 11:16 PM, Ilari Liusvaara wrote: > > On Mon, Jul 11, 2016 at 12:08:00PM -0700, Eric Rescorla wrote: > >> Folks, > >> > >> I've just submitted draft-ietf-tls-tls13-14.txt and it should > >> show up on the draft repository shortly. In the meantime you > >> can find the editor's copy in the usual location at: > >> As usual, comments welcome. > >> -Ekr > > Did a readthrough, here's a bunch of comments (didn't check the > > issues list): > > Should we bulk-open issues for these so they don't get lost? I will > only cherry-pick a couple to reply to. > I opened one giant issue because I haven't gone through this yet If you want to open individual issues that you think are meritorious that woul dbe fine -Ekr > > > ----------------------------------------------------------------------- > > > >> ### Server Hello > >> > >> cipher_suite > >> : The single cipher suite selected by the server from the list in > >> ClientHello.cipher_suites. For resumed sessions, this field is > >> the value from the state of the session being resumed. > >> [[TODO: interaction with PSK.]] > > Isn't this the true ciphersuite used on this connection, "resumption" > > or not? Otherwise you can get into all sorts of crazy situations that > > WILL be sources of implementation bugs. > > It probably ought to be, yes. > > > The idea that it isn't true ciphersuite brings me bad flashbacks about > > TLS 1.2 ticket "maybe resume" craziness (except this would be even > > worse). > > I feel like we had discussed what the resumption ciphersuite should be > previously, but I don't seem to be able to find it in my mail archives. > > > > >> ### Negotiated Groups > >> > >> As of TLS 1.3, servers are permitted to send the "supported_groups" > >> extension to the client. If the server has a group it prefers to the > >> ones in the "key_share" extension but is still willing to accept the > >> ClientHello, it SHOULD send "supported_groups" to update the client's > >> view of its preferences. Clients MUST NOT act upon any information > >> found in "supported_groups" prior to successful completion of the > >> handshake, but MAY use the information learned from a successfully > >> completed handshake to change what groups they offer to a server in > >> subsequent connections. > > Are those supposed to be filtered to be subset of ones client advertised > > or not? E.g. if client didn't indicate support for x448, can the server > > still send x448? > > Requiring filtering would prevent the client from learning when the > server supports new schemes, but having the server not filter would > likely end up with the server "always" sending a big pile of stuff even > if the client has no idea that those schemes even exist. So, on the > balance, I would go with filtering. > > > > > > >> [[TODO: Recommendation about what the client offers. > >> Presumably which integer DH groups and which curves.]] > > Bit crazy algorithm: If you haven't heard of this server before, > > pick smallest you support, if you have, pick the one it selected > > the last time. > > It does make it clear that things are only as secure as the weakest > algorithm they will accept ... but stateless clients will also always > get that weakest link. (Okay, "smallest" does not necessarily equal > "weakest", but still.) With guidance on not supporting silly things, > this algorithm does not seem too crazy... > > > > >> ### Early Data Indication > >> > >> obfuscated_ticket_age > >> : The time since the client learned about the server configuration that > it is > >> using, in milliseconds. This value is added modulo 2^32 to with the > >> "ticket_age_add" value that was included with the ticket, see > >> {{NewSessionTicket}}. This addition prevents passive observers from > >> correlating sessions unless tickets are reused. Note: because ticket > >> lifetimes are restricted to a week, 32 bits is enough to represent any > >> plausible age, even in milliseconds. > > > > And the addition also prevents correlating session with its parent, > > even in case of reuse (this was the reason for switching to addition > > from XOR). > > > >> A server MUST validate that the ticket_age is within a small > >> tolerance of the time since the ticket was issued (see {{replay-time}}). > > Good luck with that... > > It would be good to not repeat the mistake that is the 5-minute replay > window in Kerberos. (So, shall we make "small tolerance" a concrete > value or otherwise give guidance? 5 seconds? 4xRTT? other? > But, IIRC, this check does not require absolute time agreement between > peers, only that their clocks advance at a similar rate. If your clock > steps because you slept your laptop and you have to fall back to a full > handshake, oh well. > > > Also, requirement that the server MUST proceed with the handshake and > > reject 0-RTT if that validation fails would be good here... > > Definitely. > > > Oh, still trial decryption... Got it. > > I had managed to previously forget how we ended up deciding on trial > decryption, but it basically was dkg commenting in the room at Buenos > Aires "are we writing a security protocol or a protocol that is > convenient to implement?" [with respect to the privacy/leakage from > having the alert or other signal be unencrypted]. > > > > >> #### Replay Properties {#replay-time} > >> > >> There are several potential sources of error that make an exact > >> measurement of time difficult. Variations in client and server clocks > >> are likely to be minimal, outside of gross time corrections. Network > >> propagation delays are most likely causes of a mismatch in legitimate > >> values for elapsed time. Both the NewSessionTicket and ClientHello > >> messages might be retransmitted and therefore delayed, which might be > >> hidden by TCP. > > I don't think variations in clocks are minimal... > > Just to check: you mean the rate at which clocks advance, and not the > absolute number reported as the time? > > > I wonder what 95% timeskew interval per day is... > > > > (Oh, and have fun with leap seconds!) > > It only matters how big the skew is relative to the acceptance window > and how long the ticket is valid for. Which brings us back to what the > acceptance window is measured in... > > >> ### Encrypted Extensions > >> > >> The same extension types MUST NOT appear in both the ServerHello and > >> EncryptedExtensions. If the same extension appears in both locations, > >> the client MUST rely only on the value in the EncryptedExtensions > >> block. All server-sent extensions other than those explicitly listed > >> in {{server-hello}} or designated in the IANA registry MUST only > >> appear in EncryptedExtensions. Extensions which are designated to > >> appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients > >> MUST check EncryptedExtensions for the presence of any forbidden > >> extensions and if any are found MUST terminate the handshake with an > >> "illegal_parameter" alert. > > This seems inconsistent. In implementation, I would write explicit > disjoint > > whitelists of extensions for both (and non-whitelisted one is a fatal > > error). Explicit whitelisting is safe even on client side, since the > > extensions are bounded by client-supported ones. > > You would have an explicit whitelist of all (including encrypted) > extensions for the server, so that it chokes when a client starts > sending a new one? Or just that it would not be considered for further > processing [and potential inclusion in ServerHello]? > > > > >> ## Random Number Generation and Seeding > >> > >> To estimate the amount of seed material being produced, add the number > of bits > >> of unpredictable information in each seed byte. For example, keystroke > timing > >> values taken from a PC compatible 18.2 Hz timer provide 1 or 2 secure > bits > >> each, even though the total size of the counter value is 16 bits or > more. > >> Seeding a 128-bit PRNG would thus require approximately 100 such timer > values. > > This seems really obsolete. The timers have not been 18.2Hz for years, > and > > applications running on operating systems damn better use OS services for > > random numbers, given that anything else is fraught with peril. > > > > Sadly, there is a vocal minority of software implementors that insist > that the OS service is too slow and write their own. But I agree this > section needs some work; I may be able to contribute some text. > > > > >> # Overview of Security Properties {#security-analysis} > >> > >> [[TODO: This section is still a WIP and needs a bunch more work.]] > >> > >> A complete security analysis of TLS is outside the scope of this > document. > >> In this section, we provide an informal description the desired > properties > >> as well as references to more detailed work in the research literature > >> which provides more formal definitions. > >> > >> We cover properties of the handshake separately from those of the > record layer. > > I think properties of the exporter should be covered as well: > > I agree (but am unlikely to be able to contribute text). > > -Ben > > > - Is it intended to generate secret data (yes) > > - Is it intended to generate connection-unique data (yes) > > - Are values for different labels/contexts intended to be computationally > > independent (yes) > > > > > > (The TLS 1.2 exporter without EMS failed the middle requirement, > > creating security issues in applications that assumed the data was > > connection-unique. > > > > > >
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Peter Gutmann
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Watson Ladd
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Hubert Kario
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Benjamin Kaduk
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Eric Rescorla
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Benjamin Kaduk
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Scott Fluhrer (sfluhrer)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Scott Fluhrer (sfluhrer)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- [TLS] New draft: draft-ietf-tls-tls13-14.txt Eric Rescorla
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dave Garrett
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny