aah like so, I just see DTLS as a transport layer since from the application side it doesn't really matter if you have a raw or dtls stream the protoco stays the same
e.g. how https is still http but just over a tls layer
the only big difference with webrtc is the rtp muxing
Conversation
QUIC ended up just using DTLS but it's actually properly aware of it, unlike SCTP, and it doesn't end up with a separate layer of buffering/framing, etc.
QUIC actually started out with a much simpler, stripped down replacement for TLS but TLS 1.3 made TLS much less bad anyway.
1
1
They ended up just going with TLS 1.3 (DTLS variant) which is still a lot more complicated than the original QUIC encryption for Google's variant of it rather than the IETF variant. It's the main thing they changed as part of the standardization and not really for the better.
2
1
It's better if you view it as better to avoid introducing a new protocol. It's worse if you look at it in isolation in terms of TLS still having a lot of unnecessary complexity. They greatly simplified the possible states.
TLS 1.3 is simplified but not as much as QUIC did it.
2
1
It's hard for them to simplify TLS much more than they already have because of middleboxes being aware of it and doing stupid things. ECH (Encrypted Client Hello) would help enable further simplifications but that's not at all designed / meant for universal adoption.
1
1
You have to use an HTTPS record for ECH and stick your ech public keys in there so the client can get the keys needed to encrypt the connection. It's separate encryption so you can still have something like nginx.org/en/docs/stream without terminating TLS, just terminating ECH.
1
1
HTTPS records also provide an equivalent to HSTS via DNSSEC rather than it only working properly via HSTS preload lists. I find it a bit weird that they made HTTPS records as part of a SVCB/HTTPS record meant to replace SRV or even CNAME records.
1
1
They also threw in these totally superfluous ipv4hint / ipv6hint properties despite requiring that clients prefer using the A/AAAA records if already available and stating that servers should use the additional section to provide the A/AAAA records. Anyway that's just weird.
1
1
It seems like they might have originally intended to replace A/AAAA records. PowerDNS knows how to fill them out automatically.
doc.powerdns.com/authoritative/
Doesn't make much sense since it also sends an additional section with A/AAAA and standard says use those when available.
2
1
The standard even talks about optionally dynamically switching to what A/AAAA provided after the fact once they become available. I just don't get why they made it so complicated. If they wanted to replace A/AAAA they should have just actually done it.
Oh, and the one other thing done by HTTPS records which is declaring support for HTTP/3 since it's not TCP/TLS-based so it can't be a transparent upgrade for the initial connection like the ALPN-based upgrade approach used by HTTP/2.
Anyway, really the whole kitchen sink.
1
1
I'm reading this thread and now I'm afraid to asks if it's okay to just stick to http and jam everything behind nginx
1
1
Show replies