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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 23 January 2020 21:01 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C3C120842 for <tls@ietfa.amsl.com>; Thu, 23 Jan 2020 13:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X4014XX7oVL for <tls@ietfa.amsl.com>; Thu, 23 Jan 2020 13:01:54 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3EF120823 for <tls@ietf.org>; Thu, 23 Jan 2020 13:01:52 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 83D054B6EB; Thu, 23 Jan 2020 16:01:51 -0500 (EST)
Date: Thu, 23 Jan 2020 16:01:51 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20200123210151.GG73491@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <97de6364-c628-45aa-8613-ba1a32cc41b2@www.fastmail.com> <A5448AC9-6EBB-48F9-A1B0-A787FBBCFF05@akamai.com> <08A4B0CD-9903-4027-B672-E8C7AFB34B4D@akamai.com> <20200123005528.GA12073@localhost> <CAN2QdAH7t4fPgBfBSO7Ni1As2bVB9QvCw1s9j0ggqvTRUATE8A@mail.gmail.com> <20200123021455.GA73491@straasha.imrryr.org> <87427017-551e-4633-a0d3-75f378879aa9@redhat.com> <20200123124055.GF73491@straasha.imrryr.org> <CACsn0cngxBQTB+Pfw6t_+qsSFb0Kf8mV1U1J1UTsPJiUk=vg0w@mail.gmail.com> <20200123193250.GD12073@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200123193250.GD12073@localhost>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1YqMLtTXzNdpzPlQ0Cx55mvIaJE>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 21:01:56 -0000

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.