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(_at_)networkresonance(_dot_)com]
Sent: Friday, June 20, 2008 3:00 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Eric Rescorla; secdir(_at_)mit(_dot_)edu;
draft-ietf-geopriv-http-location-delivery(_at_)tools(_dot_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org;
iesg(_at_)ietf(_dot_)org; geopriv(_at_)ietf(_dot_)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(_at_)networkresonance(_dot_)com]
Sent: Saturday, May 24, 2008 9:01 PM
To: secdir(_at_)mit(_dot_)edu;
draft-ietf-geopriv-http-location-delivery(_at_)tools(_dot_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf