Delegated Credentials and the Web PKI

[wat...@cloudflare.com]

We are interested in CAs signing x509 certificates that can be used with delegated credentials for TLS, https://tools.ietf.org/html/draft-ietf-tls-subcerts-03. The certificates to be signed by the CA are x509 certificates that contain a special extension that identifies them as being able to sign short-lived (maximum 7 days) credentials to terminate TLS connections with. The short term credentials do not increase, decrease, or modify the authorization attached to the certificate: they are a tool to enable services like CDNs, SaaS providers, and indeed web servers to terminate TLS on behalf of a site for the duration chosen by the issuer of the authorization. The validity period of the certificates will not change, nor do we think there should be extra requirements on verification to issue certificates with this extension.

If using delegated credentials on a webserver with a separate server producing the delegated credentials, an event like Heartbleed that results in disclosure of a key has a more limited impact than the disclosure of the certificate's private key. Cloudflare has implemented Keyless SSL to achieve a similar effect, and this draft came out of the TLS WG's recognition that a standardized technology with similar properties would be broadly desirable. We need certificates to opt-in due to concerns about cross-protocol attacks. Delegated credentials can only be used with one signature scheme and are tied to the certificate and scheme used to issue them, so are robust in the face of cross-protocol attacks. To further minimize the risk we will add to security considerations that ECDSA certs are better due to Bleichenbacher issues in old TLS versions.

We are currently interested in deploying delegated credentials over the next few months, and hope CAs will help enable this for the broader web ecosystem. Nothing in the BR or Mozilla Root Program requirements forbids issuing certs with these extensions, but we felt it would be prudent to ask for feedback on this proposal from more sources then just those involved in the TLS WG. I look forward to your thoughts.

Sincerely,

Watson Ladd

[Ryan Sleevi]

On Fri, Mar 8, 2019 at 4:35 PM watson--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> We are interested in CAs signing x509 certificates that can be used with
> delegated credentials for TLS,
> https://tools.ietf.org/html/draft-ietf-tls-subcerts-03. The certificates
> to be signed by the CA are x509 certificates that contain a special
> extension that identifies them as being able to sign short-lived (maximum 7
> days) credentials to terminate TLS connections with. The short term
> credentials do not increase, decrease, or modify the authorization attached
> to the certificate: they are a tool to enable services like CDNs, SaaS
> providers, and indeed web servers to terminate TLS on behalf of a site for
> the duration chosen by the issuer of the authorization. The validity period
> of the certificates will not change, nor do we think there should be extra
> requirements on verification to issue certificates with this extension.
>

Is there a security considerations or analysis that explores the
considerations that were examined with respect to these certificates?

I ask, because in the context of HTTP Signed Exchanges
https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html
,
there was an effort to introduce additional validation requirements, most
notably, the explicit consent and opt-in by a site (via CAA) and a policy
expectation encoded in the spec that CAs SHALL NOT issue unless that CAA
constraint is satisfied. While in the case of HTTP Signed Exchanges, these
represent an extension of capability, and especially the ability to be used
in the absence of a direct connection to the authoritative origin (as
determined by DNS), it would be useful to know what sort of considerations
have been made - whether it's ruling out particular concerns or including
particular concerns (e.g. the inclusion within Section 3.2 of the draft of
the delegationUsage extension)

One example that stands out is the requirement that the extension MUST be
marked non-critical. The rationale for that decision would be useful to
capture in some way, whether in this document or in a supplementary
"explainer", so as to capture the thinking. A small note, if it can be
accepted, is that I believe the intended wording is "MUST NOT be marked
critical", since as a DEFAULT value in a sequence with a value of FALSE,
you would not encode anything for the criticality field. I highlight this,
as it's an area where CAs have incorrectly DER encoded FALSE values (see
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
), and such wording may lead to a similar, and undesirable, result.

