Subject: Re: [TLS] Ticket request PR#20

From: Sean Turner <[email-masked]>
Date: Fri, 1 May 2020 13:03:58 -0400

All,

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.

spt (for Joe and Sean)

> On Apr 19, 2020, at 18:23, Viktor Dukhovni <[email-masked]> wrote:
> 
> I uploaded a small pull request for the ticket request draft:
> 
>    https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/20
> 
> it stipulates that servers SHOULD send at least one ticket unless *both*
> counters are zero.  A client willing to accept tickets for either of the
> two handshake types is capable of accepting a ticket for the other.
> 
> Yes, this leaves the door open to later define (or not) special
> semantics for the zero value to be used between mutually consenting
> clients and servers.
> 
> -- 
>    Viktor.
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 1 May 2020 14:11:31 -0400

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

-- 
    Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 1 May 2020 11:18:58 -0700

Hi Viktor,

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 1 May 2020 14:39:58 -0400

> this is a *request*, not a command from the client to the server.

And yet, RFC 8446 C.4 says servers SHOULD always send at least one, and
so this draft is modifying that to say that it is now "OK" to sometimes
send no tickets based on the applicable counter.  All I am asking for is
that the "OK" condition be made more strict, requiring both counters to
zero before C.4 is overriden.

The server can still start WW-III upong seeing the extension, but that
does not preclude clarity about the *intended* meaning.  That's what
the MUSTs/SHOULDs/MAYs etc. are for.

-- 
    Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 1 May 2020 11:50:22 -0700

> zero before C.4 is overriden.

I don't see how this draft is modifying that SHOULD -- SHOULD is for cases
where "do this if you don't know any better, but in some circumstances
doing the other thing is okay".  I see this draft as defining a mechanism
to convey information from client to server, so that the server can know
whether it's one of those "some circumstances" when "doing the other thing
is okay".  But that doesn't modify the SHOULD, and it's still up to the server.

> the MUSTs/SHOULDs/MAYs etc. are for.

I actually think that in this case prose is going to be better at conveying
the intended meaning than normative keywords will, but should probably
refrain from commenting further until I actually do the AD Evaluation.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 1 May 2020 19:28:07 +0000

Sadly, I concur with Viktor.