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

[Eric Rescorla <[e-mail]>]

On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton <[e-mail]> wrote:

> On 2/21/19 7:07 AM, Eric Rescorla wrote:
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I support Benjamin's DISCUSS.
> >
> > 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
>
>
> The general approach of REQUIRETLS is that the sender is in a good
> position to determine the sensitivity of the message(s) they are
> sending, because they know what the message is.


Right, this is what I am disputing.


Ultimately, for the last
> hop anyway, the recipient has the ultimate control: they can refuse to
> accept a message unless STARTTLS has been negotiated.


Actually, this doesn't work for two reasons:

1. There might be an active attacker.
2. Requiring TLS on the *receiver* side means that you can't talk to
clients which don't speak TLS.

-Ekr


For intermediate
> hops, it's a matter of trying to balance the (perhaps) conflicting
> wishes of the sender and recipient. And as Viktor has pointed out, this
> provides a workaround for misconfigured mail systems. RequireTLS: NO is
> not a very robust mechanism in any case, because it's very possible that
> a relay MTA will not support REQUIRETLS and will ignore the header
> field. But it's an attempt to get explicitly non-sensitive messages
> through.
>
> >
> >
> >        The choices of key lengths and algorithms change over time, so a
> >        specific requirement is not presented here.
> >
> > This is not a verifiable conformance requirement. You
> > either need to not have a 8174 SHOULD here, or actually specify what
> > "meaningfully secure" means.
>
>
> This text was removed in the -07 draft, and now has a reference to RFC
> 7525 for TLS negotiation requirements. Let me know if this addresses
> this issue.
>
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> >    email by giving the originator of a message an expectation that it
> >    will be transmitted in an encrypted form "over the wire".  When used,
> >    REQUIRETLS changes the traditional behavior of email transmission,
> >
> > This does not seem to accurately describe "RequireTLS: NO"
> >
> This text was also corrected in the -07 draft.
>