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

["Chris Newman" <[e-mail]>]

On 27 Oct 2017, at 11:34, Eric Rescorla wrote:
> 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"?

Partly correct, but insufficient to support MUAs that don't implement 
RFC 6186 (which is presently the majority of MUAs). If a mail hosting 
company wants to use SNI to host multiple domains, it has two naming 
approaches for non-6186 customers:

1. customer1.mailhosting.example, customer2.mailhosting.example
2. or customer1.example, customer2.example
(these names can point to the same IP addresses)

These names will be used both for SNI and as the DNS-ID in the 
certificate. If the site chooses to support RFC 6186, then RFC 7817 
requires the certificates have an SRV-ID _in addition to_ the DNS-ID 
(and 6186 clients are required to check the SRV-ID).

So I think my proposed additional statement in combination with the 
requirements in RFC 7817 is sufficient to clarify what goes in SNI and 
to define secure use of RFC 6186 discovery.

		- Chris

> -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
>>