<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2019 at 2:01 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org" target="_blank">ietf-dane@dukhovni.org</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 Thu, Jun 20, 2019 at 12:47:26PM -0400, Phillip Hallam-Baker wrote:<br>
<br>
> I have a different approach to avoiding the single root issue which I think<br>
> much simpler for the devices that would make use of it.<br>
<br>
For the record, I am rather sympathetic to your work on MM, and<br>
hope to see it succeed<span class="gmail_default" style="font-size:small">.</span></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Thanks.</div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-size:small"></span>> My private root of trust key is not a DNSSEC key because I want to use it<br>
> as my root of trust for everything including SSH, OpenPGP, PKIX, etc.<br>
> <br>
> So now lets use it in an application<br>
> <br>
> alice@example.com.mm--MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4<br>
<br>
And this is indeed appropriate/necessary for peer-to-peer security,<br>
I don't need/want ICANN to introduce me to my family and friends.<br>
<br>
However, for scalable Internet-scale any-to-any communicaton between<br>
browsers to websites, MTAs to MTAs, ... where the party to be<br>
authenticated is a service at a DNS domain, the one DNS root is<br>
AFAIK about the best we can do.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I am making a very pedantic point about the difference between a single source of naming authority and a single root of trust.</div><div class="gmail_default" style="font-size:small"><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We could perhaps have multiple signatures on the root zone DNSKEY<br>
RRset, to shore up trust.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I proposed that back in the past. Could make it quorate so that 3 out of 5 apex authorities have to agree.</div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Other than that, when my peer is service@domain for some domain<br>
I've no prior contact with (or don't contact often enough to make<br>
stateful pseudonimity, i.e. some sort of "pinning", practical) then<br>
I'm going to rely on introduction at Internet scale, which means<br>
following from the root down to the domain, because that's all a<br>
DNS domain is, a name delegated hierarchically from the root.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Absolutely. So you start with <a href="mailto:alice@example.com" target="_blank">alice@example.com</a> and she responds with a message that has a header something like:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">SIN: alice@example.com.mm--MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4</div><br></div><div><div class="gmail_default" style="font-size:small">And now having completed the introduction, we store the SIN for trust-after first use.</div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In your work on the mesh, email to:<br>
<br>
alice@example.com.mm--MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4<br>
<br>
is not email to "whoever happens to have taken control of that<br>
mailbox today", but rather email to "the alice who shared that<br>
policy fingerprint", presently reachable via "<a href="mailto:alice@example.com" target="_blank">alice@example.com</a>".<br>
<br>
But MM generalizes PGP, and also supports more hierachical models.<br>
So that's great, but at the end of the day, if the Internet is not<br>
going to fragment into islands of security, the ICANN root is a<br>
necessary introducer.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
How is a user to know that <br>
<br>
<span class="gmail_default" style="font-size:small"></span>www.apple.com.mm--MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4<br>
<br>
is the right secure URL for <a href="http://apple.com" rel="noreferrer" target="_blank">apple.com</a>? For working at Internet<br>
scale, unless all Internet communication starts with word of mouth<br>
introduction, at some point there needs to be an internet-scale<br>
directory, thus ICANN. Or does each browser vendor curate the<br>
secure URLs for every domain you can reach from via that browser?<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 <span class="gmail_default"></span>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 <a href="http://apple.com">apple.com</a> 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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But in either case, that nuclear power station isn't going to just take random updates from the new <a href="http://apple.com">apple.com</a> without operators etc. being informed and at that level you are going to have process involved in selecting trust.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And everyone else will likely outsource their trust management to some company like they do today when they hire an AV company.</div></div></div>