Subject: RE: [Sip] The security-flows document -- use it

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 1 Aug 2005 07:59:07 -0600

Cullen, Kumiko,

   I believe this document is helpful: it looks at TLS implementation with the eyes of a sip developer (kind of similar to the early RFC2818 for http folks).

   In the light of today's working group discussion, and per our brief chat with Cullen, here are a couple of comments for your consideration on draft-jennings-sip-sec-flows-03.txt:

--- 1. Requirement section?
The document currently reads just like the sip call flow examples right now and may not lead folks to get the main implementation gotchas you are seeing at sipit. Jonathan made a similar point at the mike.
If - as you pointed out at the mike - the intent of the document is to help implementers put the right attention to some potentially obscure areas of tls/s-mime implementations, it would help abstracting those key requirements in a separate, high-level sections with pointers to the relevant ietf rfcs & section. 
Another question I have is whether there might be some other "obvious" requirements that could be added, similar to RFC2818 section 2.2 on error cases (if TLS error, at the SIP app level, how could/should it be handled?)

In short, consider moving section 6 on "testing notes" as the first section, and consider changing some of the notes to actual requirements:
For e.g., replace
<  A common problem in interoperability is that some SIP clients do not
<  support TLS and only do SSLv3.  Check that the client does use TLS.
With something like
> SIP clients SHOULD/MUST support TLS [RFC2246] as defined in SIP []
>  section x.y. Note that TLS 1.0 and SSL 3.0 do not interoperate 
> (see RFC2246 for more details and section E on TLS' Backward
> Compatibility With SSL). 

----> you could potentially borrow more or less text but my preference would be to state a simple requirement, then give the pointers. Would it be useful to also point to "HTTP Over TLS" RFC2818 and AES ciphers for TLS RFC3268 (you mention 3268 in the refs but not in the body of the draft text)?

Similar comment with:
< Many SIP clients were found to accept expired certificates with no
< warning or error.
If you can find a hard requirement in TLS or somewhere that, TLS parties must validate certificates when present (cert expiration for e.g, etc.), that would make this text clearer.

Note that a number of folks may argue that this is duplication, a repeat of requirements that exist elsewhere and we don't need it. As Robert Sparks mentioned, this may however be needed based on the sipit findings.

--- 2. msg flow and other test message snippets
If you could articulate some of the main gotchas as requirements and then provide the msg flow, it would be even more helpful. Mapping some of the requirements to msg flow sequences or actual test cases would be even better (in the context of sipit, but that may not belong in your document).

Jean-François

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip