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

Viktor Dukhovni <> Fri, 31 January 2020 22:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8DCC12004F for <>; Fri, 31 Jan 2020 14:27:18 -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 r2FBLxCB3Jom for <>; Fri, 31 Jan 2020 14:27:17 -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 5F65912002E for <>; Fri, 31 Jan 2020 14:27:17 -0800 (PST)
Received: by (Postfix, from userid 1001) id A140F3687D; Fri, 31 Jan 2020 17:27:16 -0500 (EST)
Date: Fri, 31 Jan 2020 17:27:16 -0500
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <20200123005528.GA12073@localhost> <> <> <> <> <> <20200123193250.GD12073@localhost> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.2 (2019-09-21)
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: Fri, 31 Jan 2020 22:27:19 -0000

On Fri, Jan 31, 2020 at 09:06:12AM -0800, Tommy Pauly wrote:

> However, for the purposes of the WGLC for this draft,
> draft-ietf-tls-ticketrequests, it may be best to separate the
> conversation. It seems that the negotiation of ticket reuse would be
> best served by another document that could be adopted by the WG. The
> ticket request document, as it was adopted, was specifically a
> mechanism to request multiple tickets so as to *avoid* ticket reuse.

Yes, but the issues DO NOT decouple.  It is a mechanism to communicate
the client's ticket requirements to the server.  Many clients will
want multiple tickets unconditionally, some will want none, or only
one as the presented one becomes no longer valid.

The use-case is that the Postfix SMTP server currently always vends
replacement tickets ONLY when expiring.  I'd like to be able to
distinguish between clients that always want fresh tickcets (MUAs)
and clients that don't (MTAs).  This will also reduce ticket reuse.

> This is stated several times in the use cases (section 2) and security
> considerations (section 5). While this does not preclude a future
> extension that negotiates ticket reuse, I believe, as an author, that
> enabling ticket reuse is out of scope of this particular document.

The two extensions will be in conflict.  There's a trivial solution
within the existing extension.  One code of 255 fully addresses the
issue, with no additional document required.

Proliferation of conflicting documents does not help implementors.
Let's address the issue before us in a single document.  Reuse
is not a separate issue, both are just ticket quantity negotiation.