On Sat, Apr 11, 2015 at 01:08:59PM -1000, 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. 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?
Well, without DANE, all the various hosts providing the service,
would now certificates for the name of the service domain, rather
than just the service for which they are targets, some of these
might be hosting providers for just that service. So there use-cases
in which it is highly desirable that all clients either don't do SRV
lookups, or if they do, that they support SRV-ID.
> 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.
Times change. CAs can issue new certificates if there is demand.
The first step is client support, then server operators can start
asking for these once enough clients are on board.
We're also going to ask CAs to support Curve 25519 certs, later
new hash functions...
> 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.
The CAB forum is all about browsers, not too much represenation
from the email world there.
> 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.
That cripples non-DANE email hosting, and makes security for hosted
RFC 6186 services rather tricky (leap of faith).
> 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.
Clients can support the extension before any such certificates are
available. The draft is not mandating that clients *only* support
SRV-ID. Once MUAs routinely support SRV-ID, servers can start
deploing it. This is how progress is made. It takes time.
I don't much care what the CAB forum has espoused, they have a
narrow and short-term view of the world.
> Are there any existing MUAs, certificate verification libraries,
> and/or mail servers that implement support for SRV and SRV-ID that can
> be used for interop testing?
They need to be built. Help would be appreciated. I'll look into
adding support in OpenSSL. You might help with NSS, ...
> > However, with DANE, this or a follow-on document needs to specify
> > whether SRV-ID should be supported as a secondary identifier to
> > support mixed deployments in which the SRV-ID certificate is the
> > only only one available.
>
> I would expect that if a certificate is involved then the certificate
> will be used, and that DANE will be used only to help authenticate the
> certificate. Otherwise, there wouldn't be a certificate involved and
> the document wouldn't be applicable, right?
DANE is indeed mostly about explicit trust anchors, however DNSSEC
protects otherwise insecure service redirection (SRV, MX, CNAME,
...) and makes it possible to authenticate the target, so reference
identities with DANE are different than without (indeed entirely
ignored with DANE-EE(3) for which the peer identity is validated
exclusively through DNS).
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-3.1.1
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-3.1.2
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-3.2.1
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-3.2.2
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
