--Martin
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Hannes Tschofenig
> Sent: Friday, 30 July 2010 3:18 PM
> To: Richard L. Barnes
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] policy-uri
>
> As you see, the DHCP story is very weak.
> I am wonder who wants to deploy it.
>
> On 30.07.2010 15:13, Richard L. Barnes wrote:
> > If the DHCP server is providing the same information to everybody --
> > effectively providing a value by reference -- then there's no reason
> > to have a policy URI. You just wouldn't do it.
> >
> > Adding a policy URI does introduce another attack vector. However,
> if
> > the client doesn't trust the local network to be secure enough, he
> can
> > always irrevocably kill the URI by sending a DELETE request.
> >
> > --Richard
> >
> >
> >
> >
> >
> > On Jul 30, 2010, at 2:50 PM, Hannes Tschofenig wrote:
> >
> >> Hi Richard,
> >>
> >> I have my doubts that this mechanism gets used for the DHCP based
> >> solution.
> >>
> >> DHCP does not provide confidentiality protection as a built-in
> >> feature. As Marc mentioned in response to issue#23 (see
> >> http://trac.tools.ietf.org/wg/geopriv/trac/ticket/23) I raised every
> >> target would be given the exact same location information on a
> shared
> >> medium. So, this is draft-ietf-geopriv-rfc3825bis.
> >>
> >> Note: The draft that was forwarded to the IESG does not point out
> >> this important security aspect, I believe.
> >>
> >> If you don't make the same assumption for the DHCP-URI draft then
> you
> >> suddenly allow others to modify your policies. This would be really
> bad.
> >>
> >> If you make the assumption that everyone on a shared medium gets the
> >> same pointer to location and also pointer to policy then you still
> >> allow others to modify the policy but there is at least no privacy
> >> harm with revealing location but rather denial of service.
> >>
> >> Ciao
> >> Hannes
> >>
> >> On 30.07.2010 14:23, Richard L. Barnes wrote:
> >>> Simplicity: This document does everything that HELD-Context does
> >>> (except for <snapshot>), without requiring any new XML. (And
> >>> <snapshot> should be a policy extension, anyway.)
> >>>
> >>> Generality: This document is not specific to HELD, so that, e.g.,
> it
> >>> can be used with DHCP.
> >>>
> >>>
> >>>
> >>> On Jul 30, 2010, at 2:07 PM, Hannes Tschofenig wrote:
> >>>
> >>>> Why not use the existing HELD Context document?
> >>>>
> >>>>
> >>>> On 30.07.2010 14:05, Richard L. Barnes wrote:
> >>>>> The only concern raised in the meeting with regard to
> >>>>> draft-barnes-geopriv-policy-uri was when Hannes noted that the
> >>>>> exchange could be made more efficient (in the HELD context)
> >>>>> overlaying the policy interactions on a HELD transaction. For
> >>>>> example, the client could provide policy data in a
> >>>>> <locationRequest> object, and the server could specify policy it
> >>>>> intends to use in the <locationResponse>. I think we should not
> >>>>> do this.
> >>>>
> >>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
