> On Aug 22, 2016, at 10:53 AM, Jeremy Harris <j...@wizmail.org> wrote:
> 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.
Delivery is not prioritized over security when the sending domain's
policy requires TLS for the given destination; or when the receiving
domain publishes DANE or (less reliably for initial delivery) STS
policy. What's opportunistic in the presence of DANE or STS is the
use of the stronger requirement dynamically, destination by destination,
via discovery of the destination's policy.
> This document
> describes a complementary SMTP service extension, REQUIRETLS. If the
> REQUIRETLS option is used when sending a message, it causes message
> transmission to fail if a TLS connection with the required security
> characteristics cannot be completed with the next hop MTA, or if that
> MTA does not also advertise that it supports REQUIRETLS. Message
> originators may therefore expect transport security to be used for
> messages sent with this option.
So I think the abstract can start with this text. I think that
"next hop" should be "next-hop". And of course, I still think
that the specification should be able to specify both upgrade
and downgrade of TLS policy, so not "REQUIRETLS", but
where "ENCRYPT" can be unauthenticated, but "SECURE" requires
an authenticated connection.
> 1. Introduction
> The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a
> means by which an SMTP server and client can establish a Transport
> Layer Security (TLS) protected session for the transmission of email
> messages. In this application, TLS is used only upon mutual
> agreement (successful negotiation) between the client and server; if
> this is not possible, the message is sent unencrypted.
Once again, while RFC3207 is silent on TLS policy, (IMHO rather wisely
defining only the mechanism), it is not the case the result is always
cleartext fallback. Indeed, in some industries, it is rather common
to arrange bilateral mandatory TLS policies between peer organizations.
> Even if a TLS
> protected session is established, it is uncommon for the client to
> abort the SMTP session if certificate validation fails to
> authenticate the SMTP server.
This is a feature, not a bug, it has led to rather wide adoption of
SMTP TLS encryption. There's no need to disparage the state of TLS
in SMTP. Rather, just start with the case for this extension.
> The 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.
This is adequately covered in Section 1.3 of RFC7672 and likely need
not be repeated here.
> The REQUIRETLS SMTP service extension allows the SMTP client to
> specify that a given message sent during a particular session MUST be
> sent over a TLS protected session with specified security
> characteristics. It also requires that the SMTP server advertise
> that it also supports REQUIRETLS, in effect promising that it will
> honor the requirement to require STARTTLS and REQUIRETLS for all
> onward transmissions of messages specifying that requirement.
Thus I think you should start with and expand on the need for per-message
> o Any server authentication requirements specified as an option to
> the REQUIRETLS option (see below) MUST have been satisfied in
> establishing the current session.
Again change REQUIRETLS to TLS or TLSPOLICY as an attribute-value
pair with the policy in question as the value.
> 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.
In which case the parameter ceases to be optional.
> 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
Multiple values seem needlessly complex. This mechanism should not
> 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 
> for this purpose.
See above for the MAY|ENCRYPT|SECURE trichotomy, anything more is much
to complex to be usable. An overly detailed specification will make
this specification unusable, and thus futile. In particular, only
the need for authentication can reasonably be specified, the mechanism
(WebPKI, DANE, STS).
> o DANE - The certificate presented by the SMTP server MUST verify
> succesfully using DANE as specified in [RFC7672].
Much as I am spend my time promoting DANE, this is a mistake. Such
a requirement is overly prescriptive.
> 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.
This too is most likely misguided.
> The CHAIN and DANE parameters are additive; if both are specified,
> either method of certificate validation is acceptable. If neither
> CHAIN nor DANE is specified, the certificate presented by the SMTP
> server is not required to be verified.
> 3.1. REQUIRETLS Receipt Requirements
> Upon receipt of a REQUIRETLS option on a MAIL FROM command during the
> receipt of a message, an SMTP server MUST tag that message as
> requiring TLS transmission with the specified option(s). The manner
> in which this tagging takes place is implementation-dependent. If
> the message is being locally aliased and redistributed to multiple
> addresses, all instances of the message MUST be tagged in the same
This is not always possible. Once a message leaves the world of SMTP
relaying, and is handed off to delivery agents, it is no longer possible
to convey the TLS requirements, but some delivery agents re-inject email
back into the email system for further delivery. This is quite common
with mailing lists, or gateways to SMS systems, ... Indeed it is not
clear that one should be able to specify mandatory TLS only as far as
the list server and not beyond.
> 3.2. REQUIRETLS Sender Requirements
> When sending a message tagged with a TLS requirement, the sending
> (client) MTA MUST:
> o Look up the SMTP server to which the message is to be sent. If
> the DNSSEC option is included in the message tag, the MX record
> lookups in this process MUST use DNSSEC verification and the
> response(s) MUST be DNSSEC-signed in order to ensure the integrity
> of the resource identifier [RFC6125] used to authenticate the SMTP
Again the use of DNSSEC should not be specified. The MTA is responsible
for achieving "MAY|ENCRYPT|SECURE" via some suitable mechanism. Anything
more specific will defeat this enterprise by making too much email
> 7. Security Considerations
> The purpose of REQUIRETLS is to improve communications security for
> 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,
> which favors delivery over the ability to send email messages using
> transport-layer security, to one in which messages are not
> transmitted unless the required security is available.
This will need to change if the extension is made more flexible to
specify both upgrade and downgrade policies.
Uta mailing list