Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

From: Hubert Kario <[email-masked]>
Date: Tue, 01 Oct 2019 13:39:46 +0200

On Monday, 30 September 2019 15:56:19 CEST Jeremy Harris wrote:
> On 30/09/2019 14:36, Christopher Wood wrote:
> > On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
> >>       Clients must therefore
> >>       bound the number of parallel connections they initiate by the
> >>       number of tickets in their possession, or risk ticket re-use.
> >> 
> >> ```
> >> 
> >> I'm not a native speaker, but shouldn't it be "...therefore bind the
> >> number..."?
> > 
> > Yes, we can fix it in the next version.
> 
> "Bound" reads correctly to me.  You could spell it out in detail
> if it is thought confusing:
> 
>   "Clients must therefore not start a number of parallel connections
>   larger than the number of tickets in their possession"

"bound" would work also like this:

    "The number of parallel connections the clients can initiate is bound by
    the number of tickets in their possession."

-- 
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: Hubert Kario <[email-masked]>
Date: Tue, 01 Oct 2019 14:18:10 +0200

On Monday, 30 September 2019 15:36:36 CEST Christopher Wood wrote:
> > On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote:
> > > This version addresses some of the comments we received from Hubert a
> > > while
> > > back. We think it's ready to go for WGLC, modulo whatever nits folks
> > > find.
> > > 
> > > :-)
> > 
> > I still see the "vend" instead of "send" typos... Same for "vended"
> 
> It's not a typo! We chose to use vend.

then you're not consistent:

   As per [RFC5077], and as described in [RFC8446], TLS servers send

:)
 
> > Servers MUST NOT send more than 255 tickets to clients.
> > ```
> > 
> > per what? session? at a time? connection?
> 
> This is all per session. We can state it explicitly in the next version.

so this count needs to be kept as part of session and impacts connections that 
perform resumption?
 
> > what's the expected behaviour with tickets and post-handshake
> > authentication? Are tickets sent after PHA also bound by this limit?
> 
> As mentioned earlier, there is no effect, so we left it out. We're happy to
> accept text should you think it's needed.

If the I-D states that servers should not send more tickets than the client 
asked for, and then send exactly that amount, then they won't be able to send 
new tickets after PHA and remain compliant.

Yes, it's completely up to the server to decide if to send tickets after PHA 
or not, and I'm not suggesting that the client should request for tickets in 
one of its PHA messages, much less expect or require them, but sending tickets 
after PHA is reasonable and explicitly stated behaviour:

RFC 8446 Section 4.6.1:
   For instance, the server might send a new
   ticket after post-handshake authentication in order to encapsulate
   the additional client authentication state.

so the I-D should explicitly state what's the expected behaviour in that case.

IMHO, the extension should be used for the tickets sent right after the 
handshake, it should not put an upper bound for the tickets that a server can 
send in a single connection. For a very long lived connection (especially if 
the connection uses KeyUpdate messages regularly), the initial tickets may 
expire. Server may notice that and send a new group of tickets then.

> > ```
> > 
> >    Clients MUST NOT change the value of TicketRequestContents.count in
> >    second ClientHello messages sent in response to a HelloRetryRequest.
> > 
> > ```
> > 
> > 'A server MUST abort the connection with an "illegal_parameter" if the
> > value of the extension changed, it was added or removed in second
> > ClientHello.' ?
> I don't think this is necessary.

given past discussions on this mailing list, I don't think this is entirely 
obvious....

Then what about the addition or removal of extension being forbidden? Can we 
add something like this?:

```
     The presence or absence of the extension MUST be maintained in second 
     ClientHello message when compared to first ClientHello in connection.
```

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 01 Oct 2019 07:01:32 -0700

> so this count needs to be kept as part of session and impacts connections that 

Sorry, I meant connection:

   "Clients may indicate to servers their desired number of tickets for *a single connection* via the following "ticket_request" extension"

This is a simple hint for servers. Nothing more. No state needs to be stored past connection establishment.

> expire. Server may notice that and send a new group of tickets then.

Since these hints are not mandatory to honor I don't think we need to describe this case. In particular, this is a valid case where ignoring the SHOULD is fine, in my opinion.

If the draft required that servers MUST NOT send more tickets than what's requested, then yes, I think these details would be important.

>      ClientHello message when compared to first ClientHello in connection.

That works for me. We can add it in the next version. 

Best,
Chris

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Oct 2019 10:56:00 -0400

On Fri, Sep 27, 2019 at 04:47:16PM -0700, [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
>         Title           : TLS Ticket Requests
>         Authors         : Tommy Pauly
>                           David Schinazi
>                           Christopher A. Wood
> 	Filename        : draft-ietf-tls-ticketrequests-02.txt
> 
> Abstract:
>    TLS session tickets enable stateless connection resumption for
>    clients without server-side, per-client state.  Servers vend an
>    arbitrary number of session tickets to clients, at their discretion,
>    upon connection establishment.  Clients store and use tickets when
>    resuming future connections.  This document describes a mechanism by
>    which clients may specify the desired number of tickets needed for
>    future connections.  This extension aims to provide a means for
>    servers to determine the number of tickets to generate in order to
>    reduce ticket waste, while simultaneously priming clients for future
>    connection attempts.

I've read the draft, it looks quite useful and reasonable.  It would
be good to see this published.

I have one idea (implemented in OpenSSL 1.1.1 on the server side)
that may be worth mentioning in this context (and perhaps even the
draft):

   - By default, OpenSSL TLS 1.3 servers only vend multiple (two)
     tickets on full handshakes.  Resumed sessions issue just one
     ticket.

This avoids unbounded linear growth in the number of tickets vended
to a client that makes many resumed connections even after reaching
its peak connection concurrency.

When, instead, even resumed connections (which consume at most one
ticket) also receive more than one ticket, after N connections the
client has at least N as yet unused tickets, which is a waste in
steady state.

With the proposed extension a client that already has sufficiently
many tickets to handle peak concurrency can start sending 1 as its
requested ticket count if it does not reuse tickets, and else 0 if
it is reusing tikets and has all the tickets it needs for now.

Sending 1 on resumption when enough tickets are at hand helps clients
avoid receiving useless tickets from servers that don't implement
the OpenSSL strategy.  Sending 0 helps even with servers that use
the OpenSSL strategy to avoid sending pointless tickets to clients
that do reuse tickets and don't presently need more.

In OpenSSL, with 2 default tickets vended per full handshake, and
a client that implements single-use tickets, it takes N initial
full handshakes to reach steady-state with N concurrent resumable
sessions, after which time each resumption gets a new ticket for
the next resumption.

With the proposed extension, I'd raise the number of tickets vended
on a full handshake to the smaller of say 5 and the client's requested
count, which make it possible to prime N parallel tickets in N/4
previous full handshakes.  I'd still (by default) cap the ticket
count vended in a resumed session at 1, but a hint from clients
that have enough and send a request for 0 new tickets would then
be helpful.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 01 Oct 2019 18:15:31 +0200

On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> > so this count needs to be kept as part of session and impacts connections
> > that perform resumption?
> 
>    "Clients may indicate to servers their desired number of tickets for *a
> single connection* via the following "ticket_request" extension"
> 

sounds good

> > asked for, and then send exactly that amount, then they won't be able to
> > send new tickets after PHA and remain compliant.
> > 
> > Yes, it's completely up to the server to decide if to send tickets after
> > PHA or not, and I'm not suggesting that the client should request for
> > tickets in one of its PHA messages, much less expect or require them, but
> > sending tickets after PHA is reasonable and explicitly stated behaviour:
> > 
> > RFC 8446 Section 4.6.1:
> > handshake, it should not put an upper bound for the tickets that a server
> > can send in a single connection. For a very long lived connection
> > (especially if the connection uses KeyUpdate messages regularly), the
> > initial tickets may expire. Server may notice that and send a new group
> > of tickets then.
> Since these hints are not mandatory to honor I don't think we need to
> describe this case. In particular, this is a valid case where ignoring the
> SHOULD is fine, in my opinion.
> 
> If the draft required that servers MUST NOT send more tickets than what's
> requested, then yes, I think these details would be important.

huh? I see the following in the draft-02:

   Servers MUST NOT
   send more than 255 tickets to clients.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Oct 2019 13:06:03 -0400

>      tickets on full handshakes.  Resumed sessions issue just one

Thinking about this some more a related issue comes to mind.  A
client with (what it believes to still be) a valid reusable ticket
may want to tell the server that does not *need* a new ticket, ...

But, this should not preclude the server from issuing an updated
ticket when the presented ticket has expired (necessitating a full
handshake) or will soon expire and should be replaced.

For example:

    The Postfix SMTP server maintains a sliding window of two STEKs,
    one for encrypting/decrypting new session tickets, and another
    just for decrypting older tickets.  A fresh STEK is created
    once an hour (by default), and the current active STEK becomes
    the old STEK.

    When a client presents a ticket encrypting with the current
    STEK, no replacement ticket is issued, but when a client presents
    a ticket encrypted with the old STEK, a replacement ticket is
    issued under the fresh STEK.

A server that has a similar STEK rotation approach should be able
to conditionally refresh a client's ticket that is stale, while
otherwise honouring the client's signal that it does not need
more tickets at present.

Therefore, there is I think a need for two separate "no new tickets
required" signals.

    A.  The client has no intention to perform (further?) resumptions,
	No tickets at all required.

    B.  The client is happy to keep using the current ticket so long
	as it is still fresh, but would like periodic refresh if the
	ticket gets stale from the server's perspective.

	i.  If the presented ticket is expired or stale and a new
	    one is needed, the server is asked to return just one
	    ticket.

	ii. If the ticket is fresh, return no tickets.

Therefore, it would be useful for the extension to distinguish
between these two use-cases, perhaps an optional flags field, with
use-case B indicated via one of the flag bits?

-- 
	Viktor.

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 01 Oct 2019 10:26:32 -0700

>    send more than 255 tickets to clients.

I was referring to the "SHOULD NOT send more than TicketRequestContents.count NewSessionTicket messages" blurb. Indeed, the MUST NOT above should also be a SHOULD NOT. Thanks for your patience in working through the kinks!

> Attachments:
> * signature.asc

---

From: Daniel Migault <[email-masked]>
Date: Wed, 2 Oct 2019 16:42:32 -0400

Hi,

Please find some comments on the draft.

In the introduction, I believe both limitations may be merged into one
limitation which is the number of ticket is a server only decision. The
purpose of the extension is the client providing information so the server
can pick the appropriated number.

I find "choose" and "hard-coded" a bit contradicting. If the server uses a
hard coded value for the number of tickets, then I would understand the
limitation as the server being unable to chose a value per client or per
connection. This seems to me an implementation limitation and so maybe out
of scope of the extension. If it is able to choose that number, the
limitation is that it is a server only decision.

I understand the meaning of count is the higher limit of ticket and the
server can provides any tickets between 0 and count. If that is correct,
this could be clearly stated and indication to chose an appropriated value
for each cases may be provided.

I would rather see the count value as a hard line from the server with a
MUST NOT instead of a SHOULD NOT statement.

My reading of 8446 is that NewSessionTicket messages can be sent at
multiple time during or after the handshake. If that is correct, it seems
to me quite complex to track the number of tickets that had been sent.
Typically, if I have to send them at different time how much would I send
at each flight. I would rather consider the min(count, server_limit) as the
number of tickets in any batch of NewSessionTicket messages. We may also
ask the client to only keep the latest batch of tickets and delete the
others previously sent tickets.

The ability to request 255 tickets with one byte can be seen as an
amplification vector, especially when a server sends directly the tickets
after its Finished message. I believe that additional text in the security
consideration could be added.

Yours,
Daniel

On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood <[email-masked]> wrote:

> > > This is a simple hint for servers. Nothing more. No state needs to be
> stored
> > > past connection establishment.
> >
> > sounds good
> >
> > > > > As mentioned earlier, there is no effect, so we left it out. We're
> happy
> > > > > to
> > > > so the I-D should explicitly state what's the expected behaviour in
> that
> > > > case.
> > > >
> I was referring to the "SHOULD NOT send more than
> TicketRequestContents.count NewSessionTicket messages" blurb. Indeed, the
> MUST NOT above should also be a SHOULD NOT. Thanks for your patience in
> working through the kinks!
>
> >
> >
> > --
> > Regards,
> > Hubert Kario
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 02 Oct 2019 13:53:44 -0700

Hi Daniel,

Please see inline below.

On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote:
> purpose of the extension is the client providing information so the 
> server can pick the appropriated number. 

I'd prefer we didn't merge them, though admittedly I don't feel strongly about this one way or the other.

> I find "choose" and "hard-coded" a bit contradicting. If the server 
> uses a hard coded value for the number of tickets, then I would 
> understand the limitation as the server being unable to chose a value 
> per client or per connection. This seems to me an implementation 
> limitation and so maybe out of scope of the extension. If it is able to 
> choose that number, the limitation is that it is a server only 
> decision. 

Indeed. I think this is fairly clear from the draft. How would you suggest this be clarified?

> server can provides any tickets between 0 and count. If that is 
> correct, this could be clearly stated and indication to chose an 
> appropriated value for each cases may be provided. 

The document states this:

   A supporting server MAY vend TicketRequestContents.count
   NewSessionTicket messages to a requesting client, and SHOULD NOT send
   more than TicketRequestContents.count NewSessionTicket messages to a
   requesting client. 

Is this not sufficient clear? If not, how can it be improved?

> I would rather see the count value as a hard line from the server with 
> a MUST NOT instead of a SHOULD NOT statement. 

As this is merely a hint from the client, I don't think this is necessary.

> multiple time during or after the handshake. If that is correct, it 
> seems to me quite complex to track the number of tickets that had been 
> sent. Typically, if I have to send them at different time how much 
> would I send at each flight. I would rather consider the min(count, 
> server_limit) as the number of tickets in any batch of NewSessionTicket 
> messages. We may also ask the client to only keep the latest batch of 
> tickets and delete the others previously sent tickets. 

This behavior is orthogonal to the intent of the hint. Imagine, for example, clients sent no hint and servers decided to do what you describe above. The same issues would still exist (tracking some count sent on the server, deciding which tickets to use on the client, etc.). Thus, I don't think this would add much value.

> amplification vector, especially when a server sends directly the 
> tickets after its Finished message. I believe that additional text in 
> the security consideration could be added. 

The text lists this:

   Servers SHOULD place a limit on the number of tickets they are willing to vend to clients.

Though we can add a parenthetical to indicate that failure to do so may result in doing more work that intended. 

Thanks for the feedback!

Best,
Chris

---

From: Daniel Migault <[email-masked]>
Date: Wed, 2 Oct 2019 18:00:15 -0400

Hi,

Please see my comments.

Yours,
Daniel

> Indeed. I think this is fairly clear from the draft. How would you suggest
The draft does not seem, in my opinion, to address the case when values are
hard coded. OK hardcoded is just there to expose it cannot chose the value.
It is fine.

> I believe we could be more specific than a hint, and a server supporting
the extension MUST NOT send more tickets then specified. This is what is
expected when count is set to 0.

> This behavior is orthogonal to the intent of the hint. Imagine, for
> example, clients sent no hint and servers decided to do what you describe
> above. The same issues would still exist (tracking some count sent on the
> server, deciding which tickets to use on the client, etc.). Thus, I don't
> think this would add much value.
>
> If the servers receives a count value and sends tickets right after the
Finished message and after the post handshake authentication. How many
messages do you expect to be sent at each round?  I suggested to have count
at each round, as the server does not know how the client expects to use
these tickets. I have the impression the current text says count.

> The draft mentions limitation of tickets to avoid computation of the
server, and I was reading the limit as to limit that computation, in which
case the limit addresses server's resource exhaustion. What I meant was the
use of the extension with a spoofed IP address.

---

From: Nico Williams <[email-masked]>
Date: Wed, 2 Oct 2019 18:04:03 -0500

> be good to see this published.

+1

> its peak connection concurrency.

Dumb clients that say they want so many tickets on resumption, and then
store them all, and don't clear out older tickets fast enough... can get
DoSed by a server than gives them what they asked for.

This probably warrants a bit of text on the matter.  Probably a SHOULD
saying that clients should ask for only one ticket in resumptions (i.e.,
not use this extension) unless they are short of tickets.

Nico
--

---

From: Rob Sayre <[email-masked]>
Date: Thu, 3 Oct 2019 10:08:02 +0700

> Is this not sufficient clear? If not, how can it be improved?

RFC2119 "SHOULD/SHOULD NOT" requirements are usually clearer with some
examples of "valid reasons in particular circumstances to ignore a
particular item" [RFC2119]. Otherwise, those requirements can be cryptic,
and perhaps better-described by MAY or MUST language.

thanks,
Rob

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 02 Oct 2019 20:18:42 -0700

On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote:
> particular item" [RFC2119]. Otherwise, those requirements can be 
> cryptic, and perhaps better-described by MAY or MUST language.

I understand, though I'm not sure more text is needed here. If you disagree, can you please suggest text to make it more clear?

Thanks,
Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 02 Oct 2019 20:20:06 -0700

> not use this extension) unless they are short of tickets.

