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

On Oct 7, 2013, at 8:00 PM, Paul Hoffman <paul.hoffman@gmail.com> wrote:

> We're talking around the same problem. What Mark has proposed allows the HTTP server to tell the HTTP client two different things:
> - The server has an https version of the origin available
> - The https version of the origin is / is not expected to validate
> 
> My belief is that HTTP clients do not have enough communication with their TLS stacks to be able to use the second piece of information in a secure fashion; thus, it should be removed.

I don't think that is correct. In most browsers, when a server's certificate (chain) doesn't validate, you get some warning screen that allows you to click through. That means that the TLS stack informs the browser that validation failed, and the browser can tell the TLS stack to do it again, but ignore validation failures. Even cURL and wget have parameters that tell them to not validate certificate. So if a web client gets the second piece of information, it can tell the TLS layer to connect without validation, or it can try TLS with validation , and if that fails, the browser can tell the TLS layer to proceed without validation, even without showing a scary screen to the user.

> Your preference seems to be that we fix TLS so that a web site can offer TLS in a way that a TLS client would not expect it to validate. That seems fine, except then there also has to a way to communicate that to both the HTTP client *and* the HTTP server. Do not assume that an HTTP server knows the type of certificate and/or validation that is done.

A server without a certificate could still do ADH, and that gives us encrypted HTTP without all the PKI. If we install a certificate, we'd have to tell the HTTP server whether that certificate is going to validate or not.

Received on Monday, 7 October 2013 22:37:18 UTC