Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

From: Christopher Morrow <[email-masked]>
Date: Tue, 3 May 2011 23:41:27 -0400

first, apologies for lobbing a grenade ~1month ago and getting busy
with work instead of this discussion...

On Thu, Apr 14, 2011 at 11:50 PM, Paul Wouters <[email-masked]> wrote:
>> I’m quite certain this will be DANE’s fate among browsers and other
>> consumer facing applications for self-signed certs, unless DANE builds into
>> its specs some way to
>> distinguish self-signed certs that have gone through an anti-fraud check
>> from those that have not.
>
> fraud detection is really out of scope for dane (both the working group
> and the protocol) It is indeed a real problem that needs to be solved. But
> no easy solution exists that will work for every domain.

I think this is the central point of the entire discussion about
self-signed certs and DANE, and really about DANE as a whole. the
point is NOT about fraud. I said something a few messages ago (to
DANE, which I recognize is ~1month ago...) along the lines of:

I really want a way for a client to validate
that the serivce they connect to (https on www.you.com for example)
is:
 1) the server the service owner expected (and the cusotmer expects)
 2) the service is what the service owner setup (and the customer expects)

(ref: http://www.ietf.org/mail-archive/web/dane/current/msg02390.html)

Thanks Kirk for restarting the discussion.

-Chris

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 May 2011 08:47:33 +0300

> (ref: http://www.ietf.org/mail-archive/web/dane/current/msg02390.html)

I think we'll find that just like in PKIX, it's all about the infrastructure.

If you own www.you.com and your customer knows this, then you can get both (1) and (2) only if both these conditions apply:
1) The DNS replies cannot be spoofed, and
2) Entering records in the DNS is not susceptible to fraud.

DNSSEC may provide the former at some point. I don't think DANE should ever be used for domain-issued certificates without DNSSEC.
The latter is a harder question. If you're google, then you enter your own DNS records, but smaller organizations use some service like GoDaddy to register the domain, add DNS records and everything else required to get a name for your server on the Internet. If I can get GoDaddy to add the records for www.you.com, it's as bad as Comodo issuing me a cert for www.you.com.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 4 May 2011 02:03:00 -0400

> DNSSEC may provide the former at some point. I don't think DANE should ever be used for domain-issued certificates without DNSSEC.

agreed... or 'use of dane implies dnssec is in use as well'

> The latter is a harder question. If you're google, then you enter your own DNS records, but smaller organizations use some service like GoDaddy to register the domain, add DNS records and everythin…

sure, but ... I'm sure that eventually dns service providers
(go-daddy/etc) will have to pony up for some real infrastructure to
support dnssec. pch does this for ~2k/deployment (I think... bill had
some slides at caribnog ~2wks ago that talked about this very problem,
actually). For GoDaddy/etc it's not that hard to implement some secure
interfaces/apis and the backend bits required. They may not do this
TODAY, but they will be driven there by market pressures in the
future. (which seems fine to me)

-Chris

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 4 May 2011 09:14:07 +0200

> If I can get GoDaddy to add the records for www.you.com, it's as bad as Comodo issuing me a cert for www.you.com. 

From the perspective of risks to www.you.com, that's true.  It's better than the traditional CAs (including Comodo) in the sense that GoDaddy is restricted to abusing their customers and not the whole DNS.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 4 May 2011 09:25:51 +0200

> future. (which seems fine to me)

To be clear, there's two attack vectors here:
1. Abuse by people masquerading as a domain owner
2. Abuse by the registrar itself

The former is what you're talking about (if I understand you correctly); the latter is the Comodo-like case that Yoav mentioned, which isn't really helped by more infrastructure.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 May 2011 09:09:57 -0400

On Wed, May 4, 2011 at 3:14 AM, Richard L. Barnes <[email-masked]> wrote:

> > If I can get GoDaddy to add the records for www.you.com, it's as bad as
> Comodo issuing me a cert for www.you.com.
>
> From the perspective of risks to www.you.com, that's true.  It's better
> than the traditional CAs (including Comodo) in the sense that GoDaddy is
> restricted to abusing their customers and not the whole DNS.

You think that is really the case?

I would like to see proof of that assertion. I know that there is a domain
locking system, but I have no idea how it is enforced and have never seen
documentation.

I would not expect the locking mechanism to be particularly strong since (1)
the thin registry has very little information to go on (2) any malicious
behavior can be reversed out easily (3) registrars have a large incentive
not to defect.

Fraudulent issue of certificates has been a much much rarer occurrence than
DNS name hijacking at the registry or registrar.

The plausible objective of this exercise in my view is to allow the domain
name owner to (securely) tell the relying party what the 'best' connection
is to the service.

I see an advantage to using DNSSEC, but I don't see an absolute requirement
because 'best' may turn out to be 'not very good' but it will still be
better than raw TCP/IP without SSL.

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 4 May 2011 15:30:58 +0200

At the very least, the practical barriers are higher.  

For a well-known CA to project false credentials for a domain that will be accepted by clients, all it has to do is issue a cert.  It's technically very simple, and violates no legal agreements except possibly the CA's own CP or CPS.

For someone to use DANE to project false credentials for domain that is not legitimately theirs, they have to hijack a domain, which in itself presents technical and legal challenges, especially if the hijacker is a registrar.  And in addition to the standard domain hijacking challenges, they also have to get a DS record into the appropriate parent zone.

Alternatively, since domain hijacking already exists, you could say that DANE enables you to move from two threats (CA+hijack) to one (hijack).

--Richard

On May 4, 2011, at 3:09 PM, Phillip Hallam-Baker wrote:

> I would like to see proof of that assertion. I know that there is a domain locking system, but I have no idea how it is enforced and have never seen documentation.
> 
> I would not expect the locking mechanism to be particularly strong since (1) the thin registry has very little information to go on (2) any malicious behavior can be reversed out easily (3) registrars have a large incentive not to defect.
>  
> 
> Fraudulent issue of certificates has been a much much rarer occurrence than DNS name hijacking at the registry or registrar.
> 
> 
> The plausible objective of this exercise in my view is to allow the domain name owner to (securely) tell the relying party what the 'best' connection is to the service. 
> 
> I see an advantage to using DNSSEC, but I don't see an absolute requirement because 'best' may turn out to be 'not very good' but it will still be better than raw TCP/IP without SSL. 
> 
> --

---

From: Warren Kumari <[email-masked]>
Date: Wed, 4 May 2011 09:34:31 -0400

> The former is what you're talking about (if I understand you correctly); the latter is the Comodo-like case that Yoav mentioned, which isn't really helped by more infrastructure.

And if your registrar (or anyone else who can masquerade as the domain owner) is out to screw with you, they already have this capability[0] -- they can really easily point NS records at nameservers that they control, serve MX records for your domain at mailservers that they run and apply for a cert, capturing the cookie / token needed to prove control.....

W

[0]: Yes, this may not work for the big brands (that are greylisted by most CAs), and doesn't work for getting an EV cert, but...

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 May 2011 13:09:42 -0400

You have absolutely no knowledge or experience on which to base those
assertions. Nor does anyone else.

Claims such as these are unnecessary and are going to damage DANE.

There is a mechanism already being deployed to provide a control against the
attack stated here.

If you want to make comparisons you should compare like with like, proposed
system with proposed system. DANE does not offer any advantage in this
respect over the CA system + CAA.

Don't spoil a strong case by insisting on making a weak one.

On Wed, May 4, 2011 at 9:30 AM, Richard L. Barnes <[email-masked]> wrote:

> For a well-known CA to project false credentials for a domain that will be
> accepted by clients, all it has to do is issue a cert.  It's technically
> very simple, and violates no legal agreements except possibly the CA's own
> CP or CPS.
>
> For someone to use DANE to project false credentials for domain that is not
> legitimately theirs, they have to hijack a domain, which in itself presents
> technical and legal challenges, especially if the hijacker is a registrar.
>  And in addition to the standard domain hijacking challenges, they also have
> to get a DS record into the appropriate parent zone.
>
> Alternatively, since domain hijacking already exists, you could say that
> DANE enables you to move from two threats (CA+hijack) to one (hijack).
>
> --Richard
>
>
>
> > > If I can get GoDaddy to add the records for www.you.com, it's as bad
> as Comodo issuing me a cert for www.you.com.
> >
> > I would like to see proof of that assertion. I know that there is a
> domain locking system, but I have no idea how it is enforced and have never
> seen documentation.
> >
> > I would not expect the locking mechanism to be particularly strong since
> (1) the thin registry has very little information to go on (2) any malicious
> > Fraudulent issue of certificates has been a much much rarer occurrence
> than DNS name hijacking at the registry or registrar.
> >
> >
> > The plausible objective of this exercise in my view is to allow the
> domain name owner to (securely) tell the relying party what the 'best'
> connection is to the service.
> >
> > I see an advantage to using DNSSEC, but I don't see an absolute
> requirement because 'best' may turn out to be 'not very good' but it will
> still be better than raw TCP/IP without SSL.
> >
> > --

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 5 May 2011 08:48:07 +0200

On 4 maj 2011, at 19.09, Phillip Hallam-Baker wrote:

> There is a mechanism already being deployed to provide a control against the attack stated here.

Could you please elaborate on how this "mechanism" work?

	jakob

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 5 May 2011 09:30:51 +0200

> You have absolutely no knowledge or experience on which to base those assertions. Nor does anyone else.

Ad hominem arguments don't do anybody any good.  Especially ad omnes homines arguments, which honestly seem kind of nonsensical, from an epistemological point of view.

> There is a mechanism already being deployed to provide a control against the attack stated here.

Like Jakob, I would appreciate more detail.  If you're referring to CAA, see below.

> If you want to make comparisons you should compare like with like, proposed system with proposed system. DANE does not offer any advantage in this respect over the CA system + CAA.

