On Tue, Oct 24, 2017 at 12:10:57PM +0200, Daniel Margolis wrote: > > In short, I see neither strong arguments against SNI nor any particular > reason to support it. I agree with Viktor that we can just require it (with > Ivan's language) so as to move the spec forward and be future proof. That > sounds less than satisfying to me, but it's not something I'd lose sleep > over.
One thing to be _very_ careful of is not to break SNI semantics. Which include "one name, which has to be correct". SNI assumes the web model, where there is only one correct name the client wants to connect to. In fact, the specification has a note that earlier drafts supported multiple names, but this was explicitly dropped as not useful. One way to do that with sending SNI would be: - Check received MX (and SRV?) records against the policy (including the possible implicit MX). Discard all that do not match. If no targets remain, raise temporary error. - Pick a mail exchanger from the remaining entries, look up its address, and connect with SNI being the target of the MX (or SRV?) record (without chasing CNAMEs). And since SNI is intended for "one name" standard certificate name validation scenario, this would also allow using the standard name validation instead of the wildcard-to-wildcard matching. There are a few problems with combining this with "vanity" names: - One has to either break RFCs by pointing MX to a CNAME, or to shadow provoder addresses (I think some DNS provoders allow automatic address shadowing). - If one wants balancing among multiple provoders, one needs multiple names. An alternative I see would be to specify SNI values to use in policy. Or not sending SNI values at all. -Ilari _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
