Re: [DNSOP] moving forward on special use names

Phillip Hallam-Baker <hallam@gmail.com> Mon, 19 September 2016 01:38 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 56F5212B182 for <dnsop@ietfa.amsl.com>; Sun, 18 Sep 2016 18:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 apcX_LKl58V5 for <dnsop@ietfa.amsl.com>; Sun, 18 Sep 2016 18:38:41 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 BAEE412B0CB for <dnsop@ietf.org>; Sun, 18 Sep 2016 18:38:40 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id 38so65969018qte.1 for <dnsop@ietf.org>; Sun, 18 Sep 2016 18:38:40 -0700 (PDT)
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; bh=V7AqfUMg388SNDvjX6d+Tvnc4qQKs6lJEUKCI5XhX0Q=; b=tK7K3KjX4dtVtbRBsyyp1rTNL/+JdmLMGdwlzoxFULyvAhGk8HsVZLhpNnV+gLsFpD PoQGWOD9Eok4Xojltw+1X32Zp7smxTEtYBcvbRSh3Jef6mJJVDVzW+hWxB5i5KfK+NLu YxLU29qm2LMJVtMSe6iyx2MFUhV/MGjLn34KLZjIES0Zr5CUrsiksL5RzDikiwJR/10f srj0ne8HuKHuI7Rl/AanyhfxwzvL1CcObZxE/9+FZDx8Jja6rvKPjQ9qOGL0eE9GOxsM gTZPFBvy4XQ1/6NqTQT7BY7VGUn7aGckUxnqS9CEOhFXraf46Ps6OE49nAXOd2kc/Iwq /2Zg==
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; bh=V7AqfUMg388SNDvjX6d+Tvnc4qQKs6lJEUKCI5XhX0Q=; b=RUfb1jl+qJG816snM2pIKNVyrW3n7W2AV0qiXi+YehcTah0MG7d5URGevoggi0a0xK BywoVqYNdNfgrlZ+t78qhBpJHu+QKDL9E+1Pab/bEe7c/3tC3DDuHIA0CrndFtpVWFn+ AOXnempuU9piLidXCgmYW+nTxVcvCe2lsYaE/1PpXACZ8KNGrug//B3CfsVl7yaQA6nF TQmA1Yyu7QrklW/VHwKgEp+if+D8dqVKV2eNianR/LPOsROvOf50UvPmQzQ1/4k+pgcx LiSkXSiZ89Cs4bhVVCOf7me1PqPwl5m5nkKelOCnFTYbGf/ypAnSawWZjsyUd3Nd4qcy GhSw==
X-Gm-Message-State: AE9vXwMoHvuerQS1JyVDmVY8BHxBgFfvY2l9MHM1nK0YyqSXinpmrXEjmbBpVxIQfsbyncpdm5+M4R2skxyEgA==
X-Received: by 10.200.56.55 with SMTP id q52mr27502276qtb.23.1474249119857; Sun, 18 Sep 2016 18:38:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.209.87 with HTTP; Sun, 18 Sep 2016 18:38:38 -0700 (PDT)
In-Reply-To: <20160916181356.70566.qmail@ary.lan>
References: <D60BBDEF-3C13-44CB-A0D9-DEA98F5297F5@gmail.com> <20160916181356.70566.qmail@ary.lan>
From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Sun, 18 Sep 2016 21:38:38 -0400
Message-ID: <CAMm+LwjMBq0bhbSXL8L944mfua1wpo1oOCPDKkqBO2UYngAujg@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=001a113978fe1981b0053cd25f27
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JnCTLC69SygsEK0MNGclrr5dJDE>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Suzanne Woolf <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:38:44 -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

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