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

[Christer Holmberg <[e-mail]>]

Hi,

I've submitted a new version (-07), and I'll reply to the IETF e-mail.

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[e-mail]] 
Sent: 22 June 2016 18:04
To: Christer Holmberg <[e-mail]>
Cc: Gonzalo Salgueiro <[e-mail]>; [e-mail]; SIPCORE <[e-mail]>
Subject: Re: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06

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:draft-holm
> [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:draft-ho
>> [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:draft-hol
>> [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