Asking for one upon resumption seems reasonable to me. Thanks to you and Viktor for bringing up this case!

Best,
Chris

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Oct 2019 23:44:27 -0400

> On Oct 2, 2019, at 11:20 PM, Christopher Wood <[email-masked]> wrote:
> 

Thanks!  Much appreciated.

My other point, which I probably obscured in too many words, is
that a client that prefers to re-use existing tickets, would
normally want to ask for 0 new tickets, but this should not
necessarily preclude the server from issuing one *as needed*
(STEK rollover, ...).

So there is a difference between a signal that tickets
are simply not wanted, vs. wanted only *as needed*.

Do you have any thoughts on how a client might signal this?

The use-case is clients and servers that don't make use of
early-data, and don't need to avoid traffic analysis.  For
example, MTA-to-MTA traffic, where the client even identifies
in clear text with "EHLO".  Here ticket reuse is the norm,
and renewal is only needed as tickets age.

[ I hope I managed an suitably concise description this time... ]

-- 
-- 
	Viktor.

---

From: Rob Sayre <[email-masked]>
Date: Thu, 3 Oct 2019 11:23:45 +0700

On Thu, Oct 3, 2019 at 10:19 AM Christopher Wood <[email-masked]>
wrote:

> I understand, though I'm not sure more text is needed here. If you
> disagree, can you please suggest text to make it more clear?
>

