Subject: [TLS] AD evaluation of draft-ietf-tls-ticketrequests-05

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Oct 2020 15:27:47 -0700

Hi all,

Thanks for everyone who contributed to this one; I think we ended up in
a pretty good place with it.  Sorry to have taken so long to get around
to processing it; on the plus side, the only document now in my
publication-requested queue is DTLS 1.3, and that will be entering AD
Evaluation shortly!

I think there's enough here that is reader-unfriendly that we should wait
to start the IETF LC until there's a new revision out, but hopefully the
needed changes will be fairly straightforward.

I made a few editorial suggestions and nit fixes at
https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/21 .

We have some level of duplication between the Introduction text
describing limitations of the stock 8446 mechanism, and the detailed use
cases in Section 2, but I think it's probably acceptable.

We talk about avoiding ticket reuse being a goal (e.g., explicitly so in
the "Parallel HTTP connections" use case), but we don't really say why.
I think the introduction could probably do with a paragraph on this that
references https://tools.ietf.org/html/rfc8446#appendix-C.4 for the
default behavior being to attempt to avoid reuse of tickets (without
implying that it is required behavior, of course).

Section 2

   *  Connection priming: In some systems, connections can be primed or
      bootstrapped by a centralized service or daemon for faster
      connection establishment.  Requesting tickets on demand allows
      such services to vend tickets to clients to use for accelerated
      handshakes with early data.  (Note that if early data is not
      needed by these connections, this method SHOULD NOT be used.
      Fresh handshakes SHOULD be performed instead.)

This doesn't seem to paint a very clear picture of the use case.  It
doesn't even seem to be clear about whether the "centralized service or
daemon" is a helper on the TLS client or server side!
I also want to check my understanding here, in that the recommendation
for only doing this when early data is needed is due to the fact that
you need to have an initial handshake with which to negotiate the
ability to use early data in the subsequent handshake, and having the
central service do a bunch of full handshakes just to get a ticket for
use on a subsequent connection that does user early data is a lot of
overhead, whereas if you don't need early data then you only do as many
full handshakes as you need connections (vs 2x that number to get a
ticket and then do early data) and get fully independent keys.  Since
you have this central service the extra latency for a full handshake is
irrelevant because you're priming connections in advance, not on-demand.

   *  Less ticket waste: Currently, TLS servers use application-
      specific, and often implementation-specific, logic to determine
      how many tickets to issue.  By moving the burden of ticket count
      to clients, servers do not generate wasteful tickets.  As an
      example, clients might only request one ticket during resumption.
      Moreover, as ticket generation might involve expensive
      computation, e.g., public key cryptographic operations, avoiding
      waste is desirable.

(I assume we have a particular case in mind that does use public-key
crypto when issuing a ticket, or we wouldn't have mentioned it.)

   When a client presenting a previously obtained ticket finds that the
   server nevertheless negotiates a fresh session, the client SHOULD
   assume that any other tickets associated with the same session as the
   presented ticket are also no longer valid for resumption.  This

Unfortunately, RFC 8446 does not seem to be consistent about "session"
(persists across multiple resumption handshakes) vs "connection" (a
single handshake) terminology.  We may want to consider just discussing
"full handshake" and "initial full handshake" instead of trying to use
the "session" shorthand.

   and the number requested.  Servers MAY send additional tickets, up to
   the same limit, if the tickets that are originally sent are somehow
   invalidated.

(nit) pedantically, the server can send whatever tickets it likes
whenever it likes.  The current "up to the same limit" looks a little
bit like it's trying to restrict the server's behavior, so "typically
using the same limit" might be better.

   Servers MUST NOT send the "ticket_request" extension in ServerHello
   or HelloRetryRequest messages.  A client MUST abort the connection
   with an "illegal_parameter" alert if the "ticket_request" extension
   is present in either of these messages.

I note that we do have other messages (Certificate, CertificateRequest,
NewSessionTicket itself, maybe soon ClientEncryptedExtensions) that can
carry extensions, so in that sense it's strange to only explicitly
prohibit these two.  That said, they are the two that would be most
tempting to (inadvertently) put this extension in, so I don't
particularly mind leaving it this way.

Section 6

I suppose there is perhaps some risk of traffic analysis leaking how
many tickets were issued at the start of the connection (and thus the
value that the client requested), but this is neither terribly
interesting nor terribly novel, so I don't propose that we add text
about it.

   Despite ticket lifetime hints provided by servers, clients SHOULD
   dispose of pooled tickets after some reasonable amount of time that
   mimics the ticket rotation period.

While this is true and good advice, I note that §4.6.1 of RFC 8446
already has "MUST NOT cache tickets for longer than 7 days".  It does
not look like this advice is fully duplicating the 8446 advice, so
perhaps an additional sentence like "As specified in Section 4.6.1 of
[RFC8446], 'clients MUST NOT cache tickets for longer than 7 days'."