Subject: [Simple] TLS or Not for CEMA

From: Eric Burger <[email-masked]>
Date: Mon, 22 Aug 2011 12:37:37 -0400

The CEMA draft, the latest incarnation of session matching, is almost ready for submission.  As you may recall from the list and live discussion in Quebec City (archived and minuted), the point of CEMA is not to make life easy for middleboxes.  The point is to make it *possible* for end-to-end encryption to occur in the common topology where there happen to be middleboxes.  A side effect is life is a lot easier for middleboxes, which one could consider the carrot to get the middlebox manufacturers and service providers to adopt CEMA, is it makes life easier for them.

Because the purpose of CEMA is enabling end-to-end encryption, there has been some debate as to whether, when two CEMA-endpoints are negotiating, TLS is mandatory or optional.

On the optional side are the following arguments:

o   TLS consumes resources, more so than TCP

o   TLS requires certificates in the end point

o   Non-CEMA endpoints have only a MAY requirement for TLS, and thus few if any implement TLS

o   TLS does not provide bullet-proof security, due to vulnerabilities from self-signed certificates or alternate root certificate hijacking

On the mandatory side are the following arguments:

o   While TLS consumes resources, most mobile devices have more than enough compute and battery resources to do TLS.

o   TLS does not impact middleboxes whatsoever

o   The primary market for CEMA initially is 3GPP IMS.  In 3GPP IMS, all endpoints have rooted, trusted certificates.

o   Communicating with an endpoint with a self-signed certificate, while not offering a defense against man-in-the-middle attacks, is an improvement over plaintext TCP.  Plaintext TCP is subject to eavesdropping attacks.  Moreover, mandating TLS raises the bar for man-in-the-middle attacks or alteration attacks, as the attacker much generate the appropriate certificates, potentially on the fly.

o   Mandating TLS puts the structure in place for true, end-to-end security with the deployment of an ubiquitous PKI, such as PGP or DANE.

o   Not mandating TLS means CEMA perpetuates the invitation for downgrade attacks.  This would be a structural problem that the deployment of a ubiquitous PKI would not fix.

Comments welcome.  We really are just one MUST versus MAY away from getting this finished.

Thanks.

---

From: Adrian Georgescu <[email-masked]>
Date: Mon, 22 Aug 2011 19:05:52 +0200

Comments inline,

> o   TLS consumes resources, more so than TCP

This is not a valid argument.

I have more CPU power in my Android phone today than I had 8 years in half a rack full full of servers in the data center. By the time this drafts passes, we will have 4x 1GHz CPU cores in every end-user device as standard. If you do MSRP, then your do at least WEB browsing and TLS for it anyway.

> o   TLS requires certificates in the end point

This is not a valid argument.

It is the server that must have a certificate as per usual. Same as in e-commerce, is the server that needs to prove who is to the client and not vice-versa. Once the TLS connection is established, then the client authenticates itself using an in-band mechanism with his credentials.

> o   Non-CEMA endpoints have only a MAY requirement for TLS, and thus few if any implement TLS

This is not a valid argument.

All MSRP end-points must implement TLS as per standard. And all MSRP end-points I know of, they do implement TLS by default. Search the Mac App Store for MSRP clients to confirm this. 

> 
> o   TLS does not provide bullet-proof security, due to vulnerabilities from self-signed certificates or alternate root certificate hijacking.

This is not a valid argument.

If it is, than the whole World Wide Web has the same issue.  This is problem of PKIs is general and not how they defend their CA.

> Thanks._______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 22 Aug 2011 13:21:41 -0400

I don't understand how one can mandate TLS be used, since it would break backwards-compatibility… for which this whole thing has taken all this time.
To use TLS, the m= line must indicate it, and the "msrps" scheme path is used. (well, the latter is not as clear as the former)
Since RFC 4975 did not mandate TLS, a CEMA UAC cannot assume it can use it in its offer to communicate with RFC 4975 UAS.  

-hadriel

On Aug 22, 2011, at 12:37 PM, Eric Burger wrote:

> Thanks.<smime.p7s><ATT00001..c>

---

From: Adrian Georgescu <[email-masked]>
Date: Mon, 22 Aug 2011 19:40:51 +0200

I believe mandating encryption by default is a civic duty much like implementing sanitation. It costs more in the long run and is more unpleasant if you do not have it.

Adrian

On Aug 22, 2011, at 7:21 PM, Hadriel Kaplan wrote:

> _______________________________________________
> Simple mailing list
> [email-masked]

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 22 Aug 2011 13:55:34 -0400

This seems like a sensible approach.  I don't see why CEMA endpoints should behave any differently from other SIP endpoints with regard to the use of secure media.  If either party desires or requires the use of TLS, they can negotiate it in SDP, as Hadriel notes.  ISTM that the traditional "MUST implement / MAY use" pattern applies here.

--Richard

---

From: Eric Burger <[email-masked]>
Date: Tue, 23 Aug 2011 06:32:36 -0400

Right, and since there are no protocol police, MUST implement / MAY use = DO NOT BOTHER.

