Re: DNS names, was Last Call on _openpgpkey

Andrew Sullivan <ajs@anvilwalrusden.com> Fri, 25 September 2015 02:22 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A8F1B34FA for <ietf@ietfa.amsl.com>; Thu, 24 Sep 2015 19:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 g2-W_Ol6MEUf for <ietf@ietfa.amsl.com>; Thu, 24 Sep 2015 19:22:07 -0700 (PDT)
Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0721B34F9 for <ietf@ietf.org>; Thu, 24 Sep 2015 19:22:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 3095410721 for <ietf@ietf.org>; Fri, 25 Sep 2015 02:22:06 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HqR5aQAYxvr for <ietf@ietf.org>; Fri, 25 Sep 2015 02:22:04 +0000 (UTC)
Received: from mx2.yitter.info (c-73-142-68-92.hsd1.nh.comcast.net [73.142.68.92]) by mx2.yitter.info (Postfix) with ESMTPSA id AC90010718 for <ietf@ietf.org>; Fri, 25 Sep 2015 02:22:04 +0000 (UTC)
Date: Thu, 24 Sep 2015 22:22:03 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: ietf@ietf.org
Subject: Re: DNS names, was Last Call on _openpgpkey
Message-ID: <20150925022202.GW68642@mx2.yitter.info>
References: <20150911212549.61594.qmail@ary.lan> <20150911221849.D81EC377C9BD@rock.dv.isc.org> <20150924202858.GJ68642@mx2.yitter.info> <20150924230424.E58E7384873E@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20150924230424.E58E7384873E@rock.dv.isc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/y2NEG-zOxRRk4ELX3tbjkbxQX4s>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2015 02:22:08 -0000

Hi Mark,

On Fri, Sep 25, 2015 at 09:04:24AM +1000, Mark Andrews wrote:
> RFC 1034
> 				      When you receive a domain name or
> label, you should preserve its case.

> This is at the RR level as the concept of RRset didn't exist when
> RFC 1034 was written.

While I certainly resepect your interpretation and agree it's a strong
and plausible one, it is not the only possible one.  Moreover, since
RFC 2181 updates 1034 it doesn't matter for the protocol (as a whole)
that 1034 doesn't talk about RRsets; indeed, it makes the problem
worse.  I also respect and agree with your remarks about the relative
cost of implementation, but we don't have documents that say all that
and therefore we have a gap.  I'd be extremely happy if such documents
showed up.  Still, the history of such clarifications about the DNS
does not make me optimistic.  Moreover, as Don Eastlake indirectly
points out, RFC 4343 observes that the preservation is not as complete
as one wants.

> Fixing this now would mean we could use it in 10 years time as the
> non-compliant servers would almost all be gone.

Perhaps, but the bigger hurdle is getting consensus and ensuring that
naïve implementers don't just read STD13 and maybe some other stuff.
DNSEXT had one go at a clearer document set (along the lines of the
updates of RFC 821/822) but didn't deliver.  Since I was co-chair
during the failure I will shoulder the blame.  But if you know a way
to make such an update successful the next time, I believe people
would value it.

I think this is a hard social problem, not a hard technical problem.
Maybe a few people interested in solving these problems could find a
way to get together in Yokohama or elsewhere, and try again at
incremental steps?

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com