IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 01 February 2020 01:24 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 8E50812002E for <tls@ietfa.amsl.com>; Fri, 31 Jan 2020 17:24:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 zCFTGT8DamCy for <tls@ietfa.amsl.com>; Fri, 31 Jan 2020 17:24:26 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499D1120020 for <tls@ietf.org>; Fri, 31 Jan 2020 17:24:26 -0800 (PST)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 98A25368E3 for <tls@ietf.org>; Fri, 31 Jan 2020 20:24:25 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAChr6SywucrTUsAeN6Aw26ufmhcB8txAmFVNGnUaeR3gG653VQ@mail.gmail.com>
Date: Fri, 31 Jan 2020 20:24:24 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: IETF TLS WG <tls@ietf.org>
Message-Id: <4E7DC6E9-A04E-4016-A12A-CFC723E18219@dukhovni.org>
References: <CAN2QdAH7t4fPgBfBSO7Ni1As2bVB9QvCw1s9j0ggqvTRUATE8A@mail.gmail.com> <20200123021455.GA73491@straasha.imrryr.org> <87427017-551e-4633-a0d3-75f378879aa9@redhat.com> <20200123124055.GF73491@straasha.imrryr.org> <CACsn0cngxBQTB+Pfw6t_+qsSFb0Kf8mV1U1J1UTsPJiUk=vg0w@mail.gmail.com> <20200123193250.GD12073@localhost> <20200123210151.GG73491@straasha.imrryr.org> <5F5F670C-A0BD-4F38-BEFF-192C171EDAC1@apple.com> <20200131235533.GA18021@localhost> <CAChr6Sz6PEgQUQg8dB9Ym0z5_iRjmZE5g1hUCCgEOsA-7A=P-w@mail.gmail.com> <20200201011115.GB18021@localhost> <CAChr6SywucrTUsAeN6Aw26ufmhcB8txAmFVNGnUaeR3gG653VQ@mail.gmail.com>
To: IETF TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SDQi0ev_u522cZRGEqAiZAdw-Oc>
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: Sat, 01 Feb 2020 01:24:28 -0000

> On Jan 31, 2020, at 8:15 PM, Rob Sayre <sayrer@gmail.com> wrote:
> 
> If the scope of a document can be continually expanded during last call, it can be indefinitely postponed.

I'm not proposing a change of scope.  The document specifies how a client
and server negotiate the number of tickets the server should send.  This
remains the case.  The -04 document leaves out a relevant scenario where
the client does want tickets to be refreshed (so not unconditionally zero),
but does not want gratuitous tickets (new one each time).

The scope of the document per the abstract includes the following:

   This extension aims to provide a means for
   servers to determine the number of tickets to generate in order to
   reduce ticket waste, while simultaneously priming clients for future
   connection attempts

My proposal falls squarely in the "in order to reduce ticket waste" category.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email