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

[Ilari Liusvaara <[e-mail]>]

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

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

Undecryptable 0RTT becomes practicularly fun when considering how
that would interact with handshake transcripts.


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


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


> 3. I don't currently have PSK/Resumption + 0-RTT working, because you
> need a way to indicate the expected parameters (see point #1 above).


-Ilari