Re: [Geopriv] The 's' in HELD

Richard Barnes <rbarnes@bbn.com> Wed, 30 April 2008 19:01 UTC

Return-Path: <geopriv-bounces@ietf.org>
X-Original-To: geopriv-archive@megatron.ietf.org
Delivered-To: ietfarch-geopriv-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB63E3A6D0C; Wed, 30 Apr 2008 12:01:07 -0700 (PDT)
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101FE3A6CB7 for <geopriv@core3.amsl.com>; Wed, 30 Apr 2008 12:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.849
X-Spam-Level:
X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, GB_I_LETTER=-2]
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 3eiLbtQ4rZ0m for <geopriv@core3.amsl.com>; Wed, 30 Apr 2008 12:01:06 -0700 (PDT)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 119363A6A3F for <geopriv@ietf.org>; Wed, 30 Apr 2008 12:00:49 -0700 (PDT)
Received: from col-dhcp33-244-159.bbn.com ([128.33.244.159] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <rbarnes@bbn.com>) id 1JrHXt-0007r9-3t; Wed, 30 Apr 2008 15:00:49 -0400
Message-ID: <4818C1D8.50005@bbn.com>
Date: Wed, 30 Apr 2008 15:00:40 -0400
From: Richard Barnes <rbarnes@bbn.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
References: <E51D5B15BFDEFD448F90BDD17D41CFF10441BD76@AHQEX1.andrew.com> <4818B2F8.6090506@bbn.com>
In-Reply-To: <4818B2F8.6090506@bbn.com>
Cc: GEOPRIV <geopriv@ietf.org>, Mary Barnes <mary.barnes@nortel.com>
Subject: Re: [Geopriv] The 's' in HELD
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

I've gotten a note off-list that indicates a need to clarify this comment:

My impression is that the document as it is does not require TLS be 
*used* on every transaction (which is the implication that led to 
HELDS), just that it be *available* for every transaction.  I think the 
confusion is founded in the below text from Section 9:

    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.

You can read that paragraph in either way (implement/use): The first 
sentence says that TLS is a "MUST implement" (not a "MUST use"), but the 
third sentence implies that the server MUST use TLS to authenticate.

There's no mandate for TLS to be used in the security considerations, 
only supported by implementations.  The mandates in the security 
considerations are in the form "IF you want this security property, THEN 
use TLS", the usual MO in IETF docs.

Am I understanding the document correctly, or is there some other 
section that specifies that TLS MUST be used on every transaction.

If TLS is not required, then here are some proposed (minor) changes:
1. Add "When TLS is used, ..." to the third sentence in the above 
paragraph, in order to clarify that the requirement is not absolute.
2. Change the "HELDS" URI scheme back to "HELD"

--Richard







Richard Barnes wrote:
> Is TLS really used for every HELD transaction, as opposed to being 
> available for every transaction?  This seems to be a deviation from the 
> normal pattern for Internet protocols to have a base protocol without 
> TLS and an (mandatory) option to use TLS as desired.  More importantly, 
> it seems like TLS might be undesirable in some circumstances, e.g., 
> emergency calling.
> 
> Is there a reason for this extra-strong requirement?
> 
> --RB
> 
> 
> 
> Thomson, Martin wrote:
>> I missed this in the changes for -06.  Please forgive my ignorance, but
>> I wasn't there at -71 and it appears that only the conclusion was
>> captured, not the rationale.  The minutes focus on whether there should
>> be a URI scheme or not, but make what seems (to me) to be a logical
>> leap:
>>
>>           Question: Does this HELD: scheme require TLS? Ans: Yes. Then
>> it needs
>>           to be a HELDS: scheme.
>>
>> I don't believe that the letter 's' addresses "concerns over referential
>> integrity" as stated by the held-06 change-log.  So can anyone justify
>> the above statement?  Is there some IETF guideline I don't know of that
>> states that URI schemes for protocols that use TLS have an extra 's'? 
>>
>> Cheers,
>> Martin 
>>
>> ------------------------------------------------------------------------------------------------
>> This message is for the designated recipient only and may
>> contain privileged, proprietary, or otherwise private information.  
>> If you have received it in error, please notify the sender
>> immediately and delete the original.  Any unauthorized use of
>> this email is prohibited.
>> ------------------------------------------------------------------------------------------------
>> [mf2]
>>
>> _______________________________________________
>> 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
> 
> 

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv