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

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

Hi Richard,

You description does not match what use type =0

It would have been helpful if document somewhere the threats you want to  mitigate, vs. the threats you are not mitigating as it helps such discussions. 

We need clarity around what threats DNSSEC addresses and what value DANE adds over just DNSSEC. The threats highlighted in 6394 is a DNS name resolver attack which is intrinsically blocked by DNSSEC. Today, DNS based attacks are fairly cheap and easy to use. 

Getting a bogus EE certificate is a district threat from a CA certificate.  I can stop trust in a CA certificate issued from an instance of a CA by constraining the path length of the CA certificate which is what is happening today. This mitigates the threat of an attacker getting a CA certificate from that CA.

Equally since the relying party is using full pkix validation they can impose restrictions on the set of certificate policies - which again make it impossible for any CA to issue a certificate with the right name and the right policy since the policy is constrained from the root CA down. 

There are these many reasons why when the client tries to validate the certificate issued by the bogus CA with the same name as published by DANE, why pkix will reject the certificate path based on the relying party trust policy. 

You may want to clarity what threats you are anticipating for how the attacker mounts the mitm attack with DNSSEC since you now have the right ip addresses.  

Trevor

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Thursday, November 17, 2011 9:54 AM
To: Trevor Freeman
Cc: Adam Langley; [email-masked]
Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski

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:

> 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
> 
> 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 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

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

> You description does not match what use type =0

Sure it does.  Let me clarify:

1. example.com provisions a DANE record saying that any cert must chain through "CN=super-trusted-ca.com"

2. Nefarious attacker generates a CA cert under a well-known TA with his own key pair and "CN=super-trusted-ca.com", and an EE cert under this CA.

In that case, the cert matches the type=0 constraint, but it's clearly still bogus.  And the client still gets MitM'ed.

> There are these many reasons why when the client tries to validate the certificate issued by the bogus CA with the same name as published by DANE, why pkix will reject the certificate path based on…

So the above attack is not viable if the RP/client imposes path length constraints on the TAs in its trust store.  Are you aware of clients that actually do this in practice?  How do they decide what constraints to apply, given that they don't know how the CAs they're trusting are structuring their operations?

> You may want to clarity what threats you are anticipating for how the attacker mounts the mitm attack with DNSSEC since you now have the right ip addresses.  

For example: 
<http://en.wikipedia.org/wiki/ARP_spoofing>
<http://en.wikipedia.org/wiki/IP_hijacking>

--Richard

---

From: Trevor Freeman <[email-masked]>
Date: Fri, 18 Nov 2011 22:15:53 +0000

Richard,

Lets get back to the threats because not all certificates are as easy to generate and be trusted

Threat

1.       Attacker socially engineers CA to provide a false  identity verification

2.       Attacker gets attack code into CAs environment and generates end user certificate of their choice

3.       Attacker gets attack code into CA environment and generates a CA certificate of their choice

4.       Attacker bribes a CA employee to get certificate of their choice.

We have seen examples of #1 and #2 with end entity certificates and they are only partially mitigated by better security and policy enforcement.

#1 has not so far succeeded with a CA certificate because the checks are much more extensive. We are typically talking about certificates which cost tens of thousands of dollars or more each. It's not a simple, paste your request and give us your credit card transaction like it is for SSL certificates.

 #3 has been mitigated by the public CA using path length constraints for online CAs. This is typical by putting the path length = 0 into the online CAs certificates but sometimes its higher up if the chin is longer. Pkix validation means no CA certificate issued by a CA with path length = 0 would be trusted.

#4 is still possible but that open up bribes to DNS registrars as well.

So given getting an attacker cannot get a CA certificate by #3, we are left with #1 and #4. Both #1 and #4  are at least one to two orders of magnitude harder than #2 and both are viable against DNNSEC as well

Many organizations would accept such a trade for a more robust deployment. I would not advocate subject name matching for end entity certificate because of the feasibility of #2, but it is a reasonable option for a CA certificate.

Trevor

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

For example:

--Richard

