Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
George Michaelson <ggm@algebras.org> Fri, 27 November 2015 02:18 UTC
Return-Path: <ggm@algebras.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DED1B30C6 for <dnsop@ietfa.amsl.com>; Thu, 26 Nov 2015 18:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 3w0WNWYp_KGC for <dnsop@ietfa.amsl.com>; Thu, 26 Nov 2015 18:18:12 -0800 (PST)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 E182F1B30C7 for <dnsop@ietf.org>; Thu, 26 Nov 2015 18:18:11 -0800 (PST)
Received: by qkao63 with SMTP id o63so32225042qka.2 for <dnsop@ietf.org>; Thu, 26 Nov 2015 18:18:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hcdeAzB7V9I17D1e1ZAg69M3vWFzs55rdI3d2I+ABnc=; b=BhtZOu/9tt0Tn2GZVzixJmpG6v2SMn4eek0Xd2vy7ygUG7IFIMcQN+InH5eaA14w6a 2khVyI7O0tWfMK4UC4Vea5jX0uBb7OA8NdbO/+xgTFS4+IA8TUY/yoih40dNaMQMpMkm yJaL9gx/uXxXKekFfaHHeGk2cEOQx50da5mkOmwFnOuAkQ56968iqecGyFAM40Kc7GJR XasMyrRr8d0t+tiEWWfujAypHgP/BI14j5V/xmvWa/PIFThKOsNKTFcmvsmoqzADQE8q OlyYbKdd+sAQ2ZidDjBt7cNZAQLc2rzcTYRjYBtAVtvzirLdIEnqkcy6uCmFttkr72Ov gREg==
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:date :message-id:subject:from:to:content-type; bh=hcdeAzB7V9I17D1e1ZAg69M3vWFzs55rdI3d2I+ABnc=; b=fZmZObHZYdJWMPgdaChxfc9s4qUT4WCaJ0Pa/eM3w/05IPStSNeHu/CJ7BJ3rPVnD0 /zQRQEisgxIipOwE79MCCi7dTgw1xa1N/fz2dI78p/pYk+Zo9yB+PWndiEqUtqQ+qE+u JLjWGfiVY1UZGnMc9vvbtM30ah4tKzaTkMO6SAxJM/xNTZo0dnOXD41sckuolbDAU7W3 4DRvpZv418f6vRkHE4GckolNO95Qa94jwFyS2Giqq6e5PUJHSfLDVB8HHCoU6u0UpbVA TJfqCUYbYb0Wbsk4L9a+w4uvVXN1nrs7V+hPjDN2oAg369JqraDw93YqVsQSaTB1aAPZ iJBg==
X-Gm-Message-State: ALoCoQnJreK9f5ANyNlDfUckJjQdH/yvSqrVXSCnFB1GvTgf6Y8084fKelsJGF5dZ61QuzK4ZQgR
MIME-Version: 1.0
X-Received: by 10.55.79.69 with SMTP id d66mr36066099qkb.76.1448590691108; Thu, 26 Nov 2015 18:18:11 -0800 (PST)
Received: by 10.55.164.146 with HTTP; Thu, 26 Nov 2015 18:18:11 -0800 (PST)
X-Originating-IP: [2001:dc0:a000:4:5c5a:df1c:a9d7:dd0d]
In-Reply-To: <5656F43D.9060401@gnu.org>
References: <7E4C1956-8477-4F07-BC29-3D163B7160AA@mnot.net> <5656F43D.9060401@gnu.org>
Date: Fri, 27 Nov 2015 12:18:11 +1000
Message-ID: <CAKr6gn1nTnUwxQ0LR8m-s9AHpXD72ODOrb_B2zke3Q9Mb_k=2Q@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
To: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a114a59be91abf605257c4d50"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/e3b8C8dwYjA8bKG07_Hws04BIEI>
Subject: Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Nov 2015 02:18:15 -0000
I have a different perspective on this question Mark. Firstly, I find use of .magic as the extreme RHS of a name, to force special behaviour architecturally disqueting. I really do worry about what we think we're building when we encode this behaviour into name strings. It leads to all kinds of bad places. Some of them, like the homoglyph problems John Klensin has raised, simply don't have good answers (the assumption the string .onion is the literal ASCII 'o' 'n' 'i' 'o' 'n' is not well founded) We were here a long time ago, when we had pre-Internet mail and used things like .UUCP as magic break-out signals in email. This rapidly becomes the problem: its bound to applications-level decisions about when to honour magic, and when not, and it certainly doesn't avoid lower level gethostbyname() calls everywhere. So the .magic label winds up being half-true, depending. Secondly, While I think I now understand some of the problems you have in web/apps layer (from talking to Wendy Seltzer) and I have sympathies about the syntactic constructs welded into code around URL forms, I think these problems are different to the architectural/layer violation explicit in forcing .magic names into the namespace. What really got me floored, was the qualities of cryptographic protection which a project like TOR needs, and the implication a public/commercial CA service embedded in the browser TA set is the right path. I'm frankly horrified, even under certificate pinning, that we've gone to a space where any TA can claim to sign over .onion, and excluding the pinned applications, lead people into paths where their assumptions of TLS backed security are simply not true. As I understand things, TOR *wanted* .onion to get X509 PKI over the label in a browser, and the CA community refused unless its TLD status was confirmed. Is this the kind of rigour in technical process we expect, to make technical calls to pre-empt the namespace? (which btw, we passed otherwise to another body, reserving an RFC backed process to get names, but I think that was a hugely unwise decision) To protect .onion certs, the TOR developers are going to have to code in cert pinning behaviour, all kinds of things, which frankly sound to me a lot like the cost of not having the name, or having a name buried under a 2LD instead. So I come to a different place. I come to a place where requests for magic names look like violations of any spirit of an architectural view of the network, and where retaining some technical basis to reserve them looks like violations of the separation of functional roles between ICANN and IETF, absent very very clear, strong reasons to have the name held back. I don't entirely see these reasons emerging. I see the opposite. I see expediency from apps communities, seeking to use .magic tricks to avoid cost explicitly in their layer, but at a cost of polluting the public commons. I am pretty firmly in the camp which says the revision of the RFC should be complete: we stop doing this, and people who want names go into ICANN process to establish them. -G On Thu, Nov 26, 2015 at 9:59 PM, hellekin <hellekin@gnu.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/26/2015 06:38 AM, Mark Nottingham wrote: > > > > Given this context, I was disturbed to hear the design team presentati > on > > in Yokohama > > > > So you mean there's an already working team on the revision of RFC6761, > and that team had the time to prepare a presentation, while the DNSOP > chairs didn't have the time to respond to volunteers nor to announce > this team. This is simply unacceptable. I concur that the revision of > RFC6761 should go to another group where "Internet community" makes some > sense and corporate dissent is not silenced by ignoring legitimate > requests. Please don't expect any apologies from me for telling the > truth. This is a carnival of an inclusive process. > > Thank you Mark for the heads up. > > == > hk > > -----BEGIN PGP SIGNATURE----- > > iQJ8BAEBCgBmBQJWVvQ8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 > ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9ewoQALD1dF/Wqyh2Lo5qZ35PUANA > bvq2k5BZd1UsN488+V4v7PnAHxO7XgR8IQSYYnp1oYNaZl5WbFEPjT6HOSR3O4lr > 7iSVeSxPux8hssSxorkWtBVk8oAnImGEPyIlYunBLcTyasXLY5+2fzmR1+P4/9Kk > ahjHvuQa6dOAXhqTMBizwb3kZ2PC2hFlM5LKMIBcf9GfTVmH//fbEalHYPYEwMCY > AvX9mkMvvWcWhn15OXRi50r3kQl65d0KQA2euQ8mUIe5qafDHASBtZLc81t0rAXv > fjaWT4REu+KUHexWKgI7NFF3uZ0M0Cm7imYN6+YG+AWFtPrr4SPh1BA0L4td93q8 > bGxGEJrDTWRVaW2c98UO5bFxm3kqcM4oTdBD1Rg4yC1OatvuKzZp6nPrFG09G5rn > PjorrqoNx0MHxwejrTHkkhnmvmgTfPUTvkT/7zUYLTwRITDrjzOyj932COrZV+A3 > dak5M5hRLhR8jswx/lh+SmY1RFAtCuNDcoFuXTOJygwSpj7WvigIORiT6ATLFlfW > mxYxkVP/Tc76anRTk5O/AIu87c5K9fr6TPiFRIL/0eKnFBEMn2qbaW7TLvAl6o89 > kgYYp4u59ve0vCL6gE2sn1w1EYnctFVxpzcg9HkFl/MFuQyWdc4yb5OdFWW8sema > 8hpTT/KiW1/KDHGj0kcB > =IZoh > -----END PGP SIGNATURE----- > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
- [DNSOP] Some thoughts on special-use names, from … Mark Nottingham
- Re: [DNSOP] Some thoughts on special-use names, f… hellekin
- Re: [DNSOP] Some thoughts on special-use names, f… George Michaelson
- Re: [DNSOP] Some thoughts on special-use names, f… Tim Wicinski
- Re: [DNSOP] Some thoughts on special-use names, f… Mark Nottingham
- Re: [DNSOP] Some thoughts on special-use names, f… Philip Homburg
- Re: [DNSOP] Some thoughts on special-use names, f… Jacob Appelbaum
- Re: [DNSOP] Some thoughts on special-use names, f… Philip Homburg
- Re: [DNSOP] Some thoughts on special-use names, f… Jacob Appelbaum
- Re: [DNSOP] Some thoughts on special-use names, f… David Conrad
- Re: [DNSOP] Some thoughts on special-use names, f… str4d
- Re: [DNSOP] Some thoughts on special-use names, f… Edward Lewis
- Re: [DNSOP] Some thoughts on special-use names, f… John Levine
- Re: [DNSOP] Some thoughts on special-use names, f… Philip Homburg