On Fri, Oct 27, 2017 at 11:03 AM, Chris Newman <[email protected]> wrote:
> On 26 Oct 2017, at 19:56, Keith Moore wrote: > >> On 10/26/2017 07:18 PM, Chris Newman wrote: >> >> Line 304 >>>>> preference to services supporting STARTTLS (if offered). (See >>>>> also Section 4.5.) >>>>> I note that 6186 is kind of unclear on what should go in SNI. It >>>>> obviously >>>>> needs to be what you are checking against (which 6186 gets right) but >>>>> maybe >>>>> it's worth clarifying in this document somewhere. >>>>> >>>> Hmm. I might need to come back to that one. Lots of layers to sift >>>> through. Feel free to suggest text. >>>> >>> >>> I believe RFC 7817 handles this issue sufficiently. >>> >> >> Not sure whether EKR was referring specifically to the use of SNI with >> SRV records or not, but that's what I had assumed he meant. So far I >> haven't found any specific advice for (a) what name the MUA should specify >> in SNI, or (b) what names the server should recognize and have certificates >> for. It's pretty clear that the server needs to have a certificate for >> the name on the right hand side of the SRV record, but should it also have >> a certificate for the name on the left hand side? (e.g. _pop3s._ >> tcp.example.com?) That would potentially make SRV discovery more secure. >> >> But I think that's well beyond what the WG (and IESG) approved. So I >> guess I'm inclined to leave the -10 text as it is now without specifically >> addressing this issue. >> > > 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 :-( > > I suspect in practice that most MUAs use the post-SRV-lookup hostname in > TLS SNI. And server support for that name form in SNI will be necessary to > interoperate with MUAs that don't support RFC 6186 (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. > > 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. > -- > So to be clear, what you are saying is that when I enter "mail.example.com" but it's hosted on "mailhosting.com", and that indirection is done via SRV, that the certificate contains "mail.example.com" but the SNI contains " mailhosting.com"? -Ekr 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. > > - Chris >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
