
The Maturing of QUIC - kungfudoi
https://www.fastly.com/blog/maturing-of-quic
======
mey
The spin bit reminds me of the evil bit[1]. Endpoints/clients/servers don't
have much reason to set it, except when explicitly running a trace. It may
work under initial implementations, but I expect it will eventually become a
dead field. Why maintain the code complexity to expose this information to a
network operator? Even worse, "malicious" clients could spin the bit randomly.

[1]
[https://en.m.wikipedia.org/wiki/Evil_bit](https://en.m.wikipedia.org/wiki/Evil_bit)

~~~
cesarb
> but I expect it will eventually become a dead field.

I hope that's all that happens. My worry is that middleboxes will start to
depend on it, and any implementation which doesn't spin it "correctly" (where
"correctly" is defined by the middlebox vendor, not the standard) will be
blocked.

~~~
tialaramex
Depend on it to do /what/ though?

Middleboxes can equally well insist upon tampering with other data they can't
interpret in QUIC, and that too just causes the packets to be discarded. To
what end? Middleboxes aren't actively malevolent they're just built by idiots.

Our experience has been that middlebox vendors _ossify_ things. They see a
field that's defined "Zero: Reserved for future use" and they say "Aha, that's
supposed to be zero" and so now that "future use" can never happen.

For example the Certificate in TLS 1.2 and earlier isn't intended to be useful
to anyone except the TLS Client. But middleboxes interpret it anyway, they
insist it should be an X.509 certificate, possibly from a known CA - and so
it's impossible to add a "Gzip'd Certificate" feature to TLS 1.2 even though
if you look at the protocol description it's easy to see how, if you actually
tried you would find middleboxes throw a fit since this isn't X.509 and now
your software can't be deployed.

But in TLS 1.3 compressed certificates are a thing, because TLS 1.3 encrypts
almost everything and that includes Certificate. A client can say "I grok
Compressed Certificates" and the server goes "Here's a Compressed Certificate"
and nobody else is any the wiser. A middlebox doesn't know about it and so it
can't meddle.

~~~
mey
In a lot of corp env, a corp CA is injected, which allows middleware to MITM
sessions. TLS 1.3 still allows this nonsense. Most current gen firewalls rely
on this to be useful.

~~~
tialaramex
In TLS 1.3 you can only do this by proxying all connections. Whereupon all
these hypothetical non-compliant QUIC streams are yours and nobody on the rest
of the Internet cares.

This is a significant (and for the "IT security" industry expensive) change
compared to previous versions but it was done with this in mind. The methods
often employed to avoid doing proxying don't actually deliver security though
they did ossify the protocol but they are cheaper. Too bad.

Let's take my compression example again. Your "firewall" won't tell you it
understands compressed certs since it has no idea what they are, and it won't
request them from the server, no ossification. New features don't work for you
inside your "firewall" making the Internet worse for you, but for everybody
else improvements continue.

The same for the spin bit. Corp A enforces a completely broken spin bit for
"security", it suffers mysterious and hard to diagnose network faults but the
rest of the Internet isn't affected and life continues as normal.

------
iknowstuff
QUIC has the concept of multiple streams within a single connection. I wish
some of those streams could be set as unrealiable/unordered. The QUIC stack
(with its congestion mitigation, encryption etc) could replace barebones UDP
in online games, videoconferencing, WebRTC etc.

~~~
randyreddig
Agree. There have been a handful of proposals to add unreliable or datagram
streams to QUIC, including:

