Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt

Viktor Dukhovni <viktor1dane@dukhovni.org> Wed, 08 January 2014 17:13 UTC

Return-Path: <viktor1dane@dukhovni.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 D2B761AE4B5 for <dane@ietfa.amsl.com>; Wed, 8 Jan 2014 09:13:23 -0800 (PST)
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 jS9wsPrEyj8t for <dane@ietfa.amsl.com>; Wed, 8 Jan 2014 09:13:20 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 785D31ADFA0 for <dane@ietf.org>; Wed, 8 Jan 2014 09:13:20 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CEC092AB190; Wed, 8 Jan 2014 17:13:10 +0000 (UTC)
Date: Wed, 8 Jan 2014 17:13:10 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140108171310.GF2317@mournblade.imrryr.org>
References: <20140108152321.10496.88212.idtracker@ietfa.amsl.com> <20140108160156.GE2317@mournblade.imrryr.org> <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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: Wed, 08 Jan 2014 17:13:24 -0000

On Wed, Jan 08, 2014 at 08:48:09AM -0800, Paul Hoffman wrote:

> In the real world, there are few users who have LHS user names
> that are more than 30 (or maybe even 20) characters long. What you
> are proposing is "base32 but not really base32" and that could
> introduce errors in libraries looking up the names.

This encoding of localparts to DNS labels is one way only, to
generate query domain labels.  It is not used to encode data that
the consumer will need to decode.  If so, completely standard
encoding routines can be used to generate the base32 text, but the
output can be easily truncated at the first "=" sign.

There is no need to force up to 6 bytes of needless padding into
write-only DNS labels.

> > 	OZUWW5DPOI======
> > 
> > This seems rather wasteful.
> 
> Relative to, say, the size of a PKIX certificate? :-) 

You're right in  absolute terms, it is of course just 1-6 bytes of
waste.  In relative terms however, given the limits on label lengths
and DNS name lengths, every byte can count when you're close to
the limit.  The limits for X.509 certs are much more generous, they
to fit (as a complete chain) into a 16KiB SSL record.

> > One way to get around the length limit would be to break up long
> > encoded strings into multiple labels at each 32 bytes of output
> > (which decode to 20 bytes of input).
> >
> > [...]
> > 
> > Allowing for significantly longer local parts (ultimately limited
> > by the total length of a DNS fqdn when combined with the relevant
> > suffix derived from the domain part).
> 
> I think this is vast overkill for a rarely-needed use case, but
> I'm open to hear where people think LHS names longer than 35
> characters are used in places where S/MIME or PGP are also used.

I think we need to hear from some users with Spanish names who use
full names as local parts.  At previous employer IIRC we had
something along the lines of:

    Ferndando.Fernando.Fernandez@...

which is 28 bytes, perhaps 8 more is not as uncommon as we think,
but I have no examples.  Perhaps the histogram showing username
lengths at this link is useful:

http://www.eph.co.uk/resources/email-address-length-faq/#emailwildlength

The uptick around 30 bytes is interesting, but there is no indication
of sample size, and we don't how representative their dataset is.

-- 
	Viktor.