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

[Viktor Dukhovni <[e-mail]>]

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.