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