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

From: Sean Turner <[email-masked]>
Date: Tue, 5 Nov 2019 11:05:05 -0500

All,

This is the working group last call for the "TLS Ticket Requests" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/.  Please review the document and send your comments to the list by 2359 UTC on 19 November 2019.

Note the the GH repo for this draft can be found at:
https://github.com/tlswg/draft-ietf-tls-ticketrequest

Thanks - J&S

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Nov 2019 16:34:08 +0000

I read it.  I support it.  Ship it.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Nov 2019 12:32:12 +1100

There was a lengthy discussion after the last time this was discussed.  Can I request that an editor (or a chair) summarize that discussion and the resulting actions (if any)?  I was involved in that discussion, but I don't see any changes from that.  I'm totally OK with publication as-is, but I want to make sure that nothing got dropped.

p.s., it might make sense to include some advisory text on prioritization of tickets vs. application data.  I can see a naive implementation of this seriously degrading application performance.  For instance, it doesn't take that many tickets to fill an early TCP congestion window.

p.p.s., yes, if you keep issuing last calls, I will keep finding new things.

On Wed, Nov 6, 2019, at 03:05, Sean Turner wrote:
> All,
> 
> This is the working group last call for the "TLS Ticket Requests" draft 
> available at 
> https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/.  
> Please review the document and send your comments to the list by 2359 
> UTC on 19 November 2019.
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 14 Nov 2019 10:50:24 -0500

Hi,

The current version is clearer than the previous one. However, as I
understand the document, it still seems very asymmetric in the sense
that it does not provide the client the ability to enforce a number. I
believe more guidances/specifications are needed on how to interpret the
count value. Interpretation is usually based on implicit assumptions of
today's usages, and explicit signaling should, in my opinion, be preferred.
In
other words, I believe that long term interop will benefit from these
additional specifications.

The problem stated in the introduction is that the server needs some
information from the client in order to generate the appropriated number
of tickets. In fact the client is likely to be the one that better knows
the number of tickets to be generated, but the current text does not
enable the client to enforce that number. Instead this is entirely left
to the server.

Typically, if a device does not want to have more than one ticket. It
should be able to indicate one and be sure it will only receive one
ticket. The current specification does not prevent multiple tickets to
be sent by the server. The server can ignore the count value (MAY) even
though it is known to support the extension. This means that a server
could support the extension while still having a hard coded number of
tickets. In addition, (SHOULD) let the server determining the number of
tickets.

Possible ways to address my concerns could be to limit the count value
to the number of tickets generated during the KEX, and a server MUST NOT
exceed the counter value. The text would need more guidance on how the
server SHOULD behave when emitting at different time in the KEX - after
the Finished message and after the post handshake authentication.

The security consideration should in my opinion consider the fact that a
client over UDP/DTLS may use the count value as an amplification factor
to have the server flooding a target. The current text only seems to
consider the computation aspect, not the bandwidth. If that cannot
happen, it might be beneficial to add it. However, when a server sends
tickets right after the Finished, it seems to me that can be used as an
attack.

Yours,
Daniel

On Tue, Nov 5, 2019 at 8:32 PM Martin Thomson <[email-masked]> wrote:

> There was a lengthy discussion after the last time this was discussed.
> Can I request that an editor (or a chair) summarize that discussion and the
> resulting actions (if any)?  I was involved in that discussion, but I don't
> see any changes from that.  I'm totally OK with publication as-is, but I
> want to make sure that nothing got dropped.
>
> p.s., it might make sense to include some advisory text on prioritization
> of tickets vs. application data.  I can see a naive implementation of this
> seriously degrading application performance.  For instance, it doesn't take
> that many tickets to fill an early TCP congestion window.
>

-- 
Daniel Migault
Ericsson

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 14 Nov 2019 08:01:34 -0800

On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> today's usages, and explicit signaling should, in my opinion, be preferred. In

I disagree with this assessment. The document is clear on this:

   A supporting server MAY use TicketRequestContents.count when
   determining how many NewSessionTicket messages to send to a
   requesting client, and SHOULD place a limit on the number of tickets
   sent.  The number of NewSessionTicket messages sent SHOULD be the
   minimum of the server's self-imposed limit and
   TicketRequestContents.count.

As has been stated before, the count is a *hint* to the server, nothing more. 

> enable the client to enforce that number. Instead this is entirely left

As above, I think you're misunderstanding the point of this document. Ticket requests are hints to servers.

> be sent by the server. 

Right, nor should it. Again, that's not a goal.

