Re: [DNSOP] moving forward on special use names

Phill <hallam@gmail.com> Mon, 19 September 2016 01:00 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58D412B16D for <dnsop@ietfa.amsl.com>; Sun, 18 Sep 2016 18:00:05 -0700 (PDT)
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 autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 eeQmytTOI53G for <dnsop@ietfa.amsl.com>; Sun, 18 Sep 2016 18:00:03 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 EFB4112B0CB for <dnsop@ietf.org>; Sun, 18 Sep 2016 18:00:02 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id d69so73607583ybf.2 for <dnsop@ietf.org>; Sun, 18 Sep 2016 18:00:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=F8cBh/B/LOz19ipttoIM6iMfYoR08C9sKyDl9k7GKSk=; b=cjP7A4OqGdXPQLencWqJoe7284xuR9Ky7iHqSbR85Mu4mmys74CADVaq9XTs0YvuCg rN9h3q2v9jMDGu3CX9YMCUhQ8RKLNwgoWV7t72L4lzAe1zziIDwre6uEhFGRKbTJcgx0 pezr1TpqdKCXjbMhp+gUV2+t2n6XIpWMUS9xmi0BDD+D+z5wDqSIe0yka/U1kxOKjLWB te4QUh7sl2XEOp2XzTKgJJxqiY+TtZFy9BeEHPaMIbplhydXPrvL+ZN2hORUoIJSyt5h ll9klBlbal5hrRL6Q0GcmIwGnY8B5wUoK36/gy3WIZdmv42dzQhaoo6I1+IstsoUQeti 2xNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=F8cBh/B/LOz19ipttoIM6iMfYoR08C9sKyDl9k7GKSk=; b=m/2zSaSNSUOfyF0h9nzk6a1zPoZ8vwz3+1S9DWsjelNn/aUxg4oUShpJzHU2gxeWZe HWPR8pccJemX+jO2BPkXacYXerNdnLZDzqPnyV5AnFTdtU+vV0RH7HYWc4WmgNoSnKdJ fAnvwJWBFvOOsyiMcRcwbSKf9b24SiPmtZA+KlrdLAAxgFaq4uRg8Y1gmeW6ET/au3Cz Hc1/m5ka+W6dgezbcz705HeDBhzv/5z/1lBC0Hc4n8wvReP16bTPGVXK1gm4Z75Jk1fw HlUKUjBVfyHSDxgdNgiOWOKl/its0KK9JEYxXj8evH7+2dOtNINJ+5Gt+vmpuzFIiJpd 8zSw==
X-Gm-Message-State: AE9vXwOPifZ2j0SqcklVjr/18Rv1e8bK7vtmYrzzF05LrIEpnQXOs6qxvsbwprcDc7+1GA==
X-Received: by 10.37.228.198 with SMTP id b189mr23266551ybh.138.1474246802159; Sun, 18 Sep 2016 18:00:02 -0700 (PDT)
Received: from galifrey.hallambaker.com (pool-173-48-179-147.bstnma.fios.verizon.net. [173.48.179.147]) by smtp.gmail.com with ESMTPSA id h136sm7586542ywc.41.2016.09.18.18.00.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 18 Sep 2016 18:00:01 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B64516E2-DB7F-4A93-B1FD-8F66C6E27E42"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Phill <hallam@gmail.com>
In-Reply-To: <20160916181356.70566.qmail@ary.lan>
Date: Sun, 18 Sep 2016 21:00:00 -0400
Message-Id: <D2C5DF2A-9A4A-4E72-92BE-BD8808578BCD@gmail.com>
References: <20160916181356.70566.qmail@ary.lan>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/n8nEumsCaAjsN94d2CSWmo2Z2pc>
Cc: dnsop@ietf.org, suzworldwide@gmail.com
Subject: Re: [DNSOP] moving forward on special use names
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 19 Sep 2016 01:00:05 -0000

There is actually a fifth type of name, escaped names. Right now, the only names we have of this type are SRV protocol tags, (_http._tcp.example.com) and internationalized names (xn—wev.com)

I want to add a third set of escaped names, one that has similar functionality to .onion but does not leak as much information.

example.com.m​f--​b2gk​6​-​duf5​y​-​gyyl​​-jn5e​d​

This is a strong domain name and to interpret it we require a policy that is validated under the UDF fingerprint b2gk​6​-​duf5​y​-​gyyl​​-jn5e​d​. This in turn is a base 32 encoding of 92 bits of digest value plus an 8 bit version string. The fingerprint is over a content type identifier plus some content as specified here.

https://tools.ietf.org/html/draft-hallambaker-udf-03 <https://tools.ietf.org/html/draft-hallambaker-udf-03>

The content is typically going to be some sort of cryptographic key (PGP, PKIX, SSH, JOSE, whatever) that signs some sort of assertion that states how the address ‘example.com’ is to be interpreted.

The trick here is that we can now bind security policy direct to any DNS name without having to muck about with DNSSEC, or for that matter any other PKI standard other than the particular standard we want.


Lets say that Alice is using OpenPGP and her OpenPGPv5 key is mw83i-32ri4-83klq-3odp3. We can form an address from that:

alice@example.com.mf--mw83i-32ri4-83klq-3odp3

Now that isn’t an address that we can interpret without access to Alice’s public key. Which is actually what I kinda want because I am fed up of spam. The fact that I give you my address does not mean I want just anyone being able to use it.

In the ordinary course of business, my ‘strong name aware’ mailer knows that it has to resolve mf--mw83i-32ri4-83klq-3odp3 somehow before it can use that email address. If I just type it into Outlook, the client will happily pass it on to my mail server and then it will get ‘stuck’ unless the mail system can figure out how to use that address. Which is exactly what you would want to happen with confidential mail.

If the address can be resolved, the result is normally going to be a policy that says what protocols the address can be used with and how.

Now, naturally, a split horizon DNS would be one natural place to provide access to a resolution service, but it need not be the only one.


The use of strong DNS names represents a major step forward in achieving a genuinely decentralized Web. Instead of there being an institution at the trust apex of the Internet, there is a digest function and a PKI scheme.


> On Sep 16, 2016, at 2:13 PM, John Levine <johnl@taugh.com> wrote:
> 
>> The drafts are:
>> 	https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
>> 	https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/
> 
> Having read them both, neither one thrills me but I'd give the nod to
> adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
> there are a lot of other names on the Internet such as URIs and handle
> system names, and this is about domain names.
> 
> It seems to me there are four kinds of names we have to worry about, and
> neither draft calls them all out clearly:
> 
> * Names resolved globally with the DNS protocol, i.e.
>  ordinary DNS names
> 
> * Names resolved globally with an agreed non-DNS protocol, e.g.
>  .onion via ToR
> 
> * Names resolved locally with an agreed non-DNS protocol, e.g,
>  .local via mDNS
> 
> * Names resolved locally with unknown protocols, e.g. .corp and
>  .home, the toxic waste names
> 
> R's,
> John
> 
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop