DSA certificates?

[Kathleen Wilson]

All,

Should NSS and mozilla::pkix support DSA certificates?

Should we add support for DSA to Mozilla's CA Certificate Policy?

Background:

* Currently there are no DSA roots in the NSS root store.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/

* Mozilla's policy currently does not claim support for DSA certificates.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
"8. We consider the following algorithms and key sizes to be acceptable
and supported in Mozilla products:
- SHA-1 (until a practical collision attack against SHA-1 certificates
is imminent);
- SHA-256, SHA-384, SHA-512;
- Elliptic Curve Digital Signature Algorithm (using ANSI X9.62) over
SECG and NIST named curves P-256, P-384, and P-512;
- RSA 2048 bits or higher; and
- RSA 1024 bits (only until December 31, 2013)."

* We have been asked to update Mozilla's policy to add DSA suppport.
https://wiki.mozilla.org/CA:CertPolicyUpdates#Consider_for_Version_2.3
- In item #8 of the Maintenance Section add DSA 2048.

* There are Bugzilla Bugs to remove DSA support.
https://bugzilla.mozilla.org/show_bug.cgi?id=1073867 (mozilla37)
"Remove support for DSS (non-ECC DSA) signatures from mozilla::pkix"
https://bugzilla.mozilla.org/show_bug.cgi?id=1107787 (mozilla37)
"Disable TLS_DHE_DSS_WITH_AES_128_CBC_SHA support"


I will appreciate your constructive feedback and opinions on these
questions.

Thanks,
Kathleen

[Ryan Sleevi]

Short answer: No, it shouldn't.

As part of the transition to BoringSSL, we've chosen to remove DSA
support. The number of well-formed DSA certificates out there was single
digits, so this is not likely to be a large Web Compat issue. DSA
certificates are complicated due to parameter inheritance through the
chain - which few get right, but which add ambiguity for path building and
processing. DSA certificates cannot be used for certificate pinning in
some cases because of this inherent ambiguity (
https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.4 )

The performance-vs-security of DSA certificates is questionable; it isn't
until you're using DSA2 that you begin to hit acceptable thresholds for
security, and those certificates are not at all widely used because those
are not widely implemented. DSA suffers from sudden death entropy failures
( https://www.imperialviolet.org/2013/06/15/suddendeathentropy.html ) that
can be quite fatal, and isn't justified by its benefits (compared with
ECDSA)

Adding support for DSA (as requested by at least one CA) would be a step
backwards for security. I'd like Mozilla to consider keeping the current
policy and prohibiting DSA, allowing only RSA and ECDSA roots.

[Richard Barnes]

To be clear: The current "policy" was established by the two bugs above
being landed, without discussion beyond the bugzilla thread. The point of
this thread is to verify that that policy is OK, given the potential compat
impact.

Not saying that I disagree with you, but wanted to be clear about where we
stand.

--Richard




>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Ryan Sleevi]

On Mon, December 22, 2014 1:09 pm, Richard Barnes wrote:
>
> To be clear: The current "policy" was established by the two bugs above
> being landed, without discussion beyond the bugzilla thread. The point of
> this thread is to verify that that policy is OK, given the potential
> compat
> impact.
>
> Not saying that I disagree with you, but wanted to be clear about where we
> stand.
>
> --Richard

Richard,

Sorry to be contrarian, but your description of the policy is not
accurate, as noted by Kathleen's original message.

That is, the current Mozilla CA Certificate Store does not allow DSA
roots. That part is unambiguously clear by virtue of omission, and by
virtue of the 2.3 proposal for addition.

It is a separate, and arguably orthogonal matter, as to what Firefox does
for both TLS ciphersuites and leaf certs, just as it has been historically
separate as to what NSS does for the actual library capabilities. For
example, NSS could move to end DSA support independent of the Mozilla CA
Certificate Store policy, because they're separately maintained. Or NSS
could add DSA2 support (as it has) independent of Mozilla Firefox using it
(e.g. the same as you could say for GOST) and independent of the Mozilla
CA Certificate Policy allowing DSA roots.

Kathleen posed three questions (worded as two)
1) Should NSS support DSA certificates
2) Should mozilla::pkix support DSA certificates
3) Should the Mozilla CA Certificate Policy support DSA certificates


