Re: [secdir] secdir review of draft-ietf-httpbis-tunnel-protocol-04

[Scott Kelly <[e-mail]>]

Hi Martin,

Comments below.

On Jun 9, 2015, at 2:33 PM, Martin Thomson <[e-mail]> wrote:

> On 5 June 2015 at 05:24, Scott Kelly <[e-mail]> wrote:
>> Sorry that this review is a few days late, I hope it is still useful.
> 
> Of course it is :)
> 
>> The ALPN header allows the client to tell the proxy which protocol(s) it intends to encapsulate. This ALPN header is not authenticated, and the draft makes no reference to client authentication and/or other protocol security mechanisms, so I assume this exchange is not secured in any way.
> 
> Correct.  It's a "forward-looking statement" that couldn't be validated anyway.
> 
>> Things I think should change:
>> 
>> The draft never says what the proxy should do if the client makes one claim in the ALPN header, but then does something different (including using different ALPNs in encapsulated TLS negotiations). Seems like it should.
>> 
>> Also, the draft seems to suggest that it is okay to use the ALPN for policy/authorization decisions. This is unreliable from a security perspective. At minimum, I think the draft should explicitly call this out.
> 
> Stephen made similar comments in his review.  Those lead to the
> addition of text:
> 
> https://github.com/httpwg/http-extensions/compare/6c7b987e2b25e...master
> 
> Does that help at all?  The intent is not to let this be used for
> authorization decisions, but to allow a quick, clean "deny" decision
> to be issued.  The current state of play is pretty messy in that
> regard.
> 
> Other changes (based on other reviews) resulted in more emphasis on
> this being a hint, or an indication of intent.

I looked at the modification at the github link above, but I still have the same impression when I read the text.

RFC3552 gives guidelines for writing security considerations text, and one of the stated aims is to inform the reader of relevant security issues. I don’t think the current language does this. It states that the proxy may make policy/authorization decisions based on the ALPN header value (implying that this is generally okay). This has security implications that a non-security-savvy person may not understand.

The new language says (in part),

+          A proxy can use the value of the ALPN header field as input to
+          authorization decisions.  The header field exposes protocol
+          information at the HTTP layer, allowing authorization decisions to be
+          made earlier, with better error reporting (such as a 403 status code).

The term “authorization” evokes notions of security, at least for me. This text gives me the impression that the ALPN header is suitable for use in security decisions.

I can think of a couple of ways to address this. One easy way is to replace “authorization” with something more security-neutral (“filtering”? “allow/deny”?). Another is to simply add a statement saying this header may be falsified by either the client or a MitM, and therefore should not be relied upon for security-relevant decisions unless additional security measures are applied.

—Scott