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

[Eric Rescorla <[e-mail]>]

On Fri, Oct 27, 2017 at 11:03 AM, Chris Newman <[e-mail]>
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
>