On Thu 2019-02-21 00:16:54 +0000, Peter Gutmann wrote: > (A side-note about the 3526 values, they've been independently verified > outside of their publication in the RFC, has anyone done this for the 7919 > ones? Not saying they're suspicious, but it'd be good to get independent > verification that the data values match what's described in the RFC).
i'd welcome any additional double-checks. iirc, at the time of publication, Tero Kivinen checked them independently, but i'd welcome any additional checks people want to do. I also published primality proofs (via primo) of the groups here: https://dkg.fifthhorseman.net/ffdhe-primality-proofs/ > That's a weird thing about 7919, throughout the draft process lots of people > pointed out, again and again, that it wasn't going to work if published in > that form. So it got published anyway... i agree that it would have been functionally stronger to define ciphersuite values that identify the use of named FFDHE groups. This would allow clients to signal to servers that they will *only* accept DHE if the server uses the named groups, and would avoid getting DHE handshakes from non-compliant servers. However, the mechanism is still useful as-is for clients that want to signal their preference for a known group to a cooperating server. This is still useful in a world where some clients were failing to accept server-offered DHE shares > 1024-bits (sigh, Java). IIRC, the sense at the time was also that codepoints were scarce resources, and replicating all the _DHE_RSA_ ciphersuites alone would consume another 25 codepoints (replicating all of the _DHE_ ciphersuites would consume 70 additional ones), and then it would also require haggling over how the handshake messages would differ from the standard in those variants, which might then increase implementation complexity. Too bad! At any rate, it turned out to be useful preparation for TLS 1.3, though i presume today the named DHE groups will really only come in handy in case ECDHE turns out to have some kind of serious cryptanalytic setback. --dkg, the guilty party
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
