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

[Eric Rescorla <[e-mail]>]

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).


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?



> 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.



> > 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.


Also, I noted that there isn't EncryptedExtensions for resumption.
> Is that message optional (it isn't marked so), or is it just omitted
> in pure-PSK case (tho I note that pure-PSK might want to use
> extensions that use EncryptedExtensions).


That's just error on my part. My intent was to make resumption-as-PSK as
much like ordinary handshakes as possible.


-Ekr