Subject: Re: [TLS] DH parameters, primality

From: Peter Gutmann <[email-masked]>
Date: Fri, 7 Mar 2014 10:54:04 +0000

Hanno =?UTF-8?B?QsO2Y2s=?= <[email-masked]> writes:

>Probably not many people have tested these things in the past. Using
>obviously wrong parameters could uncover other bugs. Some browsers (and other
>tls clients) accept all kinds of bogus parameters for DH. No browser checks
>for primality.

You didn't try my code, did you? :-).  OK, it's not a browser, but there are
implementations out there that won't just accept any old rubbish.

(I recently found out about a TLS implementation that erroneously sent DH
primes with p = 0 to the other side and other implementations could connect to
it, I'm still waiting to hear back on what the implementations were).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 7 Mar 2014 12:20:45 +0000

Karthikeyan Bhargavan <[email-masked]> writes:

>It’s worth rethinking TLS's DH representation for another reason. It does not
>currently provide a slot for the subgroup size “q”.

Yup, that's what I meant with going to the FIPS 186 representation.  One off-
the-top-of-my-head way to do this would be via an extension in the handshake
saying "use FIPS-186 form instead of PKCS #3 form for DH values".

(We really need some sort of bitflag-style extension to indicate all of the
things that are currently being done via individual TLS extensions, since
there seem to be quite a few I-can-do-better-than-the-default style indicators
needed for various things).

Peter.