Subject: [dane] email canonicalization for SMIMEA owner names

From: "Rose, Scott W." <[email-masked]>
Date: Thu, 11 Dec 2014 14:51:27 -0500

Realized the other action item I was assigned to from the interim meeting was email canonicalization for SMIMEA.  I believe it stems from Viktor Dukhovni's email to the endymail list:
http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html

I was wondering if we can borrow a page from RFC 4034 Section 6.2 and include text in the draft Section 3, item 1 in the numbered list:

     1.   The user name (the "left-hand side" of the email address, called
       the "local-part" in the mail message format definition [RFC2822]
       and the "local part" in the specification for internationalized
       email [RFC6530]), is hashed using the SHA2-224 [RFC5754]
       algorithm (with the hash being represented in its hexadecimal
       representation, to become the left-most label in the prepared
       domain name.  This does not include the "@" character that
       separates the left and right sides of the email address.  The
       string that is used for the local part is a Unicode string
       encoded in UTF-8 **with all upper case letters converted to their
       corresponding lower case letters where appropriate.**

The text between the '**' is new.  The goal is to prevent a situation when the email address is "[email-masked]" and the SMIMEA is created using "jrandom" as the user name.   Would this be enough, or are there scripts where this would result in different or potentially conflicting owner names?  

Scott

===================================
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: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Dec 2014 20:50:53 +0000

On Thu, Dec 11, 2014 at 02:51:27PM -0500, Rose, Scott W. wrote:

> Realized the other action item I was assigned to from the interim
> meeting was email canonicalization for SMIMEA.  I believe it stems
> from Viktor Dukhovni's email to the endymail list:

This proposal is sadly simply wrong.  There is no correct
(language-independent) canonicalization of Unicode to lower case.

Nor is it appropriate to down-case even ASCII localparts, because
these are by definition case-sensitive on the wire, with any
case-folding solely at the discretion of the destination system.

I have a proposal that solves the ASCII use-case.  Sadly, little
can be done for non-ASCII Unicode, those names will just have to
be used consistently by all parties.

For all-ASCII addresses, (ignoring for the moment Turkish case-
folding of "I" to a non-ASCII "dotless" "i"), the proposal is
as follows:

    * Clarification: Localparts that are not dot-atoms and
      require quoting, retain the quotes when hashed, only
      the @domain part of the address is removed, the rest
      of the address is retained verbatim.

    * Domains that publish user SMIMEA records, which intend for
      for the names to be treated case insensitively, compute two
      hashes for each name:

	    SHA2-224("Frank.Jr.")            -> <base32-hash1>
	    SHA2-224(@lower:"frank.jr.") -> <base32-hash2>

      The DNS records are then: 

	<base32-hash1>.example.com. IN SMIMEA ...
	<base32-hash2>.example.com. IN CNAME <base32-hash1>

    * Domains that don't do case-insensitive delivery publish only
      the as-is form of each address without any "@lower:" prefix.

    * Clients that encounter an ascii localpart that is not all lower-case
      try both keys, first the localpart as-is, then case-folded with
      the "@lower:" prefix.  
      
-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Dec 2014 16:03:13 -0600

> be used consistently by all parties.

Well, domains could publish the local-part canonicalization function
they use, or, rather, a small index of well-known canonicalization
functions.

This is just a tweak to your proposal.  You propose just two functions:
identity and ASCII-tolower, with the client trying all [two] of them.

If we add more functions we'll want to know which function the domain
uses, so we'll need that one more lookup.  We need just a handful of
functions that will work for most cases.

E.g., gmail treats periods as if they weren't there.  That might need to
be part of one ore more standard canon function(s).

I realize that your proposal is simpler, and we might want to stop there.

> folding of "I" to a non-ASCII "dotless" "i"), the proposal is

What site would want to permit local-part names that are equivalent but
for an i/dotless-i?  I realize that the situation can have come up, but
going forward a site might want to treat them as equivalents, and,
really, to implement Unicode case-folding + some standard mappings, as
the canonicalization, at least for SMIMEA purposes (the actual e-mail
addresses understood by users as canonical might bear a dotless i even
if for SMIMEA purposes it becomes a dotted i).

>       try both keys, first the localpart as-is, then case-folded with

Almost there :)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Dec 2014 16:15:01 -0600

> http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html

Er, the case-(in)sensitivity of DNS seems irrelvant here (re: Viktor's
point (e) in that post).  After all, we'd be hashing the local-part.