> The server can ignore the count value (MAY) even 

I don't think any text changes are needed to address these comments.

> tickets right after the Finished, it seems to me that can be used as an

I'm not convinced this is useful to add. The target here is the client (attacker) that requested tickets. 

Best,
Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 14 Nov 2019 08:05:34 -0800

On Tue, Nov 5, 2019, at 5:32 PM, Martin Thomson wrote:
> Can I request that an editor (or a chair) summarize that discussion and 
> the resulting actions (if any)?  I was involved in that discussion, but 
> I don't see any changes from that.  I'm totally OK with publication 
> as-is, but I want to make sure that nothing got dropped.

The only comment that was not integrated was the desire to use the hint to express not only a count, but also a bit indicating whether or not clients will accept a ticket if the server needs to send one (e.g., if its STEK is about to rotate and any old tickets would expire). The authors did not incorporate that into the document since it added complexity and there didn't seem to be much support for it. 

> p.s., it might make sense to include some advisory text on 
> prioritization of tickets vs. application data.  I can see a naive 
> implementation of this seriously degrading application performance.  
> For instance, it doesn't take that many tickets to fill an early TCP 
> congestion window.

Sure, we can add that: https://github.com/tlswg/draft-ietf-tls-ticketrequest/issues/9

> p.p.s., yes, if you keep issuing last calls, I will keep finding new things.

:-)

Thanks,
Chris

---

From: Daniel Migault <[email-masked]>
Date: Thu, 14 Nov 2019 11:19:55 -0500

Hi Chris,

Thanks for the responses, please see my comments inline.

Yours,
Daniel

On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood <[email-masked]>
wrote:

> That is my point, in my opinion a hint is under specified.

> On the contrary, I think I understood it correctly.

> (attacker) that requested tickets.

The target is the spoofed source IP address.

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 14 Nov 2019 08:24:32 -0800

On Thu, Nov 14, 2019, at 8:19 AM, Daniel Migault wrote:
> On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood <[email-masked]> wrote:

I acknowledge your opinion, but as I think I've made clear, I don't agree. Sorry!

> The target is the spoofed source IP address.

That would imply the attacker is able to complete a connection with this spoofed address, no?

---

From: Daniel Migault <[email-masked]>
Date: Thu, 14 Nov 2019 11:43:12 -0500

Hi,

If tickets are sent right after the server Finished, before the the client
Finished, these are only triggered by the clientHello - at least this is my
understanding.

Yours,
Daniel

On Thu, Nov 14, 2019 at 11:25 AM Christopher Wood <[email-masked]>
wrote:

> > >  I'm not convinced this is useful to add. The target here is the
> client (attacker) that requested tickets.

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 14 Nov 2019 08:48:05 -0800

On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote:
> If tickets are sent right after the server Finished, before the the 
> client Finished, these are only triggered by the clientHello - at least 
> this is my understanding.

Yes, that's correct. I thought your comment was about post-handshake tickets (after confirmation from the client). Adding a note about this pre-handshake completion is fine with me.

Best,
Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 14 Nov 2019 08:51:09 -0800

On Thu, Nov 14, 2019, at 8:48 AM, Christopher Wood wrote:
> Yes, that's correct. I thought your comment was about post-handshake 
> tickets (after confirmation from the client). Adding a note about this 
> pre-handshake completion is fine with me.

