Re: Punycode Mixed-case annotation

Andrew Sullivan <ajs@shinkuro.com> Tue, 30 June 2009 15:12 UTC

Return-Path: <ajs@shinkuro.com>
X-Original-To: idna-update@alvestrand.no
Delivered-To: idna-update@alvestrand.no
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A6B939E298 for <idna-update@alvestrand.no>; Tue, 30 Jun 2009 17:12:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAEy7NPbEsOM for <idna-update@alvestrand.no>; Tue, 30 Jun 2009 17:12:42 +0200 (CEST)
X-Greylist: from auto-whitelisted by SQLgrey-1.6.8
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6A8B139E1DD for <idna-update@alvestrand.no>; Tue, 30 Jun 2009 17:12:42 +0200 (CEST)
Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7AAE52FE9665 for <idna-update@alvestrand.no>; Tue, 30 Jun 2009 15:12:40 +0000 (UTC)
Date: Tue, 30 Jun 2009 11:12:38 -0400
From: Andrew Sullivan <ajs@shinkuro.com>
To: idna-update@alvestrand.no
Subject: Re: Punycode Mixed-case annotation
Message-ID: <20090630151238.GB3059@shinkuro.com>
References: <B0AE4BA85E81614A8972EBC482F14971049DE322@mtv-exbe-3.ad.corp.google.com> <b789c2f00906280848p785f1701sbac1bf2f58312450@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <b789c2f00906280848p785f1701sbac1bf2f58312450@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-BeenThere: idna-update@alvestrand.no
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IDNA update work <idna-update.alvestrand.no>
List-Unsubscribe: <http://www.alvestrand.no/mailman/listinfo/idna-update>, <mailto:idna-update-request@alvestrand.no?subject=unsubscribe>
List-Archive: <http://www.alvestrand.no/pipermail/idna-update>
List-Post: <mailto:idna-update@alvestrand.no>
List-Help: <mailto:idna-update-request@alvestrand.no?subject=help>
List-Subscribe: <http://www.alvestrand.no/mailman/listinfo/idna-update>, <mailto:idna-update-request@alvestrand.no?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 15:12:46 -0000

On Mon, Jun 29, 2009 at 01:48:41AM +1000, Wil Tan wrote:
> checking the validity of the characters. I'm not aware of any
> side-effects of ASCII lowercasing, but do appreciate that the protocol
> steps must be very carefully considered.

Steve Crocker noticed that I didn't mention this, and I should have.

There is a draft floating around, and which has been implemented in at
least some servers and resolvers, that uses the upper and lower case
of a query as part of a strategy to effectively increase the
randomness available to resolvers in order to detect spoofed answers.
It's far from perfect, but it works in some cases.  In Stockholm,
DNSEXT will be contemplating whether to adopt this strategy (among
others) as a work item.

The draft is available from
http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 (or your
favourite repository of Internet Drafts).  The basic idea is that the
DNS spec be modified to REQUIRE that the labels as presented in the
question be copied back to the answer section.  The idea is that the
requesting client could randomize the 0x20 bit on the characters in a
label.  This way each character can be either upper or lower case, and
the client can then use the randomized labels as a sort of channel
back to itself; that would allow a client to detect an answer that did
not correctly echo the 0x20 arrangement of the request.  The idea is
that this allows a client to detect when a cache has been poisoned by
some other client's efforts.  (The details are off topic for this
list; if that description is too sketchy, please read the draft.)

The upshot of adoption of that work by the DNSEXT WG would not
actually affect this WG's work, since we're making changes prior to
any query going into the DNS itself.  That said, we might want to keep
this in mind when making decisions about what we can do with upper and
lower case ASCII (and, in particular, if we want to be sensitive to
such upper and lower case when the data comes back to us from the DNS
resolver level).

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.