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

[Paul Hoffman <[e-mail]>]

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, I would
> like to suggest that trailing "=*" padding be explicitly dropped
> from the base32 label allowing for somewhat longer inputs and less
> redundant outputs.
> 
> With base32, every 5 octets of input text encode to 8 octets of
> encoded text, therefore 35 octets encode to 56 octets, but anything
> longer encodes to 64 octets which is too long.  Thus inputs with
> 36-39 octets cannot be represented when the "=" padding is part
> of the encoded text.

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.

> Also, with say "6" octets of input, e.g. "viktor", we have 48 bits
> of input which encodes to 9 full octets of 5 bit per octet output,
> plus a short 3 bit encoded octet, and then *7* octets of padding:
> 
> 	OZUWW5DPOI======
> 
> This seems rather wasteful.

Relative to, say, the size of a PKIX certificate? :-) 

>  The truncated encoding:
> 
>    OZUWW5DPOI
> 
> carries identical information.

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.

> 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).  Thus the encoding of "Base32
> is a notation for encoding arbitrary byte data using a restricted
> set of symbols":
> 
>    IJQXGZJTGIQGS4ZAMEQG433UMF2GS33O
>    EBTG64RAMVXGG33ENFXGOIDBOJRGS5DS
>    MFZHSIDCPF2GKIDEMF2GCIDVONUW4ZZA
>    MEQHEZLTORZGSY3UMVSCA43FOQQG6ZRA
>    ON4W2YTPNRZQ			// trailing "====" truncated
> 
> would result in a multi-label DNS prefix of:
> 
>    ijqxgzjtgiqgs4zameqg433umf2gs33o.ebtg64ramvxgg33enfxgoidbojrgs5ds.mfzhsidcpf2gkidemf2gcidvonuw4zza.meqhezltorzgsy3umvsca43foqqg6zra.on4w2ytpnrzq
> 
> 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.

--Paul Hoffman