Re: [TLS] Ticket request PR#20
>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. :-(
Sadly, I concur with Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
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
Re: [TLS] Ticket request PR#20
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.
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
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 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
On Mon, Apr 20, 2020 at 12:18:28PM -0700, Nick Harper wrote:
> > That precludes clients from soliciting 0 *only* from servers that
> > support some future specification, and otherwise getting 1 from
> > servers that support only the current specification.
> >
>
> That's not true. Suppose there's some future specification FOOBAR that a
> client and server might support, and the client wants a resumption_count of
> 0 when the server supports FOOBAR and 1 if the server doesn't support
> FOOBAR. The apparent problem is that the client doesn't know whether the
> server supports FOOBAR when it writes its resumption_count value. It's true
> that the client doesn't know whether the server supports FOOBAR on its
> first connection to the server, but on that connection, the value of
> resumption_count is irrelevant. On future connections, the client can
> condition resumption_count based on whether FOOBAR was supported on the
> connection that the resumption ticket came from.
Yes, that mostly works, but it will require a second extension (which
would otherwise not be needed), and assumes that the *same* server
software is doing the resumption as issued the initial ticket. That'll
generally be true I guess, but is not guaranteed. In a load-balanced
pool of servers, support for FOOBAR may not be universal.
> My take on this PR is that it unnecessarily complicates the
> ticketrequest draft. As currently specified, the two values do what
> they say on the tin; with this PR there's an extra weird edge case.
> This complication is unnecessary based on my above description of how
> the FOOBAR spec can extend it.
The "complexity" involved is exceedingly minimal, and introducing a
second extension FOOBAR to modify the meaning of this extension is
rather more complex. I'd like to have an opportunity to propose
a later refinement of this specication to give a new meaning for
{1,0} in this extension, without requiring any new FOOBAR extension.
So my hope is that the case for {1,0} -> 0 tickets on resumption is
rather weak, and {1,0} -> 1 is cheap enough to make it a reasonable
compromise.
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
On Sun, Apr 19, 2020 at 03:41:49PM -0700, Eric Rescorla wrote:
> I don't think we should make this change. In the context of this draft, if
> the client wants that behavior, it should send {1, 1}.
That precludes clients from soliciting 0 *only* from servers that
support some future specification, and otherwise getting 1 from
servers that support only the current specification.
Such clients are not looking for a static server behaviour, but
rather need only certain servers to return 0, and the rest
to return 1.
In any case, if sending 1 or more unconditionally was fine for RFC8446
(e.g. per the text in C.4) it is hard to imagine why it is suddenly so
important to insist that the server be able to send 0 when receiving
{1, 0} or {0, 1}.
Servers that don't support this new extension at all will send 1 (or
more). So it is clearly not a big deal also for servers that do
support it to do likewise.
Since there is no specific *use-case* for {1, 0} to mean 0 at present,
that couldn't also be handled by sending {0, 0}, there is no reason
to stand in the way of defining {1, 0} to be a solicitation for at
least 1 ticket regardless of the handshake type.
The only objection that makes sense is a blocking tactic to preclude
potential future refinement of this draft to support reuse, but surely
blocking that evolution can be deferred to the discussion of the
(misguided?) I-D that proposes it.
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
I don't think we should make this change. In the context of this draft, if
the client wants that behavior, it should send {1, 1}.
-Ekr
On Sun, Apr 19, 2020 at 3:23 PM Viktor Dukhovni
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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
