Re: [dane] email canonicalization for SMIMEA owner names

[Viktor Dukhovni <[e-mail]>]

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.