[cabfpub] Proposal to add DSA 2048

Ryan Hurst ryan.hurst at globalsign.com
Fri Mar 8 13:53:20 MST 2013


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
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> 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 <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] 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: https://cabforum.org/pipermail/public/attachments/20130308/2798b9e7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2098 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130308/2798b9e7/attachment-0001.bin 


More information about the Public mailing list