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

From: "Ben Campbell" <[email-masked]>
Date: Mon, 20 Jun 2016 14:27:29 -0500

(copying sipcore since, even though this is not a wg draft, sipcore 
probably offers the best nexus of expertise.)

Hi,

This is my AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06. 
I have one substantive comment and one editorial comment. I don't think 
either of these need block IETF last call. They can be handled along 
with any other last call feedback.

Thanks!

Ben.

--------------

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.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jun 2016 08:26:59 +0000

Hi Ben,

See inline.

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).

>s/... for P-header fields.../ ... for these P-header fields...

I¹ll fix as suggested (ass new text above).

Regards,

Christer

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 Jun 2016 10:22:24 -0500

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."

Thanks!

Ben.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 21 Jun 2016 16:44:36 +0000

> On Jun 21, 2016, at 11:22 AM, Ben Campbell <[email-masked]> 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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jun 2016 02:28:21 +0000

Hi,

We can add the text.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Gonzalo Salgueiro (gsalguei)<mailto:[email-masked]>
Sent: ‎21/‎06/‎2016 19:44
To: Ben Campbell<mailto:[email-masked]>
Cc: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; SIPCORE<mailto:[email-masked]>
Subject: Re: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jun 2016 07:18:57 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 22 June 2016 at 05:28
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ben Campbell <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Nevenka Biondic <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ben Campbell <[email-masked]<mailto:[email-masked]>>, "A. Mahoney" <[email-masked]<mailto:[email-masked]>>
Resent-Date: Wednesday 22 June 2016 at 05:28

Hi,

We can add the text.

Regards,

Christer

Sent: 21/06/2016 19:44

> On Jun 21, 2016, at 11:22 AM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:
>

Gonzalo

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Jun 2016 09:47:05 -0500

Works for me.

Thanks!

Ben.

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

> From: Christer Holmberg 
> <[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, Ben Campbell 
> <[email-masked]<mailto:[email-masked]>>
> Cc: 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>
> Subject: RE: AD Evaluation of 
> draft-holmberg-dispatch-rfc7315-updates-06
> Resent-To: Christer Holmberg 
> <[email-masked]<mailto:[email-masked]>>, 
> Nevenka Biondic 
> <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>, Ben Campbell 
> <[email-masked]<mailto:[email-masked]>>, "A. Mahoney" 
> <[email-masked]<mailto:[email-masked]>>
> Cc: Christer Holmberg<mailto:[email-masked]>; 
> [email-masked]<mailto:[email-masked]>; 
> SIPCORE<mailto:[email-masked]>
> Subject: Re: AD Evaluation of 
> draft-holmberg-dispatch-rfc7315-updates-06
>
>
>> On Jun 21, 2016, at 11:22 AM, Ben Campbell 
>> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> "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.”
>
>>> the

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jun 2016 14:59:04 +0000

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:[email-masked]>
Sent: ‎22/‎06/‎2016 17:47
To: Christer Holmberg<mailto:[email-masked]>
Cc: Gonzalo Salgueiro<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; SIPCORE<mailto:[email-masked]>
Subject: Re: AD Evaluation of draft-holmberg-dispatch-rfc7315-updates-06

Works for me.

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Jun 2016 10:03:56 -0500

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:

> Cc: Gonzalo Salgueiro<mailto:[email-masked]>; 
>>>>> I accept that for the reduction part. But I'm not sure we can 
>>>>> state
>>>>> that

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jun 2016 16:58:17 +0000

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:[email-masked]] 
Sent: 22 June 2016 18:04
To: Christer Holmberg <[email-masked]>
Cc: Gonzalo Salgueiro <[email-masked]>; [email-masked]; SIPCORE <[email-masked]>
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:

> [email-masked]<mailto:draft-holm
> [email-masked]>;
>> <[email-masked]<mailto:[email-masked]
>> >>
>> <[email-masked]<mailto:draft-ho
>> [email-masked]>>,
>> <[email-masked]<mailto:[email-masked]
>> >>,
>> Nevenka Biondic
>> [email-masked]<mailto:draft-hol
>> [email-masked]>;
>>>>> 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.
>>>>>
>>>>> 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 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:
>>>>>