Subject: [dane] DANE SRV draft and SIP

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 21 Apr 2013 12:27:47 +0200

Hi!

Looking at the DANE SRV draft with my SIP eyes I realize that there's a lot of work to be done to get this
to work with SIP. 

SIP has no StartTLS, we use NAPTR records to select transport. The NAPTR points to a SRV
name that resolves into a set of host names.

The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 - specificies matching a 
given SIP URI with a certificate. The matching is done on service domain either with 
a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but not the host name.

I personally agree with the policy in the DANE SRV draft that we should match on the
SRV hostname used to get A/AAAA records when using DNSsec. For this to work,
the path from the SIP URI over NAPTR to SRV and hostnames needs to be fully
signed in and verified in the DNS. This is going to require an update to 5922.

The final question is how to handle this without SNI. The certificates for both
DANE verification and RFC 5922 plus "old-style" verification with the sip
domain in the CN seems like a complicated mess to manage.

Food for thought on a sunny Sunday.

The SRV draft is not clear on how to use Subject AltNames of various types,
and doesn't mention NAPTR. I am not personally aware of other protocols using
this setup, so maybe this requires a very SIP specfic draft, following the wake of the
smtp work.

/O

---

From: Warren Kumari <[email-masked]>
Date: Mon, 22 Apr 2013 17:33:18 -0400

> Looking at the DANE SRV draft with my SIP eyes I realize that there's a lot of work to be done to get this

Thank you.

> this setup, so maybe this requires a very SIP specfic draft,

So, when we were writing the DANE protocol document we decided to describe the general case and that there would likely be a whole set of "How to do DANE with $foo protocol" documents.

Your mail backs up that decision, and also sounds like you are volunteering to start the "How to do DANE with SIP" draft...

> following the wake of the
> smtp work.

or, better yet, in parallel with the smtp work? :-)

W

> 
> /O
> 
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
> 

--
"Go on, prove me wrong. Destroy the fabric of the universe. See if I care."  -- Terry Prachett

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 Apr 2013 23:06:19 +0000

On Mon, Apr 22, 2013 at 05:33:18PM -0400, Warren Kumari wrote:

> So, when we were writing the DANE protocol document we decided
> to describe the general case and that there would likely be a whole
> set of "How to do DANE with $foo protocol" documents.
> 
> Your mail backs up that decision, and also sounds like you are
> volunteering to start the "How to do DANE with SIP" draft...
> 

Amen.  I think I am now able to articulate the root-cause of most of the
difficulty I faced reconciling RFC 6698 with SMTP, and it boils down to this:

    - RFC 6698 assumes that TLS-capable application protocols that
      will be adopting DANE TLSA, are currently using TLS in the context of
      a largely usable (if creaking at the seams) public CA PKI.

	* While I would posit that this assumption is not entirely
	  justified for browsers,  in that the public PKI only "works" because
	  users are willing to "click OK" when often it doesn't, the real
	  source of friction is that this is far from true for other protocols
	  such as SMTP.

    - Though RFCs 6394 and 6698 correctly aim to be application protocol
      neutral, the operating model of 6698 s largely based on a
      brower-centric mental model of TLS.

	* RFC 6698 does not address the dichotomy between applications that
	  know they must do TLS, and are merely trying to do a better job of
	  certificate verification (e.g. https) versus applications in which
	  TLS support by the peer needs to be "advertised" by the server and
	  "discovered" by the client (e.g. SMTP), since the destination
	  address with SMTP does not encode channel security properties (as
	  it does with http vs. https URIs).

In SMTP before DNSSEC and DANE the TLS servers to be validated are obtained
from MX lookups via an insecure DNS, it is not possible to adopt the legacy
public PKI in this context, since checking the SMTP server's certificate for
the recipient domain fails when mail is hosted by a third party provider,
while checking for the MX host name is futile the MITM attacker controls DNS.

More fundamentaly, with a store and forward protocol, there is no interactive
user clicking "OK".  So all the warts of the public PKI that are hidden under
that rug, become visible failures with SMTP.

