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

Hi Martin,

On 02/10/2013, at 2:02 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> 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.

What are you including in that?

The biggest for me is perf, and that's pretty much a showstopper.

>  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.

Sorry, you're going to have to expand that a bit. What escape clause is too hand-wavey?

> 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:

The server needs to know whether the cert is being validated (as discussed in a note near the end, there's more work to do on this). 

> 
> 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).

Indeed.

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

Received on Sunday, 6 October 2013 07:24:04 UTC