RE: Review of draft-ietf-geopriv-http-location-delivery-07

"Mary Barnes" <mary.barnes@nortel.com> Mon, 14 July 2008 16:11 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9AEB28C1EA; Mon, 14 Jul 2008 09:11:34 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6A93A6A75; Thu, 10 Jul 2008 12:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.143
X-Spam-Level:
X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS3hkd8Y-6e3; Thu, 10 Jul 2008 12:08:27 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A43843A6A58; Thu, 10 Jul 2008 12:07:16 -0700 (PDT)
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6AJ7Bh09228; Thu, 10 Jul 2008 19:07:11 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Review of draft-ietf-geopriv-http-location-delivery-07
Date: Thu, 10 Jul 2008 14:04:38 -0500
Message-ID: <F66D7286825402429571678A16C2F5EE04522E99@zrc2hxm1.corp.nortel.com>
In-Reply-To: <20080620195947.29D0B5081A@romeo.rtfm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-geopriv-http-location-delivery-07
Thread-Index: AcjTDz0Btg36b9AWTxeiRbcUtyqVPQPrR2zQ
References: <20080525020040.4DE5A5081A@romeo.rtfm.com> <F66D7286825402429571678A16C2F5EE03ADF950@zrc2hxm1.corp.nortel.com> <20080620195947.29D0B5081A@romeo.rtfm.com>
From: Mary Barnes <mary.barnes@nortel.com>
To: Eric Rescorla <ekr@networkresonance.com>
X-Mailman-Approved-At: Mon, 14 Jul 2008 09:11:34 -0700
Cc: draft-ietf-geopriv-http-location-delivery@tools.ietf.org, geopriv@ietf.org, secdir@mit.edu, ietf@ietf.org, iesg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Eric,

I've snipped the thread to just include the issues (3 total) that I'm
uncertain as to whether they've been adequately addressed in the -08:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-del
ivery-08.txt


Thanks,
Mary. 

-----Original Message-----
From: Eric Rescorla [mailto:ekr@networkresonance.com] 
Sent: Friday, June 20, 2008 3:00 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Eric Rescorla; secdir@mit.edu;
draft-ietf-geopriv-http-location-delivery@tools.ietf.org; ietf@ietf.org;
iesg@ietf.org; geopriv@ietf.org
Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07

At Thu, 29 May 2008 07:51:02 -0500,
Mary Barnes wrote:
> 
> Hi Eric,
> 
> Thanks for you review and comments.  My responses are embedded below 
> [MB].
> 
> Mary. 
> 
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com]
> Sent: Saturday, May 24, 2008 9:01 PM
> To: secdir@mit.edu;
> draft-ietf-geopriv-http-location-delivery@tools.ietf.org
> Cc: ietf@ietf.org; iesg@ietf.org
> Subject: Review of draft-ietf-geopriv-http-location-delivery-07
> 
> $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1
> 2008/05/24 15:03:19 ekr Exp $
> 
> TECHNICAL
> 
> 
---snipped------
> S 6.5.1.
> 
>    A "locationURI" SHOULD NOT contain any information that could be
used
>    to identify the Device or Target.  Thus, it is RECOMMENDED that the
>    "locationURI" element contain a public address for the LIS and an
>    anonymous identifier, such as a local identifier or unlinked
>    pseudonym.
> 
> 1. This seems like it should be clearer about what is desired.
>    In particular it's not just "identify" but also "link".
>    Also this needs to be clarified to indicate the implications
>    of idetntifiction by position.
> 
> 2. Shouldn't this be MUST strength?
> 
> [MB] This isn't a MUST strength because we had WG discussion/consensus

> that we can't mandate LIS behavior. We can make recommendations, but a

> LIS may not necessarily follow them.  I'm not entirely clear on your 
> first point as far as "identification by position".  [/MB]

I mean that knowing where someone is with high enough resolution gives a
lot of information about their identity. For instance, if you know that
someone is at the AP associated with my house, it seems pretty likely
it's me.

[MB] But, the identifier doesn't necessarily indicate who the "someone"
is. My contrarian example would be my kids are using my home network and
I'm in Dublin. How would you know who specifically this location might
be associated with?  I agree it certainly could.  There was a comment on
the list yesterday related to this:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05895.html
So, would changing the text to align with Martin's response be adequate,
something like the following:
OLD:
  Thus, it is RECOMMENDED that the
  "locationURI" element contain a public address for the LIS and an
  anonymous identifier, such as a local identifier or unlinked
  pseudonym.

NEW:
  Thus, it is RECOMMENDED that the
  "locationURI" element contain an address that provides indirect access
to the LIS to  
  avoid inadvertently revealing a location that could be associated with
a Device. Also, an
  anonymous identifier is RECOMMENDED, such as a local identifier or
unlinked pseudonym. 
  
[/MB]

--snipped--

> Is this MUST implement or MUST use? Don't the next two sentences
> imply MUST use?
> 
> [MB] Per the thread above, that text does need some clarification for
> consistency. It should be
>      MUST "implement" and not MUST "use", so I would propose the
> following change:
> OLD:
>    The implementation of HTTP as a transport mechanism MUST implement
>    TLS as described in [RFC2818].  TLS provides message integrity and
>    privacy between Device and LIS.  The LIS MUST use the server
>    authentication method described in [RFC2818]; the Device MUST fail
a
>    request if server authentication fails, except in the event of an
>    emergency.
> NEW:
>    The implementation of HTTP as a transport mechanism MUST implement
>    TLS as described in [RFC2818].  TLS provides message integrity and
>    privacy between Device and LIS. 

privacy->confidentiality. Also, only if the right cipher suiotes
are used.

[MB] It wasn't clear to me what you were suggested we add in terms of
cipher suites.
Do you just want that general statement or were you thinking of specific
cipher suites that would be appropriate for this application? [/MB]


---snipped----

> S 10.3.
>    o  The network SHOULD have mechanisms that protect against IP
address
>       spoofing, such as those defined in [RFC3704].
> 
> Is this WG really in a position to levy a SHOULD level requirement
> for network ingress filtering? Recall that this is really a global
level
> technology. Or do you mean something else?
> 
> [MB] Per Richard's response on this thread, the IP address spoofing
> recommendation is due to HELD using the devices IP address as the
> identifier for the device. In this case it is important to have a
> recommendation for IP address spoofing. I think the paragraph prior to
> those bullets appropriately qualifies the context of that
> recommendation. 
> [/MB]

I can't say I really agree with this assertion about the qualification.
This still looks to me like a general levy on the access network.

[MB] I'm not certain of the concern here.  Doesn't the "SHOULD" account
for networks that have other mechanisms, thus this isn't an across the
board levy.  Or is your concern that we don't have the should not
situations identified? [/MB]

-Ekr
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf