> More importantly, I think MTA-STS should > mandate SNI usage. I believe you > are referring to HTTPS MTA-STS policy distribution service, and do no see any > reason not to include SNI requirements in the spec.
Sent from Yahoo Mail for iPhone On Friday, October 13, 2017, 8:19 AM, Ivan Ristic <ivan.ris...@gmail.com> wrote: On Thu, Oct 12, 2017 at 12:03 PM, Daniel Margolis <dmargo...@google.com> 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 <ilariliusva...@welho.com> 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 Uta@ietf.org https://www.ietf.org/mailman/l istinfo/uta ______________________________ _________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/ listinfo/uta -- Ivan_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
