A tradeoff would have been QUIC not requiring it but the higher level http/3 protocol requiring (if that’s possible idk)
BCP 78 "Pervasive Monitoring is an Attack" says the Internet should design new systems to resist such monitoring and so offering these intuitive properties for a new transport protocol made sense. And that's what QUIC is. In a BCP 78 universe it doesn't make sense to ship new protocols that will be rendered useless by the surveillance apparatus.
if you don't understand why these 3 things are on top of tcp, well, nevermind, I was going to say you shouldn't be designing networks buy you migth be already on the quic steering committee.
most committee now are a joke so that some googler middle mamaget makes it to jr director. sigh.
Handling certificate revocations (which would be needed to "ensure security"), does indeed imply the use of some way to check for the revocations in a timely manner. The revocation lists themselves can be tampered-with.
You're not answering my question (we both know why), and I never mentioned anything about WebPKI in any of my comments anyways.
TCP is a transport-layer protocol (ref the OSI model). The responsibilities of a transport-layer are neatly summarized here: https://en.wikipedia.org/wiki/Transport_layer
The OSI model is comprised of layers of abstractions, each building on-top of each other. Making TCP (a transport-layer protocol) depend on TLS (an application-layer protocol, ref https://en.wikipedia.org/wiki/Application_layer) is completely backwards, and makes absolutely no sense when considering the model.
The OSI model has been around for a very long while. If you have a degree in CS, or have studied networking in university - chances are you've had to learn about the OSI model. There's no reason to throw that away now, or reinvent the wheel.
Yet that's exactly how the internet works today.
Even imagining that for some reason I wasn't aware of that, why would it be relevant?
> If you have a degree in CS, or have studied networking in university - chances are you've had to learn about the OSI model.
And the waterfall software development model. A bunch of long obsolete data structures. Open Hypermedia (remember that? No? That's OK it doesn't matter any more).
What's happened here is that you've privileged a bad model that somebody probably taught you out of a textbook (hopefully while grimacing, since this is useless "information") over the real world experience of dozens of really smart people who work with actual networking and designed QUIC.
Maybe, if I'm giving you benefit of the doubt you've assumed "user" somehow means "undergraduate who is studying the OSI model" but it doesn't - billions of people use the Internet, far more than will study any degree, let alone Computer Science. And it's quite reasonable for them to expect their communications to have these three properties.
If your preferred model insists that we can't have security until the application layer then your model is wrong, just as surely as if you have a model of the Atom which assumes it's a solid ball of something (the plum pudding model, as with OSI perhaps some undergraduates were taught this model between when it was proposed and when experiments showed it's just wrong).
> "What's happened here is that you've privileged a bad model that somebody probably taught you out of a textbook"
So you're dismissing the OSI model as a "bad model" that "somebody taught me", yet there's this other shiny thing developed by "dozens of really smart people" and that's clearly the way to go because those people "work with actual networking".
> "And it's quite reasonable for them to expect their communications to have these three properties."
Their communications are clearly secured and tamper-proof already today, despite not using QUIC. How do you square that?
The security happens at the application layer, using mechanisms such as TLS. Additional security mechanisms can clearly come on-top. No need to bake everything into a single transport-layer protocol when there's endless flexibility available by layering the protocols.
> "If your preferred model insists that we can't have security until the application layer then your model is wrong"
How about instead of throwing fits about some vague ideas of "security" you actually provide concrete examples of what it is you're talking about, so that we can have a meaningful and constructive conversation about technology?
All I was saying is that there's no reason to introduce more complexity into the transport layer, since "security" is already handled by the application layer (on a per-application basis). It's unclear whether a single "security" model fits into the transport layer, which should be as agnostic as possible (hence it's original intention - to facilitate the transfer of information between endpoints, and nothing else).
But there is, and I explained what that reason was. The real world is under no obligation to faithfully copy your OSI Model, on the contrary, the fact the OSI Model doesn't resemble the real world is a good reason to abandon it.
If your reason is "security" (whatever that means, you won't define that either), then I too, explained how that is guaranteed by application-layer protocols already today - so it's unclear why changing the transport layer is needed. Again, you're not saying anything concrete and keep handwaving - I don't think you really want to (or can) have a conversation, really.
When asked, our prof readily admitted that the OSI model was one of those design-by-committee experiments in purity that quickly broke down IRL.
So now what is the benefit of sticking to the OSI model, so that we can evaluate the pros and cons?
Lenovo Superfish exposed the limitations of the CA system.
It significantly reduces the attack surface (Certificate Authorities vs every ISP), it makes it a lot harder for state actors to pull off those attacks deniably with a gag order, and it makes it a lot easier for an informed but non-expert consumer to pick a secure-by-default solution.
The defense against compromised certificate authorities starts with platforms and browser makers. They demand that CAs implement certificate transparency logs to be included in root stores.
They also monitor CT logs, as do most large site operators. Facebook for example does not run an OS platform or browser, but has a robust CT monitoring program.
So if one of the random little CAs in the root store of your browser issues a rogue cert for “google.com”, it will be logged and seen, and that CA will risk getting kicked out of the root store. That’s what happened to Symantec, which was not a small CA.
In general it is safer and quieter for bad guys to target client devices with attacks like Pegasus, than systemic actors like entire CAs.
The victim might be the only one getting a collision as governments target them (and no security researchers get the compromised public key), and the Superfish cert shows that a collision is simply ignored by the browser.