Re: [Insipid] Alissa Cooper's Discuss on draft-ietf-insipid-session-id-26: (with DISCUSS and COMMENT)

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 18 August 2016 01:18 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229E412B04B for <insipid@ietfa.amsl.com>; Wed, 17 Aug 2016 18:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hmk9AnCjDLs0 for <insipid@ietfa.amsl.com>; Wed, 17 Aug 2016 18:18:43 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AEDF12B00F for <insipid@ietf.org>; Wed, 17 Aug 2016 18:18:43 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-08v.sys.comcast.net with SMTP id aByjbR7B184vjaBykbRaw4; Thu, 18 Aug 2016 01:18:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with SMTP id aByjbKIIKvDp9aBykbt8PF; Thu, 18 Aug 2016 01:18:42 +0000
To: insipid@ietf.org
References: <147135877745.22972.7550246068971515295.idtracker@ietfa.amsl.com> <2377966D-0E2D-4C90-806A-8F82D8C2C33C@cisco.com> <F3B208D2-0C38-42A1-B6EA-35D9D46DBBF1@nostrum.com> <5FAD7996-7E41-4612-9A13-2ACFED396085@cisco.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <2f23b591-039f-5d8d-4883-250d933a1670@alum.mit.edu>
Date: Wed, 17 Aug 2016 21:18:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <5FAD7996-7E41-4612-9A13-2ACFED396085@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfEVZWyEOAAh5pu/pNH/dZLlfkicK1iN1mCoPVm2PET3fC9YIM9VzDtw09VWNkcULepEka6+x9xI7fSpajEVXofcI+SxDZB4YTp5dZma7XL8M+TXPEI06 P1q6XCGdEN/JDPtWc87gtFeoOdFcznbeUB3YvRNu0n/L4Z/HgDjqQl9VJyZEuP2uWgngTa0TNcEY3Q==
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/q2VMbv9SydqluRoev9SjLTATdVo>
Subject: Re: [Insipid] Alissa Cooper's Discuss on draft-ietf-insipid-session-id-26: (with DISCUSS and COMMENT)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 01:18:44 -0000

On 8/17/16 8:18 PM, Paul Giralt wrote:
>
>> On Aug 17, 2016, at 6:12 PM, Ben Campbell <ben@nostrum.com> wrote:
>>
>> On 16 Aug 2016, at 21:20, Paul Giralt (pgiralt) wrote:
>>
>> [...]
>>
>>> == Section 12 ==
>>>>
>>>> "This document allows for additional parameters (generic-param) to be
>>>>  included in the Session-ID header.  This is done to allow for future
>>>>  extensions while preserving backward compatibility with this
>>>>  document.  To protect privacy, the data for any generic-param
>>>>  included in the Session-ID header value MUST NOT include any user or
>>>>  device information."
>>>>
>>>> To preserve the privacy properties of the session identifier, I think
>>>> this prohibition needs to extend further -- not just to any user or
>>>> device information, but to any identifier that persists beyond the
>>>> current session. Otherwise some parameter defined in the future could
>>>> easily be used to correlate sessions, while the identifier is currently
>>>> specified so as to avoid that.
>>>>
>>>
>>>
>>>
>>> I agree with your assessment, however I think the restriction has to be carefully worded because I think the ability to correlate sessions in some meaningful way could be something a future extension might want to do. For example, in an omni-channel contact center environment, we might want to be able to correlate the different channels of communications by including some other identifier (which would have to adhere to the privacy restrictions put in place here). Another potential use would be to include something like a “Related Session-ID” when two sessions are merged together in a way that is not addressed by this specification and it is desirable to include information to link the two sessions together.
>>>
>>> I think your concern is more around temporal correlation where two unrelated sessions from the same user could be somehow be associated with each other. If I’m understanding the concern correctly, I can add some verbiage to address this concern without completely eliminating the possibility of a future version having the ability to somehow correlate related sessions that cannot be correlated with the specification as it stands.
>>
>> I don't object to this path forward, but I think we will need to be careful that the future use cases we enable do not become the exact persistent correlation issue that Alissa was concerned about. Is the potential  not already covered by the rather expansive definition of a "communication session"?
>
> I don’t think it’s enough on its own because a single UUID could end up in more than one communication session (in the case of a transfer or conference), so stating that an identifier must be constrained to a single communication session is not accurate; however, from the point of view of a single endpoint, it is true that it must generate a unique identifier for each communication session it participates in. The other issue is that communication session is defined in a very SIP-specific way (user agents, SIP messages, etc… ) but a future enhancement could potentially include something related to something other than a SIP session.
>
> I think I completely understand the concern here and think I can write some text to address it by just imposing restrictions on reusing an identifier across unrelated communications sessions.

I look forward to seeing that, because IIUC reusing the session ids was 
the primary reason for making the two-part session-ids.

	Thanks,
	Paul