Subject: [sipcore] Proceeding with dane-sip

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jun 2014 15:03:21 -0400

SIPCORE people,

Before the London meeting Olle Johansson submitted 
draft-johansson-dispatch-dane-sip to dispatch. It was dispatched to 
sipcore, and we had a sipcore session in London discussing it.

That session didn't go smoothly. There was a great deal of disagreement 
over what, if anything, needs to be done to enable the use of DANE with 
sip. A poll of the room indicated profound confusion.

The decision at the time was that we should focus on specific 
examples/use cases, and asked Olle to post some to the list. Olle 
subsequently posted on the list about that:

> I don't think the confusion was about use cases at all or whether we need DANE or not - it was about whether the DANE group documents was enough,
> if this is just a bump in the TLS stack or if we actually need to do something in SIPcore. Some people claimed
> we need to do zero, nothing, nada. Some people (including me) claims we do need to document this,
> especially since the SIP Domain certificate RFC is an update to RFC 3261 and DANE usage changes
> the certificate contents.
>
> The DANE group is very clear that we do need to document our usage. Wes Hardaker pointed that out
> several times during the discussion. It's documented in the DANE SRV drafts too.

I still think use cases can help here. Suppose all sip implementations 
were capable of both 5922 and DANE. Then deployments would need to 
decide when it would be advantageous to use DANE rather than, or in 
addition to, DANE. What use cases can do is illustrate when DANE is 
advantageous.

If we can agree on cases were we want to use DANE, then we will have 
better motivation to figure out what we must do to make that possible.

This doesn't have to be just Olle - anybody can speak up.

