Subject: [secdir] secdir review of draft-ietf-sipcore-content-id-06

From: Radia Perlman <[email-masked]>
Date: Thu, 22 Jun 2017 18:00:49 -0700

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Jun 2017 12:03:35 +0000

Hi Radia,

Thank You for the review! Please see inline.

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

The WG discussed that alternative, but this was the agreed way forward.

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

As a gen-art reviewer, I hear what you are saying, and in the beginning I more or less had the same opinion. However, later I have realized that to make each RFC “understandable” on its own would mean copy/pasting lots of text from other RFCs, and/or adding lots of clarification text. So, nowadays, when I review a document, I try to make sure that there are references where I can go and find extra information.

>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 guess it is assumed that the Normative References provide such “context”.

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

Section 3.4.1 IS wrong :) It will be fixed in the next version of the document.

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

We do try to explain the work around in sections 1.3 and 1.4. But, I agree we could add actual SIP messages to the examples in sections 1.4.1 and 1.4.2 to make it more clear.

>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 normal SIP procedures of RFC 3261 apply. It the sender requires the receiver to understand a certain extension (header fields etc) in order to accept the message there is a mechanism for that.

>"The Content-ID header field value MUST NOT reveal sensitive user information.

>read the security considerations section, it's OK.

So, I’ll keep the text in the Security Considerations.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 23 Jun 2017 15:17:07 -0500

[snip]

> On Jun 23, 2017, at 7:03 AM, Christer Holmberg <[email-masked]> wrote:
> 
Would an informational reference to RFC 5411 (The Hitchhiker’s Guide to SIP) be helpful? Maybe if it were cited early in the introduction as a place to look for more information about the various SIP RFCs?

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Jun 2017 15:39:41 +0000

Hi,

>>> 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.
>>  
>> As a gen-art reviewer, I hear what you are saying, and in the beginning I more or less had the same opinion. 
>> However, later I have realized that to make each RFC “understandable” on its own would mean copy/pasting 
>> lots of text from other RFCs, and/or adding lots of clarification text. So, nowadays, when I review a document, 
>> I try to make sure that there are references where I can go and find extra information.
>>  
>>> 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.
>>  
> Would an informational reference to RFC 5411 (The Hitchhiker’s Guide to SIP) be helpful? Maybe if it 
> were cited early in the introduction as a place to look for more information about the various SIP RFCs?

I actually had a look in RFC 5411, but it doesn't clarify this.

We have defined lots of new SIP header fields over the years, and I think people know how to "fit" them into the ABNF. Having said that, IF we want to clarify this, I think it should be done in 3261, 5411, or some other generic document. 

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 27 Jun 2017 10:07:33 -0500

> On Jun 24, 2017, at 10:39 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

I think that's a reasonable answer.

---

From: Radia Perlman <[email-masked]>
Date: Tue, 27 Jun 2017 08:29:25 -0700

On Tue, Jun 27, 2017 at 8:07 AM, Ben Campbell <[email-masked]> wrote:

> > We have defined lots of new SIP header fields over the years, and I
> think people know how to "fit" them into the ABNF. Having said that, IF we
> want to clarify this, I think it should be done in 3261, 5411, or some
> other generic document.
> >
>
but I think it would be nice to have a couple of sentences in this RFC
saying "for an acronym list, see RFC xxx, for an overview of SIP concepts
see RFC xxx." rather than assuming that people will just read all the
normative references cited in the bibliography.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 27 Jun 2017 11:04:19 -0500

> On Jun 27, 2017, at 10:29 AM, Radia Perlman <[email-masked]> wrote:
> 
> 
> 
> but I think it would be nice to have a couple of sentences in this RFC saying "for an acronym list, see RFC xxx, for an overview of SIP concepts see RFC xxx." rather than assuming that people will just read all the normative references cited in the bibliography. 

The problem is, those things don’t really exist in a general sense. My point was that creating them for SIP in general is not something I think we should burden a minor extension with. We could reference 5411 as an overview of the SIP RFC space as of the time it was published, but it’s out of date now. But if we think we need those things for SIP in general (and we probably do), the work should happen elsewhere (e.g. in an update to 3261 or 5411.)

Now, it’s reasonable to at least expand non-well-known acronyms used in this draft on first mention. On a _quick_ scan, the only one I noticed that needed expansion is UAC, but there may be more. 

Thanks,

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Jun 2017 18:42:30 +0000

Hi,

...
 
>> but I think it would be nice to have a couple of sentences in this RFC saying "for an acronym list, 
>> see RFC xxx, for an overview of SIP concepts see RFC xxx." rather than assuming that people will 
>> just read all the normative references cited in the bibliography. 
>
> The problem is, those things don’t really exist in a general sense. My point was that creating them for SIP in general
> is not something I think we should burden a minor extension with. We could reference 5411 as an overview of the 
> SIP RFC space as of the time it was published, but it’s out of date now. But if we think we need those things for SIP 
> in general (and we probably do), the work should happen elsewhere (e.g. in an update to 3261 or 5411.)
>
> Now, it’s reasonable to at least expand non-well-known acronyms used in this draft on first mention. 
> On a _quick_ scan, the only one I noticed that needed expansion is UAC, but there may be more. 

Correct. In the Gen-ART review it was mentioned that I should expand UAC (in section 1.3) and UA (in the section title of section 3.4.1), so I will fix that.

Regards,

Christer