Re: [dane] draft-wouters-dane-openpgp-01 review

Mark Andrews <marka@isc.org> Tue, 07 January 2014 05:26 UTC

Return-Path: <marka@isc.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146571AE435 for <dane@ietfa.amsl.com>; Mon, 6 Jan 2014 21:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.239
X-Spam-Level:
X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] 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 feQQSjsm5buY for <dane@ietfa.amsl.com>; Mon, 6 Jan 2014 21:26:37 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 25DF61AE434 for <dane@ietf.org>; Mon, 6 Jan 2014 21:26:37 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 1EF082383D7; Tue, 7 Jan 2014 05:26:15 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E82DC1602B4; Tue, 7 Jan 2014 05:36:31 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 84FC8160050; Tue, 7 Jan 2014 05:36:31 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4EBA9C79C09; Tue, 7 Jan 2014 16:27:24 +1100 (EST)
To: Paul Wouters <paul@nohats.ca>
From: Mark Andrews <marka@isc.org>
References: <E05CBC7F-1B37-49A0-9E27-D2B52BFA48A9@ogud.com> <20140107021142.A6C6BC772A3@rock.dv.isc.org> <alpine.LFD.2.10.1401062246300.5833@bofh.nohats.ca>
In-reply-to: Your message of "Mon, 06 Jan 2014 23:30:54 -0500." <alpine.LFD.2.10.1401062246300.5833@bofh.nohats.ca>
Date: Tue, 07 Jan 2014 16:27:24 +1100
Message-Id: <20140107052724.4EBA9C79C09@rock.dv.isc.org>
Cc: "dane@ietf.org list" <dane@ietf.org>
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 07 Jan 2014 05:26:40 -0000

In message <alpine.LFD.2.10.1401062246300.5833@bofh.nohats.ca>ca>, Paul Wouters wr
ites:
> On Tue, 7 Jan 2014, Mark Andrews wrote:
> 
> Thanks for the review Mark.
> 
> > Section 3.1 has lots of factually incorrect rationals for
> > encoding using base32.  The DNS is capable of encoding
> > binary data in labels up to 63 octets.  I've got no problem
> > with encoding, but if one intends to include rationalisations
> > please make them factually correct.
> 
> I took those from draft-hoffman-dane-smime-01, Paul Hoffman and
> Jacob Schlyter believe these to be right as well? Can you explain
> what's wrong or perhaps write a replacement paragraph that would
> agree with you more? It's mostly there to explain why we did not
> end up using username._openpgpkey.domain.com and require base32 encoding.
> 
> > There is no mention of how to encode LHS which exceed 63 octets
> > when encoded using base32.  Pack the left most labels or the
> > right most labels?
> 
> Is that really a use-case we need to cover?

Yes.  Lots of mail systems use real names and some people have long names.

> How many _real_ +- 50+ LHS character email addresses do people use?

The fact that you can't answer that is the reason you need to support
them.

> I'm happy to document the
> limitation, a little more reserved for specifying tricks to go beyond.
> For example, http://tools.ietf.org/html/rfc6763 mentions this limit too
> in context of UTF8,unicode,Kanji without defining anything to extend
> this limit.
>
> > There is no mention of how to normalise LHS prior to base32 encoding.
> 
> That was discussed offline, but you are right in that the result of
> that discussion is missing. Since there seems to be great variety in
> how SMTP servers normalise the LHS, we did not want to enforce our
> one normalisation.

I didn't say enforce one normalisation, though you should specify
how to handle all the forms of Postmaster as that is required to
be treated as a case insensitive value.

> > Are "Hugh" and "hugh" the same?
> 
> That really depends on the SMTP server implementation, the OS it runs
> on, the email client used by the sender, etc.
> 
> > Should "hugh" and "hugh+xxx" be treated the same?
> 
> I don't think so? The "+" sign as magic "this is the same user as"
> is also not a feature supported by all SMTP servers or specified in
> a standard, correct? And people might want to use different keys for
> paul+personal versus paul+ietf.

And this is not a decision that needs to made by us.  This is a decision
that should be made by the publisher of the data.  One could even have
a rule which says "if *+* try as is and on nxdomain try /\(*\)+*/\1/"

> > It should be possible to specify normalisation
> > rules and store them at _openpgpkey.
> 
> But those rules could change if the SMTP implementation changes?

So you update the rules.
 
> So, this document is leaving these as unclear as whether your email
> will arrive at all or not based on the presence or absence of
> normalisation rules of the SMTP server.

This is about how to discover the pgp key stored in the DNSN for a
user given a email address.

I know that my email address is in various databases as "marka@isc.org"
and "MARKA@ISC.ORG" despite me entering it as "marka@isc.org" in
all cases.  I still want those who have stored the address as
"MARKA@ISC.ORG" to be able to find my PGP key.  I do not want to
have to add 31 CNAME records to the DNS to account for all the
permutations of MaRkA.

> > It might be useful to suppress the padding at the end of base32
> > encoded strings.  We already do similar suppression with NSEC3
> > records.
> 
> Unlike NSEC3 we will see some interaction with userland tools and humans
> that will use stock base32 that produces the padding. So I have a slight
> preference to stick with the output generated by standard base32 code in
> the hope that it will be less confusing to users and developers.

s/=*// 

> Paul
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org