- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 2 Jun 2016 10:08:05 +1000
- To: Erik Nygren <erik@nygren.org>, Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Mike Bishop <Michael.Bishop@microsoft.com>
> On 2 Jun 2016, at 1:34 AM, Erik Nygren <erik@nygren.org> wrote: > > On Tue, May 31, 2016 at 2:02 AM, Mark Nottingham <mnot@mnot.net> wrote: > FYI; this incorporates the discussing in WGLC. > > Please have a look at it; if any issues remain unresolved, please bring them to our attention ASAP. > > As we've been doing some detailed design of a server-side implementation, as well as had some internal security folks looking more closely, some additional items/questions have arisen: > > 1) Prohibit mixing scheme (HTTP vs HTTPS) on a connection without authenticated server-side opt-in: https://github.com/httpwg/http-extensions/issues/188 See separate thread. > 2) Is there anything that can trigger fall-back to clear-text HTTP? In particular, what is client-side handling when a server returns a 421 (Not Authoritative) over a strongly authenticated connection? Should clients error, fall back to clear-text just once, or remove their cached commitment? As I read it, if there's no tls-commit, the client can always fall back. If there is, it can't while that commitment is in effect. > 3) The text is still a little unclear on whether commit then requires subsequent connections to use "strong authentication" or just "authentication". In particular, Section 3 seems to add some confusion about whether "reasonable assurances" and "server authentication" are the same thing or not but then 5.2 sometimes uses "authenticated without "strongly authenticated". For example, this paragraph is not particularly crisp on what the requirements are (strong authentication or something else): > > A commitment is not bound to a particular alternative service. > Clients are able to use alternative services that they become aware > of. However, once a valid and authenticated commitment has been > received, clients SHOULD NOT use an unauthenticated alternative > service. Where there is an active commitment, clients SHOULD ignore > advertisements for unsecured alternative services. A client MAY send > requests to an unauthenticated origin in an attempt to discover > potential alternative services, but these requests SHOULD be entirely > generic and avoid including credentials. I had a similar reaction reading this earlier. Martin, do you want to do some tweaking, or should I have a go? Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 2 June 2016 00:08:34 UTC