Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

Viktor Dukhovni <> Fri, 11 October 2019 21:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60399120805 for <>; Fri, 11 Oct 2019 14:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.865
X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ck_ORmnjZlFP for <>; Fri, 11 Oct 2019 14:35:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C8B4120816 for <>; Fri, 11 Oct 2019 14:35:05 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id EAFC92B6D07 for <>; Fri, 11 Oct 2019 17:35:03 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Fri, 11 Oct 2019 17:35:03 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: IETF TLS WG <>
Message-Id: <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
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, 11 Oct 2019 21:35:18 -0000

> On Oct 11, 2019, at 4:55 AM, Martin Thomson <> wrote:
> Yeah, I agree that this is a little thorny.  However, the client asking for one extra and the server vending one more is a relatively small extra expense AND we discourage reuse in the general case.  So, at least from my perspective, this isn't that serious a problem and shouldn't block publication.

In Postfix, multiple SMTP client processes share a 1 slot external
session ticket cache, and expect to re-use tickets until a new one
is issued by the server.  This works poorly with servers that don't
allow re-use, and updating the cache on each connection is rather
wasteful on both ends.

Presently, the Postfix SMTP server assumes clients of the same kind,
and always only issues new tickets *as-needed*.  If clients could
signal their real requirements, that policy would no longer need
to be hard-coded, it would just become a default for clients that
don't send this extension.

Perhaps the solution is to say that clients that don't send the
extension get default application-specific behaviour, possibly
"refresh only as-needed".  If they prefer to always get a specific
number of tickets, they can request that number.

Then I guess I could attempt to honour the extension, and revert
to default behaviour in its absence, making sure that the Postfix
SMTP client either does not ask to send the extension, or invokes
some appropriate OpenSSL interface to ask that it not be sent as