Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ?

From: Marc Lampo <[email-masked]>
Date: Fri, 1 Feb 2013 16:40:45 +0100

what I understand in this reply is the concern about the validity of
SSL certificates
handed out by CA's.  I acknowledge that concern, that I share with you.

I am however concerned with the suggestion to cover "it" with all DNS means !
Because I know for sure that registering a domain can be and is quite
anonymous as well.
For the registrars "selling names under a top-level-domain",
this is only a low cost product, sometimes given away for free (in
return for webhosting),
with very little control of the identity of the registrant.

And once there is delegation, the registrant could then generate
self-signed ceriticates,
publish TLSA record with type 3 : "this self-signed certicate is OK,
don't alert the user".
Hence the original subject : "produce one's own identity card".

When I first read the draft, I though this was about
"informing the user which CA was used for my official certificate".
So, if a trusted CA is hacked and gives out an otherwise valid
certifate for my domain,
but to an organisation which is not "me",
I can still inform my visitors which CA *I* chose for my real certicate.
But that seems to be the CAA RR, recently published ...

Kind regards,

Marc (without trailing 'o' ;-)

On Thu, Jan 31, 2013 at 8:13 PM, Paul Wouters <[email-masked]> wrote:
> On Thu, 31 Jan 2013, Marc Lampo wrote:
>
>> how can the *parent* domain provide the identity ?
>
>
> He who controls the spice, controls the universe! Oh wait, I mean to say
> the parent can already take control of all of its children, so yes in
> the DNS world, the "ID card" analogy does not quite work. (In the X509
> world, the ID card analogy compares perhaps to US drivers licenses, each
> state looks different so no one can really verify the authenticity
> anymore)
>
> So, parent DNS controls child DNS. Child DNS controls where it points
> the webserver at. So no new "vulnerabilities" are introduced by putting
> trust in selfsigned certs anchored to DNS.
>
>
>> The TLSA record is content of the domain (not the parent) is it ?
>> I know that, for DNSSEC, the parent signs the domains public key
>> information (DS),
>> but that is purely DNSSEC.
>> It does not contribute to the identity of the domain holder.
>> Or what am I missing ?
>
>
> DNS does not provide "identity" information. But "Domain Validated" (DV)
> certificates don't either. Anyone controlling example.com acn get a DV
> cert issued by the CABforum members without any identity check.
>
> If you are talking about EVcerts, apparently CABforum people do more
> checks before handing this out, allegedly doing identity validation,
> so I would need to provide some Example Inc. paperwork before they
> should give me an EV cert. This part cannot be replaced with TLSA
> records, although TLSA records can contradict (rogue) EV certs.
>
> Paul

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 1 Feb 2013 08:25:39 -0800

> But that seems to be the CAA RR, recently published ...

The primary purpose of the CAA RR is to allow for CAs "to implement additional controls to reduce the risk of unintended certificate mis-issue" (quote from RFC 6844). Although it may be used for certificate evaluators (e.g. the browser) as well, that is not the primary purpose.

	jakob

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Feb 2013 08:34:52 -0800

> Hence the original subject : "produce one's own identity card".

Anyone, at any time, can produce an identity card for themselves. Kids in the US who want to drink alcohol before they are 21 have known this for decades. The trick is to get others to believe it.

The current web PKI allows any of hundreds of CAs to act as the ultimate authority for the ID. DANE allows a domain owner to use the DNSSEC trust anchor as the ultimate authority for the ID.

> But that seems to be the CAA RR, recently published ...

It would only seem that if you didn't read the RFC. CAA is not for informing visitors about your CA, it is for informing diligent CAs about your CA.

--Paul Hoffman

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Feb 2013 17:36:47 +0100 (CET)

Jakob Schlyter wrote:
>
> Marc Lampo <[email-masked]> wrote:
> >
> The primary purpose of the CAA RR is to allow for CAs "to implement
> additional controls to reduce the risk of unintended certificate
> mis-issue" (quote from RFC 6844). Although it may be used for
> certificate evaluators (e.g. the browser) as well, that is not the
> primary purpose.

TLS clients, including browsers, MUST NOT look at DNS CAA records!!

