Subject: Re: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage)

From: Santosh Chokhani <[email-masked]>
Date: Sat, 12 Oct 2013 01:15:57 +0000

DS bit for RSA based TLS server is not appropriate since the Server key is used by the client to encrypt and never used for digital signature verification.

I thought we set the DS bit in case the server acts as a client.

As to the EC, that should depend on the cipher suite used.  It could be ECDH or ECDSA certificate and that should translate to key agreement or DS bit respectively.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Smith
Sent: Friday, October 11, 2013 8:51 PM
To: Peter Gutmann
Cc: <[email-masked]>
Subject: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage)

On Thu, Oct 3, 2013 at 5:23 AM, Peter Gutmann <[email-masked]> wrote:
> My code, in its default configuration, strictly enforces keyUsage.  
> From this I've found that both applications and CAs can set these bits 
> more or less at random, including completely illogical settings like 
> keyAgreement for RSA keys.  I've also found, through trial-and-error, 
> that many applications completely ignore them and use the keys in 
> whatever way they feel appropriate (the situation for PKCS #12 files 
> in particular is so bad that after fighting it for awhile I had to 
> turn off checking of keyUsage entirely).  So this isn't a case of 
> copying an RSA template, it's broken software generating them and equally broken software ignoring them.

Software based on NSS's libssl has a pretty liberal interpretation of keyUsage, and this is something I'd like to correct in Firefox soon.
In particular, I want to encourage CAs to offer ECDSA SSL certificates only with the digitalSignature bit set, and to provide the option to their customers to request RSA certificates with only the digitalSignature bit set. This should provide defense-in-depth from server misconfiguration for websites that want to switch exclusively to ephemeral key exchange.

If you have any more specific information you could share regarding your experience with attempting strict(er) KU enforcement, it would be great if you could share it. (Not just Peter, but everybdoy.)

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM) _______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 12 Oct 2013 05:22:19 +0200

On 12/10/2013 03:15, Santosh Chokhani wrote:
> DS bit for RSA based TLS server is not appropriate since the Server key is
> used by the client to encrypt and never used for digital signature
> verification.
> 
Your seem to have RSA key exchange in mind, while Brian was talking about
ECDHE_RSA or DHE_RSA key exchanges, where the server's RSA key is used to sign
the parameters in the ServerKeyExchange message. The point was precisely that,
if the keyUsage bits were respected, then setting only DS would force to use
only forward secret key exchanges with this certificate.

Manuel.

---

From: [email-masked] (Martin Rex)
Date: Sat, 12 Oct 2013 06:50:01 +0200 (CEST)

Manuel Pégourié-Gonnard wrote:
> Santosh Chokhani wrote:

It might result in more TLS implementations to work around the interop
problem and disable keyUsage checks like Peter did.

Really, the best that could happen to the NSA is that everyone starts
using ECDHE with Nist curves, aka Suite B.  It just would not make sense
(and amount to a huge waste of tax dollars) if these were _not_ bugged!

The defects in (EC)DSA look rather accidental to me, and EC_Dual_DRNG was
deliberatly set up to deceive folks on what was _really_ subverted.
Considering how it is being used, ECDHE as part of Suite B is the
single point of failure that is by far the most convenient, because
it will work for large-scale passive eavesdropping.

The original "digitally-signed" in SSLv3 and TLSv1.0 for RSA was using
a conservative design, since it combined two hash algorithms (SHA1+MD5).
In TLSv1.2 this was artificially neutered -- (rsa,md5) is a valid signature
algorithm according to the TLSv1.2 spec, but ridiculously weak.

If we were to "fix" TLS, then we should use combinations of algorithms
more often, rather than less.  Such as making it possible to use
an RSA premaster secret XORed with a DHE or ECDHE shared secret.

-Martin

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 12 Oct 2013 12:15:08 +0300

Hi Martin,

I like conspiracy theories as much as the next one, but the truth is, we 
simply don't know if NIST P-256 and friends are bugged. OTOH we do know 
that DHE-1024 is too weak.

Luckily, TLS negotiates ECDHE curves. So on the server side you can 
prefer Brainpool and fall back to P-256. Or you can allow *only* 
Brainpool (or DJB's latest, or whatever) and switch to DHE or to plain 
RSA if the client doesn't have your favorite curve. The point is, ECDHE 
was engineered correctly with built-in crypto agility, so if we move to 
it we have a way forward.

Thanks,
	Yaron

On 10/12/2013 07:50 AM, Martin Rex wrote:
[...]
> it will work for large-scale passive eavesdropping.
[...]