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

[Jim Fenton <[e-mail]>]

Responses inline.

On 3/3/17 4:36 PM, Viktor Dukhovni wrote:
>> 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.

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.
>
> 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.

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.

>
> === 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.

Good point.

>
> 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.

OK; I'm not sure I re-looked at the abstract when adding "MAYTLS".
>
> 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).

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.
>
> === 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.

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.

>
> 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.

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).
>
> I'll stop here for now, because the rest of the document is moot if this
> issue cannot be resolved.
>