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

Paul Giralt <pgiralt@cisco.com> Thu, 18 August 2016 00:18 UTC

Return-Path: <pgiralt@cisco.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 414C512B03F; Wed, 17 Aug 2016 17:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Level:
X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 sp_gEGxBBuHy; Wed, 17 Aug 2016 17:18:19 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957E212D5CA; Wed, 17 Aug 2016 17:18:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4837; q=dns/txt; s=iport; t=1471479499; x=1472689099; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=bWEfpTrx/4SZHQXal+5EdcJk2F95sVsBqysm8HOvGGM=; b=am08INCC9BCP5F5aVVwIesKnPLgvoNExVK/B/Qpd9bf/2LGROw1fFSyK yzsBY/wD02R/vw5um7ArUQIGZtUbt52B6Ysx+F37N6RB0MP1maKyf4mry mb12m/B1opoXfxEPASuEk8x5UdhIfU1UWIxduBkR8jYXu6yIZroTgZKbR I=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CIAgCS/rRX/5hdJa1eg0SBUrVMgg+Bf?= =?us-ascii?q?YYdAoFqOBQCAQEBAQEBAV4nhF4BAQQBI0URBQsLGCoCAlcGCgmIKQita5AXAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARAOhiqBeAiCTYdBK4IvAQSZRIM+i2CPSYw7g3geN?= =?us-ascii?q?oISHBeBUSAyhy0BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,536,1464652800"; d="asc'?scan'208";a="136710871"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2016 00:18:17 +0000
Received: from rtp-vpn6-823.cisco.com (rtp-vpn6-823.cisco.com [10.82.251.58]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7I0IFLW030044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Aug 2016 00:18:16 GMT
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_95E0A7A2-4F5E-464B-B97B-7C98FEC879C7"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Paul Giralt <pgiralt@cisco.com>
In-Reply-To: <F3B208D2-0C38-42A1-B6EA-35D9D46DBBF1@nostrum.com>
Date: Wed, 17 Aug 2016 20:18:11 -0400
Message-Id: <5FAD7996-7E41-4612-9A13-2ACFED396085@cisco.com>
References: <147135877745.22972.7550246068971515295.idtracker@ietfa.amsl.com> <2377966D-0E2D-4C90-806A-8F82D8C2C33C@cisco.com> <F3B208D2-0C38-42A1-B6EA-35D9D46DBBF1@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/7e8xO2tfbd-LbOTFK-PywUFq2w8>
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: Thu, 18 Aug 2016 00:18:21 -0000

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