On 27 Oct 2017, at 11:34, Eric Rescorla wrote:
On Fri, Oct 27, 2017 at 11:03 AM, Chris Newman
<chris.new...@oracle.com>
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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