(We have the opportunity to discuss this further in Toronto, but unless 
we have some action on the list first then we probably won't.)

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 11 Jun 2014 20:16:38 +0100

On 11 Jun 2014, at 20:03, Paul Kyzivat <[email-masked]> wrote:

> SIPCORE people,
> 
> Before the London meeting Olle Johansson submitted draft-johansson-dispatch-dane-sip to dispatch. It was dispatched to sipcore, and we had a sipcore session in London discussing it.
> 
> That session didn't go smoothly. There was a great deal of disagreement over what, if anything, needs to be done to enable the use of DANE with sip. A poll of the room indicated profound confusion.
> 
> The decision at the time was that we should focus on specific examples/use cases, and asked Olle to post some to the list. Olle subsequently posted on the list about that:
> 
> I still think use cases can help here. Suppose all sip implementations were capable of both 5922 and DANE. Then deployments would need to decide when it would be advantageous to use DANE rather than, or in addition to, DANE. What use cases can do is illustrate when DANE is advantageous.
> 
> If we can agree on cases were we want to use DANE, then we will have better motivation to figure out what we must do to make that possible.
> 
> (We have the opportunity to discuss this further in Toronto, but unless we have some action on the list first then we probably won't.)
> 

RFC 5922 usage implies use of a CA that has a certificate that needs to be installed on every single phone. It also use certificates that are not available on the market - with SIP uri:s in the SAN extension fields.

DANE can be used with a CA in the same mode, but also with no CA, which significantly makes it easier to use. The cost of managing a CA and getting the CA chain out on every device is rather high, because it's a complex operation if you want to have a trustworthy installation.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jun 2014 15:42:28 -0400

> DANE can be used with a CA in the same mode, but also with no CA, which significantly makes it easier to use. The cost of managing a CA and getting the CA chain out on every device is rather high,…

OK. Good start!

Does anybody disagree that these are important reasons?

Isn't it also the case that having certificates follow the DNS 
delegation chain also makes it much easier to deploy - avoiding the need 
to share certs among multiple servers?

	Thanks,
	Paul

---

From: James Cloos <[email-masked]>
Date: Wed, 11 Jun 2014 19:23:41 -0400

>>>>> "PK" == Paul Kyzivat <[email-masked]> writes:

PK> Isn't it also the case that having certificates follow the DNS
PK> delegation chain also makes it much easier to deploy - avoiding the
PK> need to share certs among multiple servers?

Yes.

With the oob draft nearing publication, sipcore should include spki
configurations when discussing dane.  With that, the tls server only
sends the SPKI, which is to be verified out of band.

Dane's 3 1 1 tlsa records are a perfect way to verify them.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 12 Jun 2014 11:11:47 +0100

On 11 Jun 2014, at 20:42, Paul Kyzivat <[email-masked]> wrote:

> Isn't it also the case that having certificates follow the DNS delegation chain also makes it much easier to deploy - avoiding the need to share certs among multiple servers?

Thanks for the reminder:

Another benefit is that the server certificate only needs the server host name. With DANE you don't change the server cert when adding a new domain.

With traditional certs - using DANE or not - you need a new certificate for any change in hosted domains.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Jun 2014 10:58:30 -0400

Richard, Robert, Cullen, John,

I believe you were the people most concerned with having use cases for DANE.

Do the cases brought up in this thread sufficient to satisfy you. 
(Certainly these cases can be explained in more detail, but in general 
to you consider them valid?)

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 12 Jun 2014 10:22:34 -0500

On 06/11/2014 02:16 PM, Olle E. Johansson wrote:
> RFC 5922 usage implies use of a CA that has a certificate that needs
> to be installed on every single phone.

A bit of a correction here.  RFC5922 does not imply that the certificate
needs to be installed on "every single phone".  Instead, the expectation
is that the certificate is installed on a domain proxy (hence the
moniker of the draft, domain certificate).  There is no normative
language in rfc5922 that requires a client (i.e., a UA) to possess a
certificate.

> It also use certificates that are not available on the market - with
> SIP uri:s in the SAN extension fields.

True; however, at the time work on rfc5922 was done, an alternative
identity specific to SIP encoded in the subjectAltName was viewed as
being advantageous.

> DANE can be used with a CA in the same mode, but also with no CA,
> which significantly makes it easier to use. The cost of managing a CA
> and getting the CA chain out on every device is rather high, because
> it's a complex operation if you want to have a trustworthy
> installation.

I believe as we study whether or not the DANE model applies to SIP, we
should remove the need for UA certificates as a comparative factor.
RFC5922 does not require UAs to have a certificate.  Yes, domain
servers need to possess a certificate, but that is no different than
web servers possessing one, as is prevalent today.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 12 Jun 2014 17:26:11 +0200

2014-06-11 21:42 GMT+02:00 Paul Kyzivat <[email-masked]>:
>>
>> RFC 5922 usage implies use of a CA that has a certificate that needs to be
>> installed on every single phone. It also use certificates that are not
>> available on the market - with SIP uri:s in the SAN extension fields.
>>
>> DANE can be used with a CA in the same mode, but also with no CA, which
>> significantly makes it easier to use. The cost of managing a CA and getting
>> the CA chain out on every device is rather high, because it's a complex
>> operation if you want to have a trustworthy installation.
>
>
> OK. Good start!
>

I event consider that these are *the reasons* :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 12 Jun 2014 17:29:11 +0200

> With traditional certs - using DANE or not - you need a new certificate for any change in hosted domains.

Well, not exactly IMHO. If you run NAPTR/SRV records then the SIP UA
will try to contact "sip:myserver.com". After DNS NAPTR/SRV/A/AAAA
resolution that will point to any hostname. That's not a problem. The
certificate in those different servers must just contain
"myserver.com".

Well, all what I've said gets broken for in-dialog requests, you know.
But that's another topic.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 12 Jun 2014 16:35:19 +0100

> certificate in those different servers must just contain
Not according to the SIP Domain cert RFC, Iñaki. You need to check for 
the SIP domain in the SIP URI in the SAN fields.

/O

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Jun 2014 00:23:17 +0200

> the SIP domain in the SIP URI in the SAN fields.

Not at all:

http://tools.ietf.org/html/rfc5922#section-7.1

------------------
   2.  If and only if the subjectAltName does not appear in the
       certificate, the implementation MAY examine the CN field of the
       certificate.  If a valid DNS name is found there, the
       implementation MAY accept this value as a SIP domain identity.
------------------

;)

Of course, the problem is that if you have several servers for the
same domain (so NAPTR/SRV is in use) then in-dialog requests follow
the record-routing mechanism and thus each of those servers will set a
RR like:

  Record-Route: server01.example.com

and the SIP UA must send an in-dialog request to that URI (which
becomes a Route header for in-dialog requests). Then the UA may have
to open a new connection to the server (or reuse the previous one once
it realizes that it is the same IP:port:transport than the initial
request), and may need to, again, inspect the certificate provided by
the server.

In that case SubjectAltName is required since the server certificate
must include both example.com and server01.example.com.

So that is the real pain of SIP and TLS, and the reason for it to
NEVER success (and it will never success because it is really badly
designed, and even following the RFC line by line it becomes SO hard
to make it work).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Jun 2014 09:39:20 +0100

> http://tools.ietf.org/html/rfc5922#section-7.1
Yes, but you still map against the domain of the SIP URI, not the
host name that is the result of SRV lookups.

> must include both example.com and server01.example.com.
Record route adds a requirement for a SAN with the hostname, yes.
That's why record-routing with IP addresses is not recommended for TLS.

This also reminds me that we need to mention record-routes in our
draft, so thank you for that comment.

> designed, and even following the RFC line by line it becomes SO hard

Well, it certainly works for Microsoft lync. I don't see them using the
SIP domain certs with URI's, but both Lync and Exchange pushed
the CAs to start selling certificates with SAN support. Which means
that SAN certificates is now commercially available, certificates that
can be used in DANE processing if one wants to use a CA cert
and not anchor the cert in DNS/DNSsec alone.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Jun 2014 11:04:25 +0200

> host name that is the result of SRV lookups.

That is exactly what I said.

- Alice must register to atlanta.com.

- DNS NAPTR/SRV procedures select host01.atlanta.com DNS A record.

- Alice establishes TLS connection with host01.atlanta.com.

- The server MUST provide a certificate with SubjectAltName, DNS, or
CN with value "atlanta.com".

No problem, really.

> draft, so thank you for that comment.

In OverSIP proxy I added this configuration settings for fixing that problem:

---------------------
record_route_hostname_tls_ipv4

When enabled, OverSIP writes the given domain/hostname in the
Record-Route/Path headers when proxing a SIP request via TLS or WSS
transport over IPv4 (instead of writing the listening IPv4 address).
This is convenient when a peer open a new TLS/WSS connection to
OverSIP for sending an in-dialog request so the peer can check whether
the host part of the top Route header matches a domain in the
certificate OverSIP provides to the peer during the TLS negotiation.
This requirement is documented in RFC 5922 (“Domain Certificates in
SIP”) section 7.5.
---------------------

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Jun 2014 10:20:56 +0100

> CN with value "atlanta.com".
Then someone performs a hostile takeover of stockholm.com and all
the certificates need to change when they migrate the domain to the unified 
communication platform of atlanta.com. With DANE we match the hostname
in the SRV with the cert, so as long as you add domains and sign
it with DNSsec, you don't have to reissue certificates.
> In OverSIP proxy I added this configuration settings for fixing that problem:

Nice!

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Jun 2014 11:22:57 +0200

> it with DNSsec, you don't have to reissue certificates.

May you please repeat my example "flow" above but now with DANE?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Jun 2014 10:38:50 +0100

> May you please repeat my example "flow" above but now with DANE?

Alice calls to aveiro.com

Alice's UA use DNS, validated with DNSsec and ends up with a hostname froggy.edvina.net
The whole query is verified as a secure response.

froggy.edvina.net has a certificate with CN being froggy.edvina.net

aveiro.com makes a hostile takeover of bilbao.com

Bilbao.com is merged into the same unified realtime supercommunication platform as aveiro.com

Bob calls bilbao.com and ends up with hostname froggy.edvina.net 
The whole DNS query is verified using DNSsec.

froggy.edvina.net has a certificate with CN being froggy.edvina.net

Now, there are at least two options for validating the certificate froggy.edvina.net. One is that
edvina.net says that "froggy.edvina.net" only use the Fluffy CA and nothing else.
Now if Alice and Bob gets a certifcate from the Castillo CA, something is wrong and
their phones doees not connect.

The other option is that there's a fingerprint of the certificate in a TLSA record.
Now, they validate the certificate given by the server with the fingerprint
that they got in a secure way using DNS/DNSsec. No PKI structure other than
the DNSsec is used.

At some point we may have bare keys used and no PKIX/X.509 certs at all.

I may have missed something here, but keep asking questions!

Cheers,
/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Jun 2014 12:54:48 +0200

> I may have missed something here, but keep asking questions!

This is great. But it behaves different than the current SIP-cert
procedures (as the device checks the resulting hostname after DNS
procedures rather than the initial domain before NAPTR/SRV).

Well, IMHO it is MUCH better in this way, but it is not consistent
with how SIP-cert works.

Both SIP-cert and DANE perform two steps:

1) Get a certificate.

