On Tue, Jan 21, 2020 at 06:19:23PM +0000, Salz, Rich wrote:
> Viktor and I spoke in more detail. The use-case he brings up makes
> more sense to me now. The key observation is that this is not about a
I also spoke to Viktor, and he explained the motivation in detail. He
really should have done so on the list, but it is this:
TL;DR: Postfix multi-process ticket cache DB thrashing pain.
- Postfix (which he co-maintains) is a multi-process service (with
client and server functionality -- it's an MTA, after all)
- Postfix needs a multi-process ticket cache w/ concurrency
- OpenSSL provices no such thing, only a single process in-memory
cache, and also callbacks the app can use to implement its own cache,
which then Postfix uses to implement a multi-process ticket cache
- So, getting unnecessary tickets thrashes Postfix's shared cache,
which costs a fair bit due to synchronization
There are two ways to make this tolerable for Postfix:
- either the TLS server says "here's a ticket and you MUST or MAY
replace the one you already had"
or
- the TLS client gets to ask for no unnecessary new tickets
Now the first alternative would be infeasible to adopt because it would
require new OpenSSL callback APIs, and anyways would be a more invasive
change to TLS than the ticketrequest extension makes.
That's why Viktor would prefer the other way: let the client ask for no
unnecessary new tickets. This has the benefit of saving some bandwidth
and server cycles.
Now, as to the privacy issue. The server can simply always issue a new
ticket, even if the client didn't want it -- presumably MTAs wouldn't,
but HTTP servers would. And there is no way for -say- a great firewall
to force you to not get new tickets as the server can still always hand
the client one, and anyways, this extension can be (should be!)
encrypted, so the firewall can't know anyways. All a great firewall
gets to see is that your connections can or can't be linked. Especially
given Viktor's use case, we can assume (and require, evven) that only
SMTP MTAs might request no new unnecessary tickets, so that great
firewalls really can make no assumptions about this in HTTP use cases,
say.
> "client" in the conventional (or browser) sense, but rather more like
> a peer-to-peer kind of thing, where the client is just the one who
> initiates a connection and might be multiple processes running on
> multiple instances sharing an identity.
>
> I'm in favor of his suggestion.
Me too.
It's really very simple. There is no legitimate "unnecessarily complex"
argument; such arguments come across as unnecessarily dismissive.
There is a privacy non-issue, addressed as above, though it's fair to
demand that it be addressed.
Regarding the "define your own extension" responses... That's fine, I
suppose, but why ever bother with WGLCs for these if changes that
benefit others will generally be rejected out of hand? Why require TLS
WG review of extensions? Why not just make an Expert Review registry?
I think the answer to the last question is that we're not ready for that
-- we want some WG review, and, presumably, we want some commonality.
So, unless we're going to go with Expert Review only, then please do not
make this "define your own" argument -- it's at the very least impolite.
Nico
PS: Viktor tells me that hey, I've advised him to keep posts pithy, thus
he elided all the above explanation, but really, IMO, he should have
explained in detail.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
