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

[Viktor Dukhovni <[e-mail]>]

On Tue, Jan 21, 2020 at 07:17:05AM -0800, Eric Rescorla wrote:

> I agree with Martin that this is unnecessary complexity.

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

There is ZERO additional complexity.

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

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

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

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

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

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

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

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

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

     [VALID USE CASE]

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

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

     [ZERO COST TO PRIVACY USE CASE]

   * All servers have to do is:

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

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

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

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

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

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

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

-- 
    Viktor.