---

From: Eric Burger <[email-masked]>
Date: Tue, 23 Aug 2011 06:38:14 -0400

It does not break backwards-compatibilitiy. A CEMA peer contacting a CEMA peer MUST use TLS.  Not a problem, because the remote CEMA peer is a CEMA peer and thus is guaranteed to use TLS.

A CEMA peer contacting a RFC 4975 UAS uses RFC 4975. RFC 4975 says MUST implement TLS.  Not a problem; all we are doing is moving from PROBABLY USE TCP to MUST use TLS.

Interestingly, RFC 4975 also points out what I said earlier. msrp: could use TLS; msrps: must use TLS.  I don't have any issue with mandating msrps: if that is the issue with mandating use of TLS for CEMA.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Aug 2011 09:28:46 -0400

A MUST here gets enforced just like any other MUST in the IETF -- by people asking for it.  Conformance tests, RFPs, etc.

--Richard

---

From: Eric Burger <[email-masked]>
Date: Tue, 23 Aug 2011 15:58:42 -0400

Right, and if it is not mandated by the RFC it does not get on the request list.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Aug 2011 16:01:22 -0400

Ok, so what's the disagreement here?  Implementation is mandated by the RFC, so it goes in the request list, so it's available for users who MAY use it.  Not sure how you get from there to DO NOT BOTHER.

HTTPS usage is not required by RFC 2818, but all the browsers do it anyway.

--Richard

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Aug 2011 17:11:24 -0400

> Right, and since there are no protocol police, MUST implement / MAY use = DO NOT BOTHER.

If there's demand for it, people will do it.  If there isn't demand, we shouldn't be in the business of creating an artificial one.
We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, Telnet, etc.

-hadriel

---

From: Eric Burger <[email-masked]>
Date: Tue, 23 Aug 2011 23:05:59 -0400

THANK YOU FOR THE OPENING!!!

Let's see.  TLS was published in January, 1999.  Let's look at the other references:

	SMTP: published August, 1982.  17 years before TLS came out. Older than some IETF participants.  As published today, requirers it.

	Telnet: published May, 1983.  16 years before TLS came out.  If published today, would undoubtably require it.

	RTP: published January, 1996.  Doesn't run over TCP, so red herring.  However, lots of effort to make SRTP, DTLS, ZRTP, et al. work today.  Lots of folks wish there was a single way of doing secure RTP, key exchange, and secure key exchange signaling.  [BTW, if anyone on the list is interested in doing this kind of work, please send me an email off-list.]

	POP3: published May, 1996. 13 years before TLS came out.  If published today, would undoubtably require it.  See IMAP for the existence proof.

	SIP: published March, 1999.  Suggested one use this new thing called TLS.  Who knew if TLS was going to work.  It does.  Let us get on the bus.

	HTTP: published June, 1999.  Suggested one use this new thing called TLS.  Fast forward 12 years.  Industry wishes everything was TLS.  Market is starting to push that way.

So, if only TLS was invented twenty years earlier, are you saying we would not have this problem?

I will venture to be politically incorrect here: are what we are saying is that we always had slavery, but in the past some folks MAY be free, so it is fine to say people SHOULD be free today, because people were not free in the past?  I think most folks would say people MUST be free, especially *because* people were not free in the past.  Remember the obligation to repair the world.  Let us not fall down in our duty.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Aug 2011 23:47:28 -0400

This is the IETF.  We could have revved those protocols to require TLS at any point in the 12 years that TLS has been around.  All of those protocols have active standardization work, and somehow nobody has found that adding "MUST USE" TLS requirement was something that would be useful.

In any case, let's get real here.  TLS does not "just work".  In order for TLS to work between two endpoints, they needs to be some key agreement -- some way for them to recognize each other, usually a mutually trusted PKIX trust anchor.  Unless you have a solution for key/cert management, requiring TLS as a "MUST USE" doesn't help anything; it will just cause sessions to fail.  

The one example that we have of a protocol that has "MUST USE TLS" is RELOAD, and the only reason that works is that RELOAD explicitly defines a certificate management model, via the enrollment server.  In order to make "MUST USE TLS" work for this application, you would have to define a similar model for SIP.  RFC 6072 is out there, but as far as I know, it's not widely used.

Can you point to any prior art that show that "MUST USE TLS" would actually have any positive impact?

--Richard

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Aug 2011 04:45:04 -0400

Are you seriously comparing mandating TLS with human rights???
Wow.  I think you need to step away from the computer and go on a vacation with human beings and get some perspective.  ;)

As to your other points - I don't know what we'd do today for those protocols - given the behavior of the IETF we'd probably never publish any of them today. (seriously)  IMO that's a problem with the IETF rather than a problem with the protocols.  Instead of just publishing RFCs for the purpose of interoperating while giving us freedom to make our own decisions, it's about enslaving us to holier-than-thou Commandments.

Live free or die!

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 Aug 2011 18:20:07 -0600

