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.
Conversation
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.
1
1
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
I'd just say be aware that nginx configuration is full of header injection vulnerability traps. It's far less of an issue with HTTP/2 due to the binary framing for headers. It will just get caught as invalid frames. This is the worst aspect of it:
gixy is an open source linting tool able to catch a lot of it without many false positives. The add_header override linting can be a bit annoying since there isn't a way to declare that yes, you really do intend to override that header from the out scope without adding it back.
1
2