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

Ted Hardie <ted.ietf@gmail.com> Thu, 04 February 2016 23:16 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: arcing@ietfa.amsl.com
Delivered-To: arcing@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BC81B33C8 for <arcing@ietfa.amsl.com>; Thu, 4 Feb 2016 15:16:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juhtYt9ppBAW for <arcing@ietfa.amsl.com>; Thu, 4 Feb 2016 15:16:00 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076BD1B33C6 for <arcing@ietf.org>; Thu, 4 Feb 2016 15:16:00 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id x1so27763346qkc.1 for <arcing@ietf.org>; Thu, 04 Feb 2016 15:15:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3kaRbnHuiHc/m5wSWylph7iPR/aHlX/JFV0NBUzVyJE=; b=FRFc4hXfiW/FS90koAshrPlwdCr5aM3BBoSPtZTjelFy4AfwXVhVmkrst8bd/RpKpo qbCmes/vv1fcGw4sX/UOdg8sM9tdtVVLDhy19zcGbDeEhyt9gPWInaDbu3fcjgbaPlWw pZflQLk1gwllWK2lbSXaywC9Img5a0xOpO9+x+HjGRLJMnnZvMuoa5EvTyOYWmeRfLkA ZCSuhbR9ChXe/AAF2FfN44l6AwHFtqTE9El0IeVzHu6YWcx+ctXVUKqNc8MiMmgjgfQk TO/l7qe6UBqCTfMs6u25C+khzvYZtIgyPZNLX64SwQEGVBWk2saMJTycOYkUWwqxdBpL 4eDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3kaRbnHuiHc/m5wSWylph7iPR/aHlX/JFV0NBUzVyJE=; b=GO0yvKBRAmjS+Ye8YPE/ZNYHlsChlOO2uSBYVkAsTlxCzyZwGhXrUjIYnK2/We/6Ht v2NSs3ZqHIsUPg+rUX/66EyfacGmoduZdXfIsFIdGhvmh3hxMxLZlllTDEdZHxUS3scs WvLbfRcBgmwrgJAF5/NYXTh2T3FHuYGXlOz7srD7Mq2pdacK6kIeuwdCY//m6U6XxLca Vht/YiV9A5uS2BKB8GazmBTGQXASGzTTk9IrpCKhz9lFO6DoZEC9Wn391ilJ9dGF027q Eeep2YU2q9t+bgATqcO0hlez7t0U7VvJlp7D7zI+MoWqIqravL3Tj+zwhIgDrTneO7nC kqhA==
X-Gm-Message-State: AG10YOTnikyPlRIK3P+sTiHNPlI35hilkXvRKUX8SHuxFHbxhq59uRUyWoN2wFsod/AeSJG2Qa2WUXHvzxlMmA==
X-Received: by 10.55.71.66 with SMTP id u63mr12444577qka.67.1454627759215; Thu, 04 Feb 2016 15:15:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.14.211 with HTTP; Thu, 4 Feb 2016 15:15:39 -0800 (PST)
In-Reply-To: <CA+9kkMBspy_mKummQDvBcaSC3PXX4-cLde=Qpfi9y8Ey31_BdQ@mail.gmail.com>
References: <CA+9kkMDBPHYg3ENofdZ2jQxh=Wjv3KZXK+gw=5nYT0B=VL87Qg@mail.gmail.com> <524E4EBB-DB02-4091-9F5D-14F103A81178@mnot.net> <CA+9kkMBP1EBe7Bc0nh-DJoJaFNzSofPyuO2NOR+BDjJtFt_WZA@mail.gmail.com> <56B3D81C.9050609@gmail.com> <CA+9kkMBspy_mKummQDvBcaSC3PXX4-cLde=Qpfi9y8Ey31_BdQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Thu, 4 Feb 2016 15:15:39 -0800
Message-ID: <CA+9kkMArYF5=oYx8U78hZM-7uOyQVZ-YrA55oV+6pPFPfic6fw@mail.gmail.com>
To: Douglas Otis <doug.mtview@gmail.com>
Content-Type: multipart/alternative; boundary=001a114a7974de5b45052af9ea20
Archived-At: <http://mailarchive.ietf.org/arch/msg/arcing/c2bPwtHo-TqHVwnCLbXYlaCSLnY>
Cc: arcing@ietf.org
Subject: Re: [Arcing] A bit more on the problem statement
X-BeenThere: arcing@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names <arcing.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/arcing>, <mailto:arcing-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/arcing/>
List-Post: <mailto:arcing@ietf.org>
List-Help: <mailto:arcing-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/arcing>, <mailto:arcing-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2016 23:16:02 -0000

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

On Thu, Feb 4, 2016 at 3:12 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> On Thu, Feb 4, 2016 at 3:00 PM, Douglas Otis <doug.mtview@gmail.com>
> 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
>> Arcing@ietf.org
>> https://www.ietf.org/mailman/listinfo/arcing
>>
>
>