Subject: [homenet] On the TLD question and validatably-insecure delegation

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Nov 2016 00:46:05 -0500

Hi,

Mark Andrews's point about a DNSSEC insecure delegation today was not
I think fully appreciated.

In order to create a top-most label in the domain name that can be
used this way and that has the necessary properties, we cannot simply
instruct IANA to do it.  That is in fact creating a delegation in the
root zone of the DNS.  I believe that RFC 2860 (the MoU between the
IETF and ICANN) does allow us to create special-use domain names at
the top-most level.  But I do not believe it allows us to create
special-use domain names at the top-most level _in the DNS_, because
that is control of the root zone and it is unambiguously the province
of ICANN.
 
Therefore, if the WG decides to use a top-level label for these
purposes, we have to apply to ICANN to get it delegated from the root
in a provably insecure fashion.  Interestingly, ICANN actually has a
policy that it won't delegate things from the root any more that are
_not_ DNSSEC signed, and the whole point here is in fact to add an
entry that is contrary to that policy, so getting such a delegation
would require ICANN to change its policies before it could happen.

That is an important practical fact that ought to be taken into
consideration when deciding what kind of label to use.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Nov 2016 17:30:43 +1100

> would require ICANN to change its policies before it could happen.

I suspect this is a mischaracterization of the policy.  GTLD
delegations are so constrained.  This is not a GTLD delegation.

New country code delegations are not so constrained.

We are not asking them to delegate away from the roots.

root zone:
HOMENET. NS A.ROOT-SERVERS.NET.
...
HOMENET. NS M.ROOT-SERVERS.NET.

homenet zone:
HOMENET. SOA a.root-servers.net. nstld.verisign-grs.com. 1 1800 900 604800 86400
HOMENET. NS A.ROOT-SERVERS.NET.
...
HOMENET. NS M.ROOT-SERVERS.NET.

B.T.W. this should also be done for .ONION and .LOCAL if we want
local DNS resolvers to intercept these queries.  DNSSEC keeps
getting forgotten.  The only reason people aren't screaming
is that there are very few validating clients and the both
.ONION and .LOCAL don't use the DNS.  SERVFAIL is nearly as
good as NXDOMAIN for these use cases.

HOMENET uses the DNS.  If one can get a trust anchor for HOMENET
installed in every validator there shouldn't be any queries for
HOMENET/DS.

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2016 16:14:52 +0900

Yeah, this sunk in for all of us when we were standing around outside
the meeting room kvetching.   It's a bit of a conundrum.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Nov 2016 18:28:34 +1100

> the meeting room kvetching.   It's a bit of a conundrum.

No.

All it means is that there isn't policy for this which is exactly
the correct state of affairs for special names in the root namespace.
Each name needs to be individually handled as each is special with
its own requirements.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2016 16:30:41 +0900

Well, yes, but it means that we need to ask ICANN to do an insecure
delegation, and there isn't a process for that.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Nov 2016 18:34:52 +1100

> delegation, and there isn't a process for that.

We are adults.  They are adults.  We can talk together.  That should
be all the process needed once there is consensus that the name and
delegation are needed for protocol reasons.
 
> >> > In message <[email-masked]>, Andrew Sullivan wri
> tes
> >> :
> >> >> Hi,
> >> >>
> >> > HOMENET. SOA a.root-servers.net. nstld.verisign-grs.com. 1 1800 900 6048
> 00
> >> 86400

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2016 16:36:26 +0900

The problem is that the consensus process has to include them and we don't
know how to do that.

On Nov 16, 2016 16:35, "Mark Andrews" <[email-masked]> wrote:

> > > In message <CAPt1N1m_btPK8TGugoYd7iWxU6sEkPM288biBM
> [email-masked].
> > com>
> > > , Ted Lemon writes:

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Nov 2016 18:45:29 +1100

> The problem is that the consensus process has to include them and we don't

We have ways to talk to ICANN both formally and informally.  I
suggest we talk to them.  It may be as simple as add it to IANA
considerations in the special name defining RFC.  That would be
what I would do.  The special names process delegates the name
space to us.

