- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 12 Dec 2013 18:46:27 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 12 December 2013 15:56, Mark Nottingham <mnot@mnot.net> wrote: > That's true, *if* clients implement the http2-tls protocol identifier semantics uniformly; otherwise, they won't know whether they need to offer a valid certificate to upgrade to that protocol. Right, I guess that I had assumed that you hadn't made that leap yet. As in, clients would not be able to expect a good certificate if they had followed their noses to the other end of an http: URI. That was kinda the point of the rest of my mail: there is no point in raising the bar that high because all that does is chase people back to 1.1. > Now, if no one is interested in using TLS with authentication for http:// URIs, this problem (probably) goes away. The one thing that worries me a tiny bit is that a browser's position about what an acceptable mix of security characteristics might change over time, and if it does, we may need this distinction again. However, since we're using draft identifiers, it's not a huge risk. I think that there will be a continuing evolution of what the security properties of each of the schemes is. But I hope that this isn't going to lead to states of disconnect where each end has very different expectations. Maybe we can eliminate the differences; I remain a little skeptical about that though. > Based on this discussion, it sounds like I can go ahead and remove h2r and refine the semantics of h2t to include the HTTP URI use case (i.e., no auth if on the same host, strong auth if on a different host). Noting that the distinguishing mark here is the 's', sure.
Received on Friday, 13 December 2013 02:46:54 UTC