In the CA+CAA system, the CAs are still trusted entities.  In the sense of RFC 4949, the client acts on the assumption that the CA does the right thing.  CAA increases the probability that a good CA will do the right thing (clearly a good thing), but it doesn't prevent a bad CA from violating the security model.

The entire point of DANE is to allow clients to limit the scope of this trust using additional information from a domain owner.  In the process, this shifts some of the trust to DNS providers, but as I and others have repeatedly pointed out, DNS providers are *already* trusted entities in the CA system.  

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 May 2011 11:53:15 -0400

CAA is designed as an accountability mechanism. Part of the idea is to
provide an objective criteria for CA malfeasance. One of the problems with
the current situation is that every CA has their own criteria and there are
no objective criteria at all. CABForum is currently looking to change that
with minimum issue criteria, CAA will hopefully be a part of that.

The advantage of an accountability approach is that it fixes the current
system without depending on deployment of new code. The disadvantage is that
accountability is retrospective and thus cannot prevent an attack, it can
merely make the breach less likely.

In the real world, accountability based security can be very effective,
particularly if combined with access controls. Trying to use access controls
or accountability on their own leads to defective security systems. Access
controls are good but they can only be used when the criteria are completely
objective and definable in advance. So they end up being useful only to set
minimum standards. and that in turn leads to people like Bradley Manning
having access to a quarter million diplomatic cables despite being a very
low grade clerk. Accountability controls fail when the expectation of
consequences is low or the consequences themselves are not a deterrent.

Domain name holders can use CAA to tell applications that they must not
accept certificates that do not comply with the Relying Application
Authorization Set.

Now one way that could be implemented would be to put the enforcement code
in every browser. Which would be great as far as I am concerned.

But we still have the question of what the relying party should do. And
there are two options here:

1) Reject the certificate.
2) Tell someone an unauthorized certificate is being presented.
3) Do both

The first of these makes CAA an access scheme as well as being an
accountability scheme. I think that is useful, but it only provides
protection to parties who have upgraded their browser and it does not
provide us with any warning that an attack took place.

Attempting the rejection approach is also subject to blocking of data in the
DNS, requires us to validate the DNS records with DNSSEC and so on. I would
very much like this to happen but I cannot guarantee that it will.

So even though I want client deployment, I base my value proposition on the
second point. I claim that there is a sufficiently high value proposition
for deployment of CAA if the only client enforcement is of the second type
and it is being done by the likes of CAs checking up on each other and the
EFF and so on.

The other point to consider for client deployment (and this would affect
DANE as well) is that all or nothing deployment for a site is actually quite
hard. We faced this with EV when some banks decided that they wanted to
upgrade all their servers to EV at the same time to avoid having some EV and
some not.

Splitting the issue criteria and the enforcement criteria allows for a
phased approach. If a site has had issue criteria specified for a year,
there should be no certs in use that are non-conforming. It is thus much
easier to flip the switch.

So I believe that CAA has a value independent of the use cases and scope
that DANE was intended to address. The question I think we should ask is
whether we can work together or if we are going to have multiple
mechanisms.

When we first proposed CAA the gap between the CAA approach and the DANE
approach was large. I believe that the gap is much smaller now but there are
still important differences that would need to be reconciled.

CAA is architected to conform to the syntactic prejudices of the PKIX world.
I hate ASN.1 as much as anyone. But its the price of freight when dealing
with the X.509 world.

The CAA approach is potentially beneficial to DANE because it is designed in
a way that allows it to start providing value before there is a large base
of browser providers that implement it.

On Thu, May 5, 2011 at 3:30 AM, Richard L. Barnes <[email-masked]> wrote:

> Ad hominem arguments don't do anybody any good.  Especially ad omnes
> homines arguments, which honestly seem kind of nonsensical, from an
> epistemological point of view.

Observing that nobody has experience of smaller DNS registrars operating
DNSSEC is a statement of fact, not an ad-hominem.

Plus ad-hominem is the argument 'Y says X therefore not X'. I am arguing
that your claim should be rejected as heresay. You are making a factual
claim without the experience to back it up. There can be no factual evidence
because the circumstances do not yet exist.

> If you want to make comparisons you should compare like with like,
> proposed system with proposed system. DANE does not offer any advantage in
> this respect over the CA system + CAA.
>
> In the CA+CAA system, the CAs are still trusted entities.  In the sense of
> RFC 4949, the client acts on the assumption that the CA does the right
> thing.  CAA increases the probability that a good CA will do the right thing
> (clearly a good thing), but it doesn't prevent a bad CA from violating the
> security model.
>
> The entire point of DANE is to allow clients to limit the scope of this
> trust using additional information from a domain owner.  In the process,
> this shifts some of the trust to DNS providers, but as I and others have
> repeatedly pointed out, DNS providers are *already* trusted entities in the
> CA system.

Actually CAA allows for both mechanisms. See the above.