Subject: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?

From: Bill Cox <[email-masked]>
Date: Wed, 30 Mar 2016 02:46:55 -0700

IIRC, TLS 1.3 will not offer big companies the ability to create
short-lived sub-certificates specific to remote satellite locations.  This
forces companies to choose between good physical security for their signing
certs, or having fast connection times.  Am I recalling correctly that TLS
1.3 has this problem?  I thought we fixed this in QUIC crypto.

Thanks,
Bill

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2016 08:22:15 -0700

This got a lot of discussion early in the design process and the consensus
was that the risk of having the default mode (with existing certs) allow the
creation of a long-term delegation was too high. See, for instance, the
relative impact of the recent paper by Jager at al. [0] on TLS 1.3 and
QUIC.

With that said, I think this would be a good feature to look at in future
and the right way to do it is to:

1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to
PKIX.
2. Add a subcert extension to TLS 1.3.

Best,
-Ekr

[0]  https://www.nds.rub.de/media/nds/.../2015/08/21/*Tls13Quic*Attacks.pdf

On Wed, Mar 30, 2016 at 2:46 AM, Bill Cox <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Bill Cox <[email-masked]>
Date: Wed, 30 Mar 2016 08:37:47 -0700

> 2. Add a subcert extension to TLS 1.3.

OK, awesome.  Is it too early to volunteer for this effort?  Do you know
who the right person is to contact?

Thanks again,
Bill

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2016 08:44:47 -0700

On Wed, Mar 30, 2016 at 8:37 AM, Bill Cox <[email-masked]> wrote:

> OK, awesome.  Is it too early to volunteer for this effort?
>

No!

>   Do you know who the right person is to contact?
>

Shoot me an email offline and I can walk you through what I think would be
required
to get this going.

-Ekr

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Mar 2016 12:02:45 -0400

> 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to

this would need to be a critical extension, since the goal is to have it
be unusable by existing endpoints, right?  do we have tests about how
well existing endpoints will fail closed in the face of unknown critical
extensions?

> 2. Add a subcert extension to TLS 1.3.

This would be necessary for clients to signal that it's ok to use such a
delegated cert or subcert.  we need to think clearly about how to limit
the scope of such a delegation to make it safe.

          --dkg

---

From: Dave Garrett <[email-masked]>
Date: Wed, 30 Mar 2016 16:23:52 -0400

> 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to

Adding a PKIX extension to mandate a minimum threshold of security configuration (e.g. PFS+AEAD w/o resumption or SHA1 or any support for TLS <1.2) would also be great to have. In fact, if an intermediate could also set such a requirement and have that be required for all end-entity certs signed by it, that'd be a great way to protect against downgrades.

Dave

---

From: Watson Ladd <[email-masked]>
Date: Wed, 30 Mar 2016 13:33:41 -0700

> well existing endpoints will fail closed in the face of unknown critical

This won't work to protect against a server misconfigured to use the RSA EE
certificate for Bleichenbacher vulnerable handshakes. We would need to
limit to ECDSA certs and ensure that the subcert cannot be gamed into being
something else that might get signed by a TLS server.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2016 13:33:57 -0700

On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett <[email-masked]>
wrote:

> Adding a PKIX extension to mandate a minimum threshold of security
> configuration (e.g. PFS+AEAD w/o resumption or SHA1 or any support for TLS
> <1.2) would also be great to have

This seems like a fairly blunt instrument. Better to make sure that TLS's
negotiaton
mechanisms are reliable and trustworthy.

-Ekr

> . In fact, if an intermediate could also set such a requirement and have
> that be required for all end-entity certs signed by it, that'd be a great
> way to protect against downgrades.
>
>
> Dave
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Mar 2016 00:47:08 +0300

> mechanisms are reliable and trustworthy.

Unfortunately, there's the broken key exchanges, which fundamentally
compromise any version negotiation.

Yes, one could set RSA KeyUsage to just DigitalSignature, which would
nominally disable those broken key exchanges. Unfortunately:

- Many clients don't enforce that.
- That kind of certificates are listed as SHOULD NOT issue.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2016 14:57:40 -0700

On Wed, Mar 30, 2016 at 2:47 PM, Ilari Liusvaara <[email-masked]>
wrote:

> nominally disable those broken key exchanges.

Why is this necessary in this case? If you're a server which won't do static
RSA, why isn't it enough to just refuse to negotiate those cipher suites?

-Ekr