Re: [TLS] Potential New Handshake Flows for TLS 1.3

[Watson Ladd <[e-mail]>]

On Tue, Nov 5, 2013 at 8:01 PM, Nico Williams <[e-mail]> wrote:
> On Tue, Nov 5, 2013 at 9:38 PM, Watson Ladd <[e-mail]> wrote:
>> Is there a technical reason we can't have the client send an ECDH key,
>> server respond with ECDH key and signature of client
>> and server keys, and then use that key for a transmission in the response.
>> This has one round trip latency, and is secure under standard assumptions.
>
> Sure, but this is optimistic; there has to be a fallback if the server
> doesn't like the client's proposed curve/group/whatever.  The client
> could send multiple DH keys, but...  Also, might as well always use
> key agreement (which isn't quite the same as PFS, since what should be
> ephemeral keys might get reused).
>
> So, at least for initial [and therefore non-resumption] connections
> there must be at least an option for a 1.5 round trip handshake.  Note
> that a 1.5 round-trip handshake does not add a round-trip's worth of
> latency to when the client can start sending application records -- it
> only adds local crypto's worth of latency.
Solution: the client says what it will accept and offer, and the
server goes first. Actually,
I don't like that idea because we have to have the server present an
authentication of the handshake.
The fact that we need this is utterly horrid: there should be so few
options that
the chances of success are very good.

Seriously, why don't we resolve to do it right this time? Yes,
backwards compatibility matters, but at this point
it will break because RC4 is dead, and so is AtE without seriously clever fixes.
>
>> The second issue is that historically the handshaking has been a
>> plague upon the security: We should chop out handshakes,
>> not add them, to simplify the analysis. This assumes we keep the
>> bloated message+extension format here.
>
> The key to this is negotiating key agreement, DH groups/curves, KDFs,
> hash functions, server authentication methods, and symmetric (and
> authenticated) ciphers+modes separately, in as compact a way as
> possible (variable-length bitmasks, with a registry of bit numbers).
> With optimal initial assignments (optimal for assignment-time
> conditions anyways, or near future) this might yield really, really
> small hellos.
Will anyone not using AES_GCM, AES_SHA256, or the ECDHE variants
thereof, please explain to the list
what your reason is?
>
> Nico
> --



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