Subject: [TLS] consensus call: draft-ietf-tls-request

From: Sean Turner <[email-masked]>
Date: Wed, 4 Mar 2020 10:46:28 -0500

All,

The purpose of this message is to help the chairs judge consensus on the way forward for draft-ietf-tls-request. The issue at hand is whether the client-initiated ticket request mechanism [0] should be modified to add support for ticket reuse, see [1] lines 160-214. As we see it, the way forward involves either one draft or two. To that end, we would like your input (YES or NO) on the following question by 2359 UTC 18 March 2020:

  Must the ticket reuse use case be addressed
  in draft-ietf-tls-request?

Full disclosure: RFC 8446 recommends against ticket reuse to help protect clients from passive observers correlating connections [2]. The PR supports ticket reuse for use cases for a server-to-server connection that has fixed source addresses and no connection racing; if adopted the WG will need to ensure that the security considerations are properly documented.

Note: There have been at least three threads on this draft [2][3][4]. Please, let’s try to avoid re-litigating the points made therein.

Joe & Sean

[0] https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
[1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Mar 2020 11:02:52 -0500

Please disregard this message I clicked the send button too soon.

spt

> On Mar 4, 2020, at 10:46, Sean Turner <[email-masked]> wrote:
> 
> All,
>

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Mar 2020 11:06:50 -0500

one more time ...

All,

The purpose of this message is to help the chairs judge consensus on the way forward for draft-ietf-tls-ticketrequests. The issue at hand is whether the client-initiated ticket request mechanism [0] should be modified to add support for ticket reuse, see [1] lines 160-214. As we see it, the way forward involves either one draft or two. To that end, we would like your input (YES or NO) on the following question by 2359 UTC 18 March 2020:

 Must the ticket reuse use case be addresses
 in draft-ietf-tls-ticketrequests?

Note: There have been at least three threads on this draft [3][4][5]. Please, let’s try to avoid re-litigating the points made therein.

Joe & Sean

[0] https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
[1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18
[2] https://tools.ietf.org/html/rfc8446#appendix-C.4
[3] https://mailarchive.ietf.org/arch/msg/tls/2cpoaJRushs09EFeTjPr-Ka3FeI/
[4] https://mailarchive.ietf.org/arch/msg/tls/-7J3gMmpHNw9t3URzxvM-3OaTR8/
[5] https://mailarchive.ietf.org/arch/msg/tls/FjhqbYYTwzgiV9weeCuxn0tHxPs/

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 4 Mar 2020 17:09:35 +0000

Yes.

> The PR supports ticket reuse for use cases for a server-to-server connection that has fixed source addresses and no connection racing; if adopted the WG will need to ensure that the security considerations are properly documented.

The PR [1; do I renumber the footnotes?] is an excellent start and would not seem to need much work to document the security concerns.  And BTW, this use-case probably applies for any multi-server of multi-data-center deployment; we're interested.
	/r$

---

From: Daniel Migault <[email-masked]>
Date: Wed, 4 Mar 2020 12:33:47 -0500

My personal position is YES - that draft-ietf-tls-ticket-requests must
address the ticket reuse use case. A non negligible number of deployments
will benefit from this feature deliberately provided by RFC8446.
Yours,
Daniel

On Wed, Mar 4, 2020 at 11:07 AM Sean Turner <[email-masked]> wrote:

> one more time ...
>
> All,
>
> The purpose of this message is to help the chairs judge consensus on the
> way forward for draft-ietf-tls-ticketrequests. The issue at hand is whether
> the client-initiated ticket request mechanism [0] should be modified to add
> support for ticket reuse, see [1] lines 160-214. As we see it, the way
> forward involves either one draft or two. To that end, we would like your
> input (YES or NO) on the following question by 2359 UTC 18 March 2020:
>
> Full disclosure: RFC 8446 recommends against ticket reuse to help protect
> clients from passive observers correlating connections [2]. The PR supports
> ticket reuse for use cases for a server-to-server connection that has fixed
> source addresses and no connection racing; if adopted the WG will need to
> ensure that the security considerations are properly documented.
>
> Note: There have been at least three threads on this draft [3][4][5].
> Please, let’s try to avoid re-litigating the points made therein.
>
> Joe & Sean
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Daniel Migault
Ericsson

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Mar 2020 13:20:07 -0500

On Wed, Mar 04, 2020 at 05:09:35PM +0000, Salz, Rich wrote:
> > Must the ticket reuse use case be addresses in
> > draft-ietf-tls-ticketrequests?
>   
> Yes.
> 
> > The PR supports ticket reuse for use cases for a server-to-server
> > connection that has fixed source addresses and no connection racing;
> > if adopted the WG will need to ensure that the security
> > considerations are properly documented.
> 
> The PR [1] is an excellent start and would not seem to need much work
> to document the security concerns.  And BTW, this use-case probably
> applies for any multi-server of multi-data-center deployment; we're
> interested.
>     

+1.  My motivation for authoring the PR is nicely summed up by Rich.

-- 
    Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 4 Mar 2020 10:30:20 -0800

>  in draft-ietf-tls-ticketrequests?

NO

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 04 Mar 2020 10:48:55 -0800

On 4 Mar 2020, at 8:06, Sean Turner wrote:

> one more time ...
>
> All,
>
> The purpose of this message is to help the chairs judge consensus on 
> the way forward for draft-ietf-tls-ticketrequests. The issue at hand 
> is whether the client-initiated ticket request mechanism [0] should be 
> modified to add support for ticket reuse, see [1] lines 160-214. As we 
> see it, the way forward involves either one draft or two. To that end, 
> we would like your input (YES or NO) on the following question by 2359 
> UTC 18 March 2020:
>

No.

Best,
Chris (no hat)

---

From: David Schinazi <[email-masked]>
Date: Wed, 4 Mar 2020 10:53:55 -0800

No.

David

---

From: Carrick Bartle <[email-masked]>
Date: Wed, 4 Mar 2020 11:16:13 -0800

No.

> On Mar 4, 2020, at 8:06 AM, Sean Turner <[email-masked]> wrote:
> 
> one more time ...
> 
> All,
>

---

From: Carrick Bartle <[email-masked]>
Date: Wed, 4 Mar 2020 11:18:02 -0800

No.

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 4 Mar 2020 14:33:59 -0500

No.

  -- Victor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Mar 2020 14:15:21 -0600

>      in draft-ietf-tls-ticketrequests?

I'm missing this post in my inbox, so I shall reply to Rich Salz's
reply.  Thanks for having this LC.

Can we also ask why or why not?  Of course, some of us have already
explained our positions, but I am interested in the rationales for any
new yes/no/don't-cares.

> Yes.

Me too, yes.

Nico
--

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Mar 2020 15:22:33 -0500

Nico,

> On Mar 4, 2020, at 15:15, Nico Williams <[email-masked]> wrote:
> 

I forwarded it directly to you.

> explained our positions, but I am interested in the rationales for any

If people have something new reason to add sure, but I would rather not rehash all the previous emails.

> Me too, yes.

Noted

> Nico

Cheers,

spt

---

From: Rob Sayre <[email-masked]>
Date: Wed, 4 Mar 2020 12:30:16 -0800

No.

thanks,
Rob

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Mar 2020 14:43:35 -0600

> I forwarded it directly to you.

Ah, it had landed in my spam folder.  Thanks.

> not rehash all the previous emails.

Certainly anyone voicing new opinions should provide a rationale.

That's part of how we find consensus.  We're not counting votes.

Nico
--

---

From: David Benjamin <[email-masked]>
Date: Wed, 4 Mar 2020 15:57:10 -0500

No.

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Mar 2020 16:03:33 -0500

> On Mar 4, 2020, at 15:43, Nico Williams <[email-masked]> wrote:
> 

Nico,

Luckily we’re not just counting votes.

People are free to add, as they way more often than not do, as much rationale as they would like. They can add their own personal rationale, refer to another already provided, or not.

spt

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Mar 2020 18:32:33 -0500

Yes.  I would like to see more than just "Ticket re-use is a security and privacy concern" in the security considerations.  At an absolute minimum, there needs to be a pointer to Section 8 of RFC 8446.

Russ

> On Mar 4, 2020, at 11:06 AM, Sean Turner <[email-masked]> wrote:
> 
> one more time ...
> 
> All,
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 05 Mar 2020 10:42:09 +1100

I have a third option (mu?) which differs from previous proposals.

I have been somewhat convinced by the arguments about how resumption is different and can tolerate the complexity of the additional counter.  That is, endpoints can request replacement of consumed tickets (1 for when a connection attempt succeeds, N if they race N connections and only keep one; 1 + M if they want to replace M wasted tickets from M previous failed connection attempts).

The text about reuse in PR 18 is not good, however.  (PR 18 is also very wordy, but that's something I will leave to the editors of the draft.)

I can live with a solution that has two numbers, but only on the understanding that 0 means "no tickets".  That means no text on reuse, except to discourage it.  It means implying that resumption=0 means that the client plans to initiate a full handshake in future rather than explicitly endorsing reuse.  As Russ mentions, we might cite the relevant sections of RFC 8446 when it comes to reuse, but for me that would have to be in the context of saying not to do that.

On Thu, Mar 5, 2020, at 03:06, Sean Turner wrote:
> the way forward for draft-ietf-tls-ticketrequests. The issue at hand is 
> whether the client-initiated ticket request mechanism [0] should be 
> Full disclosure: RFC 8446 recommends against ticket reuse to help 
> protect clients from passive observers correlating connections [2]. The 
> PR supports ticket reuse for use cases for a server-to-server 
> connection that has fixed source addresses and no connection racing; if 
> adopted the WG will need to ensure that the security considerations are 
> properly documented.
>

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 04 Mar 2020 16:41:30 -0800

On Wed, Mar 4, 2020, at 3:42 PM, Martin Thomson wrote:
> I have been somewhat convinced by the arguments about how resumption is 
> different and can tolerate the complexity of the additional counter.  
> That is, endpoints can request replacement of consumed tickets (1 for 
> when a connection attempt succeeds, N if they race N connections and 
> only keep one; 1 + M if they want to replace M wasted tickets from M 
> previous failed connection attempts).
> 
> The text about reuse in PR 18 is not good, however.  (PR 18 is also 
> very wordy, but that's something I will leave to the editors of the 
> draft.)
> 
> I can live with a solution that has two numbers, but only on the 
> understanding that 0 means "no tickets".  That means no text on reuse, 
> except to discourage it.  It means implying that resumption=0 means 
> that the client plans to initiate a full handshake in future rather 
> than explicitly endorsing reuse.  As Russ mentions, we might cite the 
> relevant sections of RFC 8446 when it comes to reuse, but for me that 
> would have to be in the context of saying not to do that.

+1 -- I support two separate numbers given these constraints. 

Best,
Chris

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Mar 2020 19:42:11 -0500

On Thu, Mar 05, 2020 at 10:42:09AM +1100, Martin Thomson wrote:

> I have been somewhat convinced by the arguments about how resumption
> is different and can tolerate the complexity of the additional
> counter.  That is, endpoints can request replacement of consumed
> tickets (1 for when a connection attempt succeeds, N if they race N
> connections and only keep one; 1 + M if they want to replace M wasted
> tickets from M previous failed connection attempts).
> 

I'm open to suggested improvements, and would probably reread and
apply some polish in any case.

> understanding that 0 means "no tickets".

But not in a way that forecloses interoperability with a client that
tries to negotiate reuse via a to-be specified mechanism in a later
draft.  We can stop short of specifying/supporting/... reuse, but
deliberately precluding adding it later seems a step too far.

Which means:

    - A zero in the new_session_count really does mean no tickets,
      since then the client ends up with no tickets on an initial
      handshake.

    - However, a zero in the resumption_count can only be in scope
      when a resumption is happening, which means that in fact the
      client did present a ticket, and given a non-zero value in
      the new_session_count, a zero here can *only* mean an attempt
      to negotiate reuse.

      Given that servers presumptively do not support reuse (after
      all we're not specifying it at present) such an attempt can
      be *politely* declined by vending one ticket instead.

      Actually vending zero would in fact be what servers do when
      (perhaps some day) they do support reuse, and the client
      would conclude that the presented ticket is reusable.

> That means no text on reuse, except to discourage it.

If that's the consensus, so be it, but a resumption count of
zero does need to be treated as 1 then, otherwise we're not
just deferring a decision on reuse, but unequivocally foreclosing
any posibility of adding it later in a compatible way.

> It means implying that resumption=0 means that the client plans to
> initiate a full handshake in future rather than explicitly endorsing
> reuse.

No, that would be a tragic and deliberate roadblock, which I don't think
is merited.  The client can signal that by setting the both counters to
zero.

> As Russ mentions, we might cite the relevant sections of RFC 8446 when
> it comes to reuse, but for me that would have to be in the context of
> saying not to do that.

That's fine, if that's the consensus, but we should not sabotage the
possibility of defining reuse later in a backwards compatible manner.

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Mar 2020 19:44:18 -0500

> +1 -- I support two separate numbers given these constraints. 

-1000.  Those constraints amount to sabotage, and must be rejected.

I'm fine with postponing reuse to a separate document, but destroying
any chance of a backwards-compatible evolution that adds it is beyond
the pale.

-- 
    Viktor.

---

From: Nick Harper <[email-masked]>
Date: Wed, 4 Mar 2020 16:59:46 -0800

I agree with MT. I see some potential value of different counts for how
many tickets to provide on a resumed connection vs a fresh connection. I
also want to discourage ticket reuse. If there isn't WG consensus for MT's
approach, then my preference is that the ticket reuse case not be addressed
at all in draft-ietf-tls-ticketrequests.

On Wed, Mar 4, 2020 at 3:43 PM Martin Thomson <[email-masked]> wrote:

> different and can tolerate the complexity of the additional counter.  That
> is, endpoints can request replacement of consumed tickets (1 for when a
> connection attempt succeeds, N if they race N connections and only keep
> one; 1 + M if they want to replace M wasted tickets from M previous failed
> connection attempts).
>
> The text about reuse in PR 18 is not good, however.  (PR 18 is also very
> wordy, but that's something I will leave to the editors of the draft.)
>
> except to discourage it.  It means implying that resumption=0 means that
> the client plans to initiate a full handshake in future rather than
> explicitly endorsing reuse.  As Russ mentions, we might cite the relevant
> sections of RFC 8446 when it comes to reuse, but for me that would have to
> be in the context of saying not to do that.
>
> > [3]
> https://mailarchive.ietf.org/arch/msg/tls/2cpoaJRushs09EFeTjPr-Ka3FeI/
> > [4]
> https://mailarchive.ietf.org/arch/msg/tls/-7J3gMmpHNw9t3URzxvM-3OaTR8/
> > [5]
> https://mailarchive.ietf.org/arch/msg/tls/FjhqbYYTwzgiV9weeCuxn0tHxPs/

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 05 Mar 2020 11:59:50 +1100

> deliberately precluding adding it later seems a step too far.

Nothing we say here will prevent either:

a) someone from ignoring the recommendation, as they already do

b) someone from defining an extension that modified behaviour, superceding this mechanism

So I can't see why you would be unhappy with this.  All I am asking for is either no text on reuse (leaving it to 8446), or a brief recapitulation and reference to the text in 8446.

This does not sabotage any future attempt to define something that reuses tickets.  The text in 8446 needs no such defense because it stands on its own.

>       the new_session_count, a zero here can *only* mean an attempt

This is disagree with.  I offered other alternatives in my original mail.  I know that you might infer that a client intends to reuse from this signal, but that's different than it expressly meaning that the client will be reusing the ticket.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Mar 2020 20:06:02 -0500

> a) someone from ignoring the recommendation, as they already do

Breaking interoperability.

> b) someone from defining an extension that modified behaviour, superceding this mechanism

Breaking interoperability.

> So I can't see why you would be unhappy with this.  All I am asking
> for is either no text on reuse (leaving it to 8446), or a brief
> recapitulation and reference to the text in 8446.

Because it MUST be possible for clients and servers where only
one side supports reuse to *interoperate*.  That's the whole
point of IETF standards.

> This does not sabotage any future attempt to define something that
> reuses tickets.  The text in 8446 needs no such defense because it
> stands on its own.

It does sabotage interoperable use of the proposed extension by
clients that (some day) want to attempt to negotiate reuse with
servers that may or may not support reuse, some of which may
treat the request for zero on resumption as "no tickets" even
if the ticket is not reusable.

> This is disagree with.  I offered other alternatives in my original
> mail.  I know that you might infer that a client intends to reuse from
> this signal, but that's different than it expressly meaning that the
> client will be reusing the ticket.

It may not in fact reuse, but the server must not decline to issue
a new ticket if it will not continue to honour the existing one.

Your proposed changes, I hope inadvertently, sabotage a backwards
compatible (later) refinement of this extension for reuse.  I
strongly object, and hope that is not your goal.

-- 
    Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 4 Mar 2020 17:09:59 -0800

> one side supports reuse to *interoperate*.  That's the whole

A failure to resume does not break the connection. Tickets may age out
anyway, or the server might have dropped state on restart, etc. So
there is no interoperability problem.

Sincerely,
Watson Ladd

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Mar 2020 20:16:05 -0500

> there is no interoperability problem.

That's sophistry.  The two sides interpret the signal in incompatible
ways, leading to the client not getting the fresh ticket it needs to
continue to communicate efficiently with the server.

Especially with the much larger PQ certificates coming soon, resumption
becomes increasingly important.

Performance-impacting breakdown in signalling due to incompatible
interpretation of specifications is loss of interoperability.

-- 
    Viktor.

---

From: Nick Harper <[email-masked]>
Date: Wed, 4 Mar 2020 17:19:02 -0800

> Breaking interoperability.

This doesn't break interoperability. If both endpoints negotiate
ticketrequests and this new extension, the new definition applies. If one
endpoint negotiates only this ticketrequests extension, then the definition
here applies. That doesn't break interoperability.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Mar 2020 20:26:51 -0500

> here applies. That doesn't break interoperability.

The whole point of this discussion is that I looking to avoid the need
to define two overlapping extensions solving the same problem.  The
current extension should and will suffice.

We might never "bless" a way to negotiate reuse, fine, but there is
definitely no need to go out of one's way to forestall that possibility.

That's frankly simply hostile, and may evidences a cultural issue in
this WG.

Barring a defensible technical reason to preclude future evolution in a
compatible manner to support a use-case that has non-negligible if not
yet majority support, precluding it anyway can only be read as a hostile
exclusionary tactic.  I object.

-- 
    Viktor.

---

From: Nick Harper <[email-masked]>
Date: Wed, 4 Mar 2020 17:56:49 -0800

> current extension should and will suffice.

By current extension, do you mean what is currently
in draft-ietf-tls-ticketrequests-04, which provides no mechanism for
indicating anything about ticket reuse? If so, I'm happy with that
resolution.

> definitely no need to go out of one's way to forestall that possibility.

MT's approach of putting two values in the extension and saying nothing
about reuse, or reiterating the advice in RFC 8446 solves your problem for
enabling reuse without blessing that use case.

> exclusionary tactic.  I object.

We make many non-technical decisions. One such decision is what work we
choose to do. An explicit focus of the charter of the TLS working group is
to make the protocol more privacy-friendly and reduce the amount of data
visible to attackers. Reusing tickets goes against those goals.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Mar 2020 02:06:34 +0000

Hiya,

>  in draft-ietf-tls-ticketrequests?

Yes. I think Viktor's use case is one to not bugger
up (even if one doesn't need to support it) and don't
see how supporting it breaks something. (While also
disliking generic ticket reuse.)

I also note what seems like a correlation between
people's yes/no opinions on this and whether or not they
(or sponsors/employers) are involved in implementing
a web browser. Not sure if that implies a technical
difference or just relates to understandable priorities
but I'm sure the chairs will factor that into evaluating
the mails in this thread.

Cheers,
S.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 4 Mar 2020 18:25:38 -0800

On Wed, Mar 4, 2020 at 6:07 PM Stephen Farrell <[email-masked]>
wrote:

> a web browser.

I don't think this is a fair characterization. I wrote "no", and did work
on web browsers several years ago.

Since then, I've worked on the server side. I think the proposal is a
request to accommodate a server architecture I would not ship.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Mar 2020 02:30:21 +0000

Hiya,

On 05/03/2020 02:25, Rob Sayre wrote:
> I don't think this is a fair characterization

To be clear - I wasn't accusing anyone of anything.
As I hoped the subsequent words in my mail that you
didn't quote made clear;-)

I do think it may be that one's valid interests do
colour one's conclusions. That's true for me anyway,
and there's nothing wrong with it, but I guess it
may complicate calling consensus.

Cheers,
S.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 4 Mar 2020 18:37:57 -0800

> didn't quote made clear;-)

This issue seems strangely contentious. I assumed any text I elided from
your message would be obvious to readers.

I do disagree with the idea that "web browsers" are some special class of
participant on the internet. I guess they show a URL in their UI.

thanks,
Rob

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Mar 2020 22:04:07 -0500

On Wed, Mar 04, 2020 at 05:56:49PM -0800, Nick Harper wrote:

> > The whole point of this discussion is that I [am] looking to avoid
> > the need to define two overlapping extensions solving the same
> > problem.  The current extension should and will suffice.
> 
> By current extension, do you mean what is currently in
> draft-ietf-tls-ticketrequests-04, which provides no mechanism for

No I mean *this* extension, roughly as amended in PR#18, subject
to some further polish, with or without explicit handling for reuse.

> MT's approach of putting two values in the extension and saying
> nothing about reuse, or reiterating the advice in RFC 8446 solves your
> problem for enabling reuse without blessing that use case.

No it does not, because he specifically emphasised treating 0 in the
resumption count as issue no tickets, whereas PR#18 says that that that
don't support reuse (perhaps all if that's the present consensus, until
such time as reuse becomes specified) need to treat both 0 and 1 as 1.

Without the 0 -> 1 mapping by servers that don't support reuse clients
that later ask for reuse by sending 0 get left out in the cold when
the server does not support reusable tickets.  That element of PR#18
is the smallest viable concession to enabling reuse, without actually
defining/endorsing/... reuse.

Without the 0 -> 1 semantics, the design ceases to be compatible with
later evolution to support reuse.  If the WG's intention is to prevent
that evolution at all costs, then this would be a success, but if not,
then please don't inadvertently close out that possibility.

Mind you, if that's the definition of "success", then I'm very
disappointed in what that implies about the working culture of
the group.

> visible to attackers. Reusing tickets goes against those goals.

In many contexts yes, but not in all.  We can be sensible about where
that's applicable, and where it is mere security theatre.  In any case,
we can leave a miniscule knob in the design to perhaps some day enable
reuse without unnecessarily precluding that possibility.

I see nothing objectionable with a potential consensus to defer a
decision on reuse.  But I do strongly object to a proposal to preëmpt
that option now and unavoidable require a second overlapping extension
if reuse to ever become negotiable.

As written, PR#18 (subject to some more polish either to expand on or
largely delete text about reuse) leaves room for compatible evolution to
in the future enable reuse by sending 0 for the resumption ticket count.
That signal should not penalize clients that happen to reach servers
that have no need for and do not support ticket reuse.

