Subject: [dispatch] Fwd: New Version Notification for draft-johansson-dispatch-dane-sip-00.txt

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 2 Jan 2014 11:16:00 +0100

Hi!
I have renamed my draft and resubmitted it again. Adding DNSsec/DANE support to SIP is not a bad idea in my point of view. 

If the view gets larger we might want to focus a bit more on security aspects of SIP in the RAI area. There are many issues to look at. Why isn't S/MIME deployed, how do we get more TLS - if that's what we want? Can we improve upon MD5 digest authentication? Do we want to fix SIP identity that many claim is broken? Is it possible to set up sessions with end2end security?

Happy New Year!

/O

Begin forwarded message:
> 
> A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt
> has been successfully submitted by Olle E. Johansson and posted to the
> IETF repository.
> 
> Name:		draft-johansson-dispatch-dane-sip
> Revision:	00
> Title:		TLS sessions in SIP using DNS-based Authentication of Named Entities (DANE) TLSA records
> Document date:	2014-01-02
> Group:		Individual Submission
> Pages:		9
> URL:            http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/
> Htmlized:       http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00
> 
> 
> Abstract:
>   Use of TLS in the SIP protocol is defined in multiple documents,
>   starting with RFC 3261.  The actual verification that happens when
>   setting up a SIP TLS connection to a SIP server based on a SIP URI is
>   described in detail in RFC 5922 - SIP Domain Certificates.
> 
>   In this document, an alternative method is defined, using DNS-Based
>   Authentication of Named Entities (DANE).  By looking up TLSA DNS
>   records and using DNSsec protection of the required queries,
>   including lookups for NAPTR and SRV records, a SIP Client can verify
>   the identity of the TLS SIP server in a different way, matching on
>   the SRV host name in the X.509 PKIX certificate instead of the SIP
>   domain.  This provides more scalability in hosting solutions and make
>   it easier to use standard CA certificates (if needed at all).
> 
>   This document updates RFC 5922.
> 
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 2 Jan 2014 13:34:40 -0500

Hi Olle,

       >Can we improve upon MD5 digest authentication?

Take a look at the following HTTPAuth WG document:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/

I have been working on this for some time, with SIP in mind. This started
as an attempt to update RFC2617, and now it is a different document that
will obsolete RFC2617.
The document updates 3 aspects of RFC2617:
1. Algorithms agility: use of SHA2
2. Internationalization
3. Username hashing

I am planning on writing a document to update the digest algorithms for SIP.

Regards,
 Rifaat

On Thu, Jan 2, 2014 at 5:16 AM, Olle E. Johansson <[email-masked]> wrote:

> Hi!
> I have renamed my draft and resubmitted it again. Adding DNSsec/DANE
> support to SIP is not a bad idea in my point of view.
>
> If the view gets larger we might want to focus a bit more on security
> aspects of SIP in the RAI area. There are many issues to look at. Why isn't
> S/MIME deployed, how do we get more TLS - if that's what we want? Can we
> improve upon MD5 digest authentication? Do we want to fix SIP identity that
> many claim is broken? Is it possible to set up sessions with end2end
> security?
>
> Happy New Year!
>
> /O
>
>
>
> Begin forwarded message:
> >
> > URL:
> http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/
> > Htmlized:
> http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00
> >
> >
> > Abstract:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 2 Jan 2014 20:01:41 +0100

2 jan 2014 kl. 19:34 skrev Rifaat Shekh-Yusef <[email-masked]>:

> I have been working on this for some time, with SIP in mind. This started as an attempt to update RFC2617, and now it is a different document that will obsolete RFC2617.
That's great. I will take a look at this.  Thank you!

Since this work is on the way - maybe we have enough to start a SIP security wg?

/O
> >   This document updates RFC 5922.

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 04 Jan 2014 11:23:45 -0500

> I have renamed my draft and resubmitted it again. Adding DNSsec/DANE support to SIP is not a bad idea in my point of view.

It seems like a really good idea to me.

I have a question about backward compatibility, as discussed in section 9:

You say that that servers can use certificates that support both DANE 
and 5922 style validation. And IIUC that will be necessary in order to 
handle clients that don't support DANE validation.

But the Intro explains that one of the important reasons for introducing 
DANE authentication is because of various logistic problems providing 
certificates for 5922 style validation. Providing backward compatibility 
negates that advantage.

Have you considered the migration path? Presumably those currently using 
5922 already have a certificate that works for that. Will they be able 
to get a cert that continues that and also supports DANE validation?