[https://tools.ietf.org/html/draft-pauly-quic-
datagram-05](https://tools.ietf.org/html/draft-pauly-quic-datagram-05)

[https://github.com/tfpauly/draft-pauly-quic-
datagram/blob/ma...](https://github.com/tfpauly/draft-pauly-quic-
datagram/blob/master/draft-pauly-quic-datagram.md)

------
baby
IMO if QUIC truly wants to become TCP 2.0 it needs to accept something else
than TLS.

TLS is an Ok protocol for the web, but for other scenarios it makes zero
sense. Noise makes much more sense.

~~~
tialaramex
Noise isn't a protocol, it's a recipe for building protocols. So this is like
suggesting QUIC WG having bought all the rest of the furniture for the house
should instead of buying this ready made dining table & chairs that fit the
rest of the house perfectly buy a book on carpentry and chop a tree down to
start making the table by hand.

Most situations which would /not/ be happy with TLS here will likewise find
things not to like in any particular hypothetical Noise-based TCP replacement,
because the parameters of the recipe matter to them. They'd like a different
hash function, different type of symmetric encryption, or different DH. In
Noise the only way to do that is start over, like if during final assembly of
the table you decided you want a pine table not an oak one. So these people
would most likely insist on using Noise for their own custom protocol anyway
regardless of what QUIC does.

And if you _do_ use the Noise recipe it's not as though you just throw in the
elements you've chosen and out pops a replacement for TLS. Noise isn't
interested in the handshake problem, which is 95% of TLS, it's just waved away
as something you should solve for yourself. For a VPN like WireGuard that's
not crazy - in practice many VPN setups did this, or worse, already. But for
most TCP connections (even ignoring the Web) it's a non-starter.

So Noise replaces 5% of what TLS does for QUIC, and only once you've picked
your ingredients. It's a bad trade.

~~~
baby
> Noise isn't a protocol, it's a recipe for building protocols. So this is
> like suggesting QUIC WG having bought all the rest of the furniture for the
> house should instead of buying this ready made dining table & chairs that
> fit the rest of the house perfectly buy a book on carpentry and chop a tree
> down to start making the table by hand.

Take a look at nQUIC:
[https://eprint.iacr.org/2019/028](https://eprint.iacr.org/2019/028)

> Noise isn't interested in the handshake problem, which is 95% of TLS

That's part of my point. If you do not need TLS, now suddenly you rely on this
huge dependency and you have to figure out x509 certificates.

------
sempron64
Does the QUIC proposal do anything to address encrypting SNI?

~~~
rrll22
> HTTP/3 relies on QUIC as the underlying transport. The QUIC version

> being used MUST use TLS version 1.3 or greater as its handshake

> protocol. HTTP/3 clients MUST indicate the target domain name during

> the TLS handshake. This may be done using the Server Name Indication

> (SNI) [RFC6066] extension to TLS or using some other mechanism.

So if TLS 2.0 starts using ESNI (either draft-ietf-tls-esni or draft-ietf-tls-
sni-encryption) QUIC will benefit from that too. Otherwise, QUIC is neutral.

------
Ericson2314
I'm actually excited. So rarely does this industry clean out the old ossified
stuff, vs slap a new layer on top. Here we finally have solid layering for
networking, is QUIC is now a suite of protocols as it should be. Truly great
news.

------
amluto
> encrypt the packet first using the packet number as a nonce, and then
> encrypt the packet number using some of the encrypted packet as a nonce (and
> a different key).

I may be missing any number of details, but I would expect a simpler scheme to
work well: encrypt the packet number in ECB mode using a separate derived key.

------
kjsthree
> ...chatter within the community made it clear that many organizations were
> chomping at the bit to start implementing as soon as the IETF...

It’s “champing at the bit”, not “chomping at the bit”

/internet pedantry

Fantastic article though and I’m very interested in the future of QUIC/HTTP3.

------
Aleeshakhan786
Useful

------
gambler
Why do I feel like one of the most meaningful things I can do with my
professional life would be to find some like-minded engineers and design HTTP
1.2?

~~~
colechristensen
Many things would benefit from being redone "right" but the hurdles to get
over are almost insurmountable.

I'd like to rebuild unix front the ground up.

~~~
layoutIfNeeded
> I'd like to rebuild unix front the ground up.

Pls implement proper async syscalls this time. Thx.

~~~
colechristensen
what do you mean by "proper"?

~~~
deathanatos
Many — most? — of the system calls in nixes, even Linux, that deal w/ I/O are
blocking calls. Sure, you can chuck them into a background thread, but even
that isn't quite what you want, since you can't interrupt the background
thread while the blocking call is blocking.

Sure, we've got async networking, timers, events nowadays. But disk I/O is
almost completely async unaware (and even if you can work around the main
problem of I/O to a file, there's a ton of auxiliary calls like link, unlink,
rename, mkdir, chmod/chown, etc. that are blocking and, AFAIK, have no async
equivalents). I'm not sure if you can wait on a process (I think kqueue might
support this, but IDK about Linux).

And more fundamentally, I don't think you want synchronous I/O calls that only
allow you to do one thing per thread at a time. You _want_ to schedule as much
I/O as you have available with the OS as it becomes available, s.t. the OS has
a more complete picture of what I/O is actually outstanding, to better
schedule it.

~~~
pjc50
I got halfway through a back-of-the-envelope spec for how this might work.
Change "everything is a file" to "everything is shared pages", but impose the
additional sanity restriction that each accessor of a shared page should
choose to mostly write or mostly read using lockfree structures.

Then instead of the operating system allocating a "standard in" for you, every
process would be handed two event ring buffers, one for incoming and one for
outgoing events. On waking, all the process has to do is scan the ring buffer.

Potentially easy to make suitable for microkernels too, by passing the buffers
directly from process to disk subsystem.

------
hollerith
>QUIC is a brand-new internet transport protocol

In 1979 QUIC was software (for IBM mainframes IIRC) that produced a printout
of lines in lexicographic order with the twist that the words on the line were
shifted to eliminate initial noise words. E.g., THE TWO TOWERS appeared in the
printout as TWO TOWERS THE (and maybe also appeared as TOWERS THE TWO).

~~~
yeaaaaah
Thankfully we've now realized that "initial noise words" are fine and
shouldn't be shifted when sorting.

~~~
tialaramex
Mmm?

No, there are a bunch of places where it doesn't matter as much because
digitisation means searching is unnecessary, but when it matters, it still
really matters.

In my music player under artists The Chemical Brothers sorts with Chvrches not
with The KLF.

Human indexes are still really valuable in reference works, maybe we're
getting close to AI making a useful stab at it, but pick up a copy of K&R and
compare most auto-generated indices (if you can find a book that even bothers
with an index) today, it's night and day.