Uh, wow - looks like we are getting closer to consensus on this draft. Let me know when it get's published. I think this current thread is fairly crazy. I'm pretty sure I disagree with at least half the folks on this thread but I'll wait to read the draft first.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 26 Aug 2011 04:09:00 -0400

It occurs to me my statements below may sound angry or threatening to those who don't know me or some background.

The phrase "Live free or die" is the State motto and written on every license plate of the US State of New Hampshire, where I live, and Eric used to live for many years.  So I knew Eric would get the reference.  I did not literally mean it as a challenge to perish.

-hadriel
p.s. sometimes my attempt at humor/levity falls flat. :(

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Aug 2011 11:36:28 +0200

Cullen,

If you have an opinion on the specific topic currently being discussed, I think it would be helpful if you could give it before a new draft is available...

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]
Sent: Friday, August 26, 2011 3:20 AM
To: Simple WG
Subject: Re: [Simple] TLS or Not for CEMA

---

From: Eric Burger <[email-masked]>
Date: Fri, 26 Aug 2011 06:02:14 -0400

At least *I* got it.  Of course, given the motorcycle helmet laws, which are pretty much "please take them off when you cross the border into New Hampshire," we tended to say the state motto was "Live Free AND Die."

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 26 Aug 2011 06:57:03 -0600

> At least *I* got it.  Of course, given the motorcycle helmet laws, which are pretty much "please take them off when you cross the border into New Hampshire," we tended to say the state motto was "L…

It's good to have a goal where at least half of it is very likely to be achieved. I note that even in New Hampshire, cars MUST implement a seat belt and users can choose to use them or not with some economic incentives one way or the other. I guess I could have said "brakes" instead of "seatbelt"

---

From: Eric Burger <[email-masked]>
Date: Fri, 26 Aug 2011 08:58:47 -0400

NH: Mandatory to use for human < 18 years old.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 26 Aug 2011 07:09:09 -0600

Yes, my opinion is more or less that until someone changes BCP 61, IETF work needs to meet BCP 61. Richard more or less summarized BCP 61 for you and needless to say it roughly says "MUST implement" and explains why it is not "MUST use"

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Aug 2011 15:11:16 +0200

Thanks! :)

Regards,

Christer 

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: 26. elokuuta 2011 16:09
To: Christer Holmberg
Cc: Simple WG
Subject: Re: [Simple] TLS or Not for CEMA

On Aug 26, 2011, at 3:36 AM, Christer Holmberg wrote:

> > Wow.  I think you need to step away from the computer and go on a 
> > vacation with human beings and get some perspective.  ;)
> >
> >>      RTP: published January, 1996.  Doesn't run over TCP, so red 
> >> herring.  However, lots of effort to make SRTP, DTLS, ZRTP, et al. 
> >> work today.  Lots of folks wish there was a single way of doing 
> >> secure RTP, key exchange, and secure key exchange signaling.  [BTW, 
> >> if anyone on the list is interested in doing this kind of work, 
> >> please send me an email off-list.]
> >>

---

From: Eric Burger <[email-masked]>
Date: Fri, 26 Aug 2011 10:02:14 -0400

In this context, I would offer BCP 61 indicates MUST use.  The MUST implement versus MUST use construct of BCP 61 is for walled garden environments.  Last I looked, SIMPLE and MSRP's target is the wider Internet.  Moreover, it is for person-to-person, PRIVATE, communication.  That is not something where there is a presumption of publication.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 26 Aug 2011 08:10:27 -0600

Are you seriously saying no one would ever use MSRP in an enterprise network?

---

From: Ben Campbell <[email-masked]>
Date: Fri, 26 Aug 2011 09:21:41 -0500

(as individual)

> In this context, I would offer BCP 61 indicates MUST use.  The MUST implement versus MUST use construct of BCP 61 is for walled garden environments.  Last I looked, SIMPLE and MSRP's target is the…

I think section 7 in BCP 61 is pretty explicit in saying the opposite. It's MUST implement vs MUST use because of the assumption that any internet protocol _might_ be used in a walled garden, and it's the gardener's right to make the decision on whether or not to use. it.

As far as MSRP being intended for the wider Internet--the point of BCP 61 is to say that _all_ IETF protocols are effectively intended for the wider Internet. (I.e. even if the designers don't intend that, they are likely to "escape". That doesn't seem to imply any "more Internety" property for MSRP.

---

From: Eric Burger <[email-masked]>
Date: Fri, 26 Aug 2011 11:01:55 -0400

Naah. They use XMPP :-)

Oops - I forgot - that's all TLS.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 26 Aug 2011 10:11:40 -0500

(as individual)

> Oops - I forgot - that's all TLS.

TLS is "MUST support" in XMPP.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 26 Aug 2011 10:26:57 -0600

well that gets to the real issues, one approach to improve interoperability  would be to say all MSRP clients MUST use XMPP but may implement MSRP :-)

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 29 Aug 2011 10:20:31 -0400

Not all XMPP is over TLS, otherwise we wouldn't need draft-ietf-xmpp-dna.  If RFC 3921 had made TLS a MUST USE, then XMPP (e.g., Google Apps) would not have been feasible.