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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 02 February 2020 01:30 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 81CF81201AA for <tls@ietfa.amsl.com>; Sat, 1 Feb 2020 17:30:22 -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 HUHaVklYX6NY for <tls@ietfa.amsl.com>; Sat, 1 Feb 2020 17:30:19 -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 DBC6B120013 for <tls@ietf.org>; Sat, 1 Feb 2020 17:30:17 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id D82D238551; Sat, 1 Feb 2020 20:30:16 -0500 (EST)
Date: Sat, 1 Feb 2020 20:30:16 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20200202013016.GH49778@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <9e4ada20-680e-6fa7-f8bb-e94c26440d82@cs.tcd.ie> <9A5EE7C8-360D-49C0-92F8-274FE1A94249@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9A5EE7C8-360D-49C0-92F8-274FE1A94249@apple.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/scE-wZ_Be5qDarsJJSYTihfBaE4>
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: Sun, 02 Feb 2020 01:30:22 -0000

On Sat, Feb 01, 2020 at 07:53:57AM -0800, Tommy Pauly wrote:

> Instead, it seems unclear what value the special use of 0 and 255 adds
> that wouldn’t be better served by a separate extension.

The benefit of the new value of "0" is *unambiguous* signalling that the
client would like to reuse the ticket if possible, and the new "255"
then carries the "We don't need no stinking tickets" signal.

> Today, without any sentinel values, 0 means the client hints that it
> doesn’t need any tickets, and N means that the client hints that it
> would like N tickets. Whether or not a ticket is intended to be reused
> is not part of this, and ticket reuse is elsewhere discouraged.

And the same remains true with my proposal, with the only difference
being that 0 replaced by 255, and the new 0 as discouraged as it was
before.

Nothing we do or can do prevents a *consenting* client and server from
reusing tickets, no matter what form this extension ultimately takes.

All I'm proposing is a minor change to allow the consent to be
negotiated, rather than guessed unilaterally by the server, likely
incorrectly in various cases.

With negotiated consent, clients that don't want to reuse talking to a
server that supports reuse will get fresh tickets.  Otherwise, they
don't, and end up doing a full handshake 50% of the time.

> As far as I understand the proposal, the meaning currently expressed
> by sending 0 would be expressed by sending 255 instead;

Correct.

> and sending 0 would take on a new meaning that is “send a ticket if
> you want, and I may try to reuse a ticket if you don’t send one”,

Correct.

> which seems like the behavior already expressed by not sending the
> ticket request message at all (since not passing the message is
> equivalent to no hint).

No, it is not, because not sending the extension is status quo, and will
be for quite some time as the extension will not be available to most
clients for quite some time.

Is it your position that once the extension is defined, servers should
assume a desire or willingness to reuse if the extension is not sent?

If the document makes it clear, that *absent* the extension servers that
are *willing* to support reuse SHOULD impute that the client is willing
to reuse (and thus clients that don't reuse need to send the extension
to ensure any fresh tickets on resumption):

    Then indeed the desired signal becomes not sending the extension.

But, that would mean that legacy clients that don't implement the
extension get presumptive reuse (from reuse-supporting servers)
for quite some time as the extension gradually gets adopted.  If
that's OK, then let's specify that.

> To that end, the proposed change doesn’t seem to add any new signaling
> capabilities, but makes the meanings of numbers less intuitive.

Well, it makes the signalling unambiguous, given that without this
extension we presently have no indication of client preference.  If
however, the extension redefines absence of signal to mean willingness
to reuse if the server so chooses, then the ambiguity goes away, and
implementations that support conditional reuse default to reuse on
not receiving the extension.

This makes reuse be "opt-out", rather than "opt-in".  Which may not
be the best way to discourage it, but once the extension is broadly
supported (and enabled by default) the difference starts to fade.

> If the hint is intended to be “I’m planning on reusing tickets, let me
> know ahead of time if I shouldn’t”,

No, the hint is simply "send me a new ticket if I can't (already
expired) or shouln't (will soon expire) reuse what I just sent".

> It seems like there is a small number of clients that would use this,

Just a few million MTAs, on-prem industrial controllers, ...

> For example, if we add the proposed hint that presumably means “if you
> give me a new ticket, I’ll use it; but if you don’t, I’ll reuse an old
> one”, the client is essentially forcing a server that doesn’t want
> ticket reuse to issue a new ticket

No.  Clients can attempt reuse no matter what the server does, but
they SHOULD use any fresh ticket from the server because the server
may no longer accept the old one.  With or without this extension
a server that does not want reuse should vend a fresh ticket unless
it knows that the client does not to resumption at all (255 or 0,
wherever the chips fall).

> whereas a more explicit signal could indicate that the server won’t
> allow ticket reuse, so the client shouldn’t even try, etc, without
> necessarily giving out new tickets. 

Well, that's a completely different server->client signal, saying "don't
reuse", and does not replace the proposed "client->server" signal.  But
it makes no sense for servers to refuse reuse and also not vend fresh
tickets, unless they simply don't support resumption and never vend
tickets in the first place (in which case no such signal is needed).

Therefore the way to indicate that a ticket is no longer valid is to
issue a replacement ticket (possibly after performing a full handshake
to revalidate the client cert, if the session is too old).  This
largely obviates any need for a server->client signal.

A server can also always refuse old tickets (but that requires keeping
track of sufficiently recently used tickets).

Above I said "largely obviates", because a client making parallel
connections might race to reuse a ticket in parallel before any
of the parallel connections return a fresh ticket.

Therefore, a signal from server to client meaning "my tickets
are single-use" is potentially useful.  If so, it should be
in the server variant (response) of this extension.

-- 
    Viktor.