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

From: "Larsen, Todd" <[email-masked]>
Date: Thu, 6 Feb 2014 17:28:51 +0000

Victor,

Good questions. Here are my answers. 
Not advocating a position.

> On Thu, Feb 06, 2014 at 03:36:57PM +0000, Larsen, Todd wrote:
>
>> Agreeing with Eric's point to ensure the UC 4 discussion doesn't focus 
>> on certificate revocation.
>> 
>> Use case 4 for SMIMEA does not revoke a certificate. Rather, the 
>> domain revokes an S/MIME user. In contrast to any evidence the user 
>> has to claim association, the domain is positively stating that user X 
>> is not valid for SMIME applications. I consider that substantially 
>> different from the absence of a DANE record (or addition of a bogus 
>> record to force validation failure).
>
>This is problematic because I expect that SMIMEA like TLSA generally yields 
>an RRset, not a single record. What would be the semantics of an RRset with 
>two RRs one with CU=4 and another with CU=2?
>

CU=4 trumps CU=2. Other records present with CU=4 would clearly 
indicate a misconfiguration, but must be accounted.

This complicates validation logic. It means checking for CU=4 in entire RRSET 
instead of declaring valid on first match.

One example of use could be for a domain to wildcard CU=2 record so
all certificates signed by the organization are considered valid by default. 
Disallowed users receive CU=4 for lifetime of TA cert. NSEC3 may not be 
necessary as public knowledge of CU=4 list might be desirable. 

(Not suggesting this in lieu of CNAMEs to CU=2 record(s), just presenting possible use case)

>It still seems simplest to list no RRs for a user to indicate that there are no 
>keys for that user.
>
>If CU=4 is supposed to disavow all keys for a user, what is the meaning of the 
>selector, matching type and associated data, ...

selector, matching type and associated data have no meaning for CU=4. The fields
are present solely to maintain consistency with the SMIMEA format

--
 Viktor.
_______________________________________________
dane mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Feb 2014 19:53:22 +0000

On Thu, Feb 06, 2014 at 05:28:51PM +0000, Larsen, Todd wrote:

> selector, matching type and associated data have no meaning for
> CU=4. The fields are present solely to maintain consistency with
> the SMIMEA format

This is IMHO an unreasonable distortion of the SMIMEA semantics.

Switching gears, was any consensus reached on the endoing of the
query label?  A truncated HMAC seems to offer better usability than
base32.  I think that the specification is in good shape, modulo
the query label encoding.  

--
	Viktor.

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 6 Feb 2014 20:17:10 +0000

On Feb 6, 2014, at 2:53 PM, Viktor Dukhovni <[email-masked]> wrote:

<snip>

> the query label encoding.  

I actually have a question on this: is there some reason we are talking about HMAC instead of just straight-up using a hashing function?  iirc, hashing accomplishes the same goal (for us) w/o needing any secret material (projecting a variable length name to a fixed length label).  I'm fully willing to believe that I might just be missing something.  I mean this just as a simple clarification question.

Thanks,

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Feb 2014 20:39:28 +0000

On Thu, Feb 06, 2014 at 08:17:10PM +0000, Osterweil, Eric wrote:

> I actually have a question on this: is there some reason we are
> talking about HMAC instead of just straight-up using a hashing
> function?  iirc, hashing accomplishes the same goal (for us) w/o
> needing any secret material (projecting a variable length name to
> a fixed length label).  I'm fully willing to believe that I might
> just be missing something.  I mean this just as a simple clarification
> question.

HMAC was proposed to *salt* the hash with a domain-specific key
(namely the domain itself).  The key is NOT secret, but it is
distinct for every domain (encoded in punycode for IDNA domains).

The reason for salting the lookup keys is to make dictionary attacks
on the set of email addresses more expensive.  One could even
NSEC3-style require some number of iterations, but this would
arguably be going too far and there is not a good way to signal to
the client what the iteration count should be.

Clearly any kind of one-way function is harder to brute-force invert
than the trivially reversible base32.  And salting makes rainbow-tables
less practical.  Still Bitcoin mining has led to rather fast hash
dictionary attack codes, and perhaps even salted HMAC is fast enough
to make DNS lookup a viable directory harvesting (via DNS lookup)
attack vehicle.

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 6 Feb 2014 22:51:28 +0100