I don't believe a positive answer for #1 has any bearing on how #2 or #3
should be answered. The NSS maintainers add a variety of things to NSS
that don't belong on the public Internet, but which is needed in
enterprise environments (such as those supported by Red Hat). I believe
DSA2 is one of those - it's use outside of the US federal government is
virtually non-existent, and it's use within is anachronistic more than
anything.

#2 was related to the two bugs you mentioned, and the answer chosen at the
time was no. Again, I don't think it's something we typically answer here
on moz.dev.sec.policy (compared to dev.platform / dev.tech.crypto), but as
noted, the use on the public Internet is virtually non-existent - and for
good reason.

#3 is directly applicable to this list, and the current policy prohibits
them. I think the current policy is eminently sensible, because there's no
good reason for people to deploy new systems (especially in light of #1/#2
as it relates to other products as well). The security risks vs strength
seem to run counter to the CA Certificate Policy's attempts to improve
security (e.g. deprecating SHA-1, phasing out RSA-1024).

[Peter Gutmann]

Ryan Sleevi <ryan-mozde...@sleevi.com> writes:

>DSA certificates are complicated due to parameter inheritance through the
>chain - which few get right, but which add ambiguity for path building and
>processing. DSA certificates cannot be used for certificate pinning in some
>cases because of this inherent ambiguity (
>https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.4 )

This is a bit of a red herring since nothing [0] actually uses this, at least
one reason being that it allows signature forgery if you do. So saying "we
don't do DSA because no-one cares about it" is OK, but saying "we don't do it
because of a feature that cryptographers threw in just because they could but
that no-one uses" isn't really accurate.

>DSA suffers from sudden death entropy failures (
>https://www.imperialviolet.org/2013/06/15/suddendeathentropy.html ) that can
>be quite fatal, and isn't justified by its benefits (compared with ECDSA)

Funny you should mention ECDSA there, since it suffers from the exact same
sudden-death entropy failure problem as DSA (they both have "DSA" in their
name for a reason).

So: stick with "we don't do DSA because no-one cares" as your reason :-).

Peter.

[0] About 15-20 years ago someone on the PKIX list asked for examples of
shared-param DSA certs for testing purposes. The sound of crickets was
deafening. I think someone eventually generated some specifically for
testing, and I may even still have them somewhere, but in general even
the standards group that specified the things couldn't produce any
examples of them being used.

[Ryan Sleevi]

On Mon, December 22, 2014 3:16 pm, Peter Gutmann wrote:
> Ryan Sleevi <ryan-mozde...@sleevi.com> writes:
>
> >DSA certificates are complicated due to parameter inheritance through the
> >chain - which few get right, but which add ambiguity for path building
> > and
> >processing. DSA certificates cannot be used for certificate pinning in
> > some
> >cases because of this inherent ambiguity (
> >https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.4
> > )
>
> This is a bit of a red herring since nothing [0] actually uses this, at
> least
> one reason being that it allows signature forgery if you do. So saying
> "we
> don't do DSA because no-one cares about it" is OK, but saying "we don't do
> it
> because of a feature that cryptographers threw in just because they could
> but
> that no-one uses" isn't really accurate.

Um, no?

The point is that it has - by design - a dangerous feature that doesn't
exist with other signature schemes. That this design exists and is
mandated is part of the complexity - either no one implements it (and for
sure, Microsoft's stack _does_ implement it, and NSS _tries_ implement
it), and which point, you don't have DSA but some DSA-prime - or it's
implemented (and it is) and presents a security risk.

>
> >DSA suffers from sudden death entropy failures (
> >https://www.imperialviolet.org/2013/06/15/suddendeathentropy.html ) that
> > can
> >be quite fatal, and isn't justified by its benefits (compared with ECDSA)
>
> Funny you should mention ECDSA there, since it suffers from the exact same
> sudden-death entropy failure problem as DSA (they both have "DSA" in their
> name for a reason).
>
> So: stick with "we don't do DSA because no-one cares" as your reason :-).

Perhaps it wasn't unambiguously clear in my message, but the post I linked
to specifically discusses this and I acknowledge as much in my message.
However, the benefit of ECDSA (smaller signatures, smaller keys for
equivalent security) offers a compelling reason, and RFC 6979 exists as a
mitigation.