Therefore MTAs largely ignored the public PKI, and do not come preconfigured
with a panoply of CA certificates they can't use except for the occasional
bilaterally negotiated secure-channel with a business partner (an ad-hoc SMTP
VPN over STARTTLS).

Therefore, when I look at the mandatory to implement certificate usages "0"
and "1", I see a standard that is out of touch with my reality.  So I whine
and moan about about lack of the TA cert with "IN TLSA 2 x 1" or being
entirely unable to support "IN TLSA 0 x 1", low level issues with CNAMEs, ...

What I think I should do in the operational guidance draft, is to
identify the underlying causes, so that derived specifications and
application developers will be better able to understand what issues
they need to think about when specifying or implementing DANE for
their application or protocol.

If this ultimately leads to a 6698bis, perhaps there will be an opportunity
not only to clarify some not blatantly obvious formal consequences of the
specification, but perhaps to more closely examine some of the assumptions.

Perhaps, a revised standard might make certificate usages "0" and
"1" optional in derived application-specific standards, and thus
Tony Finch may be able to write an SMTP draft that is actually
usable by MTA developers (by mandating that SMTP MUST only use "2"
or "3" and provide the TA certificate with "2", which leaves mostly
some niggling over CNAMEs and perhaps other minutia to resolve).

Perhaps I tipped my hand too early, and should have waited until the draft is
written.  I don't want to start a flame-war and will happily hide under a rock
writing the draft until the storm blows over if the above is too radical an
agenda for this forum.

If on the other hand some of the above makes some sense to you, please keep
it in the back of your mind, as there may yet be room to produce an update
to 6698 that:

    - Discusses applications that can't (whether in theory or in practice)
      make use of the legacy PKI.

    - Provides guidance for protocols where TLS is discovered rather than
      pre-ordained (the SRV draft attempts to do this, but the issue is
      more general).  When TLS support is not known in advance the presence
      of TLSA RRs (even if all are unusable) acts as secure indication of
      TLS support, so protocols where this applies SHOULD use TLS and not
      plaintext in this case (which is not limited to SRV RRs).

    - Considers the key-management implications of SNI, and perhaps gives
      some ground or at least definitively rules me in the minority on the
      CNAME issue.

    - Anything else I may have missed, perhaps more insight from a SIP
      perspective...

-- 
	Viktor.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 23 Apr 2013 07:31:51 +0200

> Your mail backs up that decision, and also sounds like you are volunteering to start the "How to do DANE with SIP" draft...
Well, I started with trying to map the area and gather data. The RAI area wants this work to be done in the
sipcore working group and there is a discussion going on (based on the same e-mail) in the RAI dispatch wg.

> or, better yet, in parallel with the smtp work? :-)
Right. :-)
There is also work going on with XMPP that is similar to SIP, so there are many drafts to digest.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 23 Apr 2013 07:50:38 +0200

>    - Anything else I may have missed, perhaps more insight from a SIP

Viktor,
THanks. This is a lot to digest and I'm sure I'll come back with details.

A quick overview of SIP and TLS:

- the phone connects to the "home proxy" or an "outbound edge proxy"
  using TLS. The display can here act as a web browser.
- The phone place a call to another domain. The proxy now sets
  up connections that work like SMTP - hop by hop.
  NAPTR records indicate if TLS can be/should be used to reach
  another domain.
- There is a SIPS uri that forces TLS in all hops. It's mostly considered
  deprecated.
- There are no error messages to indicate validation failures back
  to the phone if a hop fails.
- To sign caller identities and other message headers, a special
   standard called SIP identity (not S/MIME) is used. The certificate
  for this is published using HTTPS, binding a possible self-signed
  private CA to a public PKI used for the HTTP server.

This is all for signaling. Media encryption keys is handled by DTLS.

In SIP the binding between the SIP uri (like sip:[email-masked]) and
the server (sollentuna.example.org) is done by a cert that contain
the subj alt name uri sip:edvina.net - not the server host name.

