Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jan 2010 14:00:19 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: Thursday, December 24, 2009 8:23 AM
> To: Dean Willis
> Cc: SIPCORE
> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: 
> technical issues
> 
> Dean Willis wrote:
> > The adoption rate of TLS peaked a couple of years back, and 
> has been 
> > steadily declining since? That should tell us something 
> important. Like, 
> > maybe nobody can figure out how to implement this stuff, 
> nobody actually 
> > uses it, or nobody runs SIP on a hostile network. Not sure 
> which is the 
> > case, here.
> 
> I don't think we can draw that general an argument that after
> peaking the support for TLS is slipping now.  We probably need
> more data about the early bakeoffs -- going back to the 11th
> bakeoff, which is the first one that took place after rfc3261
> was released.
> 
> In any case, I think the data tells us that over the 9 SIPits
> during which the data has been available, the support for TLS has
> hovered in [0.38 - 0.63] range, with an average of 0.47.
> 
> Essentially, less than 1/2 of the SIPit implementations that
> are brought to the event support TLS.  That itself is a
> telling statistic.

If the SIP UA and/or its proxy (nee, its SBC) aren't configured
to support TCP (because of worries regarding head-of-line blocking,
worries about TCP scalability, or whatever the reason), they
aren't going to be running TLS-over-TCP.

As to 'why', I would bet it's because TLS costs money, TCP
costs money, folks aren't running SIP over hostile networks,
and it's helpful to be able to run Wireshark (or whatever) to 
diagnose messages instead of hoping the SIP UA and proxy/SBC 
vendor have built adequate debugging/troubleshooting tools into 
their product.

-d

> Thanks,
> 
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Brian Hibbard <[email-masked]>
Date: Thu, 7 Jan 2010 17:18:08 -0600

That sounds good to me.  I'll add that to Sec. 8 unless there are  
objections.

On Dec 10, 2009, at 9:03 AM, Vijay K. Gurbani wrote:

> Cullen Jennings wrote:
>> On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote:
>>> From second bullet: What if all you've got is an IP address? Do we
>>> disallow IPAddress entries in SubjectAltName?
>> Good point - IPAddress are allowed in SubjectAltName AFAIC. I imagine
>> that many people did not test this case and may have problems with
>> it.
>
> We can add it as a test case in Section 8.  Something along the
> lines of:
>
>  12. TLS : Good peer certificate (CN of Subject empty, and
>      subjectAltName extension contains an iPAddress stored
>      in the octet string in network byte order form as
>      specified in [RFC791].)
>
> Thanks,
>
> - vijay
> --

---

From: Brian Hibbard <[email-masked]>
Date: Thu, 7 Jan 2010 17:18:12 -0600

If there are no objections, I can go ahead and insert this sans the  
normative MAY &  SHOULD, and add a reference to connection-reuse.   
Thanks!

-b
On Dec 10, 2009, at 8:52 AM, Vijay K. Gurbani wrote:

>>> Add a few lines about RFC 3263. Add a few lines about how the UA
>>> decides to create a new TLS session or use an existing one (but not
>>> "connection-reuse" draft level of reuse complexity). Any volunteers
>>> for writing this?
>> I can write that if you don't fine some else to do it. How about:
>> When a UA goes to send a message to example.com, the UA can see if it
>> already has a TLS connection to example.com and if it does, it MAY
>> send the message over this connection. A UA SHOULD have some scheme
>> for reusing connections as opening a new TLS connection for every
>> message results in awful performance. Implementers are encouraged to
>> read { add appropriate connection reuse refs here }.
>
> This is exactly what connect-reuse says, except of course, in
> much more detail about how the UA goes on to determine "if it
> already has a TLS connection to example.com".  I don't mind
> putting a capsule summary of the above form in sec-flows, but
> we should follow it up with a reference to connect-reuse.
>
> Thanks,
>
> - vijay
> --

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 8 Jan 2010 13:36:47 +0100

8 jan 2010 kl. 00.18 skrev Brian Hibbard:

> That sounds good to me.  I'll add that to Sec. 8 unless there are objections.
> 

During the tests we had at SIPit in New Hampshire we discovered that without an IP address in the certificate, most TLS scenarious with record-route/route headers pointing to IP addresses would fail. Either avoiding IP addresses in record-route/route or having IP address for the server in the cert are working solutions to this issue. 

IP in SAN certs is propably the fast way forward, but also gives a headache in solutions where you have multiple IP addresses in a "clustered" environment. It just feels wrong to me to have non-DNS data like IP address within the cert.

/O

---

From: Brian Hibbard <[email-masked]>
Date: Tue, 19 Jan 2010 13:16:30 -0600

On Dec 10, 2009, at 12:44 AM, Cullen Jennings wrote:

>> We should probably say something about CRLs. We need to get  
>> consensus on whether we want to recommend a method for retrieving  
>> CRLs.
>
> I predict we will never get consensus on which way one should check  
> CRLs thus I favor avoiding the CRL discussion but if others feel  
> differently I don't care one way or the other.

  We should probably say something, because we mention revocation in  