Mark

> --001a114102c073b9620541662164
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <p dir=3D"ltr">The problem is that the consensus process has to include the=
> m and we don&#39;t know how to do that. </p>
> <div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Nov 16, 2016 1=
> 6:35, &quot;Mark Andrews&quot; &lt;<a href=3D"mailto:[email-masked]">marka@i=
> sc.org</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_qu=
> ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
> "><br>
> In message &lt;CAPt1N1=3D<a href=3D"mailto:5KyXA7XLd3Ks6y%2BT%2B0SWSXcdXUTo=
> [email-masked]">5KyXA7XLd3Ks6y+T+<wbr>0SWSXcdXUTozbVw4ed3Ew=
> pQTYA@<wbr>mail.gmail.com</a>&gt;<br>
> , Ted Lemon writes:<br>
> &gt; Well, yes, but it means that we need to ask ICANN to do an insecure<br=
> >
> &gt; delegation, and there isn&#39;t a process for that.<br>
> <br>
> We are adults.=C2=A0 They are adults.=C2=A0 We can talk together.=C2=A0 Tha=
> t should<br>
> be all the process needed once there is consensus that the name and<br>
> delegation are needed for protocol reasons.<br>
> <br>
> &gt; On Wed, Nov 16, 2016 at 4:28 PM, Mark Andrews &lt;<a href=3D"mailto:ma=
> [email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt; &gt;<br>
> &gt; &gt; In message &lt;CAPt1N1m_<wbr>btPK8TGugoYd7iWxU6sEkPM288biBM<wbr>3=
> [email-masked].<br>
> &gt; com&gt;<br>
> &gt; &gt; , Ted Lemon writes:<br>
> &gt; &gt;&gt; Yeah, this sunk in for all of us when we were standing around=
>  outside<br>
> &gt; &gt;&gt; the meeting room kvetching.=C2=A0 =C2=A0It&#39;s a bit of a c=
> onundrum.<br>
> &gt; &gt;<br>
> &gt; &gt; No.<br>
> &gt; &gt;<br>
> &gt; &gt; All it means is that there isn&#39;t policy for this which is exa=
> ctly<br>
> &gt; &gt; the correct state of affairs for special names in the root namesp=
> ace.<br>
> &gt; &gt; Each name needs to be individually handled as each is special wit=
> h<br>
> &gt; &gt; its own requirements.<br>
> &gt; &gt;<br>
> &gt; &gt; Mark<br>
> &gt; &gt;<br>
> &gt; &gt;&gt; On Wed, Nov 16, 2016 at 3:30 PM, Mark Andrews &lt;<a href=3D"=
> mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt; &gt;&gt; &gt;<br>
> &gt; &gt;&gt; &gt; In message &lt;<a href=3D"mailto:20161116054604.GB55057@=
> mx2.yitter.info">20161116054604.GB55057@mx2.<wbr>yitter.info</a>&gt;, Andre=
> w Sullivan wri<br>
> &gt; tes<br>
> &gt; &gt;&gt; :<br>
> &gt; &gt;&gt; &gt;&gt; Hi,<br>
> &gt; &gt;&gt; &gt;&gt;<br>
> &gt; &gt;&gt; &gt;&gt; Mark Andrews&#39;s point about a DNSSEC insecure del=
> egation today was not<br>
> &gt; &gt;&gt; &gt;&gt; I think fully appreciated.<br>
> &gt; &gt;&gt; &gt;&gt;<br>
> &gt; &gt;&gt; &gt;&gt; In order to create a top-most label in the domain na=
> me that can be<br>
> &gt; &gt;&gt; &gt;&gt; used this way and that has the necessary properties,=
>  we cannot simply<br>
> &gt; &gt;&gt; &gt;&gt; instruct IANA to do it.=C2=A0 That is in fact creati=
> ng a delegation in the<br>
> &gt; &gt;&gt; &gt;&gt; root zone of the DNS.=C2=A0 I believe that RFC 2860 =
> (the MoU between the<br>
> &gt; &gt;&gt; &gt;&gt; IETF and ICANN) does allow us to create special-use =
> domain names at<br>
> &gt; &gt;&gt; &gt;&gt; the top-most level.=C2=A0 But I do not believe it al=
> lows us to create<br>
> &gt; &gt;&gt; &gt;&gt; special-use domain names at the top-most level _in t=
> he DNS_, because<br>
> &gt; &gt;&gt; &gt;&gt; that is control of the root zone and it is unambiguo=
> usly the province<br>
> &gt; &gt;&gt; &gt;&gt; of ICANN.<br>
> &gt; &gt;&gt; &gt;&gt;<br>
> &gt; &gt;&gt; &gt;&gt; Therefore, if the WG decides to use a top-level labe=
> l for these<br>
> &gt; &gt;&gt; &gt;&gt; purposes, we have to apply to ICANN to get it delega=
> ted from the root<br>
> &gt; &gt;&gt; &gt;&gt; in a provably insecure fashion.=C2=A0 Interestingly,=
>  ICANN actually has a<br>
> &gt; &gt;&gt; &gt;&gt; policy that it won&#39;t delegate things from the ro=
> ot any more that are<br>
> &gt; &gt;&gt; &gt;&gt; _not_ DNSSEC signed, and the whole point here is in =
> fact to add an<br>
> &gt; &gt;&gt; &gt;&gt; entry that is contrary to that policy, so getting su=
> ch a delegation<br>
> &gt; &gt;&gt; &gt;&gt; would require ICANN to change its policies before it=
>  could happen.<br>
> &gt; &gt;&gt; &gt;<br>
> &gt; &gt;&gt; &gt; I suspect this is a mischaracterization of the policy.=
> =C2=A0 GTLD<br>
> &gt; &gt;&gt; &gt; delegations are so constrained.=C2=A0 This is not a GTLD=
>  delegation.<br>
> &gt; &gt;&gt; &gt;<br>
> &gt; &gt;&gt; &gt; New country code delegations are not so constrained.<br>
> &gt; &gt;&gt; &gt;<br>
> &gt; &gt;&gt; &gt; We are not asking them to delegate away from the roots.<=
> br>
> &gt; &gt;&gt; &gt;<br>
> &gt; &gt;&gt; &gt; root zone:<br>
> &gt; &gt;&gt; &gt; HOMENET. NS <a href=3D"http://A.ROOT-SERVERS.NET" rel=3D=
> "noreferrer" target=3D"_blank">A.ROOT-SERVERS.NET</a>.<br>
> &gt; &gt;&gt; &gt; ...<br>
> &gt; &gt;&gt; &gt; HOMENET. NS <a href=3D"http://M.ROOT-SERVERS.NET" rel=3D=
> "noreferrer" target=3D"_blank">M.ROOT-SERVERS.NET</a>.<br>
> &gt; &gt;&gt; &gt;<br>
> &gt; &gt;&gt; &gt; homenet zone:<br>
> &gt; &gt;&gt; &gt; HOMENET. SOA <a href=3D"http://a.root-servers.net" rel=
> =3D"noreferrer" target=3D"_blank">a.root-servers.net</a>. <a href=3D"http:/=
> /nstld.verisign-grs.com" rel=3D"noreferrer" target=3D"_blank">nstld.verisig=
> n-grs.com</a>. 1 1800 900 6048<br>
> &gt; 00<br>
> &gt; &gt;&gt; 86400<br>
> &gt; &gt;&gt; &gt; HOMENET. NS <a href=3D"http://A.ROOT-SERVERS.NET" rel=3D=
> "noreferrer" target=3D"_blank">A.ROOT-SERVERS.NET</a>.<br>
> &gt; &gt;&gt; &gt; ...<br>
> &gt; &gt;&gt; &gt; HOMENET. NS <a href=3D"http://M.ROOT-SERVERS.NET" rel=3D=
> "noreferrer" target=3D"_blank">M.ROOT-SERVERS.NET</a>.<br>
> &gt; &gt;&gt; &gt;<br>
> &gt; &gt;&gt; &gt; B.T.W. this should also be done for .ONION and .LOCAL if=
>  we want<br>
> &gt; &gt;&gt; &gt; local DNS resolvers to intercept these queries.=C2=A0 DN=
> SSEC keeps<br>
> &gt; &gt;&gt; &gt; getting forgotten.=C2=A0 The only reason people aren&#39=
> ;t screaming<br>
> &gt; &gt;&gt; &gt; is that there are very few validating clients and the bo=
> th<br>
> &gt; &gt;&gt; &gt; .ONION and .LOCAL don&#39;t use the DNS.=C2=A0 SERVFAIL =
> is nearly as<br>
> &gt; &gt;&gt; &gt; good as NXDOMAIN for these use cases.<br>
> &gt; &gt;&gt; &gt;<br>
> &gt; &gt;&gt; &gt; HOMENET uses the DNS.=C2=A0 If one can get a trust ancho=
> r for HOMENET<br>
> &gt; &gt;&gt; &gt; installed in every validator there shouldn&#39;t be any =
> queries for<br>
> &gt; &gt;&gt; &gt; HOMENET/DS.<br>
> &gt; &gt;&gt; &gt;<br>
> &gt; &gt;&gt; &gt;&gt; That is an important practical fact that ought to be=
>  taken into<br>
> &gt; &gt;&gt; &gt;&gt; consideration when deciding what kind of label to us=
> e.<br>
> &gt; &gt;&gt; &gt;&gt;<br>
> &gt; &gt;&gt; &gt;&gt; Best regards,<br>
> &gt; &gt;&gt; &gt;&gt;<br>
> &gt; &gt;&gt; &gt;&gt; A<br>
> &gt; &gt;&gt; &gt;&gt;<br>
> &gt; &gt;&gt; &gt;&gt; --<br>
> &gt; &gt;&gt; &gt;&gt; Andrew Sullivan<br>
> &gt; &gt;&gt; &gt;&gt; <a href=3D"mailto:[email-masked]">ajs@anvilw=
> alrusden.com</a><br>
> &gt; &gt;&gt; &gt;&gt;<br>
> &gt; &gt;&gt; &gt;&gt; ______________________________<wbr>_________________=
> <br>
> &gt; &gt;&gt; &gt;&gt; homenet mailing list<br>
> &gt; &gt;&gt; &gt;&gt; <a href=3D"mailto:[email-masked]">[email-masked]=
> </a><br>
> &gt; &gt;&gt; &gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/hom=
> enet" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/mailman/<wb=
> r>listinfo/homenet</a><br>
> &gt; &gt;&gt; &gt; --<br>
> &gt; &gt;&gt; &gt; Mark Andrews, ISC<br>
> &gt; &gt;&gt; &gt; 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> &gt; &gt;&gt; &gt; PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
>  =C2=A0 =C2=A0 =C2=A0 =C2=A0INTERNET: <a href=3D"mailto:[email-masked]">mark=
> [email-masked]</a><br>
> &gt; &gt;&gt; &gt;<br>
> &gt; &gt;&gt; &gt; ______________________________<wbr>_________________<br>
> &gt; &gt;&gt; &gt; homenet mailing list<br>
> &gt; &gt;&gt; &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a>=
> <br>
> &gt; &gt;&gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/homenet=
> " rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/mailman/<wbr>li=
> stinfo/homenet</a><br>
> &gt; &gt; --<br>
> &gt; &gt; Mark Andrews, ISC<br>
> &gt; &gt; 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> &gt; &gt; PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
> =C2=A0 =C2=A0 =C2=A0INTERNET: <a href=3D"mailto:[email-masked]">[email-masked]=
> g</a><br>
> --<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0 =C2=A0INTERNET: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> </blockquote></div></div>
> 
> --001a114102c073b9620541662164--

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Nov 2016 03:26:04 -0500

Hi,

On Wed, Nov 16, 2016 at 06:45:29PM +1100, Mark Andrews wrote:

> We have ways to talk to ICANN both formally and informally.

Yes.

> I suggest we talk to them.

That's ok with me, but the key thing we need to admit is that if we
want to create a special-use domain name that is actually intended for
use with the DNS and has to work with the root zone, then we need to
subject ourselves to the names community IANA procedures and not the
protocol parameters community IANA procedures.  That means that we're
in ICANN's turf and we have to respect and follow their rules.  Most
importantly,

> what I would do.  The special names process delegates the name

the special names process doesn't do that or, if it does, it has no
authority to do it.  RFC 2860 definitely says we can create special
names for technical use.  I believe that 2860, section 4.3 (a) allows
us to create such names at the root zone (though I note that not
everyone agrees with me about that).  What it does _not_ do, as nearly
as I can tell, is permit us to create delegations from the root zone
(even if they're functionally not very interesting or just delegated
to the root servers themselves).  We do not have that authority, and
given that the IANA stewardship change just happened it seems to me we
should be alert to the boundaries we have just reinforced.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 10:15:18 +0900

Mark Andrews <[email-masked]> wrote:
    > <CAPt1N1=[email-masked]> ,
    > Ted Lemon writes:

    > We are adults.  They are adults.  We can talk together.  That should be
    > all the process needed once there is consensus that the name and

+1.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 16 Nov 2016 23:34:26 -0500

Hi,

(no hats, just experience)

> On Nov 16, 2016, at 2:34 AM, Mark Andrews <[email-masked]> wrote:
> 

Just for clarity: I have complete faith that this is true, but it’s important to appreciate the position ICANN may be put in if we ask the IANA to do an unsigned delegation in the root zone. This was Andrew’s initial point and it shouldn’t be lost:

* RFC 6761 creates a registry for special use domain names. There have been many fine arguments over a couple of years now in DNSOP about exactly what implications this registry has for the DNS and the usefulness of the domain name space generally, but from the process perspective, it’s an IETF registry, over which the IETF has policy authority to request an update. 

* the DNS root zone is a different registry, for which explicit policy authority lies outside of the IETF: not with IANA, or even ICANN-the-corporation, but with the naming community. 

The special use domain name registry created in RFC 6761 implies an expectation that the policy authority for the root zone will not take certain hypothetical future actions. But an update to it does not ask for a change to the DNS root zone registry.

If the IETF asks for an unsigned delegation in the root for a special use name, it’s requesting an update to the DNS root zone, for which neither ICANN nor IANA alone has the responsibility.

The practical implications of this, as Andrew noted, are unknown at this time— everyone who spoke in homenet yesterday about what ICANN could, should, or would do was speculating— but might very well include some level of need to consult the naming community. There are processes for that, but they take time and may not turn out the way we’d like.

I note again that this is not about what string is being requested, or about whether the IETF should consult ICANN about the special use names registry established in RFC 6761. It’s about a new process for requesting a new kind of change to the DNS root zone registry.

As I said at the mic yesterday: a second-level name under .arpa avoids this registry authority problem altogether. I understand the concern that the resulting names are ugly, but the policy authority over .arpa is held by the IETF community, via the IAB. The process of asking the IAB for an unsigned delegation in .arpa is defined already, and is likely to be vastly simpler and faster than any such process for requesting an unsigned delegation in the root zone.

Suzanne

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 16:54:22 +0900

Suzanne Woolf <[email-masked]> wrote:
    > As I said at the mic yesterday: a second-level name under .arpa avoids
    > this registry authority problem altogether. I understand the concern
    > that the resulting names are ugly, but the policy authority over .arpa

And we could have something as ridiculously short as "h.arpa", right?
Could we have: 🏠.arpa ?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 16:56:30 +0900

It has to be possible to type it.   "hm.arpa" would be amusing.   I
think that if we are going to have to live with no secure delegations
from the root, which I really can't argue with, then we need to have a
securely-delegated TLD that is _not_ .arpa for stuff like this.   I
think the point raised about .arpa is unfortunately somewhat
legitimate.   .alt will have to be securely delegated also, but it
doesn't have a registry so it won't help with this use case.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Nov 2016 04:03:59 -0500

On Thu, Nov 17, 2016 at 04:56:30PM +0900, Ted Lemon wrote:
> legitimate.

Which point?  That it is mysterious to users?  That doesn't seem like
a powerful one to me, since "homenet" is also meaningless, also not a
thing anyone configured, and completely unintuitive to anyone whose
first language isn't Geek English.

That it might be confused with the Advanced Defence Projects Agency?
My Google search just now gave me Alberta Recreation and Parks
Association, ARPA Canada (which appears to be some Christian-values
association), and then the Wikipedia entry for .arpa, which stands for
Address and Routing Parameter Area (and has done since at least 2001
and RFC 3172).  The next entry is a disambiguation of ARPA from
Wikipedia.  Then Automatic Radar Plotting Aid.  Adcanced Defence
Projects Agency doesn't appear, presumably because it has been named
DARPA since 1972.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 18:23:47 +0900

God.   You're right.   I'm old.

Sigh.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Nov 2016 09:00:59 +0900

Ted Lemon <[email-masked]> wrote:
    > It has to be possible to type it.  "hm.arpa" would be amusing.

Why does it have to be typed? Because geeks might have to type it?
I typed it in my email by using copy and paste from a browser.
(It doesn't even display in Emacs correctly, which is my MUA, btw. I see a
box with 01F3EO in it)

Being hard to type seems like an advantage for a zone that we never want to
be seen at all.  If it's hard for geeks to type, then whenever we find
ourselves having to type it, we'd know that it had leaked in a bad way.

    > And we could have something as ridiculously short as "h.arpa", right?

I'm not asking if we should use it, I'm asking if we could use it.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Nov 2016 09:04:38 +0900

I have used computers that do not allow geeks to type things.   They
suck, not only for me, but for my parents when I am trying to support
them.    The homenet naming architecture document I wrote goes into
great detail about why it is a terrible idea to hide information from
the user, from a security perspective.   If you disagree with that,
I'd be curious to know why.   My experience is that users notice when
things change, and so showing them precisely what data you are
operating on, and having that data be nominally comprehensible, is a
substantial benefit, even if they don't have a correct mental model
for what the data means.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Nov 2016 09:07:53 +0900

For whatever it's worth, IDNA doesn't permit emoji, so using one will break in many display situations.  For raw Unicode, you don't have a way to be sure that's what the octets are: there's no encoding negotiation in the DNS.  Given what we have deployed so far, I think using an emoji is a bad idea. 

A

-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On Nov 18, 2016, at 09:00, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Ray Bellis <[email-masked]>
Date: Fri, 18 Nov 2016 09:09:40 +0900

> I typed it in my email by using copy and paste from a browser.

<no hat>

I type in ".local" domains at home all the time:

- "adsb.local", for my ADS-B receiver's web display
- "nas.local" for my NAS's web UI and other apps
- "dev.local" for SSH to my Linux dev box

Ray

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Nov 2016 12:46:10 +0900

Andrew Sullivan <[email-masked]> wrote:
    > For whatever it's worth, IDNA doesn't permit emoji, so using one will
    > break in many display situations.  For raw Unicode, you don't have a
    > way to be sure that's what the octets are: there's no encoding
    > negotiation in the DNS.  Given what we have deployed so far, I think
    > using an emoji is a bad idea.

okay, thank you!  Eliminating possibilities is good.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Nov 2016 12:46:55 +0900

Ray Bellis <[email-masked]> wrote:
    >> Ted Lemon <[email-masked]> wrote: > It has to be possible to type
    >> it.  "hm.arpa" would be amusing.
    >>
    >> Why does it have to be typed? Because geeks might have to type it?  I
    >> typed it in my email by using copy and paste from a browser.

    > - "adsb.local", for my ADS-B receiver's web display - "nas.local" for
    > my NAS's web UI and other apps - "dev.local" for SSH to my Linux dev
    > box

The claim has been, that this is a bug in our tools.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 18 Nov 2016 12:48:49 +0900

> The claim has been, that this is a bug in our tools.

Please elaborate.

I don't always want to have to use an mDNS point-and-click "browser" to
discover these services.

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Nov 2016 22:59:06 -0500

> I don't always want to have to use an mDNS point-and-click "browser" to

I think the point is that geeky people who are using ssh are not
really the population for whom we need to produce all this.  After
all, if you're comfortable at a command line you could probably just
run a split-brain DNS for yourself in your homenet.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Fri, 18 Nov 2016 13:06:09 +0900

> run a split-brain DNS for yourself in your homenet.

Only one of those was SSH - the others were browser based services.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Nov 2016 13:10:35 +0900

Andrew, the set of people who want to use the command line and who can set
up DNS servers is wildly disjoint. And these domain names show up even in
Apple uis.

If you ever use SSH, or want to type in a URL, you need these names.
Furthermore, leaving information out of uis trains users to not notice
ambiguities that could meaningfully compromise their security, so I don't
even agree with the idea that there should be a separate presentation name.
I think it's a dangerous practice.

Of course, to put that in perspective, I also think domain search lists are
a dangerous practice for the same reason.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Nov 2016 15:32:09 +1100

> up DNS servers is wildly disjoint. And these domain names show up even in

Agreed: this is cut-and-pasted from the system preferences panel
on my mac.

	Computers on your local network can access your computer at:
	rock-26713.local

Yes, there have been lots of "collisions" due to trying to stitch
together multiple mDNS spaces across routed subnets and the machine
moving between them "fast".

> a dangerous practice for the same reason.

They are and even more so when you skip to the next search element
on NOERROR NODATA and SERVFAIL.

Mark

> --001a114a7e12f7dc6c05418b7c28
> <p dir=3D"ltr">Andrew, the set of people who want to use the command line a=
> nd who can set up DNS servers is wildly disjoint. And these domain names sh=
> ow up even in Apple uis.</p>
> <p dir=3D"ltr">If you ever use SSH, or want to type in a URL, you need thes=
> e names. Furthermore, leaving information out of uis trains users to not no=
> tice ambiguities that could meaningfully compromise their security, so I do=
> n&#39;t even agree with the idea that there should be a separate presentati=
> on name. I think it&#39;s a dangerous practice. </p>
> <p dir=3D"ltr">Of course, to put that in perspective, I also think domain s=
> earch lists are a dangerous practice for the same reason. </p>
> <div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Nov 18, 2016 1=
> 2:59 PM, &quot;Andrew Sullivan&quot; &lt;<a href=3D"mailto:ajs@anvilwalrusd=
> en.com">[email-masked]</a>&gt; wrote:<br type=3D"attribution"><bloc=
> kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
> c solid;padding-left:1ex">On Fri, Nov 18, 2016 at 12:48:49PM +0900, Ray Bel=
> lis wrote:<br>
> &gt; I don&#39;t always want to have to use an mDNS point-and-click &quot;b=
> rowser&quot; to<br>
> &gt; discover these services.<br>
> <br>
> I think the point is that geeky people who are using ssh are not<br>
> really the population for whom we need to produce all this.=C2=A0 After<br>
> all, if you&#39;re comfortable at a command line you could probably just<br=
> >
> run a split-brain DNS for yourself in your homenet.<br>
> <br>
> A<br>
> <br>
> --<br>
> Andrew Sullivan<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <br>
> ______________________________<wbr>_________________<br>
> homenet mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/homenet" rel=3D"noreferrer=
> " target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/homenet</a><=
> br>
> --001a114a7e12f7dc6c05418b7c28--
> 
> 
> --===============4418082070297513729==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============4418082070297513729==--
>