Subject: Using DNS system as a Global Root Certificate Authority - possible ?

From: Alexey Eromenko <[email-masked]>
Date: Sat, 26 Dec 2015 22:22:40 +0200

Hi all,

Assume DNS system added a new resource record (RR), which allowed to
publish the public key for a particular FQDN.

How secure or insecure that would be.

Is there a way to *securely* retrieve such information from, for
example, authoritative
DNS server, without any middlebox (such as DNS proxy) mangling it ?

And having TLD DNS servers as the top "Root Certificate Authorities".

so X.509 SSL certificate chain could look like:

- "."
+- ".com."
|--+ "company_abc.com."
|-----+ "www.company_abc.com."
|-----+ "mail.company_abc.com."
|-----+ "ftps.company_abc.com."
etc...

I am not yet sure if this is possible or not, just loud thinking...
In theory, if possible, this should simplify certifications and make
it easier to start an HTTPS server, cutting Verisign and friends out
of the loop.

What do you think ?
-- 
-Alexey Eromenko "Technologov"

---

From: Warren Kumari <[email-masked]>
Date: Sat, 26 Dec 2015 20:29:05 +0000

This is very similar to what the DANE working group is working on -
https://datatracker.ietf.org/wg/dane/charter/

I'd suggest you start with RFC6394, and then RFC6698, followed by RFC7671.

W

---

From: Alexey Eromenko <[email-masked]>
Date: Sat, 26 Dec 2015 22:32:51 +0200

> I'd suggest you start with RFC6394, and then RFC6698, followed by RFC7671.

Thanks.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 Dec 2015 21:52:45 -0500

> it easier to start an HTTPS server, cutting Verisign and friends out

VeriSign Inc. has been out of that loop for 5 years. Their current
business is running core DNS.

One of the issues people don't seem to consider in these schemes is
that merely reducing the number of trusted intermediaries from ~40 to
one doesn't actually remove reliance on trusted third parties, it
merely removes all choice in the matter.

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Dec 2015 22:11:31 -0500

--On Saturday, December 26, 2015 9:52 PM -0500 Phillip
Hallam-Baker <[email-masked]> wrote:

>...
> One of the issues people don't seem to consider in these
> schemes is that merely reducing the number of trusted
> intermediaries from ~40 to one doesn't actually remove
> reliance on trusted third parties, it merely removes all
> choice in the matter.

And even that equation tends to be complicated by the
observation that the trust relationship, as far as certification
of identity is concerned, is with the registrars (and, in some
cases, their agents and resellers) rather than with the
registries.  At that point, the number of trusted intermediaries
gets back toward order 40 or 100, not one, unless the question
is "do you control this domain" rather than "are you who you say
you are".

    john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 Dec 2015 23:11:04 -0500

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 Dec 2015 23:17:43 -0500

[Try the second]

> is "do you control this domain" rather than "are you who you say

The question the WebPKI was designed to answer is 'are you accountable'.

The original brief was to make buying 'stuff' online as safe as in
person at a bricks and mortar store. The basic approach was to
establish a degree of accountability, to make it infeasible for an
attacker to acquire credentials at a rate that would make online fraud
profitable.

One of the things that irritates me is that in the original design,
one of the principal controls used to ensure this goal was met was
revocation, canceling credentials when a party defects. I can't stop a
criminal registering a business but I can pull their certificate in 24
hours.

But the applications don't see the need for this particular control or
at least not in a fashion that is actually effective.. Which is rather
odd since if there actually was a trust crisis in the WebPKI you would
expect that complaints about insufficiently fast revocation would be
at least as loud as complaints about mis-issue.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 27 Dec 2015 06:08:34 +0000

> is "do you control this domain" rather than "are you who you say

It hasn't been "are you who say you are" for quite some time, not
the vast majority of certificates.  EV certificates are rather rare
with the exception of some of largest sites.  Certainly the "Let's
Encrypt" CA will not do anything resembling "are you who you say
you are".

Once the question does boils down to whether the party requesting
the certificate controls the domain (rather than the "brand"), the
only party with an authoritative answer to that question is the
registrar on record for the domain.  

Provided the domain is registrar-locked, DNSSEC gets one about as
much confidence as one can get in answer to this more modest
question.  The party who authorized the DS records via the registrar
has administrative control over the domain's DNS and thus can
delegate authority over any keys published at and below the zone
apex.

This is certainly not a solution to phishing and the like, but it
can provide useful keying material for application protocols.

-- 	Viktor.

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 27 Dec 2015 07:35:41 +0100

On 27 Dec 2015, at 4:11, John C Klensin wrote:

> At that point, the number of trusted intermediaries

It is not that bad as the domain in question is bound to one and only one registrar, which is a mapping that the registry is keeping track of. It is not the case that any registrar can do any change to any domain name.

So, with todays CA system, any CA can sign a cert with any domain name in the CN.

With the DNS and DNSSEC, only registries in the hierarchy from the root can publish the DS, and only one registrar can pass the DS to the parent for publication.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Sun, 27 Dec 2015 12:38:41 +0000

Hi Patrik,

> With the DNS and DNSSEC, only registries in the hierarchy from the root can publish the DS, and only one registrar can pass the DS to the parent for publication.
One would like to believe that name constraints as specified by RFC 5280
could be useful, and yet experience seems to show otherwise.  Perhaps
all is not lost.  My understanding is that the browser crowd in
particular have begun to tighten their requirements for having a CA in
their cache.  At least [1] seems to indicate so.  Name constraints are
an interesting area of perhaps some continued work.  That is- it seems
to me that *all* CAs should have some Name Constraints.  Further, it
also seems to me that very few CA certs should themselves be
self-signed.  Here's the problem, if ever there were a brown field, this
is it.  That requires some serious navigation through the installed base
to make a change.  Along these lines, I think many of us were quite
fascinated by Google's "interaction" with Symantec[2] since it seems to
represent a potential change in the dynamic.

Eliot

[1] https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_3_1.pdf
[2]
http://www.pcworld.com/article/2999146/encryption/google-threatens-action-against-symantec-issued-certificates-following-botched-investigation.html

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 27 Dec 2015 14:42:10 +0100

On 27 Dec 2015, at 13:38, Eliot Lear wrote:

> One would like to believe that name constraints as specified by RFC 5280 could be useful, and yet experience seems to show otherwise.  Perhaps all is not lost.

I do not have much to say part from the interaction I already have had with CA/B Forum[1], and what SSAC view on the difference between DNS and traditional cert structure is[2].

My only point was that it is not at all the case that all registrars can make changes to any subdomain of a domain managed by a registry, which was what I read in what John wrote:

> At that point, the number of trusted intermediaries gets back toward order 40 or 100, not one, unless the question is "do you control this domain" rather than "are you who you say you are".

The registry do keep track of which ones of the registrars can make changes, so not every registrar (i.e. intermediary) can become "trusted".

If I misunderstood what he wrote, my apologies.

   Patrik

[1] SAC-057: https://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf
[2] SAC-075: https://www.icann.org/en/groups/ssac/documents/sac-075-en.pdf

---

From: "John Levine" <[email-masked]>
Date: 27 Dec 2015 20:21:05 -0000

It seems like you're talking past each other here.

>The registry do keep track of which ones of the registrars can make changes, so not every registrar
>(i.e. intermediary) can become "trusted".

That's certainly true, and auth codes make it fairly hard to move a
domain from one registrar to another without inside help from whoever
reads the registrant's e-mail.  On the other hand, there are over 2100
registars in ICANN's list, and even after accounting for 300 that are
Namebright and another 300 that are Netsol, and so forth, there's
probably close to a thousand of them, some of which take security more
seriously than others.

There are certainly registrars who will accept names that are obvious
phishes, there are registrars that can be socially engineered to reset
accounts (I did that once, but it was for a virtuous reason), and so
forth.

