Picking a somewhat arbitrary place to join this discussion... On 3/14/19 9:43 AM, Eric Rescorla wrote: > > Well, my point is that this use case is in direct conflict with the plain > text of the semantics of MTA-STS. >
IMO, characterizing MTA-STS and DANE as policy mechanisms is confusing. If it was a policy that the receiving domain wanted to enforce, it would not accept mail unless STARTTLS had been negotiated. But few general-purpose domains do that, because they don't want to cut themselves off from client MTAs that haven't implemented STARTTLS, or that can't negotiate compatible parameters. And of course MTA-STS and/or DANE are needed to protect against man-in-the-middle attacks by impostor server MTAs. MTA-STS and DANE are advertisement mechanisms: they are advertising that they support STARTTLS (possibly with reference to specific public keys their certificates contain). They are saying that it is inadvisable from a security standpoint to send mail to them unless STARTTLS can be negotiated (with the right public keys if applicable). But MTA-STS and DANE are not enforcement mechanisms. Domains publishing MTA-STS and DANE, by in large, still accept mail from MTAs that don't implement MTA-STS and DANE, and that therefore might send mail without STARTTLS. So they aren't enforcing their own policies, if the semantics of the policies involved enforcement. On 3/14/19 10:27 AM, Nico Williams wrote: > > In all cases where RFC8461 says what to do in the face of policy > failures, it refers to "a Sending MTA honoring MTA-STS" -- not a sending > MTA that implements MTA-STS, but one that honors MTA-STS. And that text describes how a client MTA uses MTA-STS as an advertisement mechanism. Another way to accomplish the effect of TLS-Required: no (for a single hop, anyway) would be to route the message through an MTA that (intentionally) does not implement MTA-STS nor DANE. That would be perfectly OK, so why is 'TLS-Required: no' in conflict? -Jim
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