What about those coming to this without any history of 5922 support?

ISTM that there is need to get ubiquitous client support for this 
deployed. For that we have the usual chicken/egg scenario.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 7 Jan 2014 12:12:48 +0100

On 04 Jan 2014, at 17:23, Paul Kyzivat <[email-masked]> wrote:

> You say that that servers can use certificates that support both DANE and 5922 style validation. And IIUC that will be necessary in order to handle clients that don't support DANE validation.
Yes.
> 
> But the Intro explains that one of the important reasons for introducing DANE authentication is because of various logistic problems providing certificates for 5922 style validation. Providing backward compatibility negates that advantage.
Well, I might need to clarify that. The current way to host multiple SIP domains is either to have one certificate with a long list of subject Alt Names or multiple IPs each with it's own certificate with the domain in SubjAltName. Both are very hard to maintain. Either buy a new cert for a new domain - and a new IP. Or reissue the existing cert to get an additional name.
SNI could also be used, but is not yet wildely supported out there. It just means one cert per domain. I don't remember if we've specified how SNI applies to RFC 5922 - what are we specifying in the SNI lookup?

> 
> Have you considered the migration path? Presumably those currently using 5922 already have a certificate that works for that. Will they be able to get a cert that continues that and also supports DANE validation?
Yes, they just need to get the host name into the CN. 5922-compliant clients ignore the CN when there are SubjectAltNames and clients supporting this draft will ignore the SubjectAltNames.

> What about those coming to this without any history of 5922 support?
Those will look for something in some field that's very unspecified. Hard to support. I guess that they will look for something to match in the CN. What that is varies - which is why we need standardization :-)

Wild guess is that they look for the domain in the CN. They will not accept certificates according to this RFC.
Again SNI could help.

> 
> ISTM that there is need to get ubiquitous client support for this deployed. For that we have the usual chicken/egg scenario.
Always that chicken and the %&€&€& egg. ;-)

Thank you for your feedback, Paul!

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jan 2014 17:12:49 +0100

> SNI could also be used, but is not yet wildely supported out there. It
just means one cert per domain. I don't remember if we've specified how SNI
applies to RFC 5922 - what are we specifying in the SNI lookup?

SNI is implemented in MOST of the browsers and HTTPS servers (tested). How
is possible that it cannot be a feasible solution for SIP? As you said,
multiple SubjectAltNames in the same certificate is really hard to maintain
and it is proven to be an unfeasible solution for HTTP world (regardless
most of the browsers do support it).

About applying SNI and RFC 5922, SNI takes place before the certificate
validation rules. I see no issues at all with it.

Note: I am 100% pro DANE and any kind of validation that does not depend on
buying expensive certificates. Having to pay to some "Internet authority"
in order to get sechrityyand encryption is just terrible.

Regards.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jan 2014 17:17:18 +0100

> Those will look for something in some field that's very unspecified. Hard
to support. I guess that they will look for something to match in the CN.

This is not true. SNI does not mean "ignoring SubjectAltNames". SNI just
means that the client indicates the desired hostname during the TLS
handshake, the server offers a proper certificate for such a hostname, and
the client then validates the server certificate following the protocol
rules (in case of SIP it means rules in RFC 5922).

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jan 2014 12:17:27 -0500

Olle,

Thanks for clarification.

I think it would be helpful if you would add a section on deployment 
hints and issues. Then you could talk about various cases:

- updating a server that already supports TLS via 5922
- updating a client that already supports TLS via 5922
- recommendations for a server newly supporting TLS
- recommendations for a client newly supporting TLS
- ...

Another question that came to me is what to do about TLS client 
authentication?

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 7 Jan 2014 20:23:13 +0100

On 07 Jan 2014, at 18:17, Paul Kyzivat <[email-masked]> wrote:

> I think it would be helpful if you would add a section on deployment hints and issues. Then you could talk about various cases:
> 
THanks, I'll look into that.
We just need to get this document dispatched :-)
> 
> Another question that came to me is what to do about TLS client authentication?

I started thinking about that too. Connection reuse comes to mind. Now that we have
the s/mime dane draft we might be able to steal some ideas from that. I would like to
make that a separate document. 

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 7 Jan 2014 20:25:54 +0100

On 07 Jan 2014, at 17:17, Iñaki Baz Castillo <[email-masked]> wrote:

> 
> > Those will look for something in some field that's very unspecified. Hard to support. I guess that they will look for something to match in the CN.
> 
> This is not true. SNI does not mean "ignoring SubjectAltNames". SNI just means that the client indicates the desired hostname during the TLS handshake, the server offers a proper certificate for such a hostname, and the client then validates the server certificate following the protocol rules (in case of SIP it means rules in RFC 5922).
> 
Right - where is it documented what a SIP client should provide in a SNI - a domain name, a SIP uri (which matches the SAN) or the host name - which we claim should not be used?

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jan 2014 22:31:10 +0100

2014/1/7 Olle E. Johansson <[email-masked]>:
> Right - where is it documented what a SIP client should provide in a SNI - a
> domain name, a SIP uri (which matches the SAN) or the host name - which we
> claim should not be used?

Honestly I've never understood the real difference between a domain
and a hostname. Of course, IMHO, the SIP client should provide in the
SNI the destination domain of the server it is attempting to connect
to.

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 8 Jan 2014 08:02:36 +0100

> SNI the destination domain of the server it is attempting to connect
Right, but...

Does anyone find this in any published document?

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 8 Jan 2014 10:06:20 +0100

> Does anyone find this in any published document?

Not AFAIK :)
But in this case SIP should follow well proven mechanisms and rules of HTTP(s).

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 8 Jan 2014 10:16:11 +0100

> But in this case SIP should follow well proven mechanisms and rules of HTTP(s).
If so, that is what we need to write. 

/O

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 8 Jan 2014 08:23:00 -0500

The following is a quote from RFC6066, Section 3:

   Currently, the only server names supported are DNS hostnames;
   however, this does not imply any dependency of TLS on DNS, and other
   name types may be added in the future (by an RFC that updates this
   document).

Should a new name_type be defined for this purpose, instead of overloading
the host_name type?

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Jan 2014 10:52:52 -0500

> If so, that is what we need to write.

+1

This seems to be yet another place where as time goes on we find aspects 
of SIP that are underspecified. The problem with underspecification is 
that implementers make assumptions, often without even realizing they 
are doing so. And if implementers don't all make the *same* assumptions 
then we get interop problems.

I'm strongly in favor of publishing clarifications for such things.

	Thanks,
	Paul

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 8 Jan 2014 18:49:13 +0000

> I am planning on writing a document to update the digest algorithms for SIP.

I suspect that sip core would be the best place to move forward a proposal like that. Personally, I would probably ague that moving to OAuth might be a better way to move forward. 

Cullen (with my individual contribute hat on)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Jan 2014 14:14:06 -0500

For both this and dane-sip, sipcore is certainly the obvious candidate.
Here in dispatch we have an opportunity to hear from anyone who thinks 
there are aspects to the work that might need to be considered 
elsewhere. If there is interest in the work, and no reason to deal with 
it elsewhere, then we can proceed with it in sipcore.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 8 Jan 2014 15:56:17 -0500

Thanks Cullen,

Updating the Digest mechanism should be simple and straightforward to allow
us to address the algorithms limitation without requiring major changes to
the deployed systems.

I agree that we need a better solution for SIP that would also allow us to
provide a better way of storing the passwords in the DB.
I have been thinking about other solutions, but did not have a chance to
look at OAuth yet; I will take a look.

Regards,
 Rifaat

On Wed, Jan 8, 2014 at 1:49 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> > I have been working on this for some time, with SIP in mind. This
> started as an attempt to update RFC2617, and now it is a different document
> that will obsolete RFC2617.
> I suspect that sip core would be the best place to move forward a proposal
> like that. Personally, I would probably ague that moving to OAuth might be
> a better way to move forward.
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 11 Jan 2014 15:59:20 +0100

On 08 Jan 2014, at 14:23, Rifaat Shekh-Yusef <[email-masked]> wrote:

> Should a new name_type be defined for this purpose, instead of overloading the host_name type?
> 
You are right, we are not allowed to ask for a domain. Now, what's fastest - getting TLS implementations
that support a new "domain" name_type or SIP-domain name type or DNSsec/Dane? :-)

If we need to add a new name_type - I guess that's work outside of RAI, maybe in the TLS wg. I don't see RFC 6066 defining an IANA registry for name_types even though it mentions that more name types can be added by RFCs.

Summary: In order for SIP domain certs to use SNI we do need to write an RFC that defines new name types when asking for a domain or a SIP URI that matches a SIP domain certificate. We might have to add a new IANA registry. Then we need code for this is the TLS libraries.

/O