2) Decide which domain must be used to check the received certificate.

3) Check the certificate.

Step 1 is the same for both.
Step 2 is different (SIP-cert uses the domain before DNS procedures
while DANE uses the domain after DNS procedures).
Step 3 is obviously different (right).

I wonder about step 2. I would be happy if another spec changes that
also for SIP-cert procedures.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Jun 2014 12:06:15 +0100

> Well, IMHO it is MUCH better in this way, but it is not consistent
Which we point out in the draft...
> 2) Decide which domain must be used to check the received certificate.
s/domain/name/
> also for SIP-cert procedures.

This is the spec... :-)

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Jun 2014 13:08:13 +0200

>> also for SIP-cert procedures.

But just for DANE and not for "normal" SIP-cert, right? or do I miss something?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Jun 2014 12:14:03 +0100

> But just for DANE and not for "normal" SIP-cert, right? or do I miss something?

No, but the world needs to move to DANE and forget the rest...

SIP domain certs make sense when you can't trust the DNS imho.

(At least in my dreams) :-)

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Jun 2014 13:18:45 +0200

> No, but the world needs to move to DANE and forget the rest...

Please add "This document deprecates and looks down RFC 5922".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Jun 2014 12:20:44 +0100

> Please add "This document deprecates and looks down RFC 5922".

