[dns-operations] DNSSEC deployment incentives

[Phillip Hallam-Baker]

On Thu, Jun 20, 2019 at 2:01 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

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


Thanks.


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

I am making a very pedantic point about the difference between a single
source of naming authority and a single root of trust.



> We could perhaps have multiple signatures on the root zone DNSKEY
> RRset, to shore up trust.
>

I proposed that back in the past. Could make it quorate so that 3 out of 5
apex authorities have to agree.




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

Absolutely. So you start with alice at example.com and she responds with a
message that has a header something like:

SIN: alice at example.com.mm--MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4

And now having completed the introduction, we store the SIN for trust-after
first use.




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

Yup. The Mesh reduces the role of TTPs to be introducers rather than
ongoing participants in every subsequent transaction. Which is exactly what
their role should have been all along.



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

Depends on the context. If I am sending an email to Stuart Cheshire, Trust
after first use is fine. If I am configuring the software updates for
*inside* OSX, then I am going to make sure I check it is the Apple root of
trust. If I am configuring a nuclear power station system, I am going to
chain the device to the local root of trust and then specify the
hand-checked apple root inside it.

The other side of things I have not raised here is blockchain (yes, I know
BTC is a scam etc. but CT is not and the hash chain part is solid). So
www.apple.com.mm--MB5S...
will end up in a block chain pretty quick. So at any given point in time,
there will be a finite number of apple.com trust root possibilities. And
chances are that while we might accept unvalidated first come first served
for the first registration, we are not going to accept a change request
without some sort of evidence it is valid. Which might be signing with the
previous signing key or might be some TTP statement.

But in either case, that nuclear power station isn't going to just take
random updates from the new apple.com without operators etc. being informed
and at that level you are going to have process involved in selecting trust.

And everyone else will likely outsource their trust management to some
company like they do today when they hire an AV company.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190620/cac5accd/attachment.html>