Subject: Re: [ietf-smtp] New Mailing List to discuss email canonicalization?

From: John C Klensin <[email-masked]>
Date: Fri, 22 Apr 2016 02:33:09 -0400

Coming back to this after a week's thought...

--On Friday, April 15, 2016 16:22 +0100 Alexey Melnikov
<[email-masked]> wrote:

>> Now, if someone claims that the language in 5321 is
>> insufficiently clear on that point, discussion of a proposed
>> update to clarify it might be useful.  However, I doubt that
>> is what proponents of "canonicalization" have in mind.  What I
>> think I'm seeing is claims that 5321 is either ambiguous or
>> says something else by people who don't consider reading and
>> understanding it to be a necessary requirement for developing
>> standards about email.

> I think it is not about changing RFC 5321, but being able to
> express things like "this domain uses ASCII case-insensitive
> local-parts" or "[email-masked] is the same as [email-masked]".
> These can be expressed in some ways in DNS, being validated
> using an SMTP extension by a final delivery MTA or expressed
> in S/MIME certificates. (These are just 3 examples of what
> people were talking about recently, I express no opinion about
> their suitability for the task.)
> 
> Does this clarify what kind of "canonicalization" I am talking
> about?

It does.  Certainly there is no inherent objection to delivery
systems announcing the rules they intend to use in interpreting
addresses.  However, when one turns to the DNS for such things,
I hope than any discussions are informed by history and
operational reality.   Part of that history is that the WKS
record was a key feature of the original design of the DNS for
applications.  It turned out to be a miserable failure, so much
so that it was necessary to formally deprecate it in RFC 1123.
At least IMO, two things went wrong with WKS and the factors
that caused them are, if anything, worse today.   First, in
today's vocabulary of "permissionless innovation", WKS
essentially required sufficient cooperation between application
developers and DNS administrators to get permission from the
latter each time a new application was enabled.  Second, the
requirement created race conditions: if a function that had been
supported on on the applications server changed and it took the
DNS some time to catch up, assorted bad things happened.  How
bad depended on how much the client/sender trusted the DNS entry
and how it dealt with either the possibility of false positives
and negatives, but the best outcome was extra wasted time.

Similar issues, or at least the time-delay and race condition
ones may arise embedding addresses in certificates, but there
one may care less.  Or not.

If one is sufficiently careful about scope of applicability and
clear about the assumptions and consequent risks, I don't see a
problem with any of those approaches.  Conversely, as soon as
one starts talking about a general address canonicalizer, or
email addresses as reliable and permanent identifiers, I think
one gets onto a steeply-angled slippery slope.

    john

best,
    john

---

From: Wei Chuang <[email-masked]>
Date: Fri, 22 Apr 2016 10:26:22 -0700

> one gets onto a steeply-angled slippery slope.

Regarding the suitability of embedding email addresses in certificates,
would it be fair to say that domains willing to live with permanent email
identities and narrowly defined delivery patterns could have a standardized
means of describing equivalent email addresses?  Then recipients of emails
with such certificates could then validate the sender using a modified
RFC5280 validation.  Issuers of such certificates would have to insure that
the domain meets those requirements, and those that don't could be issued
certificates that fall back to current RFC5280 behavior.

-Wei

>     john
>
>
> best,
>     john
>
>
>
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

---

From: "John Levine" <[email-masked]>
Date: 22 Apr 2016 17:55:34 -0000

>means of describing equivalent email addresses?

Hard to say.  The PKIX crowd put in case folded addreses without, as
far as I know, asking anyone in the SMTP community whether that's a
good idea.  While nobody thinks it's likely that Fred@example,
FRED@example, and fred@example would correspond to different people,
once you get past case folding you quickly run out of popular
techniques, and even case folding is hard in EAI since the folding
rules are specific to each language.

My advice would be that if you're signing mail with S/MIME or PGP,
take the form of the address you use in your From: line and put that
in the certificate.  If you want to look up certificates, do something
like draft-bhjl-x509-srv rather than a system that depends on
client-side canonicalization.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Fri, 22 Apr 2016 14:06:37 -0400

--On Friday, April 22, 2016 10:26 -0700 Wei Chuang
<[email-masked]> wrote:

> Regarding the suitability of embedding email addresses in
> certificates, would it be fair to say that domains willing to
> live with permanent email identities and narrowly defined
> delivery patterns could have a standardized means of
> describing equivalent email addresses?  Then recipients of
> emails with such certificates could then validate the sender
> using a modified RFC5280 validation.  Issuers of such
> certificates would have to insure that the domain meets those
> requirements, and those that don't could be issued

I don't know how to answer your question, so let me answer a
slightly different one, perhaps agreeing (again) with the
comment Alexey made.

First of all, a certificate issuer can put whatever it likes
into the certificate, including strings that look like email
addresses.   Whether such strings are actually email addresses,
how multiple of them relate, whether the binding between such a
purported email address and a mailbox is actually valid, and
whether the address and/or mailbox actually are under the
control of some particular person are really trust model
questions.  

To be clear, I could say almost the same things about, e.g., an
identifier consisting of a hash of height, weight, and birthdate
or some sequentially-assigned personal ID.   The question really
does not have a lot to do directly with email or email protocols.

Now, because it is a trust model question, or several of them, I
think the community should try to insist that the certifier be
very clear about what the relationships are that they are
certifying.  In today's environment, that could be a BCP-like
statement to the effect that certifiers who don't supply
information about what they are attesting to and/or who assert
that they are not attesting to anything (or anything other than
ability to pay a bill) should be ignored for most purposes, but
that still isn't an email problem.

Partially on the basis of the old principle that chains are no
stronger than their weakest links, similar comments apply to
anything in which the DNS is involved.  So, however you would
rank your trust relationships in the following cases:

 o [email-masked], where the Whois (registry
	information) record indicates that the ownership for
	example.com is hidden for privacy reasons and you don't
	get to find out who the registrant is.
	
 o [email-masked], where data show apparently-good
	contact information but the registrar has an established
	reputation for doing business with evildoers and
	allowing registrants (possibly just by aggressive
	non-checking) to lie about actual contact or ownership
	information.
	
 o [email-masked] and/or
	johnbloggs@mafia., with the obvious implications even
	though the upstanding businessmen and community members
	involved are clearly identified.

Now, my answers about those cases (and others) and yours may not
be the same.  That is what trust models are all about.  On the
other hand, if you are going to do something automated
--something that essentially tells users who and what they
should trust-- I'd hope you would be very thoughtful and open
about those decisions and how you make them.  

But, again, this really has very little to do with email beyond
string similarity and some questions about the stability and
reliability of various bindings.

     john

---

From: Ned Freed <[email-masked]>
Date: Fri, 22 Apr 2016 13:27:55 -0700 (PDT)

> rules are specific to each language.

It's hard to say because the entire idea of defining a general
"canonicalization" operation for email address as a solution for various
problems is, as I have previously pointed out, nonsensical.

There are problems, such as the address equivalence tests mailing list managers
are obliged to perform, where a single canonicalization operation is both
necessary and sufficient. And there are problems, such as looking up
the certificate/private key to use for an address, where anything based on
canicalization will at best be a partial solution only applicable to
administrative domains that meet some very specific criteria, and a better
solution won't use canonicalization at all.

More generally, this entire discussion has taken on the characteristics of an
antipattern we see regularly in customer support: The customer has a
problem, settles on a particular solution and then asks us how to implement it.
Sounds fine, right? Except the solution they've settled on is either
unworkable, impractical, unimplementable, fails to solve the problem, or
some combination of the four.

And then we invariably spend a bunch of time wandering around before we're
able to back things up to the actual problem. Which at least we might have
a chance of solving.

And it's the same here. Painful though it may be, it's becoming increasingly
clear that we need to back up to the original set of problems that started
this discussion.

I originally thought that backing up to the problem of how to determine various
properties of an address was sufficient. But although I believe all of the
motivating problems here do reduce to property lookup, I now see that we're
going to have to go back further than that.

				Ned

---

From: Wei Chuang <[email-masked]>
Date: Fri, 22 Apr 2016 17:00:08 -0700

> going to have to go back further than that.

Perhaps a way of thinking about this is whether identity equivalence rules
of a domain can specified and then communicated to a third party so that
the third party can make its own judgement about identity of the purported
sender of some email.  At a high level can a specification be made assuming
that the domain makes it suitable to do so?