As the SRV draft says, this is not very scalable for hosting providers
and can change. The problem then is if a server doesn't support
TNI the certificates for both DNSsec/DANE capable clients and
legacy clients will be hard to set up and manage, which is not 
good in order to stimulate deployment.

Now back to re-reading RFCs and drafts :-)

/O

---

From: Richard Barnes <[email-masked]>
Date: Tue, 23 Apr 2013 15:45:57 -0400

Dropping in late here ...

Olle, I think you're misunderstanding the role of DANE here.  Regardless of
the SRV strategy, there's no need to update RFC 5922.  DANE just binds a
cert to a name; it doesn't say what needs to go in that cert.  So just like
RFC 6125 didn't need to change for general TLS services, RFC 5922 doesn't
need to change for SIP.  DANE might make some of the things in RFC 5922
redundant (since you've got two ways to say what domain you're bound to),
but that's not something that urgently needs to be changed.

--Richard

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 23 Apr 2013 22:34:02 +0200

23 apr 2013 kl. 21:45 skrev Richard Barnes <[email-masked]>:

> Olle, I think you're misunderstanding the role of DANE here.  Regardless of the SRV strategy, there's no need to update RFC 5922.  DANE just binds a cert to a name; it doesn't say what needs to go in that cert.  So just like RFC 6125 didn't need to change for general TLS services, RFC 5922 doesn't need to change for SIP.  DANE might make some of the things in RFC 5922 redundant (since you've got two ways to say what domain you're bound to), but that's not something that urgently needs to be changed.
Richard,
Please check http://tools.ietf.org/html/draft-ietf-dane-srv-02
Section 7.3 

"So this specification says that clients check that the server's
   certificate matches the server host name, to ensure that the
   certificate was issued by the CA to the server that the client is
   connecting to. 
"
Also check Appendix B which is very clear on the same topic.

This is quite different from RFC 5922, which also updates RFC 3261 and contains quite a few MUSTs.

I might have missed something here, but to me it sounds like a big change unless we come up
with our own way of doing DANE, which would be different from the proposals for SMTP
and XMPP (if I have understood all documents right).

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. 

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?

/O

---

From: James Cloos <[email-masked]>
Date: Tue, 23 Apr 2013 18:15:11 -0400

RFC 5922’s demand for a sip: URL SubjAltName for each domain which a
given server supports is unfortunate.

I can understand the motivation, at least for a non-dnssec world, but
it doesn't scale very well at all.

My MX only needs a single DNS SubAltName (or CN) for its hostname to
handle every incoming mail zone for which it is advertized as an MX.

My outgoing mail server also needs such a simple cert for itself.

Plus, a single wildcard cert can support both.  Which simplifies
things enormously.

To accept incoming sip INVITEs for each valid email address would
require more than a dozen URI SubjAltNames.  And, as you wrote, who
would sign it for the benefit of non-dane remotes?  I doubt even
the free signers support multiple disparate names, and I have no idea
whether they’ll leave URI SANs in when signing the request.

All of sip/tls/tcp, sip/d?tls/sctp, sip/dtls/udp and sip/websocket would
work better were everything to support the ideas of authenticating the
node and trusting naptr/srv/tlsa lookups (by way of dnssec).

That said, if the 5922 semantics are to be followed and a node expects a
remote’s cert to contain URI SAN sip:example.com and the naptr+srv pointed
to tcp port 5061 on host flubber.example.net, then should it look for a
tlsa RR at _5061._tcp_.example.com or at _5061._tcp.flubber.example.net?

Perhaps it should try both?

Do any sip proxies or other nodes support SNI?  That would have a
significant affect on what a node could provide.

It would help to know what other sip implementors think of the vaious
options.

If SIP needs its own RFC for how to implement DANE, that is OK.  The
MX/SRV draft is a good basis for most services, but where there are
legacy requirements which contraindicate its presumptions and/or
conclusions, protocol-specific drafts are welcome.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 Apr 2013 22:38:38 +0000

On Tue, Apr 23, 2013 at 10:34:02PM +0200, Olle E. Johansson wrote:

> 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.

> 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.