Then we're updating RFC 3261 again and I will get the wrath of Cullen over me ;-)

There's a world without DNSsec out there and will be for a long time, unfortunately.

/O

---

From: James Cloos <[email-masked]>
Date: Fri, 13 Jun 2014 10:42:19 -0400

>>>>> "IBC" == Iñaki Baz Castillo <[email-masked]> writes:

IBC> This is great. But it behaves different than the current SIP-cert
IBC> procedures (as the device checks the resulting hostname after DNS
IBC> procedures rather than the initial domain before NAPTR/SRV).

The current draft for dane for srv permits either name to be in the cert
sent by the server, for backwards compatibility with the non-dane flow.

-JimC

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 13 Jun 2014 16:52:08 +0200

> sent by the server, for backwards compatibility with the non-dane flow.

Cool then :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 13 Jun 2014 10:52:50 -0500

> request), and may need to, again, inspect the certificate provided by

Exactly so.  We grappled with all these issues back in 2006 or so when
we were doing the work on the precursor to rfc5922.  See [1].

[1] http://www.ietf.org/proceedings/67/slides/sip-6.pdf

Cheers,

- vijay

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 13 Jun 2014 17:31:41 +0000

I did not complain about the dane-sip proposal because I think DANE is a
bad fit for SIP - far from it. Nor do I insist that there is nothing
whatsoever that we need to document to use DANE with SIP. However, the
TLSA usage defined in ietf-dane-srv targets transport-layer security, as
the name might suggest. I think that if the TLSA mechanism requires every
application to do TLSA their own way, then we're going to end up with
different credential needs for different applications and thus a very
confusing deployment environment.

Broadly, I consider the potential DANE environment to be a greenfield
where we can hopefully create more uniformity in the way applications deal
with multi-tenant situations and what have you. I therefore went back to
the authors of ietf-dane-srv and asked them not to place a requirement for
every application to define its own relationship to TLSA. The latest
version of ietf-dane-srv no longer does. So, hopefully, the argument for a
dane-sip draft is no longer that we are required to have one by
ietf-dane-srv.

There's also been some discussion in this thread of effectively
deprecating the use of traditional certificates in SIP in favor of DANE.
This would be premature, I think. We should however be working towards
phasing in DANE in those environments where DNSSEC (and client support)
are available, and in this work group doing any protocol work necessary as
groundwork for that.

Jon Peterson
Neustar, Inc.

On 6/12/14, 7:58 AM, "Paul Kyzivat" <[email-masked]> wrote:

