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

Tommy Pauly <> Fri, 31 January 2020 17:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 960B0120982 for <>; Fri, 31 Jan 2020 09:06:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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, URIBL_BLOCKED=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 SH3t-QCUofxv for <>; Fri, 31 Jan 2020 09:06:17 -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 9FC0D1209A2 for <>; Fri, 31 Jan 2020 09:06:17 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 00VH2spx027557 for <>; Fri, 31 Jan 2020 09:06:17 -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=zdBWgY5KLVLZqx8zbAwgmbhVyhybhY0l/cQf95+wsXI=; b=DpAD2HwKzmODgwl7Q9mKqXkeuX5hdd2Er/uxcPG4fzGdjj5XNagzoOLU5YnnbCMR/PZD WKEsg5ZT6mCTWluuNFz/jk59V/a06OiFBVPilNf8M/qZGq4gm+/AHT17fyKUM/0GvwEZ 9F7zCljoWxm4gljzhsmgwXeKmNnrpucKE6ZIih13CuuOzYoJnpHLz2DqFbztToyqPAUm e4B45019FJ4CsiT666Ib63tSWCMVUYMeqkKTeH0MHX47F1yBnFOlKtxiGpX9oDE3NAU4 v1rPK45dZ3cFwhV5UwbkcStL0/lfyjd4t/qwnKbAlNYf2RJLwm+gZ3SQWtHLrfmNi38p kw==
Received: from ( []) by with ESMTP id 2xs6srqs58-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <>; Fri, 31 Jan 2020 09:06:17 -0800
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Jul 4 2019)) with ESMTPS id <> for; Fri, 31 Jan 2020 09:06:17 -0800 (PST)
Received: from by (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <> for; Fri, 31 Jan 2020 09:06:17 -0800 (PST)
X-Va-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2
X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-Va-CD: 0
X-Va-ID: 2f195843-dbcd-4495-ac5e-bf111dddad10
X-V-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2
X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-V-CD: 0
X-V-ID: c3b181ed-b65a-42dd-a295-6f5aaf5ff45f
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-31_04:,, signatures=0
Received: from [] by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <> for; Fri, 31 Jan 2020 09:06:17 -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 09:06:12 -0800
References: <> <> <> <20200123005528.GA12073@localhost> <> <> <> <> <> <20200123193250.GD12073@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_04:, , 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: Fri, 31 Jan 2020 17:06:20 -0000

First off, thanks for the lively discussion on ticket reuse! I think it's a valid use case and something that should continue to be discussed.

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. 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.


> On Jan 23, 2020, at 1:01 PM, Viktor Dukhovni <> wrote:
> On Thu, Jan 23, 2020 at 01:32:51PM -0600, Nico Williams wrote:
>> On Thu, Jan 23, 2020 at 09:43:21AM -0800, Watson Ladd wrote:
>>> Sending a new ticket doesn't force clients to store it.
>> Sure, but if the old ticket will not be accepted again then the client
>> will incur a full handshake later.  The client doesn't know if the old
>> ticket will or will not be accepted again.  Extending the protocol to
>> have the server signal that bit will require new OpenSSL extensions,
>> which is why that is not a sufficiently good response to the Postfix
>> issue.
> Indeed, not storing the ticket breaks resumption.  So I always store the
> ticket (actually what OpenSSL hands me is a serializable opaque
> SSL_SESSION).  For example, when the server allows reuse, but has a
> shorter maximum ticket lifetime, its "as needed" new ticket needs to be
> stored, in order to replace a stale cached session and start using the
> fresh one.
> Regardless, I also believe that not applications need or want the
> marginal privacy offered by single-use tickets (none for clients
> with stable dedicated IP addresses) and it should be possible
> in such cases (at effectively zero cost as proposed) to negotiate
> reuse in a way that allows servers to handle both types of client.
> This would allow Postfix to vend single-use tickets to clients
> that request that (e.g. MUAs).  Right now the code is statically
> optimized for the MTA-to-MTA use-case.
> So making reuse *negotiable* would in fact enhance privacy for MUAs on
> ephemeral IPs sending sufficiently frequent email (from behind a NAT or
> otherwise shared or changing address) to a sufficiently popular
> submission server that it is not trivial to link resumed TLS sessions to
> a given client.
> -- 
>    Viktor.
> _______________________________________________
> TLS mailing list