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: Patrick McManus <pmcmanus@mozilla.com>
Date: Mon, 7 Oct 2013 18:53:38 -0400
Message-ID: <CAOdDvNrasPGOjxNigGD9rG+qGkZ=rpB5D5iEOt5dXmD2t=w_pA@mail.gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Cc: Paul Hoffman <paul.hoffman@gmail.com>, "ietf-http-wg@w3.org WG" <ietf-http-wg@w3.org>
On Mon, Oct 7, 2013 at 6:36 PM, Yoav Nir <ynir@checkpoint.com> wrote:

> 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.
> yoav is correct here.. browsers also have rather invasive things like
blacklists (e.g. diginotar) and might even enable features based on ciphers
or version levels. indeed http/2 demands >= TLS 1.1 :)

It's also true that the server can't know whether or not the client
performed validation; or if it did what set of CAs was used to do so or
whether revocation was checked and when, etc.... but that's equally true
today with https:// as it is with the proposed tls-relaxed. Presumably if
that was an important property to the server it wouldn't advertise them
both on the same port/npn identifier.

I strongly support the general notion of the draft, but that being said,
I'm not convinced we need to forgo validation just to do http:// over TLS.

Received on Monday, 7 October 2013 22:54:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC