Subject: [dane] Fragility of binding to a CA certificate by certificate or ski

From: Trevor Freeman <[email-masked]>
Date: Tue, 15 Nov 2011 12:08:24 +0000

For usage type =0, I am concerned about the fragility of matching a CA certificate is only by full certificate or SKI. Certificates and keys have an inherently limited lifetime. CAs need to renew both as a matter of routine maintenance, which is an operation outside of the visibility of the domain and updating the domain DNS record is outside the control of the CA. This is a recipe for things to go wrong. All a CA can do is notify the domain of the update and hope they make the change to the DNS record.

A more stable CA identifier would be a CA's subject name. This will remain constant as certificates and keys are renewed. You can easily put a hexadecimal encoded subject names in the DNS record and define a new match type. It would also be simple for the CA to publish instructions for creating the DNS record and include the binary encoded subject name on the web page so the domain administrator can simple cut and paste the value when creating the DNS record for their domain and the instructions will not need updating every time they renew their CA certificate.

Dr Trevor Freeman  Senior Security Strategist
End to End Trust Team<http://www.microsoft.com/mscorp/twc/endtoendtrust/default.mspx>
Microsoft Trustworthy Computing <http://www.microsoft.com/mscorp/twc/default.mspx>

---

From: Adam Langley <[email-masked]>
Date: Tue, 15 Nov 2011 22:37:49 -0500

On Tue, Nov 15, 2011 at 7:08 AM, Trevor Freeman
<[email-masked]> wrote:
> For usage type =0, I am concerned about the fragility of matching a CA
> certificate is only by full certificate or SKI. Certificates and keys have
> an inherently limited lifetime.

You are correct that matching by a certificate is a mistake because
CAs often reissue their CA certificates and clients build chains from
the bottom up.

However, matching a SubjectPublicKeyInfo is rather robust. Certainly
the leaf certificate cannot change without a site reconfiguring their
servers. That implies that the next certificate's (call it I1) SPKI is
fixed by the leaf (because it has to match the signature on the leaf).

Above that, one could imagine the combination of:
* The site fails to include any intermediate certificates
* The leaf doesn't include an Authority Key Identifier, but incudes an
AIA URL for I1
* I1 is replaced with a certificate with the same SPKI, but a different issuer.

That way the CA could redirect the chain without the site knowing.
However, it requires a misconfiguration of the site (that will cause
intermittent issues and some clients to fail completely) and a grossly
stupid CA.

On the other hand, specifying via CA Subject name is very weak: any CA
can issue certificates with any Subject name.

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Nov 2011 22:10:37 +0100 (MET)

Trevor Freeman wrote:
> certificate is only by full certificate or SKI. Certificates and keys
> have an inherently limited lifetime.

That is only a problem for "cert pinning", but not for DANE.

>
> CAs need to renew both as a matter of routine maintenance, which is
> an operation outside of the visibility of the domain and updating the
> domain DNS record is outside the control of the CA. This is a recipe
> for things to go wrong. All a CA can do is notify the domain of the
> update and hope they make the change to the DNS record.

Renewal of server certificates is an administrative task of the
server admin, and certificate issuance is irrelevant, the
only thing that matters is the actual administrative update of the
servers certificate on the server itself.

The CA certificate necessary to verify the server certificate is
locked down with the signature on the server certificate and
MUST be (per TLS protocol spec) sent by the TLS server in the
servers certificate handshake message.

When the CA issues the server certificate unter a different CA cert
on server certificate renewal, then the server admin will have to
update the DNS TLSA record before installing the new server
certificate, of course.   While a CA may "price" this the same as
a renewal, it technically is not a renewal, but a different
certificate, requiring the TLS server to also send a different
forward certification path in the TLS server certificate handshake
message, so such a CA better WARNS it customer with a big red sign
when doing this instead of a renewal.

> 
> A more stable CA identifier would be a CA's subject name.
> This will remain constant as certificates and keys are renewed.

Very bad idea.  Every CA in the TLS X.509 PKI can create a
subordinate CA with any arbitrary Name in it

