Den 01. des. 2015 18:37, skrev Viktor Dukhovni:
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.
Which server name? I couldn't tell from this draft either which would be
presented or which would be stored (I assume you'd want them to be the
same).
Actually this highlights another problem: The draft claims to replace
section 2.4 of RFC 2591, "Server identity check", but fails to provide
replacement text for a crucial part of that document:
"If the match fails, the client SHOULD either ask for explicit user
confirmation, or terminate the connection and indicate the server's
identity is suspect."
This document doesn't say anything about what should happen once the
match is finished.
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?
The draft claims to have a normative dependency on RFC 6186. If the use
of RFC 6186 is not worth debating, the reference is worth deleting.
- 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
As I read that spec, it says mandatory to implement, not mandatory to
use (it's up to the application whether it claims to be capable of using
it or not) - but it permits servers to mandate its use. *Almost* there -
but if this draft wishes to mandate its use, it will have to say so (and
say which identifier it's going to send - AFAIK, it only gets to send one.)
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.