... what is relevant in the IETF at the moment and why.

This I find very hard to summarize, except for having an impression confirmed that essentially everything is moving to QUIC. If it can be done im QUIC, there is a lot of pressure to do it in QUIC.

Is this good or bad?

Well, I guess it's a little bit of both. One person put it as TLS eating its way into every part of the stack. Which means that we'll have more transport security by default, while having similar behavior to the TCP we're..

... used to. That's good, right?

It generally is. Except for a few annoying parts.

First, transport security isn't end-to-end security. It seems that people can forget that the goal is humans, not machines communicating, so transport security is of limited use.

The second thing is that switching from one protocol to the other means there is a need for a signalling mechanism telling clients how to connect to a service.

And guess what people always get back to?

That's right, DNS.

So now...

... it's no longer enough to resolve names to IP addresses, you also have to resolve to choices of transport protocols.

With encrypted transports, you always have a key exchange to deal with, which can be slow.

The TLS issue is that you have a TCP handshake, which exchanges three packets. Once the TCP session is established, you have a TLS handshake, which is also three or more packets. QUIC adds key information from the start, so you only have one handshake that combines both purposes.

So...

... what next can you optimize? You can put the key exchange even further up front, which may speed up the QUIC handshake.

And that only leaves us with DNS as anything that comes earlier. In addition to IP addresses and transport choices, now folk wish to put keys into DNS as well.

Which may be fine with small Edwards keys. But several KiB of post quantum cryptography key won't fit into a DNS message, which is in practice bound by the size of a UDP datagram.

So what then - we can't do DNS...