On Thu, Mar 05, 2020 at 11:59:50AM +1100, Martin Thomson wrote:
> On Thu, Mar 5, 2020, at 11:42, Viktor Dukhovni wrote:
> > But not in a way that forecloses interoperability with a client that
> > tries to negotiate reuse via a to-be specified mechanism in a later
> > draft. We can stop short of specifying/supporting/... reuse, but
> > deliberately precluding adding it later seems a step too far.
>
> Nothing we say here will prevent either:
>
> a) someone from ignoring the recommendation, as they already do
Breaking interoperability.
> b) someone from defining an extension that modified behaviour, superceding
> this mechanism
Breaking interoperability.
> So I can't see why you would be unhappy with this. All I am asking
> for is either no text on reuse (leaving it to 8446), or a brief
> recapitulation and reference to the text in 8446.
Because it MUST be possible for clients and servers where only
one side supports reuse to *interoperate*. That's the whole
point of IETF standards.
> This does not sabotage any future attempt to define something that
> reuses tickets. The text in 8446 needs no such defense because it
> stands on its own.
It does sabotage interoperable use of the proposed extension by
clients that (some day) want to attempt to negotiate reuse with
servers that may or may not support reuse, some of which may
treat the request for zero on resumption as "no tickets" even
if the ticket is not reusable.
> > - However, a zero in the resumption_count can only be in scope
> > when a resumption is happening, which means that in fact the
> > client did present a ticket, and given a non-zero value in
> > the new_session_count, a zero here can *only* mean an attempt
> > to negotiate reuse.
>
> This is disagree with. I offered other alternatives in my original
> mail. I know that you might infer that a client intends to reuse from
> this signal, but that's different than it expressly meaning that the
> client will be reusing the ticket.
It may not in fact reuse, but the server must not decline to issue
a new ticket if it will not continue to honour the existing one.
Your proposed changes, I hope inadvertently, sabotage a backwards
compatible (later) refinement of this extension for reuse. I
strongly object, and hope that is not your goal.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
