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

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Mar 2017 19:36:58 -0500

> On Feb 14, 2017, at 12:51 AM, Jim Fenton <[email-masked]> 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.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 7 Mar 2017 13:55:11 -0800

Responses inline.

> recent reports indicate protects ~50% of web site visits.

I did not say that opportunistic STARTTLS is not useful. I said that
STARTTLS would be more useful if it wasn't only opportunistic. It's
important to start the document with a clear statement of the problem it
is solving, and this is the clear statement.
> the approach I'm suggesting.

I'll look at this, but remember that this is just the abstract. It's
intentionally short. I'd be considerably more open to providing more
detail in the body of the document.

> the TLS handshake and deliver in the clear!  So the last sentence should

Good point.

> abstract to the introduction.

OK; I'm not sure I re-looked at the abstract when adding "MAYTLS".
> similar defenses thereafter).

DANE, STS, and other policy mechanisms are opportunistic because there
is no assurance that the client will pay any attention to them. I have
tended to associate downgrade resistance with the use of weaker (perhaps
"export grade") encryption, and opportunistic with whether things will
be sent in the clear if encryption can't be negotiated at all, but
perhaps those aren't quite the right distinctions.
> latter, but I don't think that makes sense.

The intent here is that the "=..." is optional. If the REQUIRETLS option
is specified without the optional parameter, there are no requirements
on how the server certificate is to be validated.

> I don't see anyone using "CHAIN", "DANE", "DNSSEC" or being able to

Let me start with DNSSEC, because that has the strongest case. In the
absence of an authenticated MX record for the target domain, an MITM
attacker could just spoof the MX record, substituting their own mail
server (and of course authentication will succeed because the attacker
chose the MX record target). This does not require much in the way of
attacker capabilities in addition to those required to interfere with
STARTTLS negotiation. REQUIRETLS should not just address attacks that
currently exist, but also those that might be reasonably anticipated in
response to its deployment (or perhaps STS deployment).

I have been wondering whether the DNSSEC option should require the
recipient domain to be DNSSEC signed as is currently specified, or if it
should be sufficient for the accepting SMTP server to use a
DNSSEC-verifying resolver to detect problems for those domains that are
DNSSEC-signed. The latter is weaker, but more likely to actually find use.

Your ENCRYPT option is the default, in the absence of the optional "="
parameter.

I have trouble calling anything SECURE!

SECURE shouldn't cover the DNSSEC case, because authentication isn't
meaningful if the MX record is wrong (as described above). With respect
to CHAIN and DANE, perhaps those are too fine-grained, but unfortunately
it has been difficult to get rough consensus with only a couple of us
commenting on this. The real question is whether attackers that control
a root CA are part of the threat model. Or perhaps we should just let
DANE "speak for itself": if there are DANE records for the MX server,
require them (and don't have a separate option).