Re: [TLS] implementation of cookies in DTLS

Robin Seggelmann <seggelmann@fh-muenster.de> Mon, 14 March 2011 19:25 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 93BC33A6B4E for <tls@core3.amsl.com>; Mon, 14 Mar 2011 12:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 RmwmIgMVYGDb for <tls@core3.amsl.com>; Mon, 14 Mar 2011 12:25:46 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by core3.amsl.com (Postfix) with ESMTP id 518C13A6979 for <tls@ietf.org>; Mon, 14 Mar 2011 12:25:46 -0700 (PDT)
Received: from [92.224.175.10] (helo=solemac.solenet.lan) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <seggelmann@fh-muenster.de>) id 1PzDPu-0004Z1-SG; Mon, 14 Mar 2011 20:26:59 +0100
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="iso-8859-1"
From: Robin Seggelmann <seggelmann@fh-muenster.de>
In-Reply-To: <B62B9484-F16A-405C-A943-504ADB6D572F@lurchi.franken.de>
Date: Mon, 14 Mar 2011 20:26:58 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de>
References: <4D7D0292.7080700@gnutls.org> <CC864D93-07CA-4381-8C7A-CB263A3CA7DA@fh-muenster.de> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <A28CA8BD-3C30-4D4A-9DD9-05A0FA1574E3@lurchi.franken.de> <FDF29FE9-F64F-42AE-B885-7F3B64E3424D@fh-muenster.de> <B62B9484-F16A-405C-A943-504ADB6D572F@lurchi.franken.de>
To: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
X-Mailer: Apple Mail (2.1082)
X-Df-Sender: fh@robin-seggelmann.de
Cc: "tls@ietf.org" <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 19:25:47 -0000

On 14.03.2011, at 20:13, Michael Tüxen wrote:

> On Mar 14, 2011, at 7:16 PM, Robin Seggelmann wrote:
>> 
>> On 14.03.2011, at 19:01, Michael Tüxen wrote:
>> 
>>> On Mar 14, 2011, at 5:20 PM, Robin Seggelmann wrote:
>>>> 
>>>> 
>>>> On 14.03.2011, at 16:52, Robin Seggelmann <seggelmann@fh-muenster.de> wrote:
>>>> 
>>>>> 
>>>>> On Mar 14, 2011, at 4:30 PM, Nikos Mavrogiannopoulos wrote:
>>>>> 
>>>>>> 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...
>>>>> 
>>>>> The record_seq is still increased, because it has to be unique. I wouldn't consider this as a problem because it's just a counter you're increasing. There is no resource allocation necessary and there is no benefit for an attacker to send many ClientHellos to increase the sequence number. It's only used for HMAC verification and replay check and will be reset to 0 after the ChangCipherSpec anyway.
>>>>> 
>>>>> However, I see your point. Maybe the document should state more explicitly that handshake sequence numbers must not be increased, because they always have to be the same and always have to start with 0, while the record_seq has to be unique and therefore has to change.
>>>> 
>>>> I forgot to mention that in OpenSSL I'm using the same record_seq counter for every incoming request until a CH with a valid cookie arrives. This is due to a workaround to implement an UDP based and thus one-to-many style protocol in OpenSSL's one-to-one architecture, but so I'm not required to allocate anything.
>>> Hi Robin,
>>> 
>>> can you be more specific? Did you implement it such that Nikos
>>> message exchange is valid? So do you copy the rec. seq. number
>>> from the incoming packet? Do you use the same counter for multiple
>>> client until you receive a CH with a valid cookie?
>> 
>> I don't copy the record sequence. The server is using one counter for multiple clients until the CH with a valid cookie. So the first HelloVerifyRequest has record seq 0, the second 1 and so on. When a cookie has been verified, the ServerHello will have the next record seq, while the next HelloVerifyRequest for an other client will have 0 again.
> So does this mean that one client affects the other?

Only by increasing the record sequence. As an example, a scenario with a low RTT client (lc), a high RTT (hc) client, the server listening with SSL object s1 and then s2:

hc: ClientHello(rseq:0, hseq: 0)
s1: HelloVerifyRequest(rseq:0, hseq:0)
lc: ClientHello(rseq:0, hseq: 0)
s1: HelloVerifyRequest(rseq:1, hseq:0)
lc: ClientHelloCookie(rseq:1, hseq: 1)
s1 will be connected to lc, now s2 listens
s1: ServerHello(rseq:2, hseq:1)
hc: ClientHelloCookie(rseq:1, hseq: 1)
s2 will be connected to hc, now s3 listens
s1: ServerHello(rseq:0, hseq:1)

So the more ClientHellos arrive before one with a valid cookie, the higher is the record sequence number. That's the only "state" in the server that changes. Otherwise I would have to maintain the record sequence per client which would require resource allocation or always use the same with the retransmission issues Nikos pointed out.

Regards,
Robin

> Best regards
> Michael
>> 
>> This is because I'm using an SSL object (and its rec seq counter) for listening, which will be assigned to the first client with a valid cookie to continue the connection, so the next handshake message, that is the ServerHello, will habe the next record seq. A new SSL object (with reset counters) is then created to continue listening and responding to ClientHellos.
>> 
>> Best reagards,
>> Robin
>> 
>>> Best regards
>>> Michael
>>>> 
>>>>> Regards,
>>>>> Robin
>>>>> 
>>>>>>>> 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
>>>>> 
>>>>> 
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>> 
>> 
>>