The current text the describes the interaction well enough, but I don't
understand the requirement. I can suggest two alternatives:

1) A supporting server [...] MAY send more than TicketRequestContents.count
NewSessionTicket messages to a requesting client. The client might not be
able to use all of them.
2) A supporting server [...] MUST NOT send more than
TicketRequestContents.count NewSessionTicket messages to a requesting
client.

The draft uses "SHOULD NOT". Why is that? Perhaps that trailing sentence I
added to 1) seems obvious to the authors? I did not automatically assume
the consequences of sending extra NewSessionTicket messages would be so
innocuous. If that's the case, it seems like MAY would be better, since
clients need to handle extra NewSessionTicket messages, even if they just
discard them.

thanks,
Rob

---

From: Hubert Kario <[email-masked]>
Date: Thu, 03 Oct 2019 13:55:10 +0200

> MUST NOT instead of a SHOULD NOT statement.

see my previous comments: this ignores existence of post handshake 
authentication, ticket lifetimes and KeyUpdate
 
> consideration could be added.

true
 
> > > > > > This is all per session. We can state it explicitly in the next
> > 
> > version.
> > 
> > > > > so this count needs to be kept as part of session and impacts
> > 
> > connections
> > 
> > > > > that perform resumption?
> > > > 
> > > >    "Clients may indicate to servers their desired number of tickets
> > 
> > for *a
> > 
> > > > > > > authentication? Are tickets sent after PHA also bound by this
> > 
> > limit?
> > 
> > > > > asked for, and then send exactly that amount, then they won't be
> > 
> > able to
> > 
> > > > > Yes, it's completely up to the server to decide if to send tickets
> > 
> > after
> > 
> > > > > tickets in one of its PHA messages, much less expect or require
> > 
> > them, but
> > 
> > > > > sending tickets after PHA is reasonable and explicitly stated
> > 
> > behaviour:
> > > > > RFC 8446 Section 4.6.1:
> > > > > IMHO, the extension should be used for the tickets sent right after
> > 
> > the
> > 
> > > > > handshake, it should not put an upper bound for the tickets that a
> > 
> > server
> > 
> > > > > initial tickets may expire. Server may notice that and send a new
> > 
> > group
> > 
> > > > > of tickets then.
> > > > 
> > > > describe this case. In particular, this is a valid case where ignoring
> > 
> > the
> > 
> > > > If the draft required that servers MUST NOT send more tickets than
> > 
> > what's
> >

