[secdir] secdir review of draft-ietf-sipcore-info-events

[Stephen Farrell <[e-mail]>]

Hi,

(Sorry for the tardy review;-)

This specification sort-of provides a SIP-based tunnel
for application protocols.

1: What prevents (or allows detection of) insertion of
bogus Info Package specifications? (e.g. by a proxy). If
nothing, then why is this ok?

2: I don't know how prevalent implementations of this are,
or will be, but since this calls for the user agents to
include a MIME parser plus parsers for whatever MIME types
the user agent claims to support, I'd say some guideance
about defensive programming (e.g. avoiding buffer overruns
etc.) should be given somewhere (maybe that's a more generic
SIP thing though).

3. 4.2.2. says that a UA MUST indicate which Info packages it
supports.  That seems a bit open-kimono - why MUST all UAs tell
everyone everything they support all the time? Won't that
expose more attack surface than is wise? Wouldn't it be better
to first know who the other UA is, before telling them everything
every time? For example, imagine a UA supported the "US Govt
SECRET foobar application Info Package," I'm guessing that it
wouldn't be ok to just say that to every UA one meets on
the Internet.

4. 10.10 says that if TLS is not good enough, then use S/MIME.
My understanding is that no UAs implement S/MIME (or CMS really)
and no networks support its use. So shouldn't that really say
"if TLS is not good enough, then just don't do it or require
the application to do its own security"? Same point applies to
section 13. I would think that securing specific applications
would be easier and more likely than getting S/MIME used in UAs,
so why not recommend that?

5. 1st para of section 13 says that this will be an improvement
over RFC2976. I would think a reference to the problems with
that RFC or to something detailing the expected improvement is
warranted.

6. How and why would one "filter for approved Info Packages" as
stated in section 13? It seems like that single sentence is either
too much or too little, so maybe delete it or expand upon it, so
that an implementer might know what's reasonable filtering.

Non security notes:

s1, 2nd para: how can you prevent INFO being used to update the
state of a "SIP dialog or session"? Seems like it'd be more
accurate to say that that's the intent but that there really are
no guarantees. The example given in the abstract of RFC2976 seems
in fact to be directly related to signalling so that's confusing.

Nits/Typos:

10.10: s/certain level/a certain level/


Stephen.