[dns-operations] DNSSEC deployment incentives

[Phillip Hallam-Baker]

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.

UDF is simply an improved fingerprint that uses Base32 encoding and
provides protection against semantic substitution attacks. Let us say that
the UDF of my private root of trust key is:

MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4

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

See what I did there? This is a legitimate email address with a legitimate
DNS name. Just one that ICANN will never issue a TLD for (it is prefixed
for a start).

You can't send email to that address unless your application knows that it
should interpret mm--MB5S-... as a strong internet name and apply a
security policy that has the fingerprint MB5S-...

Or maybe you do want backwards compatibility:

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

This email will work fine if example.com has the necessary redirects.


The same approach can be used to eliminate the need for a third party root
of trust in any Internet application context.

The way that I intend to use them in the Mesh is that I will use regular
DNS names for discovery but store the strong internet name versions when
those are available.

One use for this approach would be that Alice might put her strong internet
name email address in her linked in profile. MB5S-... might then be a key
that validates her Signal, Whatsapp, etc. contact addresses.



[*] One of my big problems with ICANN is that they never actually respond
to concerns about their possible defection. They dismiss them with faux
indignation. And no, I know their protocols are not adequate to defend
against some of the attacks that become likely when you make it the root of
trust for the entire Internet because they are using the same systems we
developed for VeriSign back in the day. VeriSign Class 3 key management was
never intended to provide a robust defense against Nation state actor
attacks. Only a nation state actor can provide security against another
nation state actor.

On Wed, Jun 19, 2019 at 8:28 PM Paul Wouters <paul at nohats.ca> wrote:

> On Wed, 19 Jun 2019, Paul Vixie wrote:
>
> > while i don't love the single-root trust system of DNSSEC
>
> Please review https://tools.ietf.org/html/draft-pwouters-powerbind-02
> that addresses that issue.
>
> Paul
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190620/930c3c95/attachment.html>