Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

From: "Martin Thomson" <[email-masked]>
Date: Tue, 21 Jan 2020 16:03:46 +1100

On Thu, Nov 21, 2019, at 14:19, David Schinazi wrote:
> Regarding Viktor's suggestion, I personally believe it would increase the
> complexity of the proposal, and I don't see use-cases compelling enough
> to warrant that complexity. I would rather keep this proposal as simple as
> possible.

I see that I didn't respond to this.  I support David's view.

Even the suggestion that clients that resume only request one assumes that clients only want one.  The client probably knows better than we do.  I would rather say nothing about the number and keep it simple. 0 means 0, 1 means 1, N means N.

FWIW, the cost of oversupply is often marginal, depending on circumstances.  In a client-speaks-first protocol with no client certificate, the server can occupy the first round trip with tickets and generally gain a performance advantage (as sending more will increase the congestion window in most cases).  Otherwise, there are usually quiescent periods that can be exploited for sending tickets.  And tickets are small, and cheap to generate.  With one exception: if you are relying on client authentication and packing that into tickets, I'm sorry.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Jan 2020 00:54:11 -0500

On Tue, Jan 21, 2020 at 04:03:46PM +1100, Martin Thomson wrote:

> Even the suggestion that clients that resume only request one assumes
> that clients only want one.  The client probably knows better than we
> do.  I would rather say nothing about the number and keep it simple. 0
> means 0, 1 means 1, N means N.

The proposal has since been simplified. With 1 meaning 1, 2 meaning 2,
...  The only change is that 0 and 255 become special, with 255 meaning
definitely no tickets, and 0 meaning tickets only if the server sees a
need a replace the presented ticket.  Otherwise, the client has no way
to request refresh only if needed, and must ask for 1 just in case.

Unnecessary tickets are a waste server and client resources and
bandwidth, and make external caches "hot" on clients that are perfectly
fine with a slowly changing series of multi-use tickets.

> FWIW, the cost of oversupply is often marginal, depending on
> circumstances.  In a client-speaks-first protocol with no client
> certificate, the server can occupy the first round trip with tickets
> and generally gain a performance advantage (as sending more will
> increase the congestion window in most cases).

This is useless for clients with just a single mult-use slot in their
ticket cache.  Not everything is a web browser.

> Otherwise, there are usually quiescent periods that can be exploited
> for sending tickets.  And tickets are small, and cheap to generate.
> With one exception: if you are relying on client authentication and
> packing that into tickets, I'm sorry.

There's no need to exclude valid use-cases.  The refined proposal
is rather non-invasive, and handles this case cost-effectively
on clients that re-use tickets (and don't use early-data, ...).

-- 
    Viktor.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 21 Jan 2020 19:57:27 +1100

> on clients that re-use tickets (and don't use early-data, ...).

I don't find your arguments persuasive.  This adds complexity specifically to address a case that has - in the general case - suboptimal characteristics, both in terms of forward secrecy and linkability.  Whether or not there are specific cases that might tolerate these suboptimalities, the complexity and risks are borne by everyone.

This is clearly a subjective call, so I'll step back now.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Jan 2020 04:16:18 -0500

On Tue, Jan 21, 2020 at 07:57:27PM +1100, Martin Thomson wrote:

> I don't find your arguments persuasive.  This adds complexity
> specifically to address a case that has - in the general case -
> suboptimal characteristics, both in terms of forward secrecy and
> linkability.  Whether or not there are specific cases that might
> tolerate these suboptimalities, the complexity and risks are borne by
> everyone.

    * Switching to a new ticket is of no help if the server is still
      using the same STEK.  Any forward-secrecy concerns are a function
      of the frequency of STEK rotation on the server.

    * We work in noticeably different application spaces.  SMTP client
      MTAs send 220 greetings and EHLO commands identifying themselves
      in the clear prior to the STARTTLS handshake.  MTAs don't roam
      from network to network, and linkability of traffic is not a
      concern.

    * Postfix, for example, rotates STEKs by default once an hour,
      making the forward-secrecy exposure quite limited. 

    * Clients don't use the same ticket indefinitely, they too discard
      stale tickets, if the server does not beat them to it.

The requested change is rather minimal, it merely asks the server to
intepret 0 as "optional ticket" rather than "no ticket" reserving the
last code point (not uncommon to have make it special) as a no-go
sentinel.

Even if the proposal is not compelling for some, it allows additional
legitimate use-cases at negligible cost.  So barring some actual
problem, it is hard to see on what basis it can be reasonably excluded. 

That's all from me.  Thanks.

-- 
    Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jan 2020 07:17:05 -0800

I agree with Martin that this is unnecessary complexity.

In addition, I would note that switching to a new ticket *does* help even
if the server is using the same STEK because it improves privacy.

-Ekr

On Tue, Jan 21, 2020 at 12:58 AM Martin Thomson <[email-masked]> wrote:

> I don't find your arguments persuasive.  This adds complexity specifically
> to address a case that has - in the general case - suboptimal
> characteristics, both in terms of forward secrecy and linkability.  Whether
> or not there are specific cases that might tolerate these suboptimalities,
> the complexity and risks are borne by everyone.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Jan 2020 15:24:50 +0000

>    This is clearly a subjective call, so I'll step back now.

Yes it is.  But I will say that I agree with you and think the cleverness introduced by the "255 is magic" proposal is not warranted.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Jan 2020 12:44:01 -0500

> I agree with Martin that this is unnecessary complexity.

The objections stated are non-responsive, and dismiss a valid
use-case.

There is ZERO additional complexity.

   - Servers will already range-check the requested ticket count and
     impose some local policy limit.  Treating a request for 255
     as "no tickets please" is NOT complex.

   - Clients that want fresh tickets will send the same request
     they already would have but capped at 254 instead of 255
     tickets.  That's NOT complex.

My proposal only excludes 255 as a valid ticket count.  Nobody can
justifiably insist that it is essential for servers to be able to vend
up to exactly 255 (and not up to 254) tickets.

The extension as *currently* formulated breaks ticket re-use when
employed, it is not possible for a client to signal that it would prefer
to re-use its ticket.

When the extension is not sent, the server can't distinguish between
clients that have not yet adopted it, and clients that wish re-use
tickets, so has to make the wrong guess for at least one of the two
cases.

> if the server is using the same STEK because it improves privacy.

But, as I've explained already, SMTP MTAs are a legitimate use case in
which privacy is explicitly not expected.

   * SMTP MTAs do not and cannot expect privacy against network-layer
     traffic analysis.

     They operate from fixed IPs, with PTRs mapping back to their
     hostnames, whose "reputation" they rely on for deliverability, and
     announce their identity in 220 greetings, EHLO commands and EHLO
     responses in the clear!

     [VALID USE CASE]

   * My proposal, does not FORCE anyone to use either of the special
     values 0 or 255, they can still ask for 1..254 tickets, with
     *zero* change of behaviour.

     Only clients that want to not get a ticket at all, or not get
     one every time, are affected by the change.  Other clients
     do nothing different, they just send an extension asking for
     a number of tickets in [1,254].

     [ZERO COST TO PRIVACY USE CASE]

   * All servers have to do is:

        - Send [1,254] (likely fewer at the high end) tickets when
          that many are requested, as before.  [ With or without
          my proposal, they'll still do a range check of some
          sort to compare with their local policy limits. ]

        - Send no tickets when 255 are requested, a negligible
          adjustment to their range check.

        - Send 1 ticket when 0 are requested and they don't support
          re-use, or the received ticket is invalid (support for
          ticket re-use which worked

        - send 0 tickets are 0 are requested and the received ticket is
          still valid.

      [ZERO COST TO SERVER USE CASE, plus makes possible to signal
       and support ticket reuse]

It is unjust to deny a ZERO COST valid use-case just because that's not
the use-case one is most familiar with.

This is the TLS working group, not the browser HTTPS working group, and
needs to be open to more than than one use-case.

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Jan 2020 12:47:22 -0500

On Tue, Jan 21, 2020 at 03:24:50PM +0000, Salz, Rich wrote:

> Yes it is.  But I will say that I agree with you and think the
> cleverness introduced by the "255 is magic" proposal is not warranted.

Really? TLS has no sentinel code ponts? No SCSVs?

This is not a substantive objection.

-- 
    Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Jan 2020 18:19:23 +0000

Viktor and I spoke in more detail.  The use-case he brings up makes more sense to me now. The key observation is that this is not about a "client" in the conventional (or browser) sense, but rather more like a peer-to-peer kind of thing, where the client is just the one who initiates a connection and might be multiple processes running on multiple instances sharing an identity.

I'm in favor of his suggestion.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jan 2020 13:17:59 -0800

I would make several points here:

1. RFC 8446 explicitly discourages ticket reuse
   (https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we
   should not be designing an extension to enable reuse. While it's
   potentially true that some applications do not benefit from
   non-reuse, creating a set of mechanisms around reuse risks those
   mechanisms being used in settings where reuse would be
   bad. Moreover. just because at present sending MTAs have weak
   privacy properties does not mean that we should bake in this
   situation permanently.

2. The additional cost of multiple tickets seems extraordinarily
   small, so I am not at all persuaded that there is enough value in
   this use case to justify adding new protocol machinery, even
   ignoring point (1) above.

3. If there *is* such value, then you can register your own extension
   which allows you to say the orthogonal thing, namely "don't send me
   any tickets at all if you are resuming". This would be more
   flexible in that you could then say "I would like 10 tickets, but
   only if you don't resume". Note that
   https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ would
   allow you to do this efficiently.

Thus, I would prefer to advance this document as-is.

-Ekr

On Mon, Jan 20, 2020 at 9:54 PM Viktor Dukhovni <[email-masked]>
wrote:

> ....  The only change is that 0 and 255 become special, with 255 meaning

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Jan 2020 17:46:10 -0500

>    privacy properties does not mean that we should bake in this

Indeed I agree that ticket reuse is often undesirable, and expect that
it will be avoided in many cases.  So I am somewhat sympathetic to the
above as a starting point for the analysis.

That said, I don't see that making reuse easier to negotiate is likely
to create significant opportunities for misuse.

    - Both the client *and* the server would need to opt-in to reuse.

      * Even if the client asks for reuse, the server can invalidate
        the old ticket (something it would need to be able to do
        already to ensure non-reuse) and send a fresh one anyway.

        The client would have to replace the old with the new, since
        it has to assume that the old is now likely invalid.

      * Even if the server is willing to reuse, if the client asks
        for a new ticket, the server has to assume the client has
        a single-use cache, and should vend a new ticket.

      so it takes bilateral coordination to arrive at reuse, and
      so accidental reuse in applications where it is inappropriate
      requires errors on both ends.

>    ignoring point (1) above.

Postfix has a shared cache (indexed by destination domain+mx host) for
multiple independent processes racing to use the cache to make remote
SMTP connections.

Frequent writes to that cache create measurable overhead and still don't
prevent reuse.  Transmission of unnecessary tickets is also wasteful of
network and other server resources.

Erasing tickets on first use would be unwise, most existing servers will
not presently return a fresh ticket on resumption.

>    allow you to do this efficiently.

This is an interesting idea, but how would the two extensions interact?
And wouldn't that interaction add more complexity?  By hypothesis
clients that are willing to reuse tickets don't really need more than
one at a time.  Is there a clear use case for multiple concurrent
reusable tickets.

> Thus, I would prefer to advance this document as-is.

Thanks for the substantive response.  Much appreciated.  I hope you're
willing to address the above reaction, I am trying to find common
ground that addresses your concerns and mine.

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Jan 2020 17:53:28 -0500

> multiple independent processes racing to use the cache to make remote

I should add that currently Postfix servers with OpenSSL 1.1.1 (i.e.
with TLS 1.3 support) always send 0 tickets on resumption, i.e. expect
that SMTP clients are willing to reuse the previously vended ticket.

Thus a key benefit of the proposed refinement to the extension would be
to allow SMTP clients that want a fresh ticket to unambiguously signal
that intent, and thereby allow *greater* use of single-use tickets.

It would also Postfix differentiate between MTAs and MUAs, where the
latter are likely to want fresh tickets, but even on port 587 or
465, not all clients are MUAs, some are null-client MTAs relaying
to a "smarthost".

--  
    Viktor.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 21 Jan 2020 20:32:20 -0500

I support the proposal from Viktor. It is important to minimize the
involved resource and provide the client the ability to explicitly inform
the server its policy.

As explained above, this mechanism comes with no additional complexity and
address a full range of applications.

See below my comments inline:

Yours,
Daniel

>    privacy properties does not mean that we should bake in this

 Appendix C.4 discourages the re-use of tickets to avoid passive
monitoring. This recommendation only applies when privacy is involved, and
other use cases exist (VNF, IoT, MTA,...). This is not *potentially* true,
this is simply true. These use cases are considered by RFC8446 and thus
need be considered in this proposal.

>    ignoring point (1) above.
As explained before, the *machinery* is also largely exaggerated. Those for
who the cost of generating ticket is so extraordinarily small actually do
not need this extension and can generate an extra large number of tickets
(at no cost for them).  This statement seems to contradict at least the
Less ticket waste use case.  In addition, saving cost per connection scales
the number of connections which is not negligible.

>    allow you to do this efficiently.

It is unclear to me why, in this case, this would apply specially to
Viktor's proposal rather the counter proposal.

>> .....  The only change is that 0 and 255 become special, with 255 meaning

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Jan 2020 18:55:49 -0600

On Tue, Jan 21, 2020 at 06:19:23PM +0000, Salz, Rich wrote:
> Viktor and I spoke in more detail.  The use-case he brings up makes
> more sense to me now. The key observation is that this is not about a

I also spoke to Viktor, and he explained the motivation in detail.  He
really should have done so on the list, but it is this:

    TL;DR: Postfix multi-process ticket cache DB thrashing pain.

 - Postfix (which he co-maintains) is a multi-process service (with
   client and server functionality -- it's an MTA, after all)

 - Postfix needs a multi-process ticket cache w/ concurrency

 - OpenSSL provices no such thing, only a single process in-memory
   cache, and also callbacks the app can use to implement its own cache,
   which then Postfix uses to implement a multi-process ticket cache

 - So, getting unnecessary tickets thrashes Postfix's shared cache,
   which costs a fair bit due to synchronization

There are two ways to make this tolerable for Postfix:

 - either the TLS server says "here's a ticket and you MUST or MAY
   replace the one you already had"

   or

 - the TLS client gets to ask for no unnecessary new tickets

Now the first alternative would be infeasible to adopt because it would
require new OpenSSL callback APIs, and anyways would be a more invasive
change to TLS than the ticketrequest extension makes.

That's why Viktor would prefer the other way: let the client ask for no
unnecessary new tickets.  This has the benefit of saving some bandwidth
and server cycles.

Now, as to the privacy issue.  The server can simply always issue a new
ticket, even if the client didn't want it -- presumably MTAs wouldn't,
but HTTP servers would.  And there is no way for -say- a great firewall
to force you to not get new tickets as the server can still always hand
the client one, and anyways, this extension can be (should be!)
encrypted, so the firewall can't know anyways.  All a great firewall
gets to see is that your connections can or can't be linked.  Especially
given Viktor's use case, we can assume (and require, evven) that only
SMTP MTAs might request no new unnecessary tickets, so that great
firewalls really can make no assumptions about this in HTTP use cases,
say.

> "client" in the conventional (or browser) sense, but rather more like
> a peer-to-peer kind of thing, where the client is just the one who
> initiates a connection and might be multiple processes running on
> multiple instances sharing an identity.
> 

Me too.

It's really very simple.  There is no legitimate "unnecessarily complex"
argument; such arguments come across as unnecessarily dismissive.

There is a privacy non-issue, addressed as above, though it's fair to
demand that it be addressed.

Regarding the "define your own extension" responses...  That's fine, I
suppose, but why ever bother with WGLCs for these if changes that
benefit others will generally be rejected out of hand?  Why require TLS
WG review of extensions?  Why not just make an Expert Review registry?
I think the answer to the last question is that we're not ready for that
-- we want some WG review, and, presumably, we want some commonality.
So, unless we're going to go with Expert Review only, then please do not
make this "define your own" argument -- it's at the very least impolite.

Nico

PS: Viktor tells me that hey, I've advised him to keep posts pithy, thus
    he elided all the above explanation, but really, IMO, he should have
    explained in detail.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 22 Jan 2020 17:12:34 -0800

> change to TLS than the ticketrequest extension makes.

Nothing says you have to remember tickets, so unless I'm missing
something the semantics already are the second one.

Am I being silly?

Sincerely,
Watson

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Jan 2020 21:14:55 -0500

> something the semantics already are the second one.

I want to use tickets for resumption, so naturally I have to remember
them.  I also don't actually get to directly see the tickets, rather
OpenSSL invokes a "new_session_cb" callback after updating the current
session with newly received tickets.

Since I have a shared cache, I have to perform the work of storing the
updated sesion, so that other SMTP delivery agents get to see the new
ticket.

I can't just ignore the ticket, since the reason for the new ticket may
be that the old one has expired, either after some period of reuse, or
because the server only ever issues single-use tickets.

The deployed base of Postfix servers issues multi-use tickets (always,
there's no extension to tell me otherwise), and sends zero tickets
on resumption, so I need to not just throw away tickets that are
still valid.

-- 
    Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Jan 2020 22:33:48 -0600

> something the semantics already are the second one.

That's the thing: the idea is to have one-time tickets, and keep
replacing them as you use them.

If that's never the case, then indeed, no change is needed (except maybe
to say that it's never the case).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Jan 2020 22:35:43 -0600

> to say that it's never the case).

Ay no, per-Viktor's follow-up, the client still needs some additional
information.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 23 Jan 2020 12:57:31 +0100

> on resumption, so I need to not just throw away tickets that are

I wonder if the approach with a database with strict ACID-ity is the 
correct
one for ticket storage.

What I mean, is that, especially in postfix case, using slightly older 
ticket
that it could will have minimal impact on the connection. Thus a database
that is basically append only, with clients that look for newest ticket
(and disregard races on this lookup) and a garbage-collection process that
removes old tickets every few hours will work ok.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Jan 2020 07:40:55 -0500

On Thu, Jan 23, 2020 at 12:57:31PM +0100, Hubert Kario wrote:

> correct one for ticket storage.

It isn't "strict acidity", but there never more than one ticket per
peer, stores replace the existing entry, loads read the latest entry
stored.

> ticket that it could will have minimal impact on the connection.

Slightly older is unavoidable, because time passes between configuring
an SSL connection to use a particular session and actually using it.

If tickets rotate too fast, busy Postfix SMTP clients will frequently
end up with stale tickets, and will fail resumption much of the time.

The server accepts reuse, and defaults to assuming that the client is
willing to reuse.

If the extension provides a tiny bit more signalling at no cost to
applications that have no use for reuse, then I'll be able to also
support clients that explicitly signal non-reuse (e.g. MUAs talking
to a service that is both MSA and SMTP relay).

> Thus a database that is basically append only, with clients that look
> for newest ticket (and disregard races on this lookup) and a
> garbage-collection process that removes old tickets every few hours
> will work ok.

There is indeed a GC process, but we're using off-the-shelf indexed
file dabases (Berkeley DB or LMDB), which are not append only.  And
in any case, this is rather tangential.

The real issue is that I'd like to offer clients that don't reuse a
fresh ticket, but allow clients that do reuse to continue to do that.

Anyway, I wanted to avoid TL;DR, and just present an argument based
largely on:

    - No actual complexity to those that don't ever want reuse
    - Pontential savings to those who for some reason do reuse.

That really ought to be enough, given that ignoring the reuse
case and always issuign a ticket is *free*:

    /* Hande non-use, ignore reuse, and impose local limit */
    if (ticknum == 0) ticknum = 1;
    else if (ticknum == 255) ticknum = 0;
    else if (ticknum > ticklimit) ticknum = ticklimit;

    /* now proceed as in previously solved problem */

  v.s. extension as-is:

    /* Impose local limit */
    if (ticknum > ticklimit) ticknum = ticklimit;

That's a totally trivial change that yields status-quo, but allows other
implementations to do something more intelligent with "ticknum == 0".

-- 
    Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 23 Jan 2020 09:43:21 -0800

> fresh ticket, but allow clients that do reuse to continue to do that.

Sending a new ticket doesn't force clients to store it.

>     else if (ticknum > ticklimit) ticknum = ticklimit;

What if we reverse the 0 and 255 case, and use the number 1 to mean 1? Now
the code is a no-op.

I still don't get the savings: tickets are free for the server and clients
can always not store them. With 0-rtt single use tickets are a lot more
compelling.

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Jan 2020 13:32:51 -0600

> Sending a new ticket doesn't force clients to store it.

Sure, but if the old ticket will not be accepted again then the client
will incur a full handshake later.  The client doesn't know if the old
ticket will or will not be accepted again.  Extending the protocol to
have the server signal that bit will require new OpenSSL extensions,
which is why that is not a sufficiently good response to the Postfix
issue.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Jan 2020 16:01:51 -0500

> which is why that is not a sufficiently good response to the Postfix

Indeed, not storing the ticket breaks resumption.  So I always store the
ticket (actually what OpenSSL hands me is a serializable opaque
SSL_SESSION).  For example, when the server allows reuse, but has a
shorter maximum ticket lifetime, its "as needed" new ticket needs to be
stored, in order to replace a stale cached session and start using the
fresh one.

Regardless, I also believe that not applications need or want the
marginal privacy offered by single-use tickets (none for clients
with stable dedicated IP addresses) and it should be possible
in such cases (at effectively zero cost as proposed) to negotiate
reuse in a way that allows servers to handle both types of client.

This would allow Postfix to vend single-use tickets to clients
that request that (e.g. MUAs).  Right now the code is statically
optimized for the MTA-to-MTA use-case.

So making reuse *negotiable* would in fact enhance privacy for MUAs on
ephemeral IPs sending sufficiently frequent email (from behind a NAT or
otherwise shared or changing address) to a sufficiently popular
submission server that it is not trivial to link resumed TLS sessions to
a given client.

-- 
    Viktor.

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 31 Jan 2020 09:06:12 -0800

First off, thanks for the lively discussion on ticket reuse! I think it's a valid use case and something that should continue to be discussed.

However, for the purposes of the WGLC for this draft, draft-ietf-tls-ticketrequests, it may be best to separate the conversation. It seems that the negotiation of ticket reuse would be best served by another document that could be adopted by the WG. The ticket request document, as it was adopted, was specifically a mechanism to request multiple tickets so as to *avoid* ticket reuse. This is stated several times in the use cases (section 2) and security considerations (section 5). While this does not preclude a future extension that negotiates ticket reuse, I believe, as an author, that enabling ticket reuse is out of scope of this particular document.

Best,
Tommy

> On Jan 23, 2020, at 1:01 PM, Viktor Dukhovni <[email-masked]> wrote:
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 31 Jan 2020 17:27:16 -0500

On Fri, Jan 31, 2020 at 09:06:12AM -0800, Tommy Pauly wrote:

> However, for the purposes of the WGLC for this draft,
> draft-ietf-tls-ticketrequests, it may be best to separate the
> conversation. It seems that the negotiation of ticket reuse would be
> best served by another document that could be adopted by the WG. The
> ticket request document, as it was adopted, was specifically a
> mechanism to request multiple tickets so as to *avoid* ticket reuse.

Yes, but the issues DO NOT decouple.  It is a mechanism to communicate
the client's ticket requirements to the server.  Many clients will
want multiple tickets unconditionally, some will want none, or only
one as the presented one becomes no longer valid.

The use-case is that the Postfix SMTP server currently always vends
replacement tickets ONLY when expiring.  I'd like to be able to
distinguish between clients that always want fresh tickcets (MUAs)
and clients that don't (MTAs).  This will also reduce ticket reuse.

> This is stated several times in the use cases (section 2) and security
> considerations (section 5). While this does not preclude a future
> extension that negotiates ticket reuse, I believe, as an author, that
> enabling ticket reuse is out of scope of this particular document.

The two extensions will be in conflict.  There's a trivial solution
within the existing extension.  One code of 255 fully addresses the
issue, with no additional document required.

Proliferation of conflicting documents does not help implementors.
Let's address the issue before us in a single document.  Reuse
is not a separate issue, both are just ticket quantity negotiation.

-- 
    VIktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jan 2020 17:55:35 -0600

On Fri, Jan 31, 2020 at 09:06:12AM -0800, Tommy Pauly wrote:
> First off, thanks for the lively discussion on ticket reuse! I think
> it's a valid use case and something that should continue to be
> discussed.
> 

Viktor's comment came before the end of WGLC, so the WG needs to
consider his comments, and needs to reach consensus.  Considering the
fact that cosensus has not yet _obviously_ been reached (there have been
positive and negative responses), the WG's chairs may need to make a
call for consensus (or maybe the chairs think consensus is obvious?).

Consider this my encouragement to the chairs that they make a call for
consensus.

> mechanism to request multiple tickets so as to *avoid* ticket reuse.

TLS 1.3 already does that.

The adoption call is nowhere near as specific -- in fact, it says
nothing about purpose of the extension.

The TLS WG charter doesn't mention it.

The abstract of this I-D says, among other things:

   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.

That number could be zero, and indeed, that's allowed.  "Zero unless you
won't allow me to reuse this one" seems clearly in-scope to me.  That
you have no need for it, doesn't make it out of scope or a bad idea.

Moreover, I posted an explanation of why this extension will cause
Postfix trouble.  That deserves a substantive response (and IETF process
may even demand it).

Nico
--

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 1 Feb 2020 00:43:17 +0000

+1 to what Nico says.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 31 Jan 2020 16:58:07 -0800

On Fri, Jan 31, 2020 at 3:56 PM Nico Williams <[email-masked]> wrote:

> consider his comments,

Yes.

> and needs to reach consensus.
>

No. This draft should move forward.

thanks,
Rob

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jan 2020 19:11:16 -0600

> No. This draft should move forward.

WGLCs are not about finding and discussing spelling errors.  This is not
how the Standards-Track RFC publication process works.

Nico
--

---

From: Rob Sayre <[email-masked]>
Date: Fri, 31 Jan 2020 17:15:40 -0800

> how the Standards-Track RFC publication process works.

If the scope of a document can be continually expanded during last call, it
can be indefinitely postponed.

thanks,
Rob

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jan 2020 19:23:04 -0600

> can be indefinitely postponed.

There is no attempt to postpone, and the WGLC has finished.  No new
issues will be raised.  But the ones that were raised _will_ be
addressed.  Being left on the rough side of consensus happens; having
substantive issues raised in a timely manner ignored must not.

The IETF is not a rubber-stamp SDO.  We have a process.  We don't just
pay it lip service.  WGLC is not going through the motions.  The
prescribed process will be followed.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 31 Jan 2020 20:24:24 -0500

> On Jan 31, 2020, at 8:15 PM, Rob Sayre <[email-masked]> wrote:
> 
> If the scope of a document can be continually expanded during last call, it can be indefinitely postponed.

I'm not proposing a change of scope.  The document specifies how a client
and server negotiate the number of tickets the server should send.  This
remains the case.  The -04 document leaves out a relevant scenario where
the client does want tickets to be refreshed (so not unconditionally zero),
but does not want gratuitous tickets (new one each time).

The scope of the document per the abstract includes the following:

   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

My proposal falls squarely in the "in order to reduce ticket waste" category.

-- 
	Viktor.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 31 Jan 2020 17:43:36 -0800

On Fri, Jan 31, 2020 at 5:24 PM Viktor Dukhovni <[email-masked]>
wrote:

> I'm not proposing a change of scope.

...

> The -04 document leaves out a relevant scenario...
>

That sounds like a change of scope, but reasonable people can disagree.

thanks,
Rob

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jan 2020 19:47:57 -0600

On Fri, Jan 31, 2020 at 05:43:36PM -0800, Rob Sayre wrote:
> ....

The scope was never sufficiently well defined to begin with.  I went
through the adoption thread and the WG charter.

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jan 2020 19:48:45 -0600

> through the adoption thread and the WG charter.

Oh, and I'm not conceding that the proposed change would be a scope
change even if the scope had been sufficiently well defined.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 31 Jan 2020 20:51:48 -0500

On Fri, Jan 31, 2020 at 8:16 PM Rob Sayre <[email-masked]> wrote:

> It is unclear to me how this applies here. Could you be a bit more
explicit and state what, in your opinion, is continually expanding ?

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 31 Jan 2020 17:53:50 -0800

Hi Viktor,

> On Jan 31, 2020, at 5:24 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

The document also is focused on use cases that are all about "avoid[ing] ticket re-use". The security considerations state that "Ticket re-use is a security and privacy concern".

While there are some use cases in which ticket re-use allows the reduction of ticket waste, we cannot state that every possible approach to reduce ticket waste is in scope for this particular document. Rather, this document defines its scope as simply: "This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections." Enabling ticket reuse is not part of that scope.

Beyond discussing scope creep, I think an even bigger reason to decouple the idea of ticket requests from explicit ticket re-use is the notion of working group consensus. I think the WG has clearly expressed consensus on the fact that ticket requests are a useful and non-harmful extension. Indeed, the proposals to add ticket reuse logic to ticket requests that you want relies on such an extension. However, the group certainly does not seem to have consensus on the idea that there should be an extension to allow ticket reuse. As an author, I don't know if I'd support that. Thus, the working group can progress with the tightly-scoped document that it has consensus on, and leave other use cases to future documents.

Thanks,
Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 31 Jan 2020 17:59:23 -0800

Hi Nico,

As a point on the process, I don't think anyone is proposing rubber-stamping. We are instead only suggesting that a set of work that has consensus does not need to be held up by adding new work that does not have consensus.

The outcome of points raised during a WGLC does not need to be a change in the document, if the group does not have consensus that the suggested change is correct. Particularly, as in this case, a comment during WGLC to add new functionality that is not part of addressing the intended scope of a working group deliverable does not need to be added before progressing. I think this is a case in which we have consensus on the basic ticket requests, but adding ticket reuse is (based on the way this thread has not converged) is in the rough. 

Thanks,
Tommy

> On Jan 31, 2020, at 5:23 PM, Nico Williams <[email-masked]> wrote:
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 31 Jan 2020 21:06:57 -0500

> On Jan 31, 2020, at 8:53 PM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Thus, the working group can progress with the tightly-scoped document that it has consensus on, and leave other use cases to future documents.

Such a deferral may be desirable and viable in cases where the
features are sufficiently orthogonal.  But here the extension
specifies the number of requested tickets, and so any separate
document would have to change the semantics of this extension
in order to get conditional issuance of tickets.

It makes no sense to split the negotiation of the ticket number
over multiple documents.  The added use-case is effectively
*free* to ignore by implementations that never want reuse,
just treat zero as 1, and be done.

If this were a major burdensome feature, I'd be sympathetic to
your desire to carve it out to a separate discussion.  But here,
I'm pretty consensus will be reached soon after we stop focusing
on the legitimacy or timing of the proposal and focus on its
substance in a final wrap-up consensus call.

I may end up in the rough, but let's at least see where the chips
fall.

The security considerations can continue to discourage reuse where
traffic analysis is a concern.  It is NOT a concern in MTA-to-MTA
traffic.  If my proposal moves forward, I'll gladly contribute
some text to the security considerations discouraging wanton
application of ticket reuse.  It should be enabled only where
appropriate.

Note that I'd like to use this extension to conditionally enable
non-reuse where presently re-use is unconditional.  Otherwise,
Postfix will just always go with reuse.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jan 2020 20:07:26 -0600

On Fri, Jan 31, 2020 at 05:59:23PM -0800, Tommy Pauly wrote:
> As a point on the process, I don't think anyone is proposing
> rubber-stamping. We are instead only suggesting that a set of work
> that has consensus does not need to be held up by adding new work that
> does not have consensus.

A substantive issue was raised.  Until that is disposed of through
normal consensus-finding mechanisms, there is no consensus for the I-D
to progress.  That's how the process works.

> The outcome of points raised during a WGLC does not need to be a
> change in the document, if the group does not have consensus that the

Correct.  But first that consensus needs to be reached.

> suggested change is correct. Particularly, as in this case, a comment
> during WGLC to add new functionality that is not part of addressing
> [...]

That's not how the process works.  Of course a substantive issue raised
at WGLC or IETF LC time (or IESG review time) can require new
functionality to be addressed properly!

There is no rule that no functionality may be added as a result of a
WGLC/IETF LC comment.  Or that comments that would require new
functionality can be rejected by the I-D's authors alone.

Nico
--

---

From: Rob Sayre <[email-masked]>
Date: Fri, 31 Jan 2020 18:12:26 -0800

> to progress.  That's how the process works.

Explain your reasoning.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 1 Feb 2020 02:13:37 +0000

Hiya,

I have no particular position about this draft but
am curious about 2 things:

#1 I don't get why it's not possible for postfix to
determine the best way to manage tickets based on the
destination port to which the ClientHello is sent. I
totally get why that won't solve 100% of cases, but it
would surely solve a huge percentage? Apologies if an
answer was already posted as part of this v. long
thread.

#2 I don't get why Viktor's request for special handling
for value 255 is a real problem for anyone. We have
another thread today envisaging 2040 extensions flags,
so I really have a hard time seeing what here justifies
rejecting Viktor's argument. FWIW, this thread has not
provided me with an obvious answer to #2 other than "not-
invented-here." I'm not sure that declaring things in the
rough where the only identifiable issue is NIH is the
overall best outcome, longer term.

Cheers,
S.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 31 Jan 2020 21:19:48 -0500

> overall best outcome, longer term.

+ 1 I have not seen any technical answer either for not considering this
mechanism.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 1 Feb 2020 02:21:00 +0000

*   If the scope of a document can be continually expanded during last call, it can be indefinitely postponed.

No, the WG can get consensus on not expanding scope.

It’s not great that this came up with WGLC, but several folks in the WG now recognize that this is an important use-case and feel it’s in-scope.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 31 Jan 2020 18:25:38 -0800

On Fri, Jan 31, 2020 at 6:21 PM Salz, Rich <[email-masked]> wrote:

>
>
>    - If the scope of a document can be continually expanded during last
>    call, it can be indefinitely postponed.
>
>
>

That's true, but there's no need to stop if the expanded scope doesn't have
consensus.

> It’s not great that this came up with WGLC, but several folks in the WG
> now recognize that this is an important use-case and feel it’s in-scope.
>

Not sure "several" is the correct term. There are some mailing list
messages about the topic.

thanks,
Rob

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 1 Feb 2020 02:30:47 +0000

>Not sure "several" is the correct term. There are some mailing list messages about the topic.

A few people who are heavily involved in this WG have agreed this is an issue, and a few people aren’t.  Shrug.  As Nico said, time for a consensus call or more likely a discussion in Vancouver.  I think I’m done adding useful content to this thread.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 31 Jan 2020 18:36:49 -0800

On Fri, Jan 31, 2020 at 6:30 PM Salz, Rich <[email-masked]> wrote:

> *>*Not sure "several" is the correct term. There are some mailing list
> A few people who are heavily involved in this WG have agreed this is an
> issue, and a few people aren’t.  Shrug.  As Nico said, time for a consensus
> call or more likely a discussion in Vancouver.
>

Sounds important.

> I think I’m done adding useful content to this thread.
>

Agree.

thanks,
Rob

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 1 Feb 2020 02:38:37 +0000

On Fri, Jan 31, 2020 at 6:07 PM Nico Williams <[email-masked]<mailto:[email-masked]>> wrote:

  *   Explain your reasoning.

Sec 7 of RFC 2418 (IETF Working Group Guidelines and Procedures):  A working group Last-Call serves the same purpose within a working group that an IESG Last-Call does in the broader IETF community.

Sec 14 of RFC 2026 (The Internet Standards Process -- Revision 3): “Last-Call - A public comment period used to gage the level of
      consensus about the reasonableness of a proposed standards action.”

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 1 Feb 2020 00:31:12 -0500

On Sat, Feb 01, 2020 at 02:13:37AM +0000, Stephen Farrell wrote:

> #1 I don't get why it's not possible for Postfix to determine the best
>    way to manage tickets based on the destination port to which the
>    ClientHello is sent. I totally get why that won't solve 100% of
>    cases, but it would surely solve a huge percentage? Apologies if an
>    answer was already posted as part of this v. long thread.

The Postfix SMTP server does not actually create the listener socket,
and may not even be getting the traffic directly from the network
(e.g. haproxy, postscreen, DNAT, ...).

Such a heuristic would require action from the server administrator to
configure appropriate policy for each non-default instance of an SMTP
service, and would then still yield only approximately correct results.
SMTP relays aren't always on port 25, and services that are dedicated
MSAs are sometimes in fact on port 25.

Also, though I wish other MTAs that support TLS resumption would also
reuse tickets, avoiding waste.  I don't know what TLS stacks they use,
and whether they need or don't need fresh tickets.  And coversely not
every server Postfix connects to is also Postfix, and those may have a
different default behaviour.

So I'm looking for a mechanism (absolutely trivial per #2 below) to
allow the client to signal to the server its ticket-use preference
so that the server can vend the right number of tickets (which is
the scope of this extension).

> #2 I don't get why Viktor's request for special handling for value 255
>    is a real problem for anyone. We have another thread today
>    envisaging 2040 extensions flags, so I really have a hard time
>    seeing what here justifies rejecting Viktor's argument. FWIW, this
>    thread has not provided me with an obvious answer to #2 other than
>    "not- invented-here." I'm not sure that declaring things in the
>    rough where the only identifiable issue is NIH is the overall best
>    outcome, longer term.

I am also puzzled by the reticence to make the trivial change that makes
the mechanism more expressive at negligible cost, and move on.  That too
advances the draft.  I want to see this draft move forward, that's why
I am bothering to try and make it cover the missing piece of the puzzle.

There is NO obligation on either party to enable reuse even if the
client sends the "as necessary" sentinel (0).  The server can just vend
1 new ticket in that case, and the client would need to assume the
previous one invalid and use the new one for the next connection.

The proposal does not change the security posture of any systems that
don't want to support reuse.  Also the draft as written does not prevent
consenting peers from doing reuse, it just fails to provide them with a
simple mechanism to negotiate a mutually compatible policy.

When the two ends make differt assumptions you get either waste or
insufficient tickets to meet the client's needs.

Let's make a small change to the code points to enable more precise
negotiation and move on...

-- 
    Viktor.