Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

[Nico Williams <[e-mail]>]

On Thu, 21 Feb 2019 07:07:09 -0800, Eric Rescorla wrote:
> To elaborate on one point a bit: it seems to me that it's harmful to
> security to allow the sender to unilaterally override the recipient's
> preferences that something be encrypted. To forestall one argument,
> yes, the sender knows the contents of the message, but the recipient
> knows their own circumstances, and they may be at particular risk
> [...]

This is placing too strong an emphasis on security to the detriment of
availability.

As in all things, we have to make trade-offs, and perfection is not
available to us.

In particular:

 - Email to postmaster@domain *must* be able to flow in the face of
   security-related misconfiguration, full stop.

   And, it's not always postmaster that is the contact.  The actual
   address of the actual postmaster can come from DNS SOA RRs, web
   pages, etc...

   If it were only postmaster@... surely you'd be amenable to exempting
   that.


 - Senders own the contents of what they send.  Recipients own the
   contents of what they receive.

   Each can have different policies as to how it should be sent or
   received, but each also can post it on social media, newspapers,
   whatever.

   Just because one of the parties wishes something be kept
   confidential, there is no guarantee in the absence of legal,
   contractual obligations (and PGP or S/MIME, since hop-by-hop
   transport security might not cut it or even be available).

   Refusing to accept insecurely-sent messages does not ensure their
   confidentiality!

The recipient does NOT know the sender's circumstances, and I do think
the sender's trump the recipient's.

HOWEVER, it is fair and *highly* desirable of the recipient to *mark* a
message as received insecurely -- keeping in mind that the recipient
can't force the sender to have authenticated the recipient...

My idea of an ideal end-state for hop-by-hop security for e-mail is
that:

a) *senders* should be able to specify in the envelope that they want
   secure, encrypted, authenticated delivery of email at every hop,

b) senders should get bounces when that cannot happen,

c) *recipients* get an indication of the security of any given e-mail's
   path to the recipient (perhaps we need a Transmitted: header by which
   each sending hop MTA can record what it did to authenticate the next
   hop),

d) (a) and (c) get prominent UI indications in MUAs,

e) as explained above, *senders* get a "make it go please" button for,
   e.g., "hey, dear recipient, your mail system is misconfigured, I
   cannot send secure e-mail" type messages.

Lastly,

f) forward notifications of failure to meet security policy (sender's or
   recipient's!), subject to DoS / spam filtering, naturally.

   A forward notification being like a bounce, but in the other
   direction.  The sender's address, the subject, etc., might not be
   disclosed -- the important thing is that the recipient should be able
   to discover misconfigurations and fix them.

Nico
--