Subject: Discussion of Mandatory TLS in HTTP/2.0

From: Mark Nottingham <[email-masked]>
Date: Thu, 19 Jul 2012 13:55:03 +1000

[ with my Chair hat on ]

Our discussion over the last few days about requiring HTTP/2.0 to always use TLS has been interesting, but has started to generate more heat than light.

First of all, I'm going to ask everyone to refrain from making the same arguments more than once -- repetition does NOT strengthen them -- and to avoid responding to every comment made*. So far, the conversation has been dominated by a relatively small number of people and a lot of advocacy and supposition. I'd like to hear more from others.

Secondly, NONE of the proposals on the table explicitly mandate use of TLS, and therefore, any such requirement would have to be introduced as a change proposal after we choose one as a starting point (assuming we can choose one)**. 

Thirdly, my reading of the current discussion -- which is very preliminary, since we haven't even chosen a starting point -- is that there isn't yet consensus to make TLS mandatory to use for HTTP/2.0. That's not "official", just a sense of where we're at now. Clearly, whatever decision we come to, the consensus is going to be rough.

Finally, I'd encourage everyone to carefully read BCP61 <http://tools.ietf.org/html/bcp61> (hat tip to the Security ADs), as it embodies IETF policy in this area, and will doubtless guide our decisions here.

Discussing the fine details of this issue now isn't very helpful; we need to get a starting point selected first. New information about security requirements (or lack thereof) from implementers and deployers is welcome; constant back-and-forth is not.

Regards,

* If you don't take this hint, I'll be asking you to demur, first privately, then publicly, as per BCP94.

** The SPDY proposal does imply its use, and if we choose it but don't make TLS mandatory, we may have to make a number of other adjustments to compensate (especially around upgrade).

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Jul 2012 10:10:50 -0400

Could we instead discuss how we might change HTTP to remove some of
the roadblocks that currently make it difficult to deploy strong
security?

My biggest Web security concern is not the risk of passwords being
intercepted on the wire, its the fact that users have no practical
alternative to using the same password for the 100+ sites they use
that demand one.

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Jul 2012 15:19:40 +0100

> alternative to using the same password for the 100+ sites they use

Mine too, though we may have different solutions in our heads.

But, that's being addressed as part of the auth stuff which is a
different thread entirely (at a far lower temperature:-)

S

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 14:32:18 +0000

In message <[email-masked]>

>alternative to using the same password for the 100+ sites they use

I have a hard time seeing how that can be solved at the HTTP protocol
level ?

-- 
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: Ross Nicoll <[email-masked]>
Date: Thu, 19 Jul 2012 15:41:15 +0100

I'm guessing the idea would be to write an HTTP authentication protocol 
that uses public-key pairs, so a user can confirm they have a secret 
piece of information (the private key) without having to actually share 
it to do so, or by using a smaller number of authentication providers 
(for example Twitter, Facebook, Google) so they handle the password, and 
the site only gets confirmation from a trusted source that you are who 
you say you are.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Jul 2012 15:47:06 +0100

On 07/19/2012 03:41 PM, Ross Nicoll wrote:
> piece of information (the private key) 

Fine idea:-) [1]

> without having to actually share

But [1] is just one of the proposed new auth schemes [2] some
of which are more like you last bit above.

S.

[1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba
[2] http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals

>> In message
>> <[email-masked]>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 14:47:51 +0000

In message <[email-masked]>, Ross Nicoll writes:

>that uses [...]

All I can see HTTP doing, is transport opaque tokens forth and back.

If we design the protocol to do that well enough, it will support
any identification/authentication protocol you care to put on top of
it today or at a later date.

Adding "solving the second hardest problem in cryptography" to our
TODO list, is scope-creep.

---

From: Henry Story <[email-masked]>
Date: Thu, 19 Jul 2012 16:52:15 +0200

> I have a hard time seeing how that can be solved at the HTTP protocol

Though interestingly enough it can be solved at the TLS+HTTP level,
see the WebID protocol:

   http://www.w3.org/2005/Incubator/webid/spec/

which is best read with the demonstration and the explanation shown in the screen cast

   http://webid.info/

Henry

Social Web Architect
http://bblfish.net/

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 Jul 2012 09:52:08 +1000

PHK - 

Talking about possible new authentication schemes *is* in our current scope.

Thanks,

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 20 Jul 2012 17:38:49 +1000

> Finally, I'd encourage everyone to carefully read BCP61 <http://tools.ietf.org/html/bcp61> (hat tip to the Security ADs), as it embodies IETF policy in this area, and will doubtless guide our decis…

A paragraph of note in BCP61 is:

  7. MUST is for Implementors
     We often say that Security is a MUST implement.  It is worth noting
     that there is a significant different between MUST implement and MUST use.

I do think there are good arguments to make to say that browsers MUST
use confidentiality mechanism  - I just don't think that we really
want to get bogged down in debating those arguments here.
We should endeavour to make HTTP/2.0 work well for both encrypted and
clear text connections (and there is work to do to achieve that).

Also I would assume that the inverse of 7 also applies.  Just because
we implement clear text connection does not mean that users MUST use
them.  Specifically the browser/server/service vendors should be able
to choose not to use clear text connections (or at least make their
usage difficult and non default).  This would achieve a more
confidential web, but would not require that all HTTP traffic be
encrypted.

The analogy that I see is that cell phone traffic used to be
transmitted in the clear.  It is now encrypted by default, but only
when broadcast and there is no mandate that we keep the audio
confidential when we send it over the wires to our headset or when it
is bridged onto a PSTN.

regards

-- 
Greg Wilkins <[email-masked]>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.