Scratch that! I forgot we limited this extension to TLS 1.3, which prohibits sending NSTs until the client finished is received (https://tools.ietf.org/html/rfc8446#section-4.6.1). 

Best,
Chris

---

From: Daniel Migault <[email-masked]>
Date: Thu, 14 Nov 2019 11:57:40 -0500

Unless I am missing something, the text below seems to say otherwise.

Note: Although the resumption master secret depends on the client's
   second flight, a server which does not request client authentication
   MAY compute the remainder of the transcript independently and then
   send a NewSessionTicket immediately upon sending its Finished rather
   than waiting for the client Finished.  This might be appropriate in
   cases where the client is expected to open multiple TLS connections
   in parallel and would benefit from the reduced overhead of a
   resumption handshake, for example.

On Thu, Nov 14, 2019 at 11:52 AM Christopher Wood <[email-masked]>
wrote:

> Scratch that! I forgot we limited this extension to TLS 1.3, which
> prohibits sending NSTs until the client finished is received (
> https://tools.ietf.org/html/rfc8446#section-4.6.1).
>
> Best,
> Chris
>

---

From: Hubert Kario <[email-masked]>
Date: Thu, 14 Nov 2019 17:58:54 +0100

On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault wrote:
> As above, I think you're misunderstanding the point of this 
> document. Ticket requests are hints to servers.
>

we discussed it on the list, and the reason for such phrasing is 
multi-fold:
 - the server doesn't have to implement this extension, as such, as per the
   basic TLS 1.3 RFC, it can send arbitrary number of extensions to client,
   so clients, to be RFC compliant, need to be able to process abritrary 
number
   tickets at arbitrary time after handshake finish
 - making value in extension the exact number requested by client makes the
   implementation much more complex: is that number per connection? per
   session? what about post-handshake authentication? what about Session 
Ticket
   Encryption Key rollover? do we really want the client to abort the 
connection
   if server misbehaves and sends too many or too few tickets?
 - while the client may think that it knows how many tickets it requires, 
that
   information may be out of date. If an HTTP server has been brought down, 
a
   connection to a given SNI may lead to a redirection page - in such cases
   there is no point in server sending tickets.

so please, tell: what issue would be solved by making the count requested 
by
client mandatory?
Because I see it only increasing complexity of implementation for no 
benefit.
-- 
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: Thu, 14 Nov 2019 09:02:00 -0800

>    resumption handshake, for example.

Oops again. I only read the first sentence and drew the wrong conclusion. 

   At any time after the server has received the client Finished
   message, it MAY send a NewSessionTicket message.

> 
> 
> On Thu, Nov 14, 2019 at 11:52 AM Christopher Wood <[email-masked]> wrote:

---

From: Daniel Migault <[email-masked]>
Date: Thu, 14 Nov 2019 12:18:52 -0500

Hi Hubert,

The reason I would prefer the client to enforce the count is that if a
client has constraints - memory / bandwidth, he wants to make sure its
preference is respected, and this independently of the evolution of how the
hint will be interpreted in the future or depending on different
implementations.

I understand the reasons for SHOULD. At least this should be documented. To
address your first point, of course the specification applies to the server
that support the extension. Your second concern is solved by limiting the
NTS of KEX. The third point is addressed by the minimum of the (count,
server_nbr). Note that I see count as a maximum. Overall I do not think
this would add much complexity.  The only complexity I see is when a server
sends NTS at different time in the KEX.

Yours,
Daniel

---

From: Hubert Kario <[email-masked]>
Date: Thu, 14 Nov 2019 18:32:39 +0100

> hint will be interpreted in the future or depending on different

bandwidth I sort of understand, but then if client asks for 0 tickets, it's 
explicitly stated in the draft that server should understand it as "will 
not use, don't bother" – I really don't see how in the future that can be 
reinterpreted as "nah, send tickets anyway" – also, please remember that 
the size of the ticket is very variable, so just accepting one ticket may 
be a significant size anyway

as for memory – just because server sends them, doesn't mean client has to 
remember them

finally: ok, so the server misbehaves and sends 4 tickest instead of three, 
what the client should do? close the connection?

> that support the extension. 

> Your second concern is solved by limiting the
> NTS of KEX. 

by "KEX" you mean handshake? but New Session Ticket messages are not sent 
during handshake, they are sent after handshake is finished

so how exactly you want to decide when server stopped sending NSTs after 
handshake finished?

> The third point is addressed by the minimum of the (count,

again, and what if the server misbehaves?

>>> On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood ...
>>

---

From: Daniel Migault <[email-masked]>
Date: Fri, 15 Nov 2019 07:00:14 -0500

Hi  Hubert,

> be a significant size anyway

I agree the case of count set to 0 is mention. However, the support of the
extension does not prevent a server to send 4 tickets with MAY and SHOULD.
The reason this might be ignored in the future is that the specification
does not prevent the server from doing so and takes what the client
provides as an hint which may be overwrite by the server. 0 seems also
special, but I believe we can have a common behaviour for any sort of
values.

> as for memory – just because server sends them, doesn't mean client has to
It still has to process them, which consumes battery.

> Well, the client will probably discard one. That said with the current
specification we cannot report a bug and ask the server to comply with the
spec, it is in the spec. On the other hand, if the spec ask for considering
that count, we can ask the server to be compliant with the spec. All cases
you are raising will need to be implemented and as such will be defined in
some ways. In my opinion that should be in the specification.

> yes. I would consider the NST as part of the handshake even for those sent
after the post-handshake authentication. I agree better terms may be used.
The rekey aspect seems to me out of the handshake.

> so how exactly you want to decide when server stopped sending NSTs after

That the spec does not mention it does not mean this will not be defined.
Instead it means each implementer will have its own logic, definitions and
outputs. The same reasoning occurs to the complexity argument,not
specifying it does not reduce the complexity but let it to the
implementation with all unexpected corner cases.

> again, and what if the server misbehaves?

Again, it would be a bug but the current spec is very permissive, at least
in my opinion. I do not believe that not specifying the expected behaviors
will prevent misbehaviors to happen, it, instead simply legitimates them.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 15 Nov 2019 14:43:15 +0100

> after the post-handshake authentication.

that would make tickets useless for sessions that use PHA

> I agree better terms may be used.

rekey also don't impact the keys used for derivation of session ticket
secrets...

> implementation with all unexpected corner cases.

my point is that there is no good way to define it, if you want the count 
to be
limited, you need provide a good way to do that

I say that there isn't one, so defining it is futile

> will prevent misbehaviors to happen, it, instead simply legitimates them.

a MUST requires strict definition, which we can't provide, a SHOULD is 
already
in the draft

---

From: Daniel Migault <[email-masked]>
Date: Sat, 16 Nov 2019 01:01:43 -0500

Hi Hubert,

I do not understand why tickets sent after PHA would be useless. It is also
unclear if not one solution means there are multiple good solutions - in
which case we could pick one - or that there is not one.  At least I would
envisioned something around the lines below.

For a given handshake as presented below, here are the NST with associated
number (n_0, ..., n_3) without any count value provided by the client. When
the client provides count I would expect these number to become (n'_0, ...,
n'_3) with n'_u = min(max(count- sum(n'_j, j<u), 0), n_u). Basically, you
send n_0, n_3 until counter is reached. Other NST are ignored. This seems
to ensure that only count NST are sent while not being overly complex.  I
believe that have a deterministic behavior from the server is beneficial.

Of course this is a first draft, and this may be refined.

          Client                                               Server

          ClientHello
          + key_share               -------->
                                                  ServerHello
                                                  {Finished}
                                    <--------     [Application Data*]
    <--------   NST (n_3)
          {Certificate*}
          {Finished}                -------->
                                    <--------     NST (n_2)
          [Application Data]        <------->     [Application Data]
                    <---------    NST (n_1)
                    <--------     CertificateRequest
  PHA response      --------->
                                    <---------    NST (n_0)
Yours,
Daniel

On Fri, Nov 15, 2019 at 8:44 AM Hubert Kario <[email-masked]> wrote:

> >>> I understand the reasons for SHOULD. At least this should be
> documented.
> >>> To

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 16 Nov 2019 05:05:46 -0500

On Thu, Nov 14, 2019 at 08:05:34AM -0800, Christopher Wood wrote:

> The only comment that was not integrated was the desire to use the hint
> to express not only a count, but also a bit indicating whether or not
> clients will accept a ticket if the server needs to send one (e.g., if its
> STEK is about to rotate and any old tickets would expire). The authors did
> not incorporate that into the document since it added complexity and there
> didn't seem to be much support for it.

I was hoping Matt Caswell would chime in with his perspective on this topic, as
he and I together refined the ticket generation logic in OpenSSL 1.1.1.  But,
it seems he has not been able to find the requisite cycles, so I'll post my
summary comments as best I can:

1.  The tentative proposal was a client-side indication that new tickets are
    optional, and only needed when the presented ticket requires replacement.
    If still re-usable, accept it without issuing a new one.

    The goal was to make it possible for a client and server to "negotiate"
    re-use, rather than have that be a static feature of the application or a
    given implementation.

2.  The specific suggestion of reserving a bit is more complex than needed, it
    would suffice to simply "subtract 1" from the client's hint:

        0 - (effectively -1), client unconditionally wants no new tickets.

        1 - (effectively 0), client prefers to reuse tickets.  Only issue
            a new ticket if necessary (STEK rotation, ticket expiration, ...),
            or server does not support any ticket reuse.

        n - (effectively n - 1), client would like up to n-1 fresh tickets on
            any full handshake.

    This looks simple enough to me, and allows the client to clearly communicate
    that tickets are optional when reusable.

3.  As noted previously, servers SHOULD NOT generally issue multiple tickets on
    successful resumption, at that leads to unbounded oversupply of tickets.
    Only the server knows whether resumption will happen, or a full handshake,
    and so clamping of the ticket count to 1 on resumption is best a
    server-side decision.

    A client can continue to request the same number of tickets (say hint 3 =>
    2 wanted, per the above), with the server returning that number on full
    handshake, but 1 or zero on resumption.  When the client's presented ticket
    is not suitable for resumption, cleary the client needs new tickets (fresh
    start) and the behaviour should be the same as on an initial connection
    with no tickets from the client.

    The -03 draft added a sentence suggesting that clients should ask for just
    one ticket on resumption, but I would like to suggest that this logic
    belongs in the server.

-- 
    Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Nov 2019 02:38:55 -0800

> > didn't seem to be much support for it.
[...]
>     one ticket on resumption, but I would like to suggest that this logic

We should probably be emphasizing that *all* policy belongs on the server, and
we are just defining a signal for the client to convey some information as input
to the server's decision.  In that mindset I'm not sure that the "subtract one"
signal is the most satisfying design (though I concede that it is probably the
most efficient encoding).

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 16 Nov 2019 06:04:25 -0500

> most efficient encoding).

Do you have an alternative suggestion?  I am indeed optimizing for a minimally
invasive change that keeps the encoding simple/efficient, at the cost of some
indirection between intended signal and its representation.  As with most
things, there are trade-offs here.

We could indeed have a separate flags field, or separate counts for various
conditions:

    - # to issue on full handshake
    - # to issue on STEK rollover
    - # to issue if server supports/does-not-support reuse
    - ...

But ultimately I think it boils down to whether the client:

    - can keep reusing an existing session with the ticket it already has
    - needs a single new ticket to keep reusing that session
    - is establishing a new session (full handshake) and wants to
      use parallel connections, so may want multiple fresh tickets.

Likely the simplest mechanism that handles the above is enough, and I think the
"-1" suggestion plus a server cap at 1 ticket on resumption, pretty much
handles all three cases.

Perhaps I'm missing some important cases, and if so, it would be good to flush
those out and understand their trade-offs.

-- 
    Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 16 Nov 2019 16:38:17 +0000

On 16/11/2019 11:04, Viktor Dukhovni wrote:
> Do you have an alternative suggestion?

The obvious encoding to me would be to reserve the all-bits-set value
to mean "client wants no tickets", all-bits-clear to mean "client
prefers to reuse tickets", anything else meaning "please serve up
to this many fresh tickets".
-- 
Cheers,
  Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 16 Nov 2019 16:06:17 -0500

> to this many fresh tickets".

That also works, effectively treat 0xff as "-1", but all other
values as non-negative, with 0 a request for re-use.  An isomorphic
encoding, but without the "-1".

-- 
    Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Nov 2019 15:59:53 -0800

> encoding, but without the "-1".

[Jeremy had a more eloquent description of the vague sketch of an idea that I had in my head]

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 16 Nov 2019 19:22:49 -0500

> [Jeremy had a more eloquent description of the vague sketch of an idea that I had in my head]

Jeremy's "isomorphic" encoding works fine for me, and is likely less confusing.
So, FWIW, it has my support.  Fleshing it out a bit more, I am proposing:

    - 0xff => send no tickets

    - 0x00 => reuse requested:
        + send no tickets if presented ticket is accepted and reusable
        + send one ticket if presented ticket is accepted, but is not reusable
          (expired, or reuse is not allowed).
        + Also send one ticket if session could not be resumed and a full
          handshake was performed.  Clients that reuse tickets don't need a
          separate one for each session, so one per full handshake should
          suffice.

    - 0x01-0xfe => client wants single-use tickets:
        + send up to that many tickets on full handshake,
        + however, generally send just 1 ticket on resumption, or when
          replacing tickets during long-lived connections.  This helps to
          reduce chronic ticket "oversupply".

-- 
    Viktor.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 19 Nov 2019 17:20:03 +0800

Hi,

Just to followup the discussion. I support Viktor,'s proposal as it
provides the ability to the client to specify what it wants rather than let
the server guess. What I am wondering is whether we are catching all
possible client "policies" or whether we should consider some additional
reserved values. Typically I do not see case where 200 tickets may be
requested, so we may have some place for reserved bits if needed.

I see my comment of how tickets are generated as complementary.

Yours,
Daniel

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 20 Nov 2019 10:40:20 +0800

> On Nov 19, 2019, at 5:20 PM, Daniel Migault <daniel.migault=[email-masked]> wrote:
> 
> Hi, 
> 
> Just to followup the discussion. I support Viktor,'s proposal as it provides the ability to the client to specify what it wants rather than let the server guess. What I am wondering is whether we are catching all possible client "policies" or whether we should consider some additional reserved values. Typically I do not see case where 200 tickets may be requested, so we may have some place for reserved bits if needed. 
> 
> On Sun, Nov 17, 2019 at 8:23 AM Viktor Dukhovni <ietf-dane@dukhovni..org <mailto:[email-masked]>> wrote:

Having a recommendation to generally just send one ticket doesn't address the motivating use case for the document, which is Happy Eyeballs (connection racing). Having multiple tickets is required in a steady state, so we shouldn't recommend against that.

Any client that wants to only do the reuse case can just not use this extension.

Thanks,
Tommy
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Nov 2019 22:48:12 -0500

On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote:

> Having a recommendation to generally just send one ticket

You left out the key qualification: "on resumption".  Now perhaps
that strategy is only needed in the *absence* of any signal from
the client, and with the extension the onus is perhaps on the client
to send "1" once it has enough tickets, in which case the server
does not need to apply the heuristic that helps it to avoid chronic
ticket oversupply.  In which case, the "generally send just 1" can
be left out, it is a side comment, not essential to the overall
proposal.

Somebody should try to avoid ending up with N new tickets after
every connection, but in could well be the client.

> doesn't address the motivating use case for the document, which is Happy
> Eyeballs (connection racing). Having multiple tickets is required in a steady
> state, so we shouldn't recommend against that.
> 

No, the extension is *very* useful to such clients, to signal to the server
that that's what they want to do, so that the server then only issues new
tickets when necessary.

-- 
    Viktor.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 20 Nov 2019 11:53:08 +0800

> On Nov 20, 2019, at 11:48 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

That would be great to leave that out.
> every connection, but in could well be the client.

Yes, I think that can and ought to be the client. The client is really the only party that can know how many tickets have been "consumed" by potentially failed attempts to connect that the server didn't see in time or got dropped.

Thanks,
Tommy

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 20 Nov 2019 01:48:19 -0500

On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote:

> Yes, I think that can and ought to be the client. The client is really the
> only party that can know how many tickets have been "consumed" by potentially
> failed attempts to connect that the server didn't see in time or got dropped.

OK, in that case, the proposal, is that on resumption, if the proposed
extension is *absent*, then the server should generally send just one rather
than any larger default.

If the extension is present, it is up to the client to not blindly ask for N
tickets each time, and generally ask for just one ticket on resumption, once it
has sufficiently many tickets for the desired concurrency level, with each
parallel thread obtaining one replacement ticket its next connection.

As discussed clients that prefer to reuse tickets, can ask for zero, and get 1
only as-needed.  If the server supports reuse then all is well.

If the server does not support and refuses reuse, then it will issue a new
ticket each time and may only accept it once, but the client may have a
single-slot cache.  If the client makes only one connection at a time, this
also works, but if/when its handshakes with the server overlap (a narrow window
of ~1RTT) and two connections attempt to resume with the same ticket, one of
them will end up doing a full handshake, but only when the client and server
applications have incompatible ticket reuse expectations.  Some friction
when the client and server are mismatched is not the end of the world.

So on the whole I think the proposal still works with just a numeric signal
(tweaked with 0xff == none and 0 == reuse), and the onus to "generally send 1"
on resumption moved to the client (i.e. clients that don't solicit ticket reuse
should request only 1 ticket once they have enough).

-- 
    Viktor.

---

From: David Schinazi <[email-masked]>
Date: Thu, 21 Nov 2019 11:19:36 +0800

Hi folks,

I've chatted with Daniel and Chris offline, and I think there might
have been some miscommunication here. Please allow me to
rephrase what I think is going on, and please let me know if
this accurately represents your views.

Daniel has a IoT use-case where due to memory constraints,
a client knows it can only handle a certain number of tickets,
and therefore Daniel was wondering if it would make sense to
make the requested number of tickets a required maximum
(as in a RFC 2119 MUST). However, server operators on this
thread have indicated that a MUST would get in the way of
implementing this, due to STEK rotation for example. Daniel
understands this, and is OK with the current mindset of the
document (which is only a hint, not a MUST). Additionally,
Daniel would prefer to see the document move forward.

In order to try to address Daniel's comments, I attempted
to rephrase the normative section to suggest in more
stronger terms that servers really shouldn't be sending
more than the client's request, but keeping it a SHOULD.

Here is the PR with the rephrase:
https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10

Here's a copy of the updated paragraph in the PR:
   Clients can use TicketRequestContents.count to indicate the number of
   tickets they would prefer to receive.  Servers SHOULD NOT send more
   tickets than TicketRequestContents.count, as clients will most likely
   discard any additional tickets.  Servers SHOULD additionally place a
   limit on the number of tickets they are willing to send to save
   resources.  Therefore, the number of NewSessionTicket messages sent
   SHOULD be the minimum of the server's self-imposed limit and
   TicketRequestContents.count.

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.

Thanks,
David

---

From: Rob Sayre <[email-masked]>
Date: Wed, 20 Nov 2019 21:01:39 -0800

>    TicketRequestContents.count.

This sounds pretty close to the "MAY option" I sent on Oct 2 here:

https://mailarchive.ietf.org/arch/msg/tls/YogBUOC0ZujSAxHVp8H0oIjJm3Y

The latter half of the patch's paragraph still uses "SHOULD"
interoperability requirements to remark on quality-of-implementation
issues, rather than just explain them. That's not great, but also not a
dealbreaker.

thanks,
Rob

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 21 Nov 2019 13:34:07 +0800

Thanks for clarifying, David! This text reflects my understanding and is fine by my. 

Best,
Chris

On Thu, Nov 21, 2019, at 11:19 AM, David Schinazi wrote:
> On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni <[email-masked]> wrote:

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 21 Nov 2019 13:37:46 +0800

>  TicketRequestContents.count.

Thanks for doing this David.

Friendly amendment: remove the SHOULD from this sentence (it's a consequence of the two other "SHOULD"s):

Therefore, the number of NewSessionTicket messages sent will be the minimum [...]

---

From: David Schinazi <[email-masked]>
Date: Thu, 21 Nov 2019 13:44:57 +0800

Thanks. I've updated the PR to take MT's suggestion s/SHOULD/will/.

David

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 Nov 2019 00:59:51 -0500

On Thu, Nov 21, 2019 at 11:19:36AM +0800, David Schinazi wrote:

> (as in a RFC 2119 MUST).

I agree.  I am also looking for servers to not oversupply clients with excess
tickets, and not expecting any obligation on the server to return as many as
requested.

> Additionally,

I am also keen for the document to move forward, it adds a very useful signal
from the client to server.

> complexity of the proposal,

There is no additional complexity in the protocol. The same extension
structure is sent, and its interpretation is almost identical.  The
only difference is:

    * 0xff is the new zero (client declines use of tickets)
    * 0x00 is a new value to signal optional (reusable) tickets
      as-needed.
    * 0x01-0xfe are interpreted exactly as in the original draft!
      (But clients should be *encouraged* to send 1 on resumption).

> and I don't see use-cases compelling enough to warrant that complexity. I
> would rather keep this proposal as simple as possible.

There are millions of Postfix MTAs that only support a single slot ticket
cache, and where a server that sends more than 1 ticket causes multiple writes
to the single-slot cache (hence part of the enthusiasm for the extension), but
also writes to the cache (which is an external Berkeley DB) create excessive
overhead.  Also the server wastes CPU and network bandwidth sending unwanted
tickets, but the client must not simply decline tickets, since it wants stale
tickets to be refreshed.

I have a hard understanding why a relatively simple proposal that meets the
needs of many deployed MTAs is not a valid use-case.

If you don't feel like authoring the text to make the requested change,
I can probably contribute a pull request.  At this time the details
seem to have been ironed out in principle.

-- 
    Viktor.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 20 Nov 2019 22:18:26 -0800

So, the current PR says:

"Clients can use TicketRequestContents.count to indicate the number of
tickets they would prefer to receive. Servers SHOULD NOT send more tickets
than TicketRequestContents.count, as clients will most likely discard any
additional tickets. Servers SHOULD additionally place a limit on the number
of tickets they are willing to send to save resources. Therefore, the
number of NewSessionTicket messages sent will be the minimum of the
server's self-imposed limit and TicketRequestContents.count."

I would suggest two edits to this text:

1: The second sentence can read: "If servers send more tickets than
TicketRequestContents.count, clients will likely discard excess tickets.".
This avoids a "SHOULD NOT" that should be a "MAY" or unmentioned.

2: The third sentence is implementation advice, not an interoperability
requirement: "Servers SHOULD additionally place a limit on the number of
tickets they are willing to send to save resources." I think this sentence
should be struck, or rewritten in non-2119 English. If the editors wish to
keep the text, I think there should be a comma after "send".

These proposed edits make sense to me, because servers can't know if their
tickets will be used successfully (network problems, unreliable clients,
etc).

thanks,
Rob

---

From: David Schinazi <[email-masked]>
Date: Thu, 21 Nov 2019 14:24:57 +0800

Hi Rob,

The SHOULD from your point (1) is there to address Daniel's concern about
IoT.
The SHOULD from (2) is indeed not required for interoperability, but
important
to ensure servers put this protection in place.

That said, I've taken your suggestion to add a comma since that is clearer.

Thanks!
David

---

From: Rob Sayre <[email-masked]>
Date: Wed, 20 Nov 2019 22:35:09 -0800

> The SHOULD from your point (1) is there to address Daniel's concern about

Is the idea that excess tickets would be wasteful? I think that's true, but
I would also not want an IoT device that crashed or performed
unnecessarily-poorly while processing excess tickets.

> to ensure servers put this protection in place.

In that case, this issue belongs in the Security Considerations section. I
understand that the concern is valid, but a "SHOULD" in this part of the
document is not the right way to communicate it.

thanks,
Rob

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Nov 2019 22:54:15 -0800

> document is not the right way to communicate it.

Is it more of a security consideration or an operational one?

-Ben

---

From: Rob Sayre <[email-masked]>
Date: Wed, 20 Nov 2019 22:59:32 -0800

> Is it more of a security consideration or an operational one?

Since it was referred to as a "protection", I thought it was a DoS concern.

If it's only implementation advice, that's also valid, but it doesn't call
for 2119 SHOULD language. The document should explain the operational
concern without using "SHOULD".

thanks,
Rob

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Nov 2019 23:29:08 -0800

> concern without using "SHOULD".

I disagree with your premise on when BCP 14 keyword usage is appropriate.
Which is to say, I think the "SHOULD" is fine for operational concerns.

-Ben

---

From: Rob Sayre <[email-masked]>
Date: Wed, 20 Nov 2019 23:32:28 -0800

> Which is to say, I think the "SHOULD" is fine for operational concerns.

 BCP 14, section 6:

"Imperatives of the type defined in this memo must be used with care and
sparingly.  In particular, they MUST only be used where it is actually
required for interoperation..."

thanks,
Rob

---

From: Sean Turner <[email-masked]>
Date: Thu, 21 Nov 2019 23:04:13 +0800

I’ve been remiss and not closed the WGLC.  Stay tuned for me based on today’s WG session.

spt

> On Nov 6, 2019, at 00:05, Sean Turner <[email-masked]> wrote:
> 
> All,
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 Nov 2019 12:50:34 -0600

> to warrant that complexity. I would rather keep this proposal as simple as

Complexity?  I don't see it -- and you didn't show it, only asserted it.

But the protocol is a bit broken -yes, broken- without that "option",
and here's why: the whole point of this extension is to

 - a) ensure that clients always have the resumption tickets they need,

 - and b) to reduce ticket issuance to the minimum necessary for (a),
   and, well...

 - that means only issuing resumption tickets when the client needs one
   to replace the one it's using,

 - and if the client and server are happy with ticket reuse, then it's
   up to the server to decide when the client's ticket may no longer be
   reused,

 - but the protocol as specified can't let the client say "give me a new
   ticket IFF you won't let me reuse this one any more",

 - and it doesn't let the server do such conditional issuance because
   the client might NOT want to reuse and the server can't know that if
   the client can't tell it.

That's the logical chain that leads me to declare this protocol broken.

The fix is trivial.  It most certainly isn't complex.  A plain assertion
that it's too complex is not responsive and insufficient to dismiss the
WGLC comment.

Nico
--

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 Nov 2019 14:45:51 +0100

> unnecessarily-poorly while processing excess tickets.

an IoT device that can be crashed by server just sending valid and expected
messages is horribly broken

if it can't handle such messages, I seriously doubt it would handle 
messages
from an actual attacker (which, need I remind, MUST be handled correctly 
and
result in orderly connection shutdown, one that hopefully includes Alert
messages)

---

From: Daniel Migault <[email-masked]>
Date: Mon, 25 Nov 2019 12:04:54 -0500

On Wed, Nov 20, 2019 at 10:20 PM David Schinazi <[email-masked]>
wrote:

> I apology for the late response. This addresses my MUST/SHOULD concern.
Thanks David.

> to warrant that complexity. I would rather keep this proposal as simple as

I particularly like the proposal from Viktor and - at least as I see it -
its associated simplicity. I believe it would be beneficial for the
document to include it.