Re: [TLS] Pull request for 1RTT Handshake

[Eric Rescorla <[e-mail]>]

On Thu, Jul 3, 2014 at 7:29 PM, Watson Ladd <[e-mail]> wrote:

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

I'm not saying that the client should change it's ClientHello, but since
there
are two messages, it could in principle do so, right?

The draft currently requires that the client not do so, in S 7.4.1.2:

      When a client first connects to a server, it is required to send
      the ClientHello as its first message.  The client can also send a
      ClientHello in response to a HelloRequest or on its own initiative
      in order to renegotiate the security parameters in an existing
      connection.  Finally, the client will send a ClientHello when the
      server has responded to its ClientHello with a ServerHello that
      selects cryptographic parameters that don't match the client's
      ClientKeyExchange.  In that case, the client MUST send the same
      ClientHello (without modification) along with the new
      ClientKeyExchange.

Does that seem problematic to you?



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


I'm not following your analysis here as to why this slows things down:

1. The client can't safely send data before it receives the server's
Certificate and CertificateVerify, since that's the first thing that
authenticates the server. These messages are sent in the same flight as the
Finished, so will arrive at more or less the same time.

2. If the server doesn't want client authentication for the data, it can
send data as soon as it receives the client's first flight. If not, then it
needs to wait for the client's Certificate and CertificateVerify, which
again is sent with the client's Finished. [0]

Why does the Finished slow things down in this case? What am I
missing?



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

Obviously, that's a potential problem, but it also seems pretty clear
that any extra data has to go in an extension for compatibility.

Best,
-Ekr


[0] DKG points out that the rules might be relaxable if the
server wants authentication for the client's data but might be willing
to send some data, such as a banner message, without client
auth, but let's deal with that later.