On Thu, Oct 12, 2017 at 12:03 PM, Daniel Margolis <[email protected]> wrote:
> 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 :) > > > It *can* be so used. Of course, if you publish an MTA-STS policy that is > invalid, senders who validate MTA-STS may not deliver mail to you, > similarly if you publish a TLSA record for your MX that is invalid. I would > not say anyone has to choose one *or* the other, especially since that > may limit their ability to secure mail to their domain (since some senders > may only validate DANE and some may only validate MTA-STS). We do not want > to tell people to make a choice, do we? > > Furthermore, it is not compatible with sending SNI either. There are >> servers out there that will outright abort on unknown SNI, and the SNI >> specification explcitly states this as one of recommended outcomes, >> with note that trying to continue probably won't work. > > > To be clear, the specification suggests SNI as useful for *policy* hosting > (on the HTTPS endpoint), not MX matching. There's not a direct relationship > between SNI on the MTA-to-MTA connection and the MX identity verification, > except insofar as that if SNI is used, the MX just has to return a > certificate which matches the policy, same as if SNI is not used. > I am sorry, I couldn't find where SNI is mentioned in the MTA-STS spec; could you point me to the relevant section? More importantly, I think MTA-STS should mandate SNI usage. It's taken the HTTPS world many years to finally approach the point where virtual secure hosting is possible. Given that MTA-STS is opt-in, I think SNI should be mandatory. Otherwise anyone offering mass-email hosting will be in a world of pain, having to resort to splitting traffic across IP addresses. I will respond more thoroughly on the other thread, though, to keep these > two points separate. > > On Thu, Oct 12, 2017 at 12:37 PM, Ilari Liusvaara < > [email protected]> wrote: > >> On Thu, Oct 12, 2017 at 11:16:18AM +0100, Ivan Ristic wrote: >> > >> > 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. >> >> It does not just conflict with DANE, it also conflicts with some TLS >> client APIs. And I would imagine that authors of such APIs would _not_ >> be supportive of additions to support nonstandard name matching (I >> can certainly say I am not). >> >> Furthermore, it is not compatible with sending SNI either. There are >> servers out there that will outright abort on unknown SNI, and the SNI >> specification explcitly states this as one of recommended outcomes, >> with note that trying to continue probably won't work. >> >> >> >> -Ilari >> >> _______________________________________________ >> Uta mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/uta >> > > > _______________________________________________ > 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
