Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 03 May 2012 21:59 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475CE21F86F7; Thu, 3 May 2012 14:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level:
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ej1lKeyDJ5i; Thu, 3 May 2012 14:59:28 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AE2E021F86E1; Thu, 3 May 2012 14:59:28 -0700 (PDT)
Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q43LxRZt080690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 May 2012 14:59:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <4FA2FB94.204@stpeter.im>
Date: Thu, 3 May 2012 14:59:26 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org>
References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <B7723E59-FA33-4D11-B6A6-40F54CD10ECE@nic.cz> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1257)
Cc: The IESG <iesg@ietf.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>, IETF DANE WG list <dane@ietf.org>
Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 May 2012 21:59:29 -0000

On May 3, 2012, at 2:41 PM, Peter Saint-Andre wrote:

> On 5/3/12 2:34 PM, Paul Hoffman wrote:
>> On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote:
>> 
>>> Perhaps this is simply a difference between folks who look at
>>> things from the DNS perspective and folks who look at things from
>>> the apps perspective (as users of DNS). All sorts of application
>>> protocols are being updated to support IDNs. Those applications
>>> will need to know how to translate their IDNs (which might consist
>>> of U-labels) into a form that can be placed into the DNS. To make
>>> things perfectly clear, I'm just suggesting that we add a sentence
>>> or two warning those who write code for application protocols using
>>> DANE that they might need to convert U-labels into A-labels. I'll
>>> work to propose specific text today or tomorrow.
>> 
>> 
>> I'll be interested to see that. I cannot see how anyone reading
>> Section 3 of RFC 5891 could think that they would *not* need to
>> convert to A-labels before looking up something in the DNS. If you
>> are saying that every post-5891 protocol that defines a new RRtype
>> must say "and if you are going to look up the domain name in the DNS,
>> convert to A-labels first", that's fine, but it seems kinda late to
>> start saying that.
> 
> Not everyone is as smart as you are.

If you believe that developers who are using IDNs are not following the easiest-to-read section of RFC 5891, the issue is much larger than just DANE. I propose that is not a DANE issue at all.

--Paul Hoffman