If using delegated credentials on a webserver with a separate server
> producing the delegated credentials, an event like Heartbleed that results
> in disclosure of a key has a more limited impact than the disclosure of the
> certificate's private key. Cloudflare has implemented Keyless SSL to
> achieve a similar effect, and this draft came out of the TLS WG's
> recognition that a standardized technology with similar properties would be
> broadly desirable. We need certificates to opt-in due to concerns about
> cross-protocol attacks. Delegated credentials can only be used with one
> signature scheme and are tied to the certificate and scheme used to issue
> them, so are robust in the face of cross-protocol attacks. To further
> minimize the risk we will add to security considerations that ECDSA certs
> are better due to Bleichenbacher issues in old TLS versions.
>

To confirm: In the event of a Heartbleed-like event, the expectation would
be that CAs would revoke non-Delegation Credential certificates (due to the
possible key compromise issues), but that certificates bearing the
delegationUsage extension would not be revoked, correct?

> We are currently interested in deploying delegated credentials over the
> next few months, and hope CAs will help enable this for the broader web
> ecosystem. Nothing in the BR or Mozilla Root Program requirements forbids
> issuing certs with these extensions, but we felt it would be prudent to ask
> for feedback on this proposal from more sources then just those involved in
> the TLS WG. I look forward to your thoughts.

Just to echo this for participants who may not be familiar with the
specific requirements of the Baseline Requirements, the specific
requirement or dispensation exists with 7.1.2.4 of the Baseline
Requirements (v1.6.3)

All other fields and extensions MUST be set in accordance with RFC 5280.
> The CA SHALL NOT issue a
> Certificate that contains a keyUsage flag, extendedKeyUsage value,
> Certificate extension, or other data not
> specified in section 7.1.2.1, 7.1.2.2, or 7.1.2.3 unless the CA is aware
> of a reason for including the data in the
> Certificate.



CAs SHALL NOT issue a Certificate with:
> a. Extensions that do not apply in the context of the public Internet
> (such as an extendedKeyUsage
> value for a service that is only valid in the context of a privately
> managed network), unless:
> i. such value falls within an OID arc for which the Applicant
> demonstrates ownership, or
> ii. the Applicant can otherwise demonstrate the right to assert the data
> in a public context; or
> b. semantics that, if included, will mislead a Relying Party about the
> certificate information verified by
> the CA (such as including extendedKeyUsage value for a smart card, where
> the CA is not able to verify
> that the corresponding Private Key is confined to such hardware due to
> remote issuance).


Under this provision, the argument is that the existence of the IETF draft
document, with the to-be-assigned extension point for this usage, would
allow CAs to satisfy the requirement of 7.1.2.4(a)(ii), provided they
issued according to that draft document once such an OID has been assigned.

The only concern with such an interpretation respect to 7.1.2.4(b). Is it
correct that the assumption is that the CA will require that the Applicant
for such a certificate affirmatively declare it shall be used for that
purpose?

[wat...@cloudflare.com]

On Friday, March 8, 2019 at 2:35:42 PM UTC-8, Ryan Sleevi wrote:
> On Fri, Mar 8, 2019 at 4:35 PM watson--- via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>

<chop>

>
> Is there a security considerations or analysis that explores the
> considerations that were examined with respect to these certificates?

First let me thank you for your thoughtful and detailed reply.

I think this indicates that we should expand the security considerations section of the draft. Certainly I've mostly been thinking in terms of ensuring cross-protocol attacks and the like are prevented more than broader WebPKI policy questions.

>
> I ask, because in the context of HTTP Signed Exchanges
> https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html
> ,
> there was an effort to introduce additional validation requirements, most
> notably, the explicit consent and opt-in by a site (via CAA) and a policy
> expectation encoded in the spec that CAs SHALL NOT issue unless that CAA
> constraint is satisfied. While in the case of HTTP Signed Exchanges, these
> represent an extension of capability, and especially the ability to be used
> in the absence of a direct connection to the authoritative origin (as
> determined by DNS), it would be useful to know what sort of considerations
> have been made - whether it's ruling out particular concerns or including
> particular concerns (e.g. the inclusion within Section 3.2 of the draft of
> the delegationUsage extension)

Are there specific concerns that you think should be addressed? Note that any substantive discussions of changes beyond the editorial should take place on the TLS-WG list.

