Subject: Re: [Geopriv] Proposed way forward for HELD

From: Richard Barnes <[email-masked]>
Date: Tue, 05 Aug 2008 13:03:06 -0400

Hey Andy,

> Regretfully, I disagree.

I regret that you disagree, too. :)

>> A. Optional TLS keeps the base case simple
> 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.

Like I said, it keeps the *base* case simple: In the case where everyone 
just does HTTP, you save all the expense of crypto, key management, etc. 
  This allows simple deployments, like our experiment in the IETF 
network, to work simply.

You're right that there is some minor additional complexity involved in 
negotiating, but that's easy to solve.  Hasn't been a show-stopper for 
HTTP/HTTPS, SIP/SIPS, etc.

>> B. Mandatory TLS doesn't help the security story
> I don't understand this statement, unless it is one of those "gun laws 
> just stop non-criminals from buying guns" arguments.

The statement here is that if TLS is available (i.e., MUST implement), 
then entities that want security can use it.  That is, MUST implement 
gives all the security that's required.

The only incremental difference from making it a MUST use is that 
entities that *don't* require security properties are also required to 
use it.  That's neither necessary nor useful.

>> C. Mandatory TLS isn't realistic
> 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.

What I'm saying here is basically a variation on my response to B. 
above: All a "MUST use" requirement does is require people that don't 
want security use security features.  In practice, people don't abide by 
requirements of that form.

>> D. Mandatory TLS will hinder interoperability
> Doesn't this actually speak against your first point?

No, in the following sense: If we admit that both HTTP and HTTPS will be 
used for transport, then we can define a sane, interoperable negotiation 
mechanism (as you suggest above).  If we don't allow that HTTP will be 
used, and don't define a negotiation mechanism, then one will need to be 
invented later if/when people do decide to use HTTP.

--Richard

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 5 Aug 2008 19:15:41 -0500

I think that we can agree that none of what is documented in a specification is going to prevent people from doing what they like.  The argument is to whether we (GEOPRIV/IETF) are going to facilitate those uses.

What is being said by "MUST use" is that anyone who doesn't want it needs to negotiate and agree to use the unsecured variant.  My view is that a specification for this negotiation mechanism is not needed.  The form of negotiation we used for the demonstration was exactly the form of negotiation I see as being useful.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Barnes
> Sent: Wednesday, 6 August 2008 3:03 AM
> To: Andrew Newton
> Cc: GEOPRIV; Mary Barnes
> Subject: Re: [Geopriv] Proposed way forward for HELD
> 
> Hey Andy,
> 
> > Regretfully, I disagree.
> 

------------------------------------------------------------------------------------------------
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: Tue, 05 Aug 2008 17:42:58 -0700

At Tue, 5 Aug 2008 19:15:41 -0500,
Thomson, Martin wrote:
> 
> I think that we can agree that none of what is documented in a
> specification is going to prevent people from doing what they like.
> The argument is to whether we (GEOPRIV/IETF) are going to facilitate
> those uses.
> 
> What is being said by "MUST use" is that anyone who doesn't want it
> needs to negotiate and agree to use the unsecured variant.  My view
> is that a specification for this negotiation mechanism is not
> needed.  The form of negotiation we used for the demonstration was
> exactly the form of negotiation I see as being useful.

That is not how I would interpret "MUST use". Rather, I would
interpret "MUST use X" as "if you don't use X, you're noncompliant".
Moreover a compliant implementation MUST refuse to communicate
without using X. What you describe I would call "MUST support".

With regard to the topic of negotiation, negotiationg the use or
non-use of secured variants is tricky. I'm not sure what negotiation
you used for the demonstration, so I can't tell you whether it
will work or not.

-Ekr

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 5 Aug 2008 20:55:16 -0500

I think that we are talking "MUST use TLS" in the sense that you define it.

Just so my point is really clear, the negotiation I'm talking about is not a protocol exchange.  I'm talking about people talking rather than two pieces of software.  It might even involve beer.

> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Wednesday, 6 August 2008 10:43 AM
> To: Thomson, Martin
> Cc: Richard Barnes; Andrew Newton; GEOPRIV; Mary Barnes

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 14 Aug 2008 11:13:13 -0500

Richard,

I have a few comments below [MB] as I believe this issue is independent of the debate on whether we need to define a new URI schema for HELD and I believe this is a far more critical issue to resolve. 

Despite my strong position that we should mandate TLS, Richard if you really aren't willing to compromise on this topic, then can you please provide text that properly deals with TLS being RECOMMENDED and not mandated? Most importantly, we need text that describes what happens if you don't implement and use TLS - my understanding is that the security folks would expect that this is properly documented, including all risks and ways that they can be mitigated (based on my past experiences with getting a doc approved by these folks). And, if we can't get this text agreed by the security folks, then I think we need to go back to the simpler approach. I will note that this combo HTTP/HTTPS was added in the late stages for this document, as the intention AFAIK was to just mandate TLS, although, we didn't at all have the appropriate text at that point in time.

