Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Daniel Migault <daniel.migault@ericsson.com> Tue, 19 November 2019 09:20 UTC

Return-Path: <mglt.ietf@gmail.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 71C6F12089B for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 01:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.405
X-Spam-Level:
X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN9IofPGz0lq for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 01:20:43 -0800 (PST)
Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EA21208D8 for <tls@ietf.org>; Tue, 19 Nov 2019 01:20:16 -0800 (PST)
Received: by mail-vs1-f44.google.com with SMTP id m9so13714533vsq.7 for <tls@ietf.org>; Tue, 19 Nov 2019 01:20:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IYZmEnGepBRO0VX8548IH1b2vVK6on0wNGxT/DnCviM=; b=M194MnFMUfE6/QMawtrhnN5kv1q2L1ovfgCJ1WtLkUr9wl0QK5Pvc0ur0i+2o0ruf0 W+RPoz9EKPT+eB9x/pDC5otj4ZkxQsomGihEx1+u2uJX6FsLnydm1Scnli0hVCbmF6fL eQcdETr7yzCHEdGhqkiwacrmKG215FY9dyiJAh2xGLzI7fHkzVTndrPF658eqcEh9nR3 GFYjDIWKdVPCLz1G1nV4R08Z5jcvqjHHQMoTDOh6kMAw4pLBCPhy8/GGlOKQE+70j8UR RtkPOwGJ8yD9TEotK4nlcKSHSOBNdd7bUAbGlTQPdrvYvC9FEB9i5W5bd1mxDjYbBgxd fOXQ==
X-Gm-Message-State: APjAAAUiEehZH+SFEr7vXv2GZD6xcnEmcV3JU0CvAUegQBkEvgDjG4G+ aNMryBU7ADPFK2Hu3ovXT2u/orysYFZO7UXPu0fXS1fd
X-Google-Smtp-Source: APXvYqwms/MkXcV3NdVP79Y/XgQMrbeYfdtBY9Q74NSxm1uL9lgCkwto/GuTAjqkzjJXvcH2e7MF8KYLgWsAWVgqYsc=
X-Received: by 2002:a67:fd53:: with SMTP id g19mr11045344vsr.169.1574155214971; Tue, 19 Nov 2019 01:20:14 -0800 (PST)
MIME-Version: 1.0
References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <caa6f6b4-537c-46bb-a04b-28d2b59f8ecd@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org>
In-Reply-To: <20191117002249.GV34850@straasha.imrryr.org>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 19 Nov 2019 17:20:03 +0800
Message-ID: <CADZyTkmaUVj=sFdgg93MuM2au0B=1M1k3yCA1XDoaAneVDmnNw@mail.gmail.com>
To: tls <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000068e98c0597af9253"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RxyQF8NmadWl9rXpzqzGe0tGzsU>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 19 Nov 2019 09:20:47 -0000

Hi,

Just to followup the discussion. I support Viktor,'s proposal as it
provides the ability to the client to specify what it wants rather than let
the server guess. What I am wondering is whether we are catching all
possible client "policies" or whether we should consider some additional
reserved values. Typically I do not see case where 200 tickets may be
requested, so we may have some place for reserved bits if needed.

I see my comment of how tickets are generated as complementary.

Yours,
Daniel



On Sun, Nov 17, 2019 at 8:23 AM Viktor Dukhovni <ietf-dane@dukhovni.org>;
wrote:

> On Sat, Nov 16, 2019 at 03:59:53PM -0800, Benjamin Kaduk wrote:
>
> > > That also works, effectively treat 0xff as "-1", but all other
> > > values as non-negative, with 0 a request for re-use.  An isomorphic
> > > encoding, but without the "-1".
> >
> > [Jeremy had a more eloquent description of the vague sketch of an idea
> that I had in my head]
>
> Jeremy's "isomorphic" encoding works fine for me, and is likely less
> confusing.
> So, FWIW, it has my support.  Fleshing it out a bit more, I am proposing:
>
>     - 0xff => send no tickets
>
>     - 0x00 => reuse requested:
>         + send no tickets if presented ticket is accepted and reusable
>         + send one ticket if presented ticket is accepted, but is not
> reusable
>           (expired, or reuse is not allowed).
>         + Also send one ticket if session could not be resumed and a full
>           handshake was performed.  Clients that reuse tickets don't need a
>           separate one for each session, so one per full handshake should
>           suffice.
>
>     - 0x01-0xfe => client wants single-use tickets:
>         + send up to that many tickets on full handshake,
>         + however, generally send just 1 ticket on resumption, or when
>           replacing tickets during long-lived connections.  This helps to
>           reduce chronic ticket "oversupply".
>
> --
>     Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>