Subject: Fwd: New Version Notification for draft-nottingham-http2-encryption-00.txt

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Oct 2013 10:54:58 +1000

Everyone,

This is a draft put together based upon my observations of our discussions about encryption and HTTP/2.0, both before and after Berlin, along with a fair dose of help from reviewers (thanks again!). 

It proposes a way to optimistically encrypt communication for http:// URIs that is resistant to passive attacks, but is not (yet) resistant to active attacks. Full details are in the draft.

The aim was to respect the (sometimes conflicting) requirements of various stakeholders here; I may or may not have hit that goal, and look forward to the discussion. Really, the idea is to get the conversation going, not to guide us to a particular endpoint.

I understand that other folks might be working on complementary or competing drafts as well. We're not going to discuss this general area in any detail at our Seattle interim meeting; instead, we will have a substantial block of time set aside in Vancouver.

Regards,

P.S. I've attached a possibly friendlier HTML version.

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-http2-encryption-00.txt
> Date: 1 October 2013 10:45:04 AM AEST
> To: Mark Nottingham <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-http2-encryption-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Filename:	 draft-nottingham-http2-encryption
> Revision:	 00
> Title:		 Encryption for HTTP URIs Using Alternate Services
> Creation date:	 2013-10-01
> Group:		 Individual Submission
> Number of pages: 15
> URL:             http://www.ietf.org/internet-drafts/draft-nottingham-http2-encryption-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-nottingham-http2-encryption
> Htmlized:        http://tools.ietf.org/html/draft-nottingham-http2-encryption-00
> 
> 
> Abstract:
>   This document proposes a way to optimistically encrypt HTTP/2.0 using
>   TLS for HTTP URIs.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Eliot Lear <[email-masked]>
Date: Tue, 01 Oct 2013 07:01:01 +0200

Hi Mark,

Section 3.3 of your draft does not properly characterize a substantial
security consideration:

If a browser has a primitive that says, “relax your certificate
inspection when you connect on port xyz”, then an insertion attack can
be made not just against those sites that intend to use the header, but
for any site on the Internet, including those sites that have valid
certificates, thus substantially damaging the existing TLS deployment.

Consider the following snippet going into the MITM:

<a href="https://bankofeliot.com/login">Click Here To Login</a>

and coming out:

Alt-svc: http2-tls-relaxed=:443
{...}

<a href="http://bankofeliot.com/login:443">Click Here To Login</a>

Worse, the server has no notion that the browser hasn't validated the
certificate.

  The mitigations for this attack are, as far as I can tell:

1.  Do not have the primitive in the browser;
2.  Only upgrade on the existing connection;
3.  Use a DNS record instead that is signed and can be validated (I
don't know if this is a complete mitigation).

My suggestion is (2) or (3) if you're looking for OE.

Finally, using port 443 in the example conflicts with TLS and the
assignment as articulated in RFC 2818.

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Oct 2013 15:43:37 +1000

> Hi Mark,

Hi Eliot,

> Worse, the server has no notion that the browser hasn't validated the

AIUI your concern is that when this is in place, it enables an attacking intermediary to redirect links in HTML content to a site that isn't encrypted without having that redirection show up in the browser, or noticed on the server. 

However, it *will* show up in the browser, in that the security "lock" won't be in place. Furthermore, note the item in "Next Steps":

"""
Indicating Chosen Service: It’s likely necessary for the server to know which protocol the client has chosen, and perhaps even the hostname (for load balancing). This could be conveyed as part of the “magic”, or as a request header. There are also security implications here; for example, without this information, the server doesn’t know if the client has checked the certificate, leading to a situation where an intermediary can downgrade a HTTPS connection to relaxed HTTP.
"""

I fully expect that if we get momentum on this proposal, we'll need to look at modifying the protocol to carry this information from the UA to the origin.

> assignment as articulated in RFC 2818.

The registry does not reference RFC2818:
  <http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=443>

It merely says "http protocol over TLS/SSL." That's what's happening here.

More to the point, this draft is proposing a pretty fundamental change to how URI schemes map to protocols and ports, and so some adjustment of scheme and port semantics ought to be expected. 

Cheers,

---

From: Eliot Lear <[email-masked]>
Date: Tue, 01 Oct 2013 07:57:01 +0200

On 10/1/13 7:43 AM, Mark Nottingham wrote:

> However, it *will* show up in the browser, in that the security "lock" won't be in place. 

That is not what I call a strong indication.  Want to test its
effectiveness with users?

> Furthermore, note the item in "Next Steps":
>
> """

Not to the detriment of TLS.

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Oct 2013 16:00:32 +1000

> effectiveness with users?

I'm not disagreeing with you. Then again, it's already possible to perform this attack; the only difference is that the hostname will change (or not, depending on how IRIs are handled, and how creative the attacker is). 

Stronger mitigation is indeed necessary, although I disagree with your characterisation of only having three possible ways forward. 

> Not to the detriment of TLS.

Of course. We'll need to define that, though.

Regards,

---

From: Eliot Lear <[email-masked]>
Date: Tue, 01 Oct 2013 08:19:33 +0200

> I'm not disagreeing with you. Then again, it's already possible to perform this attack; the only difference is that the hostname will change (or not, depending on how IRIs are handled, and how crea…

This is more.  Here the hostname itself DOESN'T have to change.
Remember, you're dealing with a man in the middle, and so it terminates
one side and establishes a new (ironically authenticated non-relaxed
TLS) connection on the other side.  And the closer the man in the middle
is, the more attacks he can effect, so long as the browser follows the
primitive.
> Stronger mitigation is indeed necessary, although I disagree with your characterisation of only having three possible ways forward. 

Oh I imagine there are many ways forward.  Smarter people will surely
come up with something more than what I've suggested.  Heck off the top
of my head I can think of other ways forward, including the use of SSH,
but that doesn't seem to make efficient use of existing code, although
some of the concepts are relevant...

> Of course. We'll need to define that, though.

And just to be clear, RFC 2818 specifies the use of port 443, and that
clients MUST validate certs, and servers may have that very expectation.

Of course I'm not a fan of relaxed cert checking, but if you're going to
do it, consider some safer alternatives.  For instance, you could just
as easily go with Start-TLS: relaxed as a header and get the same
behavior on the same connection (this also reduces TCP overhead, as a
side effect).  That too is subject to an MITM attack, but at least it
leaves you no worse off than you are today.

Eliot