All that matters is that senders, resenders, ... preserve the form given
them by recipients.

So maybe we need no canonicalization step at all.

If I say I'm [email-masked], and you type [email-masked] into your
MUA to send me e-mail, you might not reach me.

That seems fair.  And allows for aliases of any kind.  If I want to
publish SMIMEA RRs for all possible capitalizations of "foo"
@bar.example, well I can, and if I don't want to then I don't have to.

Nico
--

---

From: Christian Rößner <[email-masked]>
Date: Thu, 11 Dec 2014 23:35:24 +0100

Hi,

> Am 11.12.2014 um 20:51 schrieb Rose, Scott W. <[email-masked]>:
> 

sorry, if my answer might be a little bit off-topic. When the draft for SMIMEA was posted the first time, I wrote to someone here on the list off-list. I asked, why to use SHA2-224 for the local part of an email address. I thought about useability for many of records in DNS for a large company. That seeing only hashes and nothing readable would make it nearly impossible to find a record again manually without technical help.

So I thought about punycode RFC3492. I know the RFC might only be for domains, but I asked myself, why this would not be applied to a local part as well.

Many countries would benefit from such a representation, because the have parts of the latin alphabet and therefor just a hand full of characters would need conversion.

I am a layperson, so these are just my ideas and there might exists good reasons, why this is not applicable. But at least I did not want to miss the chance to bring up this discussion.

And sorry, if this is not 100% answer to this thread. At least it focuses on parts of the SHA2-224 and I wanted to give an optional view.

Kind regards

Christian
--
Bachelor of Science Informatik
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2014 22:40:07 -0000

>they use, or, rather, a small index of well-known canonicalization

Mail systems do fuzzy matching on local parts in an enormous number of
ways.  But you will find that once you get past "map it all to lower
case" the rest of them are all out at the tail of the curve.

I don't know anyone other than Gmail that treats dots as noise
characters ([email-masked], [email-masked], and
[email-masked] are all the same mailbox) but since Gmail is
such a large player, do they get their own special case?

Personally, I think that:

a) Viktor's approach is terrible, and

2) it's the best we're going to do so we might as well use it.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2014 22:50:38 -0000

>So I thought about punycode RFC3492. I know the RFC might only be for domains, but I asked
>myself, why this would not be applied to a local part as well.

Mailboxes can contain characters not valid in punycode.  Mailboxes in
regular ASCII mail can contain spaces and ASCII graphics.  Mailboxes
in EAI mail can include arbitrary UTF-8.

You could imagine a punycode-like encoding for mailboxes, or perhaps
something more like quoted printable, but punycode or A-labels aren't
adequate.

Also keep in mind that RFC 5321 says that mailbox names are opaque, so
any case folding we do is technically wrong.  But in practice everyone
expects case folded mailboxes to work, so even mail purists are likely
to grumble but admit that a hack like Viktor's optional lower case is
OK.

R's, John

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 11 Dec 2014 15:12:28 -0800

I don't know how that's supposed to work with EAI. We are working towards
EAI deployment, and while we will probably have to do some normalization
(ｲｱﾝﾌｪｯﾃｨ -> イアンフェッティ) I would not make some generic assumption. Until
there's more deployment and experience I don't think it's safe to make
assumptions there.

2014-12-11 14:50 GMT-08:00 John Levine <[email-masked]>:

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Dec 2014 23:55:19 +0000

On Thu, Dec 11, 2014 at 04:15:01PM -0600, Nico Williams wrote:

> If I want to

The problem is that (without my encoding) a client can't tell
whether the "[email-masked]" key it found really is the
"[email-masked]" it wanted to reach, or whether that is some other
mailbox.  Yes, any mailbox provider that assigned mailboxes that
way would be insane, but not "criminally insane"... :-)

So my "@local:" prefix avoids collisions if there are in fact sites
where mailboxes are case-sensitive.

I am pleased with John Levine's characterization of my proposal:

    * It's terrible.
    * We may as well use it.

Like passwords for authentication (or democracy as a form of
governance), it stinks, but the other options stink more.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Dec 2014 11:09:53 +1100

We could just do this correctly and use SRV records to point to
keyserver servers running over TLS.  The keyserver can do whatever
local canonicalisations that are required.  The SMTP server could
even be performing this role on a different port.  That way you
only have to enter the canonicalisation rules once.

This also gets rid of the complaints about being able to walk the
zone.

-- 
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, 12 Dec 2014 00:31:31 +0000

> This also gets rid of the complaints about being able to walk the

Since this is the DANE working group, those would be DANE TLSA
authenticated servers, designated via a suitable SRV record.

The presence of the SRV record itself would signal adoption of the
protocol by the domain.

However, this makes the protocol much more complex.  Mail clients
that just do local submission and did not need a TLS stack, would
now need to implement HTTPS, and we'd end-up defining a rather
complex protocol layered over that.

DNS does scale better.

If we're really going to do this as a direct query to the remote
domain (and not a DNSSEC lookup), perhaps the right application
protocol is some sort of minimal SMTP over SSL on a port indicated
by the SRV record:

    <tcp connect>
    C/S: <TLS handshake>
    C: SMIMEA "Frank.Jr."@example.com
    S: 250-3 1 1 <blob1>
    S: 250 3 1 2 <blob2>
    <TCP disconnect>

HTTP seems like much too much baggage, and the above could actually
be an additional service operated as part of the MTA, (the email
administrator would not need to be either a DNS administrator or
a webmaster).  The SMTP server would know how/whether to case-fold
the address.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Dec 2014 11:41:30 +1100

> complex protocol layered over that.

If mail clients are doing SMIME the addition complexity of HTTPS
or TLS is not much.

> DNS does scale better.

No, it doesn't.  DNS scales equally well.
 
>     C: SMIMEA "Frank.Jr."@example.com

But not port 25.  That is blocked too often.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Dec 2014 00:55:50 +0000

> But not port 25.  That is blocked too often.

Absolutely, this would be an additional service on some other port,
indicated via SRV records, and authenticated via DANE TLSA records.

The downside of something other than HTTPS or DNS, is that while
less likely to be blocked for anti-spam reasons, this is likely to
be inaccessible to MUAs inside various firewalled environments.

Perhaps a sufficiently light-weight http encapsulation is right
after all, and MTA authors might be able to implement just enough
HTTPS to still support this as an MTA feature.

In Postfix this would be a separate program that runs out of
"master.cf", but uses the Postfix table facilities to get the data
out of any supported datastore (including LDAP!).

This however takes far away from any similarity to the SMIMEA draft
as it is today.  Is it really time to throw it all away and start
again?

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Dec 2014 12:00:07 +1100

In message <[email-masked]>, Viktor Dukhovni writ
> as it is today.  Is it really time to throw it all away and start

Yes.  It's just a pity it has taken so long for other to realise this.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 11 Dec 2014 17:22:03 -0800

Sorry, just reading the SMIMEA stuff for the first time, so apologies for
the basic question, but do I really have to publish a record for each
address? How would I say "this is a trusted intermediate CA for [email-masked]
"?

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Dec 2014 01:36:56 +0000

> address? How would I say "this is a trusted intermediate CA for [email-masked]

That would look like so:

    ;; insert CNAMEs for any desired indirection when
    ;; the same set of SMIMEA RRs handles multiple domains
    ;;
    *._smimecert.gmail.com IN SMIMEA 2 0 1 <blob>

Keep in mind that this only supports signature verification, not
encryption, one can't encrypt to an intermediate CA, one needs the
leaf public key for that.  So enabling encryption on first contact
requires publishing per-user keys by some means.

Otherwise all one gets is authenticated key exchange, possibly
followed later by encryption once leaf keys have been exchanged in
both directions.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 11 Dec 2014 21:11:42 -0500 (EST)

On Thu, 11 Dec 2014, Nico Williams wrote:

> That seems fair.

Actually, that is really stupid, seeing that many mobile phones, which
are hard to type on to begin with, auto-capitalize for many reasons. My
phone regularly corrects emails I forward to myself to [email-masked].

No currently maintained implementation of email should support that these
two might be different local users.

> And allows for aliases of any kind.  If I want to

A client can lookup the given name, if NXDOMAIN and not all lowercase,
lowercase it and try again.

And someone should write an RFC updating SMTP to not allow
case-sensitivity for different mailboxes so we can stop coming back to
this whenever anyone wants to do anything with email addresses.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 11 Dec 2014 21:14:08 -0500 (EST)

> 	<base32-hash2>.example.com. IN CNAME <base32-hash1>

Are you confusing wire format with presentation format? Why the extra
base32 ?

