Re: [dane] email canonicalization for SMIMEA owner names

[Nico Williams <[e-mail]>]

On Fri, Dec 12, 2014 at 12:55:50AM +0000, Viktor Dukhovni wrote:
> On Fri, Dec 12, 2014 at 11:41:30AM +1100, Mark Andrews 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 [e-mail] cert-hash
MSA: connect to sender.domain's MTA
MSA: VRFY_SENDER_CERT [e-mail] 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).

> 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.

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.

> 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.

Why HTTP?

> [...]
> 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?

Maybe so.

Nico
--