Re: [TLS] implementation of cookies in DTLS

Nikos Mavrogiannopoulos <nmav@gnutls.org> Tue, 15 March 2011 10:01 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E453A6C6E for <tls@core3.amsl.com>; Tue, 15 Mar 2011 03:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsyrEEv5wEDO for <tls@core3.amsl.com>; Tue, 15 Mar 2011 03:01:39 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id F11AA3A69E3 for <tls@ietf.org>; Tue, 15 Mar 2011 03:01:38 -0700 (PDT)
Received: by qyk7 with SMTP id 7so316617qyk.10 for <tls@ietf.org>; Tue, 15 Mar 2011 03:03:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SH+NaW7i+XfMFrBuXRG8Ieffdsa+ArdN0hqjCGMIx4U=; b=cUXj1naHBfQwiHD45X4CJOJNcIuUk+C4V/uPVbsFUuIWWAmvnXiEFJ+uKBVtsbPE96 jUtNk+utLAEUKIY1OWCDzKr389ljm1eX2Pk1hoC55ft2hRT9g3412JY3szAyXzCSs0mW gP2jFbQ9QrcKDbCCKaiz1/0uFOdyNxVQ2RVGQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=KdvpuJWnYTI9apYOjPfet40c7+uaAE71V0IYbxErBKN0TENksJcOfoua3PCipt+smL mSHdgiDTJqYNVKjZoArDmj4DjN3nBFIO2ZxtbK6FvMKZCsWOItifxWYwTUnPVeRplalS A3O8/hXvTCz4ZAbzLlGEwNBfT/ewSLmQ9UzOA=
MIME-Version: 1.0
Received: by 10.229.122.131 with SMTP id l3mr4058067qcr.124.1300183168427; Tue, 15 Mar 2011 02:59:28 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.220.140 with HTTP; Tue, 15 Mar 2011 02:59:28 -0700 (PDT)
In-Reply-To: <AANLkTimUWvrzb-JuHbsX3sRFo=EYP_BCYKiQRBOpveEP@mail.gmail.com>
References: <4D7D0292.7080700@gnutls.org> <CC864D93-07CA-4381-8C7A-CB263A3CA7DA@fh-muenster.de> <4D7E3487.7090805@gnutls.org> <40048296-255C-4DBF-A1B0-3E18721EE710@fh-muenster.de> <5ED7449A-546E-4457-861E-D780A117FD5A@fh-muenster.de> <A28CA8BD-3C30-4D4A-9DD9-05A0FA1574E3@lurchi.franken.de> <FDF29FE9-F64F-42AE-B885-7F3B64E3424D@fh-muenster.de> <B62B9484-F16A-405C-A943-504ADB6D572F@lurchi.franken.de> <6E372B69-4A29-4664-910B-35665760C7E2@fh-muenster.de> <DE5FC70F-9E17-4595-9162-CFC70457EEDF@lurchi.franken.de> <AANLkTikpbA5wgxOEhLH95ojBzAXAZOr9ZUGvXjMUGR9H@mail.gmail.com> <5A4D85EB-BBBC-4854-B661-808C512668DA@lurchi.franken.de> <AANLkTimUWvrzb-JuHbsX3sRFo=EYP_BCYKiQRBOpveEP@mail.gmail.com>
Date: Tue, 15 Mar 2011 10:59:28 +0100
X-Google-Sender-Auth: P0f5TRFs_FWdhnAy_nkPOg1P2Pw
Message-ID: <AANLkTi=+5VOYNp4w8jV7G-oTOufm0jZRVVGcyz9MMObR@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] implementation of cookies in DTLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Tue, 15 Mar 2011 10:01:39 -0000

On Tue, Mar 15, 2011 at 12:37 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> I suspect either reflecting or the special case would work. I'm trying
> to get all the other
> changes in before the deadline so I'll leave it with =0 and the
> special case and an
> open issue marker and let's just resolve in Prague.

I will not be there but I'd like to make these points:
1. Define precisely the behavior of initial pre-handshake before state
is allocated. My opinion is that I don't like special cases such as
use 0 always
and do not case about re-use because they are more likely to introduce
bugs and new attacks. Copying the client's numbers should solve the
issue with no special cases and no state. Also I suppose that if
handshake_seq=0 is used for HelloVerifyRequest then handshake_seq=1
should be used for ServerHello and this should be clear as well to
avoid having another special case.

2. Drop requirement: 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.
This will create incompatibilities when more than 1 DTLS protocols are
implemented
in a single client or server. It is not really possible for a server
to do an emulation of
the decisions it would do as if a state existed. What are the reasons for this
requirement?

regards,
Nikos