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

["Ben Campbell" <[e-mail]>]

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

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