My understanding earlier in the standardization process was that nothing prohibits a static DH. There's no real way for a client to tell that it happens. (This eTLS stuff has some visibility requirements, except when it doesn't.)
Yeah, that's what I'm trying to say. And, to be honest, the design & implementation of even an impossible-to-detect mechanism is not hard.
-
-
how do you get around the CA problem? I'd think a stealth intermediary would get flagged pretty quickly by Mountain View.
-
Like I mentioned earlier in this thread, if you want to share a static key but you need the ECDH key to change every connection, you can do that by making the ECDH key a function of the static key and Server.Random.
-
If we wanted to prevent this kind of thing, then we would have tried to find a way to make the protocol secure by making Server.Random deterministic, and get people to insist on that variant of TLS. (Even now, given the use of ephemeral DH, does Server.Random need to be random?)
-
This is an impossible problem. You’d have to lock down every potentially random byte of the protocol to make this work, and even then you could always use a timestamp or an out-of-band channel.
-
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
- 3 more replies
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.