Re: [Insipid] WG Review: INtermediary-safe SIP session ID (insipid)

SM <sm@resistor.net> Sun, 29 September 2013 18:40 UTC

Return-Path: <sm@resistor.net>
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 2E53F11E8101 for <insipid@ietfa.amsl.com>; Sun, 29 Sep 2013 11:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.613
X-Spam-Level:
X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+napkp5ceK3 for <insipid@ietfa.amsl.com>; Sun, 29 Sep 2013 11:40:30 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AF321F9DF7 for <insipid@ietf.org>; Sun, 29 Sep 2013 11:40:29 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8TIeLl3015289; Sun, 29 Sep 2013 11:40:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380480027; bh=BA1ho6QWgoGY1uelt4UQjm6FAielR1zW2Ay+Fi120CU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uqy+YUdgvjkm1rBFn+QMJMGbR1QZUT2IPbGIaCEUZj83D7477SzGqzfPCpsFJsXsY 5aqoJkF50HT17mB5J/92IA7z4EvceOEv+eviuGn8c+QxILh2eNQ5qEzEKD4X7mzymf t9rKCL96bTYAoBhAxZuMPIPnJJEnNbbIQlgPzSvI=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1380480027; i=@resistor.net; bh=BA1ho6QWgoGY1uelt4UQjm6FAielR1zW2Ay+Fi120CU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2UN9reLCtmdSajL/aVo7uzoyCkPdeIlG3hwlmoeCh2asQQH3mSwaaPw+lnyosERcR C0pLmt5I5KHlJgXUr3f/+HvgEgPGlazfT9kc3SC3BT+37fd3WCBUQ19d2SgL3O7HZD bRmfOGZo+kFZK3ABCRDsYN+P1QCQA68HChy6Qyk4=
Message-Id: <6.2.5.6.2.20130929064034.0c3bda30@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 29 Sep 2013 07:14:58 -0700
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
From: SM <sm@resistor.net>
In-Reply-To: <5248289C.6070003@ericsson.com>
References: <20130927160805.11230.12046.idtracker@ietfa.amsl.com> <5248289C.6070003@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Mailman-Approved-At: Sun, 29 Sep 2013 16:49:50 -0700
Cc: insipid@ietf.org
Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID (insipid)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sun, 29 Sep 2013 18:40:31 -0000

Hi Gonzalo,

Thanks for bringing this up.

At 06:18 29-09-2013, Gonzalo Camarillo wrote:
>note that as a result of this rechartering, the milestones will be the
>following:
>
>Dec 2012 Requirements and use cases for new identifier sent to IESG
>(as informational)
>
>Feb 2013 Specification of the new identifier sent to the IESG (PS)

The above milestones are in the past.  I suggest updating the dates 
if the work items are still due or removing them is they have already 
been delivered.

>On 27/09/2013 7:08 PM, The IESG wrote:
> > This group will focus on two documents:

The proposed charter discusses about two documents whereas there are 
four milestones.

> > The first document will specify a SIP identifier that has the same aim
> > as the From-tag, To-tag and Call-ID conjunction, but is less likely to
> > be mangled by intermediaries.  In doing this work, the group will pay
> > attention to the privacy implications of a "session ID", for example
> > considering the possibility to make it intractable for nodes to
> > correlate "session IDs" generated by the same user for different
> > sessions.

It is not clear whether the working group would have to pay attention 
to privacy implications for the last two work items.  Does the 
privacy implications cover the work items, wherever it is relevant, 
or examples of "session ID" only?

Is the privacy implications only about correlation?  I am asking the 
question as correlation is only one of the privacy-specific threats 
identified by the IAB?

Regards,
-sm