> the query label encoding.  

Yes, we're looking at doing a plain sha224 for the LHS lookup instead of base32. Paul Wouters will provide some draft text for both documents (S/MIME & PGP). I would say we have consensus for HMAC-sha224 yet, but that's something we can discuss further.

	jakob

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Feb 2014 21:57:42 +0000

On Thu, Feb 06, 2014 at 10:51:28PM +0100, Jakob Schlyter wrote:

> Yes, we're looking at doing a plain sha224 for the LHS lookup
> instead of base32. Paul Wouters will provide some draft text for
> both documents (S/MIME & PGP). I would [not] say we have consensus for
> HMAC-sha224 yet, but that's something we can discuss further.

I think that HMAC-sha224 would be wiser, since otherwise a single
dictionary works for all domains.  The key should be the domain
name.  The question is I think not whether HMAC is necessary, but
rather whether it is sufficient, one might argue for iterated HMAC
with a reasonably high iteration count (unfortunately fixed, but
Moore's law will end any day now, ... promise! )

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 6 Feb 2014 17:12:18 -0800

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
> Sent: Thursday, February 06, 2014 1:58 PM
> To: [email-masked]
> Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
> 
> > > base32.  I think that the specification is in good shape, modulo the
> > > query label encoding.
> >
> > Yes, we're looking at doing a plain sha224 for the LHS lookup instead
> > of base32. Paul Wouters will provide some draft text for both
> > documents (S/MIME & PGP). I would [not] say we have consensus for
dictionary
> works for all domains.  The key should be the domain name.  The question
is I
> think not whether HMAC is necessary, but rather whether it is sufficient,
one
> might argue for iterated HMAC with a reasonably high iteration count
> (unfortunately fixed, but Moore's law will end any day now, ... promise! )

A trivial way to avoid the global dictionary is to simply hash the email
address - that is both the local part and the domain.  This would make it
unique for each domain.

Jim

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Feb 2014 17:26:55 -0800

Why are we trying to make the names any more difficult to walk through than they would be for SMTP? The use of the hash was *purely* to allow longer LHSs, not to prevent enumeration. Enumeration has never been considered a serious problem for SMTP, and we should not be complicating our protocol to prevent it. Hash-of-LHS is simple and not prone to any misunderstanding.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 7 Feb 2014 01:48:09 +0000

> address - that is both the local part and the domain.  This would make it

This also works, but is twice as fast as HMAC, where as my concern
is that even HMAC is too fast.  Of course a factor of 2 is not a
real deterrent.  So I must admit that there is no compelling reason
to prefer HMAC over SHA2-224, provided the hash covers the domain.

Perhaps I should mention the fact that in order to perform the
off-line dictionary attack the attacker first has to discover a
large fraction of the domain's NSEC3 records (assuming the domain
does not provide NSEC records) and then dictionary attack the NSEC3
RRs.  Thus he at least has to perform multiple NSEC3 hash iterations
(far too few sadly to prevent off-line discovery of the most common
user names).

The iteration counts for NSEC3 are additive with respect to any
iterations we might impose on the SMIMEA lookup key, rather than
multiplicative because at any given time for a given zone all NSEC3
RRs have the same salt, and thus for each guess at a user name it
is easy to compute the SMIMEA query domain, and thus the corresponding
NSEC3 value for the current zone salt.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 7 Feb 2014 02:02:01 +0000

On Thu, Feb 06, 2014 at 05:26:55PM -0800, Paul Hoffman wrote:

> Why are we trying to make the names any more difficult to walk
> through than they would be for SMTP? The use of the hash was *purely*
> to allow longer LHSs, not to prevent enumeration. Enumeration has
> never been considered a serious problem for SMTP, and we should
> not be complicating our protocol to prevent it. Hash-of-LHS is
> simple and not prone to any misunderstanding.

SMTP does not yield an efficient offline attack.  There exist
popular milters that attempt to thwart "directory harvesting
attacks".

Once there's a hash, it should at least (at no extra cost) include
the domain, to make the attack require per-domain computations.

However, what I forgot to take into account is that with DNSSEC
what the attacker learns are the NSEC3 hashes of the email address
query domain, so a single dictionary is already not an option
because the NSEC3 RRs need to be cracked and these are already
salted with the domain and additional salt value.

So the offline attack is already a per-domain attack even without
salting of the hashed label.  Thus perhaps including the domain is
not essential (but no reason not to).  What could offer much better
protection is O(100,000) iterations (i.e., O(0.1) CPU second to
compute a lookup key).  An interactive user may not notice, but a
legititmate bulk email engine sending encrypted mail may run into
noticeable latency.

I am not strongly advocating for this, more thinking out loud, in
case the issue resonates with the group.

-- 
	Viktor.

---

From: Tom Ritter <[email-masked]>
Date: Fri, 7 Feb 2014 05:56:12 -0500

> case the issue resonates with the group.

I saw it mentioned, but when I ran into a similar situation, I got
hung up with the normalization/canonicalization process.
Capitalization ('Mark' vs 'mark') and in other languages and Suffixes
([email-masked] vs [email-masked] and other configurable
characters) being the foremost.

No hashing allows a server to go to lengths to set up a DNS response
that matches their implementation (e.g. perhaps my suffix character is
'G') - hashing either takes that ability away from servers or creates
a way-too-complicated algorithm with unacceptable back-and-forth 'What
is your suffix character' queries.

I lean away from hashing, in favor of robust anti-spam solutions that
take into account things like sender DKIM and SMIME. That said, I also
recognize the value in trying not to decrease security (actual or
perceived) from what is actually deployed milter software.

-tom

---

From: Paul Wouters <[email-masked]>
Date: Fri, 7 Feb 2014 12:57:09 -0500 (EST)

On Thu, 6 Feb 2014, Viktor Dukhovni wrote:

> dictionary works for all domains.

So what, telnet'ing to port 25 and issuing HELO and RCP TO: is cheaper
already.

As PaulH said, this is not a security feature - it's only meant as a
method to be able to store any LHS username in DNS.

Straight sha224, no hmac.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 7 Feb 2014 13:00:07 -0500 (EST)

On Fri, 7 Feb 2014, Viktor Dukhovni wrote:

> SMTP does not yield an efficient offline attack.

Since when are spamming botnets interested in offline attacks to harvest
email addresses? Botnets just sent to every random character combo @
domain.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 7 Feb 2014 18:11:29 +0000

> So what, telnet'ing to port 25 and issuing HELO and RCP TO: is cheaper

There's a difference between online and off-line attacks.  

For an NSEC zone, if the hash does not include the full address,
the attacker can trivially perform a lookup in a pre-computed
domain-indendent dictionary.  Thus the usernames are easily recovered
off-line.  So if you don't do HMAC, you must hash the full address,
not just the localpart.

For an NSEC3 zone, the attacker gets lightly iterated salted hashes
of the query fqdn, and needs to compute the same for each guess of
a plausible user name.

Bottom line, hash the full address, not just the localpart.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 7 Feb 2014 18:41:55 +0000

> email addresses? Botnets just sent to every random character combo @

Since a time in the future when it becomes possible. :-)