>
> One example that stands out is the requirement that the extension MUST be
> marked non-critical. The rationale for that decision would be useful to
> capture in some way, whether in this document or in a supplementary
> "explainer", so as to capture the thinking. A small note, if it can be
> accepted, is that I believe the intended wording is "MUST NOT be marked
> critical", since as a DEFAULT value in a sequence with a value of FALSE,
> you would not encode anything for the criticality field. I highlight this,
> as it's an area where CAs have incorrectly DER encoded FALSE values (see
> https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
> ), and such wording may lead to a similar, and undesirable, result.

Excellent editorial note! As for why not mark critical we want these certificates to also work
for clients that do not support the extension. I can imagine a situation where a certificate is on a low-performance HSM, and delegated credentials are usually used, but then there is the occasional fallback.

>
> If using delegated credentials on a webserver with a separate server
> > producing the delegated credentials, an event like Heartbleed that results
> > in disclosure of a key has a more limited impact than the disclosure of the
> > certificate's private key. Cloudflare has implemented Keyless SSL to
> > achieve a similar effect, and this draft came out of the TLS WG's
> > recognition that a standardized technology with similar properties would be
> > broadly desirable. We need certificates to opt-in due to concerns about
> > cross-protocol attacks. Delegated credentials can only be used with one
> > signature scheme and are tied to the certificate and scheme used to issue
> > them, so are robust in the face of cross-protocol attacks. To further
> > minimize the risk we will add to security considerations that ECDSA certs
> > are better due to Bleichenbacher issues in old TLS versions.
> >
>
> To confirm: In the event of a Heartbleed-like event, the expectation would
> be that CAs would revoke non-Delegation Credential certificates (due to the
> possible key compromise issues), but that certificates bearing the
> delegationUsage extension would not be revoked, correct?

The expectation is that certificates bearing the delegatedUsage extension would not need to be revoked as they would not have been compromised. This of course depends on the details: if a webserver was happily serving up the entire disk, private keys included that otherwise were living in a different process, then the certificates would be compromised and hence need to be revoked.

I do not understand what 7.1.2.4(a) means. My interpretation, were someone to demand I explain it, would be that 7.1.2.4(a) does not exclude any extensions standardized by the IETF as those extensions apply to the public Internet.

>
> The only concern with such an interpretation respect to 7.1.2.4(b). Is it
> correct that the assumption is that the CA will require that the Applicant
> for such a certificate affirmatively declare it shall be used for that
> purpose?

I do not understand what 7.1.2.4(b) is saying as applied to this matter. What assertion is being made about what with this OID in place? I think what you are saying is this OID should be opt-in on the part of the Applicant and the BRs require it to be opt-in, and the security analysis might be assuming this.

Sincerely,
Watson

[Ryan Sleevi]

(Sending from the right e-mail this time)

Thanks for the responses! I think this is a great thing to bring here,
because there are some interplays with policy and implications that can
affect the design, as I discuss below. I'm trying to be mindful of
proffering solutions outside of the TLS-WG, so mostly, I'm trying to
provide context and framing and create some supporting paper trail. Totally
happy to engage in the TLS-WG if there are substantive technical changes to
address the specific policy concerns.

On Fri, Mar 8, 2019 at 7:16 PM watson--- via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> > I ask, because in the context of HTTP Signed Exchanges
> >
> https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html
> > ,
> > there was an effort to introduce additional validation requirements, most
> > notably, the explicit consent and opt-in by a site (via CAA) and a policy
> > expectation encoded in the spec that CAs SHALL NOT issue unless that CAA
> > constraint is satisfied. While in the case of HTTP Signed Exchanges,
> these
> > represent an extension of capability, and especially the ability to be
> used
> > in the absence of a direct connection to the authoritative origin (as
> > determined by DNS), it would be useful to know what sort of
> considerations
> > have been made - whether it's ruling out particular concerns or including
> > particular concerns (e.g. the inclusion within Section 3.2 of the draft
> of
> > the delegationUsage extension)

> Are there specific concerns that you think should be addressed? Note that
> any substantive discussions of changes beyond the editorial should take
> place on the TLS-WG list.

I was trying to capture a request to understand what the thinking had been.
The design shape tends to evolve over time, and various considerations may
be raised and ruled out, or result in design changes. Typically in the IETF
drafts, the "Security Considerations" tend to focus on "Here's the concerns
with the document in the current state", but I suppose I was trying to
understand if there is more documentation on "Here were the concerns that
motivated this particular decision", if there were any. It may very well be
that various decisions were made by throwing darts at a dart board ;)

