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

From: Brian Hibbard <[email-masked]>
Date: Tue, 24 Nov 2009 15:26:14 -0600

There are a lot of paragraphs prefaced with "OPEN ISSUE" in the  
draft.  This email points out some of them that are specifically  
related to the technical content of the draft. Some of these are  
questions which can hopefully be addressed by experts in the related  
areas.  Some of these are issues that require working group consensus.

== Message Composition in sections 4.2 and 5.X ==
Are we fine with using MESSAGE, or do we need to use INVITE?

Do we want to demonstrate SIPS rules for Contact header field?

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?

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

Do we mean client class devices, or user agents in general? Does this  
exclude proxies? (same question throughout section.)

Is "...should send...must be prepared..." intended to be a normative  
statement? There is a larger issue as to whether this document is  
intended to be normative or informative. Should it be standards track?

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?

== Additional Test Scenarios section 7 ==

Are we sure all of this is truly folklore and none of it is from bona  
fide normative language somewhere? The true folklore portions may  
indicate future normative work we need to do.

 From first bullet, "peer's URI"...What URI? An AoR for the user? From  
or To values? Contacts? Request-URIs? For request URIs, do we need to  
discuss the effects of retargeting? Do we need to consider some of the  
current History-Info discussions?

 From second bullet: What if all you've got is an IP address? Do we  
disallow IPAddress entries in SubjectAltName?

First sub-bullet (Wildcard matching is not allowed against these  
dNSName entries): Is there something that can be referenced here? In  
particular, RFC2818 explicitly allows wildcards in dNSName entries. It  
is not obvious to me whether the proscription against wildcards in  
RFC4474 should apply to general use of TLS, or just to identity.

What about cases where the basic constraints or allowed uses are not  
appropriate? Is it worth putting in cases around self-signed certs?  
(i.e. self-signed cert, explicitly trusted, not trusted, etc.) How  
about cases where one or more certs in the chain to the root were not  
provided and not available through other means? Those seem like  
sensible cases to either include or explain why they aren't included.  
The self-signed cert is definitely a popular case among developers.

== CRLs in section 10 ==
We should probably say something about CRLs. We need to get consensus  
on whether we want to recommend a method for retrieving CRLs. We could  
explicitly state that these are assumed to be retrieved out-of-band.  
Should they be retrieved by HTTP by some maintenance procedure? Via  
OCSP?  How do we expect the SIP community to handle CRLs?

== Appendix A.  Making Test Certificates ==

The information in this section needs to be verified with the latest  
software versions. How to do conversions between supported types needs  
to be updated accordingly.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Nov 2009 15:47:39 -0600

> indicate future normative work we need to do.
[...]

Brian: While I will go through the entire document, I can
help you with specifically S7, having initially contributed it.

I will get back to you after Thanksgiving with some feedback
on S7 and other sections.

Ciao,

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