There'll probably be a service selling the harvested addresses to
spammers.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 7 Feb 2014 11:08:20 -0800

> There'll probably be a service selling the harvested addresses to

Those existed 15 years ago, and still do. The proposal to make it slightly harder for a harvester (and that's all we're suggesting) adds complexity and no measurable value.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 7 Feb 2014 19:49:33 +0000

On Fri, Feb 07, 2014 at 11:08:20AM -0800, Paul Hoffman wrote:

> Those existed 15 years ago, and still do. The proposal to make
> it slightly harder for a harvester (and that's all we're suggesting)
> adds complexity and no measurable value.

Yes, adding iterations would definitely add complexity.

Arguably HMAC(domain, localpart) is more complex than
SHA(localpart@domain), I don't care which is used.

Either way of computing the hash of the full address, rather than
just the local part adds no complexity, and makes off-line attacks
more difficult (per site dictionaries, rather than global dictionaries).
This is a free win.  There's simply no reason not to.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 8 Feb 2014 00:58:51 -0000

>There'll probably be a service selling the harvested addresses to

Harvesting off the web will always be easier.  I have to say this
feels like a solution in search of a problem.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 8 Feb 2014 00:58:51 -0000

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Fri, 7 Feb 2014 20:49:13 -0500 (EST)

> There's a difference between online and off-line attacks.