This idea would only work in a strictly hierarchical PKI with a
singular root authority (which does not need to have a root cert,
but must have the authority to define and enforce the policy by which
all CAs in the PKI must be operated).

-Martin

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 17 Nov 2011 01:31:56 +0000

Hi And,

Pkix has many controls to control trust in CAs. There are more controls for trust in CAs certificates than those over end entities. We are talking about usage type =0 so the relying party has full control over their own pkix policy.

I agree that matching SKI is a stronger binding but it is not necessary more robust if it results in loss of service. It’s a much a business rick determination if the site want to trade higher availability for a stronger binding. They are best placed to determine scale of impact from loss of service vs. an active attack.

Given we are anticipating a work with DNSSEC, the attacker now has to obtain a site certificate and compromise some part of the routing infrastructure for the mark so they can perform address mapping to redirect the ip traffic to the bogus site. That is not an attack that scales well but if the CA changes its key and the site did not update its DNS record, the site is down.

Adam, you need to check 5280 section 6. Pkix chaining is name based not key based.  Yes it checks the signatures but SKI\AKI matching is not used in any way.

Matching by subject name presents a strong CA binding mechanism which is more robust against configuration mismatch - hence delver's higher availability. 

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Wednesday, November 16, 2011 11:38 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski

> have an inherently limited lifetime.

You are correct that matching by a certificate is a mistake because CAs often reissue their CA certificates and clients build chains from the bottom up.

However, matching a SubjectPublicKeyInfo is rather robust. Certainly the leaf certificate cannot change without a site reconfiguring their servers. That implies that the next certificate's (call it I1) SPKI is fixed by the leaf (because it has to match the signature on the leaf).

Above that, one could imagine the combination of:
* The site fails to include any intermediate certificates
* The leaf doesn't include an Authority Key Identifier, but incudes an AIA URL for I1
* I1 is replaced with a certificate with the same SPKI, but a different issuer.

That way the CA could redirect the chain without the site knowing.
However, it requires a misconfiguration of the site (that will cause intermittent issues and some clients to fail completely) and a grossly stupid CA.

On the other hand, specifying via CA Subject name is very weak: any CA can issue certificates with any Subject name.

Cheers

AGL

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 17 Nov 2011 01:48:45 +0000

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, November 17, 2011 5:11 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or

That is only a problem for "cert pinning", but not for DANE.
[TF] DANE use type =0 depends on pkix validation which mends this is an issue for DANE to consider since you are depending on pkix.

>
> CAs need to renew both as a matter of routine maintenance, which is an 
> operation outside of the visibility of the domain and updating the 

Renewal of server certificates is an administrative task of the server admin, and certificate issuance is irrelevant, the only thing that matters is the actual administrative update of the servers certificate on the server itself.
[TF] The critical thing with server certificate renewal is that the site operator is fully aware of the new cert so can initiate the update of the DANE record of they are using the leaf cert for the DANE record.

The CA certificate necessary to verify the server certificate is locked down with the signature on the server certificate and MUST be (per TLS protocol spec) sent by the TLS server in the servers certificate handshake message.
[TF] Not true, any CA certificate with the same subject name and key can be used.  The server sends a set of certificates but the client is not obligated to use them. After that, the choice of possible paths is constrained only by what is valid under the relying parties trust policy. DANE does not mandate that the publish CA certificate be the leaf issuing CA, merely a CA that the pkix path must intersect. 

When the CA issues the server certificate unter a different CA cert on server certificate renewal, then the server admin will have to update the DNS TLSA record before installing the new server
certificate, of course.   While a CA may "price" this the same as
a renewal, it technically is not a renewal, but a different certificate, requiring the TLS server to also send a different forward certification path in the TLS server certificate handshake message, so such a CA better WARNS it customer with a big red sign when doing this instead of a renewal.
[TF]  We seem to be in violent agreement. For server certificate renewal the site admin has to be in the loop for request\installing the new certificate. That is not the case for a CA certificate. 

> This will remain constant as certificates and keys are renewed.

