Subject: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Nov 2013 16:47:02 -0500

I have been looking at the minimal requirements for pervasive crypto.

I like TLS everywhere with strong authentication. The idea of weakening the
authentication requirements further and calling the result TLS worries me a
lot.

The other problem with TLS everywhere is that it changes the communication
model of HTTP. Proxies no longer work for a start. Data can't be cached.

Which has me thinking about extending my session continuation proposal to
add in an ephemeral DH exchange and content encryption options to provide a
very lightweight message layer security scheme.

The idea is that MLS could be used with or without authentication and this
would be understood from the start. High security applications would
eventually use TLS+MLS as a matter of course and authenticate at both
levels.

MLS is a better place to put in client authentication. In a scaled system I
almost always want to terminate my TLS tunnel before the actual Web
Service.

Stephen F. suggests that I should look to WebCrypto as a basis. Which seems
OK, though I might have a different approach to key packaging. Crypto
libraries seem to expect keys to be packaged up in BASE64 encoded ASN.1.

Is anyone interested in reading/reviewing drafts? Looking to shoot for an
experimental at this stage.

The objective would be to get to a point where all Web content can be
encrypted including very large chunks of static data like video. This would
essentially recapitulate the work done on SHTTP and Shen back in the early
90s so there is little IPR risk.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Nov 2013 12:04:41 +1300

On 17/11/2013 10:47, Phillip Hallam-Baker wrote:
...
> model of HTTP. Proxies no longer work for a start. Data can't be cached.

Indeed. A "solution" in which caches, proxies, content filtering
and possibly CDNs don't work is not going to be deployed on any Internet
on this planet.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Nov 2013 18:51:40 -0500

> and possibly CDNs don't work is not going to be deployed on any Internet

Er, be careful here.   It's certainly true that a solution that prevents CDNs, caches, proxies and content filtering from working won't see rapid uptake among providers that depend on these capabilities.   However, there is a rather substantial long tail of web sites that do not depend on these capabilities and never will, and it is these very web sites for which the ability to do various kinds of passive tracking will be most useful, because they say the most about you.

Also, to completely contradict that point, facebook with https enabled still uses a CDN, so the theory that https prevents CDNs from working is apparently wrong anyway.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Nov 2013 16:27:48 +1300

> Er, be careful here.   It's certainly true that a solution that prevents CDNs, caches, proxies and content filtering from working won't see rapid uptake among providers that depend on these capabil…

Well yes, but the hypothesis seemed to be TLS on *every* HTTP connection.
That doesn't seem to fly, is my point (and, I think, Phill's).

> Also, to completely contradict that point, facebook with https enabled still uses a CDN, so the theory that https prevents CDNs from working is apparently wrong anyway.

I said "possibly" because I wasn't sure. Maybe somebody can explain
how it works and how the associated trust model works?

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Nov 2013 22:54:05 -0500

> That doesn't seem to fly, is my point (and, I think, Phill's).

I don't see it.  Sure, for transparent caching it won't work, but are people still using transparent caching for CDN?   Clearly facebook isn't, nor Google.   I think this ship has already flown the coop.

> how it works and how the associated trust model works?

The web page you download using https from facebook lists content on cdn URLs.   The browser connects to the cdn server and fetches each such URL.   The URLs on the facebook page I looked at are all https.   Why wouldn't this just work?   Transparent caching would break, but that's not what's going on here—this is not at all transparent.

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Sun, 17 Nov 2013 09:25:06 +0000

The CDN has one TLS connection from the client to the CDN and another from the CDN to the server, it sees everything in plaintext. A CA signs the CDNs TLS server certificate so that it can still be accepted by browsers. Depending on the CA, different verifications of ownership may be made.

This does raise the issue that these CDNs, which may be managing many large services, would be a great place to tap the wires. Maybe we should be discouraging them?

Iain.

--
Iain R. Learmonth MBCS
Electronics Research Group
School of Engineering
University of Aberdeen
Kings College
Aberdeen
AB24 3UE

Tel: +44 1224 27 2799

The University of Aberdeen is a charity registered in Scotland No.SCO13683

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Nov 2013 15:39:48 +0000

Folks,

> authentication requirements further and calling the result TLS worries me a

TLS has include anon-DH from the get go. Self-signed certificate
deployments with TLS amount to 10% of all web sites (says [1]).
Only about 3 times that number use certs that chain up to a
browser-trusted CA of one sort or another. So a premise that
all TLS deployments have strong server authentication today is
wrong. And I've objected to PHB saying "weakening" elsewhere, [2]
so I won't repeat that here.

And to the extent this discussion is about http/tls, that
belongs on the httpbis wg list, where there's been a firestorm
of discussion on exactly that topic. So, please let's not start
another http/tls thread here, which is what this seems to be turning
in to, even though Phill asked something else.

