W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 1 Oct 2013 21:02:06 -0700
Message-ID: <CABkgnnW+qvsgop-b5_G5=Ga5r_Uy1dnzDe+y==1LENNLjqmHjg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org WG" <ietf-http-wg@w3.org>
On 30 September 2013 17:54, Mark Nottingham <mnot@mnot.net> wrote:
> 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.

Having thought about this at great length, I wonder why Upgrade isn't
appropriate here, aside from the obvious deficiencies we've already
identified.  After all, we're already requiring the use of Upgrade for
HTTP/2.0 (at least for the in-the-clear cases).  The use of the header
seems unnecessary, and with the same-hostname restriction bound to it
(the escape clause too hand-wavey for me to take it seriously), it's
effectively the same.

I also wonder why you bothered to introduce the concept of a
"http2-tls-relaxed" profile.  To my mind, since the decision to use
TLS for the "http" resource was discretionary on the part of the
client, then the decision to validate the server certificate is
equally discretionary.  I would have thought that the logic would go
something like:

1. If https: then start with TLS from the outset
2. If http: then try to get to TLS somehow
3. If https: then make sure the certificate is good, fail if bad
4. make request
5. if https: display secure indicators

I don't see how anything that the server might say would affect this.
If the certificate is self-signed or otherwise not "good", then the
http requests simply won't block based on that.  That too is
discretionary.  I could imagine all sorts of other discretionary
measures that clients might take (like certificate pinning of a kind;
for instance, knowing that example.com always presents a genuine
certificate might cause alarm if they suddenly stop doing so).
Received on Wednesday, 2 October 2013 04:02:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC