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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
