Which is the whole point of the static DH proposal. To build something you can detect.
-
-
The alternative proposals were much worse, and now hopefully those won't happen.
3 replies 0 retweets 3 likes -
Replying to @matthew_d_green @agl__
in any case, your kludge doesn't change the protocol. Anyone who thinks they need it can implement it themselves.
1 reply 0 retweets 1 like -
Replying to @BenLaurie @agl__
I think you've answered your own question. Nobody is being screwed because it doesn't change the protocol.
1 reply 0 retweets 1 like -
Replying to @matthew_d_green @agl__
nobody is screwed if you don't give it an RFC. If you do, it makes it look legitimate/good.
1 reply 0 retweets 5 likes -
Replying to @BenLaurie @agl__
I very much doubt this will get an RFC. But I want it in front of IETF rather than in an industry trade group like ANSI.
2 replies 0 retweets 2 likes -
Replying to @matthew_d_green @agl__
what would be useful is an RFC that describes how to detect and block this bad practice. :-)
1 reply 0 retweets 3 likes -
Replying to @BenLaurie @agl__
I love it! Write that I-D and we can coordinate. Or we can add a section to this one.
1 reply 0 retweets 2 likes -
The real problem is that TLS 1.3 (last I looked) didn't clearly mandate fresh key shares for each session.
2 replies 2 retweets 3 likes -
Replying to @matthew_d_green @BenLaurie
I think (esp in light of https://dl.acm.org/citation.cfm?id=2987480 …) that we might need to enforce fresh DH in code.
3 replies 0 retweets 8 likes
Why is this even an issue? Either peer should be able to enforce ephemerality if DH is properly used.
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.