---

From: Robert Relyea <[email-masked]>
Date: Thu, 3 Oct 2019 11:39:25 -0700

>      the number of tickets in their possession."
That would be 'is bounded by'

bound as a past participle/adjective of bind means to connect to. (in 
which case you would use bound with)
bound as a verb means to constrain or set limits on, it's past 
participle is bounded.

Maybe we should use Jeremy's construction which avoids the word, since 
it's bound to cause confusion (sorry couldn't resist the pun, as well as 
noting another reason to avoid the word in a spec that has to be parsed 
by non-native speakers;).

bob

---

From: Daniel Migault <[email-masked]>
Date: Thu, 3 Oct 2019 16:15:14 -0400

> authentication, ticket lifetimes and KeyUpdate
I think we agree on the problem which is it is hard to have a specific
count as tickets may be sent at multiple time during the key exchange or
the later during the session. If the "SHOULD" is addressing this aspect I
believe that more text is needed.. From my perspective, what I proposed  I
imagined that count was related to the maximum number of ticket provided
**each time the server is sending tickets**. The reason for having the same
number is that the server does not know how the client will use these
tickets and the client does not know precisely when the server sends the
tickets. So at the end the number of tickets sent is likely to be n*count
when n represents the number of times during the session tickets are
provided.

My understanding of the SHOULD is that it makes legitimate for a server to
ignore the count value provided by the client.

> > > > > > If the I-D states that servers should not send more tickets than
> the
> > > > > > client
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic_______________________________________________
> TLS mailing list
> [email-masked]