Section "Additional Test Scenarios".  I think it could be helpful to  
point out that there is such a thing as revocation status and that for  
PKI to work in the real world, certificate revocation status needs to  
be checked. How this is done has little impact on interoperability or  
implementation.

As for how to check revocation status, you're almost certainly right  
about whether we can get agreement.  We could refer them to section  
3.3 of RFC 5280 and leave it at that.

Unless someone feels strongly one way or another, I'll go ahead and  
add a blurb in section "Security Considerations" effecting the above,  
and close that issue.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 Jan 2010 11:00:45 -0700

On Jan 19, 2010, at 12:16 PM, Brian Hibbard wrote:

> 
> 
> As for how to check revocation status, you're almost certainly right about whether we can get agreement.  We could refer them to section 3.3 of RFC 5280 and leave it at that. 

I think it might be good to add an informative ref to OSCP and SCVP too.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 Jan 2010 11:01:07 -0700

> IP in SAN certs is propably the fast way forward, but also gives a headache in solutions where you have multiple IP addresses in a "clustered" environment. It just feels wrong to me to have non-DNS…

You are complete right that what goes in the record route needs to match what is in the cert. However, it is difficult to get cert signed by a well known CA that has an IP address in it so the obvious solution is don't put IP addresses in your record-route. If a particular proxy, say with a host name of say proxy22, in the example.com domain wants to record route, the easiest thing to deploy in my opinion is putting proxy22.example.com in the record route. Or if you are a domain with only one proxy, you could just put example.com in the record route. In the simple one proxy case, then all you need is a cert with example.com and in the more complex case you might want a cert with both example.com and proxy22.example.com. Hope that makes sense. The other problem with IPs in certs is when you want to renumber the network or move a machine, you might need new certs. There is likely some cases where IP in certs make sense but my opinion is that in most case, using DNS names is easier. 

Cullen <in my individual contributor role>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 Jan 2010 11:02:08 -0700

On Dec 23, 2009, at 8:18 PM, Dean Willis wrote:

> Vijay K. Gurbani wrote:
> 
>> Here is a table that contains the number of TLS implementations
>> since SIPit 16:
> 
> The adoption rate of TLS peaked a couple of years back, and has been steadily declining since? That should tell us something important. Like, maybe nobody can figure out how to implement this stuff, nobody actually uses it, or nobody runs SIP on a hostile network. Not sure which is the case, here.
> 
> --
> Dean

Dean, I don't buy this argument in the slightest. The prevalence of something at SIPit has close to nothing to do with the deployment prevalence or the number of products that support it. Most widely distributed mainstream SIP products are not taken to SIPit at all because the value proposition of SIPIit is mostly around helping fix new things where a vendor does not have significant experience to get them right without showing a pre release version of a product to your competitors. For example, the amount of TLS at SIPit exceeds the Video at SIPit, yet I hardly think you can come to the conclusions that therefore the video over IP market it really small.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 27 Jan 2010 12:23:01 -0600

Cullen Jennings wrote:
> You are complete right that what goes in the record route needs to
> match what is in the cert. 
[...]

Cullen: We had extensive discussion on this very topic when we
were hashing out domain-certs (remember: we were then referring
to "pinning" the request through a particular proxy.)

The normative behavior that we agreed  on is spelled out in
Section 7.5 of domain-certs (see the third paragraph.)  Fortunately,
the normative behavior in Section 7.5 matches your description.

Thanks,

- vijay

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 27 Jan 2010 19:37:22 +0100

> the normative behavior in Section 7.5 matches your description.

"  If a proxy adds a Record-Route when forwarding a request with the
   expectation that the route is to use secure connections, the proxy
   MUST insert into the Record-Route header a URI that corresponds to an
   identity for which the proxy has a certificate; if the proxy does not
   insert such a URI, then creation of a secure connection using the
   value from the Record-Route as the AUS will be impossible."

It doesn't really say that a DNS name is preferred. Maybe we should add that, and a note about benefits using a domain name in some environments.

/O

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 27 Jan 2010 12:51:59 -0600

Olle E. Johansson wrote:
> It doesn't really say that a DNS name is preferred. Maybe we should 
> add that, and a note about benefits using a domain name in some 
> environments.

Olle: The document recognizes what you presciently write above,
and says this in support:

    This document shows how the certificates are to be used for mutual
    authentication when both the client and server possess appropriate
    certificates, and normative behavior for matching the DNS query
    string with an identity stored in the X.509 certificate.
    Furthermore, a certificate can contain multiple identities for the
    subject in the subjectAltName extension (the "subject" of a
    certificate identifies the entity associated with the public key
    stored in the public key field.)  As such, this document specifies
    appropriate matching rules to encompass various subject identity
    representation options.

Thanks,

- vijay

---

From: Brian Hibbard <[email-masked]>
Date: Wed, 27 Jan 2010 16:16:47 -0600

I'll put references in.  Thanks!

-b

---

From: Brian Hibbard <[email-masked]>
Date: Wed, 27 Jan 2010 16:30:37 -0600