> From: Richard Barnes [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

> Cc: Adam Langley; [email-masked]<mailto:[email-masked]>

> 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

> 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

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of

>> Adam Langley

>> Cc: [email-masked]<mailto:[email-masked]>

>> On Tue, Nov 15, 2011 at 7:08 AM, Trevor Freeman <[email-masked]<mailto:[email-masked]>> wrote:

>> * The leaf doesn't include an Authority Key Identifier, but incudes

>> an AIA URL for I1

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

>> [email-masked]<mailto:[email-masked]>

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Nov 2011 23:57:21 +0100 (MET)

Trevor Freeman wrote:
> #3 has been mitigated by the public CA using path length constraints
> for online CAs. This is typical by putting the path length = 0 into
> the online CAs certificates but sometimes its higher up if the chin
> is longer.  Pkix validation means no CA certificate issued by a CA
> with path length = 0 would be trusted.

Some 9 years ago it was discovered that MSIE would not check for
"BasicConstraint cA=TRUE" in a certificate before accepting it as
a CA cert in a certification path, therefore all End-Entity certs
were treated equivalent to real CA certs:

  http://www.thoughtcrime.org/ie-ssl-chain.txt

In 2011 it was reported that none of the existing versions of
Apple iOS was having the exact same defect and would accept
End-Entity certs as valid CA certs in certification paths.

  http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0228

Your claim about PathLenConstraint=0 saving the day,
reminds me of a quote from a movie:

  Did you see the body? Assumption is the mother of all F*** UPS! 

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Nov 2011 22:48:54 -0500

Really, this one way 'lets beat up on PKIX but nobody can ever question
DNSSEC' is getting tiresome. What you want is to have free hits on PKIX
then run hide behind mommy when your scheme is considered.

People screw up the implementation of all crypto code. Some people will
screw up the implementation of DANE as well, if you are lucky enough for
people to implement it.

-- 
Website: http://hallambaker.com/

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Nov 2011 15:42:28 +0100 (MET)

Phil,

You're entirely missing the point.

The PathLenConstraints is a pure business-model control in PKIX,
it is *not* a security control.  As Steve Kent keeps pointing out,
X.509v3&PKIX design boldly assumes that properly managed CAs simply
can not be subverted.  The possibility to issue yourself CRL and OCSP
signer certs *and* control the locations that will be checked for
revocations of such certs only through the OCSP-AIA and CRL-DP elements
of the (fraudulent) end-entity cert itself will reliably subvert revocation.

But if CAs want to employ a original business model control such as
PathLenConstraint=0 as a security control, they should probably first
get some idea whether that feature is actually implemented
in the installed base.

BasicConstraint "cA=TRUE" is a security control, but anyhow at least
two commercial CAs managed to issue themselves CA-certs without it,
one of them (Entrust) even got it accepted and distributed by
Browser vendors (OUCH!), and two vendors managed to ship without support
for it (Microsoft in 1998 -- fixed 2002, Apple in 2007 -- fixed 2011).

If a CA actually cared about security, it would have been a trivial
no-brainer for them to configure a TLS server with various "demo-fraudulent"
TLS credentials on non-standard ports signed under one of their official
CA certs so that novice customers could check their fancy devices
against it just by clicking an URL the CA's web page.

It is even possible to use Flashcrowd/crowdsourcing to determine
within hours whether the installed base supports your assumptions about
security control.  Example for a flashcrowd:
http://www.theregister.co.uk/2009/12/07/darpa_balloon_hunt_result/

Apple shipped 4 generations of iPhones and 2 generations of iPads over
4 years (some 50 million gadgets) without (functioning) X.509v3
BasicConstraints security controls, and it required a curious
security researcher to find out that the security controls, that
commercial CAs blindly rely on, were not working on that Apple gear.

Had any of the commercial CAs any such test-pages with "demo-fraudulent"
certs then some curious folks (potentially even Apple-fans working for CAs)
had stumbled upon this problem during the first year of its shipment.

-Martin

Phillip Hallam-Baker wrote:
> --f46d044472bb2c73d804b20e553f
> Content-Type: text/html; charset="ISO-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> Really, this one way &#39;lets beat up on PKIX but nobody can ever question=
>  DNSSEC&#39; is getting tiresome. What you want is to have free hits on PKI=
> X then run hide behind mommy when your scheme is considered.<div><br></div>
> <div>People screw up the implementation of all crypto code. Some people wil=
> l screw up the implementation of DANE as well, if you are lucky enough for =
> people to implement it.</div><div><br><br><div class=3D"gmail_quote">On Fri=
> , Nov 18, 2011 at 5:57 PM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D"mail=
> to:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex;">Trevor Freeman wrote:<br>
> &gt;<br>
> &gt; Lets get back to the threats because not all certificates are as<br>
> &gt; easy to generate and be trusted<br>
> &gt;<br>
> &gt; 3. =A0Attacker gets attack code into CA environment and generates<br>
> &gt; =A0 =A0 a CA certificate of their choice<br>
> &gt;<br>
> &gt; #3 has been mitigated by the public CA using path length constraints<b=
> r>
> &gt; for online CAs. This is typical by putting the path length =3D 0 into<=
> br>
> &gt; the online CAs certificates but sometimes its higher up if the chin<br=
> >
> &gt; is longer. =A0Pkix validation means no CA certificate issued by a CA<b=
> r>
> &gt; with path length =3D 0 would be trusted.<br>
> <br>
> Some 9 years ago it was discovered that MSIE would not check for<br>
> &quot;BasicConstraint cA=3DTRUE&quot; in a certificate before accepting it =
> as<br>
> a CA cert in a certification path, therefore all End-Entity certs<br>
> were treated equivalent to real CA certs:<br>
> <br>
>  =A0<a href=3D"http://www.thoughtcrime.org/ie-ssl-chain.txt" target=3D"_bla=
> nk">http://www.thoughtcrime.org/ie-ssl-chain.txt</a><br>
> <br>
> In 2011 it was reported that none of the existing versions of<br>
> Apple iOS was having the exact same defect and would accept<br>
> End-Entity certs as valid CA certs in certification paths.<br>
> <br>
>  =A0<a href=3D"http://web.nvd.nist.gov/view/vuln/detail?vulnId=3DCVE-2011-0=
> 228" target=3D"_blank">http://web.nvd.nist.gov/view/vuln/detail?vulnId=3DCV=
> E-2011-0228</a><br>
> <br>
> <br>
> Your claim about PathLenConstraint=3D0 saving the day,<br>
> reminds me of a quote from a movie:<br>
> <br>
>  =A0Did you see the body? Assumption is the mother of all F*** UPS!<br>
> <br>
> <br>
> -Martin<br>
> _______________________________________________<br>
> dane mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
> tps://www.ietf.org/mailman/listinfo/dane</a><br>
> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Website: <a =
> href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
> </div>
> 
> --f46d044472bb2c73d804b20e553f--
>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 21 Nov 2011 12:16:12 -0500

This seems to be the last message in the thread before the CA bashing started, so forking here....

I am having somewhat of a hard time following this thread -- it seems to be slightly unclear what *exactly* is being proposed, so I am asking that, if folk are still interested in this topic, they provided proposed text[0]. If not, we are dropping it.

W

[0]: Proposed text suitable for a draft, not inflammatory text couched in RFCese...

On Nov 18, 2011, at 5:15 PM, Trevor Freeman wrote:

> #1 has not so far succeeded with a CA certificate because the checks are much more extensive. We are typically talking about certificates which cost tens of thousands of dollars or more each. It’s not a simple, paste your request and give us your credit card transaction like it is for SSL certificates.
> >> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >> Adam Langley

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Nov 2011 21:29:39 +0100 (MET)

Trevor Freeman wrote:
>
> Pkix validation means no CA certificate issued by a CA

   http://tools.ietf.org/html/rfc5280#section-4.2.1.9

   A pathLenConstraint of zero indicates that no non-self-issued
   intermediate CA certificates may follow in a valid certification path. 

A self-issued CA cert would be just fine for an attacker.

> screw up the implementation of DANE as well, if you are lucky enough for

Trevor assumptions rely on a very specific form of PKIX NON-compliance.
That is not to be recommended.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Nov 2011 22:04:33 +0100 (MET)

Warren Kumari wrote:
> 
> This seems to be the last message in the thread before
> the CA bashing started, so forking here....
> 
> I am having somewhat of a hard time following this thread -- it seems
> to be slightly unclear what *exactly* is being proposed, so I am asking
> that, if folk are still interested in this topic, they provided
> proposed text[0]. If not, we are dropping it.

Trevor said that PKIX CA certs can not be reliably identified with
a certificate hash for TLSA usage type 0.

I agree with this observation.  There are a *some* TLS peers
that do perform certificate path discovery when processing the
peers Certificate handshake message.  While this is clearly not
something that the TLS spec suggests, it is something that a number
of PKIX folks *want* to happen.  AFAIK, Microsoft's SChannel does it
and Opera does it.  So DANE inevitably will have to account for it.

PKIX cert path discovery may cause *any* and all except the end-entity
cert conveyed by Certificate handshake message to be replaced by
CA certs with a different lifetime or arbitrary cross-CA certs
before entering the PKIX certificate path validation algorithm.

If TLSA usage type 0 tries to match the certificate hash of
a CA cert that has passed PKIX certificate path validation,
it may no longer find that CA cert in that path, even though
it was conveyed in the forward path of the Certificate handshake
message.

Matching of the end-entity cert (TLSA usage type 1) does not have
that problem, and TLSA usage type 0 when limited to the spki
(subject public key info) of the CA that directly signed the
TLS servers certificate would also not have such a problem
-- and both are reliably predictable by the TLS server admin.

Trying to cling to a specific CA cert seems to interfere with
PKIX design and CA operations.  Intermediate CA certs of
commercial CAs usually have a shorter lifetime.  In case they're
renewed (same keypair, same Subject, new lifetime) rather than
moving to a different CA cert (new keypair, new Subject, new lifetime),
the distribution of the renewed intermediate CA cert to RPs and its
use during PKIX certificate path validation will be non-predictable
to the server admin.  Use of cross-certification rather than
acceptance of seperate trust anchor by a fraction of the TLS clients
can also lead to the use of CA (cross-)certs in a path that the
TLS server admin can hardly predict.

-Martin