Re: [TLS] implementation of cookies in DTLS

Nikos Mavrogiannopoulos <nmav@gnutls.org> Mon, 14 March 2011 15:28 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
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 52DB43A69AA for <tls@core3.amsl.com>; Mon, 14 Mar 2011 08:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.666
X-Spam-Level:
X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 yrv9VdS+Dkwb for <tls@core3.amsl.com>; Mon, 14 Mar 2011 08:28:56 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DD3D23A6929 for <tls@ietf.org>; Mon, 14 Mar 2011 08:28:55 -0700 (PDT)
Received: by wwa36 with SMTP id 36so3995820wwa.13 for <tls@ietf.org>; Mon, 14 Mar 2011 08:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=lqoGQgquyVSgcccX2gzp7LMPO4eQHs59fKuoXjPMp4I=; b=bY1tFBQAyyZzILvZeaPdl7wfC3ayVPjR6s+NM6Vz9RgUIPomeypYgdFDZfBb8HfTbz WyoRRdqNzbCvggRQZaDoGHlFEhMJchwJUijqztnbF/8igfyMliDnigaUD55MQEoAuTEo EKiwiMdbl8E6aW3rKHuTvTbTdFxqYdKIlxNFg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=A9nLV9UNrO6UY/xhKKGjBna0c/4tqlOgse6m4XL59uJgJCHdnTsf/NFjr8u6axPYmF 02fxc9Txv6fXOjbupBIaMqqcqn+A7CPV+y16Hdbhm3pKdyOB7GBTajL62QAJPLqlDWma Lu2oqWHSf72Vl87p89PGTFj6RsYiDF1rX6TNI=
Received: by 10.227.32.132 with SMTP id c4mr11274842wbd.190.1300116619043; Mon, 14 Mar 2011 08:30:19 -0700 (PDT)
Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id w25sm6226756wbd.11.2011.03.14.08.30.16 (version=SSLv3 cipher=OTHER); Mon, 14 Mar 2011 08:30:17 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4D7E3487.7090805@gnutls.org>
Date: Mon, 14 Mar 2011 16:30:15 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: Robin Seggelmann <seggelmann@fh-muenster.de>
References: <4D7D0292.7080700@gnutls.org> <CC864D93-07CA-4381-8C7A-CB263A3CA7DA@fh-muenster.de>
In-Reply-To: <CC864D93-07CA-4381-8C7A-CB263A3CA7DA@fh-muenster.de>
X-Enigmail-Version: 1.1.2
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: =?ISO-8859-1?Q?T=FCxen?= <tuexen@fh-muenster.de>, =?ISO-8859-1?Q?Michael_?=, 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:28:57 -0000

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