On Thu, Feb 28, 2019 at 02:49:13PM -0800, Jim Fenton wrote: > On 2/27/19 12:11 PM, Benjamin Kaduk 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. > > > Works for me. That might also clear up some potential confusion where > the spec refers to the REQUIRETLS SMTP extension and the RequireTLS > header field. It will need to be "TLS-Required: no" so there isn't a > space in the header field name. > > > > >>> 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? > > > Maybe not exactly in this context, but it's common for finer-grained > directives to take precedence over coarser ones (in routing protocols, > for example). So it seemed at least intuitive if not exactly logical.
Generally true, though here we see a fine-grained thing in domain A and a coarse-grained thing in related domain B (er, using the generic English definition of "domain", not the DNS one), so it's not quite as clear-cut. > > > > >> 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). > > > Yes, I understand the discussion was pushed out. > > > > >>> 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. > > > Thanks for explaining. I expect it to remain an optional feature. That's helpful to know, thanks. > > > >>> 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 see that Viktor has explained this better than I would have. (Thanks, > Viktor). > > > > >>> 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. > > > No existing deployments exist that we need to be compatible with in this > respect. Since the two mechanisms have opposite effect, the combination > should never happen. (My preference would be to just disallow it, but I don't plan to hold a DISCUSS point to force the change -- when I said "I'd like to discuss" that's all I wanted.) > > > >>> ---------------------------------------------------------------------- > >>> 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. > > > See Viktor's response. > > > > >>> 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/) > > > It could, but two mechanisms occur at different stages (envelope and > message data). The error would not be reported until the end of the DATA > stage of message transmission, although I suppose that's OK. We should > probably allocate another error subcode if we're going to do that. Understood. -Benjamin [more good stuff trimmed] _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
