Hi Brian,
On 12/04/2015 00:08, Brian Smith wrote:
Viktor Dukhovni <[email protected]> wrote:
Brian Smith wrote:
That said, maybe I'm not understanding the importance of SRV-ID.
Clarification of why supporting SRV-ID is important would be useful.
My understanding is that clients should support SRV-ID when they
locate the submission or IMAP service via SRV records.
Correct.
Most MUAs
don't do SRV lookups for either, and therefore don't need to support
SRV-ID.
Even if the client uses SRV records, it will still operate just fine
using DNS-IDs and without supporting SRV-ID, right?
In general case this is not true. This will only work correctly if DNS
SRV is pointing to a server in the same DNS domain.
Take for example a case where email addresses @example.com are
outsourced to another provider, e.g. gmail.com
When a client connects to IMAP service for example.com, it needs to know
that imap.gmail.com is a legitimate server for this service. So either
imap.gmail.com's TLS certificate needs to include sRVName
_imap.example.com or it needs to include dNSName for example.com. The
latter is of course problematic if only IMAP service is delegated to
imap.gmail.com.
(And yes, DANE can be used to address this as well, but it depends on
another service that need to be deployed)
I re-read what RFC 6125 says about using SRV-IDs instead of DNS-IDs to
restrict which services a certificate is valid for.
Yes, this is the main part of it.
I also read RFC
6186 regarding the use of SRV records to support email client
auto-configuration. The goals of each seem reasonable. But, it seems
too early to mandate SRV-ID support.
First, note that the CABForum Baseline Requirements [1] say, regarding
subjectAltName: "This extension MUST contain at least one entry. Each
entry MUST be either a dNSName containing the Fully-Qualified Domain
Name or an iPAddress containing the IP address of a server." Thus, a
certificate that conforms to the CABForum Baseline Requirements MUST
NOT contain any SRV-ID subjectAltNames.
I would not interpret it like this, because CABForum can't talk for uses
of TLS outside of the browser world.
XMPP uses presence of XMPP URIs (see Section 13.7.1.4 of RFC 6120) in
subjectAltName for TLS verification. According to your interpretation
CABForum certificates disallow XMPP use as well.
It is reasonable--some would even say good--for a MUA to use
certificate verification logic that only validates certificates that
are valid according to the CABForum Baseline Requirements. In that
case, the certificate verification logic doesn't need to support
SRV-ID at all, since instead it should reject--or, if it wants to be
liberal, ignore--all SRV-ID subjectAltName entries.
Further, because of what the CABForum Baseline Requirements say, it
seems like it would be very difficult to get a certificate that
contains SRV-ID subjectAltNames from a CA that typical MUAs trust.
Are there any existing MUAs,
Yes.
certificate verification libraries,
and yes. I am tempted to collect more information and show examples of
how this can be done in Java and using other open source libraries.
and/or mail servers that implement support for SRV and SRV-ID that can
be used for interop testing? Has any interop testing been done yet?
Not that I am aware of, but I am happy to talk about this off-list.
I think such interop testing should be done before SRV-ID support is
mandated or recommended.
Some comments:
1) I've looked at several big Mail Service Providers and pretty much all
of them use DNS SRV to advertise location of their submission/imap
servers. They don't user sRVName in subjectAltNames, which makes it
impossible for email clients to verify whether such servers are
legitimate. So I think something needs to be done to address this problem.
2) I am expecting that some CAs would be unable to validate/accept
sRVNames in certificate signing requests. This can be intentional and
can be covered by "local policy". But at least they must not crash and
burn when they encounter sRVName in subjectAltNames.
3) This document is not reflecting universally widespread practice,
because frankly too many email clients don't verify TLS certificates,
and server certificates don't comply with very basic requirements
expressed in much earlier RFCs. I don't believe there is a requirement
for a Standard Track RFC to only reflect what is already deployed, in
many cases Standard Track RFCs are drawing attention to what should be
the recommended practice.
Best Regards,
Alexey
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
