- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 2 Mar 2017 14:05:24 +1100
- To: Charlie Kaufman <charliekaufman@outlook.com>
- Cc: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Charlie, Thanks. > On 2 Mar 2017, at 3:53 am, Charlie Kaufman <charliekaufman@outlook.com> wrote: > > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. > > This document specifies a protocol allowing http servers to announce to clients that they allow http queries over TLS, and for capable clients to optionally retrieve content over TLS. The intent is to protect against passive eavesdropping attacks but to never cause errors due to problems with certificates or non-support of TLS by the origin server. It does not protect against server impersonation because there is no reliable way to learn that the server implements this feature The design uses the alternative service advertisement mechanism specified in RFC7838 and appears (at least to my naïve eyes) consistent with the syntax and spirit of that spec. It includes a number of mechanisms designed to prevent hijacking attacks. > > I see no security issues with this document. It claims an intended status of Experimental, which seems surprising. I would expect this to be standards track. > > The title of the document: "Opportunistic Security for HTTP" is a little misleading since I expect many in this community would like to see opportunistic encryption for HTTP/1.1, which could not be implemented with this specification. A better title might be "Opportunistic Encryption for HTTP/2". That seems reasonable to me. See: https://github.com/httpwg/http-extensions/commit/93e79a9247ba8e734 > In general, the document has a long list of rules for when it is OK to do this and when it is not. It would be helpful to readers (and to people working on future revisions) if there were more explanations of why usage is so restricted (i.e., what could go wrong if the restrictions were ignored). I found myself wondering, for example, why server certificates needed to pass all the same restrictions as https when there is no cryptographic protection against server impersonation. I believe the answer is that without that restriction there are scenarios where the feature could make it logistically easier to impersonate a server without modifying DNS responses. But more explanation in the document would have been helpful. I understand. I'm a little reluctant to start adding rationale for each requirement en masse at this stage; it feels likely that we'd misrepresent something. > Nits: > > Last paragraph of section 1.1, there is an ambiguous antecedent. > > Furthermore, this specification is not > intended to replace or offer an alternative to "https", since it both prevents active attacks and invokes a more stringent security model in most clients. > > Should be replaced with: > > Furthermore, this specification is not > intended to replace or offer an alternative to "https", since https both prevents active attacks and invokes a more stringent security model in most clients. See: https://github.com/httpwg/http-extensions/commit/c3e04d1539 Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 2 March 2017 03:06:05 UTC