$ wc -l /usr/share/dict/words
479828 /usr/share/dict/words

$ head -100000 /usr/share/dict/words > /tmp/10k
$ time (for word in `cat /tmp/10k`; do echo -n "$word.nohats.ca" | sha224sum; done > /dev/null)
real	3m9.064s

And that's using only 1 cpu, and a horrible shell kludge.

I'm sure the spammers have awesome LHS dictionaries gathered over the
years. Your proposal does not actually add any security.

You'd have to also ratelimit DNS queries if you go down the path of the
hash being a security feature.

> of the query fqdn, and needs to compute the same for each guess of

Why do i need to follow the hashes? I'll just brute force a dictionary
list and sent queries. Whether I sha2-224 that once, or once per domain,
is not that big of a difference. hashing is cheap.

> Bottom line, hash the full address, not just the localpart.

what's next? using scrypt? pbkdf2?

The hashing is not a security feature. Hashing the domain brings in
other problems, such as case sensitivity that changes hashes but not
DNS names.

Also, not using the domain name allows for CNAME/DNAME entries, so for
example I can add the same record in my "libreswan.org" zone that is
used as DNAME for libreswan.{net|com|ca|fi|nl}. Adding the domain into
the hash would break this setup.

Seriously, if spammers use the location of SMIME/OPENPGPKEYs to find
email addreses's WE HAVE WON THE CRYPTO WARS!

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 8 Feb 2014 03:03:46 +0000

> years. Your proposal does not actually add any security.

If that's the group consensus, fine.  Though it seems to me that
including the domain in the hash is essentially free, so why not?

> >Bottom line, hash the full address, not just the localpart.

I just thought you'd do the simplest thing that costs nothing and
turns the attack from a single dictionary into a per-sites attack.
I did not see any downside.

> other problems, such as case sensitivity that changes hashes but not

Don't see how.  The domain would be canonicalized to lower case
before hashing, just as with NSEC3.

> the hash would break this setup.

Indeed hashing the domain would cause a problem with DNAMEs.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 8 Feb 2014 03:52:03 +0000

> Indeed hashing the domain would cause a problem with DNAMEs.

Or not, note that just becase example.com is a CNAME for example.net
does not mean that [email-masked] is the same *mailbox* (email
recipient) as [email-masked].  Nothing in SMTP makes it so, and
some people in fact use multiple domains hosted at the same target
as independent namespaces.  So from that perspective, hashing the
domain actually better matches SMTP semantics.  It avoids conflating
addresses that are cannot be presumed to be equivalent.

-- 
	Viktor.

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 13 Feb 2014 18:19:15 +0000

> This is a free win.  There's simply no reason not to.

I have to say that I agree with Paul here.  I think the epsilon increase in security is nice, but not at the cost of the additional operational complexity.  However, the hashing-only approach has the nice side effect of fixing the label length.  That _does_ seem to solve a problem w/o some of the additional complexity.  My vote would be hashing-only approach over Base32 and HMAC.

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 13 Feb 2014 18:24:53 +0000

On Thu, Feb 13, 2014 at 06:19:15PM +0000, Osterweil, Eric wrote:

> I have to say that I agree with Paul here.  I think the epsilon
> increase in security is nice, but not at the cost of the additional
> operational complexity.  However, the hashing-only approach has
> the nice side effect of fixing the label length.  That _does_ seem
> to solve a problem w/o some of the additional complexity.  My vote
> would be hashing-only approach over Base32 and HMAC.

In an off-list IM discussion, Paul H. and I reached consensus on
local-part only hashing.  His argument is based on the introduction
of root zone DNAME RRs that create equivalence between large subtrees
of the DNS namespace.  Users will likely expect these to result in
equivalence of email addresses, ... so having SMIMEA lookup labels
that work relative to multiple equivalent domain FQDNs is then a
requirement.

So I withdraw the suggestion to salt the lookup key with the domain.

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 13 Feb 2014 15:43:27 -0500

On Thu, Feb 13, 2014 at 1:24 PM, Viktor Dukhovni
<[email-masked]> wrote:
> of the DNS namespace.

Doh! Yeah, that's a really good point -- there have been a number of
similar discussions recently where DNAME has thrown a spanner into the
works / hasn't been considered.

W
> Users will likely expect these to result in