Re: [ipwave] MAC Address minor textual issue

John Kenney <jkenney@us.toyota-itc.com> Thu, 18 May 2017 15:41 UTC

Return-Path: <jkenney@us.toyota-itc.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207D0129C13 for <its@ietfa.amsl.com>; Thu, 18 May 2017 08:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.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 rWTBZ31pnbF8 for <its@ietfa.amsl.com>; Thu, 18 May 2017 08:41:49 -0700 (PDT)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 D438F129C1D for <its@ietf.org>; Thu, 18 May 2017 08:36:23 -0700 (PDT)
Received: by mail-wr0-x229.google.com with SMTP id l50so38233114wrc.3 for <its@ietf.org>; Thu, 18 May 2017 08:36:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KqzAJUtND5/27arkRqXsNUJQyDdQQxIQQnaC98+pDV4=; b=eUr3zFvMtTI0Uaz0u8FHVd6rGXZyXGQhFMvRSvslnIZ/fF7DD4eXdcQ7x+5IrriqcQ 71WR3p/t5gb8AfH9K+gHcgm4fwBGUTYvuPKPccfc/iKPtK0ycu5q8/ebaoZ26KSAbyFT T9jc5i4b7HZKmxEl8rymVvrEdWuMJ2AHYEnIdcx5xVLaktGq6kdWcz7zRAg5GJ7M2GvK EMj/Nkrk3Ozzt3CKfXugMUF8pTmtuqgZFKshrpcOJAue4wh2TDQ+lyBAXZ13frviamEC QVlQD8tsSWYCGWWhTRC1DwFZzkBrljc0lj5EL0Naabd3xkcgvsrKvXY6ECBbk/P2KaI/ BJ4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KqzAJUtND5/27arkRqXsNUJQyDdQQxIQQnaC98+pDV4=; b=HDONcKVGi43aZw78HfjlEILYLM6wEdUwBB53FcUGb01dTv05c6xyy2+P+Mc5QayvPT V0fxPfd+dWfxIWosiBrguOKCFKyDhZedUcMWsyYer0bKntTK1GJ0mBfbYMgD14QIOW/1 YyQoPsrsqdBDDa1KA2sd78ZbQSZcDYJNjHMYazNpqRsvzFs+rw+ThCPvXOOkaGRiQHrt kvZUVnKpeWbg5JPHcoEeSXrGIXHpej49sfv9Xxf1aCJLmCSbZDlr00PojVwSXBgcC2dX xjjGZb6/6U45VRgWrpWwqZIx5miY3xPaW3OAMsz2GfM/TmvEZiRHCUaM/uI8wrcqrSom qhWA==
X-Gm-Message-State: AODbwcB/Qz4/mqllXROr3ZdOO+dIRER4DsrOGYLEnDFnt0ea7B2a3uc7 R1NPo5PFi7cIXzy0l2IihHLTN/Gxi7o5
X-Received: by 10.223.170.74 with SMTP id q10mr3402940wrd.171.1495121782244; Thu, 18 May 2017 08:36:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.138.136 with HTTP; Thu, 18 May 2017 08:36:21 -0700 (PDT)
In-Reply-To: <846437B4-BE7D-4DF2-9C37-26D60180E82B@tony.li>
References: <b7d0f246-da90-ac56-db69-40e9e929900d@gmail.com> <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> <009601d2cfde$ad5abce0$081036a0$@eurecom.fr> <CAP6QOWQkSod0JxSdN9U+ztPwhLu0z35w-=O=WMQL1EOi_UzwpQ@mail.gmail.com> <846437B4-BE7D-4DF2-9C37-26D60180E82B@tony.li>
From: John Kenney <jkenney@us.toyota-itc.com>
Date: Thu, 18 May 2017 08:36:21 -0700
Message-ID: <CAP6QOWS06tqEAGShEYORnD-M0TtE+kA2YaZ6YfcS-H9kA=JvGA@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: Jérôme Härri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, Russ Housley <housley@vigilsec.com>, "its@ietf.org" <its@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1cda32ba1ad4054fce2a3a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/SToc_oqgkQzMtS3KaQSCw1SBkhw>
Subject: Re: [ipwave] MAC Address minor textual issue
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 May 2017 15:41:51 -0000

Hi Tony,

Frequent identifier changes are one component of the privacy protection
solution in DSRC. If IP is involved, I believe you are correct that IP
addressing would need to change in synchrony with other identifiers. That's
partly what I meant by "cross-layer and systemic." I don't know what the
technical challenges associated with that are, but I believe that is the
requirement where privacy needs to be protected.

You're right to have concerns, but these are technical concerns that stem
from privacy requirements, not privacy concerns. We have good solutions, so
I want to avoid saying there are "strong privacy concerns." We would not
deploy technology for which there were strong privacy concerns.

To use an analogy, it would be horrible if a plane crashed, but the people
flying on it need not have "strong concerns" that it will.  The plane was
designed, built, and maintained according to strong requirements to make
sure it doesn't crash.

Thanks,
John


On Thu, May 18, 2017 at 8:00 AM, Tony Li <tony.li@tony.li> wrote:

>
> On May 18, 2017, at 7:50 AM, John Kenney <jkenney@us.toyota-itc.com>
> wrote:
>
> I do not agree with the statement that "there are strong privacy
> concerns". I suggest changing "concerns" to "requirements".
>
> I think stating that there are strong concerns conveys a sense of this
> being a big unsolved problem. For the DSRC/ITS-G5 community this is not the
> case. Privacy protection, including careful avoidance of PII in messages,
> pseudonymous certificates, and frequent identifier randomization, has been
> designed into DSRC/ITS-G5 from day 1.
>
>
> Well, I for one am still mystified by how the solution maps to IP.  DSRC
> can do all of this work, but if my IP addressing doesn’t change in
> synchrony, it seems like it all doesn’t help. And if the IP addresses do
> change in synchrony, you abort upper layer TCP connections.
>
> So I’m still concerned.
>
> Tony
>
>


-- 
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644