Subject: Re: [sipcore] Review of sipcore-sec-flows-01

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

Thanks for the input!

For all the changes below I find agreeable,  I will proceed with the  
changes unless someone halts and catches fire from objections.

-b

On Dec 22, 2009, at 2:28 PM, Vijay K. Gurbani wrote:

> First off, sorry for the delay in getting this review out.  I had
> promised to send it shortly after Thanksgiving, but ...
>
> Second, I believe that this work is of importance to the development
> community that can use an additional resource to get a TLS-capable
> SIP entity tested and running.
>
> That said, here are the rest of my comments from my review.
>
> 1) S1, paragraph 2:
>
> OLD:
> Furthermore, testing at the events is often hampered by trying
> to get certificates signed by some common test root into the
> appropriate format for various clients.
>
> NEW:
> Furthermore, testing at the events is often hindered due to the
> lack of a commonly trusted certificate authority to sign the
> certificates used in the events.
>

Will do.

> 2) S1, paragraph 2: The following text
>
>   In addition, this document provides a common certificate and
>   private key that can be used for a Certificate Authority (CA)
>   to reduce the time it takes to set up a test at an
>   interoperability event.
>
> makes the reader believe that the common certificate and private
> key can be used by any CA in the world.  This is, of course,
> not the intent.  The document is providing a common certificate
> and the associated private key for the express purpose of creating
> a mock CA to sign the certificates for the interoperability events.
>
> Thus, I would suggest the following paragraph as a substitute for
> the above one (please feel free to edit as needed):
>
>   In addition, this document provides a common certificate and
>   private key that can be used to set up a CA --- a mock CA ---
>   during the SIP interoperability events.  Certificate requests from
>   the users will be signed by the private key of the mock CA.
>

Will do.

> 3) S1, paragraph 4, last sentence:
> s/the same CA certificate/the same mock CA private key/
>

Will do.

> 4) S1, paragraph 5:
> s/list of things implementers/list of items that implementers/
>

Will do.

>
> 5) S1, paragraph 6:
> s/A way to make/Scripts and instructions to make/
> s/is presented/are presented/
>
Will do.

> 6) S3.2, note that the DNS label in the certificate under the SAN
> extension is wrong.  It should be "DNS:example.com" and not
> "DNS:com".
>
> Also, the example.net certificate suffers from the same problem,
> it also contains "DNS:net" in the SAN instead of "DNS:example.net".
>

THANKS.  The script that generates the certs is in somewhat in error.   
I will repair it and incorporate fresh binaries as infrequently as  
possible.  The binary changes will be some of the last ones I will  
make before "finalizing" the draft.

> 7) S3.3, the sentence "The message could be coming from a host
> called atlanta.example.com, and the AOR in the user certificate would
> still be the same." adds ambiguity to the text without contributing
> much information.  Unless there is a specific reason why the reader
> needs to know that the SIP message sent over a TLS channel established
> by this certificate originated from the host atlanta.example.com, I
> would suggest to remove the offending sentence completely.
>

Will do.

> 8) S4.1, paragraph 1:
> s/TLSRFC/TLS RFC/
> s/set to example.net/contains example.net
>

Will do.

> 9) S4.1, the ssldump output: should not the second endpoint be
> identified as "www.example.net (5061)"?  See the very first line
> of the ssldump output.
>

It should.  There is a note in the "binary content issues" email I  
sent regarding that.  The tool is doing a reverse lookup, and alas,  
both domains have the same address in the test environment on my Mac.

> 10) S4.2: The first paragraph says that the <allOneLine> convention
> from rfc4475 is used, however, I do not see the <allOneLine>
> element in the subsequent example.
>

I will go see what it takes to incorporate that into the tools that  
automagically prepare these messages for inclusion in the draft.

> 11) S4.2, first open issue: If Contact is not allowed in a MESSAGE
> and its corresponding 2xx, simply take it out, no?  Taking the
> Contact out does not result in any loss of generalization, nor
> does it detract from the point the example is trying to make.
>

