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

"Ben Campbell" <ben@nostrum.com> Wed, 17 August 2016 22:12 UTC

Return-Path: <ben@nostrum.com>
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 17E5E12D19F; Wed, 17 Aug 2016 15:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=unavailable 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 wTNYV_H0VIOq; Wed, 17 Aug 2016 15:12:57 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59FB712D1E4; Wed, 17 Aug 2016 15:12:57 -0700 (PDT)
Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7HMCiiq081645 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Aug 2016 17:12:45 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4]
From: "Ben Campbell" <ben@nostrum.com>
To: "Paul Giralt" <pgiralt@cisco.com>
Date: Wed, 17 Aug 2016 17:12:43 -0500
Message-ID: <F3B208D2-0C38-42A1-B6EA-35D9D46DBBF1@nostrum.com>
In-Reply-To: <2377966D-0E2D-4C90-806A-8F82D8C2C33C@cisco.com>
References: <147135877745.22972.7550246068971515295.idtracker@ietfa.amsl.com> <2377966D-0E2D-4C90-806A-8F82D8C2C33C@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/XzX1JmRV3g63Pge-1cRLdJxVW8U>
Cc: "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>, Alissa Cooper <alissa@cooperw.in>, "draft-ietf-insipid-session-id@ietf.org" <draft-ietf-insipid-session-id@ietf.org>, "insipid@ietf.org" <insipid@ietf.org>, The IESG <iesg@ietf.org>, "christer.holmberg@ericsson.com" <christer.holmberg@ericsson.com>
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: Wed, 17 Aug 2016 22:12:58 -0000

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

[...]

Thanks!

Ben.