I've cc'ed been on this thread since he is both the gen-art reviewer and the author of the MSRP spec and hopefully he might be able to shed some additional light as to why both MSRP and MSRPS were defined.  And, I've cc'ed Robert so he can perhaps add why SIP still allows both SIP and SIPS. 

Mary.

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2008 12:03 PM
To: Andrew Newton
Cc: Barnes, Mary (RICH2:AR00); GEOPRIV
Subject: Re: [Geopriv] Proposed way forward for HELD

Hey Andy,

[MB] We can add one more that disgrees with Richard :) [/MB]

> also means the possibility of listening on multiple ports... etc.

Like I said, it keeps the *base* case simple: In the case where everyone just does HTTP, you save all the expense of crypto, key management, etc. 
  This allows simple deployments, like our experiment in the IETF network, to work simply.

[MB] But, don't you have security issues in this experimental network? It seems your security model is based on trusting everyone within the IETF network. I may be quite naïve about security, but aren't attacks from within some of the more difficult security issues? Even in the IMS closed network, IPSEC is required AFAIK. [/MB]

You're right that there is some minor additional complexity involved in negotiating, but that's easy to solve.  Hasn't been a show-stopper for HTTP/HTTPS, SIP/SIPS, etc.

[MB] I don't think SIP/SIPS is a very good example at all given how long the SIP WG took to figure out how to do SIPS - i.e., RFC 3261 was published in 2002 and how to use SIPS has yet to be reviewed by the IESG.  And, AFAIK, the primary reason why SIP is still supported along with SIPS is due to backwards compatibility and there having been a very broad deployment of SIP when RFC 3261 was published. I would imagine it's the same with HTTP, but from my experience (again I may be very naïve), but HTTPS seems to dominate (at least for the sites) that I interface with. It would be good to get stats from the HTTP and security community on this topic. [/MB]

> just stop non-criminals from buying guns" arguments.

The statement here is that if TLS is available (i.e., MUST implement), then entities that want security can use it.  That is, MUST implement gives all the security that's required.

The only incremental difference from making it a MUST use is that entities that *don't* require security properties are also required to use it.  That's neither necessary nor useful.
[MB] Again, my naivety about security may be showing through, but I didn't think there was anything within the Internet that didn't require security properties of some sort. [/MB]

What I'm saying here is basically a variation on my response to B. 
above: All a "MUST use" requirement does is require people that don't want security use security features.  In practice, people don't abide by requirements of that form.

[MB] I totally agree with Andrew on this point (and really applies to B as well).  In practice, we CANNOT police the protocols that we specify. However, we can absolutely RECOMMEND and REQUIRE what folks MUST do if they implement the protocol in the open Internet. I can certainly agree that in a closed network, it might be okay to not deploy TLS, but from the perspective of the protocol, that's a "use at your own risk" situation and would not be standard's compliant. But, again, we can't police the protocol and the reality is you likely could find very, very few implementations that meet every requirement for a lot of the protocols that we're specifying in RAI.  This was quite clear on the first SFSIW held at IETF-70.[/MB]. 

> Doesn't this actually speak against your first point?

No, in the following sense: If we admit that both HTTP and HTTPS will be used for transport, then we can define a sane, interoperable negotiation mechanism (as you suggest above).  If we don't allow that HTTP will be used, and don't define a negotiation mechanism, then one will need to be invented later if/when people do decide to use HTTP.

[MB] Per my response to C., I disagree with this.  If we mandate TLS, then the use of HTTP is at your own risk and should only be used within a closed environment. Again, we aren't protocol police. [/MB] 

--Richard

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 15 Aug 2008 15:02:43 -0500

Hi folks,

I'd also like to hear from other folks in the WG as to views on whether we just mandate TLS for HELD.  Also, in order to try to finally complete this document, if folks could respond with their views by next Friday (Aug 22nd), that would be great.

Thanks,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barnes, Mary (RICH2:AR00)
Sent: Thursday, August 14, 2008 11:13 AM
To: Richard Barnes; Andrew Newton
Cc: GEOPRIV; Ben Campbell
Subject: Re: [Geopriv] Proposed way forward for HELD

Richard,

Mary.

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 12:03 PM
To: Andrew Newton
Cc: Barnes, Mary (RICH2:AR00); GEOPRIV
Subject: Re: [Geopriv] Proposed way forward for HELD

Hey Andy,

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 19 Aug 2008 10:29:42 -0500

EKR had pointed out two issues with regard to TLS:
1) the document was unclear about whether TLS was required and
2) it wasn't always clear how the clients and/orservers knew whether 
they should be using TLS.

I think the first issue is adequately addressed by changing the 
following existing sentence in Section 9:
"The implementation of HTTPS as a transport mechanism MUST implement TLS 
as described in [RFC2818]."
... to this sentence:
"Implementations of HELD that implement the HTTP transport MUST also 
implement a transport over HTTPS [RFC2818]."

