Subject: [dane] E-mail Cert left hand side -- what the chairs think the consensus is

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 1 Sep 2015 14:44:37 -0400

Dear Colleagues 

We received some questions about the selection. 
In the discussions on the different ways to represent the left hand sides as DNS names there are number of ways the three ways we have been discussing are:
a) HEX( SHA256( LHS) [:28]))  i.e. 28 left most bytes of SHA256 hash hexified 
b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the email name is lower cased before digesting, this will help mainly email addresses written in Latin-1 
c)  split_lables(HEX(LHS), 60))    i.e. encode the email as a HEX, there are two drawbacks and one advantage see below 

a) and b) both are fixed length and fit in one label, c) on the other hand may require multiple labels 
c) in theory allows server that sees query may apply rules that allow it to give out better answers 
c) on the other hand also has privacy issues against a passive “attacker” i.e. one that only listens to traffic, it can w/o any work discover email addresses, a) and b) require work by attacker to discover the email address (reverse/guess the HASH()) . There was pushback due to the privacy issue. 

The difference between a) and b) is the lower casing. While this may be a win in some cases that is unproven, as we do not know if more people will know or guess the LHS they want to send to. 
In addition the DNS contains a simple facility to equate names i.e. CNAME.

Olafur & Warren

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 01 Sep 2015 21:00:22 +0200

I think one should combine:

1. Whatever the left hand side is in the traditional RFC822 envelope address

2. Case folding, so that it is surviving whatever basic matching in email clients/services

3. Hash, if nothing else for privacy reasons

So, I guess (b) is the closest, but I want to be more specific it is "the ascii/fallback" version of the local part and not (for example) the internationalized version -- while supporting potential future UTF-8 encoded raw addresses. I.e. use whatever localpart is used in the SMTP protocol. But I guess that is what you mean with LHS?

   Patrik

On 1 Sep 2015, at 20:44, Olafur Gudmundsson wrote:

> a) HEX( SHA256( LHS) [:28]))  i.e. 28 left most bytes of SHA256 hash hexified b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the email name is lower cased before digesting, this will help mainly email addresses written in Latin-1 c)  split_lables(HEX(LHS), 60))    i.e. encode the email as a HEX, there are two drawbacks and one advantage see below
>
> a) and b) both are fixed length and fit in one label, c) on the other hand may require multiple labels c) in theory allows server that sees query may apply rules that allow it to give out better answers c) on the other hand also has privacy issues against a passive “attacker” i.e. one that only listens to traffic, it can w/o any work discover email addresses, a) and b) require work by attacker to discover the email address (reverse/guess the HASH()) . There was pushback due to the privacy issue.
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Brian Dickson <[email-masked]>
Date: Tue, 1 Sep 2015 20:14:41 -0400

I think the safest choice is a).

Here's the logic that applies to a) vs b), which I think leads to
choice a) being preferred.
Suppose there is a domain where email addresses are case-sensitive.
(RFC822 et al permit this.)
Suppose there is a case-folded collision (two LHS addresses differ
only by case).

What happens if you want to encrypt ONLY to the correct recipient? You
need some way to identify the correct public key from among the two
(or more!) colliding LHS values, or you are forced to encrypt with all
the keys found. This is an undesirable security and/or privacy risk
introduced by the use of str2lower.

Or, alternatively, how do you associate the correct key with the
correct recipient, in a way that does not also leak the non-SHA256'd
address to a passive observer? I don't think you can.

These questions are mooted in choice a), since there is no case
folding and thus no collision.

So, I think the choice between a) and b) is a no-brainer: a).

Brian

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Sep 2015 23:10:02 -0400 (EDT)

> What happens if you want to encrypt ONLY to the correct recipient?

What is "the correct recipient" in that case? Your supposed use case
would consist of say [email-masked] and [email-masked] being different
people. These two people would already regularly receive each other's
email. When you tell someone your email over the phone, do you say
"brian dot peter dot dickson at gmail dot com" or do you say
"lowercase brian dot lowercase peter dot lowercase dickson at gmail dot
com"?

This simply does not happen in the real world.

> So, I think the choice between a) and b) is a no-brainer: a).

I disagree. You are solving a non-existent case at the experience of
a real life case of auto-capitalization.

For example, today I logged in on "bluejeans.com" using their ios app,
and their app changed my username input of "[email-masked]" to
"[email-masked]". It wasn't even a dictionary word/name and it
got capitalized.

In the real world therefor, option a) is the worst choice.

Paul

---

From: Michael Kliewe <[email-masked]>
Date: Wed, 2 Sep 2015 11:59:33 +0200

b) is the most practical solution, I don't know ANY mail provider or
private mailserver that handles local parts case-sensitive...

