There's been some drama in the TLS WG. I wrote it up. https://www.cs.uic.edu/~s/musings/tls13-enterprises/ …
-
-
Replying to @stevecheckoway
Great write-up! I think what is urgent is modifying TLS 1.3 to forbid static-DH, otherwise it will happen regardless :( Feels like an attack
1 reply 1 retweet 6 likes -
Replying to @colmmacc @stevecheckoway
I'm firmly in the pragmatist camp too, and don't think finding an alternative solution is urgent, but DH should be enforceably ephemeral.
1 reply 0 retweets 1 like -
Replying to @colmmacc
I've been thinking about this a bit but I don't see how it could work. Even if a peer could prove it just generated the DH secret key, 1/2
1 reply 0 retweets 0 likes -
Replying to @stevecheckoway @colmmacc
how does it prove destruction of the key or that it didn't send the key to a key-logging server? 2/2
1 reply 1 retweet 1 like -
Replying to @stevecheckoway
It doesn't, but it raises the cost of that attack to the same as the cost of logging PMS. Always in favor of making attacks more expensive.
2 replies 0 retweets 2 likes -
Replying to @colmmacc @stevecheckoway
I also think of it as preventing an inadvertent implementation mistake, similar to how implicit nonces do for AEAD.
1 reply 0 retweets 2 likes -
Replying to @colmmacc
Maybe one could use a NIZK to prove knowledge of PRNG inputs used for DH sk, but who wants to verify a proof each TLS connection?
2 replies 0 retweets 0 likes
That's a smart idea. In practice it can enough that tools like SSLabs do it occasionally. That's how endpoint security is /really/ enforced.
-
-
-
Replying to @stevecheckoway @colmmacc
For comparison, CT validation is never enforced for privacy reasons. This might actually work.
1 reply 0 retweets 0 likes - 4 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.