ServerHello.Random could be the ECDH private key, encrypted w/ shared secret, and everything would work fine for both use cases, for typical ECDH key sizes. And/or one could build a similar thing directly on top of the "randomness improvement" draft mechanism w/ a random Random.
It would be difficult. I think it helps that there are few unencrypted extensions in TLS 1.3 and almost all data is encrypted/authenticated. On the other hand, the record header is authenticated but not (required to be) verified to be in range so it allows a covert channel.
-
-
(FWIW I argued against the record header covert channel on the TLS WG mailing list but people disagreed.) I agree that such a design would be tricky and would require a lot of effort (not just a couple of tweets) and kind of too late since TLS 1.3 shipped. Not sure *impossible*.
-
Oh, maybe it can be done for QUIC.
-
Quic packets are the record layer for quic, so quic only forwards tls messages not records
-
Yeah, I mean, more generally, one could/should analyze QUIC more generally to see if there are unnecessary covert channels. I assume that since it uses TLS 1.3 then Server.Random is still one, for example.
-
The harder problem with QUIC is that the server could just send out a junk QUIC record that the client throws away, which contains the)(encrypted) information for the MitM to process. So, probably there's not much one could do.
-
Ya quic is designed ignore things that don’t decrypt so you could technically send a malformed udp packet with anything in it
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.