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

["Dickson, Brian" <[e-mail]>]

On 1/8/14 11:48 AM, "Paul Hoffman" <[e-mail]> wrote:

>On Jan 8, 2014, at 8:01 AM, Viktor Dukhovni <[e-mail]>
>wrote:
>
>> On Wed, Jan 08, 2014 at 07:23:21AM -0800, [e-mail]
>>wrote:
>> 
>>> 	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
counter-proposals.

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
input).

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

Brian