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