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

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

Works for me.

Thanks!

Ben.

On 22 Jun 2016, at 2:18, Christer Holmberg wrote:

> Hi,
>
> 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). 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].”
>
> Regards,
>
> Christer
>
>
> From: Christer Holmberg 
> <[e-mail]<mailto:[e-mail]>>
> Date: Wednesday 22 June 2016 at 05:28
> To: "[e-mail]<mailto:[e-mail]>" 
> <[e-mail]<mailto:[e-mail]>>, Ben Campbell 
> <[e-mail]<mailto:[e-mail]>>
> Cc: 
> "[e-mail]<mailto:[e-mail]>" 
> <[e-mail]<mailto:[e-mail]>>, 
> "[e-mail]<mailto:[e-mail]>" 
> <[e-mail]<mailto:[e-mail]>>
> Subject: RE: AD Evaluation of 
> draft-holmberg-dispatch-rfc7315-updates-06
> Resent-From: <[e-mail]<mailto:[e-mail]>>
> Resent-To: Christer Holmberg 
> <[e-mail]<mailto:[e-mail]>>, 
> Nevenka Biondic 
> <[e-mail]<mailto:[e-mail]>>, 
> "[e-mail]<mailto:[e-mail]>" 
> <[e-mail]<mailto:[e-mail]>>, Ben Campbell 
> <[e-mail]<mailto:[e-mail]>>, "A. Mahoney" 
> <[e-mail]<mailto:[e-mail]>>
> Resent-Date: Wednesday 22 June 2016 at 05:28
>
> Hi,
>
> We can add the text.
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ________________________________
> From: Gonzalo Salgueiro (gsalguei)<mailto:[e-mail]>
> Sent: 21/06/2016 19:44
> To: Ben Campbell<mailto:[e-mail]>
> Cc: Christer Holmberg<mailto:[e-mail]>; 
> [e-mail]<mailto:[e-mail]>; 
> SIPCORE<mailto:[e-mail]>
> Subject: Re: AD Evaluation of 
> draft-holmberg-dispatch-rfc7315-updates-06
>
>
>> On Jun 21, 2016, at 11:22 AM, Ben Campbell 
>> <[e-mail]<mailto:[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