Re: [TLS] Ticket request PR#20

[Viktor Dukhovni <[e-mail]>]

On Mon, Apr 20, 2020 at 12:18:28PM -0700, Nick Harper wrote:

> > 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.
> >
> 
> 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.

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.

> 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.

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.