Very bad idea.  Every CA in the TLS X.509 PKI can create a subordinate CA with any arbitrary Name in it
[TF] As already observed, the pkix validation has many ways to control trust in CAs by the relying party. 

This idea would only work in a strictly hierarchical PKI with a singular root authority (which does not need to have a root cert, but must have the authority to define and enforce the policy by which all CAs in the PKI must be operated).
[TF] I don't understand the comment. Every pki path is hierarchical and this has no dependency on the number of root authorities. PKI
merely defines how to validate a path. 

[TF] Trevor

-Martin

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Nov 2011 09:53:38 +0800

So are you not concerned about the following attack?

1. example.com provisions a DANE record saying that any cert that comes under the CA "CN=super-trusted-ca.com" is OK for that domain

2. Nefarious attacker generates a cert with his own key pair and "CN=super-trusted-ca.com"

3. Nefarious attacker MitMs a TLS session to example.com and presents his cert

4. Client looks at the cert, sees the right name, and blissfully proceeds with the hijacked session

In light of this, any discussion of binding only to names is ridiculous.  I think this is what Adam was trying to say, a bit more politely.

--RIchard

On Nov 17, 2011, at 9:31 AM, Trevor Freeman wrote:

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Nov 2011 05:02:32 +0100 (MET)

(Your MUA's quoting style/settings seems completely hosed.)

Trevor Freeman wrote:
> Martin Rex wrote:
> > locked down with the signature on the server certificate and MUST
> > be (per TLS protocol spec) sent by the TLS server in the servers
> > certificate handshake message.
>
> [TF] Not true, any CA certificate with the same subject name and key
> can be used.

There are a number of broken TLS peers out there that perform discovery
instead of straight path validation, but that doesn't meant that it
is a good idea.

>
> The server sends a set of certificates but the client is not obligated
> to use them.

But should unconditionally abort when the path conveyed by the server(!)
does not validate, i.e. when the server included an expired cert. 

Btw. no sane CA should issue a cert with a validity beyond the
CAs own certificate.  That would be stupid and calling for trouble.

But I see that a common, and obviously very error prone custom,
such as conveying a server credential as a pitiful single certificate
instead of a sensibly bagged complete certification path, could lead
to the situation where a newly received server certificate might
outlive and old (intermediate) CA cert that is locally available
and get used erroneouly when the local PKI software does not
perform a certificate path validation against both, current time
and a second before the end-entities validto date and report the
error upfront, but blindly believes that inspite of arbitrarily
mixing and matching certificates into a certification path and
hoping for the best is "good enough".  That happens more likely for
developers who either do not provide support for what they ship
or are walled off from the support load their solutions create.

I do remember that when I was first exposed to SSL & X.509 in 2001
as a developer, I experimented with the test area of "Thawte",
and in their test area you could select whether to receive the
CA response as pitiful singular cert of PKCS#7 bag of a cert chain.
They had a notice on their page indicating that they expected PKCS#7
responses to become the standard and pitiful singular cert response
to become deprecated soon.

Unfortunately that migration never happened, and there is a significant
amount of PKI software with only brittle and vague idea of
"PKI credential management" providing plenty of administrative
pitfalls that would be trivially and completely avoidable.

As it turns out, the extreme laissez-faire approach of OpenSSL & Apache
to credential management is a major cause of misconfigured TLS servers
(by having the certification path spread out over entirely independent
 files and complete absence of a "credential management" concept
 that will ensure the server's forward certification path is validated
 at least once during installation of a new server certificate.)

An implementors approach to make a random pick about the value for
a protocol option, in combination with that pick not blowing up
on a very limited (read statistically insignificant) black-box test
with all default settings, is what caused Win7 to get shipped with
invalid RSA pre-master secret check on renegotiaton handshakes
and causes interop-problems when activating TLSv1.2 because
of the unconditional use of { 0x03,0x03 } for the record layer
protocol_version instead of only for the ClientHello.client_version
on the initial ClientHello.

>
> After that, the choice of possible paths is constrained only by what
> is valid under the relying parties trust policy. DANE does not mandate
> that the publish CA certificate be the leaf issuing CA, merely a CA
> that the pkix path must intersect. 

It OUGHT to be a certificate from the forward path that the server sends
within the server certificate handshake message.  If we do not have that
in the DANE protocol I-D, then we ought to put it in.

And clients ought to ensure that they *ALL* use the CA cert from the
server's Certificate handshake message when they perform the DANE
validation, because only for that cert an synchronous update
of the cert itself and the DNS DANE record can be ensured by the
server admin.  Distribution of renewed intermediate CA certs to
clients will be completely random and diverse -- if at all.

> 
> > (about unique CA subject names)
> >
> > This idea would only work in a strictly hierarchical PKI with a singular
> > root authority (which does not need to have a root cert, but must have
> > the authority to define and enforce the policy by which all CAs in the
> > PKI must be operated).
>
> [TF] I don't understand the comment. Every pki path is hierarchical
> and this has no dependency on the number of root authorities. PKI

Unique CA subject names and Name constraints extension can only work
in a strictly hierarchical PKI with ONE SINGLE root authority.

The TLS X.509 PKI has plenty of completely independent, omnipotent
root authorities.  The windows trust anchor store maintained by
Microsoft for Windows XP contains about 300 individual rootCA certificates
today.  And with big companies, such as Microsoft and Google, and government
agencies such as DHS operating their own, fully trusted, omnipotent CA,
you really ought to link your trust to specific keys rather than to
names that can be spoofed by probably several hundred independent
organizations around the globe (or anyone that manages to create
a valid CA cert und any one of those, either by break-in or by
collision precomputation or an MD2 or MD5 preimage attack on one
of the tainted old rootCA certs.

-Martin

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 17 Nov 2011 06:26:52 +0000

See inline below

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, November 17, 2011 12:03 PM
To: Trevor Freeman
Cc: [email-masked]; [email-masked]
Subject: Re: [dane] Fragility of binding to a CA certificate by certificate

Trevor Freeman wrote:
> > locked down with the signature on the server certificate and MUST be 
> > (per TLS protocol spec) sent by the TLS server in the servers 

There are a number of broken TLS peers out there that perform discovery instead of straight path validation, but that doesn't meant that it is a good idea.
[TF] Broken implementation are just that. DANE is mandating here pkix validation so anybody not doing pkix validation is non-compliant. 

> The server sends a set of certificates but the client is not obligated 

But should unconditionally abort when the path conveyed by the server(!) does not validate, i.e. when the server included an expired cert. 
[TF] The relying part MUST find a valid pkix path. The server may include expired certs but as long as the RP builds a valid path somehow, that is all that matters. 

Btw. no sane CA should issue a cert with a validity beyond the CAs own certificate.  That would be stupid and calling for trouble.
[TF] SHOULD not MUST. As long as the CA operator fixed the problem in time by creating a new CA certificate, life is good. The main case where this kind of behavior is useful is decommissioning a CA so you are sure all issued certificates are expired when you turn off the CA.

But I see that a common, and obviously very error prone custom, such as conveying a server credential as a pitiful single certificate instead of a sensibly bagged complete certification path, could lead to the situation where a newly received server certificate might outlive and old (intermediate) CA cert that is locally available and get used erroneouly when the local PKI software does not perform a certificate path validation against both, current time and a second before the end-entities validto date and report the error upfront, but blindly believes that inspite of arbitrarily mixing and matching certificates into a certification path and hoping for the best is "good enough".  That happens more likely for developers who either do not provide support for what they ship or are walled off from the support load their solutions create.
[TF] In scenarios like organization using bridge CA, the bag of certificates offered by the server is never complete - by design. The client still has to find a valid path by finding the missing certificates for itself. Expired or revoked CA certificates are the same problem. 

I do remember that when I was first exposed to SSL & X.509 in 2001 as a developer, I experimented with the test area of "Thawte", and in their test area you could select whether to receive the CA response as pitiful singular cert of PKCS#7 bag of a cert chain.
They had a notice on their page indicating that they expected PKCS#7 responses to become the standard and pitiful singular cert response to become deprecated soon.

Unfortunately that migration never happened, and there is a significant amount of PKI software with only brittle and vague idea of "PKI credential management" providing plenty of administrative pitfalls that would be trivially and completely avoidable.
[TF] TLS and DANE use types one and two are both fully dependent on pki so we have to accept the dependency on those aspects. 

As it turns out, the extreme laissez-faire approach of OpenSSL & Apache to credential management is a major cause of misconfigured TLS servers (by having the certification path spread out over entirely independent  files and complete absence of a "credential management" concept  that will ensure the server's forward certification path is validated  at least once during installation of a new server certificate.)
[TF] DANE has a dependency on TLS which in turn has a dependency on credential management. 

An implementors approach to make a random pick about the value for a protocol option, in combination with that pick not blowing up on a very limited (read statistically insignificant) black-box test with all default settings, is what caused Win7 to get shipped with invalid RSA pre-master secret check on renegotiaton handshakes and causes interop-problems when activating TLSv1.2 because of the unconditional use of { 0x03,0x03 } for the record layer protocol_version instead of only for the ClientHello.client_version on the initial ClientHello.

> that the pkix path must intersect.

It OUGHT to be a certificate from the forward path that the server sends within the server certificate handshake message.  If we do not have that in the DANE protocol I-D, then we ought to put it in.
[TF] You need something in the security considerations about the selection. 

And clients ought to ensure that they *ALL* use the CA cert from the server's Certificate handshake message when they perform the DANE validation, because only for that cert an synchronous update of the cert itself and the DNS DANE record can be ensured by the server admin.  Distribution of renewed intermediate CA certs to clients will be completely random and diverse -- if at all.
[TF] No - the current wording is correct - build a valid pkix path. The sent set of certificates are useful but as a RP it's down to me to build the path. 

> > but must have the authority to define and enforce the policy by 
> > which all CAs in the PKI must be operated).
>

Unique CA subject names and Name constraints extension can only work in a strictly hierarchical PKI with ONE SINGLE root authority.
[TF] There are shipping pkix clients today that don't have that restriction and work just fine with pkix.

The TLS X.509 PKI has plenty of completely independent, omnipotent root authorities.  The windows trust anchor store maintained by Microsoft for Windows XP contains about 300 individual rootCA certificates today.  And with big companies, such as Microsoft and Google, and government agencies such as DHS operating their own, fully trusted, omnipotent CA, you really ought to link your trust to specific keys rather than to names that can be spoofed by probably several hundred independent organizations around the globe (or anyone that manages to create a valid CA cert und any one of those, either by break-in or by collision precomputation or an MD2 or MD5 preimage attack on one of the tainted old rootCA certs.
[TF] This reiterates the need for a concise list of threats DANE want to mitigate. Many of the threats you mentioned are already mitigated. I am all in favor blocking unmitigated threat but let's not reinvent wheels. Use types 0 and 1 both are dependent real CAs and pkix validation; use type 3 is where the server domain is rolling its own. 

-Martin

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Nov 2011 14:28:04 +0800

Just to clarify: Are you asking for some change to the spec, or just noting an operational risk?

Thanks,
--Richard

On Nov 15, 2011, at 8:08 PM, Trevor Freeman wrote:

> A more stable CA identifier would be a CA’s subject name. This will remain constant as certificates and keys are renewed. You can easily put a hexadecimal encoded subject names in the DNS record and define a new match type. It would also be simple for the CA to publish instructions for creating the DNS record and include the binary encoded subject name on the web page so the domain administrator can simple cut and paste the value when creating the DNS record for their domain and the instructions will not need updating every time they renew their CA certificate.
>  
> End to End Trust Team
> Microsoft Trustworthy Computing  
>

---

From: Trevor Freeman <[email-masked]>
Date: Fri, 18 Nov 2011 21:43:32 +0000

I was asking to add subject name as a selector field

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 10:28 PM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski

Thanks,
--Richard

On Nov 15, 2011, at 8:08 PM, Trevor Freeman wrote:

> Dr Trevor Freeman  Senior Security Strategist End to End Trust Team