Subject: MLS or TLS? There is more than one encryption option.

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 14:55:03 -0500

I have heard all the tactical reasons for wanting TLS as a mechanism for
proxy busting. I do not accept these because however awful people think
proxies are, they were invented for a purpose.

Moreover I think that people are ignoring many of the practicalities of how
TLS is supported by commercial providers. Whether you like the business
models of the ISPs or not, there will be no deployment of HTTP 2.0 without
them. Most ISPs provide HTTP 1.0 and DNS names at or below cost. Their
primary means of making profits is to sell premium services. The only
premium service that has not ended up being commoditized is selling SSL/TLS
certificates.

>From a technical point of view, TLS has two major impediments, first the
stack is huge and proposing to use a subset does not make things any
easier. The only part that can be easily separated from the rest is the
PKIX stack but separating out all the dependencies would be many years of
work for most of the systems out there. It really would be easiest to write
a TLS-Lite stack from scratch rather than try to cut down the existing
libraries.

And that is before we get to the fact that it would take five years to
agree on what TLS-Lite should contain.

I propose that we go a different route for preventing pervasive
surveillance, one that protects the HTTP content against a passive attack,
has negligible additional overhead other than the actual encryption cycles
and is compatible with the existing semantics of TLS.

>From a marketing point of view I think the group is shooting itself in both
feet (and other parts) with its message that HTTP/2.0 is much faster than
HTTP/1.0 until you use the mandatory encryption which makes the transition
a wash.

It is quite easy to design a scheme that has these properties with a small
fraction of the complexity of TLS-Lite. All that is required is a
lightweight key exchange in the headers plus a Content-Encrypted header.

I have even written code for such a scheme recently, albeit with Web
Services in mind. This is the scheme that I subsetted to come up with the
HTTP Session-ID proposal:

https://datatracker.ietf.org/doc/draft-hallambaker-httpsession/

