Re: [TLS] implementation of cookies in DTLS

[Nikos Mavrogiannopoulos <[e-mail]>]

On Tue, Mar 15, 2011 at 12:18 PM, Eric Rescorla <[e-mail]> wrote:

>> 2. Drop requirement: The server MUST use the same
>>   version number in the HelloVerifyRequest that it would use when
>>   sending a ServerHello.  Upon receipt of the ServerHello, the client
>>   MUST verify that the server version values match.
>> This will create incompatibilities when more than 1 DTLS protocols are
>> implemented
>> in a single client or server. It is not really possible for a server
>> to do an emulation of
>> the decisions it would do as if a state existed. What are the reasons for this
>> requirement?
> I don't understand why this is an issue: the server can remember what the
> client offered (indeed, he must remember a whole pile of other stuff in order
> to verify that it hasn't changed) by stuffing a digest into the cookie.

My issue is not about server remembering stuff, but the fact that at this point
the server has minimum information  and has to do actual negotiation of the
protocol version.

Depending on the implementation chosing the version to negotiate might not
be simple. I.e. the application might have configured that DTLS 1.0 and DTLS
1.2 are allowed, but say for example only ciphersuite 0xfb, 0xbf is enabled for
this client, that has the constraint that it can be used with DTLS 1.0
(probably
this is not an issue now in DTLS but this scenario is common in TLS).
Thus the server cannot readily negotiate the highest DTLS 1.2, but has to also
check ciphersuites for conflicts, meaning that this pre-handshake cannot really
be kept as minimal as possible.

I think the pre-handshake should be as dumb as possible to serve its
role as DoS
protection and no more. In typical cases it is expected to be implemented as
something external to the handshake process, thus would be nice to require
as less information and information interpreting as possible.

regards,
Nikos