Re: [TLS] implementation of cookies in DTLS

[Michael Tüxen <[e-mail]>]

On Mar 15, 2011, at 12:18 PM, Eric Rescorla wrote:

> On Tue, Mar 15, 2011 at 2:59 AM, Nikos Mavrogiannopoulos
> <[e-mail]> wrote:
>> On Tue, Mar 15, 2011 at 12:37 AM, Eric Rescorla <[e-mail]> wrote:
>>> I suspect either reflecting or the special case would work. I'm trying
>>> to get all the other
>>> changes in before the deadline so I'll leave it with =0 and the
>>> special case and an
>>> open issue marker and let's just resolve in Prague.
>> 
>> I will not be there but I'd like to make these points:
>> 1. Define precisely the behavior of initial pre-handshake before state
>> is allocated. My opinion is that I don't like special cases such as
>> use 0 always
>> and do not case about re-use because they are more likely to introduce
>> bugs and new attacks. Copying the client's numbers should solve the
>> issue with no special cases and no state. Also I suppose that if
>> handshake_seq=0 is used for HelloVerifyRequest then handshake_seq=1
>> should be used for ServerHello and this should be clear as well to
>> avoid having another special case.
> 
> Noted.  Let's see how that discussion shakes out in the meeting.
Hi Eric,

I can't attend the IETF meeting and would also prefer the reflection
for the same reasons Nikos pointed out.

Best regards
Michael
> 
> 
>> 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.
> 
> -Ekr
>