Re: [TLS] Another IRINA bug in TLS

[Peter Gutmann <[e-mail]>]

Santiago Zanella-Beguelin <[e-mail]> writes:

>We accept them if they're in the pre-populated cache. If not, we reject them
>because we can't check the order of the generator and validate ephemeral keys.

Just out of interest and if you have any sort of figures, what sort of
rejection rate do you get, and what sort of distribution do you see for g=2
vs. g=anything else?  I've seen a lot of g=2, then some g <= 8 bits, and a
very few sizeof( g ) == sizeof( p ) which I suspect is the q vs. g confusion
mentioned elsewhere (looking at dh_check.c, I see that it comments out the
check for g=3, implying perhaps that it's not seen in the wild?).  However
because I typically don't have direct contact with, or control over, end
users, only developers building end-user products, in my case any check with a
FP rate greater than zero is going to cause headaches.  Even something as
simple as rejecting obviously bogus g values (which is what the broken PLC
I've mentioned previously does, among assorted other bugs) causes problems
because what matters is availability, not correct use of DH values (or correct
implementation of the TLS protocol).

Peter.