[cabfpub] Proposal to add DSA 2048

Fri Mar 8 22:35:44 UTC 2013

Sorry, “no objections”.  It’s been a long week.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Friday, March 08, 2013 2:33 PM
To: CABFPub
Subject: Re: [cabfpub] Proposal to add DSA 2048

Great, thanks.  Trend Micro has objections to including.

From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
Sent: Friday, March 08, 2013 1:39 PM
To: Ryan Hurst; Erwann ABALEA
Cc: Kirk Hall (RD-US); CABFPub
Subject: RE: [cabfpub] Proposal to add DSA 2048

To address everyone’s questions:

-          FIPS 186 originally allowed for DSA 1024 bits max, but in the 186-3 revision 2048 and SHA-2 were added.

-          ECDSA is allowed in the BRs; Appendix A allows P-256, P-384, or P-521 curves

-          Does it present any issues that are different from RSA algorithm certs? AFAIK, just what Erwann listed below (it can be used for signature only, not encryption/decryption). I haven’t heard of any particular vulnerabilities. In fact, the “Ron was wrong, Whit is right” paper (http://eprint.iacr.org/2012/064.pdf) suggests that there are advantages to cryptosystems like DSA that require only a single secret during key setup.

-          Same authentication processes and security considerations? I don’t see why not.

-          Can only government agencies obtain these certs, or can any user? Anyone can. We expect more interest from government customers given its inclusion in FIPS 186-3, but there are no restrictions
-Rick
From: Ryan Hurst [mailto:ryan.hurst at globalsign.com]
Sent: Friday, March 08, 2013 12:53 PM
To: Erwann ABALEA
Cc: kirk_hall at trendmicro.com; Rick Andrews; CABFPub
Subject: Re: [cabfpub] Proposal to add DSA 2048

I agree, I don't know why one would use it given the realities that exist but I don't see an issue with its use.

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: ryan.hurst at globalsign.com<mailto:ryan.hurst at globalsign.com>
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

On Mar 8, 2013, at 12:48 PM, Erwann ABALEA <erwann.abalea at keynectis.com<mailto:erwann.abalea at keynectis.com>> wrote:
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<mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com<mailto: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> [mailto: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> [mailto: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<mailto:ryan.hurst at globalsign.com>]
Sent: Thursday, March 07, 2013 7:25 PM
To: 'Rick Andrews'; 'CABFPub (public at cabforum.org<mailto: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> [mailto:public-bounces at cabforum.org] On Behalf Of Rick Andrews
Sent: Thursday, March 07, 2013 4:23 PM
To: CABFPub (public at cabforum.org<mailto: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<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

--
Erwann.

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.

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
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.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130308/706a50ce/attachment-0003.html>