On 9/18/16 6:38 PM, Viktor Dukhovni wrote: >> On Aug 22, 2016, at 10:53 AM, Jeremy Harris <j...@wizmail.org> wrote: >> >>> draft-fenton-smtp-require-tls > ion >> Abstract >> >> 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.
It's still opportunistic from the standpoint of a user sending a message and asking whether the message will be transmitted securely. A large provider is very unlikely to broadly establish policies requiring TLS for their outgoing messages, even for specific destination domains, because of the possibility that something will break (e.g., certificate expiration) and cause their outgoing mail to queue. This would potentially affect large numbers of their customers who don't care about TLS. Also, that only applies for the first hop. What about after that? I would not expect the user to research the DANE or STS status of their mail recipient. In the general case, with mail forwarders, it's not even possible to do that. > >> 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 > > TLS=MAY|MUST > > or perhaps > > TLS=MAY|ENCRYPT|SECURE > > where "ENCRYPT" can be unauthenticated, but "SECURE" requires > an authenticated connection. Hyphenation: agree. I don't understand the difference between TLS=MAY and not specifying REQUIRETLS at all. > >> 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. My experience is that cleartext fallback is common, and that it is exploited by certain "email firewall" products as well as at a national level in some places. I will change this to "the message is often sent unencrypted" since the statement is too absolute now. > >> 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. I understand why it is the way it is, and did not disparage TLS in SMTP, but merely stated the way that it works. Is there anything inaccurate in that sentence? > >> 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. Maybe, but it's not a lot of repetition and helps establish the motivation. > >> 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 > policy signaling. > >> 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. Are you suggesting that the name of the service extension, the MAIL FROM option, or both? I am reluctant to use the word "policy" because of confusion with MTA STS and I don't think of something that applies to a single message as much of a policy, any more than the recipient address is a policy on where to deliver the message. > >> 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. For onward transmission of that particular message? Yes. Broadly however, the parameter is optional: MTAs implementing REQUIRETLS are not required to include the REQUIRETLS option on every message they send. > >> 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: > Multiple values seem needlessly complex. This mechanism should not > be over-engineered. I noted this comment from the last version, and am looking for more opinions on this. > >> 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. > 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). This looks to be a reasonable simplification if rough consensus is that we should simplify as you suggest. > >> 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. Please elaborate on 'misguided': also overly prescriptive? Unlikely to be used? > >> 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. > See above. > >> 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 >> manner. > 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. See section 5 for discussion of mailing lists. It is recognized that some MTAs may not be able to guarantee onward use of TLS; they must not advertise REQUIRETLS or at least must not accept REQUIRETLS-tagged messages. > >> 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 >> server. > 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 > undeliverable. As noted above. > >> 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. I'm still not understanding the concept of downgrade policies that you're describing. -Jim _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
