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

Tommy Pauly <> Sat, 01 February 2020 01:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B119120074 for <>; Fri, 31 Jan 2020 17:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6-J5OLVC03JV for <>; Fri, 31 Jan 2020 17:53:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8006B120024 for <>; Fri, 31 Jan 2020 17:53:58 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 0111qBUY051757 for <>; Fri, 31 Jan 2020 17:53:56 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=2EsSjlPljxWP7iSVAMcTISsMEkf4xQK0xWSL8HAh628=; b=k3hZX/ddc+sVTPA9DVmNWB6UOOttiUe8vFgH7cEJ3AyTJGo/4gzW6TJtYzNHKtTie7me MqeKOIQy8PkTE+bI4iAIaFUyK5nUuMnXAfb/WCVrvrlF9SjIoq7MRsxx3b7Qn8Z4An6G GNk/BAAhpB3kHLNuAbzMdWGRmbE4xv40+JwebBWzUmgWCgCaxMtoDgGq8sF35ZwpUNo2 pJu8bKo/mYE4SAJ0kHrC1wq1z3Hq9E/5BwEs78tULNUtlL5YJY3mz1roCrrSSqe5FnKP NkeZT3SLQcbF1cPIx0MzK6zAxIkhX3lwXGE12VYTNup9u3yYR7N2z96UQrG8lMaBckiM Xw==
Received: from ( []) by with ESMTP id 2xrnj3n29q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <>; Fri, 31 Jan 2020 17:53:56 -0800
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Jul 4 2019)) with ESMTPS id <> for; Fri, 31 Jan 2020 17:53:55 -0800 (PST)
Received: from by (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <> for; Fri, 31 Jan 2020 17:53:54 -0800 (PST)
X-Va-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2
X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-Va-CD: 0
X-Va-ID: f2449301-87b0-4504-8eba-82e152537ec7
X-V-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2
X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-V-CD: 0
X-V-ID: f9786c27-4620-4798-8909-082ce00af532
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-31_07:,, signatures=0
Received: from [] by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <> for; Fri, 31 Jan 2020 17:53:54 -0800 (PST)
From: Tommy Pauly <>
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Date: Fri, 31 Jan 2020 17:53:50 -0800
References: <> <> <> <> <> <20200123193250.GD12073@localhost> <> <> <20200131235533.GA18021@localhost> <> <20200201011115.GB18021@localhost> <> <>
In-reply-to: <>
Message-id: <>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-31_07:, , signatures=0
Archived-At: <>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 Feb 2020 01:54:00 -0000

Hi Viktor,

> On Jan 31, 2020, at 5:24 PM, Viktor Dukhovni <> wrote:
>> On Jan 31, 2020, at 8:15 PM, Rob Sayre <> 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.

The document also is focused on use cases that are all about "avoid[ing] ticket re-use". The security considerations state that "Ticket re-use is a security and privacy concern".

While there are some use cases in which ticket re-use allows the reduction of ticket waste, we cannot state that every possible approach to reduce ticket waste is in scope for this particular document. Rather, this document defines its scope as simply: "This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections." Enabling ticket reuse is not part of that scope.

Beyond discussing scope creep, I think an even bigger reason to decouple the idea of ticket requests from explicit ticket re-use is the notion of working group consensus. I think the WG has clearly expressed consensus on the fact that ticket requests are a useful and non-harmful extension. Indeed, the proposals to add ticket reuse logic to ticket requests that you want relies on such an extension. However, the group certainly does not seem to have consensus on the idea that there should be an extension to allow ticket reuse. As an author, I don't know if I'd support that. Thus, the working group can progress with the tightly-scoped document that it has consensus on, and leave other use cases to future documents.

> -- 
> 	Viktor.
> _______________________________________________
> TLS mailing list