Subject: [TLS] draft-rescorla-tls-subcerts

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Jul 2016 12:28:33 -0700

We've talked several times about designing some sort of TLS delegation
mechanism. A few of us got together and put together some initial thoughts
about the options at:
https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt

The general idea here is to have some mechanism for allowing what
are effectively end-entities to issue short-lived credentials that allow
other
entities to act on their behalf (e.g., for CDN use cases).
Comments welcome.

In terms of the security analysis, it's obviously very important that this
mechanism
not present a risk to existing TLS servers. The mechanism designed here is
intended to be future safe in that sense, though perhaps we've missed
something.

I also wanted to clarify a couple points about attacks where the
certificate that signs the delegated credential is also used for ordinary
TLS operation (which generally is a practice that's pretty scary). As noted
above it's important that existing certs not be usable this way, but maybe
future certs would be.

1. It's important to construct the delegated credential in such a way that
you can't use a TLS server as a signing oracle. If you choose "option 2"
where you define a new structure, then it's probably sufficient to use the
TLS 1.3 "context-including" digitally-signed production proposed by AGL. If
you you choose "option 1" where the delegated credential is an X.509 cert,
then you'd need to make some rules about fixing portions of the cert that
the TLS client can't control.

2. If you're concerned about attacks like those of Jager et al. which
exploit RSA decryption, what's important is that the attacker not be able
to get the server to do TLS 1.2-style static RSA with the key. Playing with
the usage bits definitely makes it harder to configure the server this way
(because it's likely to cause bustage) but may not be enough, because
sufficiently busted clients and server might be willing to use them that
way anyway.

In the next rev, we'll update the draft to make these points more clearly.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 8 Jul 2016 01:13:24 +0300

On Thu, Jul 07, 2016 at 12:28:33PM -0700, Eric Rescorla wrote:
> other entities to act on their behalf (e.g., for CDN use cases).
> Comments welcome.
> 

- I think most browsers ignore KeyUsage presently, allowing the broken RSA
  key exchange even when KeyUsage does not permit it. And as for server side,
  I don't think many server products check the certificate they try to load,
  just serve it mostly blindly.
- I would definitely use TLS 1.3 signature construct for digitally-signed
  instead of TLS 1.2 one, as it mitigates some attacks (oh, you arlready
  mentioned it below).

Also, instead of extension one way that came to mind would be a new
CertficateType, where Cert#0 is the delgated credential and Cert#1 is
X.509 EE cert, and then comes the normal CA certs. Dunno which would be
better.

I also checked if one could do some funky stuff with credential lifetime
notation to limit the lifetime. Nothing came up (apart for using 16-bit
count in decaseconds (das) only allowing presenting lifetimes up to 7
days, 14 hours, 2 minutes and 30 seconds). :->

Also, what is the ServerNameList for? As far as I see, the delegated
credential structure only contains one name. Or was it supposed to have
multiple, but there was a typo in definition?

Also why "SignatureScheme algorithm;" ... Doesn't digitally-signed already
have a algorithm field?

Also, doesn't digitally-signed "eat" all the fields inside? So if you
want to actually transfer the data, you need the actual fields the second
time?

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Jul 2016 15:19:30 -0700

>   just serve it mostly blindly.

This is my sense as well. That text in the document probably needs to be
rewritten.

> want to actually transfer the data, you need the actual fields the second

All good catches. This was supposed to be more evocative than definitive,
and
we probably would have been better not providing any definition at all :)

-Ekr

---

From: Kyle Rose <[email-masked]>
Date: Thu, 7 Jul 2016 20:08:11 -0400

> days, 14 hours, 2 minutes and 30 seconds). :->

What would it be anchored to if it's not an absolute time? If you anchor
the interval to, say, the issue time of the end-entity cert you haven't
limited the resolution of the interval in any useful way: it still needs to
be able to express intervals that end at or after the expire time. I
suppose an implementor could be less likely to screw up if you also include
and sign the interval start and require two things:

(1) interval start <= now() + fuzz
(2) interval length < 7 days

Are these really much easier than

(1) interval start <= now() +- fuzz <= interval end
(2) interval end - interval start < 7 days

?

Kyle

---

From: Watson Ladd <[email-masked]>
Date: Thu, 7 Jul 2016 19:29:08 -0700

