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

From: Marc Lampo <[email-masked]>
Date: Wed, 30 Jan 2013 09:11:47 +0100

Hello,

If a correct TLSA record for a domain would mean
there is no warning to the user about : cannot verify certificate
I'm a bit concerned about the value 3 for "Certificate Usage" !

Because there (value is 3), I read :
"This certificate usage is
      sometimes referred to as "domain-issued certificate" because it
      allows for a domain name administrator to issue certificates for a
      domain without involving a third-party CA."

So basically both the certificate (self signed)
and the TLSA record (in the DNS of the domain)
are under control of the owner of the domain name.

But since domain registration can be quite anonymous
doesn't this mean that anybody could, if support for TSLA is widespread,
create https websites that do not cause warning messages to users.

To me it seems that anybody could, kind of, produce his own identity card ?

It that is the case, it would only increase the need for HTTPS inspection
 - "man-in-the-middle" -
in which case the certificate offered to the user will change
and no longer be "in line" with the TLSA record.

Is that interpretation of that value 3, and its consequences, correct ?
Or am I missing something terribly important ?

Kind regards,

Marc Lampo

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Wed, 30 Jan 2013 09:41:06 +0100

> create https websites that do not cause warning messages to users.

It does.

In fact, this is identified as a security consideration (8.1.4) in the RFC.

--
Marco

---

From: Marc Lampo <[email-masked]>
Date: Wed, 30 Jan 2013 09:56:58 +0100

On second reading (of 8.1.4) it does indeed come down to my concern.
Thanks for pointing in that direction !

Marc

On Wed, Jan 30, 2013 at 9:41 AM, Marco Davids (SIDN)
<[email-masked]> wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Tony Finch <[email-masked]>
Date: Wed, 30 Jan 2013 11:49:38 +0000

> create https websites that do not cause warning messages to users.

Yes, that is the desirable outcome.

> To me it seems that anybody could, kind of, produce his own identity card ?

No, the identity is provided by the parent domain.

> It that is the case, it would only increase the need for HTTPS inspection

Why?

> and no longer be "in line" with the TLSA record.

Indeed. DANE will detect the man-in-the-middle attack.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 30 Jan 2013 13:03:58 +0100

> I'm a bit concerned about the value 3 for "Certificate Usage" !
[...]
> To me it seems that anybody could, kind of, produce his own identity card ?

That's how dns is, anybody may register a domain (i.e. create an ID).
I'd interpret the value 3 as the ability, for one who registered a DNS
domain, to prove that it is the same person with the one who operates
the web server.

regards,
Nikos

---

From: Marc Lampo <[email-masked]>
Date: Thu, 31 Jan 2013 19:02:45 +0100

Tony,

how can the *parent* domain provide the identity ?
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 ?

Marc

---

From: Tony Finch <[email-masked]>
Date: Thu, 31 Jan 2013 18:10:59 +0000

> how can the *parent* domain provide the identity ?

It authenticates the owner of the zone, in a similar way that
certification authorities authenticate the recipient of an X.509
certificate. They have about the same amount of connection to the
owners of individual services addressed from the zone.

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 31 Jan 2013 14:13:14 -0500 (EST)

> 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.

> It does not contribute to the identity of the domain holder.

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: Stephen Kent <[email-masked]>
Date: Thu, 31 Jan 2013 15:46:53 -0500

Paul,

I think the simple argument here is that, in the DNS, the parent is
authoritative for (DNS) names it assigns to nodes below it, period.
This differs from the browser PKI model (let's not dump on X.509 for this
truly awful PKI design), where any TA can issue a cert for any name.

Steve

---

From: Paul Wouters <[email-masked]>
Date: Thu, 31 Jan 2013 17:32:12 -0500 (EST)

> truly awful PKI design), where any TA can issue a cert for any name.

But it is not different at all, _because_ the parent or child DNS admin
can point the webserver elsewhere and get a new certificate issued.

That cert was never safe from any DNS admin control before TLSA, and not
after TLSA. So I disagree with Marco's claim that DNSSEC/TLSA changed
something.

Paul