Subject: [Geopriv] The 's' in HELD

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 29 Apr 2008 20:40:42 -0500

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
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Apr 2008 08:00:48 -0700

At Tue, 29 Apr 2008 20:40:42 -0500,
> states that URI schemes for protocols that use TLS have an extra 's'? 

No, there's no rule, but it's pretty much the convention.

-Ekr

---

From: Randall Gellens <[email-masked]>
Date: Wed, 30 Apr 2008 10:39:17 -0700

>  states that URI schemes for protocols that use TLS have an extra 's'?

My recollection is that the "referential integrity" concern regards 
using a specific scheme versus a generic scheme: with a specific 
scheme there is an explicit context that it is used to exchange 
location; with a generic one (such as 'http') this context is lost.

The 's' issue is really separate.  It was stated at the meeting that, 
because there was an initial TLS exchange, there needed to be the 
's', but this wasn't really discussed.

Personally, I see no need to have the 's', since the 's' convention 
differentiates between a protocol by itself, and the same protocol 
with an initial TLS exchange at the start.  Since there will always 
be an initial TLS exchange, there is no need for the 's', as there is 
nothing to differentiate against.

However, and again speaking personally, I can't see this as an issue 
worth fighting about :-)

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The Macintosh may only have 10% of the market, but it is clearly
the top 10%.
       --Douglas Adams, 1996 WWDC.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Wed, 30 Apr 2008 13:57:12 -0400

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 30 Apr 2008 15:00:40 -0400

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

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 30 Apr 2008 14:11:15 -0500

Richard,

I see your point, however, wouldn't we then want to define both "held:"
and "helds:"? That's been the approach of other protocols that I'm aware
of (e.g., SIP, MSRP, etc.).  

Mary. 

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2008 2:01 PM
To: Thomson, Martin
Cc: GEOPRIV; Barnes, Mary (RICH2:AR00)
Subject: Re: [Geopriv] The 's' in HELD

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

--Richard

Richard Barnes wrote:
> 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.
> 
>> 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.
>> immediately and delete the original.  Any unauthorized use of this 
>> email is prohibited.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 30 Apr 2008 15:27:27 -0400

Sure, that's fine with me.  As long as both options are supported.
--RB

Mary Barnes wrote:
>>> ---------------------------
>>> [mf2]
>>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 30 Apr 2008 18:23:06 -0500

Thanks all for the explanation, but that was all I was looking for.

Speaking about the proposed; I like the concept.  Flexibility and such a
small change...

I do wonder whether there is any potential for interoperability problems
if the same URI is used for both TLS and unadorned TCP sessions.  If
there's no real problem with mixing the two, then I'm all for the
change; otherwise, let's leave be and leave implementations to agree
(amoungst themselves) to use TLS_NULL_WITH_NULL_NULL if they want to.

Cheers,
Martin

p.s. The 's' smells bad, but I can live with worse (c.f.
emergencyRouting/emergencyDispatch).

> Sent: Thursday, 1 May 2008 5:27 AM
> To: Mary Barnes
> Cc: Thomson, Martin; GEOPRIV; Eric Rescorla
-------------------------------------------------------------------
-------------------------------------------------------------------