Re: [TLS] implementation of cookies in DTLS

Nikos Mavrogiannopoulos <> Tue, 15 March 2011 11:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75FB03A6C7B for <>; Tue, 15 Mar 2011 04:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2axw92JOidM0 for <>; Tue, 15 Mar 2011 04:35:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8BF2B3A6C78 for <>; Tue, 15 Mar 2011 04:35:51 -0700 (PDT)
Received: by qwg5 with SMTP id 5so410253qwg.31 for <>; Tue, 15 Mar 2011 04:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XCtChp8KWnBe9mxfNC6B6pSKa0oscP9+0NRI3D3dDpY=; b=EX7f3LGFrh4GB5FZPx/LSOb65x89q9WC37sfE/OV6QK3J8OFTVWPCHTRffwij0cTdZ BJH0su7kulQY07VHNx+fauFCJsGAdOfkhta24KdnYIHwvNBcUzqLa0CSTBDbaIz6WeAz IO5y+1tm7x7+QpALkuKrNzDaYF45dVVJF7RiU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LtX0BZ1jf1OfLuWFrDd++qJjx4K2U3/zuBkDS8rBvZtTnyCahKRDwbhbLYgTYoV9iz y3BRgMeHmiSsdS0g6rly2+W4OLlVL9gVxxp2b1Z53TwDrrv3jOCQ/Fqlee6l+ydQLDvw tO46LdGrj5L1b3kS1Nq8kgZ0o1yDWHmU+E9gk=
MIME-Version: 1.0
Received: by with SMTP id hm6mr12441743qab.172.1300189036122; Tue, 15 Mar 2011 04:37:16 -0700 (PDT)
Received: by with HTTP; Tue, 15 Mar 2011 04:37:16 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 15 Mar 2011 12:37:16 +0100
X-Google-Sender-Auth: tqFnJpbkT9h93Tcxt0K8Pqb-sKs
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [TLS] implementation of cookies in DTLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Mar 2011 11:35:52 -0000

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

>> 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.

My issue is not about server remembering stuff, but the fact that at this point
the server has minimum information  and has to do actual negotiation of the
protocol version.

Depending on the implementation chosing the version to negotiate might not
be simple. I.e. the application might have configured that DTLS 1.0 and DTLS
1.2 are allowed, but say for example only ciphersuite 0xfb, 0xbf is enabled for
this client, that has the constraint that it can be used with DTLS 1.0
this is not an issue now in DTLS but this scenario is common in TLS).
Thus the server cannot readily negotiate the highest DTLS 1.2, but has to also
check ciphersuites for conflicts, meaning that this pre-handshake cannot really
be kept as minimal as possible.

I think the pre-handshake should be as dumb as possible to serve its
role as DoS
protection and no more. In typical cases it is expected to be implemented as
something external to the handshake process, thus would be nice to require
as less information and information interpreting as possible.