Making life even more confusing, while most registries and registrars
strictly limit registrations to anyone whose credit card isn't
rejected, there are a few that make more or less credible attempts to
validate that registrants are who they claim to be.  The sTLDs like
.aero, .travel, .coop and .jobs make some effort to verify that
registrants are members of the relevant community, although the checks
have gotten pretty perfunctory as the money failed to roll in.  (I can
tell you about .aero and .travel.)  The .pro domain was supposed to be
for licensed professional doctors, lawyers, accountants, and
engineers, but a combination of financial problems and registrar
gimmickry made the checks ever feebler until last month they gave up
and now it's purely generic.  The .coop domain checks that you're a
co-op when you register, but never checks again.  One time I noticed
that the registrant for chicken.coop had sold out and wasn't a co-op
any more.  I told the .coop registry, and its head personally thanked
me and asked me to tell her about any other misregistrations I
noticed.  Uh, OK.

In the latest round, .ngo/.ong is making a reasonable attempt to
verify that applicants really are NGOs and that the domain name is
related to the organization name.  I have talked to someone from
Encirca who is working with .bank to do something similar.  It's too
early to find out whether they'll stick with it as their business
models fail, but even if they do persist, there's no DANE version of a
green bar certificate so it's not clear how much good it will really
do.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Dec 2015 18:58:35 -0500

--On Sunday, December 27, 2015 2:42 PM +0100 Patrik Fältström
<[email-masked]> wrote:

> My only point was that it is not at all the case that all
> registrars can make changes to any subdomain of a domain
> managed by a registry, which was what I read in what John
> wrote:
> 
>> At that point, the number of trusted intermediaries gets back
>> toward order 40 or 100, not one, unless the question is "do
>> you control this domain" rather than "are you who you say you
>> are".
> 
> The registry do keep track of which ones of the registrars can
> make changes, so not every registrar (i.e. intermediary) can
> become "trusted".
> 

You did misunderstand the point I was trying to make, which
isn't about "who can make a change" but about "who can put the
name there in the first place", i.e., make an initial
registration.  The issue, as usual, comes down to what threats,
and threat model, one is concerned about.  If, as Victor's note
seems to suggest, the main concern is being able to find a key
with which to encrypt and have some reasonable confidence that
whoever controls the key also controls the relevent domain, then
that is one sort of problem.  If one is concerned about assuring
the user that the site is the intended one and, more to the
point, that anything encrypted to a particular key (whether
found/certified through a "normal" X.509 PKI mechanism or
something DANE-like) will be readable only to the intended
recipient, then that is a different sort of problem.

As a handy real-world example, consider
  ford.com
  fordmotorcompany.com
  fordcarcompany.com

The first two use the same registrar, the same name servers, and
have admin information that points to Ford Motor Company's
corporate HQ information.   The third uses a registrar in
Australia, identifying information that is as hidden as
possible, and a web site that apparently won't expose any
information at all unless one allows it to run scripts on the
local machine.   Nothing prevents such a registration, nor
prevents if from being used in a deceptive manner, nor setting
up keys that are bound to it, except the integrity of the
registrar, and I (much less a typical user) has no practical way
of determining whether "Fabulous.com Pty Ltd." is trustworthy.  

Moreover, were Ford to let "fordmotorcompany.com" lapse --
intentionally or not -- there is nothing in ICANNs systems or
that of Verisign (as the registry operator for COM.) that would
prevent FraudRUs, operating as, or as a reseller of, an
ICANN-accredited registrar, grabbing the name, generating new
keys and/or certs, and committing evil deeds against any user
who stumbled upon that site, perhaps through habits or
established bookmarks.

So, again, it depends on what problem one is trying to solve,
which threat models are of interest, etc.

  best,
    john

> [1] SAC-057:
> https://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf
> [2] SAC-075:
> https://www.icann.org/en/groups/ssac/documents/sac-075-en.pdf

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Dec 2015 10:26:10 +0900

> DNS server, without any middlebox (such as DNS proxy) mangling it ?

You must avoid default port number 53 of DNS.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Dec 2015 10:41:50 +0900

Phillip Hallam-Baker wrote:

> one doesn't actually remove reliance on trusted third parties,

That is, DNSSEC is not secure at all. Just as plain DNS is vulnerable
to active attacks on communication channels, DNSSEC is so on CA
chains.

> Encrypt" CA will not do anything resembling "are you who you say

We don't need CA for encryption, because DH is good enough. Though
DH is vulnerable to active attacks on communication channels, CA is
so on CA chains.

						Masataka Ohta