Re: [TLS] Pull request for 1RTT Handshake

[Watson Ladd <[e-mail]>]

On Thu, Jul 3, 2014 at 9:00 PM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> 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?

Why send two messages when one will do? In particular the server can
send a Server Key Exchange,
and a Certificate, CertificateVerify message in response to the Client Hello.

Once the client receives this, it's ready to send data after its CKE
and such messages.

Restarting the protocol the way we have now introduces another round trip.

In fact, it might be worth ditching the current client psyc approach
in favor of this one: less complex,
backwards compatibility by signalling an extension, and gets client
authentication in one round trip also.

This of course assumes a minor change to the protocol's calculation of
keys, and makes 0-RTT more of a jump.

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

I was a bit confused about what exactly Finished protects, and why we
need to wait for it.

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

Have you read the hello-pading draft? Or heard people complain about
Java interop with things not RC4?
Vendors are not adequately testing their ability to deal with legal
but unused corners of the spec, and virtually none of them are doing
adversarial fuzzing.

Sincerely,
Watson Ladd
>
> 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.
>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin