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

From: Tommy Pauly <[email-masked]>
Date: Sat, 01 Feb 2020 07:53:57 -0800

> On Jan 31, 2020, at 6:14 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 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.

That’s a fair point, and worth clarifying. Totally agree that NIH isn’t a good reason. Instead, it seems unclear what value the special use of 0 and 255 adds that wouldn’t be better served by a separate extension.

Today, without any sentinel values, 0 means the client hints that it doesn’t need any tickets, and N means that the client hints that it would like N tickets. Whether or not a ticket is intended to be reused is not part of this, and ticket reuse is elsewhere discouraged.

As far as I understand the proposal, the meaning currently expressed by sending 0 would be expressed by sending 255 instead; and sending 0 would take on a new meaning that is “send a ticket if you want, and I may try to reuse a ticket if you don’t send one”, which seems like the behavior already expressed by not sending the ticket request message at all (since not passing the message is equivalent to no hint).

To that end, the proposed change doesn’t seem to add any new signaling capabilities, but makes the meanings of numbers less intuitive.

If the hint is intended to be “I’m planning on reusing tickets, let me know ahead of time if I shouldn’t”, that seems like it could be an explicit signal sent that doesn’t need to reuse a field that is a numeric count of tickets being requested. It seems like there is a small number of clients that would use this, so adding another message to signal this and potentially more info about reuse policy would make more sense and could be fleshed out in more detail separately. For example, if we add the proposed hint that presumably means “if you give me a new ticket, I’ll use it; but if you don’t, I’ll reuse an old one”, the client is essentially forcing a server that doesn’t want ticket reuse to issue a new ticket; whereas a more explicit signal could indicate that the server won’t allow ticket reuse, so the client shouldn’t even try, etc, without necessarily giving out new tickets. 

Best,
Tommy

> 
> Cheers,
> S.
> 
> <0x5AB2FAF17B172BEA.asc>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 1 Feb 2020 20:30:16 -0500

On Sat, Feb 01, 2020 at 07:53:57AM -0800, Tommy Pauly wrote:

> Instead, it seems unclear what value the special use of 0 and 255 adds
> that wouldn’t be better served by a separate extension.

The benefit of the new value of "0" is *unambiguous* signalling that the
client would like to reuse the ticket if possible, and the new "255"
then carries the "We don't need no stinking tickets" signal.

> Today, without any sentinel values, 0 means the client hints that it
> doesn’t need any tickets, and N means that the client hints that it
> would like N tickets. Whether or not a ticket is intended to be reused
> is not part of this, and ticket reuse is elsewhere discouraged.

And the same remains true with my proposal, with the only difference
being that 0 replaced by 255, and the new 0 as discouraged as it was
before.

Nothing we do or can do prevents a *consenting* client and server from
reusing tickets, no matter what form this extension ultimately takes.

All I'm proposing is a minor change to allow the consent to be
negotiated, rather than guessed unilaterally by the server, likely
incorrectly in various cases.

With negotiated consent, clients that don't want to reuse talking to a
server that supports reuse will get fresh tickets.  Otherwise, they
don't, and end up doing a full handshake 50% of the time.

> As far as I understand the proposal, the meaning currently expressed
> by sending 0 would be expressed by sending 255 instead;

Correct.

> and sending 0 would take on a new meaning that is “send a ticket if
> you want, and I may try to reuse a ticket if you don’t send one”,

Correct.

> which seems like the behavior already expressed by not sending the
> ticket request message at all (since not passing the message is
> equivalent to no hint).

No, it is not, because not sending the extension is status quo, and will
be for quite some time as the extension will not be available to most
clients for quite some time.

Is it your position that once the extension is defined, servers should
assume a desire or willingness to reuse if the extension is not sent?

If the document makes it clear, that *absent* the extension servers that
are *willing* to support reuse SHOULD impute that the client is willing
to reuse (and thus clients that don't reuse need to send the extension
to ensure any fresh tickets on resumption):

    Then indeed the desired signal becomes not sending the extension.

But, that would mean that legacy clients that don't implement the
extension get presumptive reuse (from reuse-supporting servers)
for quite some time as the extension gradually gets adopted.  If
that's OK, then let's specify that.

> To that end, the proposed change doesn’t seem to add any new signaling
> capabilities, but makes the meanings of numbers less intuitive.

Well, it makes the signalling unambiguous, given that without this
extension we presently have no indication of client preference.  If
however, the extension redefines absence of signal to mean willingness
to reuse if the server so chooses, then the ambiguity goes away, and
implementations that support conditional reuse default to reuse on
not receiving the extension.

This makes reuse be "opt-out", rather than "opt-in".  Which may not
be the best way to discourage it, but once the extension is broadly
supported (and enabled by default) the difference starts to fade.

> If the hint is intended to be “I’m planning on reusing tickets, let me
> know ahead of time if I shouldn’t”,

No, the hint is simply "send me a new ticket if I can't (already
expired) or shouln't (will soon expire) reuse what I just sent".

> It seems like there is a small number of clients that would use this,

Just a few million MTAs, on-prem industrial controllers, ...

> For example, if we add the proposed hint that presumably means “if you
> give me a new ticket, I’ll use it; but if you don’t, I’ll reuse an old
> one”, the client is essentially forcing a server that doesn’t want
> ticket reuse to issue a new ticket

No.  Clients can attempt reuse no matter what the server does, but
they SHOULD use any fresh ticket from the server because the server
may no longer accept the old one.  With or without this extension
a server that does not want reuse should vend a fresh ticket unless
it knows that the client does not to resumption at all (255 or 0,
wherever the chips fall).

> whereas a more explicit signal could indicate that the server won’t
> allow ticket reuse, so the client shouldn’t even try, etc, without
> necessarily giving out new tickets. 

Well, that's a completely different server->client signal, saying "don't
reuse", and does not replace the proposed "client->server" signal.  But
it makes no sense for servers to refuse reuse and also not vend fresh
tickets, unless they simply don't support resumption and never vend
tickets in the first place (in which case no such signal is needed).

Therefore the way to indicate that a ticket is no longer valid is to
issue a replacement ticket (possibly after performing a full handshake
to revalidate the client cert, if the session is too old).  This
largely obviates any need for a server->client signal.

A server can also always refuse old tickets (but that requires keeping
track of sufficiently recently used tickets).

Above I said "largely obviates", because a client making parallel
connections might race to reuse a ticket in parallel before any
of the parallel connections return a fresh ticket.

Therefore, a signal from server to client meaning "my tickets
are single-use" is potentially useful.  If so, it should be
in the server variant (response) of this extension.

-- 
    Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 1 Feb 2020 19:04:53 -0800

> then carries the "We don't need no stinking tickets" signal.

Brown sticker conventions belong in the Bermuda Bowl, not TLS. I'd be
happier with a magic 0, or a N = valid tickets at the end including the one
used, then swapping 2 values and making one magic.
(For those of you who aren't bridge fiends:
https://en.wikipedia.org/wiki/Brown_sticker)

Sincerely,
Watson

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 1 Feb 2020 22:58:48 -0500

On Sat, Feb 01, 2020 at 07:04:53PM -0800, Watson Ladd wrote:

> I'd be happier with a magic 0, or a N = valid tickets at the end
> including the one used, then swapping 2 values and making one magic.

Sorry, no idea what that above means.  And is it simpler than the
proposal under discussion (which got some fine-tuning in early
feedback)?

-- 
    Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 1 Feb 2020 20:05:28 -0800

> proposal under discussion (which got some fine-tuning in early

So one proposal in above is we treat 0 tickets as "ensure I have a valid
ticket, either this one or a new one" and all other numbers are straight
asks for that many tickets.

The other proposal is N means "ensure I have N valid tickets, including the
one I used on this connection". I find both cleaner then the 0 and 255 swap.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 2 Feb 2020 06:52:03 -0500

> asks for that many tickets.

This is indeed simpler, but it removes the ability to ask for zero
tickets, which I think was one of the intended use-cases (that's what
the 255 is for).

> one I used on this connection". I find both cleaner then the 0 and 255 swap.

The problem here is now reuse is implicit, and the only way for a client
to ensure that it gets a fresh ticket, is by asking for 2.

So I now see where you're coming from, and it was worth a try at
simplification, but I don't think it works out.  The reasons for
two sentinels is that in fact are three separate cases.

    1.  Client wants no tickets
    2.  Client wants to try to reuse an existing ticket
    3.  Client wants n > 0 fresh tickets.

I don't see how to handle 1 and 2 cleanly without two sentinels.

-- 
    Viktor.

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 02 Feb 2020 06:42:56 -0800

> On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

I think Watson’s point (which I fully agree with) is that sending the value “0” already means “the client wants no tickets”.  The document already explains this usage. Thus, you don’t need a sentinel value to express that case—is what the value of N already intuitively means. 

If you did need a sentinel to indicate that you wanted to try to reuse a ticket (which you can always try if you want), it would make more sense to just make that sentinel be 255, etc, rather than creating two sentinels.

The ticket reuse signaling that is proposed really is orthogonal to the *count* of tickets.

When requesting a number of tickets, there is a signal in one direction from the client about how many tickets it wants; and the server signals back by issuing some number of tickets. There isn’t much ambiguity.

On the other hand, the proposed sentinel value indicates “I’d like to reuse tickets if I can”, but without any additional signaling from the server about the support of ticket reuse, a server response containing no tickets is ambiguous—maybe it means ticket reuse is fine; maybe it means the server isn’t giving out any more tickets and won’t allow resumption. It is much clearer if there is a bidirectional signal about negotiating ticket reuse.

Beyond that, it seems odd to mark a Boolean sent by the client to ask for ticket reuse in an integer that counts numbers of tickets. It’s not that one value (255) is precious, but it means that these orthogonal concepts can no longer be communicated separately. Let’s imagine a client that had received 4 tickets the first time around, on request, and then wanted to either reuse some of them or ask for 2 more. Keeping the ticket request just a number and having a separate message for the reuse Boolean allows that. Allocating a sentinel means that a request for reuse to a server that doesn’t support reuse now loses the ability to request a particular number of tickets.

Thanks,
Tommy

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Feb 2020 09:09:47 -0800

On Sun, Feb 2, 2020 at 6:43 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> On the other hand, the proposed sentinel value indicates “I’d like to
> reuse tickets if I can”, but without any additional signaling from the
> server about the support of ticket reuse, a server response containing no
> tickets is ambiguous—maybe it means ticket reuse is fine; maybe it means
> the server isn’t giving out any more tickets and won’t allow resumption. It
> is much clearer if there is a bidirectional signal about negotiating ticket
> reuse.
>
>
It's worth noting that because tickets are delivered serially and without a
leading count it's actually somewhat ambiguous no matter what. The server
might just decide to interleave data with tickets. I do agree it's somewhat
more ambiguous in the reuse case.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 2 Feb 2020 12:53:09 -0500

On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote:

> If you did need a sentinel to indicate that you wanted to try to reuse
> a ticket (which you can always try if you want), it would make more
> sense to just make that sentinel be 255, etc, rather than creating two
> sentinels.

Sure, if you want to swap my 0 <-> 255, that'd be fine by me, then
0--254 are "natural", and 255 means "only as needed".  If that's what it
takes to reach a compromise, I'm on board.

> The ticket reuse signaling that is proposed really is orthogonal to the *count* of tickets.

Except that it really isn't.  Reuse means: 0 tickets or 1 ticket when
the one presented is or soon will become unusable.  There's no way to
decouple that from the ticket count.

The idea is not to allow the client to gratuitously inform the server
that it is engaged in reuse while not attempting to reuse by requesting
fresh tickets anyway.  The idea is to attempt a reuse of the presented
ticket, by havving the server not return anything back if it is still
good.

> server about the support of ticket reuse, a server response containing
> no tickets is ambiguous—maybe it means ticket reuse is fine; maybe it
> means the server isn’t giving out any more tickets and won’t allow
> resumption.

The ambiguity is harmless.  If the server no longer accepts tickets the
next reuse will elicit a full handshake, resulting a new ticketless
session.  The client's existing ticket will get flushed.

> It is much clearer if there is a bidirectional signal about
> negotiating ticket reuse.

There an opportunity for a signal in the reverse direction, but not the
one above.  Rather, a useful reverse signal could be: I never accept a
previously used ticket, do not attempt reuse.  I would support that
signal.

> Beyond that, it seems odd to mark a Boolean sent by the client to ask
> for ticket reuse in an integer that counts numbers of tickets. It’s
> not that one value (255) is precious, but it means that these
> orthogonal concepts can no longer be communicated separately.

My point (made above) is that the client signals are NOT orthogonal.
Reuse implies 0 or 1 at the server's discretion.

> Let’s imagine a client that had received 4 tickets the first time
> around, on request, and then wanted to either reuse some of them or
> ask for 2 more.

This scenario doesn't quite work.  It can't reuse "some", it can only
request to reuse (again after the current resumption) the one it is
presenting.  If that one is not reusable, the server issues a
replacement, either way the client still has 4 usable tickets.

> Keeping the ticket request just a number and having a separate message
> for the reuse Boolean allows that. Allocating a sentinel means that a
> request for reuse to a server that doesn’t support reuse now loses the
> ability to request a particular number of tickets.

Yes, that's because reuse does not need multiple tickets.  Indeed long
ago upthread we discussed the fact that multiple tickets should
generally only happen on full handshakes (or at least infrequently,
rather than on each resumption).  Successful resumption should typically
yield at most 1 ticket, otherwise the number of tickets indefinitely
outpaces the number of connections.

The text added to describe that issue is fairly minimal, it should
ideally be expanded, but I am not going to make this a point of
contention.

But if indeed it makes sense to have the client signal how fresh tickets
it wants to get should a full handshake rather resumption takes place,
because:

    - While it prefers reuse, the server may not support it

    - The client not only supports reuse, but also supports a
      multi-slot ticket cache, and reuses tickets round-robin.

then indeed one may envision a signal that indicates the number of
tickets to send on full handshake (what this extension really should
mean to servers), but otherwise perhaps reuse on resumption, or else a
single unconditional ticket.

For that to happen, the reuse signal would be a separate bit, but
splitting the signal across two extensions makes for rather complicated
server and client code to get this right.

Therefore, if that's the way forward, then I'll take the high bit
as a resumption indication, with the ticket count in the low
seven bits.

If you tweak the shape of the signal to work for you, I'll not be fussy.
Let's just get something that solves the whole problem.

-- 
    Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Feb 2020 10:57:56 -0800

> outpaces the number of connections.

"Generally" seems to be doing a fair bit of work here, as if you are doing
happy eyeballs or some other parallel connection mechanism, then you in
fact need N new tickets.

-Ekr

-Ekr

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 02 Feb 2020 11:05:24 -0800

> On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

I don’t see why one should limit the number of tickets that can be requested to only 1 in a case in which a client wants ticket reuse, since the entire point of this extension message is to allow requesting multiple. I understand that there may be some scenarios in which a client requests multiple on the initial handshake, and then wants only one more after that, but that’s not necessarily the case.

For example, I connect once, and request 4 tickets so I can do happy eyeballs attempts (one for v4 and v6 on each Wi-Fi and Cell, say). When I try to connect later, I end up using all four of those tickets on attempts, but only one succeeds. Now I want 4 more, but only have one connection. If you wanted to have your ticket reuse signaling in this case, you’d want to express “either give me 4 new tickets, or let me know I can reuse the previous four”, in which case overloading values in the number of tickets is indeed reducing the expressivity of the mechanism.

Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 02 Feb 2020 21:00:58 -0800

I spoke with Viktor this afternoon about various scenarios being discussed on this thread. Going through the different use cases was very helpful in elucidating what functionality is appropriate.

The use cases we discussed are as follows. A and B are about multiple ticket requests. C and D are about ticket reuse. E is about both.

A. Multiple Tickets: Client with concurrent connections
In this scenario, a client may want to, from one initial TLS session, retrieve tickets for a pool of future connections. For this example, say this is four connections in a pool. On the initial connection, the client requests four tickets. It then can create four more connections, each with a unique ticket. From then on, each of those connections only requests a single ticket more, so as to get a ticket to replace the one they consumed. This allows a constant-sized pool of connections, where each connection gets to use tickets to resume.

If the server rejects a ticket due to deleting the session, the client can either continue to ask for one new ticket for each connection in the pool, or recognize that the tickets are no longer valid, and thus ask for a new batch (say, four new tickets) on the next handshake.

B. Multiple Tickets: Client with connection racing
For a client that wants a single connection, but may race connection establishment across address families (classic Happy Eyeballs) and interfaces (as in a mobile device case), the client may request a handful of tickets up front to allow connection racing. When racing, the client may consume, via connection attempts, more than one ticket to get one successful connection. For example, a client make use a ticket on a connection attempt over Wi-Fi, but then try LTE if Wi-Fi is stalling, and thus consume two tickets but only completes one connection. So, whenever a client knows it has consumed more tickets, it should try to repopulate the tickets. Note that it only knows how many it consumed *after* one is established, so it shouldn’t run its ticket collection dry on every connection attempt. Rather, it would probably make most sense to have enough tickets for two connection establishment attempts, such that any time many are consumed, the following handshake has the opportunity to ask for more.

If the server rejects a ticket due to deleting the session, all raced attempts for establishment will likely fail to resume together. Just like the case in which a client consumes many tickets due to racing, the client can only change the number of tickets it asks for on the *subsequent* handshake.

C. Single Ticket Reuse: Clients with trusted connection to the server, all/most clients reuse
If, in a controlled environment, a deployment wants to reuse tickets for resumption, the server can choose to allow that, and clients can choose to support that. If each client only needs a single ticket (since it can reuse its tickets), it doesn’t need to signal about multiple tickets. The one case in which it does need a new ticket is if the server deletes the session.

If the server knows that the majority of its clients reuse tickets, it can choose to simply give out a ticket only on the first handshake for a given client, or when a session has been deleted. For this case, no signaling should be needed.

D. Single Ticket Reuse: Clients wants to reuse (and server supports), most other clients do not reuse
As a variation, a server that supports ticket reuse in a situation when most of its clients do not support ticket reuse cannot simply only hand out tickets upon initial handshake, since most clients would then stop resuming. Instead, it would prefer to, by default, hand out a new ticket. For clients that *did* support reuse, it would be useful to have a signal. This signal is effectively a boolean to indicate that the client is happy with the tickets it currently has, and will reuse them unless the server gives out new tickets.

E. Multiple Ticket Reuse: Client want separate tickets for concurrent connections, that are later reused
Viktor described a case in which a client is split across multiple processes, so could be convenient to have independent tickets that are all retrieved from an initial connection that requested multiple handshakes, but the individual processes would want to treat those tickets as reusable until the server deleted the session. This case would want to both be able to request multiple tickets, and signal that reuse is possible.

=========

The questions I think that are most relevant are, based on our discussion:

How many distinct pieces of information are there that could be communicated from client to server?
Are any of these pieces fundamentally entangled, or should they be communicated separately? Is any capability lost by allowing them to be communicated separately?

To answer question 1, there are a few possible pieces of information that the client can send:
First is the item in the current draft, the Integer number of tickets that a client would like to receive from the server, based on the client’s current knowledge (how many tickets it already has, and if it is a new handshake or a resumption). This shows up in cases (A), (B), and (E).
Next is the Boolean value that indicates that a client intends to reuse the ticket(s) it already has, as a request to the server to only send tickets if the old one won’t work. This is what Viktor originally proposed to use as a sentinel value in the Integer space. This shows up in cases (C), (D), and (E).
A third possible item is a case that was brought up in our discussion: the Integer number of tickets that a client would like to receive if the current resumption attempt fails. The idea here is that a client in case (A) would be happy to only receive one ticket if the session is still valid, but would possibly want an entirely new batch (such as 4) if the resumption fails, so it can restock its ticket pool. This is certainly an interesting case, and one that I do consider to be in scope for the document, but I do have concerns that it does not apply well to all cases. For example, in scenario (B), the client is racing multiple connection attempts. If two or more raced attempts do hit the server at the same time, and the session state has been deleted, having all of them start to request more tickets than they would otherwise may end up requesting too many. Since the cases like (B) do often need to adjust their requests on subsequent handshakes, it seems to me that it is simpler to have only one value, and err on the side of requesting too few tickets on occasion instead of requesting some exponential amount. However, if people have particular opinions on this, I’d like to hear them!

So, to sum up, there are two possible Integer values to send, and one possible Boolean value to send.

To answer question 2, I’d point to the example use cases to conclude that, at the very least, the Integer number of tickets, and Boolean client intent to reuse tickets, are indeed separate pieces of information. Cases (A) and (B) only are concerned with the number of tickets. Cases (C) and (D) are only concerned with signaling ticket reuse. Case (E) could take advantage of both.

If we consider that these two pieces of information are independent, and can be used either separately or together, we can evaluate the possible approaches:
The initial proposal to carve out a sentinel value from the Integer request count space to signal the reuse Boolean. This approach has the downsides of not allowing the values to be communicated together, as well as requires that any implementation that supports one value must also write logic to support the other. As we see above, many of the use cases only need one.
The ticket_request struct could contain two separate values, an Integer and a Boolean. In this case, the values can be communicated alongside on another, which is good. It does still require handling both values in an implementation that only uses one.
Use the ticket_request extension for the Integer, and create a new prefer_ticket_reuse extension for the Boolean. This allows flexibility of communication, and also allows the semantics of this new extension to be defined, and to potentially have server response (which the ticket_request extension doesn’t have).

Viktor expressed two concerns with the separation proposed in approach 3:

First, the concern that the working group wouldn’t work on any more extensions around tickets. I hope that this would not be the case! Any valid use case that the working group sees fit to work on should be open to be worked on, and it is not the intent of the ticket request draft to preclude any future extensions that interact with tickets in other ways, such as specifying reuse policies.

Second, the concern that server processing logic would be too complex if these values weren’t combined. This I do want to dig into a bit.
From the server’s perspective, there should be three possibilities: the client uses only the ticket_request extension, the client uses only the prefer_ticket_reuse extension, or the client uses both the ticket_request and prefer_ticket_reuse extensions.
If the server supports both extensions, it should wait to process all client extensions before deciding how many tickets to send back. If the prefer_ticket_reuse extension is present, it would choose to not generate any new tickets unless session state was explicitly deleted; in that case, it would send tickets with a count hinted by ticket_request. My impression is that this does not actually constitute any more complexity in server implementation than if the values were present in a single extension, since the generation of tickets should wait until the server has finished the handshake anyway. The difference in implementation is only in the parsing, not in the processing.

=========

Based on this analysis, I’d recommend the following:
The proposal for hinting ticket reuse should be written up as a new draft proposing an extension, with discussion on use cases around ticket reuse. The reuse discussion can continue around that document.
Consider adding text to draft-ietf-tls-ticketrequests to explain the fact that when racing connections, the client won’t necessarily know the number of tickets it will “consume”, so it should either have enough tickets for two subsequent handshake resumptions; or else use fewer tickets but potentially run out.
Thanks,
Tommy

> On Feb 2, 2020, at 11:05 AM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> 
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 3 Feb 2020 12:04:18 -0500

> Viktor described a case in which a client is split across multiple
processes, so could be convenient to have independent tickets that are all
retrieved from an initial connection that requested multiple handshakes,
but the individual processes would want to treat those tickets as reusable
until the server deleted the session. This case would want to both be able
to request multiple tickets, and signal that reuse is possible.

What is reuse allowing us to optimize in this case?  If each process has
its own ticket cache, then reuse doesn't reduce inter-process overhead, so
what is the resource we are trying to economize?

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Feb 2020 13:34:57 -0500

> On Feb 3, 2020, at 12:04 PM, Ben Schwartz <[email-masked]> wrote:
> 
> its own ticket cache, then reuse doesn't reduce inter-process overhead,
> so what is the resource we are trying to economize?

The processes do not have their own ticket caches.  They are SMTP
delivery agents, that deliver messages to whatever destination
is next to receive email, and don't keep any state between
messages.  The session cache is shared across processes.

-- 
	Viktor.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 3 Feb 2020 13:39:47 -0500

On Mon, Feb 3, 2020 at 1:35 PM Viktor Dukhovni <[email-masked]>
wrote:

> messages.

I thought in Case E the goal was that each delivery agent keeps its ticket
as persistent per-process state, to avoid re-querying the global cache.

>   The session cache is shared across processes.
>
> --
>         Viktor.
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Feb 2020 13:50:18 -0500

> On Feb 3, 2020, at 1:39 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> I thought in Case E the goal was that each delivery agent keeps its ticket as
> persistent per-process state, to avoid re-querying the global cache.

I don't recall discussing such a scenario.  In Postfix the cache is shared.

There is not sufficient process affinity to particular destinations to
make such a cache design be viable, and the processes have limited
lifetimes, with new ones spawned as needed.  So whatever E might be,
a per-process cache is not the use-case I'm working with.

I'll read the post more closely over the next few days and attempt to
summarize where I think we are, and propose a pull request to at least
clarify the issues that motivate potential tweaks to the design.

We're starting to lose focus, and I think something more concrete in
writing will help.

-- 
	Viktor.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 3 Feb 2020 18:33:47 -0800

> clarify the issues that motivate potential tweaks to the design.

I find the sentinel idea a little odd, and it seems to create habitat for
overflow bugs.

As others have written, it might be better for you to change your program,
rather than change the protocol in the draft.

It would be nice to describe that tradeoff, if you write a summary.

thanks,
Rob