---

From: Hubert Kario <[email-masked]>
Date: Fri, 04 Oct 2019 15:17:15 +0200

On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> > > this could be clearly stated and indication to chose an appropriated
> > 
> > value
> > 

yes, it looks like we are in agreement

Sounds like something that should be spelled out explicitly in the draft. I.e. 
it should talk about groups of tickets, not tickets in connection, and it 
should definitely not specify the maximum number of tickets a server can send 
in a connection.
 
> > > tickets
> > > after its Finished message. I believe that additional text in the
> > 
> > security
> > 
> > > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood <[email-masked]>
> > 
> > wrote:
> > > > > > This is a simple hint for servers. Nothing more. No state needs to
> > 
> > be
> > 
> > > > stored
> > > > 
> > > > > > > > As mentioned earlier, there is no effect, so we left it out.
> > 
> > We're
> > 
> > > > happy
> > > > 
> > > > > > > > to
> > > > > > > Yes, it's completely up to the server to decide if to send
> > 
> > tickets
> > 
> > > > after
> > > > 
> > > > > > > PHA or not, and I'm not suggesting that the client should
> > > > > > > request
> > > > > > > for
> > > > > > > so the I-D should explicitly state what's the expected behaviour
> > 
> > in
> > 
> > > > that
> > > > 
> > > > > > > case.
> > > > > > > 
> > > > > > > IMHO, the extension should be used for the tickets sent right
> > 
> > after
> > 
> > > > the
> > > > 
> > > > > > > handshake, it should not put an upper bound for the tickets that
> > 
> > a
> > 
> > > > server
> > > > 
> > > > > > > (especially if the connection uses KeyUpdate messages
> > > > > > > regularly),
> > > > > > > the
> > > > > > Since these hints are not mandatory to honor I don't think we need
> > 
> > to
> > 
> > > > > > describe this case. In particular, this is a valid case where
> > 
> > ignoring
> > 
> > > > the
> > > > 
> > > > TicketRequestContents.count NewSessionTicket messages" blurb. Indeed,
> > 
> > the
> >

---

From: Daniel Migault <[email-masked]>
Date: Fri, 4 Oct 2019 09:55:23 -0400

Hi Hubert,

I agree.
Yours,
Daniel

On Fri, Oct 4, 2019 at 9:17 AM Hubert Kario <[email-masked]> wrote:

> correct,
> > > > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood <[email-masked]
> >
> > >
> > > wrote:
> > > > > MUST NOT above should also be a SHOULD NOT. Thanks for your
> patience
> > > > > in

---

From: Hubert Kario <[email-masked]>
Date: Fri, 04 Oct 2019 18:44:06 +0200

> [ I hope I managed an suitably concise description this time... ]

Well, the client doesn't have any feedback from server that the server 
supports this extension so it will need to be able to handle tickets anyway. 
It can't use this extension to disable sending of tickets.

now, we may say in the text, that's it's recommended for the server to still 
send them in case of resumption and STEK rollover of PHA, but I'm not sure if 
we're not too far into the weeds...
-- 
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: "Christopher Wood" <[email-masked]>
Date: Sat, 05 Oct 2019 05:06:04 -0700

> [ I hope I managed an suitably concise description this time... ]

You did indeed! However, as I'm not sure we should be encouraging ticket re-use. I think asking for 1 upon resumption would be the norm, which should address this case. (That is, I'm not sure adding more information to the signal to support the *as needed* case is worth the added complexity.)

Best,
Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Sat, 05 Oct 2019 05:08:45 -0700

> should definitely not specify the maximum number of tickets a server can send 

Since it's meant as a hint, removing that clause (maximum number of tickets a server can send in a connection) is reasonable, and sounds like it should address the concerns here. (Assuming we also include text which says servers should obviously place a cap on what they send, as they do today.) Would you agree? I'm really trying to avoid this becoming overly complex, as it's a very small feature. 

Best,
Chris

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 5 Oct 2019 13:05:02 -0400

On Sat, Oct 05, 2019 at 05:06:04AM -0700, Christopher Wood wrote:

> > [ I hope I managed a suitably concise description this time... ]
> 
> You did indeed! However, as I'm not sure we should be encouraging ticket
> re-use. I think asking for 1 upon resumption would be the norm, which
> should address this case.

Granted, ill-conceived ticket re-use should not be encouraged, in
fact should be prominently discouraged.

But perhaps the MTA-to-MTA use-case has more general applicability
in a broad class of server-to-server (datacentre-to-datacentre)
traffic, where the client has a long-term stable IP address, and
often a long-term affiliation with a single downstream peer.

