Re: [Uta] New Version Notification for draft-fenton-smtp-require-tls-03.txt

[Viktor Dukhovni <[e-mail]>]

> On Feb 14, 2017, at 12:51 AM, Jim Fenton <[e-mail]> wrote:
> 
> A new version of I-D, draft-fenton-smtp-require-tls-03.txt
> has been successfully submitted by Jim Fenton and posted to the
> IETF repository.

Review comments:

=== Abstract:

The text starts:

   The SMTP STARTTLS option, used in negotiating transport-level
   encryption of SMTP connections, is not as useful from a security
   standpoint as it might be because of its opportunistic nature;
   message delivery is prioritized over security. ...

I do not think it is appropriate to say "not as useful as it might
be".  Unauthenticated opportunistic STARTTLS is *very* useful and
effective in reducing opportunities for passive attacks.  Indeed
with ~84% of email protected via TLS:

   https://www.google.com/transparencyreport/saferemail/

opportunistic STARTTLS is more successful than HTTPS, which
recent reports indicate protects ~50% of web site visits.

Now of course it is fair and accurate to say that unauthenticated
opportunistic SMTP STARTTLS alone offers only passive attack
protection and that mechanisms such as RFC7672 DANE or the
proposed STS are hop-by-hop MTA-to-MTA security protocols,
which seek to strengthen "the network", but give no control
to the user.  So I see this draft as filling that gap.

Therefore, I think it would be best to start with something that
goes right to the point.  A start in that direction might be:

  No existing IETF protocol gives an email user the means to
  express SMTP transport security policy beyond the user's
  initial interaction with the message submission agent (MSA).
  Any further SMTP relaying of the message from the MSA, often
  via multiple relay hops, to its final destination is
  subject only to the policy of the intermediate email relays.
  This specification provides a mechanism for a user to express
  an SMTP transport security preference, either to prioritize
  security, or, conversely, to prioritize delivery even
  when transport security is not available or appears to
  be compromised.

The above likely has its own flaws, so feel free to borrow from
it or ignore it as you see fit, but perhaps it serves to clarify
the approach I'm suggesting.

=== 1.  Introduction

   By default, TLS is used only upon mutual agreement
   (successful negotiation) of STARTTLS between the client and server;
   if this is not possible, the message is sent without transport
   encryption.  Furthermore, it is common practice for the client to
   negotiate TLS even if the SMTP server's certificate fails to
   authenticate it.

Here, I think the point is not that the client "negotiates TLS" even
when authentication fails, but rather that *delivery* continues despite
lack of authentication (a reference to RFC7435 may be appropriate here).
It would certainly not be better (as sadly done by some MTAs) to abort
the TLS handshake and deliver in the clear!  So the last sentence should
be rewritten.

The second paragraph:

   Policy mechanisms such as DANE [RFC7672] and SMTP STS
   [I-D.ietf-uta-mta-sts] may impose requirements for the use of TLS for
   email destined for some domains.  However, such policies do not allow
   the sender to specify which messages are more sensitive and require
   transport-level encryption, and which ones are urgent and ought to be
   relayed even if TLS cannot be negotiated successfully.

is much closer to the spirit of what I'm suggesting for the abstract, so
it could be another basis for a new abstract, or text that connects the
abstract to the introduction.

The third paragraph reads:

   The default opportunistic nature of SMTP TLS enables several "on the
   wire" attacks on SMTP security between MTAs.  These include passive
   eavesdropping on connections for which TLS is not used, interference
   in the SMTP protocol to prevent TLS from being negotiated (presumably
   followed by eavesdropping), and insertion of a man-in-the-middle
   attacker taking advantage of the lack of server authentication by the
   client.  Attacks are more described in more detail in the Security
   Considerations section of this document.

Here you're conflating opportunistic (RFC7435), with "unauthenticated"
use-cases that are not downgrade-resistant.  Keep in mind that DANE
is still "opportunistic TLS", because authenticated delivery takes
place only when the peer publishes TLSA records, and TLS is otherwise
best effort.  So DANE for SMTP is a downgrade-resistant, authenticated,
but still opportunistic mechanism, and the same holds for the proposed
STS.  Downgrade attacks are considerably more difficult with DANE, and
to a lesser degree with STS (which is weak on first contact, but provides
similar defenses thereafter).

=== 2.  The REQUIRETLS Service Extension

What is optional per the paragraph:

   An optional parameter to the REQUIRETLS MAIL FROM option specifies
   the requirements for server authentication that MUST be used for any
   onward transmission of the following message.  The parameter takes
   the form of either a single value or comma-separated list, separated
   from the REQUIRETLS option by a single "=" (equals-sign) character.
   If present, the parameter MUST take one or more of the following
   values:

is optional to add "REQUIRETLS=..." to "MAIL FROM" or it optional
to add "=..." with "REQUIRETLS"?  The first sentence suggests the
latter, but I don't think that makes sense.

What follows immediately below that paragraph is IMNSHO an overly
prescriptive disaster:

   o  CHAIN - The certificate presented by the SMTP server MUST verify
      successfully in a trust chain leading to a certificate trusted by
      the SMTP client.  The choice of trusted (root) certificates by the
      client is at their own discretion.  The client MAY choose to use
      the certificate set maintained by the CA/B forum [citation needed]
      for this purpose.

   o  DANE - The certificate presented by the SMTP server MUST verify
      succesfully using DANE as specified in RFC 7672 [RFC7672].

   o  DNSSEC - The server MUST confirm that any MX record or CNAME
      lookup used to locate the SMTP server must be DNSSEC [RFC4035]
      signed and valid.

   o  NO - The SMTP client SHOULD attempt to send the message regardless
      of its ability to negotiate STARTTLS with the SMTP server,
      ignoring policy-based mechanisms, if any, asserted by the
      recipient domain.  Nevertheless, the client MAY negotiate STARTTLS
      with the server if available.  If the NO parameter is present, any
      other REQUIRETLS parameter MUST NOT be used.

Setting aside the "NO" case, the remaining options are MUCH too precise.
The client should at most be able to specify:

	* ENCRYPT: must negotiate STARTTLS, but perhaps not authenticated
	* SECURE: must negotiate STARTTLS *and* authenticate the peer via
                  DANE, STS or local policy that provides active-attack
                  resistance for the nexthop destination.

I don't see anyone using "CHAIN", "DANE", "DNSSEC" or being able to
explain these to users.

I'll stop here for now, because the rest of the document is moot if this
issue cannot be resolved.

-- 
	Viktor.