Re: [TLS] implementation of cookies in DTLS

Robin Seggelmann <seggelmann@fh-muenster.de> Mon, 14 March 2011 15:11 UTC

Return-Path: <seggelmann@fh-muenster.de>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B235A3A6DAC for <tls@core3.amsl.com>; Mon, 14 Mar 2011 08:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgCzAQmMsiTr for <tls@core3.amsl.com>; Mon, 14 Mar 2011 08:11:33 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by core3.amsl.com (Postfix) with ESMTP id 93C643A6905 for <tls@ietf.org>; Mon, 14 Mar 2011 08:11:33 -0700 (PDT)
Received: from [212.201.121.94] (helo=[10.0.1.103]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <seggelmann@fh-muenster.de>) id 1Pz9S0-0006L9-3E; Mon, 14 Mar 2011 16:12:52 +0100
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Robin Seggelmann <seggelmann@fh-muenster.de>
In-Reply-To: <4D7D0292.7080700@gnutls.org>
Date: Mon, 14 Mar 2011 16:12:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC864D93-07CA-4381-8C7A-CB263A3CA7DA@fh-muenster.de>
References: <4D7D0292.7080700@gnutls.org>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
X-Mailer: Apple Mail (2.1082)
X-Df-Sender: mail@robin-seggelmann.de
Cc: =?iso-8859-1?Q?Michael_T=FCxen?= <tuexen@fh-muenster.de>, tls@ietf.org
Subject: Re: [TLS] implementation of cookies in DTLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2011 15:11:34 -0000

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