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

Sean Turner <turners@ieca.com> Thu, 09 June 2011 13:29 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 79EEB11E80B7 for <tls@ietfa.amsl.com>; Thu, 9 Jun 2011 06:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.91
X-Spam-Level:
X-Spam-Status: No, score=-101.91 tagged_above=-999 required=5 tests=[AWL=0.687, 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 y6gSpMO1FjaI for <tls@ietfa.amsl.com>; Thu, 9 Jun 2011 06:29:13 -0700 (PDT)
Received: from nm16.access.bullet.mail.mud.yahoo.com (nm16.access.bullet.mail.mud.yahoo.com [66.94.237.217]) by ietfa.amsl.com (Postfix) with SMTP id CAEFF11E8081 for <tls@ietf.org>; Thu, 9 Jun 2011 06:29:06 -0700 (PDT)
Received: from [66.94.237.126] by nm16.access.bullet.mail.mud.yahoo.com with NNFMP; 09 Jun 2011 13:29:03 -0000
Received: from [66.94.237.100] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 09 Jun 2011 13:29:03 -0000
Received: from [127.0.0.1] by omp1005.access.mail.mud.yahoo.com with NNFMP; 09 Jun 2011 13:29:03 -0000
X-Yahoo-Newman-Id: 883336.54150.bm@omp1005.access.mail.mud.yahoo.com
Received: (qmail 89084 invoked from network); 9 Jun 2011 13:29:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307626143; bh=YIS9xS6gLf4P1aQQidarQKO9s07Cx9jjMu+OSu1uXfA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=5ozt3YVe14tKNu9ReGaXSc1JKzcY88D4JBJ9LJCF+6FdDhRGS/dt6EC/zMBDKBOyOPfmHnJsSpeEVHcWWrBQq1QSyaPDKwPjivqSDTrMTj6vnSjQ1YRRX1ReXfwPmOEqc0uN8anCv7csz4mEXHuhFUnVdyNV3D1HVCi6XvLwmPI=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: UvNuqUgVM1kQNxFiAujcy7DmyQp0xrpI5xsQiCXUDpv94s0 nigWj7YKffLoalSZs2f.a1IuArD1IGtDsRKcP7uanQA6ELUHgER1bEwC3cBK K.4F2egvYQia7AHJGS92fUAoGrngzqriLvbQwqTnWzNmSKHYFN1vPBWimcC7 CdCX5qDMB3Mt5SZsGiSsm9R3yXqFptU2.FXswWMQ8Ol8hs7H6NQwpO85Zh04 83EZ1.tHJb14mSbDTeq37VpKXVymNnqyDpKYfPegC4tHm8NMVQeTnuwpXaKd 5WNfz_QNvEria8K7ZmJf81nTTayr5bZT7FKKG8M2jYnicrULOFbghJokgIWY vHXhGQdJx0CS5M9WRDcnILJE6Xis3p.NHvbuWZqCx
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
Received: from thunderfish.local (turners@96.231.120.246 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 09 Jun 2011 06:29:02 -0700 PDT
Message-ID: <4DF0CA9D.1030006@ieca.com>
Date: Thu, 09 Jun 2011 09:29:01 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: tls@ietf.org
References: <BANLkTikjMZpYm4Maef1wqnmH4RJ02-6t1g@mail.gmail.com>
In-Reply-To: <BANLkTikjMZpYm4Maef1wqnmH4RJ02-6t1g@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: Thu, 09 Jun 2011 13:29:14 -0000

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
>