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

From: "Salz, Rich" <[email-masked]>
Date: Sun, 1 Mar 2020 14:15:45 +0000

>    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.
  
Agreed, and strongly so with the last sentence.

---

From: Rob Sayre <[email-masked]>
Date: Sun, 1 Mar 2020 22:39:07 -0800

> Agreed, and strongly so with the last sentence.

None of these messages have addressed the chairs' suggestion:

"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."

What's wrong with this suggestion? Is the concern that it won't be adopted?

thanks,
Rob

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Mar 2020 02:20:07 -0500

> What's wrong with this suggestion? Is the concern that it won't be adopted?

PR#18 isn't exclusively or primarly about reuse.  Rather it addresses a
gap in the design which fails to address the difference in required
tickets between resumptions and full handshakes.

A client should generally (connection racing aside) ask for just one
ticket when attempting resumption, but will need more than one if
instead a full handshake results.

But on the reuse side, it would be exceedingly cumbersome to have two
separate extensions for negotiating the requested ticket count.  We
should just resolve the issue now:

    - Does TLS 1.3 support ticket reuse in applications that can't
      take advantage of and don't need the privacy advantages of
      single-use tickets?

    - If so, they should be able to negotiate ticket reuse, and
      this extension is precisely the right vehicle for that.

Let's not be in the habit of ducking issues that need to be
addressed.

That said, the dula counters could be defined now without reuse defined,
and a separate draft *could* do that part later, without changing the
structure, or introducing a second extension.  But kicking the can down
the road would IMHO be very sad.  Surely we can do better than that.

Instead of endlessly debating whether to decide now or later, let's
just decide one way or other:

    * Is the ticket-non-reuse traffic-analysis counter-measure
      mandatory for all TLS clients?

      - Even though its protection can't ultimately be reliable,
        there are more side-channels linking clients in traffic
        flows than just the ticket.

     - Even though some clients can't possibly benefit because
       they're by design the sole clients at their IP address,
       may be on private networks, in industrial settings, ...

I hope the answer is that ticket non-reuse is not mandatory,
but if it is, at least we'll have a decision.

-- 
    Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Mar 2020 05:36:59 -0800

>       take advantage of and don't need the privacy advantages of

I actually don't think this is quite the right question. Rather, the
question is:

Should the TLS WG produce a Standards Track (Recommended) extension
that is designed to facilitate reuse. I believe the answer to this is "no",
which
is why I was not in favor of your original suggestion (I've already
explained why
I think your "can't take advantage of and don't need" language isn't quite
right, so I won't go into that again). The distinction between Recommended
and Not Recommended is the mechanism we have come to for allowing
TLS to be extensible in ways that the WG thinks are unwise and I think
that that's the right way to handle reuse.

With that said, I *do* think that the argument that you might only want 1
ticket when you are resuming has some force, and so I feel somewhat more
positive about this more general extension, though I have to think about it
more.

-Ekr

---

From: Daniel Migault <[email-masked]>
Date: Mon, 2 Mar 2020 10:10:44 -0500

The changes proposed by Viktor in [1] address my concern and I am happy
with those.

I am also fine to to have further considerations in another draft as the
current structure let this to be document be moved forward.

I think it is important we provide means to minimize the resource involved,
and this includes the possibility to re-use ticket.

I am wondering if more text should be provided for:
new_session = n > 1
resumption = m  > 1

Yours,
Daniel

[1]
https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18/commits/3dd8be998435fb54bbf78369449099aca217347f

On Fri, Feb 28, 2020 at 11:24 AM Sean Turner <[email-masked]> wrote:

> 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
> 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
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Daniel Migault
Ericsson

---

From: Sean Turner <[email-masked]>
Date: Mon, 2 Mar 2020 10:37:43 -0500

> On Feb 29, 2020, at 22:19, Nico Williams <[email-masked]> wrote:
> 
> On Sat, Feb 29, 2020 at 04:29:38PM -0800, David Schinazi wrote:
>> On Sat, Feb 29, 2020 at 2:57 PM Nico Williams <[email-masked]> wrote:
>>> On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
>>>> 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
>>>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Did I miss a consensus call or something?
>> 
>> 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.
> 
> Well, you think so, and I don't.  Now what?

The chair step in. Stay tuned.

spt