@bascule To be fair, it does seem like you're missing a bit about how the spec works :) Subtleties about here
-
-
-
@bascule +=Supports,C=Client, S=Server. C(+)&S(-) - S shouldn't configure DHE, period. C(-)&S(+) - S's TLS lib should know to select !DHE -
@sleevi_ the real-world problem is humans saw Logjam and are trying to actively harden DHE cuz a scary branded vuln said so... -
-
@ivanristic@sleevi_ legacy shit has legacy problems. Implementers have to deal. You of all people should know this... -
@ivanristic@sleevi_ Logjam was a "branded" vuln that got people scared about weak DH groups except they didn't understand what they'd break -
@ivanristic@sleevi_ the thing that's driving me insane is it's breaking TLS handshakes for clients that WOULD NEGOTIATE ECDHE OTHERWISE -
@ivanristic@sleevi_ in an effort to shore up a legacy solution, we're breaking clients that wouldn't use the legacy solution anyway
End of conversation
New conversation -
-
-
@bascule just because Java sucks doesn't mean that FF-DHE is a bad idea :) -
@a_z_e_t it's slow, it has large keys, and it has sharp edges. That's why it sucks. And... keeping it around is breaking things -
@a_z_e_t but hey, let's make TLS more complicated by doubling down on features that nobody uses! -
@bascule actually a lot of sites still use it. and its the only fallback if somerhing in the ECC stack breaks. -
@a_z_e_t I not only called that argument out in advance in my first message but it’s wrong. There’s still RSA -
@a_z_e_t I’m not a fan of RSA for key exchange, but it *is* a backup in the event of an ECC-specific disaster -
@bascule i'll take ffdhe over rsa any day.
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.