Re: [TLS] implementation of cookies in DTLS

[Eric Rescorla <[e-mail]>]

On Tue, Mar 15, 2011 at 4:37 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> 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.

Ah, I see your point. I'll have to think a bit about what I think the
best approach is
here.

-Ekr