Re: [Geopriv] Please note: Re: I-D Action: draft-ietf-geopriv-deref-protocol-06.txt

["Richard L. Barnes" <[e-mail]>]

Ok, it seems the winds are against me today.  I'll give Stephen his "only" :)

NEW:
"
The scheme of a location URI determines whether or not TLS is used on a given dereference transaction.  Location Servers MUST be configured to issue only HTTPS URIs and respond to only to HTTPS dereference requests, unless confidentiality and integrity protection are provided by some other mechanism.  For example, the server might only accept requests from clients within a trusted network, or via an IPsec-protected channel. 
"





On Jul 13, 2012, at 2:24 PM, Martin Thomson wrote:

> The text that you propose contains the same escape clause, which is
> either sufficient for this, or not.  That is, "unless confidentiality
> and integrity protection are provided by some other mechanism".
> 
> If the "other mechanism" is unicorns and fairies, as long as the
> people deploying are OK with that, then the letter and spirit of the
> language is adhered to.  We all sleep soundly at night knowing that
> the fairy princess and her noble unicorn mount are defending our
> location privacy.
> 
> I think that you might need to provide a stronger case for the weaker
> security you advocate.
> 
> --Martin
> 
> On 13 July 2012 09:37, Richard L. Barnes <[e-mail]> wrote:
>> Thanks, Martin.
>> 
>> The reason I'm cautious about the "only respond over HTTPS" suggested by Robert is that it seems to me to disallow the redirect case.  Even though the redirect case does have the vulnerability that you point out, it can be a fail-safe in case an HTTPS URI gets transposed to an HTTP URI.
>> 
>> But if we don't say "only respond over HTTPS", then we need to clarify that you shouldn't actually do a dereference over HTTP, just ancillary stuff like redirects.
>> 
>> 
>> 
>> 
>> On Jul 13, 2012, at 12:16 PM, Martin Thomson wrote:
>> 
>>> This is more explicit text, which makes things a lot clearer.  In
>>> particular, I like the point that it is the choice of the server to
>>> choose an http: URI.
>>> 
>>> I don't see the need for your more recent additions, which implies
>>> permission to do these things.  When redirects from HTTP are
>>> encouraged (though I hardly think that is your intent, that's how it
>>> appears to me), this offers an attacker the opportunity to change the
>>> URI target.  I'd rather just drop any statements of that sort.  I
>>> prefer your original suggestion, with the edits implied by Robert.
>>> 
>>> --Martin
>>> 
>>> On 13 July 2012 09:05, Richard L. Barnes <[e-mail]> wrote:
>>>> I don't think we want to preclude HTTP entirely.  For example, a LIS might want to use HTTP to redirect clients to HTTPS if they decide to try going non-secure.  But obviously, it shouldn't send location in HTTPS unless alternative protections are in place.
>>>> 
>>>> NEW:
>>>> "
>>>> The scheme of a location URI determines whether or not TLS is used on a given dereference transaction.  Location Servers MUST be configured to issue only HTTPS URIs and respond to only to HTTPS dereference request, unless confidentiality and integrity protection are provided by some other mechanism.  For example, the server might only accept requests from clients within a trusted network, or via an IPsec-protected channel.  Location Servers MAY respond to dereference requests over HTTP, but MUST NOT provide location information over HTTP unless alternative protections are in place.  HTTP should only be used for ancillary functions, such as redirecting clients toward HTTPS URIs.  Dereference clients MUST support dereference of HTTPS URIs and SHOULD support dereference of HTTP URIs.
>>>> "
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Jul 13, 2012, at 10:30 AM, Robert Sparks wrote:
>>>> 
>>>>> Hi Richard.
>>>>> 
>>>>> Where you say "be configure to" and "respond to", do you mean "be configured to only" and "respond only to"?
>>>>> 
>>>>> RjS
>>>>> 
>>>>> On 7/12/12 2:35 PM, Richard L. Barnes wrote:
>>>>>> <hat type="individual"/>
>>>>>> 
>>>>>> I would prefer that this text make a little clearer which entities in the protocol are required to do something and when.
>>>>>> 
>>>>>> OLD:
>>>>>> "
>>>>>> TLS SHOULD be used.
>>>>>> "
>>>>>> 
>>>>>> NEW:
>>>>>> "
>>>>>> The scheme of a location URI determines whether or not TLS is used on a given dereference transaction.  Location Servers MUST be configured to issue HTTPS URIs and respond to HTTPS dereference request, unless confidentiality and integrity protection are provided by some other mechanism.  For example, the server might only accept requests from clients within a trusted network, or via an IPsec-protected channel.  Dereference clients MUST support dereference of HTTPS URIs and SHOULD support dereference of HTTP URIs.
>>>>>> "
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Jul 12, 2012, at 2:15 PM, Robert Sparks wrote:
>>>>>> 
>>>>>>> This revision addressed all the points from IESG review.
>>>>>>> 
>>>>>>> Notably, it contained a clarification to when TLS is required:
>>>>>>> 
>>>>>>> OLD:
>>>>>>> TLS SHOULD be used.
>>>>>>> 
>>>>>>> NEW:
>>>>>>>  TLS MUST be used unless confidentiality and integrity are provided by
>>>>>>>  some other mechanism, such as IPsec or a fully trusted network.
>>>>>>>  Without a reliable assertion that a mechanism is in place, such as
>>>>>>>  through configuration or user override, then TLS MUST be used.
>>>>>>> 
>>>>>>> If you have a concern with this change, please let me know ASAP.
>>>>>>> If I haven't heard anything I'll approve the document towards the end of next week.
>>>>>>> 
>>>>>>> RjS
>>>>>>> On 7/11/12 6:13 PM, [e-mail] wrote:
>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>>>>> This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.
>>>>>>>> 
>>>>>>>>  Title           : A Location Dereferencing Protocol Using HELD
>>>>>>>>  Author(s)       : James Winterbottom
>>>>>>>>                         Hannes Tschofenig
>>>>>>>>                         Henning Schulzrinne
>>>>>>>>                         Martin Thomson
>>>>>>>>  Filename        : draft-ietf-geopriv-deref-protocol-06.txt
>>>>>>>>  Pages           : 23
>>>>>>>>  Date            : 2012-07-11
>>>>>>>> 
>>>>>>>> Abstract:
>>>>>>>>  This document describes how to use the Hypertext Transfer Protocol
>>>>>>>>  (HTTP) over Transport Layer Security (TLS) as a dereferencing
>>>>>>>>  protocol to resolve a reference to a Presence Information Data Format
>>>>>>>>  Location Object (PIDF-LO).  The document assumes that a Location
>>>>>>>>  Recipient possesses a URI that can be used in conjunction with the
>>>>>>>>  HTTP-Enabled Location Delivery (HELD) protocol to request the
>>>>>>>>  location of the Target.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>>> 
>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-geopriv-deref-protocol
>>>>>>>> 
>>>>>>>> 
>>>>>>>> There's also a htmlized version available at:
>>>>>>>> 
>>>>>>>> http://tools.ietf.org/html/draft-ietf-geopriv-deref-protocol-06
>>>>>>>> 
>>>>>>>> 
>>>>>>>> A diff from previous version is available at:
>>>>>>>> 
>>>>>>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-deref-protocol-06
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>>> 
>>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Geopriv mailing list
>>>>>>>> 
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Geopriv mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> Geopriv mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>