An obvious example that comes to mind is a reverse-proxy that
terminates and resumes TLS.  At various $jobs I've helped folks
design/deploy such beasts in the DMZ.  Here there's a steady stream
of traffic between two nodes, and traffic-analysis "privacy"
considerations around ticket re-use don't come into play.

> (That is, I'm not sure adding more information to the signal to support
> the *as needed* case is worth the added complexity.)

That's the key question.  Such a signal could perhaps steal the
high-bit of the ticket count, limiting the count to at most 127.
Or alternatively the extension could send

    * 0 to mean no tickets ever (client has no ticket cache)
    * 1 to mean none required, but refresh as needed
    * n=2 or more to mean please send n-1 tickets.

This keeps the structure of the extension simple: for most clients
just send n+1 for n∈[1,254].

On the server side for n∈[2,255], just vend the lower of the server's
limit and n-1, for 0 send no tickets, which leaves only "n=1" for
the server to handle specially, by renewing the ticket if it is
either a single-use ticket or suitably dated.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 07 Oct 2019 16:45:42 +0200

On Saturday, 5 October 2019 14:08:45 CEST Christopher Wood wrote:
> > Sounds like something that should be spelled out explicitly in the draft.
> > I.e. it should talk about groups of tickets, not tickets in connection,
> > and it should definitely not specify the maximum number of tickets a
> > server can send in a connection.
> 
> Since it's meant as a hint, removing that clause (maximum number of tickets
> a server can send in a connection) is reasonable, and sounds like it should
> address the concerns here. (Assuming we also include text which says
> servers should obviously place a cap on what they send, as they do today.)
> Would you agree? I'm really trying to avoid this becoming overly complex,
> as it's a very small feature.

yes, having a "server SHOULD place a cap on the number of tickets it sends at 
once" with a note in security section that "not having such a limit may expose 
the server to DoS or amplification attacks" would be enough

(note that without client certificate authentication, the server can use early 
exit from handshake method and thus send the extensions just as a result of a 
single ClientHello message)
-- 
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: Daniel Migault <[email-masked]>
Date: Tue, 8 Oct 2019 10:04:18 -0400

If we suppose all tickets are sent by the server at once, I am wondering if
we have any case where the server will send more tickets that the number
provided by the hint.

Yours,
Daniel

On Mon, Oct 7, 2019 at 10:46 AM Hubert Kario <[email-masked]> wrote:

> > > > > > I understand the meaning of count is the higher limit of ticket
> and
> > > > > > the
> > > > the later during the session. If the "SHOULD" is addressing this
> aspect
> > > > I
> > > > believe that more text is needed.. From my perspective, what I
> proposed
> > > > I
> > > > **each time the server is sending tickets**. The reason for having
> the
> > > > same
> > > > My understanding of the SHOULD is that it makes legitimate for a
> server
> > > > to

---

From: Hubert Kario <[email-masked]>
Date: Tue, 08 Oct 2019 16:28:12 +0200

> we have any case where the server will send more tickets that the number

long lasting connection and a ticket encryption key expiring
 
> > > > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario <[email-masked]>
> > 
> > wrote:
> > > > > > > this could be clearly stated and indication to chose an
> > 
> > appropriated
> > 
> > > > > > value
> > > > > > 
> > > > > > > I would rather see the count value as a hard line from the
> > > > > > > server
> > > > > > > with a
> > > > > I think we agree on the problem which is it is hard to have a
> > 
> > specific
> > 
> > > > > count as tickets may be sent at multiple time during the key
> > 
> > exchange or
> > 
> > > > > imagined that count was related to the maximum number of ticket
> > 
> > provided
> > 
> > > > > tickets and the client does not know precisely when the server sends
> > 
> > the
> > 
> > > > Sounds like something that should be spelled out explicitly in the
> > 
> > draft.
> > 
> > > Since it's meant as a hint, removing that clause (maximum number of
> > 
> > tickets
> > 
> > > a server can send in a connection) is reasonable, and sounds like it
> > 
> > should
> > 
> > > servers should obviously place a cap on what they send, as they do
> > 
> > today.)
> >

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 10 Oct 2019 12:04:59 +1100

I think that the discussion Victor started about the number of tickets you might want to supply being different for a resumed connection is a sensible one, but I would caution against servers making inferences, especially in light of a very clear signal from clients.  Advice for client implementations might be wise, so that servers are less motivated to make these sorts of decisions.

