Re: [dane] DANE SRV draft and SIP

[Viktor Dukhovni <[e-mail]>]

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.