IETF Logo Mail Archive

Re: [TLS] implementation of cookies in DTLS

Nikos Mavrogiannopoulos <nmav@gnutls.org> Tue, 15 March 2011 09:36 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 606373A6C19 for <tls@core3.amsl.com>; Tue, 15 Mar 2011 02:36:57 -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=[AWL=-0.000, 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 3KSLbyEdb1-i for <tls@core3.amsl.com>; Tue, 15 Mar 2011 02:36:54 -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 586793A6C0D for <tls@ietf.org>; Tue, 15 Mar 2011 02:36:54 -0700 (PDT)
Received: by qyk7 with SMTP id 7so301118qyk.10 for <tls@ietf.org>; Tue, 15 Mar 2011 02:38:18 -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=/L9FXRx+x+BaLADiQtXPS3XmM9aS9qa6g4oOluLNOj4=; b=o7SM5KIJjk7Sue2UDTApWrIBaw8WMtvmiNv527AWS15yX0nz5QGlnpfOZkq+jT9GdL B/7kHAyT5hU8Q4pwqomccYKQC76sdy24j8xlg3t0FUUwebvfCiSbfWjAnO7eQHEi2ysl mXzMl/mOMS0hjrYnvAE5w0nxpV6/vbYcPHzic=
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=UruwJPpdCkwKP9CXX+dA6w/7XQX9gOIF/VF39wqoDMa8U29D2V9YWkBgXVDUAxytTG nd93QLNWb49OW2P6R04i/dG0pVLNnqzAhrq7+SgNekn5sfFd48/21HEyo7aWwxb3LOOK u+y6GE7+jTASFRNmK57R6OJco0B7/2gwKZR+A=
MIME-Version: 1.0
Received: by 10.229.111.194 with SMTP id t2mr10923227qcp.48.1300181898723; Tue, 15 Mar 2011 02:38:18 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.220.140 with HTTP; Tue, 15 Mar 2011 02:38:18 -0700 (PDT)
In-Reply-To: <AANLkTikpbA5wgxOEhLH95ojBzAXAZOr9ZUGvXjMUGR9H@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>
Date: Tue, 15 Mar 2011 10:38:18 +0100
X-Google-Sender-Auth: VVYL-ZvvP-pIWX26pgAPJL50Cps
Message-ID: <AANLkTinafWfj_qGdw9XsfwVEf5b=N09eqKyXCefWF7WA@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 09:36:57 -0000

On Tue, Mar 15, 2011 at 12:27 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> FWIW, I believe the correct answer is that the server should always use
> sequence number 0 for HelloVerifyRequest, and that clients should not do
> duplicate suppression during the initial handshake. I agree it's a
> tiny bit clunky,
> but IMO it's the best option.

I can see that using handshake_seq of 0 for HelloVerifyRequest is a
good option, but using 0 for record_seq requires a special handling of
those records and thus extra complexity. The reflection method has
no requirements from the record layer, thus I'd prefer that unless
there are implications of course.

regards,
Nikos

v2.23.0 | Report a Bug | By Email