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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
