On Tue, Dec 01, 2015 at 03:34:32PM +0100, Harald Alvestrand wrote:
If I understand this draft correctly, I object.
It says:
2. When using email service discovery procedure specified in
[RFC6186] the client MUST also use the right hand side of the
email address as another "reference identifier" to compare
against SRV-ID identifier in the server certificate.
The key word in that text is "another". This does not require the
server to have a certificate that matches this identifier, provided
there is some other some suitable identifier. It provides additional
flexibility, not a constraint.
NOTE HOWEVER, that use of the server name from the SRV record as
a DNS-ID reference identifier offers no security at all absent
DNSSEC. So "another" might become "only" in that case. The 6186
approach to address lack of trustworthy identifiers basically boils
down to "ask the user". Once the user confirms the SRV record it
becomes pinned, and the server name becomes one of the reference
identifiers.
My question upthread was whether this draft continues that legacy,
or departs from it.
HOWEVER:
If I understand RFC 6186 correctly, a (possibly large scale) IMAP email
service provider that wishes to serve a new domain "example org"
according to RFC 6186 must do two things:
I am not aware of any adoption of RFC 6186. Are there are any MUAs
actually doing RFC 6186 SRV lookups? If there are none, is it worth
debating?
- Change its certificate to include a complete list of all the domains
it is serving, and have its CA sign off on that certificate.
Not needed in the "ask the user" approach, which is what 6186
entails. Also not needed with SRV records protected with DNSSEC.
With plain-old SRV records, and no user confirmation, one is left
with no trustworthy identifiers other than SRV-ID (_imap.domainpart
of user's email address and the like).
So, if indeed MUAs want to implement this draft, and "ask the user"
is acknowledged as denial of reality, then they MUST use SNI.
For example RFC7671 and RFC7672 mandate SNI for DANE clients.
Indeed in TLS 1.3 SNI becomes mandatory to implement and send:
https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-8.2
The reason it cannot provide one certificate per served domain is that
neither this specification nor any other specification I have found says
that the client MUST include any distinguishing information (such as a
Server Name Indication) that says what name it is expecting the server
to provide service for.
See above.
--
Viktor.