[cryptography] [Cryptography] Email is unsecurable

Nico Williams nico at cryptonector.com
Wed Nov 27 15:34:33 EST 2013


On Wed, Nov 27, 2013 at 08:01:19PM +0000, Stephen Farrell wrote:
> On 11/27/2013 06:58 PM, Nico Williams wrote:
> > [...]
> 
> I'm not sure detecting the path length in terms of ADMDs is so
> easy, not so useful in terms of MTAs (with all the spam checking

Sure it is!  Nowadays the path should generally be:

    sender's MUA    -> sender's MSA
    sender's MSA    -> sender's MTA (this is generally internal, and
                                     anyways it can be marked as such)
    sender's MTA    -> recipient's MTA
    recipient's MTA -> recipient's mailbox

Internal-to-sender/recipient's-infra hops are irrelevant/uninteresting.

Now, a recipient might use a third-party MX, but the recipient's MUA can
check that the MX RRs for the recipient's domain match the unexpected
path element.  (MX RRs can change, which can cause the path validation
results for an e-mail with non-shortest path to change over time.)

> that can go on), nor that the above is really explicable to users.
> We'd need to ask some mail folks.

No need to explain to users.  The MUA either validates the path and
marks the mail as verified to be from the sender, or... not.  It's a
boolean.  Users can be expected to understand a boolean.

Of course, it doesn't help the user that a phisher is "authenticated";
phishers and spammers would be the first to implement this, as with
DKIM.  But the MUA can also AND the sender's presence in the recipient's
address book to the expression producing that boolean result.

> But I like the emerging scheme below a good bit more:-)

:)

> The problem with DANE is the lack of DNSSEC. If we had both [...]

When I refer to DANE, I also mean that DNSSEC must be there.  We're
getting there.

> Otherwise I think we're in agreement and I'll send a pointer
> to this sub-thread to apps-discuss so follow up can happen
> there. (I think you're on that list right?)

I am.  Thanks for sending this there.

Nico
-- 


More information about the cryptography mailing list