Re: [sipcore] AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

> On Jun 21, 2016, at 11:22 AM, Ben Campbell <[e-mail]> wrote:
> 
> That's a good start, but don't be surprised if we get questions specifically about adding NPLI to ACK requests. some language to the effect of the following might help:
> 
> "This document adds the ability to include P-Access-Network-Info in ACK requests. As documented in RFC7315, P-Access-Network-Info may include privacy sensitive information, including the user's location. The security and privacy considerations for P-Access-Network-Info in ACK requests are similar to those for the other SIP requests discussed in RFC7315.”

I’m fine with adding such text.

Christer - Can we append this to your proposed text?

Gonzalo


> 
> Thanks!
> 
> Ben.
> 
> On 21 Jun 2016, at 3:26, Christer Holmberg wrote:
> 
>> Hi Ben,
>> 
>> See inline.
>> 
>>> --------------
>>> 
>>> Substantive:
>>> 
>>> The security considerations state that the draft removes some places
>>> that some of the P-Headers can be sent, but expands that to some other
>>> places. Further, it says that neither introduce new security
>>> considerations beyond those in 7315.
>>> 
>>> I accept that for the reduction part. But I'm not sure we can state that
>>> sort of thing for the expansion part, at least without some more
>>> discussion. Since 7315 already acknowledges potential privacy issues
>>> around P-Access-Network-Info, I'd like to at least see a sentence or two
>>> about the allowance of that in ACK requests, even if they just say that
>>> this addition makes things no worse than they already are.
>> 
>> 
>> OLD:
>> 
>> The security considerations for P- header fields are defined in
>>   [RFC7315].  This specification allows some header fields to be
>>   present in messages where they were previously not allowed, and
>>   disallow some header fields to be present in messages where they were
>>   previously allowed. That does not cause any security issues, but
>>   implementations need to be aware that implementations may not have
>>   been updated according to this document, and take proper actions if a
>>   header field occur, or does not occur, in a message where it should
>>   occur (or occurs in a message where it should not occur).
>> 
>> 
>> 
>> NEW:
>> 
>> The security considerations for these P- header fields are defined in
>>   [RFC7315].  This specification allows some header fields to be
>>   present in messages where they were previously not allowed, and the
>> security considerations and assumptions (e.g. regarding only sending
>> Information to trusted entities) also to those messages. In addition,
>> this specification also disallow some header fields to be present
>> in message where they were previously allowed. That does not cause
>> any security issues, but implementations need to be aware that
>> implementations may not have been updated according to this document,
>> and take proper actions if a header field occur, or does not occur,
>> in a message where it should occur (or occurs in a message where it
>> should not occur).
>> 
>> 
>> 
>>> Editorial:
>>> 
>>> -5, first sentence: "The security considerations for P- header fields
>>> are defined in
>>>   [RFC7315]"
>>> I assume this means 7315 discusses the security considerations for these
>>> P-Headers specifically, not P-Headers in general. Is this the intent? If
>>> so, I suggest:
>>> 
>>> s/... for P-header fields.../ ... for these P-header fields...
>> 
>> I¹ll fix as suggested (ass new text above).
>> 
>> Regards,
>> 
>> Christer