Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 13 April 2015 18:12 UTC
Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
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 <tls@ietfa.amsl.com>; 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 <tls@ietfa.amsl.com>; 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 <tls@ietf.org>; 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 <ilari.liusvaara@elisanet.fi>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20150413181144.GA720@LK-Perkele-VII>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <20150412165542.GA19481@LK-Perkele-VII> <CABkgnnUr4wYkVwBGvH0MSmBnzNBd+T1s4aZJ5OvT_Gw3UyMSjQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABkgnnUr4wYkVwBGvH0MSmBnzNBd+T1s4aZJ5OvT_Gw3UyMSjQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/VMEIepwLxkKpp2-F9gkINQOY7bI>
Cc: "tls@ietf.org" <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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 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 <ilari.liusvaara@elisanet.fi> 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
- [TLS] 0-RTT and Anti-Replay Eric Rescorla
- Re: [TLS] 0-RTT and Anti-Replay Mohamad Badra
- Re: [TLS] 0-RTT and Anti-Replay Eric Rescorla
- Re: [TLS] 0-RTT and Anti-Replay Stephen Checkoway
- Re: [TLS] 0-RTT and Anti-Replay Daniel Kahn Gillmor
- Re: [TLS] 0-RTT and Anti-Replay Andrey Jivsov
- Re: [TLS] 0-RTT and Anti-Replay Eric Rescorla
- Re: [TLS] 0-RTT and Anti-Replay Martin Thomson
- Re: [TLS] 0-RTT and Anti-Replay Andrey Jivsov
- Re: [TLS] 0-RTT and Anti-Replay Colm MacCárthaigh
- Re: [TLS] 0-RTT and Anti-Replay Colm MacCárthaigh
- Re: [TLS] 0-RTT and Anti-Replay Nico Williams
- Re: [TLS] 0-RTT and Anti-Replay Ilari Liusvaara
- Re: [TLS] 0-RTT and Anti-Replay Nico Williams
- Re: [TLS] 0-RTT and Anti-Replay Nico Williams
- Re: [TLS] 0-RTT and Anti-Replay Martin Thomson
- Re: [TLS] 0-RTT and Anti-Replay Eric Rescorla
- Re: [TLS] 0-RTT and Anti-Replay Roland Zink
- Re: [TLS] 0-RTT and Anti-Replay Martin Thomson
- Re: [TLS] 0-RTT and Anti-Replay Colm MacCárthaigh
- Re: [TLS] 0-RTT and Anti-Replay Viktor Dukhovni
- Re: [TLS] 0-RTT and Anti-Replay Martin Thomson
- Re: [TLS] 0-RTT and Anti-Replay Brian Sniffen
- Re: [TLS] 0-RTT and Anti-Replay Salz, Rich
- Re: [TLS] 0-RTT and Anti-Replay Roland Zink
- Re: [TLS] 0-RTT and Anti-Replay Martin Thomson
- Re: [TLS] 0-RTT and Anti-Replay Martin Thomson
- Re: [TLS] 0-RTT and Anti-Replay Viktor Dukhovni
- Re: [TLS] 0-RTT and Anti-Replay Roland Zink
- Re: [TLS] 0-RTT and Anti-Replay Viktor Dukhovni
- Re: [TLS] 0-RTT and Anti-Replay Roland Zink
- Re: [TLS] 0-RTT and Anti-Replay Colm MacCárthaigh
- Re: [TLS] 0-RTT and Anti-Replay Ilari Liusvaara
- Re: [TLS] 0-RTT and Anti-Replay Viktor Dukhovni
- Re: [TLS] 0-RTT and Anti-Replay Ilari Liusvaara
- Re: [TLS] 0-RTT and Anti-Replay Nico Williams
- Re: [TLS] 0-RTT and Anti-Replay Viktor Dukhovni
- Re: [TLS] 0-RTT and Anti-Replay Nico Williams
- Re: [TLS] 0-RTT and Anti-Replay Nico Williams
- Re: [TLS] 0-RTT and Anti-Replay Eric Rescorla
- Re: [TLS] 0-RTT and Anti-Replay Nico Williams
- Re: [TLS] 0-RTT and Anti-Replay Patrick McManus
- Re: [TLS] 0-RTT and Anti-Replay Dave Garrett
- Re: [TLS] 0-RTT and Anti-Replay Martin Thomson
- Re: [TLS] 0-RTT and Anti-Replay Eric Rescorla
- Re: [TLS] 0-RTT and Anti-Replay Eric Rescorla
- Re: [TLS] 0-RTT and Anti-Replay Nico Williams
- Re: [TLS] 0-RTT and Anti-Replay Ilari Liusvaara
- Re: [TLS] 0-RTT and Anti-Replay Watson Ladd
- Re: [TLS] 0-RTT and Anti-Replay Ilari Liusvaara
- [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Ilari Liusvaara
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Martin Thomson
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Ilari Liusvaara
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Martin Thomson
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Ilari Liusvaara
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Martin Thomson
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Ilari Liusvaara
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Martin Thomson
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Daniel Kahn Gillmor
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Ilari Liusvaara
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Ilari Liusvaara
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Martin Thomson
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Nico Williams
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Ilari Liusvaara
- Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay) Ilari Liusvaara