This draft does not have the DH key agreement or the encryption described
but the code works and the whole package is only about 300 lines of C plus
whatever the crypto libraries need (my estimate may be off as I write in
C#).

I took the encryption layer out for two reasons. First I thought it might
shoot the chances of getting a standard in the IETF. But the more important
reason was that I wanted to keep that capability as a silent, latent
capability that could be turned on in case of future need such as another
Arab Spring situation.

Now that we are going to be going for preventing pervasive surveillance, I
think we should add a Message Layer Security scheme to HTTP to complement
TLS. In cases where the initial key exchange is supported by TLS, we can
use channel binding to connect the two. We can also provide a mechanism to
authenticate the MLS layer (which would be optional). But either scheme
could be used independently.

The advantage of using MLS and TLS in combination is that they both serve
different security requirements.

Pervasive encryption is a good idea but not if the cost is to weaken the
security of a deployed system that works.
We already have a TLS system that works well. I have no objection at all if
the HTTP-BIS WG wants to mandate use of TLS with the WebPKI. But I don't
think that is what is being proposed.

What I think is being proposed is to wreck the only widely deployed
security infrastructure that we have today by offering a 'lite' version
that busts holes in the trust model. And that is not going to happen.

-- 
Website: http://hallambaker.com/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 15 Nov 2013 20:18:53 +0000

In message <CAMm+LwitCMbU5Xo_fpDfjZGkZEa9H=qgoe=[email-masked]>
, Phillip Hallam-Baker writes:

>Now that we are going to be going for preventing pervasive surveillance,

I hate to be the one to bring this up, but that is not in any way
shape or form inside the WG charter and not even remotely close to
any concensus I can detect.

HTTP/2.0 should, according to common sense run on any byte-pipe, or
as the WG charter says it, somewhat more convoluted:

	The Working Group will produce a specification of a new
	expression of HTTP's current semantics in ordered,
	bi-directional streams. As with HTTP/1.x, the primary target
	transport is TCP, but it should be possible to use other
	transports.

	[...]

	Explicitly out-of-scope items include:

	* Specifying the use of alternate transport-layer protocols.
	Note that it is expected that the Working Group will work
	with the TLS working group to define how the protocol is
	used with the TLS Protocol; any revisions to RFC 2818 will
	be done in the TLS working group.

Your proposal may be good or bad, but it is simply not the right
place for it.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 21:17:56 +0100

Le Ven 15 novembre 2013 20:55, Phillip Hallam-Baker a écrit :

> TLS.

Indeed that would be a good middle ground as a lot of the filtering in
corps-space only cares about urls (both to block slacker-sites and the url
signatures of zombie networks)

-- 
Nicolas Mailhot

---

From: Bruce Perens <[email-masked]>
Date: Fri, 15 Nov 2013 13:33:26 -0800

On 11/15/2013 12:18 PM, Poul-Henning
Kamp wrote:

I hate to be the one to bring this up, but that is not in any way
shape or form inside the WG charter

This is no surprise.

I am approaching the conclusion that it's impossible, anyway. Given
that a government subverts even one CA with a certificate
that is honored by the browser, a man-in-the-middle attack that
would fool the naive user becomes trivial.

---

From: Tobias Gondrom <[email-masked]>
Date: Fri, 15 Nov 2013 16:40:32 -0500

Not so trivial if the server has key pinning.
Best regards, Tobias

Bruce Perens <[email-masked]> wrote:
>On 11/15/2013 12:18 PM, Poul-Henning Kamp wrote:
>
>I hate to be the one to bring this up, but that is not in any way shape
>or form inside the WG charter 
>
>This is no surprise.
>
>that a government subverts even one CA with a certificate that is
>honored by the browser, a man-in-the-middle attack that would fool the
>naive user becomes trivial.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 17:25:17 -0500

> Your proposal may be good or bad, but it is simply not the right

The point of bringing it up here is because the fact this option exists has
a big impact on the rationale being given for MUST USE TLS.

Where such a scheme would be specified is secondary. The point that is
relevant to this working group is that discovering what the NSA was up to
have caused some people to assert a new set of reasons for mandating TLS.

If we rule those reasons out of scope then the fact that they are better
addressed in a different approach can also be left out of scope. But if
people are going to be making the security case for weakened TLS everywhere
then they are very relevant.

There are good reasons why everyone should use strong TLS. The problem I
have with the TLS mandate is that the reasons advanced are not considered
strong enough for mandating strong TLS and so there is pressure to weaken
TLS.

I do not think that the HTTP/2.0 difficulty with bypassing legacy proxies
is sufficient to justify accepting a weak TLS

I do not think that the understanding of the pervasive surveillance use
case is mature enough to mandate any particular approach yet and certainly
must not be used to justify weakening TLS.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 15 Nov 2013 22:27:16 +0000

>would fool the naive user becomes trivial.

I reached that conclusion some time ago, and tried to explain it
for my ACM audience:

  http://queue.acm.org/detail.cfm?id=2508864

The Surveillance State is a political issue that must be solved by
political means.  As long as NSA, GCHQ and other similar have a
mandate, funds and political support for what they are doing, adding
more encryption simply only means that more encryption will be broken.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Nov 2013 23:37:09 +0000

Phill,

I *know* you know better than to use terms like "weak TLS"
which you *know* is purely rhetorical and doesn't help here
at all. There is no "weak" variant of anything that's been
put on the table by anyone credible, nor does that adjective
really make sense when put in front of any cryptographic
protocol. This discussion needs more precision and not less.

If you mean unauthenticated TLS then say so. If your claim
is that that is "weaker" than server-authenticated TLS then
presumably you think that is in turn "weaker" than mutually
authenticated TLS, which is obviously a dumb argument, so
I conclude your phraseology can only be useless rhetoric.

I also think "MLS or TLS" is a false dichotomy if its being
setup that way.

TLS is a practical widely deployed technology, with flaws,
sure, but there is no credible alternative for HTTP security
and TLS is in fact good enough, though we can improve it
as well.

A putative application layer security mechanism like "MLS"
could be useful, but a) is mythical today so would have
to be defined, implemented, deployed, debugged etc before
it'd be worth thinking about comparing its properties to
those of TLS, and b) would involve significant changes to
both browsers and server-side web application frameworks,
(not the folks here), and c) would in large part
contradict the efforts underway on WebCrypto, unless it
was built on that. So, as an alternative that's worth
considering now, that's nonsense.

(Don't get me wrong, if it made sense for the IETF or
someone else to define an "MLS" that used WebCrypto
then I'd be all for it, if the right people were involved
and if it had a chance to be deployed.)

Having said that, you're by no means the only person
who's been waffling on this topic. As far as I can
see there's an inverse relationship between the level
of rhetoric used and the attention that should be
paid to posts on this list in the last few days.

