[cabfpub] Proposal to add DSA 2048

Erwann ABALEA erwann.abalea at keynectis.com
Fri Mar 8 20:48:03 UTC 2013


Anybody can generate a DSA key and use it, there's no restriction.

It's different from RSA in several ways:
 - can be used for signature only (to sign a DH key which will be used to
agree on a key for encipherment)
 - you separate domain parameters generation and key generation; domain
parameters set the security level of the keys and can be shared between any
number of unrelated users, DSA key generation is way faster than RSA
 - signing/verifying cost ratio is reversed (faster signatures than
verifications); this could have been an advantage against basic TLS DoS
tools such as THC-SSL-DOS, or not (it depends on the negotiated ciphersuite)
 - signing is extremely fault intolerant; a secret random is generated for
each signature, if a random is reused the private key can be recovered; if
this random can be predicted (even a few bits) part of the private key can
be recovered; if the random is revealed the private key can be recovered;
this intolerance is shared with ECDSA
 - limitations to 1024 bits come from DSS (the FIPS186 standard), which
specifies acceptable parameters for DSA, and the first edition allowed for
1024 bits max with SHA1 hash, which has a security level equivalent to a
1024 bits RSA (80 bits of security)

I don't see any value added in using DSA2048/3072. It's not as fast as pure
RSA for a full TLS handshake if you're concerned with performance, and if
you want to keep forward-secrecy, RSA+(EC)DHE works today with probably
similar performance. It's also not compatible with RC4-* ciphersuites,
which shouldn't be a problem in an ideal world where BEAST doesn't apply.

I don't have any problem allowing its use, either.

Haven't check the BR in the past few days, is ECDSA allowed?

2013/3/8 kirk_hall at trendmicro.com <kirk_hall at trendmicro.com>

>  Rick, I don’t know much about DSA (other than it’s a different
> algorithm).  ****
>
> ** **
>
> http://en.wikipedia.org/wiki/Digital_Signature_Algorithm****
>
> ** **
>
> Does it present any issues that are different from RSA algorithm certs?***
> *
>
> ** **
>
> Same authentication processes and security considerations?****
>
> ** **
>
> Can only government agencies obtain these certs, or can any user?****
>
> ** **
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Rick Andrews
> *Sent:* Friday, March 08, 2013 11:40 AM
> *To:* Ryan Hurst; 'CABFPub'; Erwann Abalea
> *Subject:* Re: [cabfpub] Proposal to add DSA 2048****
>
> ** **
>
> We’re working with Stanford and CMU to do performance testing, but it will
> be a few weeks before we have results.****
>
> ** **
>
> Regardless of performance, does anyone have any problem with explicitly
> adding DSA 2048 to the BRs?****
>
> ** **
>
> -Rick****
>
> ** **
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Ryan Hurst
> *Sent:* Thursday, March 07, 2013 7:29 PM
> *To:* Rick Andrews; 'CABFPub'; Erwann Abalea
> *Subject:* Re: [cabfpub] Proposal to add DSA 2048****
>
> ** **
>
> I just remembered a post I did on this topic:
> http://unmitigatedrisk.com/?p=50****
>
> ** **
>
> I just reread it and ran across Erwann’s comment about the performance
> implications of DH and its use in SSL. This also makes me wonder if anyone
> has done performance benchmarking of DSA 2048 relative to RSA looking at
> the DH overhead and DSA costs as a whole – basically does it really provide
> you any value?****
>
> ** **
>
> Ryan****
>
> ** **
>
> *From:* Ryan Hurst [mailto:ryan.hurst at globalsign.com]
> *Sent:* Thursday, March 07, 2013 7:25 PM
> *To:* 'Rick Andrews'; 'CABFPub (public at cabforum.org)'
> *Subject:* RE: [cabfpub] Proposal to add DSA 2048****
>
> ** **
>
> The performance properties of DSA are great relative to RSA for servers
> but major clients (as far as I know) do not support DSA keys larger than
> 1024, I know this is the case for anything that relies on CryptoAPI in
> Windows. Out of curiosity are there major browsers that can work with such
> keys or are your scenarios limited to custom applications?****
>
> ** **
>
> Ryan****
>
> ** **
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org<public-bounces at cabforum.org>]
> *On Behalf Of *Rick Andrews
> *Sent:* Thursday, March 07, 2013 4:23 PM
> *To:* CABFPub (public at cabforum.org)
> *Subject:* [cabfpub] Proposal to add DSA 2048****
>
> ** **
>
> Symantec has begun offering SSL certificates with DSA 2048-bit keys. Since
> DSA is not mentioned in the Baseline Requirements or EV Guidelines, I’d
> like to explicitly add DSA 2048 in BR Appendix A as the minimum DSA key
> size.****
>
>  ****
>
> If there are no objections, I’ll draft a ballot and seek endorsers.****
>
>  ****
>
> -Rick ****
>
>  ****
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>


-- 
Erwann.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130308/5268a9c1/attachment-0003.html>


More information about the Public mailing list