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

[Christer Holmberg <[e-mail]>]

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