Finally, sorry to pick on you Phill, but in contrast
to others who've been coming out with security-gibberish
I know you know this stuff better. (And you're a serial
offender in the court of rhetoric as well, so I hope
you don't mind so much being called out for it:-)

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 19:15:58 -0500

On Fri, Nov 15, 2013 at 6:37 PM, Stephen Farrell
<[email-masked]>wrote:

> If you mean unauthenticated TLS then say so.

Laking authentication means that it only prevents passive attack. Ergo it
is weaker.

> If your claim

Using terms like 'dumb' in that fashion is probably against the diversity
policy.

What attacks does mutual authentication protect against that server-only
auth does not? If TLS was widely used as the control against those attacks
then I would use the term weaker. But since it is not I don't consider that
to be an issue.

Server auth is not a casual feature of TLS, it was the original purpose of
the protocol.

> and TLS is in fact good enough, though we can improve it

TLS with either CA issued certificates or out of band trust configuration
is a practical widely deployed technology. This proposed 'no
authentication' TLS is not.

> both browsers and server-side web application frameworks,

And removing certificates from TLS would not? I think that would require
rather more of an upheaval than you imagine.

And HTTP + TLS + PKIX is hardly a trivial stack to implement. Care to
implement that in VLSI logic?

Defining a new protocol is not a trivial exercise but in my experience
attempting to remove core functionality from an existing protocol is far
more difficult and complex. If that was not the case we could make PKIX a
LOT simpler, and the same goes for SMTP and pretty much every stack we have.

> considering now, that's nonsense.

I think the question is where you put the WebCrypto, whether it is
something that is only visible in Javascript or a feature that can be
invoked via HTTP.

> paid to posts on this list in the last few days.

I have running code, that is hardly waffle. OK I am only doing
authentication of HTTP sessions right now but doing encryption against the
shared secret is a trivial additional complexity that the code was doing
before I took it out.

> you don't mind so much being called out for it:-)

 Since rhetoric is the process of rational argument, I am not sure what the
alternative is you suggest.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Nov 2013 00:34:26 +0000

> Laking authentication means that it only prevents passive attack. Ergo it

No. Firstly, there was a proposal for doing an unauthenticated
mode of TLS for http:// URIs, which now (unfortunately IMO)
seems sidelined. If you want to descend to ridiculously coarse
terminology, then that'd be "stronger" than the status quo ante.

Nobody has suggested changes that affect https:// URIs at all
so you're attacking a proposal that simply hasn't been made.

Mark's subsequent proposal is to in fact run TLS as-is, with
the only change being that http:// URIs will (somehow) all be
re-directed to https:// URIs. While I don't like that so much,
it actually involves no unauthenticated TLS at all.

> Using terms like 'dumb' in that fashion is probably against the diversity

So bite me:-) Actually though its not. I said your argument was
dumb and why.

> Server auth is not a casual feature of TLS, it was the original purpose of

Yes. But there's been no credible (or any?) proposal to change
that for https:// URIs.

> authentication' TLS is not.

Disagree, to an extent. Yes had httpbis wanted to do unauth
TLS beneath http:// URIs then there would be some new stuff.
But its pretty much the same as using self-signed certs, so
there is actually plenty of real experience with deploying
that.

> implement that in VLSI logic?

I've no idea what you mean, but I think that's ok.

> LOT simpler, and the same goes for SMTP and pretty much every stack we have.

Possible.

> I have running code, that is hardly waffle. 

I did not say that you always waffled. I maintain that your
use of terms like "weak TLS" is waffle.

> OK I am only doing

The alternative I suggest is to be precise and lose the
overblown language. For you, me and everyone else.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 23:56:48 -0500

> it actually involves no unauthenticated TLS at all.

Then maybe I am reading in more to some of the arguments than the people
behind them intend.

What is worrying me is the idea that we have to do something about
pervasive monitoring and this is so important that it blocks all other
security concerns. First do no harm.

> So bite me:-) Actually though its not. I said your argument was

My point was that equating a particular disability with stupidity is non-PC
these days.

> there is actually plenty of real experience with deploying

That is what I was thinking last week.

I am not so happy now having read the discussion.

> I've no idea what you mean, but I think that's ok.

We have quite a few HTTP/1.1 implementations in very low level technology.
It appears in industrial controllers in microcode.

I don't think we can expect people to do ASN.1 in microcode.

> use of terms like "weak TLS" is waffle.

Well maybe there will be sufficient commitment to security to do it right.
But looking at the fanatical obsession here with shaving milliseconds off
round trips I suspect that it is going to be very hard to avoid performance
being put ahead of security.

My bottom line is do TLS right or not at all. If people decide TLS is too
much then we should make sure it has a different name at the very least. I
do not want to see HTTP/2.0 TLS everywhere as an excuse to weaken the
SSL/TLS brand.