So, we should add an admonition in section 6 "Additional Test Scenarios" to avoid using IP addrs in SAN if possible, and reference sec 7.5 of domain-certs?  Is it beneficial to cite the specific issue of Record-Route?  I was thinking of paraphrasing Cullen's earlier comment.   Of course, if someone wants to take a stab at word-crafting this, I'm sure it would be well received.

-b

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 28 Jan 2010 09:25:13 -0600

Brian Hibbard wrote:
> So, we should add an admonition in section 6 "Additional Test
> Scenarios" to avoid using IP addrs in SAN if possible, and reference
> sec 7.5 of domain-certs?  

Brian: No matter how strongly we admonish against this, those that
want to use IP addresses will do so (sometimes in a closed lab
setting, people just use raw IP addresses instead of bothering
to set up a DNS infrastructure.)

I think the handling of raw IP addresses is well covered
by domain-certs and since you already have a reference
to that, IMHO it suffices.

> Is it beneficial to cite the specific issue
> of Record-Route?  I was thinking of paraphrasing Cullen's earlier
> comment.   Of course, if someone wants to take a stab at
> word-crafting this, I'm sure it would be well received.

AFAICT, this is worded in domain-certs already in S7.5, viz:

   If a proxy adds a Record-Route when forwarding a request with the
   expectation that the route is to use secure connections, the proxy
   MUST insert into the Record-Route header a URI that corresponds to an
   identity for which the proxy has a certificate; if the proxy does not
   insert such a URI, then creation of a secure connection using the
   value from the Record-Route as the AUS will be impossible.

Feel free to use the same wordings, or simply have a reference
to that section.

Thanks,

- vijay

---

From: Brian Hibbard <[email-masked]>
Date: Thu, 28 Jan 2010 14:43:37 -0600

Hi Vijay,

You're totally right that there will be folks that will still use IP addresses, regardless of how much lead shot they have to dig out of their feet.  My only thinking on it was that perhaps some of those folks might make better decisions if they understood *why*.  Of course, I'm second guessing them, and maybe I shouldn't.    

How about something like this:
"Note that if IP addresses are used in subjectAltName, there are important ramifications regarding the use of Record-Route headers that also need to be considered.  See section 7.5 of domain-certs[??]"

Thanks for the input,
-b

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 28 Jan 2010 14:46:03 -0600

Brian Hibbard wrote:
> How about something like this: "Note that if IP addresses are used in
> subjectAltName, there are important ramifications regarding the use
> of Record-Route headers that also need to be considered.  See section
> 7.5 of domain-certs[??]"

Brian: Works for me.  Thanks for getting this ironed out.

Ciao,

- vijay

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 31 Jan 2010 09:53:36 +0100

> Brian: Works for me.  Thanks for getting this ironed out.

I like this. People won't be reading between the lines and understand that a "SIP URI" means that we prefer domain usage, since that will give them more functionality. Sometimes, you just have to be extremely clear.

Thanks, Brian and Vijay!
/O

---

From: Dean Willis <[email-masked]>
Date: Sun, 31 Jan 2010 12:13:42 -0600

On Jan 27, 2010, at 12:02 PM, Cullen Jennings wrote:

>> The adoption rate of TLS peaked a couple of years back, and has  
>> been steadily declining since? That should tell us something  
>> important. Like, maybe nobody can figure out how to implement this  
>> stuff, nobody actually uses it, or nobody runs SIP on a hostile  
>> network. Not sure which is the case, here.
>>
>> --
>> Dean
>
> Dean, I don't buy this argument in the slightest. The prevalence of  
> something at SIPit has close to nothing to do with the deployment  
> prevalence or the number of products that support it. Most widely  
> distributed mainstream SIP products are not taken to SIPit at all  
> because the value proposition of SIPIit is mostly around helping fix  
> new things where a vendor does not have significant experience to  
> get them right without showing a pre release version of a product to  
> your competitors. For example, the amount of TLS at SIPit exceeds  
> the Video at SIPit, yet I hardly think you can come to the  
> conclusions that therefore the video over IP market it really small.
>

Okay. Show me a current large-scale SIP deployment that uses TLS, and  
I'll show you a widespread adoption rate for TLS that is roughly  
comparable to the TLS implementation rate at SIPit.

--
Dean

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 1 Feb 2010 08:36:47 +0100

31 jan 2010 kl. 19.13 skrev Dean Willis:

> Okay. Show me a current large-scale SIP deployment that uses TLS, and I'll show you a widespread adoption rate for TLS that is roughly comparable to the TLS implementation rate at SIPit.
> 

I won't get into the debate about adoption rate, but can report that we have focused a bit more on TLS during the last couple of SIPits. During the SIPit in New Hampshire in September 2009, Nils Ohlmeier and I set up a large set of automated tests and also had a short seminar to educate people about general TLS/PKI and the implementation in SIP. Thanks to the self-tests and the training there was a lot of TLS testing going on and we came much more detailed in the group tests than I've seen before. 

I hope that will have an impact on implementations out there. Robert has been working to set up a permanent SIPit test bed with these tests and a few other self-tests that has been around on SIPits.

/O