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

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

Please go ahead. It might be worth replying to the IETF last call 
announcement with a mention of the update, in case anyone has a review 
in progress.

Thanks!

Ben.

On 22 Jun 2016, at 9:59, Christer Holmberg wrote:

> Good :)
>
> Is it ok of I submit a new version of the draft? That way the new text 
> will be available during  IETF last call.
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ________________________________
> From: Ben Campbell<mailto:[e-mail]>
> Sent: ‎22/‎06/‎2016 17:47
> To: Christer Holmberg<mailto:[e-mail]>
> Cc: Gonzalo Salgueiro<mailto:[e-mail]>; 
> [e-mail]<mailto:[e-mail]>; 
> SIPCORE<mailto:[e-mail]>
> Subject: Re: AD Evaluation of 
> draft-holmberg-dispatch-rfc7315-updates-06
>
> 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