Quoting from rfc6844:

                                          Relying Applications MUST
   NOT use CAA records as part of certificate validation.

The content of the CAA is information directed to CAs about permissible
issuers for _new_ certificates.  They are not necessarily related to
the issuer of any currently used certificates, any may differ,
i.e. a Web Server might be currently using a certificate from
an issuer for which no CAA record exists, and TLS clients (Relying Parties)
MUST NOT check this during certificate path validation.

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Fri, 1 Feb 2013 12:41:54 -0500 (EST)

> Because I know for sure that registering a domain can be and is quite

and getting a DV cert issued from a random SSL provider from that point
onwards is just as anonymous. It does not even require money if you just
want it for a few months.

So yes, the collective "we" have moved from "click the selfsigned cert
warning away" to "be aware of frauds when the URL bar isn't green".

Are you suggesting we bring the popups back for non-green URLs in
browsers? If not, what _do_ you suggest we do?

Paul

---

From: Marc Lampo <[email-masked]>
Date: Mon, 4 Feb 2013 20:42:59 +0100

Indeed, thanks for pointing out, CAA is meant to be used at
certificate issue time;
an oversight of mine.

For the TLSA record, upon rereading that RFC, I think the values 0 and 1 for
the certificate usage field are OK.

Together with an official CA, the domain administrator can, via
another way (DNS-DNSSEC)
inform the users of the CA that has been chosen for the domain.

There are a number of cases were this does not contribute to security
 (malicious user who obtained a certificate and publishes
corresponding TSLA RR);
but good/genuine users can inform the users of the CA that has been chosen.
 If there is support at client side, they now have the capability to
detect a "weird" certificate :
 apparently correct, by trusted CA, but not chosen by the domain (cfr
Diginotar case)

However values 2 and 3 introduce a way to use DNS only.
 The certificate is still used - because is is simply a built-in and
widely supported way to encrypt -
 but the "who has created the certificate" is irrelevant, since, via
the TLSA record with given valuers,
 the domain admin can simply OK whatever certificate generated locally.
This shift (in who provides identity) from "only trusted CA" to "only
via DNS info"
 is, in my opinion, a bad idea.
 Probably, as Paul Wouters contributed in this conversation,
  it is possible to obtain genuine certificates from not so good CA's,
 but a complete shift to DNS only is no improvement.
 As it is possible to register domain names with hardly any identity
verification as well.

Kind regards,

Marc

---

From: Stephen Kent <[email-masked]>
Date: Mon, 04 Feb 2013 15:12:13 -0500

Paul,

The assertion by the parent relates to the DNS name, nothing more. But, that
name is under the control of the appropriate entity, in the DNS context. 
More
importantly, that entity is limited in  the range of DNS names for which it
can create a signed assertion, unlike in the browser PKI context. So, I 
think
that makes the DANE approach to binding a public key to a web site DNS name
much more secure than the current browser PKI approach.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Feb 2013 12:26:26 -0800

> the certificate usage field are OK.

They are all "OK". If you don't like one of the usage types, don't use it.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Feb 2013 00:18:01 -0500 (EST)

> This shift (in who provides identity) from "only trusted CA" to "only

There _is_ no shift. Whoever controls the DNS can do either things:

- Create MX to receive email for the domain, and get a valid CA signed
   cert.
- Create their own self signed cert, and put in a TLSA record.

"Only trusted CA" is a lie. If I control your DNS, I can get a "trusted
CA" certificate too.

> but a complete shift to DNS only is no improvement.

This has nothing to do with "not so good CAs". If I control you DNS, I
can get any "good CA" to issue a cert for me.

And again, this _is_ different for EV certs but they are rare,
expensive and per definition won't scale.

Paul

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Feb 2013 08:15:50 -0800

>  (malicious user who obtained a certificate and publishes

It's worth noting that in order to do the above, you only had to trick a
CA into issuing a cert *and* you must have control over the DNS for the
domain, whereas before you had to only trick a CA into issuing a cert.
So the bar has been raised for sites that have published a TLSA record.
So it certainly does contribute to security as it increases the
infrastructure that an attacker must target to succeed in a take-over.
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/