<div dir="ltr"><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><font color="#000000"><span style="font-size:13.3333px">UDF</span></font> 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:<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4</span> <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So now lets use it in an application</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">alice@example.com.mm--<span style="color:rgb(0,0,0);font-size:13.3333px">MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4</span> <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">You can't send email to that address unless your application knows that it should interpret mm--<span style="color:rgb(0,0,0);font-size:13.3333px">MB5S-... as a strong internet name and apply a security policy that has the fingerprint </span><span style="color:rgb(0,0,0);font-size:13.3333px">MB5S-...</span></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">Or maybe you do want backwards compatibility:</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default" style="font-size:small">alice@mm--<span style="color:rgb(0,0,0);font-size:13.3333px">MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4</span>.<a href="http://example.com">example.com</a></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This email will work fine if <a href="http://example.com">example.com</a> has the necessary redirects.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The same approach can be used to eliminate the need for a third party root of trust in any Internet application context.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One use for this approach would be that Alice might put her strong internet name email address in her linked in profile. <span style="color:rgb(0,0,0);font-size:13.3333px">MB5S-... might then be a key that validates her Signal, Whatsapp, etc. contact addresses.</span></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[*] 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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 19, 2019 at 8:28 PM Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 19 Jun 2019, Paul Vixie wrote:<br>
<br>
> while i don't love the single-root trust system of DNSSEC<br>
<br>
Please review <a href="https://tools.ietf.org/html/draft-pwouters-powerbind-02" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-pwouters-powerbind-02</a> that addresses that issue.<br>
<br>
Paul<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
dns-operations mailing list<br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div>