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

Viktor Dukhovni <> Sat, 01 February 2020 02:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7390120045 for <>; Fri, 31 Jan 2020 18:07:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ePJ9SJ8OyJgS for <>; Fri, 31 Jan 2020 18:06:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5E8E120024 for <>; Fri, 31 Jan 2020 18:06:59 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7778A36C38 for <>; Fri, 31 Jan 2020 21:06:58 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Fri, 31 Jan 2020 21:06:57 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: IETF TLS WG <>
Message-Id: <>
References: <> <> <> <> <> <20200123193250.GD12073@localhost> <> <> <20200131235533.GA18021@localhost> <> <20200201011115.GB18021@localhost> <> <> <>
X-Mailer: Apple Mail (2.3608.
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 02:07:03 -0000

> On Jan 31, 2020, at 8:53 PM, Tommy Pauly <> wrote:
> Thus, the working group can progress with the tightly-scoped document that it has consensus on, and leave other use cases to future documents.

Such a deferral may be desirable and viable in cases where the
features are sufficiently orthogonal.  But here the extension
specifies the number of requested tickets, and so any separate
document would have to change the semantics of this extension
in order to get conditional issuance of tickets.

It makes no sense to split the negotiation of the ticket number
over multiple documents.  The added use-case is effectively
*free* to ignore by implementations that never want reuse,
just treat zero as 1, and be done.

If this were a major burdensome feature, I'd be sympathetic to
your desire to carve it out to a separate discussion.  But here,
I'm pretty consensus will be reached soon after we stop focusing
on the legitimacy or timing of the proposal and focus on its
substance in a final wrap-up consensus call.

I may end up in the rough, but let's at least see where the chips

The security considerations can continue to discourage reuse where
traffic analysis is a concern.  It is NOT a concern in MTA-to-MTA
traffic.  If my proposal moves forward, I'll gladly contribute
some text to the security considerations discouraging wanton
application of ticket reuse.  It should be enabled only where

Note that I'd like to use this extension to conditionally enable
non-reuse where presently re-use is unconditional.  Otherwise,
Postfix will just always go with reuse.