The IESG has approved QUIC Version 2 for publication as an RFC | Hacker News Reader

The IESG has approved QUIC Version 2 for publication as an RFC

datatracker.ietf.org

33 pointsmfiguiere17 comments

So the only difference is they incremented the version number and changed some other numbers, just to make sure that all software will have to be able to handle the numbers changing going forward, so changing them again won't break things?

There seems to be one other new thing: "Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in [QUIC-VN] to prevent version downgrade attacks.", with that QUIC-VN being another draft which also seems to have been approved for publication at the same time (https://datatracker.ietf.org/doc/draft-ietf-quic-version-neg...). So if I understood it correctly, what's actually new is the version negotiation mechanism, with QUIC version 2 being its first user.

Yep... yawn. Why bother with the time and effort it takes to do this? I don't get it.

Because they didn't do that with TLS and HTTP, and then they discovered many networks had become home to middleboxes that shipped ossified out of the box and broke horribly whenever trying to deploy any improvements

They're like mold, these middleboxes. Grows easily, doesn't evolve much, likes sitting in the dark, surprisingly hard to kill, and ultimately not very friendly to human life

By exercising the fields early and encrypting anything that's not nailed down, they prevent ossification from taking hold before it becomes a problem

On the other hand, they prevent middleboxes from providing any value as well. I don't mean stupid nonsense like corporate TLS man-in-the-middle, but also.... load balancers.

That’s the point.

This approach to preventing ossification is interesting, and also rather bad, since it creates cruft RFCs such as this one.

The approach has the downside of creating cruft RFCs, yes. But does that make it bad? Ossification is a real problem. What analysis are you doing which forces you to conclude that a few cruft RFCs is worse than the practical problems they solve? Or is there some other mechanism you'd prefer which achieves the same result but without cruft RFCs?

I really wish the IETF would change the QUIC spec so that it must allow connections even without CA based TLS. As of right now the implementations from Google do not.

Nothing in the QUIC spec mandates the use of well-known CAs, as far as I know. (And QUIC-TLS is a separate spec because the crypto protocol is a natural extension point in QUIC -- experiments for QUIC with Noise already exist.)

QUIC uses TLS1.3. You need a trusted CA on the ends but it doesn’t need to be one you pay for. That’s how any version of TLS works.

Right. Requiring TLS via CAs means that you cannot host a public visitable website on HTTP/3 without the continued permission of an incorporated entity. Just like with (most of) HTTP/2 in practice. But very much unlike HTTP/1.1.

You're not going to be able to host a website without an "incorporated entity" continuously providing you a network connection either. That seems like the much harder bar to clear given the existence of Let's Encrypt.

Lots of people have been deplatformed by their ISP. Even if your CA did try to shut you down you could switch to literally any other CA in the world on a moment's notice. You can't do that with your ISP.

Yep. ISPs should be regulated like phone lines: a utility. There's really no excuse for the way the law fails to protect citizens this late into the internet revolution. Can you link me to some of the incidents of people "deplatformed by their ISP"?

I consider it a bit different because there are far more ISPs than there are CAs. Most human persons currently just use letsencrypt (good, but not good that everyone does).

Requests for Comments have to be approved?

Can you imagine how many half-baked, poorly-specified, insecure-by-design RFCs would be published if they didn’t have one?

Of course. It’s a committee and everything moves forward by approval.

Reply on news.ycombinator.com