Re: [TLS] Final (hopefully) issues with DTLS 1.2
Eric Rescorla <ekr@rtfm.com> Mon, 04 July 2011 00:58 UTC
Return-Path: <ekr@rtfm.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 04E229E8007 for <tls@ietfa.amsl.com>; Sun, 3 Jul 2011 17:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 otsxkriZmZYx for <tls@ietfa.amsl.com>; Sun, 3 Jul 2011 17:58:06 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 574851F0C3C for <tls@ietf.org>; Sun, 3 Jul 2011 17:58:02 -0700 (PDT)
Received: by wwe5 with SMTP id 5so3110510wwe.13 for <tls@ietf.org>; Sun, 03 Jul 2011 17:58:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.1.197 with SMTP id n47mr822734wes.28.1309741081231; Sun, 03 Jul 2011 17:58:01 -0700 (PDT)
Received: by 10.216.175.204 with HTTP; Sun, 3 Jul 2011 17:58:01 -0700 (PDT)
In-Reply-To: <9ACC73EC-6834-465B-A5DD-A0DFAE80BD40@cisco.com>
References: <BANLkTikjMZpYm4Maef1wqnmH4RJ02-6t1g@mail.gmail.com> <4DF0CA9D.1030006@ieca.com> <9ACC73EC-6834-465B-A5DD-A0DFAE80BD40@cisco.com>
Date: Sun, 03 Jul 2011 17:58:01 -0700
Message-ID: <CABcZeBMg9JfCLr4bAGnNm_6My8CtONsoOnjzioRf3ByQ1udrOw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Joe Salowey <jsalowey@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org
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 00:58:07 -0000
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 >
- [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