Not my ballot thread, but "TLS Required: no" is a LOT clearer to me. I'm not the target audience, but the original order screws me up every time I see it in a ballot e-mail.
Do the right thing, of course. Spencer On Wed, Feb 27, 2019 at 2:11 PM Benjamin Kaduk <[email protected]> wrote: > On Tue, Feb 26, 2019 at 03:26:05PM -0800, Jim Fenton wrote: > > On 2/21/19 8:55 PM, Benjamin Kaduk wrote: > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > I'm pretty sad to see that the "RequireTLS: no" header field has the > > > name "require TLS" and the opposite semantics. It seems like the > > > positvie signal that we are trying to indicate is "Ignore TLS" or "TLS > > > optional" or similar; why does the header field need to be named > > > "Require TLS" -- isn't that confusing to users? > > "Ignore TLS" would have the wrong semantics; even with RequireTLS: NO we > > want it to negotiate TLS if it can; it's just that the sender is asking > > that TLS transport not be required by recipient policy for this > > particular message. "TLS optional" is closer (and is used in the heading > > of Section 4.2.2), but doesn't quite capture the intended meaning, which > > is "don't require TLS". > > I think even swapping the order to "TLS Required: no" would be an > improvement, since it's a declarative statement rather than an imperative. > > > > > > > While I understand that there can be cases where it is desired to > ignore > > > recipient-domain indications to use TLS, such as to report problems > with > > > the TLS capabilities of those domains, I have strong qualms about > > > describing this protocol as an "override" for DANE and MTA-STS, or that > > > such recipient-domain signals should be "ignored". In effect, by > > > attempting to do so, this document is fundamentally modifying the > > > protocol semantics for (SMTP) DANE and MTA-STS, something that can only > > > properly be done by clearly calling out the behavior change and an > > > Updates: relationship with the documents whose semantics are being > > > modified. Alternately, it could also be reasonable to remove claims of > > > "override" or "ignore" and to leave the semantics of the header field > as > > > being that the sender requests one behavior, and the MTA can balance > the > > > requests of the sender and recipient at their own discretion. This is > > > still not a great option, though, as it would seem to put multiple IETF > > > proposed standards at odds with each other. > > I don't like the "own discretion" option either; I feel like some > > desired behavior should be specified, even if it's as a SHOULD. Since > > RequireTLS: NO affects the handling of a single message, it should take > > precedence over a general policy published by a domain for all messages. > > I seem to be missing some logical steps here. Why does that conclusion > follow from that input? > > > As to whether REQUIRETLS updates those specifications, I understand from > > Alexey that there is some precedent for not calling out an "Updates" > > relationship for mail extensions such as this, and he has far more > > experience than I on such things. > > I think the plan is for the IESG to chat about this topic in real-time next > week (I was unable to make last week's call, unfortunately). > > > > > > > I'm also concerned about the apparent new burden placed on senders to > > > actively decide whether every outgoing message requires end-to-end TLS > > > protection or is safe to forward without TLS, especially in light of > the > > > apparent goal (see next paragraph) of quickly achieving > (near-)universal > > > deployment. There doesn't seem to be much in this document to justify > > > the stance that the default "don't care" option should be removed. > > I'm unsure whether or not near-universal deployment will ever be > > achieved. There are important use cases (reporters in remote > > jurisdictions sending email to their editors, dissidents communicating > > among themselves, workers at some sensitive NGOs communicating with > > their organizations) where limited deployment among these populations > > would be beneficial to protect their email against MITM attacks by > > middle-boxes would be beneficial. > > > > > > > > The "must chain forward to final delivery" property for the REQUIRETLS > > > option seems to present some incremental deployment difficulties, in > that > > > it will be nigh-impossible to successfully deliver such a message until > > > there is fairly significant deployment coverage. E.g., if any major > email > > > hosting provider does not implement, then it will forever remain a > niche > > > technology. What indication to we have that this technology can > succeed as > > > specified? If we anticipate it becoming a part of the de facto core, > > > mandatory, SMTP feature set, should we not indicate that by an Updates: > > > relationship? > > See above; I'm not sure whether it will remain a niche technology or > > not. I'm also not sure why the deployment coverage has to do with > > whether there should be an Updates: relationship. > > It's not directly related to the deployment coverage, but rather to the > sense of "is this something that we consider to be logically part of the > core minimum implementable unit?". If the deployment of this is big enough > that a substantial chunk of normal Internet-wide mail traffic sets the > REQUIRETLS tag, then de facto you must implement it if you want to keep > getting mail. That's the case that I'm worried about, though the > subsequent discussion has made me less certain that that will be the end > state of deployment that we reach. > > > > I'm also unsure exactly how tightly nailed down the (non-DANE) TLS > > > certificate validation process is supposed to be as a result of this > > > document; more in the COMMENT section. It seems that without some form > > > of strict certificate (host)name validation, this mechanism does not > > > actually mitigate the lack of server authentication by the client > that's > > > described as a goal. > > In what respect is the certificate name validation not strict? DNSSEC or > > MTA-STS is required to make sure that the MX hostname can't be altered > > in a DNS response, and that should be the name on the certificate. > > DANE and/or MTA-STS give me an MX hostname. Do I require that exact > hostname to be present in the X.509 certificate presented by the TLS > server? I didn't see any text in the document that clearly says the answer > is "yes". > > > > I'd also like to discuss whether it's safe to require that the tag and > > > header be mutually exclusive. (As per the COMMENT section,) I don't > have > > > a great picture on what scenarios could cause that to arise, how common > > > they are, and what the impact would be for strict enforcement. > > Section 4.1 describes the behavior if the MAIL FROM option and header > > field are both present: the MAIL FROM option wins. > > I'm not saying it's under-specified; I'm asking if there's a reason we need > to allow the combination at all. Are there existing deployments that allow > it that we need to be compatible with? Does it provide some benefit in > some use case? If there's no reason to have it, it just seems like > needless complexity and risk of misimplementation. > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > Section 2 > > > > > > o The certificate presented by the SMTP server MUST either verify > > > successfully in a trust chain leading to a certificate trusted by > > > the SMTP client or it MUST verify successfully using DANE as > > > specified in RFC 7672 [RFC7672]. For trust chains, the choice of > > > trusted (root) certificates is at the discretion of the SMTP > > > client. > > > > > > I don't see how this requirement restricts the presented end-entity > > > certificate so as to eliminate the attacks that exploit "the lack of > server > > > authentication by the client". What does certificate have to name in > order > > > to be trusted by the client? > > The certificate has to name the hostname returned by the MX record > > lookup that the client MTA thinks it is communicating with (or recipient > > domain name in the case of finding the MTA via an A record lookup). Does > > this requirement need to be more explicit? I thought it was obvious. > > "verify successfully" is pretty vague. Do I just verify the signatures > along the chain? Do I need to check those fiddly keyUsage bits? Do I care > what the CN/SAN is? We cite RFC 6125 in Section 4.2.1, but it's probably > prudent to reference it here as well. > > > > > > > Section 4.1 > > > > > > Upon receipt of the REQUIRETLS option on a MAIL FROM command during > > > the receipt of a message for which the return-path is not empty > > > (indicating a bounce message), an SMTP server MUST tag that message > > > as needing REQUIRETLS handling. > > > > > > What processing should happen when REQUIRETLS is received and the > > > return-path *is* empty? > > Ben Campbell caught this as well; the exemption for bounce messages in > > this section needs to be removed. > > > > > > If the REQUIRETLS MAIL FROM parameter is specified, the > > > RequireTLS header field MUST be ignored but MAY be included in > onward > > > relay of the message. > > > > > > How could this scenario arise? (Why is it not a user error to attempt > to > > > use both -- isn't one requiring TLS and the other disclaiming its use, > > > making them mutually incompatible?) > > It shouldn't normally happen, but I thought it worthwhile to define the > > behavior of the protocol in this case anyway. > > I agree that it's worthwhile. Could it be a hard error instead of this? > (Per https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/) > > > > Section 4.2.1 > > > > > > 2. If the server lookup is accomplished via the recipient domain's > > > MX record (the usual case) and is not accompanied by a valid > > > DNSSEC signature, the client MUST also validate the SMTP server > > > name using MTA-STS as described in RFC 8461 [RFC8461] > > > Section 4.1. > > > > > > What happens if this validation fails? Perhaps the below text "If any > of > > > the above fails" could include "(including MTA-STS validation)" for > extra > > > clarity. > > In this case, transmission of a REQUIRETLS-tagged message fails. > > > > > > 3. Open an SMTP session with the peer SMTP server using the EHLO > > > verb. > > > > > > 4. Establish a TLS-protected SMTP session with its peer SMTP server > > > and authenticate the server's certificate as specified in > > > [RFC6125] or [RFC7672] as applicable. > > > > > > "STARTTLS" does not appear in here anywhere. > > > Separately, is this combination of steps going to preclude any setups > that > > > (e.g., via preconfiguration) go straight to TLS with no STARTTLS > > > negotiation? > > Either STARTTLS or implicit TLS (i.e., on a different port) would > > satisfy this requirement. It's because of the "straight to TLS" case > > that STARTTLS isn't mentioned here. This is REQUIRETLS, not > > REQUIRESTARTTLS. > > I'm complaining more about the transition from (3) to (4) than either one > per se. If I open a connection and then establish a (new?) TLS-protected > session, that seems to mostly be STARTTLS. But if I use implicit TLS, why > do I need to bother with (3) at all? > > > > What name is used as input to certificate validation (for the 6125 > branch)? > > > Is Appendix B.4 therein supposed to be normative? (The Appendix B > header > > > indicates that the content is non-normative.) > > 6125 Appendix B.4 just quotes RFC 4954. Perhaps I need to be normatively > > referencing the latter instead? In any case, the intent is that the MX > > hostname match one of the names on the certificate. > > Given that 4954 just talks about the client's "understanding of the server > hostname", I'd suggest that this document explictly state that the MX > hostname must match, independently of the question of citing 4954 and/or > 6125 here. (Hmm, and Section 14 of 4954, that talks about "server > hostname", is predicated on supporting SASL [PLAIN] over TLS anyway, which > isn't particularly general.) So I'd be onboard with citing 4954 here > (possibly in addition to 6125?) but there likely still needs to be some > additional text discussion for clarity. > > > > Section 4.2.2 > > > > > > Some SMTP servers may be configured to require STARTTLS connections > > > as a matter of policy and not accept messages in the absence of > > > STARTTLS. A non-delivery notification MUST be returned to the > sender > > > if message relay fails due to an inability to negotiate STARTTLS > when > > > required by the server. > > > > > > This is an "inability to negotiate" combined with a rejection of > > > non-STARTTLS, right? > > This is just a situation where the server requires that TLS be > > negotiated, and the client isn't able to do that so delivery fails and a > > bounce is generated. This behavior isn't specific to REQUIRETLS at all. > > I think we're in violent agreement here. > > > > Section 5 > > > > > > The path from the origination of an error bounce message back to the > > > MAIL FROM address may not share the same REQUIRETLS support as the > > > forward path. Therefore, users requiring TLS are advised to make > > > sure that they are capable of receiving mail using REQUIRETLS as > > > > > > nit: "requiring TLS for outgoing mail"? > > Sure, but if you're requiring TLS through this mechanism it's > > necessarily for outgoing mail. > > > > > > If a REQUIRETLS message is bounced, the server MUST behave as if > > > RET=HDRS was present as described in [RFC3461]. If both RET=FULL > and > > > REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be > > > transformed to RET=HDRS on relay. The SMTP client for a REQUIRETLS > > > > > > If the MAY is not taken, will the next hop be obligated to detect that > this > > > is a bounce and apply the preceding MUSTs? If not, perhaps this also > > > should be a MUST? > > It seems like it should, yes. > > [this is covered downthread, it looks like] > > > > bounce message uses an empty MAIL FROM return-path as required by > > > [RFC5321]. When the MAIL FROM return-path is empty, the REQUIRETLS > > > parameter SHOULD NOT cause a bounce message to be discarded even if > > > the next-hop relay does not advertise REQUIRETLS. > > > > > > Perhaps an internal cross-reference up to Section 4.2.1 is in order? > > This section says, "ignore REQUIRETLS for bounce messages" so it > > shouldn't be doing section 4.2.1. Or perhaps I misunderstand the comment. > > I was just noting that 4.2.1 had the complementary text that exempted > bounce messages from certain REQUIRETLS processing; this comment may be > overtaken by events given some of the other ballot threads, though. > > > > Senders of messages requiring TLS are advised to consider the > > > possibility that bounce messages will be lost as a result of > > > REQUIRETLS return path failure, and that some information could be > > > leaked if a bounce message is not able to be transmitted with > > > REQUIRETLS. > > > > > > It's not really clear how actionable this is. If you have a message > > > that you want to send, you're either going to send it or not send it. > > > What would you change about the message based on whether or not you > > > could get a bounce, or whether or not the bounce would leak the message > > > contents? > > This is simply, "remember that you might not get a bounce". That's > > probably true anyway. > > > > > > Section 6 > > > > > > Mailing lists, upon receipt of a message, originate new messages to > > > list addresses. This is distinct from an aliasing operation that > > > redirects the original message, in some cases to multiple > recipients. > > > > > > I'm not entirely sure how universally acknowledged this claim is; at > > > MIT, we have lots of "mailing lists" implemented via the central Moira > > > management database, but the actual implementation on the mailhubs is > > > more like the aliasing operation described in the second sentence. > > > Is there a need to make this distinction in order to support the > > > following points, or could they stand on their own without this? > > There are lots of cases where a new message is originated as the result > > of a received message, mailing lists (as distinct from distribution > > aliases) being a very common one. But there are also various other > > things that originate new messages, like the vacation program, sieve, > > etc. Perhaps this section should be generalized, but right now it's > > setting context for how REQUIRETLS could be supported by mailing lists, > > at the list operator's discretion. > > To be clear, I'm not asking for any change here (and this is the > non-blocking COMMENT section anyway). I'm just noting my experience when > it seems slightly at odds with the text in the document. > > > > The requirement to preserve the REQUIRETLS tag therefore does not > > > necessarily extend to mailing lists, although the inclusion of the > > > RequireTLS header field MAY cause messages sent to mailing lists to > > > inherit this characteristic. [...] > > > > > > Maybe I'm confused, but doesn't the REQUIRETLS tag and the RequireTLS > > > header field have very different characteristics? I don't understand > > > which one "this characteristic" is supposed to refer to. > > Since header fields are typically copied into the messages sent by > > mailing lists, this would happen in the case of the RequireTLS header > > field as well. > > Maybe s/this characteristic/the header field/, then? > > > > Mailing list operators MAY apply REQUIRETLS requirements in incoming > > > messages to the resulting messages they originate. If this is done, > > > they SHOULD also apply these requirements to administrative traffic, > > > such as messages to moderators requesting approval of messages. > > > > > > Maybe note that such administrative traffic can include message > contents > > > intended for the list? > > I'm not sure what you mean here. The main concern is the compromise of > > metadata, i.e., that a particular user has subscribed to a list. I > > realize this isn't perfect, and that there are other ways (such as > > timing and size of messages) by which this could be inferred. > > I think that the compromise of non-meta data is also a concern, probably a > contender for "main" concern. > > Consider when I send a message, with REQUIRETLS tag and sensitive contents, > to a moderated mailing list. Mailman (among others?) will then accordingly > notify the moderator that a message requires action, and at least in some > configurations will *include the entire message contents* that need > moderation. So I'm saying that mailman should propagate the REQUIRETLS tag > when it's sending that "action required" message, since otherwise the > message contents that I, the sender, thought were protected by REQUIRETLS, > would lose that protection. > > > > Section 8.2 > > > > > > clear, where they can be intercepted. REQUIRETLS detects the > failure > > > of STARTTLS and declines to send the message rather than send it > > > insecurely. > > > > > > nit: I'd say that REQUIRETLS requires the detection and declining, > > > rather than doing so itself. > > Sure. > > > > > > REQUIRETLS > requires > > > successful certificate validation before sending the message. > > > > > > (As mentioned above, we need greater clarity about what the validation > > > specifically entails.) > > Addressed above. > > > > > > REQUIRETLS requires that the recipient domain's MX > > > record lookup be validated either using DNSSEC or via a published > > > MTA-STS policy that specifies the acceptable SMTP server hostname(s) > > > for the recipient domain. > > > > > > Are we then required to use those server hostname(s) in the certificate > > > validation portion of the TLS connection? > > Yes. > > > > > > Section A.1 > > > > > > In light of https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ > please > > > consider using IPv6 examples. > > > > OK, although this protocol does not reference IP addresses of any sort, > > so the improvement would be only decorative. > > Indeed. > > -Benjamin > >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