Other foo/tls protocols will also soon have a separate venue [3]
and we have a TLS working group. So I see little left to discuss
about TLS on this list to be honest.

Finally, I note the subject line here said "without TLS" and
not "debate TLS on yet another list" :-)

S.

[1] http://w3techs.com/technologies/overview/ssl_certificate/all
[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0928.html
[3] https://datatracker.ietf.org/doc/charter-ietf-uta/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Nov 2013 08:00:45 +1300

> This does raise the issue that these CDNs, which may be managing many large services, would be a great place to tap the wires. Maybe we should be discouraging them?

Yep, that's my concern about the trust model (also after redaing Ted Lemon's response).

All I know is that some site I have decided to trust has redirected me
to content on a third-party site, which presents an apparently valid cert.
I don't understand why I should trust that third-party site.

   Brian

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Mon, 18 Nov 2013 09:13:05 +0000

> [3] https://datatracker.ietf.org/doc/charter-ietf-uta/

I agree that the HTTP/TLS discussion should be moved to the uta (Using TLS in Applications) mailing list, when one exists, with regard to authentication. It protects far more against active attacks and this list is about preventing passive mass monitoring being useful.

I think that the discussion relating to the use of TLS for encryption, its effect on proxies and CDNs, and the fact that CDNs are a privacy issue still need discussion here and are relevant to this list.

The main question: are there times when we would ever want HTTP traffic to not be encrypted?
The secondary question is: how does the trust model for CDNs be improved? I don't believe that third-party CDNs that do caching and have access to private information are a good idea. Maybe we can come up with some best practices like only proxy static content but directly contact for dynamic content that could contain private information and declaring in the cert that you're contacting a CDN instead of the actual site? But then there are no guarantees that people are following them.

Iain.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Nov 2013 11:46:49 +0000

> I think that the discussion relating to the use of TLS for encryption, its effect on proxies and CDNs, and the fact that CDNs are a privacy issue still need discussion here and are relevant to this…

Well, please bear in mind that httpbis are have a HUGE discussion
(~100 mails/day) on exactly this for HTTP/2.0 which is raging now,
so let's at least punt the discussion here for a few weeks until
the immediate work  in httpbis settles down. Or dive in there [1],
seems like everyone else is doing that already;-)

Pretty please?

S.

[1] http://tools.ietf.org/wg/httpbis/

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Nov 2013 07:49:50 -0500

On Mon, Nov 18, 2013 at 6:46 AM, Stephen Farrell
<[email-masked]>wrote:

> > I agree that the HTTP/TLS discussion should be moved to the uta (Using
> TLS in Applications) mailing list, when one exists, with regard to
> authentication. It protects far more against active attacks and this list
> is about preventing passive mass monitoring being useful.
> >
> > I think that the discussion relating to the use of TLS for encryption,
> its effect on proxies and CDNs, and the fact that CDNs are a privacy issue
> still need discussion here and are relevant to this list.
>

Its a lot more than 100 a day. There are close to 100 in a thread you
started last night. And that is the weekend.

All the chatter about confidentiality and nobody is interested in fixing
the massive hole in the use of cookies for authentication. And they can't
even see the connection between the two.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Nov 2013 14:26:50 +0000

> started last night. And that is the weekend.

Yep. That's why I'd rather we not re-do all that here too.

> even see the connection between the two.

That is interesting yes. Yoav mentioned it too and invited
folks to look at the work that's not (yet) gotten traction
on that in websec.

S.

---

From: Eric Burger <[email-masked]>
Date: Mon, 25 Nov 2013 07:46:34 -0500

Is it physically possible to tell the difference between a CDN and a MITM? IMHO the only way of doing this is if the authentication token presented by the CDN saying it represents the source is if that token is issued (signed) by the source.

In theory, no problem. X.509 chains have no problem with Symantec issuing a certificate to foo (the source) and foo issuing a certificate on foo’s behalf to bar (the CDN).

In reality, foo is buying service from bar *because* they are not in the IT business. They want bar to handle all of the “technical stuff.”

If we can make this easy, we can break the CDN = MITM connection.

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Mon, 25 Nov 2013 13:18:45 +0000

It could be that a CA does have a problem with signing a cert that can be used to sign other certs that would potentially be mishandled by a non-technical group allowing certs that appear to have a trust chain back to the CA whereas the CA hasn't really verified anything about those downstream signings.

Iain.

Tel: +44 1224 27 2799

________________________________________
From: perpass <[email-masked]> on behalf of Eric Burger <[email-masked]>
Sent: 25 November 2013 12:46
To: perpass
Subject: Re: [perpass] CDNs as wiretaps [Unauthenticated,       ephemeral keying in HTTP/1.0 without TLS]

---

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Nov 2013 09:11:01 -0500

Iain,

You're right, but there the Basic Constraints extension can be used to limit
the length of the cert chain, and thus minimize the problem.

Steve