Subject: [TLS] progressing draft-ietf-tls-ticket-request

From: Sean Turner <[email-masked]>
Date: Fri, 28 Feb 2020 11:23:48 -0500

Hi!

Based on Tommy Pauly’s suggestion [0], Joe and I believe that the best way for us to get to the place where we can declare rough consensus is to:

* Consider the PR: [1].  This PR explains that when racing connections, the client will not necessarily know the number of tickets it will “consume”, so it should either have enough tickets for two subsequent handshake resumptions; or else use fewer tickets but potentially run out.

* Consider adoption of an individual draft that describes an extension for hinting ticket reuse. This draft will also discuss the use cases around ticket reuse.

Obviously, the rationale here is to progress this relatively simple draft, but allow the reuse discussion to continue. Again, we believe this allows us to declare rough consensus and avoid any deadlocks.

Please let us know your thoughts on the PR, which (assuming the PR gets consensus) we plan to ask the authors to merge sometime around 6 March.

Thanks,
Joe and Sean

[0] https://mailarchive.ietf.org/arch/msg/tls/fOmUYve5DLomjx3-Df9xQy0bocg/
[1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/17

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Feb 2020 22:41:00 +0000

Can we modify the existing draft to say 0-200 tickets not 0-255?

---

From: Watson Ladd <[email-masked]>
Date: Fri, 28 Feb 2020 15:03:08 -0800

The PR looks good to me.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 29 Feb 2020 04:17:28 -0500

> * Consider the PR: [1].  This PR explains that when racing connections, the client will not necessarily know the number of tickets it will “consume”, so it should either have enough tickets for two…

My sincere and deep apologies about tardiness in drafting my PR, it is
now done.  This builds on the above PR, but also addresses more fully
happy eyeballs, etc. by observing that even clients that never reuse
ticket can benefit from separate counts for resumption vs. full
handshakes, and can't generally predict which they'll get.

https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18

-- 
    Viktor.

---

From: David Schinazi <[email-masked]>
Date: Sat, 29 Feb 2020 12:40:43 -0800

Hi Viktor,

I like the editorial changes in your PR #18, as they do a good job of
explaining things.
However, I don't think we should add a second count in this extension.
Allowing ticket
reuse is not something we have consensus for in the WG, and I would like to
see this
discussion happen in the TLS WG, but not preventing this draft from moving
forward.

Thanks,
David

On Sat, Feb 29, 2020 at 1:18 AM Viktor Dukhovni <[email-masked]>
wrote:

> > * Consider the PR: [1].  This PR explains that when racing connections,
> the client will not necessarily know the number of tickets it will
> “consume”, so it should either have enough tickets for two subsequent
> handshake resumptions; or else use fewer tickets but potentially run out.
> >
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 29 Feb 2020 17:28:11 -0500

> I like the editorial changes in your PR #18, as they do a good job of

Thanks!  I could add a bit more text to guide client implementations on
how to update their ticket caches in response to tickets from the
server, but first wanted to see how this first cut will be received. 
And perhaps there's a risk of explaining too much.

> However, I don't think we should add a second
> count in this extension.  Allowing ticket reuse is not something we
> have consensus for in the WG, and I would like to see this discussion
> happen in the TLS WG, but not preventing this draft from moving
> forward.

But the second count is not just or even primarily for reuse, it is also
useful for the non-reuse case as explained in the new text.  The fact
that it then possible to cleanly express reuse is a byproduct, and I
also don't mean to encourage reuse in general, but it does have
non-trivial applications, where the privacy impact is zero (no client
privacy is possible or desirable).

The TLS WG can maintain a strong focus on *enabling* privacy, and a
strong recommendation that applications need to take privacy into
account, but WITHOUT forcing pointless privacy-related counter-measures
down everybody's throat, whether you need it or not.

Ignoring the needs of market segments other than the principal one
of browser-to-website is IMHO not something that the TLS WG should
do.  The browsers are perfectly capable of not doing reuse, and
even if some misguided client erroneously offers reuse, the server
can decline.  Ticket reuse requires the coöperation of both client
and server, by which point a reasonable position to take is that
it is their choice to make.

-- 
    Viktor.

---

From: Nico Williams <[email-masked]>
Date: Sat, 29 Feb 2020 16:57:03 -0600

On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> Allowing ticket reuse is not something we have consensus for in the
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Did I miss a consensus call or something?

> WG, and I would like to see this discussion happen in the TLS WG, but
> not preventing this draft from moving forward.

Nico
--

---

From: David Schinazi <[email-masked]>
Date: Sat, 29 Feb 2020 16:29:38 -0800

> > Allowing ticket reuse is not something we have consensus for in the

Hi Nico,

To clarify what I said: I meant that there has not been a consensus call
here,
and additionally I've heard that some folks would like to enable ticket
reuse,
whereas some other folks are very opposed to any kind of reuse.

In other words, I meant "we do not have consensus to allow reuse";
I did not mean "we have consensus to not allow reuse".

I'm not a TLS WG chair, I cannot judge consensus here. I was simply
noting that there indeed had not been a consensus call on this topic.

Furthermore, I still think the topic of reuse is out of scope for
draft-ietf-tls-ticket-request.

Hope this helps.
David

---

From: David Schinazi <[email-masked]>
Date: Sat, 29 Feb 2020 16:34:17 -0800

Hi Viktor,

I think that what you bring up here has value, but I do not see it in
scope of draft-ietf-tls-ticket-request. The draft as currently written
addresses the use-cases that it was scoped to address. I would
encourage you to propose another draft with your use-cases, as
that would be a great starting point for that discussion. I appreciate
your editorial work on draft-ietf-tls-ticket-request and I'm willing to
make those editorial changes (assuming the other editors agree),
but we shouldn't change the normative text to support an
out-of-scope use-case.

Thanks,
David

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 29 Feb 2020 19:47:15 -0500

> draft-ietf-tls-ticket-request.

But is not at all out of scope.  This extension is negotiating ticket
requirements between client and server.  It is not possible for reuse to
be "out of scope", if reuse is ever allowed, then it should be possible
to negotiate it.

A decision needs to be made.  Is the TLS WG mandating non-reuse even
where there is zero privacy gain and efficiency gains on both sides
from just using a single ticket until it is replaced by the server?

However, if one *really* wanted to punt on the decision, the two
counters could be specified, without defining the case where the
resumption count is zero as being "reuse".  The "reuse case" could
then be deferred to a subsequent draft.  In *this* draft any "<= 1"
resumption_count case could then be treated as "1" (server does not
at present support reuse).

I don't think that making reuse possible is really such a hot potato.
But if it so toxic, that we're collectively unable to touch it, then
it could be deferred in a way that leaves room to get it done later
without fundamentally revising the extension.

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 29 Feb 2020 19:50:13 -0500

On Sat, Feb 29, 2020 at 04:34:17PM -0800, David Schinazi wrote:

> scope of draft-ietf-tls-ticket-request.

I don't see how it can be out of scope.  The abstract clearly
puts it in scope:

   TLS session tickets enable stateless connection resumption for
   clients without server-side, per-client state.  Servers vend an
   arbitrary number of session tickets to clients, at their discretion,
   upon connection establishment.  Clients store and use tickets when
   resuming future connections.  This document describes a mechanism by
   which clients can specify the desired number of tickets needed for
   future connections.  This extension aims to provide a means for
   servers to determine the number of tickets to generate in order to
   reduce ticket waste, while simultaneously priming clients for future
   connection attempts.

And even without reuse, the two separate counters aid in producing the
right number of tickets on routine resumption vs. session renegotiation.

-- 
    Viktor.

---

From: David Schinazi <[email-masked]>
Date: Sat, 29 Feb 2020 17:19:23 -0800

My personal opinion is that reuse is clearly out of scope,
especially given the diverging opinions in the working
group on this topic.

I'm going to let the chairs step in and let us know what
their view of the scope is.

David

---

From: Nico Williams <[email-masked]>
Date: Sat, 29 Feb 2020 21:19:33 -0600

On Sat, Feb 29, 2020 at 04:29:38PM -0800, David Schinazi wrote:
> To clarify what I said: I meant that there has not been a consensus
> call here, and additionally I've heard that some folks would like to
> enable ticket reuse, whereas some other folks are very opposed to any
> kind of reuse.
> 
> In other words, I meant "we do not have consensus to allow reuse"; I
> did not mean "we have consensus to not allow reuse".

I don't think even that is correct.  Without a consensus call we don't
know.  Viktor has raised serious concerns and a simple fix.

> draft-ietf-tls-ticket-request.

Well, you think so, and I don't.  Now what?

Nico
--