The discussion of validation requirements naturally lead to a desire to
understand more of the reasoning about how the conclusion was reached, not
necessarily a disagreement with the conclusion. HTTP Signed Exchanges took
a similar approach, but reached different conclusions. Those conclusions
may have been (and likely are) due to their very different threat models,
but understanding whether all this had been discussed and bashed out and
reasoned about it just as useful as understanding the conclusion (i.e. that
no additional validation is required), since that's what gives CAs and the
community confidence that it's a sensible conclusion.

I don't think these are things that necessarily need to be addressed in the
draft; in many ways, they're answers to the policy questions that the
technical draft raises.

<snip>

> Excellent editorial note! As for why not mark critical we want these
> certificates to also work
> for clients that do not support the extension. I can imagine a situation
> where a certificate is on a low-performance HSM, and delegated credentials
> are usually used, but then there is the occasional fallback.

<snip>

> The expectation is that certificates bearing the delegatedUsage extension
> would not need to be revoked as they would not have been compromised. This
> of course depends on the details: if a webserver was happily serving up the
> entire disk, private keys included that otherwise were living in a
> different process, then the certificates would be compromised and hence
> need to be revoked.

I think these two things may be incompatible. Given that it's not a
critical extension, and thus MAY be used to terminate the connections, from
a policy perspective, CAs would likely need to assume the key "probably" is
compromised, and thus revoke. This means it doesn't really address the
Heartbleed scenario - the certificates still end up revoked.

Making the extension critical provides a greater signal to CAs that it's
unlikely to have been used on the server (since conforming clients would
have rejected it), and thus make it less likely to need to revoke the
extension-bearing certificates vs the 'traditional' certificates.

Not to pick on Cloudflare, but since they ran into a large revocation event
re: Heartbleed, it actually makes a great example. If Cloudflare had been
using delegated credential-enabled certificates for both DC-enabled and
non-DC-enabled clients, then the safest path a CA could take to defend
themselves against an adverse interpretation of the BRs or Mozilla Policy
would be to revoke these certificates. If such certificates were unusable
for non-DC-enabled clients, then there's stronger protocol-level indicators
that such certificates would not have had their private keys exposed (only
the DC keys would have been exposed), and thus it wouldn't be necessary to
revoke the DC-enabled-certificates.

Hopefully that makes sense; there's some interplay here between the policy
implications and expectations of revocation, particularly around
Heartbleed-like events, and what DC is trying to achieve. While DC (and
things like keyless SSL) MIGHT mean the certificates and keys were less
likely to be exposed for a given Subscriber/certificate, the conservative
CA would take the conservative approach of assuming they had been, and
require a key rotation regardless.

<snip>

> I do not understand what 7.1.2.4(b) is saying as applied to this matter.
> What assertion is being made about what with this OID in place? I think
> what you are saying is this OID should be opt-in on the part of the
> Applicant and the BRs require it to be opt-in, and the security analysis
> might be assuming this.

The thinking here is this: Reading the BRs in a very conservative
perspective, CAs need to be very careful about what additional extensions
they include within a certificate, both as a matter of policy and as it
matters to compliance with the BRs. A CA including an extension not
enumerated in the BRs bears the burden of proof to demonstrate why the
inclusion is permissible by the BRs. 7.1.2.4 places restrictions on the
types of extensions, and thus the CA has to demonstrate that both
conditions have been satisfied, even under a maximally pessimistic
interpretation.

Given this framing, my hope was to get a clear interpretation on the record
for why it would be OK for CAs to include such an extension, and how they
could demonstrate both criteria have been satisfied, even under a
pessimistic reading. By discussing it here on m.d.s.p., that then makes it
easier for CAs to point back to the public discussion and the
interpretation that was discussed and the consensus reached, and thus
allows a CA to respond to anyone that might file an incident report
claiming non-compliance with the BRs (due to including the extension) with
that discussion.

Having that discussion now makes it easier for CAs wanting to adopt these
certificates to have confidence that including it is defensible. :)