On Jul 7, 2016 12:29 PM, "Eric Rescorla" <[email-masked]> wrote:
> are effectively end-entities to issue short-lived credentials that allow other
> In terms of the security analysis, it's obviously very important that this mechanism
> intended to be future safe in that sense, though perhaps we've missed something.
>
> I also wanted to clarify a couple points about attacks where the certificate that signs the delegated credential is also used for ordinary TLS operation (which generally is a practice that's pretty scary). As noted above it's important that existing certs not be usable this way, but maybe future certs would be.
>
> 1. It's important to construct the delegated credential in such a way that you can't use a TLS server as a signing oracle. If you choose "option 2" where you define a new structure, then it's probably sufficient to use the TLS 1.3 "context-including" digitally-signed production proposed by AGL. If you you choose "option 1" where the delegated credential is an X.509 cert, then you'd need to make some rules about fixing portions of the cert that the TLS client can't control.
>
> 2. If you're concerned about attacks like those of Jager et al. which exploit RSA decryption, what's important is that the attacker not be able to get the server to do TLS 1.2-style static RSA with the key. Playing with the usage bits definitely makes it harder to configure the server this way (because it's likely to cause bustage) but may not be enough, because sufficiently busted clients and server might be willing to use them that way anyway.

How about limit to ECDSA certificates? This eliminates the
Bleichenbacher issues. We can also make this opt in via an extension
to the EE certificate: since the certificate is not a CA certificate
(even if used that way) the extension can be noncritical.

As for format we know we have a TLS 1.3 signed structure that doesn't
overlap. Option 2 is easy: throw a key and TAI seconds for interval
start and end. I hope we won't need more structure then that. Using
X509 runs a risk of cross-format issues, and showing there aren't any
is likely to be hard.

I don't think we can use name constraints here. Yes, they are opt-in
and clients can indicate support, but it may well be that a TLS
implementation doesn't know if its X509 validation code will support
them as it hands the certificate to a system provided validator. (I
believe there was a longstanding Chrome on Windows XP bug for a
similar reason).

Sincerely,
Watson

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

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 8 Jul 2016 03:28:57 +0000

>https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt

That's going to be a tricky one.  The PKIX standing committee has always
rigidly (and in some cases I'd say rabidly) opposed anything that would allow
end users to bypass CAs (in one case the WG chair killed a proposal for
delegated certs with the comment "we don't want to turn X.509 into PGP").
Admittedly PKIX is now defunct, but there are still enough PKIX members in the
IETF that it could be tricky getting anything done.

Another issue is how you're going to do it.  You really need to have an EE
able to use a standard cert to issue short-term certs for high-exposure
environments, so only the high-risk key needs to be online.  One of the
proposals for this (which I have a link to, since I wrote it in this case)
was:

https://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt

This talks about all of the issues involved.

The alternative is to use a cert to sign "credentials", whatever form that may
take.  That's going to get ugly since you're now introducing something that's
in effect a certificate, but isn't called a certificate (yes, you can whittle
it down a bit, but eventually you'll want to add more features, and end up
reinventing certs). 

I would go for delegated certs, since 99% of the work is already done for you
(formats, data types, how to process them, code to handle them, etc).

Peter.

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Jul 2016 00:53:54 -0400

Eric:

I have not had a chance to look at the draft yet, but based on your cover note you seem to have several requirements in common with RFC 3820.

Russ

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 8 Jul 2016 13:09:34 +0300

On Thu, Jul 07, 2016 at 08:08:11PM -0400, Kyle Rose wrote:
> What would it be anchored to if it's not an absolute time? 

There is validity start time in there, the relative end time would
be relative to that.

That is, instead of saying "this is valid from t1 to t2", saying "this
is valid from t to t+dt".

No real perference either way, it was just an experiment to play with
time notations.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 8 Jul 2016 13:21:10 +0300

> (even if used that way) the extension can be noncritical.

You mean ECDSA legacy signature type (TLS_ECDHE_ECDSA_WITH_*
ciphersuites)? There's EdDSA too (and it would meet the above definition)?

New extension would need CAs to issue it, and getting them to do that
could be, erm... "laborious".

> X509 runs a risk of cross-format issues, and showing there aren't any

Or use POSIX time notation if you can tolerate being off by a second
due to leap secods.

Then the proposal had server name or server name list. Dunno if those
are needed.

> believe there was a longstanding Chrome on Windows XP bug for a

The nasty Chrome on WinXP bug I was aware of was that WinXP code couldn't
handle certificates that were like "allow all, except .foo". LE X1
intermediate hit that bug, causing lots of trouble, even with WinXP being
EoL'd.

-Ilari

---

From: Kyle Rose <[email-masked]>
Date: Fri, 8 Jul 2016 09:03:36 -0400

> No real perference either way, it was just an experiment to play with

I think either would be fine, but once we start playing with the units
(e.g., decaseconds), we're probably likely to increase errors. The nice
thing about (t,dt) is that of the required checks:

t <= now
now <= t+dt
dt <= 7 days

the complex case (doing arithmetic on timestamps, for some value of
"complex") has a straightforward backup control with no arithmetic and with
comparison to a static value: dt <= 604800. With (t1,t2), the 7 day hard
limit is the more complex check.

That said, anyone hacking on security software probably shouldn't screw
this up in either case. I'm even struggling to imagine a system library
that could lead to unexpected errors here, given that the values are just
epoch times.

Kyle

---

From: David Benjamin <[email-masked]>
Date: Fri, 08 Jul 2016 15:35:24 +0000

> believe there was a longstanding Chrome on Windows XP bug for a

What are you referring to? I think one would know well enough whether our
validators support a given feature. If there's weird cases, one can always
decline to advertise if unsure.

If you're thinking ECDSA and Chrome/XP, I believe it only got reflected in
the cipher list and not sigalgs, but that's just because we never routed
that bit through, not because we didn't know if we could do ECDSA. (And by
now it's irrelevant since Chrome/XP is no longer supported.)

David

---

From: Andrei Popov <[email-masked]>
Date: Fri, 15 Jul 2016 00:28:18 +0000

Naïve question: why not simply get a constrained CA certificate and issue short-validity end entity certs? Unless I’m missing something, this would work with existing TLS implementations, no extensions required.

Short-lived credential approach seems more viable than draft-mglt-lurk-tls-requirements-00 (which requires an additional round-trip between the Edge Server and Content Provider).

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, July 7, 2016 12:29 PM
To: [email-masked]
Subject: [TLS] draft-rescorla-tls-subcerts

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 15 Jul 2016 02:53:04 +0000

> Naïve question: why not simply get a constrained CA certificate and issue short-validity end entity certs?

Wouldn't you need one for every potential user? And the nameConstraints then becomes a union of all SAN fields?

> Short-lived credential approach seems more viable than draft-mglt-lurk-tls-requirements-00 (which requires an additional round-trip between the Edge Server and Content Provider).

Except that the RSALG and/or "keyless SSL" approach are already deployed.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 15 Jul 2016 12:14:23 +0300

On Fri, Jul 15, 2016 at 12:28:18AM +0000, Andrei Popov wrote:
> Naïve question: why not simply get a constrained CA certificate and
> issue short-validity end entity certs? Unless I’m missing something,
> this would work with existing TLS implementations, no extensions
> required.

The I-D actually covers this. Additionally, I think getting NC
certificate is quite expensive/difficult.

> Short-lived credential approach seems more viable than
> draft-mglt-lurk-tls-requirements-00 (which requires an additional
> round-trip between the Edge Server and Content Provider).

Those two serve different purposes. Sometimes you really need the
ES/KS split, sometimes short-lived certs would be more useful.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Fri, 15 Jul 2016 17:34:40 +0000

> The I-D actually covers this.
Understood; the I-D lists a few cons, but arguably none of them are blocking issues. It seems unnecessary to create a new TLS-specific mechanism that duplicates existing PKI semantics.

> Those two serve different purposes. Sometimes you really need the ES/KS split, sometimes short-lived certs would be more useful.
Possibly so.

Cheers,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 15, 2016 2:14 AM
To: Andrei Popov <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; [email-masked]
Subject: Re: [TLS] draft-rescorla-tls-subcerts

> this would work with existing TLS implementations, no extensions 

The I-D actually covers this. Additionally, I think getting NC certificate is quite expensive/difficult.

> round-trip between the Edge Server and Content Provider).

Those two serve different purposes. Sometimes you really need the ES/KS split, sometimes short-lived certs would be more useful.

-Ilari

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 15 Jul 2016 13:47:00 -0500

> Understood; the I-D lists a few cons, but arguably none of them are blocking issues. It seems unnecessary to create a new TLS-specific mechanism that duplicates existing PKI semantics.

I think the main justification is supposed to be that there's a big
impedance mismatch between the engineering reality of interacting with
PKI CAs and the engineering demands seen in the field.

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 16 Jul 2016 12:09:29 +0300

On Fri, Jul 15, 2016 at 05:34:40PM +0000, Andrei Popov wrote:
> Understood; the I-D lists a few cons, but arguably none of them are
> blocking issues. It seems unnecessary to create a new TLS-specific
> mechanism that duplicates existing PKI semantics.

IMO, the draft severly understates the cons. Basically, NC certs aren't
feasible except for the bigger shops that can afford the $$$ and the
difficulty needed.

Also, it doesn't look like the semantics are complicated. E.g one
can completely skip revocation by making things short-lived (because
revocation on short timescales simply does not work anyway).

-Ilari