Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

[Viktor Dukhovni <[e-mail]>]

> On Oct 27, 2017, at 2:03 PM, Chris Newman <[e-mail]> 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.