Re: [TLS] TLS 1.3 draft-07 sneak peek

[Ilari Liusvaara <[e-mail]>]

On Tue, Jun 30, 2015 at 10:33:23PM -0700, Eric Rescorla wrote:
> On Tue, Jun 30, 2015 at 10:22 PM, Ilari Liusvaara <
> [e-mail]> wrote:
> 
> > On Tue, Jun 30, 2015 at 03:23:18PM -0700, Eric Rescorla wrote:
> > >
> > > OPEN ISSUES
> > > There are still a number of known open issues to discuss:
> > >
> > > 1. The present known_configuration mechanism allows the client to
> > > resurrect the handshake parameters (though not the keys) which were
> > > negotiated in a previous handshake, but this is done implicitly,
> > > i.e., the server provides a label and the client returns it on
> > > the next connection. This has the advantage of keeping things short
> > > but the disadvantage the it means that you can't have a static
> > > configuration ID for everyone (instead, the server has to somehow
> > > embed the properties in the configuration ID). There are (at least)
> > > three potential alternative designs:
> > >
> > >    (a) Have the client indicate in his first flight "these are the
> > >        parameters I expect you to negotiate", along with the
> > >        configuration identifier, based on what the server
> > >        negotiated the previous time. [Optionally, the server
> > >        can run the same negotiation locally and abort on mismatch.]
> > >
> > >    (b) As in (a) but with no indication of the expected parameters,
> > >        just the configuration ID, and the client just preemptively
> > >        uses the parameters from the last time and if the negotiation
> > >        ends up differently, all the data is undecryptable
> > >        (ugh) and you somehow fall back.
> > >
> > >    (c) Have the server provide a preference list in his
> > >        ServerConfiguration (this can be the same as in the
> > >        ClientHello) and have the client do the negotiation based on
> > >        that rather than the server (as in QUIC). This is a little odd
> > >        in that it means that sometimes the server selects the
> > >        parameters and sometimes the client does, but it's not that
> > >        hard to make this code symmetrical.
> > >
> > > As I think this through, I am leaning towards (a) but other people's
> > > opinions on this topic would be welcome.
> >
> > I think that there should be capability for server to fail decrypting
> > the 0RTT data but still proceed with handshake (informing client of
> > this fact).
> >
> 
> What I had in mind here was that you would be able to fail to decrypt
> the 0-RTT data and you fell back to an ordinary 1-RTT handshake
> (i.e., if there was client auth, it went in the second flight).

Without a retry, right? 

> Are parameters here things like symmetric ciphersuite used for 0RTT
> > encryption? Or something else? I think that even if one uses supported
> > symmetric ciphers, one could still get decrypt failures.
> >
> > Or is this the "PSK + 0RTT" vs "DHE + 0RTT" problem (the one remaked
> > in #3)?
> >
> 
> Sorry, I'm not quite following this. Can you rephrase?

Say, one has DHE-CERT (for full handshake) and pure-PSK (for resumption)
key exchanges signaled. Which one provodes the key to decrypt the 0-RTT
data (because the keys sure won't be the same)? 
 
> > Undecryptable 0RTT becomes practicularly fun when considering how
> > that would interact with handshake transcripts.
> 
> That's why I'm thinking that the above is the simpler approach.

Well, if handshake is not retried and 0RTT is rejected (i.e. server
replies with Finished in its reply), it shouldn't matter very much what
is in 0RTT data.

Then there's the more fun case of where handshake that has 0RTT data is
retried (e.g. missing group key). One needs to ensure transport
consistency[1] on retry as well as preferably defending against clients
and servers doing dumb things (experience has shown that all kinds of
dumb bugs creep in, despite MUST specifically against the behaviour in
question).

> > > 2. Should we require that PSK cipher suites where the PSK is used for
> > > resumption use compatible ciphers? This is the way it was in TLS 1.2
> > > and below for resumption and tickets, but once you have a PSK, that's
> > > not really necessary [0]. So, for instance, if you had the following
> > > cipher list order:
> > >
> > >     ECDHE + AES-GCM
> > >     ECDHE + ChaCha/Poly
> > >     PSK + ChaCha/Poly
> > >     PSK + AES-GCM
> > >
> > > You could potentially negotiate one connection with GCM, use it
> > > to establish a shared key, and then reconnect with ChaCha/Poly.
> > > This seems like it probably should be something we avoid, though
> > > I'm not sure we have a concrete reason why, and it means a
> > > weird special case for PSK. Note that this issue might be
> > > ameliorated some (though not completely) with a la carte negotiation.
> >
> > I would place stuff like this into "client sending odd stuff and
> > getting odd behaviour in response". And with the negotiation the
> > way it is, I don't see security problem here.
> 
> Thanks.

More specifically, if there's a problem here, pure-PSK also has that
problem (and more severe one). And due to THS fix, it is not possible
to perform dangerous actions like keying two different ciphers with the
same key.


[1] Renego bug actually involved inconsistent transport state, as well
as two different things looking confusingly similar.


-Ilari