<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 21, 2018 at 2:00 AM Karl Auerbach <<a href="mailto:karl@cavebear.com">karl@cavebear.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is a widespread misconception about DNS that it is somehow an <br>
authoritative service, by which I mean that if one says "connect to <br>
X.Y.Z that one is, in fact, going to be connected to X.Y.Z."<br>
<br>
That misconception is partially fueled by the "authoritative answer" bit <br>
in the DNS reply packet.  That bit merely means that the DNS server that <br>
generated the answer got the information from its own configuration <br>
files rather than overhearing it via the kind of DNS hearsay activity <br>
that occurs within DNS order to make DNS more efficient.<br>
<br>
What you might notice is that the internet architecture is missing a <br>
layer.  Way back in the mid 1970's we tried to insert a layer above TCP <br>
and UDP in which there would be an exchange of mutual identification and <br>
credentials proving that identification.  Due to security (or rather <br>
paranoia) concerns of certain US government agencies, that layer never <br>
made it into the internet architecture. And, because such a layer tends <br>
to imply a universal authority over the issuance of those credentials, <br>
there was pushback by those who favored a more diffuse internet with <br>
less centralization.<br>
<br>
Had that layer been present, then when one tries to connect to "X.com" <br>
after that connection had been established at the TCP level there would <br>
have been an exchange that would prove whether the connection had <br>
reached the desired "X.com" or a homographic (typically with intent to <br>
deceive) different target.<br></blockquote><div><br></div><div>Is there a flaw in the argument here?  If the user wants the ASCII <a href="http://x.com">x.com</a>, and queries by typing <a href="http://x.com">x.com</a> by an ASCII keyboard, the DNS server is not likely to misdirect the query to the homographic domain's webspace.  If such a likelihood were to exist, a mutual identification layer would minimise the misdirection. What we are concerned here is more of a situation of a user not knowing that there are two <a href="http://x.com">x.com</a> domains, and not knowing that there are two different webspaces. The user might have been presented with a link to the homographic <a href="http://x.com">x.com</a> which he clicks on, in which case the DNS server would respond by giving the user the answer to the query, which actually happens to be a query for the location of the homographic <a href="http://x.com">x.com</a>.  How would an identification layer have helped in this case?</div><div>   </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
DNS is intended to be a "hinting" system, by which I mean that it gives <br>
information that it (and you) hope is accurate but about which there are <br>
really no guarantees, leaving security as a job for the user to perform.<br>
<br>
We see that job being added in later years via TLS certificate chains <br>
(which are often merely tracked back to a known certificate authority, <br>
which is an inadequate test, but it is the test most often done.)  <br>
DNSSEC also provides tools so that one can know that the DNS data has <br>
not been modified somewhere, but that does not change the nature of the <br>
address information in DNS resource records being merely a hint.<br>
<br>
DNS, because of caching, can never become give ironclad promises that <br>
the result you get from your local DNS resolver is utterly accurate.  <br>
And with the rise of geo-IP based DNS mappings, the definition of <br>
"accurate" becomes somewhat contextual.<br>
<br>
The real answer to homographic deceptions is not really within the realm <br>
of DNS itself, or within ICANN but, rather, would be through the <br>
adoption (at long last) of a proper layer of mutual identification and <br>
authentication either within the transport protocols or between them and <br>
the applications.<br>
<br>
None of this is easy - just look at how SSL evolved, and grew, to become <br>
TLS 1.1, 1.2, 1.3 ...  And nobody has ever said that DNSSEC is simple.<br>
<br>
     --karl--<br>
<br>
<br>
</blockquote></div></div>