On 19/09/16 02:38, 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.
The draft is referring to the currently more common case where those policies or protocols are not in use. Possibly it could make that explicit. >> 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. > > 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 Why downgrade? Currently the proposal is for an absolute requirement of security; are you asking for an absolute requirement for plaintext and no peer-verification? Or are you asking for a means of providing permission for those (the word "MAY" suggests the latter to me)? If the latter - is there any difference from the current opportunistic use of STARTTLS, in the absence of system-policy, DANE or STS? - is the intent to override system-policy, DANE and STS? I am, at best, unconvinced as to the utility of a downgrade. > or perhaps > > TLS=MAY|ENCRYPT|SECURE > > where "ENCRYPT" can be unauthenticated, but "SECURE" requires > an authenticated connection. I don't like the word "SECURE"; it's not clear per. se. whether it requires encryption, endpoint-identity-verification, or both. > >> 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. Again the draft is speaking to the common case. Such industries could implement REQUIRETLS as a means of enforcing their policies, or remain with their current per-system policies, or run with both. >> 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 is optional in the syntax of the MAIL option. If present during reception, its semantics require it be used on any onward transmission. > >> 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. [...] > 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). Suspect you missed out a "should not be" at the end there? >> 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. Partially agree. We could make it clear that we're only covering the SMTP end-to-end (but including alias-style exploders) and specifically not covering mailinglist-style re-transmission. -- Cheers, Jeremy _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