Another approach might be to rework how to interpret the sender with signed
messages so that its possible to skip the RFC5280 address validation at the
receiving MUA.  In this process, the MUA would  ignore the RFC822
FROM/SENDER header, and take the sender from the certificate SAN rfc822
email address.  (Only one address would be allowed in the SAN in this
approach)  The email UI would display the certificate email address as the
FROM address and replies would go there.  This is a bit more of a change
though I would think.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Fri, 22 Apr 2016 17:09:35 -0700

On Fri, Apr 22, 2016 at 5:00 PM, Wei Chuang <[email-masked]> wrote:

> Another approach might be to rework how to interpret the sender with
> signed messages so that its possible to skip the RFC5280 address validation
> at the receiving MUA.  In this process, the MUA would  ignore the RFC822

I should mention a variation of this 2nd approach would be to use RFC7508
securing header field by rewriting the FROM / SENDER header at the
receiving MUA during S/MIME decryption/verification time which presumably
is after SMTP delivery.  This might actually be a smaller change.

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 22 Apr 2016 21:31:21 -0400

>> problems is, as I have previously pointed out, nonsensical. ...

> that the domain makes it suitable to do so?

Probably not, for all the reasons discussed before.

Moreover, I don't understand what problem this is solving.  If it's my 
S/MIME key and my MUA, why wouldn't I put the same address in the key that 
my MUA puts in the From: line?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Peter Bowen <[email-masked]>
Date: Fri, 22 Apr 2016 19:15:08 -0700

> my MUA puts in the From: line?

Imagine you run a large mailbox provider (e.g. Gmail, Hotmail, Yahoo
mail, Fastmail, etc) and you want to create managed keys and
certificates for every user.  Most of your users exclusively use
webmail, so they don't have a traditional MUA.  You also support local
part canonicalization using an algorithm (e.g. remove all periods and
downcase).

Now you want to enable people to discover the right certificate when
sending mail to your users and validate certificates when receiving
mail from your users.  What do you do?

Thanks,
Peter

---

From: "John R Levine" <[email-masked]>
Date: 22 Apr 2016 22:18:37 -0400