Nits-wise, there are lots of lowercase instances of "may", which is fine, but most can be replaced with "can", except one that I think could be a "MAY": Clients may send this extension in ClientHello.

Otherwise, I only skimmed this.  If I get a chance, I might send more detailed editorial comments, but I didn't see any technical reason to hold this back from WGLC.

On Sat, Sep 28, 2019, at 09:59, Christopher Wood wrote:
> while back. We think it's ready to go for WGLC, modulo whatever nits 
> folks find. :-)
> 
> Best,
> Chris (no hat)
> 
> On Fri, Sep 27, 2019, at 4:47 PM, [email-masked] wrote:
> > 
> > 	Pages           : 6
> > 	Date            : 2019-09-27
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-02
> > https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-02
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ticketrequests-02
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Oct 2019 23:07:10 -0400

> On Oct 9, 2019, at 9:04 PM, Martin Thomson <[email-masked]> wrote:
> 

THanks for the above.  I share much the sentiment.  There's
just one thing I see no way to do, without a somewhat more
nuanced interaction between client and server.

  * The client has a what it believes to be a valid ticket
    and is willing to re-use it, and would prefer to avoid
    the cost of replacing it on each resumption.

  * The server is happy to allow re-use of still valid
    tickets by clients, but needs to know whether the
    client wants a new ticket (because it never re-uses).

  * The server would like to vend a new ticket only when the
    old one needs to be refreshed (ticket lifetime or STEK
    rotation).

In the context of the draft as-is, such a client and server
have a time arriving at a mutually compatible configuration.

  1. If the client requests zero tickets, the server might
     decide the client never wants tickets.  Perhaps here,
     we could say that if the client in fact presented a
     resumption PSK, then it should get zero tickets most of
     the time, but 1 if the ticket needs to be replaced.

     [ This may not quite work right if the presented resumption
       PSK turned out to already be expired and a full handshake
       took place.  In that case the server may not retain any
       knowledge of the original resumption attempt by the time
       the handshake is complete. And for PSKs that fail to
       decrypt, it may not be possible to know whether the PSK
       even was a ticket-based resumption attempt or not. ]

  2. If the client requests one ticket, the server can't
     distinguish between clients that want 1-to-1 replacement,
     because they implement single-use, and those that only want
     one if needed.

  3. When a client gets a new ticket, it has no idea whether the
     original one is still valid, and so must discard the old and
     switch to the new.  So servers that vend a new ticket each
     time force clients to constantly update their ticket store,
     which is sometimes problematic.

Therefore, I am trying to see whether there's a bit of wiggle-room
here for better coordination between server and client.

The simplest I've been able to come up with is to make 0 mean
send no tickets, and 1 mean send 1 as needed, and for n >= 2,
mean send n-1 unconditionally.  But perhaps some else has a
more elegant design that addresses the above?

-- 
	Viktor.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 11 Oct 2019 19:55:10 +1100

> have a time arriving at a mutually compatible configuration.

Yeah, I agree that this is a little thorny.  However, the client asking for one extra and the server vending one more is a relatively small extra expense AND we discourage reuse in the general case.  So, at least from my perspective, this isn't that serious a problem and shouldn't block publication.

I'm not especially happy with the idea of having 1 mean "maybe 1".  Having 1 mean 1 is far less dangerous.  I think that I would prefer to go for an application- or configuration-level signal for this, if it is an important use case to consider.  It's not like it is impossible to have an client say "I really need a ticket" at the application layer, and the server to receive that and call `tls.send_ticket()` (that's a function that NSS provides, for instance).

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 Oct 2019 17:35:03 -0400

> On Oct 11, 2019, at 4:55 AM, Martin Thomson <[email-masked]> wrote:
> 

In Postfix, multiple SMTP client processes share a 1 slot external
session ticket cache, and expect to re-use tickets until a new one
is issued by the server.  This works poorly with servers that don't
allow re-use, and updating the cache on each connection is rather
wasteful on both ends.

Presently, the Postfix SMTP server assumes clients of the same kind,
and always only issues new tickets *as-needed*.  If clients could
signal their real requirements, that policy would no longer need
to be hard-coded, it would just become a default for clients that
don't send this extension.

Perhaps the solution is to say that clients that don't send the
extension get default application-specific behaviour, possibly
"refresh only as-needed".  If they prefer to always get a specific
number of tickets, they can request that number.

Then I guess I could attempt to honour the extension, and revert
to default behaviour in its absence, making sure that the Postfix
SMTP client either does not ask to send the extension, or invokes
some appropriate OpenSSL interface to ask that it not be sent as
appropriate.

-- 
	Viktor.