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

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

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
> 
>