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

[Christer Holmberg <[e-mail]>]

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