- From: Patrick McManus <pmcmanus@mozilla.com>
- Date: Mon, 7 Oct 2013 18:53:38 -0400
- To: Yoav Nir <ynir@checkpoint.com>
- Cc: Paul Hoffman <paul.hoffman@gmail.com>, "ietf-http-wg@w3.org WG" <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNrasPGOjxNigGD9rG+qGkZ=rpB5D5iEOt5dXmD2t=w_pA@mail.gmail.com>
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. -P
Received on Monday, 7 October 2013 22:54:06 UTC