Re: [VIPR] VIPR privacy issue

Marc Petit-Huguenin <petithug@acm.org> Mon, 06 February 2012 14:51 UTC

Return-Path: <petithug@acm.org>
X-Original-To: vipr@ietfa.amsl.com
Delivered-To: vipr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B2921F85F0 for <vipr@ietfa.amsl.com>; Mon, 6 Feb 2012 06:51:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.313
X-Spam-Level:
X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 5CsmNLOI-uYv for <vipr@ietfa.amsl.com>; Mon, 6 Feb 2012 06:51:09 -0800 (PST)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 2114421F85DD for <vipr@ietf.org>; Mon, 6 Feb 2012 06:51:09 -0800 (PST)
Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6C06920142; Mon, 6 Feb 2012 14:36:07 +0000 (UTC)
Message-ID: <4F2FE8D8.7000804@acm.org>
Date: Mon, 06 Feb 2012 06:51:04 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0
MIME-Version: 1.0
To: Cullen Jennings <fluffy@iii.ca>
References: <4F1F1A42.1030201@acm.org> <9734F726-C0A8-42D6-87A4-65535D5F3E80@bbn.com> <4F217CC9.4080802@acm.org> <50D0BC87-EC6C-401E-A2F9-A05AC60D5EF0@bbn.com> <4F2183D0.3070809@acm.org> <373FB643-AE7A-473C-A7AB-09F9A9E7093B@bbn.com> <4F21A121.10403@acm.org> <5466D9E6-3859-41A7-9A54-D23DC6D775C6@iii.ca> <E9DCDEA3-5BDC-41E6-B2BE-606E4CCE4F1B@bbn.com> <00A1AC3E-167F-4243-9F1B-345AC99D2409@softarmor.com> <E0A81E2A-6E9C-4D83-9478-C54C21761C86@iii.ca>
In-Reply-To: <E0A81E2A-6E9C-4D83-9478-C54C21761C86@iii.ca>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "vipr@ietf.org" <vipr@ietf.org>, Dean Willis <dean.willis@softarmor.com>
Subject: Re: [VIPR] VIPR privacy issue
X-BeenThere: vipr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Verification Involving PSTN Reachability working group <vipr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vipr>, <mailto:vipr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vipr>
List-Post: <mailto:vipr@ietf.org>
List-Help: <mailto:vipr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vipr>, <mailto:vipr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Feb 2012 14:51:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/05/2012 08:57 PM, Cullen Jennings wrote:
> 
> Just as an idle question that I have not thought about much ... how does
> this attack change if you assume the VIPR server and SIP edge element for a
> domain are running on an Amazon EC2 node?

It does not matter for the SIP edge element, as SIP is used only after a
successful PVP transaction, which is not the case we are concerned with here.

For the VIPR server (i.e. RELOAD and PVP), running it on an EC2 node
effectively anonymizes the source IP address, as if a TURN server was used.

Note that even in this case, the certificate of the signer of the AppAttachReq
RELOAD message is leaked, which may contain sensible information in the
Subject or subjectAltName.

But my main concern is that protecting privacy using this method requires a
action from the VIPR domain to make sure that the IP address used cannot be
resolved back to them.  A small number of domains will care, but the vast
majority will not.  I think that privacy has a better chance if the mechanism
does not depends on the actions of individual domains, like always using a
TURN server or adding onion routing in RELOAD.

This still does not fix the certificate leak but one way to fix it could be to
use a Traceable Anonymous Certificate (RFC 5636), which would provide the
right amount of privacy while still permitting to blacklist a domain that
abused its anonymity.

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPL+jWAAoJECnERZXWan7EswYQAL9VPeCEEqUFfKWRbuVvi0XP
pkRL+rhiC62FKf1Y6CqlSYKJczUchCPniTsl1a8/m0XbAtXE0CR+s7BhuZLsy3ZB
IrJYWqIgWu3SY47W2r/kGcvo0hYiZ40CPBdTwPtwJPYeCvoCK/rMpHDWTdQRv1Mv
YG+mO3jVKhSeAWYLHs4piA9JhMRhI546m4GJ6qaL5lqu1CaG0DEVIrcUKr4OL7R0
9vHSL1wsxmdFz9rVgGC7Booq68JCgHXGTtZ+mN3fBUhQEeawkd9UXNmgVeAURNoI
BdcBL7QQx6nGmMJke37Dll0Mz/Zvy2rjmtcC31y8YlwSYvS9g+aoBZUYqU7UJMaR
Brt3fg01qdECuOa6ekS2nS/xgogxh/yKGFI6u2Kvx8y+YuNLZGfu+EB2rNm+M5kb
vAUQ9ZSK4SlR51V1f7lwGQb2T/5Ou/lazyJ9FWte9ToU5HYQsUlxQrN715/QmkUN
fJ7EA3Ywyg+sBgWDKuJKY1pD0Shn7C3Wr5xKZXqOUZos/VGFR8eYMwpLS0jCPFie
bFFgO96WCxsxcKlf9at3Keei/3OO7DGZNrUWjIv8bnrJ7/lEbiw9X98fcUslJxHl
U151sAETS6wvNg8yff4oK4tQx4tZVcOjW7DKqqj9ymJ7yvAsb28A/rLXDtiNWUX0
rs5oOJP0O9fAMxqnGRUS
=vnpL
-----END PGP SIGNATURE-----