[At-Large] IDN Variants in the market place

sivasubramanian muthusamy 6.internet at gmail.com
Fri Jul 20 22:20:25 UTC 2018


On Sat, Jul 21, 2018 at 2:00 AM Karl Auerbach <karl at cavebear.com> wrote:

> There is a widespread misconception about DNS that it is somehow an
> authoritative service, by which I mean that if one says "connect to
> X.Y.Z that one is, in fact, going to be connected to X.Y.Z."
>
> That misconception is partially fueled by the "authoritative answer" bit
> in the DNS reply packet.  That bit merely means that the DNS server that
> generated the answer got the information from its own configuration
> files rather than overhearing it via the kind of DNS hearsay activity
> that occurs within DNS order to make DNS more efficient.
>
> What you might notice is that the internet architecture is missing a
> layer.  Way back in the mid 1970's we tried to insert a layer above TCP
> and UDP in which there would be an exchange of mutual identification and
> credentials proving that identification.  Due to security (or rather
> paranoia) concerns of certain US government agencies, that layer never
> made it into the internet architecture. And, because such a layer tends
> to imply a universal authority over the issuance of those credentials,
> there was pushback by those who favored a more diffuse internet with
> less centralization.
>
> Had that layer been present, then when one tries to connect to "X.com"
> after that connection had been established at the TCP level there would
> have been an exchange that would prove whether the connection had
> reached the desired "X.com" or a homographic (typically with intent to
> deceive) different target.
>

Is there a flaw in the argument here?  If the user wants the ASCII x.com,
and queries by typing x.com 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 x.com domains, and not
knowing that there are two different webspaces. The user might have been
presented with a link to the homographic x.com 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 x.com.  How would an identification layer have helped in this
case?


>
> DNS is intended to be a "hinting" system, by which I mean that it gives
> information that it (and you) hope is accurate but about which there are
> really no guarantees, leaving security as a job for the user to perform.
>
> We see that job being added in later years via TLS certificate chains
> (which are often merely tracked back to a known certificate authority,
> which is an inadequate test, but it is the test most often done.)
> DNSSEC also provides tools so that one can know that the DNS data has
> not been modified somewhere, but that does not change the nature of the
> address information in DNS resource records being merely a hint.
>
> DNS, because of caching, can never become give ironclad promises that
> the result you get from your local DNS resolver is utterly accurate.
> And with the rise of geo-IP based DNS mappings, the definition of
> "accurate" becomes somewhat contextual.
>
> The real answer to homographic deceptions is not really within the realm
> of DNS itself, or within ICANN but, rather, would be through the
> adoption (at long last) of a proper layer of mutual identification and
> authentication either within the transport protocols or between them and
> the applications.
>
> None of this is easy - just look at how SSL evolved, and grew, to become
> TLS 1.1, 1.2, 1.3 ...  And nobody has ever said that DNSSEC is simple.
>
>      --karl--
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/at-large/attachments/20180721/d07e4bab/attachment.html>


More information about the At-Large mailing list