Thread by @vcsjones

OK, let's do this. I guess for the next hour or so, I am going to tweet random crap about QUIC. First, for the uninitiated, QUIC is a network protocol, for the lack of a better term, is TLS and HTTP/2 over UDP.

I can think of a few reasons why UDP would be preferable. I think it makes multiplexing easier, and the draft RFC specifically calls out no need for compatibility with existing HTTP/TLS so as not to confuse old OSs or middleboxes.

TLS 1.3 is a great example where middleboxes forced compatibility changes to make it "look" like TLS 1.2 traffic so that middleboxes wouldn't block it because they didn't recognize the protocol.

So the TLS 1.3 spec includes things to make it look like TLS 1.2 and a bunch of people spent a lot of time trying to figure it out. Makes sense to start from something that doges that bullet... probably. I'm sure there's some fun cases.

QUIC's RFC for including TLS is separate but they seem very intertwined.

It would seem that QUIC in "plaintext" form is not meant to be a thing.

QUIC packets are numbered, and can be from 0..2^62-1. BUT, the first packet number does not start at 0, it starts at "The initial value for packet number MUST be selected randomly from a range between 0 and 2^32 - 1025"

If you run out of packet numbers, a QUIC endpoint just stops talking entirely. This seems suitable given that the RFC also indicates that the packet number (somehow) plays a roll in determining nonces for encryption. The details seems to be in the QUIC-TLS RFC.

QUIC depends entirely on TLS 1.3.

Ah see, the QUIC RFC kind of makes that coupling a little more clear: "
Rather than a strict layering, these two protocols are co-dependent:QUIC uses the TLS handshake; TLS uses the reliability and ordered delivery provided by QUIC streams."

Note that QUIC is just a transport protocol. It does not prescribe HTTP specifically. That occurs in a separate document. You could also, say, implement Remote Desktop over QUIC.

It wouldn't be a new protocol without a little drama. QUIC's latest seems to be the "spin bit" tools.ietf.org/html/draft-tra…

UDP does not offer anything "already there" like TCP for measuring latency by passive observation. Network carriers consider this important. QUIC encrypts everything, including ACK frames, time stamps, etc.

The proposal is to add a _single_ bit to the short header that flips, and passive network operators can measure time between the flip.

Some people really seem to dislike the idea of adding something to the protocol that doesn't do anything besides enable passive measuring.

In QUIC TLS - the TLS handshake itself is encrypted with AEAD_AES_128_GCM to prevent middleboxes from tampering with negotiation. Once the handshake is done, it switches to the cipher selected by TLS.

Man QUIC is like, super pissed off at middleboxes.

The AEAD nonce is an XOR of an IV and the incrementing QUIC transport packet number.

The IV is derived via HKDF.

The RFC specifically mentions a concern for packet reflection attacks. QUIC tries to mitigate this by padding the ClientHello packet to a certain size.

Also, the ClientHello needs to fit entirely in a single packet, so 1129 bytes.

I don't know why but the later part kind of gives me pause. 1,129 bytes seems like a lot, until it's not.

I seem to recall a few TLS implementations barfing when the ClientHello got too big.

The TLS part was the most interesting for me. Not because it does anything weird but because I just generally like that stuff. There is still a lot for me to dig in on actual QUIC. I skimmed that so I could read the TLS part first.

I guess, to ask myself, what makes QUIC "quick". A few thoughts...

TCP has all that gnarly slow start and congestion control. UDP drops packets and moves on.

QUIC can make certain assumptions. For example, an ACK frame is not necessary for all frame types, like the retry packet.

Next question is, how does a browser "know" a site supports QUIC for HTTP?

Basically, the browser (Chrome) starts off with a regular TCP connection. The server tells the client "hey buddy I support QUIC" via the Alt-Svc HTTP header or HTTP/2 frame. The browser can then decide to switch to QUIC based on the header.

Based on that, I don't believe it is possible to run a QUIC-only web server right now unless you use magic flags to force Chrome to connect to the site as QUIC and slip HTTP TCP entirely.

The Alt-Svc header includes the port, so you can run QUIC on any UDP port, not just 443. But nothing is stopping you from running QUIC on 443, too.