Subject: [dane] Updated version of SIP DANE brainstorm

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 4 Jul 2013 14:46:12 +0200

Hi!

I've updated my brainstorm of SIP & Dane. The new version can be found here:
http://www.slideshare.net/oej/sip-dane

Changes:
- Clarified TLSA records and validation (Cullen, Victor)
- Added thoughts on SIP connection reuse

SIP connection reuse is the art form of re-using a TLS connection between two SIP servers for more than one destination - in the case of SIP hosting with multiple domains.
The current RFC is based on exchanging server and client certificates with a list of domains in the SubjAltName field. 

With DANE, there will be only the SRV host name. The server needs to look up domains and if there's a secure delegation from a new domain to a hostname where
the server has a connection, add the domain to the domain table for that connection and reuse it.

Now the question is raised in my head - what about the client certificate?

We get a connection from an IP address and request a client certificate. Is it really needed? In the current RFC it's a requirement.

Server for example.com gets a connection from serverb.example.net. The example.com domain relationship to the actual host srv02.example.com
was verified using DANE and the cert validated correctly.

Now if example.com has a SIP request addressed to example.net - it checks DNS and gets DNSsec signed responses that points to serverb.example.net.
Is this enough to reuse the existing TLS connection for requests to example.net?

Or do we need a certificate on top of this somewhere?

/O

References:
- RFC 5923 describes SIP connection reuse
- RFC 5922 defines SIP domain certificates

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Jul 2013 16:35:02 +0000

> - Clarified TLSA records and validation (Cullen, Victor)

On slide 11 you state that with DANE TLSA certificate usage 0/1 after
matching the TLSA RR the certificate is verified "as before".

It is true that the chain's validity is verified via PKIX as before, but
name checks (which RFC 6698 does not detail, so this will be discussed
in my "ops" draft) should look for the "base domain" of the TLSA RRset.

Since DANE TLSA base names are fundamentally DNS entities, the
corresponding certificate element must be a DNS subjectAltName.

You seem to assume that clients will check both subjectAltNames
and the CN, but existing RFCs specify that subjectAltName takes
precedence, and if present the CN is ignored.

Therefore, a certificate that matches both a legacy SIP domain and
a new DANE SRV host name should have:

	Subject: /what=ever/CN=legacy.example

	subjectAltName:  DNS:legacy.example, DNS:sip-srv.example.com

That is the subjectAltName should always include any legacy CN intended
for clients that don't understand subjectAltName.

> SIP connection reuse is the art form of re-using a TLS connection
> between two SIP servers for more than one destination - in the case
> of SIP hosting with multiple domains.
> The current RFC is based on exchanging server and client certificates
> with a list of domains in the SubjAltName field.

Is there any expectation that *outbound* SIP connections are only made
by the hosts that receive incoming SIP connections?  This is far from
true for SMTP for example.

If with SIP (as with SMTP), this cannot reasonably be assumed to
be the set of inbound SRV hosts, you can't expect to find the client
TLSA RRs at:

	_<srvport>_tcp.<srvhost>.

You may need a new mechanism to publish the expected client
certificate associations.

-- 
	Viktor.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 4 Jul 2013 20:46:38 +0200

> for clients that don't understand subjectAltName.
Ok, that was badly written. I need to specify more clearly what I want.
I think we always should match the SRV host name with the certificate
if DANE is used and TLSA records exists, never fall back to the old RFC. 

If there's a TLSA record, let's skip the SIP domain certificates RFC and 
follow the DANE SRV draft more closely.

> true for SMTP for example.
The word "outbound" is in SIP reserved for a specific standard NAT
traversal method for clients. The SIP connection reuse RFC is for exchange
of SIP messages between two SIP servers, not endpoints.
It leaves some parts unlear in regards to a server knowing that another
server is connecting to it and separating a server from a user agent 
- because we have no separation of "server" vs "phone", 
like in XMPP where two different ports are used.

> certificate associations.

The question here is if the client sends messages from
sip:[email-masked] - can I find the SRV hosts for example.net,
look them up and see if any IP matches the one I have a connection from?

If all these DNS lookups was protected with DNSsec, can I assume
that the client is authoritative for "example.net" and send messages 
to that domain reusing the same connection?

This way, no certificate is involved in that direction, from the original
server to the client in the connection. The connection is already using
TLS, but we haven't used TLS certificates to check the client side.

I hope you follow what I mean.
/O