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

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Dec 2009 23:28:01 -0700

On Nov 24, 2009, at 2:26 PM, Brian Hibbard 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 }. 

Cullen (All my post on this draft are in my role as an individual contributor)

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Dec 2009 23:34:09 -0700

On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote:

> == Observed Interoperability Issues in section 6==
> Who observed them? Is this experience from SIPits, etc? I think it would strengthen the idea that these are real-world, observed-in-the-wild issues to give sources.

Kumiko and I at SIPits are the main ref but this is all pretty uh fluffy, it's not like we have enough observation for any significant statistical sample. I have also seen S/MIME flows in operational networks but no one that uses those is going to be very interested in talking about them so I doubt we are going to get more input on this. I'm not wiling to put in an RFC names of vendors or product that had problems with their S/MIME flows - among other things that seems like it would violate the NDA and spirit of SIPit testing. Perhaps the best thing would be to remove the "problems observed" type text and just leave it at the  "If you are writing some code, make sure it does not have these problems" type text.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Dec 2009 23:37:16 -0700

On Nov 24, 2009, at 2:26 PM, Brian Hibbard wrote:

> There's some implicit stuff here that should be explicit. Do you mean to recommend never attaching certs? It's probably worth mentioning the message size limit issue. What do we mean by "it cannot be relied upon"--that we can't rely on the peer sending it, or it is unreliable when the peer does send it?

The first thing not the second. There is no guarantee that the peer will attach a cert to every message that would use it so you have to have some way to cache or get certs.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Dec 2009 23:39:45 -0700

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.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Dec 2009 23:44:08 -0700

On Nov 24, 2009, at 2:26 PM, Brian Hibbard 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.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 10 Dec 2009 08:52:14 -0600

Cullen Jennings 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?
> 
> 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
-- 
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/

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 10 Dec 2009 09:03:05 -0600

Cullen Jennings 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: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 11 Dec 2009 15:07:55 +0100

NO.

In my view this is an informational document. Description only in the text.

See previous message. 

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Thursday, December 10, 2009 6:28 AM
> To: Brian Hibbard
> Cc: SIPCORE; Kumiko Ono
> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: 
> technical issues
> 
> 
> > 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?
> 
> 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 }. 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 11 Dec 2009 11:05:29 -0600

On reflection, I agree this draft should not contain normative statements for this sort of thing.  If we run across a real need for such language in this draft, perhaps it means we have other standards work to do.

In this case, is there nothing in RAI's entire body of work that talks about this normatively?

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 22 Dec 2009 11:44:49 -0600

Cullen Jennings wrote:
>> == Observed Interoperability Issues in section 6== Who observed
>> them? Is this experience from SIPits, etc? I think it would
>> strengthen the idea that these are real-world, observed-in-the-wild
>> issues to give sources.
> 
> Kumiko and I at SIPits are the main ref but this is all pretty uh
> fluffy, it's not like we have enough observation for any significant
> statistical sample. [...]

Here is a table that contains the number of TLS implementations
since SIPit 16:

    SIPit   Unique          Number of TLS
    No.     Implementations implementations   Percentage
    ----------------------------------------------------
    16       57                  25               44%
    18       73                  30               41%
    19       90                  41               45%
    20       90                  42               46%
    21       70                  34               49%
    22       80                  50               63%
    23       50                  24               48%
    24       43                  22               52%
    25       42                  16               38%

Note: (1) 16th SIPit was held in April 2005, 23 SIPit was held in
           October 2008.
       (2) Data for 16th SIPit is form my private archive
           and is not reflected in [1].
       (3) I don't have data for 17th SIPit.
       (4) Data from SIPit 18-25 is archived at [1].

[1] Robert J. Sparks, SIPit Summaries, archived at
     https://www.sipit.net/SIPitSummaries

In the last 3-4 bakeoffs, there weren't any implementations of
S/MIME.  In the earlier bakeoffs, there were very few implementations
of S/MIME.  If you want me to compile these for a summary, I can
do so.

I am preparing a review of sec-flows.  I will include this table
in the review comments as well.

Thanks,

- vijay

---

From: Dean Willis <[email-masked]>
Date: Wed, 23 Dec 2009 21:18:39 -0600

> Here is a table that contains the number of TLS implementations

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Dec 2009 23:03:25 -0500

> uses it, or nobody runs SIP on a hostile network. Not sure which is the 

I don't know the data - perhaps this just says something about which 
products are being brought to sipit, and *which* sipits they go to.

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 24 Dec 2009 10:22:42 -0600

> uses it, or nobody runs SIP on a hostile network. Not sure which is the 

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.

Thanks,

- vijay