Re: [TLS] Ticket request PR#20

[Benjamin Kaduk <[e-mail]>]

Hi Viktor,

On Fri, May 01, 2020 at 02:11:31PM -0400, Viktor Dukhovni wrote:
> On Fri, May 01, 2020 at 01:03:58PM -0400, Sean Turner wrote:
> 
> > We recommend that PR#20 be closed and we will progress the draft to
> > Ben for his AD review. The suggested text is not strictly needed. As
> > the name of the draft suggests, the client’s ticket requests are just
> > that a request for tickets. The server is free to do whatever it wants
> > with the request.
> 
> This is unfortunate, because there's an opportunity here to specify
> an extensible extension that could later be refined to support
> reuse at negligible cost to the "complexity" of the specification,
> indeed all the server has to do is issue at least one ticket like
> it always did, unless both counters are zero.
> 
> I've agreed to defer actual consideration of reuse to a separate draft,
> but this preëmptively shuts the door on getting that done, without
> requiring a second largely redundant extension that would have to modify
> the meaning of {0,1} to make the "1" be "as needed".  Now server that
> (hypothetically) are willing to support reuse will have to consider the
> interplay of two separate related extensions, which is definitely more
> complex.
> 
> Declining this comes across hostile to me.  I read the objections to
> "only {0, 0} means zero" as a blocking counter-measure against the
> deferred discussion, and not a material objection on the merits. :-(

I don't think it's right to say that "only {0,0} means zero" -- after all,
this is a *request*, not a command from the client to the server.
In particular, I see it as an indication of what the client wants in order
to meet the client's policy for (non-)reuse, but when the server's policy
is different, the server can and should diverge from the client's request.
This divergence can occur in either direction (more or fewer tickets issued).

Since the signal we're sending is merely advisory, it seems more prudent
to leave discussion of what a server should do when it receives specific
values as guidance for what factors a server logic should take into account
rather than trying to assign specific semantics to pairs of values that are
advisory in the first place.  I think what people are objecting to is
trying to assign precise semantics to specific pairs of values when the
individual values themselves do not have such precise semantics.

I would need to go and re-read the text to be sure (and I guess I'll have
to when it gets to me for AD evaluation), but expect that some discussion
of how client policy can mismatch with server policy to be appropriate;
I expect to have more concrete text suggestions as part of my AD review.

Thanks,

Ben