Re: [TLS] Pull request for 1RTT Handshake

[Watson Ladd <[e-mail]>]

On Thu, Jul 3, 2014 at 10:27 PM, Eric Rescorla <[e-mail]> wrote:
> On Thu, Jul 3, 2014 at 9:41 PM, Watson Ladd <[e-mail]> wrote:
>>
>> On Thu, Jul 3, 2014 at 9:00 PM, Eric Rescorla <[e-mail]> wrote:
>>
>> 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.
>
>
> I assume you intend the ServerHello here as well, since you need that for
> the
> cipher suite, etc.?
>
>
>>
>> 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.
>
>
> Ah, I understand what you are suggesting.
>
> Certainly something like this is possible, but the general sense of the
> discussion at the Interim was that people wanted the "wrong group"
> handshake to look like a missed guess/correction followed by the "right
> group" handshake, in the interest of simplicity. Note also that if we
> have a relatively small number of groups (which seems like a good idea
> in any case) then the vast majority of handshakes can complete in 1-RTT
> because the client guesses right (e.g., they send P256 and 25519 and
> the server supports one or both.)

True: the client can take a guess.
>
> Another difficulty is that it in the flow you are suggesting, you don't
> protect
> the server's first flight, which includes:
>
> - The server's extensions response (and request if we add DKG/Ritter's
>    'type B extensions').
>
> - The server's certificate (relevant if using SNI encryption and for
>    passive protection for P2P applications).

Unless I'm missing something you aren't either: the Change Cipher Spec
would come before the Certificate and Certificate Verification to
protect these two. But yes, this does require guessing of server
parameters, so once we need to do that, might as well guess more.

(It seems a bit weird to me to design the protocol one feature request
at a time: that way lies Perl 6. Also, I don't recall having seen
'type B extensions': what was the rationale? How was the answer going
to come back?)

Sincerely,
Watson Ladd

>
> In some cases, an attacker can elicit these, so protection is just
> passive, and in others he cannot, in which case protection is also
> active.
>
> Best,
> -Ekr
>



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