Subject: Re: [TLS] Another IRINA bug in TLS

From: Peter Gutmann <[email-masked]>
Date: Fri, 22 May 2015 14:54:53 +0000

Santiago Zanella-Beguelin <[email-masked]> writes:

>Regarding validation of DHE parameters and how reasonable it is in practice,
>I wanted to make some publicity for miTLS (http://www.mitls.org/).
>
>A miTLS client maintains a table of known trusted parameters, including the
>subgroup order for parameters with non-safe primes. When receiving unknown
>parameters from a server, it tests the primality of p and (p-1)/2 to check if
>p is a safe prime (and caches a positive result in the table). 

So you do a full primality test (Miller-Rabin or whatever) for each connect?
Doesn't that make it awfully slow?

>If the modulus is prime but not safe, miTLS checks if it is in the table of
>trusted parameters and otherwise rejects it. We distribute miTLS with a pre-
>populated table of parameters which we tested thoroughly (and we welcome
>people to test further). Most of the time we hit an entry in the table.

What testing do you do on unsafe primes?

Peter.

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 22 May 2015 13:05:31 -0400

> Doesn't that make it awfully slow?

The software under my purview does.

I don't allow the developers to use any parameters without validation.
That includes crypto parameters. But its for a systems that handles
medium and high value data; and not low value data where web browsers
and their use of TLS would be appropriate.

I don't think browsers will ever be able to handle anything other than
low value data, so I probably won't have to worry about web browsers
and what do (or don't) validate before use.

> What testing do you do on unsafe primes?

GnuTLS with its Lim-Lee primes causes me a lot of problems because
they cannot be validated.

If we encounter them, then developers are *not* allowed to apply a
secret to them. The user has to generate a new, verifiable key and
then add that key to their keyring.

Jeff

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Fri, 22 May 2015 17:52:29 +0000

>So you do a full primality test (Miller-Rabin or whatever) for each connect?

No. We do primality tests only if the prime isn't in the cache. That happens the
first time the client connects to a server, or when the server refreshes its
parameters. That, assuming the parameters aren't already in the pre-populated
cache.

>Doesn't that make it awfully slow?

No. The typical cost of validation is just one table lookup. This works
extremely well when people use just a few thousand parameters and don't change
them often. Even if that changes in light of Logjam (I hope it does!), online
primality tests for every connection are not prohibitive. I did a quick test
using Sage and the stock is_pseudoprime: testing if a 2048-bit prime is safe
takes ~180ms in a laptop, while computing two DH operations (exponentiations)
takes ~17ms. The amortized cost using a cache is of course much lower.

> What testing do you do on unsafe primes?

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.
Unsafe primes have other problems too, e.g. NFS pre-computation is a bit easier
than for safe primes.

--Santiago

________________________________________
From: TLS <[email-masked]> on behalf of Peter Gutmann <[email-masked]>
Sent: Friday, May 22, 2015 3:54 PM
To: <[email-masked]>
Subject: Re: [TLS] Another IRINA bug in TLS

Peter.

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 22 May 2015 16:55:29 -0400

[ i fixed typo in the Subject line because it bothered me; sorry if that
  kills threading in anyone's MUA ]

> takes ~17ms. The amortized cost using a cache is of course much lower.

I'm considering adding a Miller-Rabin primality check for the group
modulus to negotiated-ff-dhe's "Local Policy for Custom Groups" section:

 https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09#section-3.1

I'm also considering adding a suggestion for checking that the modulus
is a safe prime, if it is not already known to the client to be an
acceptable modulus.  What do others think about either of these
additions?

----

I see how the idea of every server choosing their own groups makes sense
From a crypto theory point of view, and if everyone does it right, it
would indeed probably be the best situation.

I have concerns about it from a practical perspective, though.

A client encountering a novel group now has to make a choice about
whether to perform some tests on the group (as suggested above) or to
proceed without testing (hoping that the server picked the right
parameters).  Since TLS clients are in tension between the demands of
efficiency (make connections faster and cheaper for your user) and
security (ensure the integrity and confidentiality of your user's
communications), many will be tempted to skip the extra checks, since if
the remote servers are well-configured, the check should be unnecessary.

Furthermore, generating a large safe prime group is expensive and slow,
which puts it out of reach of many devices that act as TLS servers,
which practically might mean we're delegating the job of prime selection
to implementors or software distributors.

As a case in point, the SSH protocol provides custom moduli, but i
believe most SSH servers ship with a set of default moduli (e.g. the
OpenSSH project ships a default set of moduli), and everyone just uses
those.  In the OpenSSH case, the upstream moduli appear to be generated,
tested and found to be safe primes on the basis of 100 rounds of
Miller-Rabin (see moduli(5) and /etc/ssh/moduli on a debian system, for
example), instead of generating proofs of primality (which are
significantly more expensive).

Yesterday, OpenSSH updated the set of moduli they'll be distributing for
the first time in 3 years [0] (this is better than the oakley groups,
which haven't been updated!).  The new ones were also tested on the
basis of 100 rounds of Miller-Rabin.  There is also discussion on the
openssh-unix-dev mailing list that different distributions might
consider shipping different sets of moduli, though this could
potentially introduce a distro-fingerprinting attack in places where
such an attack might not already exist.

We need protocol designs that simplify things for implementators and
deployers, and that remove the need for expensive security checks that
might be skipped for efficiency reasons. sufficiently large known-groups
seem to solve that problem, as long as we deprecate smaller groups
promptly.  I'm not sure that encouraging custom groups does, even though
it sounds like it would be the safer option when everyone is playing by
the best practice guidelines.

      --dkg

[0] https://anongit.mindrot.org/openssh.git/commit/?id=8b02481143d75e91c49d1bfae0876ac1fbf9511a

---

From: Andrei Popov <[email-masked]>
Date: Fri, 22 May 2015 21:09:26 +0000

I agree that sufficiently large known groups make precomputation infeasible, and also simplify both client and server implementation.

So the immediate mitigation could be for clients to stop accepting small DH groups, and for servers to send larger DH groups (this will of course create interop issues, esp. initially).

In the long term, it may become possible to only allow DHE cipher suites when a known group has been negotiated using draft-ietf-tls-negotiated-ff-dhe.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Friday, May 22, 2015 1:55 PM
To: [email-masked]
Subject: Re: [TLS] Another INRIA bug in TLS

On Fri 2015-05-22 13:52:29 -0400, Santiago Zanella-Beguelin wrote:
>>>A miTLS client maintains a table of known trusted parameters, 
>>>including the subgroup order for parameters with non-safe primes. 
>>>When receiving unknown parameters from a server, it tests the 
>>>primality of p and (p-1)/2 to check if p is a safe prime (and caches a positive result in the table).
>> 
> No. We do primality tests only if the prime isn't in the cache. That 
> happens the first time the client connects to a server, or when the 
> server refreshes its parameters. That, assuming the parameters aren't 
> already in the pre-populated cache.
>
> No. The typical cost of validation is just one table lookup. This 
> works extremely well when people use just a few thousand parameters 
> and don't change them often. Even if that changes in light of Logjam 
> (I hope it does!), online primality tests for every connection are not 
> prohibitive. I did a quick test using Sage and the stock 
> is_pseudoprime: testing if a 2048-bit prime is safe takes ~180ms in a 
> laptop, while computing two DH operations (exponentiations) takes ~17ms. The amortized cost using a cache is of course much lower.

I'm considering adding a Miller-Rabin primality check for the group modulus to negotiated-ff-dhe's "Local Policy for Custom Groups" section:

I'm also considering adding a suggestion for checking that the modulus is a safe prime, if it is not already known to the client to be an acceptable modulus.  What do others think about either of these additions?

----

I see how the idea of every server choosing their own groups makes sense From a crypto theory point of view, and if everyone does it right, it would indeed probably be the best situation.

A client encountering a novel group now has to make a choice about whether to perform some tests on the group (as suggested above) or to proceed without testing (hoping that the server picked the right parameters).  Since TLS clients are in tension between the demands of efficiency (make connections faster and cheaper for your user) and security (ensure the integrity and confidentiality of your user's communications), many will be tempted to skip the extra checks, since if the remote servers are well-configured, the check should be unnecessary.

Furthermore, generating a large safe prime group is expensive and slow, which puts it out of reach of many devices that act as TLS servers, which practically might mean we're delegating the job of prime selection to implementors or software distributors.

As a case in point, the SSH protocol provides custom moduli, but i believe most SSH servers ship with a set of default moduli (e.g. the OpenSSH project ships a default set of moduli), and everyone just uses those.  In the OpenSSH case, the upstream moduli appear to be generated, tested and found to be safe primes on the basis of 100 rounds of Miller-Rabin (see moduli(5) and /etc/ssh/moduli on a debian system, for example), instead of generating proofs of primality (which are significantly more expensive).

Yesterday, OpenSSH updated the set of moduli they'll be distributing for the first time in 3 years [0] (this is better than the oakley groups, which haven't been updated!).  The new ones were also tested on the basis of 100 rounds of Miller-Rabin.  There is also discussion on the openssh-unix-dev mailing list that different distributions might consider shipping different sets of moduli, though this could potentially introduce a distro-fingerprinting attack in places where such an attack might not already exist.

We need protocol designs that simplify things for implementators and deployers, and that remove the need for expensive security checks that might be skipped for efficiency reasons. sufficiently large known-groups seem to solve that problem, as long as we deprecate smaller groups promptly.  I'm not sure that encouraging custom groups does, even though it sounds like it would be the safer option when everyone is playing by the best practice guidelines.

      --dkg

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 May 2015 14:10:39 -0700

> modulus to negotiated-ff-dhe's "Local Policy for Custom Groups" section:

Please don't.  I like the statement you have already:

   Compatible clients that are willing to accept FFDHE ciphersuites from
   non-compatible servers may have local policy about what custom FFDHE
   groups they are willing to accept.  This local policy presents a risk
   to clients, who may accept weakly-protected communications from
   misconfigured servers.

More words aren't going to change that.  In fact, I can see only harm
in going further.  I would even go so far as to remove the two
paragraphs that follow this.  SHOULD >= 1024 isn't really advice that
I'm comfortable with.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 May 2015 14:12:59 -0700

> In the long term, it may become possible to only allow DHE cipher suites when a known group has been negotiated using draft-ietf-tls-negotiated-ff-dhe.

That time might have come sooner, if it weren't for the
misapprehension people have been given regarding custom groups off the
logjam mitigation advice.  I think that Karthik's clarification [1] is
much clearer than the message that has been propagated.

[1] http://www.ietf.org/mail-archive/web/tls/current/msg16496.html

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 22 May 2015 18:37:54 -0400

>  https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09#section-3.1
M-R is one check, but there are others. For example, trial division
and the choice of g in a group (g may not necessarily be a generator).

As a practical example from a guy who regularly validates all
parameters, see
http://crypto.stackexchange.com/questions/17707/trial-divisions-before-miller-rabin-checks
and http://crypto.stackexchange.com/questions/12961/diffie-hellman-parameter-check-when-g-2-must-p-mod-24-11.

What I found in the past that the IETF's choice of g = 2 meant that
various DH_param_check(...) would fail.

Jeff

---

From: Tanja Lange <[email-masked]>
Date: Sat, 23 May 2015 00:52:51 +0200

> and the choice of g in a group (g may not necessarily be a generator).
You want g to generate a large prime-order subgroup. 

> various DH_param_check(...) would fail.
The choice of g=2 is appropriate for the Oakley primes because 2 generates
the group of squares, which is exactly the group of size (p-1)/2.

Unfortunately some programs decide to check whether g generates the
entire group of size p-1, i.e. is a primitive element. I say 
'unfortunately' because if this is taken together with the recommendation
of using relatively short intervals for the secret key (p-1)/2
being composite you're likely to get a powerful break using
Pohlig-Hellman.

All the best
	Tanja

---

From: Tanja Lange <[email-masked]>
Date: Sat, 23 May 2015 00:55:00 +0200

Hi,
> Unsafe primes have other problems too, e.g. NFS pre-computation is a bit easier
What algorithm do you refer to here when you say that the NFS
precomputation gets easier. The only thing I know is that you
can solve the matrix modulo the group oder (or using fewer 
moduli when using CRT), but that's a very small speedup.

	Tanja

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 22 May 2015 16:27:38 -0700

> In the long term, it may become possible to only allow DHE cipher suites when a known group has been negotiated using draft-ietf-tls-negotiated-ff-dhe.

( Correct me if I am wrong, but I thought that IE only offered DHE with 
DSS until the last year, when a security update added DHE support with 
RSA. Last time I checked the IE's ClientHello this year, there were no 
DHE+RSA in IE 11, supposedly without that security update. )

What I wonder here about is the support for DHE 2048 by the (legacy) 
clients on the Internet. If the server will start sending DHE 2048 in 
the ServerKeyExchange, the DHE handshakes with older clients will fail, 
with a fallback to even less secure ciphersuites. The only way I see 
these old clients not failing is when these clients don't offer DHE in 
the ClientHello, but then there is no clear benefit to upgrade the 
server to send DHE 2048.

If ECDHE P-256 cannot be used, and absent any DHE size 
negotiation/signaling mechanism, fixing TLS clients not to accept short 
groups with non-export ciphersuites, which enabled the TS-specific 
attack, and perhaps switching to periodically regenerated DHE 1024 
groups looks like the safest plan.

To rephrase, what's the slice of the Internet that cannot do DHE P-256 
but can do DHE 2048?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 May 2015 16:45:11 -0700

On 22 May 2015 at 16:27, Andrey Jivsov <[email-masked]> wrote:
> To rephrase, what's the slice of the Internet that cannot do DHE P-256 but
> can do DHE 2048?

I can only answer for the slice that I see, which is mostly server
behavior.  Are you asking about clients?

>From the client end, we see 4-5% of connections on DHE[1].  Most of
those servers choose 1024-bit groups [2].

[1] Values in the 20s:
http://telemetry.mozilla.org/#filter=release%2F37%2FSSL_CIPHER_SUITE_FULL%2Fsaved_session%2FFirefox&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph
[2] Guess what means what here:
http://telemetry.mozilla.org/#filter=release%2F37%2FSSL_KEA_DHE_KEY_SIZE_FULL%2Fsaved_session%2FFirefox&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Fri, 22 May 2015 23:47:09 +0000

Hi Tanja,

> moduli when using CRT), but that's a very small speedup.

That's the only speedup I'm aware of, and it's indeed a small one.
(Table 2 in https://weakdh.org/imperfect-forward-secrecy.pdf has 
some estimates.)

--Santiago

________________________________________
From: Tanja Lange <[email-masked]>
Sent: Friday, May 22, 2015 11:55 PM
To: Santiago Zanella-Beguelin
Cc: Peter Gutmann; <[email-masked]>
Subject: Re: [TLS] Another IRINA bug in TLS

Hi,

        Tanja

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sat, 23 May 2015 08:21:56 +0200

> much clearer than the message that has been propagated.

Apologies if the paper led to any confusion on this, we were summarising lessons for
all DH-based protocols, not just TLS.

Yes, we *DO* support wide deployment of the FF-DHE draft, because
(a) 2048-bit groups are believed to be currently out of reach of the NFS-based technique considered in our paper,
(b) generating safe primes based on a public value like “e” is believed to avoid trapdoors (with high probability).

The “avoid fixed groups” recommendation applies to 1024 bits (and any other group-size for which
precomputation becomes feasible.)

Having said that, it would be good to set up a rigorous mechanism for “retiring” DH groups and EC curves
as their expiry date gets closer. DHE_EXPORT has survived 15 years after deprecation. Cryptographers
have recommended against using 1024-bit DH groups for a few years now. We’re going to hit the same
problem with curves at some point.

One option is to periodically obsolete drafts like FF-DHE, but would that just make a mess for implementations?

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 23 May 2015 13:29:55 +0100

Hiya,

On 23/05/15 07:21, Karthikeyan Bhargavan wrote:
> The “avoid fixed groups” recommendation applies to 1024 bits (and any
> other group-size for which precomputation becomes feasible.)

It's a really good paper, but if you have the chance I
think adding the above clarification would be very good.

Cheers,
S.

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Sat, 23 May 2015 13:12:53 +0000

Hi Stephen,

> think adding the above clarification would be very good.

Thanks! 
We're working on that.

________________________________________
From: TLS <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Saturday, May 23, 2015 1:29 PM
To: Karthikeyan Bhargavan; Martin Thomson
Cc: [email-masked]
Subject: Re: [TLS] Another INRIA bug in TLS

Hiya,

Cheers,
S.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 23 May 2015 20:36:49 -0400

> The software under my purview does.

And that software would be? Of course, once software is designed and
written it doesn't cost more to use. The whole rationale of protecting
some information less than others ignores the zero marginal cost of
software.

> and their use of TLS would be appropriate.

But that use is what TLS was originally designed for. We have to be
very clear on this point: TLS lacks properties other protocols, like
SSH have, that would defend against these attacks. Some of these
attacks are made worse by implementation complexity and bugs, assisted
by the use of informal descriptions of protocols instead of formal
methods.
> and what do (or don't) validate before use.

Web browsers handle bank account information, tax returns, user
accounts, etc for billions of people. Hard to think of a more
high-importance target.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 23 May 2015 21:35:28 -0400

On Sat, May 23, 2015 at 8:36 PM, Watson Ladd <[email-masked]> wrote:
>> ...

Ah, this is a very good point. I just call it "drinking the koolaide".

SSL was originally designed for ecommerce transactions. In ecommerce,
risk is offloaded onto merchants and share holders. When something
goes wrong, its the merchants and share holders who pay.

After inception, SSL/TLS was repurposed for additional uses, but the
risk model was not the same. For example, someone in Iran may use
SSL/TLS to access their Gmail account, and that account may have email
threads with views that are not popular with the current regime. But
the risk was not offloaded, and lots of people were likely tortured
and killed because of Diginotar.

>From my time in US Financial, we were well aware of the problems with
browser based web applications and underlying technologies like PKIX.
We would regularly decline browser based applications for use in the
firm. The application would then be sent into risk acceptance *if* a
director or VP really wanted to use it.

If the system handled low value data, like online banking, then the
firm would accept the risk because they did not want to lose
customers. That is, they chose to accept the risk. If it was high
value data, like pending litigation, mergers and acquisitions,
executive compensation, then the risk committee would not overrule us.
That is, they would not accept the risk.

By the way, the "... did not want to lose customers" is one of the
reasons we lack 2FA in so many US banks. They don't want to make it
inconvenient on their existing customers. And its one of the reason US
Financial suffers loses at 25x to 600x than their European
counterparts.

Jeff

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 24 May 2015 07:12:00 +0000

Jeffrey Walton <[email-masked]> writes:

>GnuTLS with its Lim-Lee primes causes me a lot of problems because they
>cannot be validated.

Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as well!), it's
the fact that TLS uses the PKCS #3 format rather than the DSA format, so
you've got nice verifiable values for which you have to throw away the
parameter used to verify them and send them in an unverifiable format.  Having
said that, there's a pretty simple fix, define an extension that acts like the
existing propose/accept extensions that signals a change in DH values to the
DSA form (p, q, g) rather than PKCS #3 form (p, g).  And for TLS 1.3, use the
DSA form by default, not the PKCS #3 form.

Peter.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sun, 24 May 2015 09:23:52 +0200

The confusion between DSA and PKCS#3 has other unexpected consequences.
As we describe in 3.5 of our Imperfect Forward Secrecy paper, some server
implementations take a DSA group (p,q,g) and, when fitting it to TLS, confuse
the “q” with the generator “g”. This bug leads to a rather nasty attack.

(Yeah, you’d probably want to add this to the WTF category.)

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 24 May 2015 09:55:24 +0000

Karthikeyan Bhargavan <[email-masked]> writes:

>The confusion between DSA and PKCS#3 has other unexpected consequences. As we
>describe in 3.5 of our Imperfect Forward Secrecy paper, some server

It's a WTF, but it's the IETF's, not the implementers':

/* [...]

   For peculiar historical reasons (copying errors and the use of obsolete
   drafts as reference material) the X9.42 interpretation used in PKIX 
   reverses the second two parameters from FIPS 186 (so it uses p, g, q 
   instead of p, q, g), so when we read/write the parameter information we 
   have to switch the order in which we read the values if the algorithm 
   isn't DSA */

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 24 May 2015 08:19:13 -0400

> and killed because of Diginotar.

Are we talking about phishing? No, we're not.

Are we talking about CA compromise? No, we're not.

The bugs we are discussing involve core security claims: that knowing
the private key associated to one end of a TLS connection is required
to know what data is sent. It's a problem that every single use of
cryptography faces. And it's trivially solvable: SSH has far fewer of
these problems. (It has other problems: check what your hostkeys are
people! If you generated them two decades ago, time to rotate)

So what exactly are you proposing as the solution, if you want to
protect all data? Or is this working group just not worth it: we would
need the Very Serious Security Protocol for you to actually think that
it's worth fixing this problems and sharing your infinite wisdom? I'm
well aware of how TLS got designed: SSH v1 also had tons of problems,
but SSH v2 fixed them all. IKEv1 had problems, IKEv2 fixed them all.
That's the point of having these new versions.

Of course, once you actually have the VSSP, you can just use it for
*all* your data, and replace TLS, SSH, etc. with it. Maybe instead of
quietly fixing holes, you should let all of us know about them, and we
should fix them.

Sincerely,
Watson Ladd

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 24 May 2015 12:37:06 +0000

>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.

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Sun, 24 May 2015 12:59:14 +0000

> vs. g=anything else?  

Sorry, we don't have that sort of telemetry.

> I've seen a lot of g=2, then some g <= 8 bits, and a
> mentioned elsewhere 

For DSA parameters, sizeof(g) == sizeof(p) is what's expected. Rather,
sizeof(g) == sizeof(q) would be very suspicious.

> (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?).  

Are you talking about OpenSSL? I don't know what it checks.

> However because I typically don't have direct contact with, or control over, end

Then I'm afraid I cannot help you. What matters to me the most is
security, not being able to interoperate with servers using buggy
parameters or insecure implementations of TLS.

---

From: Andrey Jivsov <[email-masked]>
Date: Sun, 24 May 2015 10:21:47 -0700

> sizeof(g) == sizeof(q) would be very suspicious.

sizeof(g) ~= sizeof(p) would be expected if one to follow the DSA spec. There are two methods specified, including deterministic/verifiable generation, both resulting in this outcome.

See http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf, sec A.2.1, A.2.3

Interestingly, the g validity check in sec A.2.2 may allow small g (except in the case of a verifiable g).

You probably didn't mean strict size checking, but let me note it anyway. Strict checking sizeof( g ) == sizeof( p ) for DSA will result in hard-to-reproduce interoperability failures, which are bugs. Given how the FIPS 186-4 is specified, it's unreasonable to demand ==.