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 >
- [TLS] Final (hopefully) issues with DTLS 1.2 Eric Rescorla
- Re: [TLS] Final (hopefully) issues with DTLS 1.2 Nikos Mavrogiannopoulos
- Re: [TLS] Final (hopefully) issues with DTLS 1.2 Eric Rescorla
- Re: [TLS] Final (hopefully) issues with DTLS 1.2 Nikos Mavrogiannopoulos
- Re: [TLS] Final (hopefully) issues with DTLS 1.2 Eric Rescorla
- Re: [TLS] Final (hopefully) issues with DTLS 1.2 Nikos Mavrogiannopoulos
- Re: [TLS] Final (hopefully) issues with DTLS 1.2 Sean Turner
- Re: [TLS] Final (hopefully) issues with DTLS 1.2 Joe Salowey
- Re: [TLS] Final (hopefully) issues with DTLS 1.2 Eric Rescorla
- Re: [TLS] Final (hopefully) issues with DTLS 1.2 Sean Turner