[cryptography] [Cryptography] Email is unsecurable

Nico Williams nico at cryptonector.com
Wed Nov 27 13:58:28 EST 2013


On Wed, Nov 27, 2013 at 06:02:08PM +0000, Stephen Farrell wrote:
> On 11/27/2013 05:42 PM, Nico Williams wrote:
> > On Mon, Nov 25, 2013 at 09:51:41PM +0000, Stephen Farrell wrote:
> >> New work on improving hop-by-hop security for email and other
> >> things is getting underway in the IETF. [1] Basically the idea
> > 
> > I see nothing in the proposed charter you linked to about hop-by-hop
> > security.
> 
> Isn't the "Using TLS" part enough? At least for the applications
> listed. Could be worth adding a sentence to the charter though
> I guess.

Maaayyybe.

> > I could imagine something like Received headers to document how each
> > SMTP (and SUBMIT) end-point was authenticated (if they were) along a
> > mail transfer path.  This would be of some utility, particularly for
> > *short* paths (MUA->MSA->MTA->mailbox); for longer paths this loses its
> > utility.
> 
> Not sure I get the utility there, at least as in scope for
> this proposed WG. Do you mean the receiving MUA would display
> the message differently or something?

Yes.  You get an e-mail from me.  Your edge MTA authenticated my MTA and
my MTA claims to have authenticated me.  Add in a signature by my MSA
over the relevant headers and body and your MUA can display my e-mail as
more authenticated than one that transited a non-secure link (or where
the transfer path was longer).

Note that there'd be a need for using DANE to authenticate MTAs acting
as *clients*.  There'd be no need to prove the use of DANE for
authenticating MTAs acting servers: if the mail gets to its intended
destination, and the transit path is the shortest possible path, then
we're good to go.  But it'd still be desirable to use DANE for
authenticating MTAs acting servers: to prevent e-mail falling into the
wrong hands.

Note too that if a path is longer than the absolute shortest possible
path then it's difficult to verify that there was no MITM in the path.
That is, an MTA along the path could have had its DNS MX RR lookups
spoofed so as to transfer my email to you via an MITM (who then gets to
see it).  It's not like a client can prove to a server that the client
used DANE to authenticate the server, so the servers can't protect
against this.  The shortest path will generally be: my MUA->my MSA, my
MTA -> your MTA, your MTA -> your mailbox.  Internal MTA hops on my
and/or your side are irrelevant and can be noted as such or even not
recorded (assuming our respective internal networks are secure).  Policy
could be used to validate longer-than-shortest paths, but in practice
just the shortest-path approach will suffice.

> There might be an idea there though if some of the hops used
> e.g. anon-DH and someone developed a generic witness protocol
> to help try spot MITM attacks on that, and if the MSA and MTAs
> DKIM-sign messages, then a message header field containing the
> inbound & outbound witness-protocol PDUs that was included in
> the DKIM signature could be good.

If there's just anon-DH it's not terribly useful except as a way to
bootstrap up to using DANE.  If you use DANE then you get the above
property (all hops authenticated == much better than one [or more] hops
not authenticated).

> That sounds like it'd be a bit out the scope for UTA but if
> that's  what you meant (or similar) but I'd say a mail to
> apps-discuss on that would be useful.

Right.

> But I don't think we'd want the UTA WG to be the one to
> develop a protocol for how to post-facto spot a MITM on anon-DH
> or other TLS sessions though. (Anyone got suggestions for that
> btw? Probably a different thread though.)

Agreed.

> (And yes, the above would depend on DKIM public key records in
> the non-DNSSEC DNS, so a DANE like thing and DNSSEC would be
> stronger, but given that lots of large and small mail services
> already do DKIM and don't change their keys that often, even
> the non-DNSSEC thing might be good enough.)

I'd prefer the hop-by-hop DANE thing for e-mail.  It makes much more
sense.


More information about the cryptography mailing list