On Thu, Oct 12, 2017 at 10:53 AM, Daniel Margolis <[email protected]> wrote:
> In the scenario you describe (in which the MX servers have certificates > that are not CA-validated), MTA-STS is simply not applicable. > > I think your point is that it could be useful to allow MTA-STS to be used > in this case (because the recipient domain may not have DNSSEC but the MX > domain may), which is fair, but I suspect esoteric and not worth the > additional complexity, for a few reasons. First, big providers tend to be > the ones who find it harder to deploy DNSSEC, not small personal domains, > so the scenario you describe is, I think, not so common. But it's also the > case that supporting a "mixed" mode like this is quite difficult; what does > "mode=report" then do in "TLSA" usage? What does a sender who can do CA > validation but not DNSSEC validating resolves do? The complexity this > introduces is severe. (If you read back on the list archives, the early > drafts of this proposal *did* support DNSSEC/TLSA validation of MXs as an > alternative to CA, but we removed this to reduce the unneeded complexity!) > I think I agree with your assessment. I just think it would be better to clearly say "MTA-STS is not designed to be used with DANE". Otherwise, you will inevitably get people attempting to use it. Well, that will probably happen anyway, but you'd at least be able to point them to the spec :) I'm not sure I follow your point about hostname validation. Is your point > that MTA-STS may consider a given MX to be valid (due to one of the SANs > matching the pattern in the policy) but DANE may not? That's certainly > possible, but a non-issue; it's up to deployers to not send conflicting > signals if they deploy both DANE and MTA-STS, no? > Sorry, I should have made it more clear. I was using the conflict to give a supporting example for the conversation in the other thread. The custom MX hostname validation in MTA-STS conflicts with DANE, not because it's DANE, but because it does way differently from everything else in TLS. In TLS, you decide which host you want to connect to, then you validate the connection is valid for that hostname. So my point would be that there may be other conflicts that we're not aware of, and that TLS/PKI may evolve in a direction that creates new conflicts in the future. > On Thu, Oct 12, 2017 at 11:01 AM, Ivan Ristic <[email protected]> > wrote: > >> In re-reading the spec, I noticed that the spec, as it's written now, >> effectively forbids DANE authentication, which may or may not be what you >> wanted. >> >> I am thinking about a scenario in which I outsource my email to a >> third-party. Let's assume that I don't have DNSSEC on my domain name >> user.com but that the provider does on their provider.com. Consequently, >> their SMTP servers (mx.provider.com) might conceivably have self-signed >> certificates that rely on DANE for validation. >> >> MTA-STS is still useful in this case because it prevents MITM from >> manipulating the MX servers that are allowed to receive email for >> user.com. >> >> I've read the DANE language in the spec that says that MTA-STS doesn't >> override DANE. That's fine. But should a MTA-STS-aware client fail a sever >> with a non-public certificate that's DANE-validated? I think the answer is >> probably yes, but perhaps that should be explicitly stated in the spec. >> >> This is also an area where the current hostname matching might interfere >> with DANE, because DANE is validated for the specific hostname that you're >> connecting to, and all other hostnames in the certificate are ignored. >> >> -- >> Ivan >> >> _______________________________________________ >> Uta mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/uta >> >> > -- Ivan
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