Paul

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Dec 2014 21:43:27 -0600

> phone regularly corrects emails I forward to myself to [email-masked].

That's dumb of the MUA.  Local-parts are case-sensitive as far as the
standard goes, but MTAs can make them case-insensitive.

(The same is true for all sorts of things.  Filesystems, HTTP URIs, ...)

If you have such a dumb MUA you would still be able to send e-mail if
you got the address wrong and got an alias instead, you just wouldn't
get SMIMEA.

On mobiles it's all about how the app configures the keyboard context.
Some apps match what you type against addresses of peers you've
corresponded with before, and that's extremely useful, while plain old
auto-correct for e-mail addresses is about the most obnoxious thing an
MUA can do to its user.

> two might be different local users.

I can't decode this.

The problem is that now we want the client to be able to find a public
key for the recipient and encrypt to it, yes?  But we also want to avoid
making it trivial to find addresses to spam, no?

Well, these two requirements conflict.  Any solution that addresses them
both is going to have the suckage you mention above.

> lowercase it and try again.

Yes, for ASCII that works.  For Unicode it requires accepting more
aliasing that one might want.  I might not be opposed (I haven't
decided), but the problem is that either way you're getting aliasing
that the target domain may not want, but with Unicode there are tricky
political problems ("why can't I have a dotless i in my address?" "well,
you can" "but I keep seeing e-mail sent to my address with a dotted i,
and that's wrong!" "well, uh...").

> this whenever anyone wants to do anything with email addresses.

How would you know whether a target domain's local-parts are case
sensitive or not?  They aren't now.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Dec 2014 22:14:23 -0600

On Fri, Dec 12, 2014 at 12:55:50AM +0000, Viktor Dukhovni wrote:
> > [stuff about indirecting via a keyserver elided]

SUBMIT/SMTP itself could act as the keyserver.

There are two use cases: validate a sender's signing certificate, and
get a recipient's encryption certificate.

Both mean contacting the peer's domain's keyserver, but we could
indirect through any SUBMIT server that the MUA can talk to, and we can
authenticate any replies via DNSSEC in a way that does not permit
walking the zone.

I.e.,

Client: connect to C's MSA
Client: VRFY_SENDER_CERT [email-masked] cert-hash
MSA: connect to sender.domain's MTA
MSA: VRFY_SENDER_CERT [email-masked] cert-hash

The MTA responds, the MSA forwards the response.  The client also does a
DNS lookup for base32(H(sender certificate || sender
address))._smimesendercert.sender.domain. and [hopefully] finds
base32(H(sender address)).

No need for the client to talk to sender.domain's MTA directly, so no
concerns about port 25 blocking.

And if the MSA lies, the client will find out.

The client has to speak SUBMIT/SMTP anyways, and it has to support doing
so with TLS (which the client's MSA surely will speak, and the network
damned well ought to permit).

> be inaccessible to MUAs inside various firewalled environments.

See above as to firewalls.  But it's true that a pure DNSSEC scheme
means that the client can encrypt e-mail to / validate e-mail signatures
without having to worry about downgrade attacks on SMTP.  We'd still
want the client to use TLS for SUBMIT/SMTP though.

A middle of the road might be that domains could publish RRSets for
local-parts they don't mind people being able to walk, but not for those
they do, with the trade-off being that the latter lose security (or
access) when networks attempt MITM downgrade attacks on StartTLS.

> HTTPS to still support this as an MTA feature.

Why HTTP?

> [...]

Maybe so.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Dec 2014 22:16:46 -0600

> requires publishing per-user keys by some means.

There's always IBE, or just plain encrypting to the MTA's encryption
cert and then let it decrypt and re-encrypt to the local-part's
encryption key.

> followed later by encryption once leaf keys have been exchanged in

That's not so bad.  It's interactive, but so what.

Nico
--

---

From: "John Levine" <[email-masked]>
Date: 12 Dec 2014 04:32:08 -0000

>Actually, that is really stupid, ...

This time I completely agree with Paul.

>this whenever anyone wants to do anything with email addresses.

It's 30 years too late for that.  The situation we're in here is
fairly peculiar, in that clients other than the recipient MTA are
trying to interpret the mailbox name.  Previous mail protocol hacks
have carefully avoided that.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Dec 2014 15:42:11 +1100

The other thing we have to do is to arrange for the CERT to get
from the MUA to the keyserver.  Extending submission to handle that
is a sensible.  That way the user can generate their own CERT.  They
can then submit it to the keyserver using submission/smtp after
authenticating themselves.  This last step is critical.

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Dec 2014 23:08:31 -0600

> authenticating themselves.  This last step is critical.

Yes: use MSA/MTA as the keyserver, both for lookup and registration.

For verification/key lookup results can be attested to via DNSSEC.
A client's MSA could check the peer's MTA on behalf of the MUA.

I think this solves all problems, including aliasing, except in the case
where the sender doesn't trust its own MSA as to the local-parts of
peers.

Nico
--

---

From: Ben Laurie <[email-masked]>
Date: Fri, 12 Dec 2014 11:37:14 +0000

> The text between the '**' is new.  The goal is to prevent a situation when the email address is "[email-masked]" and the SMIMEA is created using "jrandom" as the user name.   Would this be enough,…

Speaking of canonicalisation:

1. What about X+Y@Z - for almost all MTAs, this is the same as X@Z.

2. What about GMail's [email-masked] == [email-masked] ==
[email-masked] == [email-masked]?

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 12 Dec 2014 16:33:50 +0100

> lowercase it and try again.

IMHO, this is a very reasonable approach that does not require any magic. It is also the reasonable thing to do for a client that actually want to find something.

	jakob

---

From: Paul Wouters <[email-masked]>
Date: Fri, 12 Dec 2014 10:38:13 -0500

Whoever starts using variant email addresses should publish records for it? As John said, clients shouldn't start guessing addressing schemes used by others

Sent from my iPhone

> On Dec 12, 2014, at 06:37, Ben Laurie <[email-masked]> wrote:
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 12 Dec 2014 15:56:03 +0000

> Whoever starts using variant email addresses should publish records for it? As John said, clients shouldn't start guessing addressing schemes used by others
+1. Nobody other than the final MTA/MDA knows that certain forms are 
equivalent.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 12 Dec 2014 15:57:38 +0000

> 1. What about X+Y@Z - for almost all MTAs, this is the same as X@Z.
This is a bit misleading: MSA or intermediate MTAs can't know that these 
are the same (unless MSA is also the final MTA).
> [email-masked] == [email-masked]?
As above.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 12 Dec 2014 11:12:56 -0500 (EST)

> Yes: use MSA/MTA as the keyserver, both for lookup and registration.

Why add another service, another dependancy and another choke point and
another trans protocol for auditing that the world sees the same view?

That can all be done with DNS.

Adding another service just adds more problems.

Paul

---

From: Nico Williams <[email-masked]>
Date: Fri, 12 Dec 2014 10:21:09 -0600

> another trans protocol for auditing that the world sees the same view?

Well, it's another service on a protocol that already exists, that the
MUA must speak, and has similar functionality (VRFY) anyways.

> That can all be done with DNS.

If done *only* with DNS then we get into the canonicalization/zone
walking (spam) trap and we then have to do something that sucks.

> Adding another service just adds more problems.

So does not adding it.  It's a case of pick your poison.

I can't say I like one poison better than the other yet...

BTW, for the DNS-only scheme, there's no need for local-part canon when
verifying sender certs: because hopefully! the sender's MUA will use a canonical
sender local-part.

As for looking up a recipient's encryption cert...  well, if the MUA
gets the wrong recipient local-part form as a result of applying an
incorrect canonicalization, then it could get the wrong recipient -- a
relatively minor problem, but one worth noting.

The SMIMEA I-D does need to describe the motions that the MUA goes
through to do the two different tasks: verifying sender signature certs,
and finding recipient encryption certs.

Nico
--

---

From: Ben Laurie <[email-masked]>
Date: Fri, 12 Dec 2014 16:28:34 +0000

On 12 December 2014 at 15:56, Alexey Melnikov <[email-masked]> wrote:
>> Whoever starts using variant email addresses should publish records for
>> it? As John said, clients shouldn't start guessing addressing schemes used
>> by others
>

True, but does not make your scheme workable.

>>>> meeting was email canonicalization for SMIMEA.  I believe it stems from
>>>> Viktor Dukhovni's email to the endymail list:
>>>> I was wondering if we can borrow a page from RFC 4034 Section 6.2 and
>>>> include text in the draft Section 3, item 1 in the numbered list:
>>>>
>>>> The text between the '**' is new.  The goal is to prevent a situation
>>>> when the email address is "[email-masked]" and the SMIMEA is created
>>>> using "jrandom" as the user name.   Would this be enough, or are there
>>>> scripts where this would result in different or potentially conflicting
>>>> owner names?
>>>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 12 Dec 2014 17:01:22 +0000

> True, but does not make your scheme workable.
Only publish canonical form or variants that were used for sending 
emails out?

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Dec 2014 17:52:42 +0000

On Fri, Dec 12, 2014 at 10:38:13AM -0500, Paul Wouters wrote:

[ NOTE:  I am not advocating abandoning SMIMEA, just thinking out
  loud about what an alternative might look like, since some folks
  seem to want to discuss alternatives. ]

> Whoever starts using variant email addresses should publish
> records for it? As John said, clients shouldn't start guessing
> addressing schemes used by others

With address extensions, There may not be such a list to publish,
all extensions are valid.  In

    <base-user-name><recipient-delimiter><address-extension>@example.com

The <address-extension> part is any string that is not too long to
fit into SMTP commands and email headers.

If queries are sent to an HTTPS service that is deployed with the
(ultimate) inbound MTA for "example.com", then X.509 key lookup is
rather similar to what the MTA already does to validate the inbound
recipient so as not to be a backscatter source.

The HTTPS service would be operated as part of the organization's
boundary MTA (thus with MessageLabs, Postini, ... in proxy rather
than hosting mode, not as part of those services, but as part of
the real border system accepting mail from those).

The presence of the associated SRV records would signal adoption
of the protocol.  Domains that employ filtering services such as
MessageLabs, Postini, ... might publish only signing keys if they
wish for all email to be scanned and don't want end-to-end encryption,
or might allow end-to-end encryption via user to user requests (you
can only get my encryption key if I reply, the protocol only yields
signature verification data).

The main thing this would have to recommend itself is there is no
encoding of the localpart into DNS labels, the HTTPS service can
support queries with the full EAI address as-is, and can easily
grok the address extensions, etc., because the MTA already knows
how to do that.  DANE would be used to authenticate that service,
and the data coming back from the service would still be RFC 6698
style (usage,selector,mtype,data) associations.  This would just
be a variant oracle that avoids encoding email addresses in DNS.

The oracle can query LDAP, ... can make up fake replies for
non-existent addresses to thwart directory harvesting attacks
if desired, ...

HTTPS, allows the service to be reached from inside corporate
environments that block most other outbound services (possibly
including external DNS).  In some environments even HTTPS is subject
to corporate MiTM (that the users are aware of with the HTTP proxy
signing certs trusted by browsers, ...).  In such environments
users don't get end-to-end email encryption, just like they don't
get end-to-end HTTPS.  Their border email gateway might be able to
play gateway-to-gateway SMIME with the destination.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 12 Dec 2014 18:05:51 -0000

>1. What about X+Y@Z - for almost all MTAs, this is the same as X@Z.

Only if by almost all you mean sendmail and postfix.  Subaddresses are
popular here in nerd land but they're almost unknown elsewhere.  Yahoo
has an obscure subaddress feature which nobody uses.

>[email-masked] == [email-masked]?

That's a better question.

Having written a few books aimed at non-technical users and gotten a
certain number of comments, it's clear that everyone expects upper and
lower mailbox names to be equivalent, but have no general expectations
about dots, + - and the like.

The point about UTF-8 characters is a good one, but until there's a
lot more experience with EAI, I don't see how we can say anything about
a similar canonicalization.

R's,
John

---

From: Nico Williams <[email-masked]>
Date: Fri, 12 Dec 2014 12:38:28 -0600

> recipient so as not to be a backscatter source.

Yes.  It has to be HTTPS because that will go through firewalls.

Whereas my chaining through MSAs/MTAs idea is too burdensome on the
MSAs/MTAs.

For verification of sender signing certs this need not reveal anything
about valid local-parts.

For recipient encryption cert lookups... avoiding an oracle for
local-part validity is harder because the service would have to serve a
valid encryption cert (SMIMEA RRs, really) for every query.  For PK
algorithms where it's cheap to fake random public keys this is not a
problem at all.

> encoding of the localpart into DNS labels, [...]

And thus no canonicalization concerns.

> play gateway-to-gateway SMIME with the destination.

Yeah, and then either the client gives up (hey, if it's in a corporate
network that seems fair) or we do the chaining-with-DNSSEC-proof thing I
proposed earlier.

Nico
--

---

From: James Cloos <[email-masked]>
Date: Fri, 12 Dec 2014 17:50:10 -0500

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

VD> The presence of the associated SRV records would signal adoption
VD> of the protocol.

The only issue with using SRV is that the http GET path would have to be
standardized, which could be an pain if the advertized MXs already serve
https for something else.

An NAPTR RR, OTOH, can specify an arbitrary URL.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Dec 2014 23:16:28 +0000

> https for something else.

I was thinking of multiplexing by port, rather than URI.  So that
the service in question really could be a light-weight HTTPS server
add-on to an MTA, rather than an HTTP application in a general
purpose HTTPS server.

The key advantage is that MTAs already have code for email address
parsing, table lookups, LDAP, ... and so operating a listener on
some custom port (from an SRV record) might not be a major burden.

The URI would then be "/".  The protocol would be some elaboration of:

    Client:
	GET /?email=<URL-encoded-address> HTTP/1.1
	Host: <hostname from srv record>
	Content-Length: 0

    Server:
	200 OK
	Content-Type: text/plain; charset=us-ascii
	Connection: close

	2 0 1 <trust-anchor digest>
	3 0 0 <encryption key>

This avoids encoding issues, UDP payload limits, and allows MTAs
to perform the necessary canonicalization to find the keys of
variant address forms.

The disadvantage of a service that's operated as part of the MTA,
is that people would have to deploy updated MTAs to support this.
It does however seem that this may be easier and more flexible than
populating per-user data into the DNS.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2014 04:47:37 -0000

>add-on to an MTA, rather than an HTTP application in a general

Before we go too far down this road, we might check with some people
who run large mail systems and ask how likely they are to spin up an
all new address verification server.  It doesn't seem very likely to
me.

The DNS has its faults, but it has the great advantage of already existing.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2014 04:47:37 -0000

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 13 Dec 2014 04:59:09 +0000

> The DNS has its faults, but it has the great advantage of already existing.

And of course ask them also how likely they are to publish per-user
keys in DNS, other than perhaps a wildcard trust-anchor.

In other words, were they to provide access to a key lookup service,
what are the relevant design constraints.

Perhaps Ian Fette can comment from a Gmail perspective.

Also do they see key lookup for encryption on first contact as a
requirement?  Or is signature-only first contact with encryption
keys provided optionally on reply, their preferred  model for
encryption key distribution.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Sat, 13 Dec 2014 11:02:12 -0500

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

VD> I was thinking of multiplexing by port, rather than URI.

I got that.

But what if the MXs already run something on port 443?

If the GET/POST path can be specified, the existing web server can proxy
to the MTA's port.  Otherwise the MTA would have to proxy anything which
it doesn't handle.

Of course, with ipv6 there are always enough addresses to put the other
443 service(s) on their own ip.  So it is a short-term issue.

And it may take longer for something like this widely to deploy than it
will for v6 to displace v4 w/in the subset of sites which would use it.

So it may not be worth worry.

Otherwise, I like the idea.

Either way, it would be cool for such a service to provide gpg keyids,
too.  So the reply should include for each line a token specifying which
kind of key (smime, gpg, future) that line matches.

-JimC

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2014 18:17:24 -0000

>encryption key distribution.

How does that differ from what S/MIME does now, give or take the warts
of which CAs you trust?

It seems to me that SMIMEA offers two things:

* verify an incoming signature without reference to a CA

* encrypt mail to people who haven't already sent you a key

Of the two, the second seems much more important.  If it's only the
first, I don't think it's worth the effort.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 13 Dec 2014 18:33:37 +0000

> first, I don't think it's worth the effort.

[ I understand and in part agree with your point, but I think
  even the first alone is not as vacuous as it might seem. ]

Well I don't see to many organizations outsourcing user enrollment
to a CA, or wanting to operate an RA, so the CA-trust thing is not
so much the issue as the problem of getting CA signatures for the
user certificates, having to handle revocation via a CA, ...

What DANE can do is make it possible to just use your enterprise
CA.  For example, the Microsoft CA is very difficult to use for a
Windows shop, with DANE this can be extend to issuing certificates
that others can validate.

And I am not sure that first contact end-to-end encryption in which
only the final recipient gets to read the mail will be terribly
popular in a world of spam and email malware.  In many ways,
signature-only with key exchange on reply has security advantages
that may make it a popular mode of deployment.

-- 
	Viktor.