> On Oct 27, 2017, at 2:03 PM, Chris Newman <chris.new...@oracle.com> wrote: > > I just re-read the related text a bit more carefully. Although RFC 7817 > adequately covers what subjectAltName identities mail servers need to support > in certificates, it doesn't cover what goes in SNI (although it mentions > SNI). Ditto for RFC 6186. This is annoying; the issue really should have been > addressed in 7817 or 6125 :-(
My take is that use of SRV-ID will see negligible or no adoption, and so despite https://tools.ietf.org/html/rfc7817#section-5.1 there is no likely value in sending anything other than the target hostname in SNI. Validation of the SRV record via the WebPKI rather than DNSSEC is from this perspective basically unrealistic. > I suspect in practice that most MUAs use the post-SRV-lookup hostname in TLS > SNI. Agreed, where most is ~100%. > And server support for that name form in SNI will be necessary to interoperate > with MUAs that don't support RFC 6186 Agreed. > (or use an alternative autodiscovery mechanism in preference to RFC 6186). So > the remaining question is would it be useful/helpful for a server to also > support an SNI based on the SRV record or SRV-ID name? I don't think the > answer to that question is important enough to justify a normative change to > this document. My take is that support for SRV-ID in SNI would be largely pointless. > To address this, I suggest we add a sentence to the end of section 4.4 (just > before the sentence referencing 7817): > > -- > Mail servers supporting SNI need to support the post-SRV hostname to > interoperate with MUAs that have not implemented RFC 6186. > -- > > I view that as a statement of fact rather than a normative change so I think > it's kosher. Saying more on the topic would probably cross the normative > change line so I'd prefer not to go there. Works for me. Of course another way to interoperate (for servers that don't TLS virtual hosting) is to simply ignore any SNI extension from the client and always present the same (sole) server certificate chain. -- Viktor. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
