On Tue, Apr 23, 2013 at 10:34:02PM +0200, Olle E. Johansson wrote:
> RFC 5922 will still apply for non-DANE clients - but my biggest
> worry is the certificates.
>
> RFC 5922 hasn't really been used, I've seen no commercial vendors that
> sign certs with SIP URI's in subj alt names. If a server needs to support
> both (and doesn't support TLS SNI) the certificate requirements will lead
> to a messy cert indeed. We will have to have server names for all the
> servers in the SRV DNS alt names, all the supported SIP domains in URI
> subj alt names. That's quite a lot of information in one certificate for
> a service, and something that will be hard to get people to create and
> install.
Perhaps the lack of deployment of the public CA PKI with SIP is
not unrelated to similar lack of deployment with SMTP. If the
legacy PKI is neither used nor usable, then the specification
defining it is practically irrelevant. So unlike the browser case
you could perhaps assume that DANE is starting with a clean slate.
> If we're not going down this route, which name do we use in DNS to find data
> related to the SIP certificate for a domain?
Presumably the goal with SIP is to build a hop-by-hop secure channel
to a given destination. With protocols like SMTP that obtain peer
gateway information from DNS, this leads to two questions:
- How do you securely determine the peer gateway endpoint.
- How do you establish a secure connection to that endpoint.
Before DNSSEC the first question had no adequate answer, so all
the security effort went into overloading a single certificate to
answer both questions by authenticating the gateway's association
with the destination domain. This scales poorly and deployments
are isolated islands.
With DNSSEC and DANE the two questions become independent.
- Use DNSSEC to securely obtain a binding from the destination
domaint to the gateway.
- Use certificates to authenticate the gateway connection.
This means that the gateway certificate with DANE encodes the name
of the gateway ideally in a subjectAltName that also specifies the
protocol or service. So I would go with:
sip:gateway.example.com
as the name in a DANE-compatible SIP server certificate. I would
also strongly recommend that any server publish exclusively "IN
TLSA 3 1 1 ?" associations, which make the name in the certificate
moot, since these certificates are matched by public-key alone.
They can carry the legacy altnames for the old PKI if desired.
If an organization wishes to deploy a multi-level PKI, and publish
"IN TLSA 2 1 1" associations, then the name comes into play, and
the server may need to support SNI when virtual hosting 3rd-party
domains with TLS security. In practice this may be sufficiently
inconvenient that almost nobody does it.
This brings us back to my upthread point about "discovery" of TLS
support. With SMTP we have a fortuitous accident, nothing in either
the email address or the MX record gives us any information about
TLS. This means that we can overload DANE TLSA RRs to securely
infer TLS support *with* DANE verification (falling back to just
mandatory TLS when all the TLSA RRs are unusable).
With SIP, if I understood correctly, TLS transport is encoded in
NAPTR records, which are not DANE-specific. This creates a problem,
because NAPTR might mean TLS with legacy PKI and perhaps DANE, if
appropriate TLSA records are found. So a SIP domain can't signal
TLS support to DANE-enabled clients without also signalling TLS
support to legacy PKI clients.
My proposal would be to find a way to use DANE TLSA RRs to *upgrade*
what look to legacy clients like non-TLS NAPTR records to TLS.
Then, one can deploy servers that only support TLS with DANE, and
non-DANE clients get legacy (in)security. (This would mimmic closely
the SMTP situation where sans TLSA RRs, there is no explicit security
except by prior bilateral arrangement).
If you're stuck with bolting DANE into a TLS channel implied by
NAPTR records that apply to both legacy and DANE PKIs, then indeed
the certificate requirements are rather messy, but in that case
using exclusively "IN TLSA 3 1 1" gets the server out of any
DANE-specific naming mess. It need only support SANs for the legacy
PKI, with "3 1 1" only the server public key is relevant with DANE
(there is a bug to fix in draft-ietf-dane-srv in this respect, as
it incorrectly requires name checks for all certificate usages).
For SIP neophites like me, can you sketch out the channel discovery
in a bit more detail, by posting a complete example of all the
relevant DNS records for some hypothetical SIP service @example.com?
What does the phone do? What does its local gateway do? Is DANE
intended to be pertinent for both, or are we primarily interested
in the gateway-to-gateway traffic?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
