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

Viktor Dukhovni <> Tue, 21 January 2020 09:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C572B1200B3 for <>; Tue, 21 Jan 2020 01:16:20 -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 bpfOAoDdLZOs for <>; Tue, 21 Jan 2020 01:16:19 -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 1332E12008D for <>; Tue, 21 Jan 2020 01:16:19 -0800 (PST)
Received: by (Postfix, from userid 1001) id 0D3E849144; Tue, 21 Jan 2020 04:16:18 -0500 (EST)
Date: Tue, 21 Jan 2020 04:16:18 -0500
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
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: Tue, 21 Jan 2020 09:16:21 -0000

On Tue, Jan 21, 2020 at 07:57:27PM +1100, Martin Thomson wrote:

> On Tue, Jan 21, 2020, at 16:54, Viktor Dukhovni wrote:
> > There's no need to exclude valid use-cases.  The refined proposal
> > is rather non-invasive, and handles this case cost-effectively
> > on clients that re-use tickets (and don't use early-data, ...).
> I don't find your arguments persuasive.  This adds complexity
> specifically to address a case that has - in the general case -
> suboptimal characteristics, both in terms of forward secrecy and
> linkability.  Whether or not there are specific cases that might
> tolerate these suboptimalities, the complexity and risks are borne by
> everyone.

    * Switching to a new ticket is of no help if the server is still
      using the same STEK.  Any forward-secrecy concerns are a function
      of the frequency of STEK rotation on the server.

    * We work in noticeably different application spaces.  SMTP client
      MTAs send 220 greetings and EHLO commands identifying themselves
      in the clear prior to the STARTTLS handshake.  MTAs don't roam
      from network to network, and linkability of traffic is not a

    * Postfix, for example, rotates STEKs by default once an hour,
      making the forward-secrecy exposure quite limited. 

    * Clients don't use the same ticket indefinitely, they too discard
      stale tickets, if the server does not beat them to it.

The requested change is rather minimal, it merely asks the server to
intepret 0 as "optional ticket" rather than "no ticket" reserving the
last code point (not uncommon to have make it special) as a no-go

Even if the proposal is not compelling for some, it allows additional
legitimate use-cases at negligible cost.  So barring some actual
problem, it is hard to see on what basis it can be reasonably excluded. 

That's all from me.  Thanks.