For the issue, I'd like to propose the following paragraph be added at 
the end of Section 9:
"
While individual HELD servers may offer HELD services over either HTTP 
or HTTPS, it is RECOMMENDED that they offer both.  When a server offers 
both HTTP- and HTTPS-based HELD services, these services MUST use 
separate ports.  This document does not specify default ports for HELD 
over either the HTTP transport or the HTTPS transport.  In order for 
clients to access a HELD server, mechanisms for discovering or referring 
to HELD servers (e.g., the URI-based scheme defined in [lis-discovery]) 
MUST specify both the TCP port to be used and the binding to be used 
(HTTP or HTTPS).
"

I think the current security considerations discuss the trade-offs 
appropriately.  They're written to explicitly describe the trade-offs 
you get with secure vs. non-secure transports.

--Richard

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Aug 2008 21:20:53 -0500

My two cents:

It seems reasonable to me that HELD can be used in a completely closed and isolated network where security is unnecessary.

Where security is used, it MUST be TLS. A HELD client SHOULD implement both modes in order to maximize interoperability when attaching to arbitrary networks.

I think that's the spirit of Richard's wording - his being more precisely correct.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, 20 August 2008 1:30 AM
To: Mary Barnes
Cc: GEOPRIV; Ben Campbell; Andrew Newton
Subject: Re: [Geopriv] Proposed way forward for HELD

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Aug 2008 20:23:00 -0500

Hi Richard,

I agree with your proposed changes.
I might drop the work "also" from your first change so that it becomes:

"Implementations of HELD that implement the HTTP transport MUST implement a transport over HTTPS [RFC2818]."

Otherwise I am fine with the changes.

Cheers
James

> > I have a few comments below [MB] as I believe this issue is independent
> of the debate on whether we need to define a new URI schema for HELD and I
> believe this is a far more critical issue to resolve.
> >
> > Despite my strong position that we should mandate TLS, Richard if you
> really aren't willing to compromise on this topic, then can you please
> provide text that properly deals with TLS being RECOMMENDED and not
> mandated? Most importantly, we need text that describes what happens if
> you don't implement and use TLS - my understanding is that the security
> folks would expect that this is properly documented, including all risks
> and ways that they can be mitigated (based on my past experiences with
> getting a doc approved by these folks). And, if we can't get this text
> agreed by the security folks, then I think we need to go back to the
> simpler approach. I will note that this combo HTTP/HTTPS was added in the
> late stages for this document, as the intention AFAIK was to just mandate
> TLS, although, we didn't at all have the appropriate text at that point in
> time.
> >
> > I've cc'ed been on this thread since he is both the gen-art reviewer and
> the author of the MSRP spec and hopefully he might be able to shed some
> additional light as to why both MSRP and MSRPS were defined.  And, I've
> cc'ed Robert so he can perhaps add why SIP still allows both SIP and SIPS.
> >
> > Mary.
> >
> > [MB] But, don't you have security issues in this experimental network?
> It seems your security model is based on trusting everyone within the IETF
> network. I may be quite naïve about security, but aren't attacks from
> within some of the more difficult security issues? Even in the IMS closed
> network, IPSEC is required AFAIK. [/MB]
> >
> > [MB] I don't think SIP/SIPS is a very good example at all given how long
> the SIP WG took to figure out how to do SIPS - i.e., RFC 3261 was
> published in 2002 and how to use SIPS has yet to be reviewed by the IESG.
> And, AFAIK, the primary reason why SIP is still supported along with SIPS
> is due to backwards compatibility and there having been a very broad
> deployment of SIP when RFC 3261 was published. I would imagine it's the
> same with HTTP, but from my experience (again I may be very naïve), but
> HTTPS seems to dominate (at least for the sites) that I interface with. It
> would be good to get stats from the HTTP and security community on this
> topic. [/MB]
> >
> entities that *don't* require security properties are also required to use
> it.  That's neither necessary nor useful.
> > [MB] Again, my naivety about security may be showing through, but I
> didn't think there was anything within the Internet that didn't require
> security properties of some sort. [/MB]
> >
> > [MB] I totally agree with Andrew on this point (and really applies to B
> as well).  In practice, we CANNOT police the protocols that we specify.
> However, we can absolutely RECOMMEND and REQUIRE what folks MUST do if
> they implement the protocol in the open Internet. I can certainly agree
> that in a closed network, it might be okay to not deploy TLS, but from the
> perspective of the protocol, that's a "use at your own risk" situation and
> would not be standard's compliant. But, again, we can't police the
> protocol and the reality is you likely could find very, very few
> implementations that meet every requirement for a lot of the protocols
> that we're specifying in RAI.  This was quite clear on the first SFSIW
> held at IETF-70.[/MB].
> >
> > [MB] Per my response to C., I disagree with this.  If we mandate TLS,
> then the use of HTTP is at your own risk and should only be used within a
> closed environment. Again, we aren't protocol police. [/MB]
> >
> >
> > --Richard
> >
> >