I'm happy with that.  That Open Issue could really be two separate  
issues, but, if the real solution were to be that we need to INVITE  
instead, what we do with MESSAGE would be moot.  I just wanted to be  
sure we have The Right Examples (TM).

That said, if there's no further ado, consensus so far is that we  
stick with MESSAGE and clean it up.

> 12) S4.2, second open issue: If you take Contact out of the 200 OK,
> then you do not have this problem.  The Contact in the 200 OK
> contains an IP address that is the same as the one in the top-most
> Via header (which is what leads to the confusion in the first
> place, I believe.  The To and From contain URIs with domain names.)
>

Will do.

> 13) S4.2, third open issue: I am not sure what you are trying to
> point out by referencing rfc3263 or connect-reuse here.  IMHO, the
> section looks fine without referencing rfc3263 or connect-reuse.
>

I gather more folks are happier with it in there.  Feel free to fight  
amongst yourselves.  ;)

> 14) S5.1: I would advise being consistent and using <allOneLine>
> convention everywhere in this draft.

As above.

>
> 15) S5.1, this is a nit, but to be orthogonal to S4.2, it will help
> if the message body in S5.1 contained the same message as in
> S4.2 (i.e., "Hello!" instead of "hello").

Not a difficult thing to change when I'm fixing the binary-generated  
content.  But that will be later rather than sooner.

>
> 15) S5.3: I would advise being consistent and using <allOneLine>
> convention everywhere in this draft.

As above.

>
> 16) S6: First open issue: Cullen has already stated that he and
> Kumiko has observed these.  In addition, 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) Rest of the table created from data 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.
>

Actually, if you want to come up with that summary, I would happily  
include it in the draft.

> 17) S6, second open issue: Does it matter?  What is gained by further
> categorizing the SIP clients into UAS, UAC, or a proxy?
>

These came up in another review on this list.   I don't know if they  
had a specific issue in mind, or if they thought it would simply be  
more informative.

> 18) S7, general comment -- some "folklore" is specified in the
> domain-certs document
> (http://tools.ietf.org/html/draft-ietf-sip-domain-certs-04), which
> is with the IESG right now.  The domain-certs document should
> be cited here as well.
>

Good, thanks.

> 18) S7, second bullet item is normatively specified in domain-certs.
> Suggest that a reference to domain-certs be included here for
> further reading.
>

Will do.

> 19) S7, third open issue: I believe that IP addresses can appear in  
> the
> SAN (rfc5280 says so.)  Their handling is specified in domain-certs (I
> believe they will appear as "DNS:192.168.0.1"; we need to have someone
> -- from pkix? -- ascertain this.  If this is the case, then their
> handling is specified in S7.1 of domain-certs.)

Ok.  We'll need to follow up on this.

>
> 20) S7: For the test cases in S7, I wonder if it is worth creating  
> test
> certificates issued by the mock CA and including these in the
> draft?  That way, implementers can simply download the certificates
> and use them for their testing.  If people think this is a good
> idea, I can spend some time doing this.
>

I'm not sure I follow you.  We have host certs already generated and  
attached in the draft.  Are you concerned that the domains they are  
issued for aren't usable?  If so, maybe we should just make those more  
easily usable and center our examples around them?

> 21) S7: last open issue: I think that the case of having one or more
> certificates in a path not provided or not available is a good one.
> Question is should we provide a certificate signed by a subordinate CA
> for testing to implementers or simply discuss this case?

This is the third time someone's brought up whether we need a non-root  
CA.  What seems best to me is to give example certs:  the root CA we  
already have, a non-root CA signed by the root CA, and a host cert  
signed by that non-root CA.  I think simply discussing the case should  
be sufficient, because, truthfully, the most difficult aspect of that  
case is configuring the TLS implementation library.   We haven't dealt  
with that, and we aren't going to.

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