Those servers can send a single ticket, instead of sending none.  It is
a negligible concesssion, that even those strongly opposed to supporting
reuse should not be taking a stand against.

Reuse may never be specified, and worst case there'll be two ways to say
"give me at most one ticket on resumption", with "at most 1" meaning
"1" in that version of reality.  The two ways being sending either "0"
or "1" for the resumption count (assuming the new session count in
both cases is != 0).

If there are serious objections to interpreting a zero resumption count
as 1 because that may later prove useful, I've not heard them yet.

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Mar 2020 22:08:47 -0500

> such time as reuse becomes specified) need to treat both 0 and 1 as 1.

Some sort of keyboard glitch in the above paragraph, sorry...

    s/that that that/that servers that/

-- 
    Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 4 Mar 2020 20:32:45 -0800

> disliking generic ticket reuse.)

It's not the usecase: it's the program. Postfix made architectural
choices that make storing tickets allegedly expensive.

I would be a lot more sympathetic if Viktor could provide actual
measurements with actual numbers demonstrating that rewriting tickets
is an insurmountable obstacle, given all the other time taken by
opening connections and sending mail. There also is the possibility
that a different architecture that reduces contention on the cache
(say by not having multiple processes attempting to open connection to
the same server at once, or switching to storage system that
accomodates multiple simultaneous writers) would have better
performance.

> the mails in this thread.

0-RTT=> replay=> either single use tickets or idempotent methods only.
And then we learned that websites don't have idempotent GET always.
Hence the interest in server side enforcement of single use tickets.

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Mar 2020 23:16:38 -0600

> choices that make storing tickets allegedly expensive.

Well, Postfix runs about 40% of the world's email infrastructure outside
of gmail and yahoo and such, so excuse me, but your response is just not
acceptable.

But also, this WG has tried to accomodate things like SChannel whose API
designs are very different from others and impinge on what is feasible
in the protocol.  E.g., reconnects are avoided.

Nico
--

---

From: Rob Sayre <[email-masked]>
Date: Wed, 4 Mar 2020 21:47:49 -0800

> of gmail and yahoo and such, so excuse me, but your response is just not

I think the response is fine.

thanks,
Rob

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Mar 2020 00:53:05 -0500

> choices that make storing tickets allegedly expensive.

These fit into a existing archicture of security-hardened
privilege-separated ephemeral processes that handle a modest number of
deliveries and exit to be replaced by new processes, concurrent
delivery (within sensible bounds) to the same destination, because
serializing all output to the same destination really kills
performance, ...

The architecture is actually reasonably well thought out.  It is true
that Postfix could probably learn to have a multi-slot cache, and to
keep updating on each and every resumption.  But the shared ticket cache
is backed by Berkeley DB or LMDB, and especially in the case of LMDB's
copy-on-write design a high write rate (hundreds of new tickets per
second) is not particularly appealing.