>>>>> I still think use cases can help here. Suppose all sip
>>>>>implementations were capable of both 5922 and DANE. Then deployments
>>>>>would need to decide when it would be advantageous to use DANE rather
>>>>>than, or in addition to, DANE. What use cases can do is illustrate
>>>>>when DANE is advantageous.
>>>>>
>>>>> (We have the opportunity to discuss this further in Toronto, but
>>>>>unless we have some action on the list first then we probably won't.)
>>>>>
>>>>
>>>>to be installed on every single phone. It also use certificates that
>>>>are not available on the market - with SIP uri:s in the SAN extension
>>>>fields.
>>>>
>>>delegation chain also makes it much easier to deploy - avoiding the
>>>need to share certs among multiple servers?
>>
>> Thanks for the reminder:
>>
>> Another benefit is that the server certificate only needs the server
>>host name. With DANE you don't change the server cert when adding a new
>>domain.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jun 2014 14:45:04 -0400

On 6/13/14 1:31 PM, Peterson, Jon wrote:
> version of ietf-dane-srv no longer does.

I see that there have been a number of changes to achieve this. Thanks 
for pushing that!

> So, hopefully, the argument for a

ietf-dane-srv now has a new section "Guidance for Application Protocols" 
that gives a list of things that an application specific document could 
cover. It doesn't require these, but I take it that if the shoe fits 
then wear it. We should certainly have the discussion of what we do need 
to say.

> This would be premature, I think.

+1

Perhaps the traditional use will be supplanted by DANE because of the 
benefits that ensue. We don't need to get too far in front of that.

ISTM that a major issue is backward compatibility, and the chicken/egg 
problem: there is no motivation for clients to deploy the DANE logic 
until there are servers that can use it, and there is no reason for 
servers to use it until there are clients supporting it. IIUC most of 
the benefits accrue to servers, but only after it can be assumed that 
all clients support it. That makes for a hard migration.

> We should however be working towards

I'm not sure who you mean by "we". ISTM this is a deployment issue, not 
a standards issue.

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 13 Jun 2014 14:48:26 -0500

> Please add "This document deprecates and looks down RFC 5922".

Before we hastily throw out the baby with the bathwater, it seems to
me that the crux of the problem is as Iñaki described in an earlier
email; to wit:

    1) Get a certificate.

    2) Decide which domain must be used to check the received
    certificate.

When the work that lead to rfc5922 was done, the constraints were that
the identity encoded in the certificate (preferably in a subjectAltName,
or less preferably in CN) match the URI that the user uses to establish
the session.  Therefore, if someone establishes a session with me using
sips:[email-masked] then the certificate presented by my domain's
proxy best assert an identity of sip:example.com in the certificate.

Has this constraint, i.e., the identity encoded in a certificate can be
different than the one used to procure a host that is responsible for
that certificate, now been relaxed?

If the answer is affirmative, then by all means go ahead and throw both
the baby and the bathwater out.

But if --- as Paul noted --- that "there is no motivation for clients
to deploy the DANE logic until there are servers that can use it, and
there is no reason for servers to use it until there are clients
supporting it." then I am at a loss to see how moving to DANE will
foster faster support when the same chicken-and-egg problem haunted
rfc5922 as well?

Thanks,

- vijay

---

From: James Cloos <[email-masked]>
Date: Fri, 13 Jun 2014 19:36:07 -0400

>>>>> "VG" == Vijay K Gurbani <[email-masked]> writes:

VG>  Step 1 is the same for both.
VG>  Step 2 is different (SIP-cert uses the domain before DNS procedures
VG>  while DANE uses the domain after DNS procedures).
VG>  Step 3 is obviously different (right).

The current draft recommends that clients accept either the before or
the after in step 2.

The tlsa, of course, has to be configured to match the cert which the
server offers no matter what style of cert it is.

And a 3 1 x tlsa specifies that the client should ignore all of the
pkix aspects of the cert, and just verify the key.

That means that adding a 3 1 x tlsa to any existing setup will, if
everything is dnssec-signed, be enough for any dane-enabled client.

No changes to the server's setup are required beyond adding the tlsa
and signing the dns.

Over time, as more clients switch to dane, the servers can stop
providing backwards compatibility, but there is no rush to do so.

-JimC