[dns-operations] DNSSEC deployment incentives
Viktor Dukhovni
ietf-dane at dukhovni.org
Thu Jun 20 17:53:16 UTC 2019
On Thu, Jun 20, 2019 at 12:47:26PM -0400, Phillip Hallam-Baker wrote:
> I have a different approach to avoiding the single root issue which I think
> much simpler for the devices that would make use of it.
For the record, I am rather sympathetic to your work on MM, and
hope to see it succeed.
> My private root of trust key is not a DNSSEC key because I want to use it
> as my root of trust for everything including SSH, OpenPGP, PKIX, etc.
>
> So now lets use it in an application
>
> alice at example.com.mm--MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
And this is indeed appropriate/necessary for peer-to-peer security,
I don't need/want ICANN to introduce me to my family and friends.
However, for scalable Internet-scale any-to-any communicaton between
browsers to websites, MTAs to MTAs, ... where the party to be
authenticated is a service at a DNS domain, the one DNS root is
AFAIK about the best we can do.
We could perhaps have multiple signatures on the root zone DNSKEY
RRset, to shore up trust.
Other than that, when my peer is service at domain for some domain
I've no prior contact with (or don't contact often enough to make
stateful pseudonimity, i.e. some sort of "pinning", practical) then
I'm going to rely on introduction at Internet scale, which means
following from the root down to the domain, because that's all a
DNS domain is, a name delegated hierarchically from the root.
In your work on the mesh, email to:
alice at example.com.mm--MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
is not email to "whoever happens to have taken control of that
mailbox today", but rather email to "the alice who shared that
policy fingerprint", presently reachable via "alice at example.com".
But MM generalizes PGP, and also supports more hierachical models.
So that's great, but at the end of the day, if the Internet is not
going to fragment into islands of security, the ICANN root is a
necessary introducer.
How is a user to know that
www.apple.com.mm--MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4
is the right secure URL for apple.com? For working at Internet
scale, unless all Internet communication starts with word of mouth
introduction, at some point there needs to be an internet-scale
directory, thus ICANN. Or does each browser vendor curate the
secure URLs for every domain you can reach from via that browser?
--
Viktor.
More information about the dns-operations
mailing list