Subject: [dane] Email box mapping: Who is responsible ?

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 1 Apr 2015 09:19:29 -0400

Dear Colleagues 

<chair-hat off> 
I have been thinking about the issues in finding right email address format for a user. 
IMHO we need to take a step back and think about responsibilities, and expectations as well as goals.  

The goal is to create a simple way to find <email key> for a known correspondent. 
Can we assume that the email encryptor knows the address of recipients in a format emitted by the recipients email system, and is that good enough? 

Can we expect a User mail agent to look up many different form of an email address just to find an <email key> ? 

Can we expect a Email provider to publish users email key for number of variants of the users email address? 

There have been mentions of EMAIL oracle, and other methods to find “canonical address” for user. 

Are there simple rules we can apply to email addresses that decrease the number of combinations? 
For example we can apply lower case rule to the left hand side before hashing? 

<chair-hat off> 

<char-hat on> 
I think we can publish OPENPGPKEY draft as is tagging it as Opportunistic key lookup, if it has to be labeled EXPERIMENTAL that is fine. 
We  push the issues of canonical email discovery and techniques to improve finding keys for random email addresses into the OPENPGPKEY-usage document as
there are things that email receivers can do as well as what senders can do. 

Comments. 

Olafur

---

From: Jacques Latour <[email-masked]>
Date: Wed, 1 Apr 2015 13:25:38 +0000

+1

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Olafur
> Gudmundsson
> Sent: April-01-15 9:19 AM
> To: <[email-masked]>
> Subject: [dane] Email box mapping: Who is responsible ?
> 
> Dear Colleagues
> 
> <chair-hat off>
> Can we assume that the email encryptor knows the address of recipients in a
> format emitted by the recipients email system, and is that good enough?
> 
> I think we can publish OPENPGPKEY draft as is tagging it as Opportunistic key
> lookup, if it has to be labeled EXPERIMENTAL that is fine.
> We  push the issues of canonical email discovery and techniques to improve
> finding keys for random email addresses into the OPENPGPKEY-usage
> document as there are things that email receivers can do as well as what
> senders can do.
> 
> Comments.
> 
> Olafur
> 
> 
> 
> 
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Apr 2015 09:38:01 -0400 (EDT)

> Can we assume that the email encryptor knows the address of recipients in a format emitted by the recipients email system, and is that good enough?

I believe so.

> Can we expect a User mail agent to look up many different form of an email address just to find an <email key> ?

Whatever we say in the document, some User mail agents will probably
perform multiple lookups, especially for the [email-masked] case.

> Can we expect a Email provider to publish users email key for number of variants of the users email address?

That is very unlikely. See the VRFY command in SMTP.

> For example we can apply lower case rule to the left hand side before hashing?

I do think that lowercasing is a valid option that would reduce the
number one case of requiring CNAME's for the hash("Firstcaps") use case.
Even John wrote in his draft that:

    The most common variants are upper and lower case, which are now
    invariably treated as equivalent.

> I think we can publish OPENPGPKEY draft as is tagging it as Opportunistic key lookup, if it has to be labeled EXPERIMENTAL that is fine.

I would prefer it not be labeled EXPERIMENTAL. This draft isn't rocket science.

> there are things that email receivers can do as well as what senders can do.

As long as it is not decided to hold up this document over the -usage
document, or else we are just moving and re-opening this same discussion
again.

As for Stephen's comment regarding sha224. I honestly don't care that
much, but lean towards not manually cutting down hash lengths and let
cryptographers make those calls. Hence the use of sha224.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Apr 2015 14:47:46 +0100

> cryptographers make those calls. Hence the use of sha224.

We're not depending on either collision resistance or pre-image
resistance here so truncating sha256 is way better compared to
using a hash algorithm that is almost never used.

S.

---

From: "Rose, Scott W." <[email-masked]>
Date: Wed, 1 Apr 2015 10:09:36 -0400

>> Can we assume that the email encryptor knows the address of recipients in a format emitted by the recipients email system, and is that good enough?

I don't but then the credentials aren't found.  That is an answer - the client/end user will need to account for that.

> That is very unlikely. See the VRFY command in SMTP.

Some enterprises might if they feel it is important enough, but probably only the "big ones" like FLast and flast, etc.

> I would prefer it not be labeled EXPERIMENTAL. This draft isn't rocket science.

+1, Just having it opportunistic is enough.

> cryptographers make those calls. Hence the use of sha224.

I understand Stephen's reasoning and if it makes deployment easier for folks who need to pass audits, then let's do that. 

Scott

> Paul

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Apr 2015 10:44:54 -0400 (EDT)

> I don't but then the credentials aren't found.  That is an answer - the client/end user will need to account for that.

If you do not know the email address of John Doe, your first task is to
find out that email address. Once found, you can come back here and look
for a key. (if you have a key, you might also have the email address,
and you can verify the two are a set)

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Apr 2015 09:16:18 -0700

> there are things that email receivers can do as well as what senders can do. 

It does not have to be labeled "experimental". Saying that we know how to do exact-name lookup is not experimental at all.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2015 17:24:19 -0000

>system, and is that good enough? 

I have a stack of business cards on my desk about 10cm high.  Every
one has at least one e-mail address that I am presumably expected to
type in by hand.  (Two have QR codes, but they have text addresses,
too, which is good since my laptop doesn't have a QR scanner.)

With internationalized addresses, the fuzz problem gets a lot worse.
Domain names have normalization rules so there's no ambiguity about
whether to use the separate or precomposed accented letters and the
like. But internationalized local-parts remain totally opaque to the
sender.  I expect that inbound MTAs will do lots of normalization on
incoming addresses, but there is no way to predict from the outside
what they'll do, or what their internal normalized format will be.

This means that hand-typed internationalized addresses are unlikely to
match the internal form the recipient MTA uses without some
intermediate massaging, and nobody but the MTA knows what massaging to
do.

>I think we can publish OPENPGPKEY draft as is tagging it as Opportunistic key lookup,
> if it has to be labeled EXPERIMENTAL that is fine. 

That seems appropriate.  The design is well-defined, but we have no
experience to tell us whether it'll be workable in practice.  This
reminds me of the early EAI drafts which were also experimental.  The
address protocol was well defined, but it turned out to be unworkable in
practice, so for the standards track we did something different.

R's,
John

PS: I still don't understand the opposition to base32.