Re: [TLS] Final (hopefully) issues with DTLS 1.2

Sean Turner <> Mon, 04 July 2011 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27D7B21F85AC for <>; Mon, 4 Jul 2011 08:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.425
X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R6C2P4abaEof for <>; Mon, 4 Jul 2011 08:11:27 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id ADBCA21F8597 for <>; Mon, 4 Jul 2011 08:11:26 -0700 (PDT)
Received: from [] by with NNFMP; 04 Jul 2011 15:11:23 -0000
Received: from [] by with NNFMP; 04 Jul 2011 15:11:23 -0000
Received: from [] by with NNFMP; 04 Jul 2011 15:11:23 -0000
Received: (qmail 24803 invoked from network); 4 Jul 2011 15:11:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1309792283; bh=o+T6FKnRdE9zPZ47GeUrl+x7gvmaSuItzW+GcdA4/N8=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZP1j1ozYseknfVw8MTFQSQvag9jDqpjHEO0cOfKxfgATmNt2m9JFbXX+lru15kozy+H0xHAeOzKamDqvHgF7UjgHwDvnSuPsy+X9xNHjPPWgqnnidjs/RPiNl9jOJj7ZwCTHWUHdq8lW+tr7CZBh+0wDgIm1SEY/MMlLOWpkdBk=
Received: from (turners@ with plain) by with SMTP; 04 Jul 2011 08:11:21 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: u7jKjU4VM1lMo6hZxjcG6ES4cGf98ez1AW6FqjkUwyfM5us F5fgRHXQ4m8gWKxJM7IPLzwVvuq3XJyVwadmCJ8tr7yB4B7KNuJ0u29FtmHU VQOViZETA2ezJb5vmh6l4d.o8AtLuBy1n_VxATM6oaHf1cgPinS4HJr1_D4f uSEgzQqYq_6Mb6LBmhJobFAnCJgBXAsZVHL89q.pEePlll17Q6ZbTY0dRZr9 FlDSC6uh7evQz5kdeZKcugOcMCj_lz1uIqojZYz33GFZt9l2O8gzhSXqBE_A PnIiUdSIr8QQfRALlKz5AjjhXmAdwYKq7Y_H_yhq1M2EUU2jlKdfZwHvoHaF rivLMokC1oCfO1uF2nvSousbZ3oVz6NJ_yNSXUaDkKg--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Mon, 04 Jul 2011 11:11:20 -0400
From: Sean Turner <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Final (hopefully) issues with DTLS 1.2
X-Mailman-Version: 2.1.12
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: Mon, 04 Jul 2011 15:11:28 -0000

Can we have comments back by the 8th?  That way if we need to make 
changes we can get them in before the submission deadline on the 11th.


On 7/3/11 8:58 PM, Eric Rescorla wrote:
> I have now submitted draft -06, which (I believe) matches Nikos's
> version number fix.
> As Nikos objected to giving the CCS a sequence number and nobody spoke up for
> it, I left it as-is and added a warning. I would mildly favor adding
> one, but I don't
> think the change is appropriate absent support from the WG which has not yet
> been observed. If people believe that this change is appropriate, please speak
> up. Otherwise I believe we are done.
> Best,
> -Ekr
> On Tue, Jun 14, 2011 at 9:41 AM, Joe Salowey<>  wrote:
>> The open issue is with respect to the version number that Nikos raised.  Eric is working on text along the lines of Nikos' recommendation of fixing the version number.
>> Joe
>> On Jun 9, 2011, at 6:29 AM, Sean Turner wrote:
>>> Does anybody else have thoughts about this?  I'd really like to be able to put this draft to bed.
>>> spt
>>> On 5/23/11 9:19 AM, Eric Rescorla wrote:
>>>> Following up on Prague, here is the new text for the 2MSL and the
>>>> record sequence number issues:
>>>> MSL:
>>>> 4.1.
>>>>     Note that because DTLS records may be reordered, a record from epoch
>>>>     1 may be received after epoch 2 has begun. In general,
>>>>     implementations SHOULD discard packets from earlier epochs, but if
>>>>     packet loss causes noticeable problems MAY choose to retain keying
>>>>     material from previous epochs for up to the default MSL specified for
>>>>     TCP [TCP] to allow for packet reordering. (Note: the intention here
>>>>     is that implementors use the current guidance from the IETF for MSL,
>>>>     not that they attempt to interrogate the MSL the system TCP stack is
>>>>     using.)  Until the handshake has completed, implementations MUST
>>>>     accept packets from the old epoch.
>>>>     ...
>>>> 4.2.4.
>>>>     In addition, for at least twice the default MSL defined for [TCP],
>>>>     when in the FINISHED state, the node which transmits the last flight
>>>>     (the server in an ordinary handshake or the client in a resumed
>>>>     handshake) MUST respond to a retransmit of the peer's last flight
>>>>     with a retransmit of the last flight. This avoids deadlock conditions
>>>> Record Sequence Number:
>>>>     When responding to a HelloVerifyRequest the client MUST use the same
>>>>     parameter values (version, random, session_id, cipher_suites,
>>>>     compression_method) as it did in the original ClientHello.  The
>>>>     server SHOULD use those values to generate its cookie and verify that
>>>>     they are correct upon cookie receipt.  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. In order to avoid
>>>>     sequence number duplication in case of multiple HelloVerifyRequests,
>>>>     the server MUST use the record sequence number in the ClientHello as
>>>>     the record sequence number in the HelloVerifyRequest.
>>>> ...
>>>>     When the second ClientHello is received, the server can verify that
>>>>     the Cookie is valid and that the client can receive packets at the
>>>>     given IP address.  In order to avoid sequence number duplication in
>>>>     case of multiple cookie exchanges, the server SHOULD use the record
>>>>     sequence number in the ClientHello as the record sequence number in
>>>>     its initial ServerHello. Subsequent ServerHellos will only be sent
>>>>     after the server has created state and MUST increment normally.
>>>> I believe this matches what I said in Prague, but any objections to
>>>> this in concept or the way I've written it up.
>>>> Finally, I've been rethinking the issue of the interaction of the
>>>> ChangeCipherSpec and the handshake sequence numbers. In Prague I
>>>> suggested not changing this and just putting a note in the spec that
>>>> one had to be careful, but at this point I am thinking it might be
>>>> better to simple suck up the change and put a message sequence number
>>>> in the CCS. This removes the need to consult the handshake state
>>>> machine in order to deal with reordering, though not in order to
>>>> determine whether the CCS is at the appropriate place in the handshake
>>>> (in order to detect misbehaving or malicious behavior early).  The
>>>> downside for this is that it's a difference from TLS, but it seems
>>>> like fairly easy code--though I admit I haven't tried to code it up. I
>>>> don't think either way represents a security issue, but doing it this
>>>> way means that we won't need to be as careful in the future about
>>>> having the state machine be completely deterministic prior to the CCS,
>>>> which seems like the Right Thing. Comments?
>>>> -Ekr
>>>> _______________________________________________
>>>> TLS mailing list
>>> _______________________________________________
>>> TLS mailing list
>> _______________________________________________
>> TLS mailing list