In any case, Postfix is but an example of an application where ephemeral
tickets are mere security theatre, there is simply no privacy benefit,
and no plausible use-case for early data.

I am all down with discouraging ticket reuse, not enabling it by
default, ... but none of that amounts to a sound reason for precluding
reuse where non-reuse has demonstrably no value.

> opening connections and sending mail.

Why does it have to be an insurmountable obstacle.  What's wrong with
the observation that I have a well-oiled mature code-base that works
well with multi-use tickets, and would need significant refactoring to
take advantage of ephemeral tickets.

It is true that with returning a fresh ticket each time, the cache churn
is not a *disaster* for Postfix, but it is unnecessary, and not just
Postfix, but also other application can benefit from avoiding ticket
churn security theatre.

> There also is the possibility that a different architecture that
> reduces contention on the cache (say by not having multiple processes
> attempting to open connection to the same server at once, or switching
> to storage system that accomodates multiple simultaneous writers)
> would have better performance.

So I gather I should trade-off optimizing mail queue management for
optimizing ticket cache management?  (I don't think so...)

> Hence the interest in server side enforcement of single use tickets.

There's no GET in SMTP.  The transaction starts with a 220 greeting
from the server to the client.  Then eventually STARTTLS, and a new
EHLO from client to server.  There's no 0-RTT, no early data, ...

I think a singular focus in this WG on HTTPS as the sole motivating
use-case is unfortunate.

-- 
    Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 5 Mar 2020 10:57:16 +0000

> serializing all output to the same destination really kills

That also pretty much describes the Exim implementation model.
-- 
Cheers,
  Jeremy

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Mar 2020 11:02:55 +0000

Hiya,

> opening connections and sending mail.

That's a fair point.

S.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Mar 2020 06:16:28 -0800

I concur with MT's proposal

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Mar 2020 06:26:48 -0800

[Trimming extensively]

> as 1 because that may later prove useful, I've not heard them yet.

Well, both MT and Nick have raised objections, and they seem serious to me:

TLS has decided, as memorialized both in the charter and in 8446, that
ticket reuse ought not to be encouraged, and therefore we should not
specify technical features at Recommended that are designed to facilitate
that.

I appreciate that you don't consider this a "serious" objection, but that's
your opinion, and in this matter, consensus is a judgement for the chairs
and ADs to make, not you.

-Ekr

---

From: Andrei Popov <[email-masked]>
Date: Thu, 5 Mar 2020 14:48:16 +0000

Hi Nico,

> But also, this WG has tried to accomodate things like SChannel whose API designs are very different from others and impinge on what is feasible in the protocol.  E.g., reconnects are avoided.
Both Session ID-based and session ticket-based TLS resumption options are supported in schannel. It is true that the API design is different from others (GSS-like, an attempt to match Windows APIs used for other security protocols, e.g., Kerberos).

Cheers,

Andrei

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Nico Williams
Sent: Wednesday, March 4, 2020 9:17 PM
To: Watson Ladd <[email-masked]>
Cc: TLS List <[email-masked]>
Subject: [EXTERNAL] Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

On Wed, Mar 04, 2020 at 08:32:45PM -0800, Watson Ladd wrote:
> > Yes. I think Viktor's use case is one to not bugger up (even if one 
> > doesn't need to support it) and don't see how supporting it breaks 
> > something. (While also disliking generic ticket reuse.)
> 

Well, Postfix runs about 40% of the world's email infrastructure outside of gmail and yahoo and such, so excuse me, but your response is just not acceptable.

But also, this WG has tried to accomodate things like SChannel whose API designs are very different from others and impinge on what is feasible in the protocol.  E.g., reconnects are avoided.

Nico
-- 

_______________________________________________
TLS mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf68655dfdfb74261cbe408d7c0c4787e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189822393462003&amp;sdata=%2F1yYpQkjpBiS7BTz1ZMcEVO4VzTf7AnYfrrOrQR5blQ%3D&amp;reserved=0

---

From: Sean Turner <[email-masked]>
Date: Thu, 5 Mar 2020 10:06:13 -0500

> On Mar 4, 2020, at 21:30, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

These rest of the para:

> Not sure if that implies a technical

> may complicate calling consensus.

Stephen,

No worries we always consider who responded. We do consider a bit more though than just what we think they might do in their day jobs since some have some sway over open source TLS implementation and some of the employers do have infrastructure (and maybe interactions with others) that might do server-to-server connections. Likewise, I also consider everybody here is acting as an individual unless they say otherwise, just like I assume you are just acting as you and not, say, as an IAB member.

As far as complications in calling consensus, it, as you know, pretty much goes with the territory.

spt

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 5 Mar 2020 15:17:18 +0000

No, it's the use-case.

We don't use postfix.

---

From: Kyle Nekritz <[email-masked]>
Date: Thu, 5 Mar 2020 19:17:26 +0000

No.

FWIW, we (at my day job) run TLS 1.3 at large scale for server-to-server RPC communication, and have seen no appreciable performance overhead from ticket refresh on resumption.

I also have no objection to Martin's proposal.

Kyle

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Sean Turner
Sent: Wednesday, March 4, 2020 11:07 AM
To: TLS List <[email-masked]>
Subject: [TLS] consensus call: draft-ietf-tls-ticketrequests

one more time ...

All,

 Must the ticket reuse use case be addresses  in draft-ietf-tls-ticketrequests?

Joe & Sean

[0] https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtls-2Dticketrequests_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=4Kz5f1xxZ6P7E_YXEhOUWD50NCnQZIkbCRZbqojrJBk&e=
[1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18
[2] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8446-23appendix-2DC.4&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=N3Qf8xv0MnsGbbTtjHb5U2IuianYB7TQ8a8CXcIS7Gc&e=
[3] https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tls_2cpoaJRushs09EFeTjPr-2DKa3FeI_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=PELoSAnGtZHjPCTcCWS1d0a-Ta0ZLvhHFeFQ8wbagqs&e=
[4] https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tls_-2D7J3gMmpHNw9t3URzxvM-2D3OaTR8_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=Mfbl7bM_Esrm6nALbKFAUwBtA9G-nCrqy7Le2efwdi8&e=
[5] https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tls_FjhqbYYTwzgiV9weeCuxn0tHxPs_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=pPiiy8g1rqhJ3lj78u9JrggB4p3yo2yHLLV35NPvFrk&e=
_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=sU60CTb3C9iJnQ7Xnnn5xxjDMHWjjccFZybS8IzGCG0&e=

---

From: Nick Harper <[email-masked]>
Date: Thu, 5 Mar 2020 13:42:03 -0800

In regards to the 0 -> 1 mapping:

Let's assume we have a client that wishes to reuse tickets when possible
talking to a server that is content to allow ticket reuse (since I believe
this is the use case Viktor cares about).

Without that mapping, the client sends a new_session_count of 1 and a
resumption_count of 0. On a fresh connection, the client gets a (single)
ticket, which it reuses for resumptions. On the resumed connections, the
client gets no new tickets. Eventually (presumably 7 days after the initial
fresh connection), the server rejects the resumption forcing a complete
handshake, and issues a new ticket.

If the client is forced to do a full connection every 7 days, I don't see
that as a bad thing. The client should be doing a full connection
periodically so that the client can verify the server still has a valid
cert and has control over the private key in that cert.

With the mapping, the client still sends the same counts. The initial fresh
connection remains the same: the client gets a single ticket. Now, on
resumed connections, the client may get 0 or 1 ticket depending on whether
the server thinks the client needs a new ticket.

I haven't seen any explanation of how a server makes this decision. (This
isn't text I'd expect in the draft.) Ticket age is mentioned as one
criteria. If the ticket is still valid for some time in the future, does
the server assume a new ticket isn't needed because it can still be reused?
Even if it's only valid for a few more seconds? Hours? Or on the other end
of that spectrum, does the server realize that it can always mint a fresher
ticket than the one it just received, and so it issues a new ticket to
increase the chance of resumption on a future connection? (After all, the
server doesn't know when the client might next attempt a resumption.) If I
were implementing a server that supports ticket reuse and the extension
described by PR#18, when resumption_count is 0, I would either always send
a new ticket (because the new ticket has a slightly higher chance of a
successful resumption than the existing one), or never send a new ticket
(because the one I just received could still be used for resumption for
some epsilon period of time).

Ultimately, this looks like a balance between having as few full handshakes
as possible and receiving as few unneeded NewSessionTicket messages as
possible. I don't think there's any form of this ticket request extension
that can drive both of those values to their minima. A format like having
both a new_session_count and a resumption_count (with no 0 -> 1 mapping)
drives the unneeded NewSessionTicket messages to zero, but may result in an
extra full handshake every week. With the 0 -> 1 mapping, the number of
full handshakes might be driven down to the minimum number the client will
do based on whatever policies it has for re-verifying certificates, and the
number of unneeded NewSessionTickets might be reduced based on the server's
behavior.

I think the 0 -> 1 mapping relies too much on server heuristics, and if the
goal is to reduce the number of unneeded NewSessionTickets sent by a server
to a client where both support ticket reuse, removing the 0 -> 1 mapping
(but keeping the two separate counts) achieves that goal the best.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Mar 2020 16:49:54 -0500

> this is the use case Viktor cares about).

I care about all use cases, incuding the case where the server DOES NOT
support reuse, and the client is attempting to negotiate reuse.

> handshake, and issues a new ticket.

[ FWIW, Postfix will by default issue a fresh ticket once an hour ].
The above is NOT the problem case, that case works fine, the server
returning no tickets when the resumption count is zero is what servers
that *support* reuse would be expected to do.

The problem case is when the server does NOT support reuse, and still
issues zero tickets.  Then the client tries to reuse the previous
ticket, but it is no longer usable, and so it ends up doing a full
handshake every other connection.

-- 
    Viktor.

---

From: Nick Harper <[email-masked]>
Date: Thu, 5 Mar 2020 13:56:07 -0800

> handshake every other connection.

I forgot to consider that case. Thanks for explaining that. Given that, it
sounds like MT's third option doesn't actually help the reuse case (unless
the client has some other knowledge, presumably out of band, that the
server supports ticket reuse).

For purposes of the consensus call, I'm now leaning towards not addressing
ticket reuse at all in draft-ietf-tls-ticketrequest (i.e. not merging PR
18), though I'd also be fine with MT's variant of 18.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Mar 2020 17:31:49 -0500

> server supports ticket reuse).

Yes, I'm glad it is now more clear.

> 18), though I'd also be fine with MT's variant of 18.

Note that PR#18 is a menu of options, and the consensus call is whether
support for ticket reuse should be specified *now*.  But if there's no
consensus for specifying it now, then PR#18 can be modified to:

    1.  Leave the two counters that improve handling of full
        handshake vs. resumption.

    2.  Strip explicit text describing support for reuse.

    3.  Leave a mere bread-crumb (the zero to one mapping for the
        resumption counter) that would allow the WG to consider a later
        document that updates this one in a backwards-compatible manner
        to specify resumption.

        The mapping by itself disables reuse by always issuing a new
        ticket, given that this is what servers are expected to do.

            https://tools.ietf.org/html/rfc8446#appendix-C.4

           [...]    Servers SHOULD issue new tickets with every connection.
           This ensures that clients are always able to use a new ticket when
           creating a new connection.

So unfortunately, we now have responses that go beyond the immediate
question of whether this extension should explicitly support reuse.

Martin Thomson has decided (perhaps inadvertently) to break 3, making it
impossible to reconsider reuse in a later document that updates the
current extension in a backwards-compatible manner.

You seem to be saying you don't want any of the changes in PR#18, not
even the ones that improve non-reuse negotiation.  But that's not
the subject of this consensus call.

But this consensus call was not about whether to adopt PR#18 as-is,
rather it is narrowly about whether reuse is to be considered now, or
later (and then perhaps never[1]).

-- 
    Viktor.

[1] https://www.newyorker.com/cartoons/bob-mankoff/the-story-of-how-about-never

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Mar 2020 17:28:12 -0800

Hi Martin,

> I can live with a solution that has two numbers, but only on the understanding that 0 means "no tickets".  That means no text on reuse, except to discourage it.  It means implying that resumption=0…

I'm not sure that I understand why you feel a need to require that 0 is
interpreted as an implication that the client plans to initiate a full
handshake in the future.  It's not clear to me that we need to make any
statement about the client's intent, but can rather describe the
semantics of what different values in different protocol fields mean,
while reiterating the recommendation of RFC 8446 to not reuse tickets.
It seems like we should be able to specify flexible technical mechanisms
without dictating policy.

Other than this bit about giving resumption_count of zero additional
semantics than "I am requesting zero tickets if resumption succeeds", I
actually think this proposal is quite good.  The comments I left on PR
18 are effectively advocating for something like this.

For an example of mechanism without policy, if a client successfully
resumes and asks for zero tickets in the resumption case, but the server
issues a ticket anyway, we can pretty reliably conclude that the
original ticket is no longer valid for resumption.

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Mar 2020 17:30:04 -0800

> such time as reuse becomes specified) need to treat both 0 and 1 as 1.

Is this actually the case, though?  If we keep the signal from server to
client in the echoed extension, the client will know whether or not the
server supports resumption, and thus can ask for the appropriate value 0 or 1
in subsequent handshakes.
It seems like this would avoid the trap of alternating full and resumption
handshakes that was discussed downthread for the case where client supports
reuse but server does not.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Mar 2020 17:37:10 -0800

> accomodates multiple simultaneous writers) would have better

I don't think Viktor's obligated to do so.
Everyone will make their own decisions based on their perception of
the cost of the various options.  While having hard data can be useful
in shaping everyone's perceptions of the cost of a given operation, we should
not expect that this requested hard data will magically force everyone to
behave as if additional ticket issuance has negligible cost.  There may well
be other factors in play, even qualitative ones, including personal opinions
about architecture design, preparedness for large post-quantum certificates
in the future, etc., and Viktor is well within his rights to make such
a decision even in the absence of "hard data" about CPU cycles and bandwidth.
As it happens, Viktor's decisionsi affect a nontrivial amount of internet
traffic due to his role maintaining Postfix.  We can supply facts and
reasoning to attempt to influence his decisions, but they remain his
decisions to make, not ours; I recall that it was previously discussed that
Postfix currently performs ticket reuse *always*, and having the extra
flexibility of the various technical mechanisms under discussion would
allow for that to change and allow for single-use tickets to enter in
the situations where they make sense.

> Hence the interest in server side enforcement of single use tickets.

Please don't assume that the web/HTTP is the only consumer of TLS.
Yes, web servers are very interested in enforcing single-use tickets;
they are not the only kind of TLS server we should consider.

Thanks,

Ben

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 06 Mar 2020 12:37:26 +1100

> 18 are effectively advocating for something like this.

Yeah, I think that's perfect.  We don't have to get into implications or inferences.

> original ticket is no longer valid for resumption.

I wouldn't make any inferences there either :)  But it seems like something that could happen.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Mar 2020 21:27:47 -0500

> in subsequent handshakes.

Yes, if the signal from the server is reliable (e.g. required of servers
that support reuse), and clients are updated to store that signal along
with issued tickets, rather than treating each exchange de-novo, then
yes, you're right the 0->1 becomes inessential.  I addressed this in
response to your pull-request comments.

> reuse but server does not.

Yes, there is some wiggle-room here.  What's your sense of the best
way forward?

-- 
    Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Mar 2020 19:24:01 -0800

> Yes, there is some wiggle-room here.  What's your sense of the best

So far as I know, either version will meet the technical needs, so it's to
large extent a matter of style and "philosophical consistency with the
rest of the protocol".  My personal thoughts are that "make zero mean zero"
makes a lot of sense, and there doesn't seem to be much burden from the
"return whether the server supports reuse" part of things, so if I held the
pen that's what I'd go with.  But I will take whichever version the WG
sends to me for publication.

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Mar 2020 22:35:05 -0500

> sends to me for publication.

The main reason I was reluctant to rely on the echoed extension from the
server is that it changes the data-type of the client's ticket cache, it
is no longer just an array of tickets, there now needs to be additional
associated metadata.  This is likely not a major burden, but a small
potential hurdle.

If we do get to specify reuse, then ultimately either choice can work,
with the new alternative being that an echoed extension supporting
reuse (in whatever form that takes) is required for the client to
attempt reuse.  Perhaps that's the cleaner option.  I failed to
consider making the echoed extension (optional in the original
text) mandatory in the reuse case.  Thanks for noticing.

-- 
    Viktor.