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

"Dickson, Brian" <> Thu, 09 January 2014 17:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DAC981ADF96 for <>; Thu, 9 Jan 2014 09:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I2r8x2SDMwYr for <>; Thu, 9 Jan 2014 09:08:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C5A2B1ADFB7 for <>; Thu, 9 Jan 2014 09:08:39 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 09 Jan 2014 09:08:31 PST
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id s09H8Ttn019829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jan 2014 12:08:29 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.02.0342.003; Thu, 9 Jan 2014 12:08:29 -0500
From: "Dickson, Brian" <>
To: Paul Hoffman <>, " list" <>
Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-04.txt
Date: Thu, 9 Jan 2014 17:08:28 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Jan 2014 17:08:43 -0000

On 1/8/14 11:48 AM, "Paul Hoffman" <> wrote:

>On Jan 8, 2014, at 8:01 AM, Viktor Dukhovni <>
>> On Wed, Jan 08, 2014 at 07:23:21AM -0800,
>>> 	Filename        : draft-ietf-dane-smime-04.txt
>> Given the use of base32 encoding, and explicit non-support for
>> names that encode to more than 63 bytes of base32 text

[snip, include all useful context ;-)]

>Yes it does. It also puts a burden on the application to use our new
>"base32ish" encoding instead of the base32 encoding they already have. In
>order to save five bytes.
>> Finally is the word "prohibited" appropriate in the new text:
>>       Also note that user names can be any length, and labels are
>>       limited to 63 octets.  Also note that user names that are
>>       encoded with Base32 are longer than the original user name.
>>       Any user name that would cause a label of longer than 63
>>       octets is expressly prohibited by this specification.
>> I would think "unsupported" or "incompatible" would be closer,
>> since such local parts remain valid, even though there are incompatible
>> with SMIMEA.
>You are right: we'll change to "incompatible" in the next draft.

Let's see if I understand the purpose of the original proposal (base32
encoding of local-part/"local part"), the limitations, and the

These are for deterministically putting something into DNS, and for
deterministically finding the thing that was put into DNS.
The RHS is the interesting thing (e.g. smime stuff), and the LHS just has
to be deterministic, right?

The input can be either non-international (arbitrary length ASCII
characters, bytes with first bit 0) or international (arbitrary length
strings of UTF8). Even adding a distinguisher between the two input sets,
at best would only optimize fixed-upper-limit functions (7 onto 5 or 8
onto 5 encoding schemes with 63 character max).

So instead of "encoding" per se, what about using a hash function?

It does not have to automatically be an existing hash function, although
re-use of the NSEC3 code might be reasonable.

All that matters is that the probability of hash collisions is very very
low, and perhaps the addition of some collision-mitigation would help.

LDH = 26 alpha + 10 digit + hyphen = 37 characters
37^63 is a big big number (about 100 decimal digits starting with "6").

It means on average the lhs is longer, but in practical terms removes the
upper limit on the encoding (since the hash function has no upper limit on

We're talking about stuff that hasn't yet been developed, right, so a
major shift in LHS stuff is no biggie?