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

From: [email-masked]
Date: Wed, 08 Jan 2014 07:23:21 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

        Title           : Using Secure DNS to Associate Certificates with Domain Names For S/MIME
        Authors         : Paul Hoffman
                          Jakob Schlyter
	Filename        : draft-ietf-dane-smime-04.txt
	Pages           : 6
	Date            : 2014-01-08

Abstract:
   This document describes how to use secure DNS to associate an S/MIME
   user's certificate with the intended domain name, similar to the way
   that DANE (RFC 6698) does for TLS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smime/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-smime-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Jan 2014 16:01:56 +0000

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

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.  The truncated encoding:

    OZUWW5DPOI

carries identical information.

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.

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

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Jan 2014 08:48:09 -0800

> 36-39 octets cannot be represented when the "=" padding is part

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 seems rather wasteful.

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

>  The truncated encoding:

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.

> since such local parts remain valid, even though there are incompatible

You are right: we'll change to "incompatible" in the next draft.

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Jan 2014 17:13:10 +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.

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

> > (which decode to 20 bytes of input).
> >
> > [...]
> > 
> 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.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Jan 2014 16:01:56 -0500 (EST)

> 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 intr…

It's not _that_ hard:

paul@thinkpad:~$ python
Python 2.7.5 (default, Nov 12 2013, 16:45:54) 
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
>>> x = bas64.b32encode("PaulReallyIHaveNoMiddleNameAndThatOtherGuyIsNotMeAndIdontBowlEitherNorRunaNudeBeachInRotterdamWouters")
>>> [ x[i:i+60] for i in range(0, chunks, 60) ]
>>> ".".join([ x[i:i+60] for i in range(0, chunks, 60) ]).lower()
'kbqxk3csmvqwy3dzjfegc5tfjzxu22lemrwgkttbnvsuc3tekrugc5cporug.k4shov4us42on52e2zkbnzseszdpnz2ee33xnrcws5dimvze433skj2w4yko.ovsgkqtfmfrwqslokjxxi5dfojsgc3kxn52xizlsom======'

Similarly, it's easy to add a .strip("=")

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

In some sense, I'm more interested in skipping the '=' symbols because
some GUI's won't allow "=" in DNS names. Size does not really matter
to me.

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

That I agree with. I'd rather not do it if it is not a "real thing".

Paul

---

From: [email-masked]
Date: Thu, 09 Jan 2014 10:47:10 +0100

Zitat von Paul Hoffman <[email-masked]>:

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

Not followed closely on the topic but LHS part of e-mail addresses  
with more than 20 characters are common here in Germany because of the  
schema which uses <Vname>.<Nname>@domain. With the double lastname  
this will even get <Vname>.<Nname1>-<Nname2> in some cases. With names  
from other contries this could be even worse like the following  
(slightly modified) example show:

Dr.Massouf.Najani.Maryam.Nemari

Furthermore "descriptive" e-mail addresses are often used, for example  
"wirtschaftsrat-deutschland", "Redaktionsservice-Buch" and the like.

An short estimate on our input relay would be around 5% > 20  
characters and <1% with more than 30 characters. But IMHO one should  
try to avoid to limit the useable scope from the begining as far as  
possible, no?

Regards

Andreas

---

From: "Dickson, Brian" <[email-masked]>
Date: Thu, 9 Jan 2014 17:08:28 +0000

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

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

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 9 Jan 2014 17:39:43 +0000

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

An intriguing suggestion.  If the hash is HMAC-SHA1(domain, username),
its hex representation is 40 octets which fits comfortably into a
DNS label.  Dictionary harvesting attacks by following NSEC records
are a bit harder, since HMAC with the domain as a key makes the
use of rainbow tables less useful.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Thu, 09 Jan 2014 14:45:50 -0500

>>>>> "BD" == Brian Dickson <[email-masked]> writes:
>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

BD>> So instead of "encoding" per se, what about using a hash function?
BD>> ... re-use of the NSEC3 code might be reasonable

VD> An intriguing suggestion.

Very!

VD> If the hash is HMAC-SHA1(domain, username), its hex representation
VD> is 40 octets which fits comfortably into a DNS label.

As hex; and 40 hex vs 32 base32 isn't enough of a difference to warrant
adding extra code for base32.  A win overall.

Should anyone insist of hmac-sha256, though, base32 would be necessary.
But I've yet to see any credible claims that sha1's vulnerabilities
affect hmac-sha1, so there shouldn't be a reason for sha2 or sha3.

VD> HMAC with the domain as a key makes rainbow tables less useful.

If hmac nonetheless isn't used, then the nsec3 hash SHOULD be.

The issue of normalization (before hashing) remains, as foo will
generate a different hash than LHS or Lhs (or lHs), not to mention
the differences between NFC vs NFD (eg, <U+E4> vs <U+61 U+308>).

I like the idea of a published policy (perhaps using the token _policy)
to specify the details for that zone.  With lc(nfc(lhs)) as the default
policy, if none is specified.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 9 Jan 2014 20:56:04 +0000

> affect hmac-sha1, so there shouldn't be a reason for sha2 or sha3.

Indeed, but if one really wants to avoid HMAC-SHA1 because it is
now unfashionable, one can use SHA2-224 to get a 56-byte label.

Choices of canonicalization rules for the HMAC input are identical
to those for the base32 input.  Neither is particularly more amenable
to case-insensitive or other imprecise matching on the encoded output.

So it seems that there is little advantage to base32, and clear
disadvantages.  The only upside I can see for base32 is that with
HMAC the DNS administrator who forgets which user a given key is
for, can't easily recover that information, but he can with base32.
Keeping the user names "secret" is arguably a security feature when
DNS is outsourced.

A sensible administrator will keep the unhashed input names in a
configuration system that generates the corresponding DNS entries.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Jan 2014 19:26:51 -0500 (EST)

> now unfashionable, one can use SHA2-224 to get a 56-byte label.

SHA2-224 would have my preference, as SHA1 is on its way out FIPS-wise
and it is just easing not having to maintain SHA1 exceptions to the
"disallow sha1" code paths.

> configuration system that generates the corresponding DNS entries.

Yes, base32 is as unradable as a hash for the admin eye.

I think I'm fine with using sha2-224, if it saves us the hassle of doing
label splitting. But still a little worried about hashing various
character sets.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jan 2014 11:48:12 +1100

Whatever encoding is choosen can draft-ietf-dane-smime and
draft-wouters-dane-openpgp please use the same encoding method for
the local part.  I would even go so much as to say we should split
this out of both drafts and make it a seperate draft that they can
reference.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Jan 2014 00:49:54 +0000

> "disallow sha1" code paths.

I can live with HMAC SHA2-224.

> label splitting. But still a little worried about hashing various

Email addresses are still (multiple failed[*] attempts at SMTP + UTF-8
addresses notwithstanding) US-ASCII strings.  One can canonicalize
these via the identity map to UTF-8 if one wants to pretend otherwise.

-- 
	Viktor.

[*] RFCs that nobody implements do not count as success.

---

From: James Cloos <[email-masked]>
Date: Thu, 09 Jan 2014 21:02:36 -0500

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> Email addresses are still (multiple failed[*] attempts at SMTP + UTF-8
VD> addresses notwithstanding) US-ASCII strings.

One of the reasons for base32 in the original smime draft was that some
sites have local email addresses which differ only in case.

upper() vs lower() vs nothing(), as well as whether to strip some suffix
or other are still a valid local policy issue when normalizing the strings
before hashing or base32ing.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Jan 2014 02:17:46 +0000

> before hashing or base32ing.

How does this bear on the encoding lookup key labels? Any encoding
(e.g. base32, or HMAC-SHA-224, but not punycode) that does not map
input strings that differ only in case to output strings that differ
only in case offers no advantage over a 1-way hash function.

I am not sure what you're getting at.  Perhaps I'm missing something.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Jan 2014 19:21:53 -0800

> I am not sure what you're getting at.  Perhaps I'm missing something.

The person looking up someone's S/MIME or PGP cert either knows how the LHS is spelled (including exact case, and character encoding) or they don't. This issue is for a layer that is not ours.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jan 2014 14:59:32 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> The person looking up someone's S/MIME or PGP cert either knows how the LHS i
> s spelled (including exact case, and character encoding) or they don't. This 
> issue is for a layer that is not ours.

So a user has my address as "[email-masked]" (this is not made up,
some companies have it saved as that despite the fact that I entered
it in lowercase).  Is the MUA supposed to lowercase "MARKA" or not
before looking for a SMIME key?

>From my perspective there isn't a hard and fast answer to that.

We could publish rules, in the DNS, for the MUA to use so that it
doesn't have to guess.

Mark

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Jan 2014 08:23:18 -0800

> before looking for a SMIME key?

Again: this is an issue is for a layer that is not ours. The question is identical to whether or not your SMTP server will or will not accept both "marka" and "MARKA".

> We could publish rules, in the DNS, for the MUA to use so that it

We could. And the SMTP folks could do the same. Or we could finish this work in the next five years.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 10 Jan 2014 14:50:05 -0500 (EST)

On Fri, 10 Jan 2014, Mark Andrews wrote:

> the local part.

Yes we will, which is why I have  been waiting with posting an updated draft.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Mon, 13 Jan 2014 10:59:27 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> Again: this is an issue is for a layer that is not ours. The question is
> identical to whether or not your SMTP server will or will not accept both
> "marka" and "MARKA".

No it isn't.

The SMTP server for my addresses will treat the input as case
insensitive.

The input to this process is treated as case sensitive.  This means
that I have to enter records for:

marka, markA, marKa, maRka, mArka, Marka, marKA, maRKa, mARka, MArka,
maRkA, mArkA, MarkA, ...

to achieve parity.

Note both this draft and SMTP are taking email address as input, not
normalised email addresses.

> work in the next five years.

Yes, IDNA was a horrible protracted problem.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 12 Jan 2014 16:12:28 -0800

If you believe that the DANE WG gets to change the SMTP standard, there is not much we have to discuss, is there?

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Mon, 13 Jan 2014 12:16:49 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> If you believe that the DANE WG gets to change the SMTP standard, there =
> is not much we have to discuss, is there?
> 
> --Paul Hoffman=

Dane is *externalising* a function that in normally internal to SMTP.
Dane needs to address this issue.

This is like if the DNS was case sensitive.  gethostbyname would
have to downcase/uppercase the inputs to the DNS call and the data
entry would have to be similarly case converted.  Rather than doing
this it was decided that the keys would be case insensitive in DNS
lookups.

Mark