On Fri, May 01, 2020 at 02:39:58PM -0400, Viktor Dukhovni wrote:
> On Fri, May 01, 2020 at 11:18:58AM -0700, Benjamin Kaduk wrote:
>
> > > 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.
>
> 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.
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 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.
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
