That's just 2 minutes of thinking. No doubt there are "better" ones. Seems unrealistic to expect to prevent the server from leaking the ECDH key to something it trusts, in a scalable way that depends only on out-of-band shared key + the bytes on the wire. What's the exact goal?
(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.