> part canonicalization using an algorithm (e.g. remove all periods and

So far so good.

> mail from your users.  What do you do?

For the former, you implement draft-bhjl-x509-srv, of course.

For the latter, you get your act together so the address in the 
certificate matches the address your web MUA puts on the From: line. 
This is not rocket science.

Regards,

---

From: Paul Smith <[email-masked]>
Date: Mon, 25 Apr 2016 09:35:51 +0100

> mail from your users.  What do you do?
Hang on - step back a minute...

'you want to create managed keys and certificates for every user.'

Doesn't this mean that the user has just thrown away any chance of security?

'I want to encrypt my emails, so I'll just let a company I have no 
control over generate a "private" key for me'...

Again, this seems to come back to giving people the illusion of security 
rather than true security.

Ignoring that huge problem, then why does the user not simply choose the 
form of the email address they want to use (fred.bloggs, FredBloggs etc) 
and tell you that, then you generate a certificate which matches. Then, 
hey presto, the FROM address matches the certificate. Seems simple to me.

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2016 16:27:08 -0000

>control over generate a "private" key for me'...

Not necessarily.  It entirely depends on the relationship between the
user and the MTA operator.  If the users are employees of the
operator, it's entirely reasonable for the operator to control the
certs.  Even if the operator is someone like gmail, users might
reasonably decide that a system that lets Google continue to read
their mail while making it harder for random outsiders to do so is an
improvement over what they had before.

>hey presto, the FROM address matches the certificate. Seems simple to me.

Agreed.  And for external parties wanting to find your users' keys,
you run the key lookup server, so you can apply whatever your
local-part equivalence rules are.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Mon, 25 Apr 2016 11:04:50 -0700 (PDT)

> improvement over what they had before.

It's also conceivable that a company would offer users the ability to upload
their public key to the repository.

> local-part equivalence rules are.

I generally agree, but I want to point out that while equivalence  to
a canonical address with an associated key is sufficient to solve this problem,
it isn't necessary: Strictly speaking all that's necessary is a mapping from
address to key. And there are a myraid of ways to accomplish that, some
of which don't involve a canonical address.

For example, in our implementation the mapping would be from an address to an
LDAP entry that contains the key, which might or might not also have an
associated canonical address.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 25 Apr 2016 15:10:51 -0400

> their public key to the repository.

True, although if it's web mail you're going to need some impressively 
complex Javascript to arrange so that the user can read the mail but the 
provider can't.

> it isn't necessary:

Oh, of course, sorry if that wasn't clear.  You need a mapping from the 
address to the key, not to a canonical anything.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Mon, 25 Apr 2016 12:58:07 -0700 (PDT)

> complex Javascript to arrange so that the user can read the mail but the

It's a nasty problem even if you're willing to settle for possibly
exposing the message but not the private key.

And even if you're willing to expose the private key to the webmail system,
there's the interesting issue of how to set things up so your mobile
client shares the same key.

> address to the key, not to a canonical anything.

In our software having a canonical address for all the addresses associated
with an LDAP entry is optional, and may in fact be disallowed.

				Ned

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Apr 2016 13:18:23 -0700

> On Apr 25, 2016, at 12:58 PM, Ned Freed <[email-masked]> wrote:
> 

The nasty bit is trusting someone you don't trust with your private key to
serve you the javascript code your crypto is executing on.

The rest of it is fairly easy. PGP in in-browser javascript is a (multiply) solved
problem, as is secure local storage for private keys.

> client shares the same key.

The mobile client generates it's own key pair, then the desktop / web /
whatever / client sends it's key pair via encrypted & signed mail to the
mobile client.

To wander vaguely back towards the thread, that'd be a perfect example
of a single email address having multiple not-quite-equivalent cryptographic
identities; mapping an email address to a single associated key isn't
sufficient.

Cheers,
  Steve

---

From: Dave Crocker <[email-masked]>
Date: Mon, 25 Apr 2016 15:52:56 -0700

> serve you the javascript code your crypto is executing on.

+1, and thanks for noting it.

In practical terms, if the mail operator is supplying the client code, 
then the client's activity is wholly controlled by the operator.  That 
includes the operator knowing the user's private key.

But the general form of this is:  whoever supplies the MUA -- or, more 
precisely, the user's encryption-related software and process -- knows 
the user's private key.  Or at least, they can.  So creafully vetting 
that code and supplier is essential.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Tue, 26 Apr 2016 11:27:13 -0400

--On Monday, April 25, 2016 15:52 -0700 Dave Crocker
<[email-masked]> wrote:

>> The nasty bit is trusting someone you don't trust with your
>> private key to serve you the javascript code your crypto is
>> executing on.
> 
> In practical terms, if the mail operator is supplying the
> client code, then the client's activity is wholly controlled
> by the operator.  That includes the operator knowing the
> user's private key.
> 
> But the general form of this is:  whoever supplies the MUA --
> or, more precisely, the user's encryption-related software and
> process -- knows the user's private key.  Or at least, they
> can.  So creafully vetting that code and supplier is essential.

I agree almost completely, but with one small, practical,
exception.  It, again, depends on who and what one is trying to
protect against.  If the concern is about the casual curiosity
of a neighbor, then mail provider (or MUA provider) protection
or encryption just good enough to constitute a significant
annoyance may be sufficient protection.  If one is worried about
curious operators working for the mail provider who have too
much time on their hands, even a compromised MUA may be ok if
the compromise is not widely known and whether or not mail
encrypted in keys supplied by the mail provider is at risk
depends on that provider's policies and how strictly they are
monitored and enforced.  If one is concerned about surveillance
of messages in transit, then TLS-style link encryption is fine
("opportunistic" or otherwise) as long as you trust the MTA
providers at both ends and their staffs.  If you don't, it is
often easier to attack the servers, message queues and mailboxes
than the links and, even for the links, if the decryption keys
can be (or are) compromised. all bets are off.  Finally, if the
real concern is an entity who is targeting you in particular and
has resources (of money, supercomputers, the ability to issue
secret subpoenas, or all three), then it is not clear what helps
unless the message is strongly encrypted end to end using
mechanisms, software, and keys that you control and have audited.

Looking at those distinctions makes a lot of the current efforts
look, to some of us, a lot more like security theater than real
and focused protection -- overkill for the casually curious and
insufficient for targeted and well-resourced attacks.   That
doesn't get me to "you can't control everything so it is
hopeless and you should just give up" but I think it argues for
some careful thought about methods, claims, and what is actually
being protected and against whom.

best.
    john