Re: [TLS] implementation of cookies in DTLS

[Robin Seggelmann <[e-mail]>]

Hi,

On Mar 13, 2011, at 6:44 PM, Nikos Mavrogiannopoulos 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.

> 2. There should be some text on how to determine the sequence
> numbers for the initial conversation without keeping state. As I
> understand one follows the peer's sequence numbers as reference?
> 
> 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.

> 3. The document describes a potential attack of an adversary
> collecting multiple cookies from several servers.
> Wouldn't adding a 40-bit or more salt to the cookie
> eliminate that threat? Given that cookie is pretty
> long (32-bytes) spending 5 or more bytes for a salt
> and 16 or 20 bytes for an HMAC would be practical.

RFC 4347 only makes suggestions how the cookie may look like and also states the problems of the suggested approach which may also apply to similar strategies. You can easily add a timestamp, random number, encryption, etc. for increased security in your implementation. OpenSSL leaves the implementation of cookie generation and verification callback functions to the user. This could be anything from doing nothing to generating a fully featured cookie.

Best regards
Robin