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

Sean Turner <turners@ieca.com> Mon, 04 July 2011 15:11 UTC

Return-Path: <turners@ieca.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D7B21F85AC for <tls@ietfa.amsl.com>; Mon, 4 Jul 2011 08:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.425
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6C2P4abaEof for <tls@ietfa.amsl.com>; Mon, 4 Jul 2011 08:11:27 -0700 (PDT)
Received: from nm19.bullet.mail.ac4.yahoo.com (nm19.bullet.mail.ac4.yahoo.com [98.139.52.216]) by ietfa.amsl.com (Postfix) with SMTP id ADBCA21F8597 for <tls@ietf.org>; Mon, 4 Jul 2011 08:11:26 -0700 (PDT)
Received: from [98.139.52.189] by nm19.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jul 2011 15:11:23 -0000
Received: from [98.139.52.163] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jul 2011 15:11:23 -0000
Received: from [127.0.0.1] by omp1046.mail.ac4.yahoo.com with NNFMP; 04 Jul 2011 15:11:23 -0000
X-Yahoo-Newman-Id: 696517.15269.bm@omp1046.mail.ac4.yahoo.com
Received: (qmail 24803 invoked from network); 4 Jul 2011 15:11:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; 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 thunderfish.westell.com (turners@71.191.8.211 with plain) by smtp114.biz.mail.mud.yahoo.com 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: <4E11D818.3030701@ieca.com>
Date: Mon, 04 Jul 2011 11:11:20 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: tls@ietf.org
References: <BANLkTikjMZpYm4Maef1wqnmH4RJ02-6t1g@mail.gmail.com> <4DF0CA9D.1030006@ieca.com> <9ACC73EC-6834-465B-A5DD-A0DFAE80BD40@cisco.com> <CABcZeBMg9JfCLr4bAGnNm_6My8CtONsoOnjzioRf3ByQ1udrOw@mail.gmail.com>
In-Reply-To: <CABcZeBMg9JfCLr4bAGnNm_6My8CtONsoOnjzioRf3ByQ1udrOw@mail.gmail.com>
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-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 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.

spt

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<jsalowey@cisco.com>  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@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>