Re: [TLS] Pull request for 1RTT Handshake

[Watson Ladd <[e-mail]>]

On Thu, Jul 3, 2014 at 7:54 AM, Eric Rescorla <[e-mail]> wrote:
> I've just put up a pull request that makes the first cut changes from
> the consensus from Denver for 1-RTT handshake without SNI
> protection. As we discussed, I'm leaving the door open for SNI
> protection, but since these are separable work items, and this is
> already a fairly signficant change I wanted to get the 1-RTT stuff
> down first.
>
> The PR can be found at:
>
>   https://github.com/tlswg/tls13-spec/pull/52
>
> It's still kind of rough and there are a bunch of open issues (and
> most likely several mistakes) but I think it's clear what direction
> it's going in.
>
> I wanted to explicitly called out some known open issues in the draft,
> both so I can get feedback/discussion on these and so that people know
> they haven't been forgotten:
>
> - Based on the mailing list and interim discussion and a bunch of
>   private conversations, I wrote this up as requiring named DHE groups
>   (and assuming we will want named ECDHE groups). This makes things
>   quite a bit simpler and seemed like a good idea anyway. I recognize
>   that I'm a bit ahead of the list consensus here, but my sense is
>   that this was the emerging consensus.  If there are major objections
>   to this change, I can rework things otherwise, but I believe it will
>   make things more confusing.
>
> - I have partly removed dh_rsa and dh_dss because they get in the way
>   of having a common handshake pattern and nobody seemed to want
>   them. Assuming nobody screams I will do a separate PR to remove them
>   entirely.
>
> - We need to take care that we don't introduce a downgrade issue in
>   the 2-RTT flow (Figure 2) where the server tells the client he has
>   sent an incorrect CKE. There are some open issues noted in the draft
>   about how to do this exactly. Comments welcome.
>
> - MT convinced me that the client should be able to make multiple
>   ClientKeyExchange offers for different parameter sets, so I did
>   that.

So I don't why a client would change their Client Hello in response to
a Server Hello, and hence
why there can be a downgrade.

The client says "here are my capabilities, and some early guesses as
to what you want to see"
If those guesses are incorrect, there is no need for another Hello:
the server already knows what
the client wants to tell it, and the client knows what the server would see.

There is no state machine issue, because the server knows if it got
the data or not, and
the client will know if the negotiated curve and suite were among the guesses.

Another misfeature is the Finished message ordering: it slows down one
side or another.
If we fix Triple Handshake the right way, it's safe to send data
before receiving the other
Finished message.

>
> - The EarlyData mechanism is a bit overgeneral as opposed to an
>   explicit ClientKeyExchange extension, but it seems like it's going
>   to be useful when we do SNI encryption and 0-RTT.

Are we ever going to be able to turn it off? Clients initially will
use only it for compatibility. Servers will develop bugs
because clients all use it. Lather, rinse, reiterate.

Sincerely,
Watson Ladd