Last Call Review of draft-ietf-sipcore-content-id-06
review-ietf-sipcore-content-id-06-secdir-lc-perlman-2017-06-24-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

What this RFC does is define a syntax that allows a part of a SIP message
to refer to another part of the SIP message. This was previously possible
only if the referred-to-part was a body part and this spec generalizes that
to allow references to an entire body.

It is very difficult to read this by itself, even though it is very short.
I'd think it would be better to just make this minor modification to the
base RFC.  And if we want to have these tiny RFCs, I understand that it's
unusual for someone to just read one rather than the whole group...it's
really the case of a SECDIR person being assigned a specific RFC that might
not be caught up on all the jargon for that WG.  However, I think each RFC
should be understandable.  There ought to be a "context", that includes
what other RFCs should be read first, and in particular, either an acronym
dictionary or a pointer to an RFC that has explanations for all the
acronyms in the little RFC.

I found one technical point that seems like an important inconsistency:
Section 3.2 says the Content-ID header field must be unique in the context
of a given SIP message, while section 3.4.1 says it must be globally
unique. The difference is important; globally unique is hard and ugly. I
hope that section 3.4.1 is wrong.

More examples - with annotations - would be helpful, as would an
explanation of how people work around this limitation today. Perhaps also
an explanation understandable to an ordinary human as to what problem they
are trying to solve and the context in which that problem comes up.

Perhaps also worth asking is how the sender of a SIP message is supposed to
know whether the recipient of the SIP message can handle this new syntax,
and perhaps what it would do if it couldn’t. I suspect they have a good
answer to these questions, but they would be worth stating.

The security considerations section says
"The Content-ID header field value MUST NOT reveal sensitive user

   information.

   If the message-body associated with the Content-ID header field is an
   encrypted body, it MUST NOT be possible to derive a key that can be
   used to decrypt the body from the Content-ID header field value."


It seems to me that that text should be in the body of the RFC, because it

is specifying what must be done, rather than what I usually think of for

security considerations, which would say "if you didn't do what we said

in section XXX, the following bad things could happen."  But as long as people

read the security considerations section, it's OK.


Radia