Re: [TLS] implementation of cookies in DTLS

[Nikos Mavrogiannopoulos <[e-mail]>]

On 03/14/2011 04:12 PM, Robin Seggelmann wrote:

>> Hello, I've been reading the section "Denial of Service
>> Countermeasures" of DTLS and as I understand it the proposed
>> subsystem (client-hello and client-hello-verify-request) is
>> expected to operate before allocating state for the session to
>> discard requests from clients with forged addresses.
>> 
>> Some comments: 1. The document says: If a server receives a
>> ClientHello with an invalid cookie, it SHOULD treat it the same as
>> a ClientHello with no cookie.
>> 
>> What does it mean with regards to the handshake sequence. Does the 
>> second HelloVerifyRequest has seq=0 or seq=1?
> 
> The second HelloVerifyRequest should have seq=0 again, since the
> server must not change its state. That's how I implemented it in
> OpenSSL.  The server does not change any sequence numbers until a
> cookie has been verified and the regular handshake continues.

What about the record_seq. Is it also 0? If yes  a client
would see this record packet as a replay and discard it. If no
it seems you have to keep state...

>> e.g. if I receive ClientHello (record_seq=0, seq=0)  ------>
>> 
>> <-- HelloVerifyRequest (record_seq=0, seq=0)
>> 
>> ClientHello (record_seq=1, seq=1)  ------> (wrong cookie)
>> 
>> <-- HelloVerifyRequest (record_seq=1, seq=1) [seq copied from
>> clienthello]
>> 
>> ClientHello (record_seq=2, seq=2)  ------> (wrong cookie)
>> 
>> <-- HelloVerifyRequest (record_seq=2, seq=2) [seq copied from
>> clienthello]
>> 
>> ClientHello (record_seq=3, seq=3)  ------>
>> 
>> [server allocates session and continues handshake]
> That may be helpful, but in my opinion "must not change its state"
> includes not changing any sequence numbers.

What is of most concern is the record_seq. A client would just discard
packets with the same sequence number.

regards,
Nikos