Subject: [Geopriv] Proposed way forward for HELD

From: "Mary Barnes" <[email-masked]>
Date: Wed, 30 Jul 2008 04:17:54 -0500

Hi all,

We had some offline discussions last week as to how best address the
sec-dir (and gen-art) concerns on the latest version of HELD.  I will be
updating the document sometime next week or early the following week
after I get back from IETF and a quick trip to Seattle. Thus, feedback
within the next week would be optimal.  The following summarizes the
proposed way forward: 

1. Move URI schema for lbyr into dereference document and describe the
lbyr (locationURI in the protocol) as being anyURI and the dereferencing
of such is out of scope for this document and include an informational
reference to the dereference document as one such mechanism.  Note that
this was the suggestion I made on the list in response to "Round 2"
thread discussions.  In one sense this reverts the text to what it was
before we added any HELD specific URI schemas at all. 

2. Add the URI schema for LIS discovery back into this document. 

3. Mandate TLS for HELD, thus we will not be defining either held: or
heldref: URI schemas. (Note: this is also reverting back to where we'd
been in the past). 

Note that these are not small changes and will impact quite a few
sections of the doc. But, in the end, things should be much clearer and
cleaner in terms of dependencies. 

I will also be addressing a few other issues that have come up during
this IETF LC timeframe:
1. Update the schema to force people to include at least one location
type. (Thanks Martin T.!)
2. Eric Rescorla's most recent feedback based on my responses on the
-08: 
http://www.ietf.org/mail-archive/web/geopriv/current/msg05962.html
3. Martin's most recent comments (note some of those points aren't
relevant based on proprosed changes above):
http://www.ietf.org/mail-archive/web/geopriv/current/msg05900.html

Regards,
Mary. 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Wed, 30 Jul 2008 10:52:31 +0100

Mary,

Thanks for keeping on top of this.  I agree that 1 and 2 are the right 
thing to do in terms of URI schemes.  I still think that this document 
should follow the usual pattern of making TLS a "MUST implement, SHOULD 
use", for a few reasons:

A. Optional TLS keeps the base case simple
It maintains the simplicity of HELD in situations where security is not 
an issue.  The HELD experiments we've run at the last couple of IETFs 
would not have been possible if we had to set up the certificate 
infrastructure necessary to support TLS.

B. Mandatory TLS doesn't help the security story
Mandating TLS doesn't improve the security story at all, since anyone 
who cares about security can use it anyway.  All you have to say in the 
document is that the protocol has the required security properties when 
TLS is used.

C. Mandatory TLS isn't realistic
HELD is going to be used without TLS anyway, e.g., when the endpoint and 
the LIS only talk over a private network (even if this network is part 
of the Internet).  To specify that TLS MUST be used just ignores that 
this will happen.

D. Mandatory TLS will hinder interoperability
In order to support non-TLS usage of HELD, some folks will build 
implementations that do HELD as well as HELDS.  These HELD 
implementations will have to figure out a way to work with HELDS-only 
clients.

Thanks,
--Richard

---

From: Andrew Newton <[email-masked]>
Date: Thu, 31 Jul 2008 09:24:36 -0400

Richard,

Regretfully, I disagree.

On Jul 30, 2008, at 5:52 AM, Richard Barnes wrote:

> It maintains the simplicity of HELD in situations where security is  
> not an issue.  The HELD experiments we've run at the last couple of  
> IETFs would not have been possible if we had to set up the  
> certificate infrastructure necessary to support TLS.

The reverse is actually true: optional TLS makes things more  
complicated.  When TLS is optional, there must be some negotiation for  
its use, either via some port arbitration or a STARTTLS mechanism.  It  
also means the possibility of listening on multiple ports... etc.

> Mandating TLS doesn't improve the security story at all, since  
> anyone who cares about security can use it anyway.  All you have to  
> say in the document is that the protocol has the required security  
> properties when TLS is used.

I don't understand this statement, unless it is one of those "gun laws  
just stop non-criminals from buying guns" arguments.

> HELD is going to be used without TLS anyway, e.g., when the endpoint  
> and the LIS only talk over a private network (even if this network  
> is part of the Internet).  To specify that TLS MUST be used just  
> ignores that this will happen.

If we were talking about a heavily deployed protocol with many, many  
implementations, I'd agree with you.  But we are not.  Nobody can say  
for certain what will happen.

> implementations will have to figure out a way to work with HELDS- 
> only clients.

Doesn't this actually speak against your first point?

-andy