On Wed, Mar 04, 2020 at 05:56:49PM -0800, Nick Harper wrote:
> > The whole point of this discussion is that I [am] looking to avoid
> > the need to define two overlapping extensions solving the same
> > problem. The current extension should and will suffice.
>
> By current extension, do you mean what is currently in
> draft-ietf-tls-ticketrequests-04, which provides no mechanism for
> indicating anything about ticket reuse? If so, I'm happy with that
> resolution.
No I mean *this* extension, roughly as amended in PR#18, subject
to some further polish, with or without explicit handling for reuse.
> > We might never "bless" a way to negotiate reuse, fine, but there is
> > definitely no need to go out of one's way to forestall that possibility.
>
> MT's approach of putting two values in the extension and saying
> nothing about reuse, or reiterating the advice in RFC 8446 solves your
> problem for enabling reuse without blessing that use case.
No it does not, because he specifically emphasised treating 0 in the
resumption count as issue no tickets, whereas PR#18 says that that that
don't support reuse (perhaps all if that's the present consensus, until
such time as reuse becomes specified) need to treat both 0 and 1 as 1.
Without the 0 -> 1 mapping by servers that don't support reuse clients
that later ask for reuse by sending 0 get left out in the cold when
the server does not support reusable tickets. That element of PR#18
is the smallest viable concession to enabling reuse, without actually
defining/endorsing/... reuse.
Without the 0 -> 1 semantics, the design ceases to be compatible with
later evolution to support reuse. If the WG's intention is to prevent
that evolution at all costs, then this would be a success, but if not,
then please don't inadvertently close out that possibility.
Mind you, if that's the definition of "success", then I'm very
disappointed in what that implies about the working culture of
the group.
> We make many non-technical decisions. One such decision is what work we
> choose to do. An explicit focus of the charter of the TLS working group is
> to make the protocol more privacy-friendly and reduce the amount of data
> visible to attackers. Reusing tickets goes against those goals.
In many contexts yes, but not in all. We can be sensible about where
that's applicable, and where it is mere security theatre. In any case,
we can leave a miniscule knob in the design to perhaps some day enable
reuse without unnecessarily precluding that possibility.
I see nothing objectionable with a potential consensus to defer a
decision on reuse. But I do strongly object to a proposal to preëmpt
that option now and unavoidable require a second overlapping extension
if reuse to ever become negotiable.
As written, PR#18 (subject to some more polish either to expand on or
largely delete text about reuse) leaves room for compatible evolution to
in the future enable reuse by sending 0 for the resumption ticket count.
That signal should not penalize clients that happen to reach servers
that have no need for and do not support ticket reuse.
Those servers can send a single ticket, instead of sending none. It is
a negligible concesssion, that even those strongly opposed to supporting
reuse should not be taking a stand against.
Reuse may never be specified, and worst case there'll be two ways to say
"give me at most one ticket on resumption", with "at most 1" meaning
"1" in that version of reality. The two ways being sending either "0"
or "1" for the resumption count (assuming the new session count in
both cases is != 0).
If there are serious objections to interpreting a zero resumption count
as 1 because that may later prove useful, I've not heard them yet.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
