Re: [TLS] Ticket request PR#20

On Sun, Apr 19, 2020 at 4:06 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> On Sun, Apr 19, 2020 at 03:41:49PM -0700, Eric Rescorla wrote:
>
> > 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}.
>
> 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.

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

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.

>
> --
>     Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>