a) would be more correct. And I would suggest an additional DNS record
for "rules", like TXT="nodots,lower,subaddressing:+" for Gmail (I hope
it's correct) and maybe just "lower" for most others. The mail provider
can publish this rule, and clients that want to help the enduser can
apply it to the local part before querying for the OPENPGPKEY/SMIME
record... The only drawback is that you need 2 DNS queries, but does
anybody notice these additional 50ms? And the most used "rules" can be
cached or hardcoded into the client.
With this you are most flexible, you don't have unwanted collisions, and
it's a solution that can be fully automated and secure for encryption
gateways.
You even could think about a "domain-salt" that could be added to the
"rules" TXT record, so that "info" in domain.com is not the same as
"info" in domain.org... Then an attacker needs a rainbow table per
domain, and not one global rainbow table...

c) is no option (privacy)

Michael

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 02 Sep 2015 07:30:11 -0700

On 1 Sep 2015, at 11:44, Olafur Gudmundsson wrote:

> In the discussions on the different ways to represent the left hand 
> sides as DNS names there are number of ways the three ways we have 
> been discussing are:
> b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the 
> email name is lower cased before digesting, this will help mainly 
> email addresses written in Latin-1
> c)  split_lables(HEX(LHS), 60))    i.e. encode the email as a HEX, 
> there are two drawbacks and one advantage see below
>
> c) on the other hand also has privacy issues against a passive 
> “attacker” i.e. one that only listens to traffic, it can w/o any 
> work discover email addresses, a) and b) require work by attacker to 
> discover the email address (reverse/guess the HASH()) . There was 
> pushback due to the privacy issue.
>
> The difference between a) and b) is the lower casing. While this may 
> be a win in some cases that is unproven, as we do not know if more 
> people will know or guess the LHS they want to send to.

All of the options have operational plusses and minuses that we can't 
actually measure until after we deploy. (a) seems most in line with the 
mail standards we are using. That is a strong argument for (a).

--Paul Hoffman

---

From: "Rose, Scott" <[email-masked]>
Date: Wed, 2 Sep 2015 10:36:13 -0400

> actually measure until after we deploy. (a) seems most in line with 
> the mail standards we are using. That is a strong argument for (a).
>
> --Paul Hoffman
>

Another ‘+1’ for (a).  I kind of feel (b), may make discovery 
easier, but not sure and we will never know unless we deploy.  (a) is 
simpler and after some deployment we may find out that cert discovery is 
not that difficult, not desired, or easily done another way.

Scott

==================================
Scott Rose, NIST
[email-masked]
ph: +1-301-975-8439
Google Voice: +1-571-249-3671

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Sep 2015 14:41:56 +0000

> a) HEX( SHA256( LHS) [:28]))  i.e. 28 left most bytes of SHA256 hash hexified 

Once we're hashing, there's no point in making the hashes needlessly
long, so if we're hashing "a" of course.

> email name is lower cased before digesting, this will help mainly email
> addresses written in Latin-1

No, this would be a second lookup, if the original input in "a" is
not lower-case, and if MUAs choose to do that.

> c)  split_lables(HEX(LHS), 60))    i.e. encode the email as a HEX, there are two drawbacks and one advantage see below 

This is the "low-privacy" unhashed option, which supports hypothetical
nameservers that can canonicalize the address and perform on-the-fly
signing.  If such servers are unlikely to materialize, then "a" is
better.  If, on the contrary, large providers are likely to implement
such nameservers, then "c" is better.

I thought that there was a recent rough consensus to hash, but if
there's not, it is not clear that we have enought information to
choose between "a" and "c".

I'll be at M3AAWG35 in Atlanta in late October, and will be askin
the large providers what they think about all this, and also Keith
Moore's "addrquery" draft by comparison.

Of course that's still 7 weeks away, and I may not get any feedback
to report...

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 2 Sep 2015 21:18:12 +0200

> On 2 sep 2015, at 16:41, Viktor Dukhovni <[email-masked]> wrote:
> 

Consensus was declared by the chairs August 6th 2015 in [1] and both the OpenPGP and S/MIME drafts has been updated since. I believe/hope Olafur's revisit in this thread sought to clarify the pre-consensus options, not to stir things up again.

	jakob

[1] Message-ID: <[email-masked]>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 2 Sep 2015 15:33:16 -0400

> On Sep 2, 2015, at 3:18 PM, Jakob Schlyter <[email-masked]> wrote:
> 
> 

To clarify 
The chairs were trying to clarify the background of their consensus call. 
We are not trying to change consensus at this point in the working group. 

The OPENPGP document is in IETF last call, if the chairs made the wrong call please put that comment to the IETF last call 
thread. 

   Olafur