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

[Watson Ladd <[e-mail]>]

On Fri, Nov 1, 2013 at 8:53 PM, Robert Ransom <[e-mail]> wrote:
> On 11/1/13, Dan Harkins <[e-mail]> wrote:
>>
>>
>> On Fri, November 1, 2013 5:38 pm, Robert Ransom wrote:
>>> On 11/1/13, Dan Harkins <[e-mail]> wrote:
>>>>
>>>>
>>>> On Fri, November 1, 2013 4:13 pm, Nico Williams wrote:
>>>
>>>>> 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).
Or we could use a RNG with a security reduction to something strong.
What is it about cryptography that causes people to invent unproven solutions
against nonexistent problems?
>>>>
>>>>   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.
>>>
>>> Small-subgroup attacks are entirely orthogonal to whether a server can
>>> be caused to reuse a session key.  (Reusing a session key destroys the
>>> security properties of many bulk encryption methods, including all
>>> stream ciphers, regardless of whether the server's DH secret key is
>>> disclosed.)
>>
>>   "caused to reuse a session key"? Who said anything about that.
>
> Nico Williams proposed omitting all nonces from (EC)DHE handshakes and
> shared secrets in a future version of TLS.  My objection to that
> proposal was that servers need to ensure that *something* in the
> handshake is fresh, and if that is not a nonce, they will need to
> ensure that at least one of the DH keypairs is new.  I thought it was
> obvious that the reason for that was to prevent an attacker from
> replaying the client DH public key and causing the server to reuse a
> session key.  (It was obvious to Nico.)
>
>> My
>> statement was in response to yours that said:
>>
>>    "If the server sends a nonce during DHE/ECDHE key exchange, the
>>     server can safely reuse its DH keypair for multiple clients WITH NO
>>     FURTHER DESIGN OR IMPLEMENTATION CONSIDERATIONS  (emphasis
>>     mine)".
>>
>> Again, if the server decides to reuse its DH key pair with multiple
>> clients then it needs some implementation considerations, namely it
>> needs to protect itself against a small sub-group attack. And this is
>> regardless of whether it sends a nonce or not. It has nothing to do with
>> key derivation.
>
> Sorry.  I forgot that some elliptic-curve groups are meant to be
> implemented in such a way that single-use ECDH keypairs appear to
> remain safe, but an attacker can obtain the secret portion of an ECDH
> keypair if it is used for more than one key exchange.
Which ones are those? Assuring near-prime order is trivial, as is
checking points are
on the curve. Maybe this explains why some people think it is okay to
skip curve checks.
>
> If the server sends a nonce during DHE/ECDHE key exchange, the server
> can safely reuse its DH keypair for multiple clients with no further
> *protocol-level* design or implementation constraints.  The
> cryptographic primitive still needs to be securely designed and
> implemented.
>
> My main point was that if the server does *not* send a nonce, as Nico
> suggested, the server needs significant further design,
> implementation, and runtime computation to reuse its DH keypair
> without reusing session keys.  That further effort may negate the
> performance benefits of reusing DH keypairs on the server side, and
> may lead implementations to not support (EC)DHE or a hypothetical
> future version of TLS.
Not really: it just needs to blacklist client keys that it has seen
before. The extra
design is trivial, and computation is checking a hash table or Bloom
filter (false positives
have no cost). If you have multiple threads each can have one cache. However,
the cost of a nonce is small.
>
>
>>   Also, your statement that "[r]eusing a session key destroys the security
>> properties of...all stream ciphers" leaves a bit of quantification up to
>> the reader. It's reuse of a session key _and_ a counter/nonce, and that's
>> only if you are not using SIV mode.
>
> RC4 does not support a counter/nonce.  Adam Langley's proposed
> ChaCha/Poly1305 ciphersuites use ChaCha's nonce input for the message
> number, not to permit safe reuse of a session key.
>
> GCM mode (which uses AES in counter mode as a stream cipher) may or
> may not reuse a nonce.  There's no way to guarantee that a GCM
> implementation will not choose to reuse the portion of a nonce that it
> generates, especially if it does not know that the key is being
> reused, but you do have a point -- GCM can be implemented in such a
> way that using a session key twice will not immediately destroy its
> security.  (Reusing a session key many times will still eventually
> lead to nonce reuse.)
>
> CCM mode (also based on AES in counter mode) may or may not reuse a
> nonce.  They cut-and-pasted the text from the GCM RFC that "Each value
> of the nonce_explicit MUST be distinct for each distinct invocation of
> the GCM encrypt function for any fixed key.", without changing "GCM"
> to "CCM", and again without any mention of how this distinctness is to
> be guaranteed within a 64-bit field if the implementation does not
> know that a key has been reused.  As with GCM, reusing a session key
> many times will still lead to nonce reuse in implementations with
> limited storage.
>
> SIV mode should be safer under key reuse, but is not used in any TLS
> ciphersuite, and is not likely to be useful if future versions of TLS
> retain the ServerRandom field (or an equivalent server-provided nonce
> in the handshake).
>
> Future stream-cipher-based ciphersuites are likely to be more like the
> proposed ChaCha ciphersuite than GCM/CCM.
Why are we talking about supporting multiple ciphersuites? We have
strong reductions
to the security of AES for everything we are considering using, or
some similar cipher.
Performance will lead to one clear winner. Options are bad: they
invite incompatibility
and deployment issues, and are a place for bugs to hide. I want to
write TLS 1.3 in an
IOCCC entry ideally. (Well, I would if the success of OpenSSL didn't
ensure people
would use it).

We could parametrize keysize if you really want: give a 128 and 256
option. But no more!
>
>
> In any case, for the sake of security, performance, and simplicity,
> ciphersuites should be able to rely on the handshake layer to not
> generate the same session key twice.
For the sake of all three of those we should have one ciphersuite, one
key negotiation,
one curve, and a security proof.

>
>
> Robert Ransom
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



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