The argument here is not "we don't do DSA because no-one cares", but "we
don't do DSA because the risks are high and there are no benefits relative
to those risks"

[Peter Gutmann]

Ryan Sleevi <ryan-mozde...@sleevi.com> writes:

>(and for sure, Microsoft's stack _does_ implement it,

Does anyone know the motivation for this? MS also implemented support for
X9.42 certificates, which no-one has ever seen in the wild, but it was in
receive-only mode (it would never generate data using them) and was done
solely in order to avoid any accusations that they weren't following standards
(there was this antitrust thing going on at the time). So having it present
in a MS implementation doesn't necessarily mean that it's used or supported,
merely that it's, well, present in a MS implementation.

(I'm just curious, wondering what the story behind this one is).

Peter.

[Phillip Hallam-Baker]

DSA was the mandatory to implement algorithm originally since that was out
of patent earlier than RSA.

I would like to kill as many unused crypto implementations as possible. The
algorithm might be sound but an implementation that has never been used in
practice is a huge liability.




On Tue, Dec 23, 2014 at 3:31 AM, Peter Gutmann <pgu...@cs.auckland.ac.nz>
wrote:

[rashmi...@symantec.com]

Symantec supports customer choice in algorithm selection and we have customers that take advantage of that choice today. Whether to support organizational policies that require the use of DSA or to provide an alternative to RSA in the event that any vulnerabilities in that algorithm are identified in the future, we recommend that Mozilla and other browsers support DSA.

Symantec currently has 3 DSA roots that we also request be included in the Mozilla root store.

[Ryan Sleevi]

Given that ECDSA exists with all of the downsides, but significantly more
benefits (and security) than DSA, and meets the criteria you set forth as
"provide an alternative to RSA", what reasons remain to support DSA?

"Supporting organizational policies that require the use of DSA" is one,
although I think the merits of that argument (vs the risk, complexity, and
maintenance costs) are exceptionally weak.

If DSA support is still needed in 5 years (the current maximum validity
period of BR-conforming certs), would we call that a good thing? I would
argue no.

[Kurt Roeckx]

On 2014-12-22 21:26, Ryan Sleevi wrote:
> As part of the transition to BoringSSL, we've chosen to remove DSA
> support. The number of well-formed DSA certificates out there was single
> digits, so this is not likely to be a large Web Compat issue

My charts (http://roeckx.be/certificates/dsa.png) shows for more than a
year now their hasn't been any EE DSA certificate used and that the
total number of valid certificates that were ever valid I know about is 11.

> The performance-vs-security of DSA certificates is questionable; it isn't
> until you're using DSA2 that you begin to hit acceptable thresholds for
> security, and those certificates are not at all widely used because those
> are not widely implemented. DSA suffers from sudden death entropy failures
> ( https://www.imperialviolet.org/2013/06/15/suddendeathentropy.html ) that
> can be quite fatal, and isn't justified by its benefits (compared with
> ECDSA)
>
> Adding support for DSA (as requested by at least one CA) would be a step
> backwards for security. I'd like Mozilla to consider keeping the current
> policy and prohibiting DSA, allowing only RSA and ECDSA roots.

I also see no good reason to support DSA.


Kurt

[Kathleen Wilson]

On 1/14/15 1:14 AM, Kurt Roeckx wrote:
> On 2014-12-22 21:26, Ryan Sleevi wrote:

>> <snip>

>> Adding support for DSA (as requested by at least one CA) would be a step
>> backwards for security. I'd like Mozilla to consider keeping the current
>> policy and prohibiting DSA, allowing only RSA and ECDSA roots.
>
> I also see no good reason to support DSA.
>

Thanks to all who have contributed to this discussion. And thanks to
Kurt for the data.

I see only one argument in favor of adding DSA support to Mozilla's CA
Certificate Policy -- to have an alternative to RSA. As was pointed out,
ECC is an acceptable (and more secure than DSA) alternative to RSA.

All of the other statements in this discussion were opposed to adding
DSA support to Mozilla's CA policy.

Therefore, I believe we have a clear answer: No, we should not add DSA
support to Mozilla's CA Certificate Policy, and mozilla::pkix does not
need to support DSA certificates.

Thanks,
Kathleen