Subject: Re: Secdir review of draft-ietf-httpbis-http2-encryption-10

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Mar 2017 14:05:24 +1100

Hi Charlie,

Thanks.

> On 2 Mar 2017, at 3:53 am, Charlie Kaufman <[email-masked]> 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/

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 14:25:12 +1100

>> 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.

That's maybe *part* of the reason, which is to say that I'm not 100%
confident that I could write down exactly why in a way that wouldn't
be  either subtly wrong, or in other ways act as an irritant.  For
instance, I think that part of the reason is that it is just so damned
easy to get a valid cert that we create the more incentives to deploy
a server that could do HTTPS, even when that is not possible for other
reasons.  But then, it's entirely possible that the real reason is
subjective.  That's why I agree with Mark:

> 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.