Subject: [TLS] Ticket request PR#20

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 19 Apr 2020 18:23:18 -0400

I uploaded a small pull request for the ticket request draft:

    https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/20

it stipulates that servers SHOULD send at least one ticket unless *both*
counters are zero.  A client willing to accept tickets for either of the
two handshake types is capable of accepting a ticket for the other.

Yes, this leaves the door open to later define (or not) special
semantics for the zero value to be used between mutually consenting
clients and servers.

-- 
    Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Apr 2020 15:41:49 -0700

I don't think we should make this change. In the context of this draft, if
the client wants that behavior, it should send {1, 1}.

-Ekr

On Sun, Apr 19, 2020 at 3:23 PM Viktor Dukhovni <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 19 Apr 2020 19:06:23 -0400

> the client wants that behavior, it should send {1, 1}.

That precludes clients from soliciting 0 *only* from servers that
support some future specification, and otherwise getting 1 from
servers that support only the current specification.

Such clients are not looking for a static server behaviour, but
rather need only certain servers to return 0, and the rest
to return 1.

In any case, if sending 1 or more unconditionally was fine for RFC8446
(e.g. per the text in C.4) it is hard to imagine why it is suddenly so
important to insist that the server be able to send 0 when receiving
{1, 0} or {0, 1}.

Servers that don't support this new extension at all will send 1 (or
more).  So it is clearly not a big deal also for servers that do
support it to do likewise.

Since there is no specific *use-case* for {1, 0} to mean 0 at present,
that couldn't also be handled by sending {0, 0}, there is no reason
to stand in the way of defining {1, 0} to be a solicitation for at
least 1 ticket regardless of the handshake type.

The only objection that makes sense is a blocking tactic to preclude
potential future refinement of this draft to support reuse, but surely
blocking that evolution can be deferred to the discussion of the
(misguided?) I-D that proposes it.

-- 
    Viktor.

---

From: Nick Harper <[email-masked]>
Date: Mon, 20 Apr 2020 12:18:28 -0700

> servers that support only the current specification.

That's not true. Suppose there's some future specification FOOBAR that a
client and server might support, and the client wants a resumption_count of
0 when the server supports FOOBAR and 1 if the server doesn't support
FOOBAR. The apparent problem is that the client doesn't know whether the
server supports FOOBAR when it writes its resumption_count value. It's true
that the client doesn't know whether the server supports FOOBAR on its
first connection to the server, but on that connection, the value of
resumption_count is irrelevant. On future connections, the client can
condition resumption_count based on whether FOOBAR was supported on the
connection that the resumption ticket came from.

> (misguided?) I-D that proposes it.

My take on this PR is that it unnecessarily complicates the
ticketrequest draft. As currently specified, the two values do what they
say on the tin; with this PR there's an extra weird edge case. This
complication is unnecessary based on my above description of how the FOOBAR
spec can extend it.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Apr 2020 15:28:41 -0400

> connection that the resumption ticket came from.

Yes, that mostly works, but it will require a second extension (which
would otherwise not be needed), and assumes that the *same* server
software is doing the resumption as issued the initial ticket.  That'll
generally be true I guess, but is not guaranteed.  In a load-balanced
pool of servers, support for FOOBAR may not be universal.

> ticketrequest draft. As currently specified, the two values do what
> they say on the tin; with this PR there's an extra weird edge case.
> This complication is unnecessary based on my above description of how
> the FOOBAR spec can extend it.

The "complexity" involved is exceedingly minimal, and introducing a
second extension FOOBAR to modify the meaning of this extension is
rather more complex.  I'd like to have an opportunity to propose
a later refinement of this specication to give a new meaning for
{1,0} in this extension, without requiring any new FOOBAR extension.

So my hope is that the case for {1,0} -> 0 tickets on resumption is
rather weak, and {1,0} -> 1 is cheap enough to make it a reasonable
compromise.

-- 
    Viktor.