Subject: [Lurk] Fwd: draft-rescorla-tls-subcerts

From: Eric Rescorla <[email-masked]>
Date: Fri, 8 Jul 2016 07:59:03 -0700

Perhaps complementary to lurk. Being discussed on the TLS list.

---------- Forwarded message ----------
From: Eric Rescorla <[email-masked]>
Date: Thu, Jul 7, 2016 at 12:28 PM
Subject: draft-rescorla-tls-subcerts
To: "[email-masked]" <[email-masked]>

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: Leif Johansson <[email-masked]>
Date: Tue, 12 Jul 2016 18:57:33 +0200

> Perhaps complementary to lurk. Being discussed on the TLS list.

https://www.ietf.org/rfc/rfc3820.txt ?

> From: *Eric Rescorla* <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> 
> 
> In terms of the security analysis, it's obviously very important that
> this mechanism
> 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.
> 
> 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.
> 
> _______________________________________________
> Lurk mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lurk
>

---

From: Carl Wallace <[email-masked]>
Date: Tue, 12 Jul 2016 13:18:52 -0400

>https://www.ietf.org/rfc/rfc3820.txt ?

3820 suffers from the fatal flaw of using a critical extension, which has
limited its adoption. I think the sub-certs spec could address this and
use a non-critical extension in a CA-issued certificate. The non-critical
extension would contain a structure signed by the delegating party. The
structure for the TLS extension in the sub-certs spec probably has the
content that would desired in the extension. The pre-certificate structure
in the experimental CT draft would be another approach, but maybe more
complicated. This approach would require validating the delegating party's
cert in addition to the proxy cert. However, it may also be a means of
addressing the problem of authorizing a content inspection proxy when
mutually authenticated TLS is used.