Re: [TLS] What would make TLS cryptographically better for TLS 1.3

["Dan Harkins" <[e-mail]>]

On Fri, November 1, 2013 4:13 pm, Nico Williams wrote:
> On Fri, Nov 01, 2013 at 03:38:06PM -0700, Dan Harkins wrote:
>> On Fri, November 1, 2013 2:34 pm, Robert Ransom wrote:
>> > On 10/31/13, Nico Williams <[e-mail]> wrote:
>> >
>> >>  - Many fewer nonce bytes and random IVs where possible.  Nonce
>> payloads
>> >>    should be sent when needed, if needed.  For example, to derive a
>> >>    session key from an DHE shared secret one does not really need
>> >>    nonces.  This means that counter modes are better, for example,
>> than
>> >>    CBC modes.
>> >
>> > If the server sends a nonce during a DHE/ECDHE key exchange, the
>> > server can safely reuse its DH keypair for multiple clients with no
>> > further design or implementation considerations.
>>
>>   I don't believe that's true. If the server reuses its ephemeral D-H
>> key
>> then caveat emptor applies-- it should validate the client's public key,
>
> Agreed.  A small nonce should suffice for key derivation if either party
> reuses their supposedly-ephemeral DH keys.  By "small" I mean "not
> nearly as large as 32 bytes, i.e., not enough to suffice for a
> Dual_EC-type backdoored RNG attack".  The party reusing a key should
> send some such small nonce, possibly a 64-bit nonce.  In any case, the
> client ought not be reusing ephemeral DH keys, and any server that does
> should be rotating them often (like SSHv1 used to).

  It has nothing to do with key derivation, it's to prevent a small sub-group
attack. Sending a nonce does not prevent this attack since it's just going to
be another known for the attacker to use when running through the small
sub-group looking the right secret.

>> regardless of whether a nonce is sent or not.
>
> For some curves there's no need to validate the client's public key.

  Which curves would those be?

  Dan.