Re: [Arcing] A bit more on the problem statement

[Ted Hardie <[e-mail]>]

Sorry, I mis-licked and this went out early.

On Thu, Feb 4, 2016 at 3:12 PM, Ted Hardie <[e-mail]> wrote:

> On Thu, Feb 4, 2016 at 3:00 PM, Douglas Otis <[e-mail]>
> wrote:
>
>>
>> On 2/4/16 11:44 AM, Ted Hardie wrote:
>> > If we get broad agreement to use a particular signal,
>> > like .alt, then folks minting new namespaces in .alt can
>> > avoid collision with a simple FCFS registry.  If everyone
>> > plays nice, there is no collision and you have no big
>> > issues.  But we have no way of making that so, and we
>> > have seen in the pseudo-TLD case that people mint these,
>> > use them, and then require updates of others to deal with
>> > the collisions.  Depending on the usage of .alt or a
>> > similar signal, that could remain a concern (at least
>> > version of the proposal had no registry at all, just the
>> > reserved top label).
>>
>> Dear Ted,
>>
>> Why assume .home should be converted to .home.alt? Is this
>> to ensure .alt gains inertia with its namespace containing
>> definitions similar to those found with
>> https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02?
>>
>>
> ​For what it is worth, I think you missed the fact I was citing
> someone else's work, not advocating .alt myself.  That said,
> I believe the draft you cite has a method that covers this:
>
​

   For residential home networks, Zero Configuration [ZC
<https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02#ref-ZC>]
operation is
   desirable, without requiring any manual configuration from the user.
   A client device learns about its network environment in a variety of
   ways.  It builds a list of network-recommended DNS search domains
   using DHCP options 15 (Domain Name option [RFC2132
<https://tools.ietf.org/html/rfc2132>]) and 119 (Domain
   Search option [RFC3397 <https://tools.ietf.org/html/rfc3397>]).  It
builds a list of network-recommended
   DNS-SD browsing domains by sending domain enumeration queries
   [RFC6763 <https://tools.ietf.org/html/rfc6763>].

​

>
> Open-ended FCFS registration will encourage an explosion of
>> variant namespaces having any number of resolution methods
>> and context.
>
>
​This is possible, but unless these are deemed a valuable commodity,
it seems somewhat unlikely.  Registry policy can certainly be tweaked
to "expert review" or something so that a dictionary attack on .alt
fails.

But that's a good bit further along than we are.

regards,

Ted​



> It seems safer to keep .home as defined by
>> draft-cheshire-homenet-dot-home-02, and let .alt develop
>> independently. In the goodness of time resource assessments
>> and related risks assessments can then be made.
>>
>>



> Small home CPE devices offer limited storage and need
>> simplistic access methods to limit vulnerabilities and
>> coding complexity. As such, offering a highly extensible
>> resolution structure as a first step seems ill considered.
>> Otherwise, assessing security risks will provide resulting
>> extensibility APIs likely to make Java and Flash defense
>> seem trivial in comparison and will do nothing to limit the
>> leakage of .home.
>>
>> Regards,
>> Douglas Otis
>>
>>
>>
>> _______________________________________________
>> Arcing mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/arcing
>>
>
>