TLS delivers three things, Confidentiality, Integrity and Authentication. But intuitively these three things are what people expect their transport protocol to do anyway, it's actually surprising as a user that TCP doesn't really bother providing say, Integrity. "Oh, yeah, your data might be arbitrarily changed by the time it is delivered". Er, what?

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.

> The OSI model has been around for a very long while.

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).

I have absolutely no idea what anything you just wrote means. You're ramblings make no sense whatsoever, and they lead towards no conclusions. Get over yourself.

> "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 on-top of each other.

> "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 and light-weight as possible (hence it's original intention - to facilitate the transfer of information between endpoints, and leave the rest to whatever consumes that information).

> All I was saying is that there's no reason to introduce more complexity into the transport layer

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.

> "But there is, and I explained what that reason was."

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.

I studied networking in the university, 20 years ago. We did study OSI as well as TCP/IP and the rest of the actual Internet stack, and it was blatantly obvious that the latter doesn't really conform to the former - protocols straddling boundaries etc. For example, TCP is not a strictly transport-layer protocol, since it also handles sessions.

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.

TCP/IP does not use the OSI model. Stacking layers on top of each other promotes inefficiency and poor security, and is one reason why TCP/IP won over the OSI-recommended protocols.

> "Stacking layers on top of each other promotes inefficiency and poor security"

Yet that's exactly how the internet works today.

The advantage of merging TCP and TLS is improved performance and security/privacy (security/privacy is improved due to fewer session parameters being readable or modified by third parties)

So now what is the benefit of sticking to the OSI model, so that we can evaluate the pros and cons?

it's insane to expect the opposite: that traffic in my own network will need to keep reaching to a certificate authorities outside to validate packages from one host to another.

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.

The use of TLS for QUIC does not imply or require the use of the Web PKI which is what I assume you're thinking of by "certificate authorities outside to validate packages".

> "The use of TLS for QUIC does not imply or require the use of the Web PKI"

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've jumped from assuming the Web PKI, which isn't required, to assuming online revocation checks, which is even more not required.

So how does your imaginary version of a transport-layer guarantee a message can't be tampered with if it trusts keys which are revoked?

Web PKI is not the only way to revoke keys.

> "Web PKI is not the only way to revoke keys."

You're not answering my question (we both know why), and I never mentioned anything about WebPKI in any of my comments anyways.