Re: draft-ietf-httpbis-http2-encryption-04

Hi Kari,

> On 18 Mar 2016, at 5:35 AM, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> 
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04
> Opportunistic Security for HTTP
> 
> 
> 1)
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-3
> 3. Server Authentication
> 
> 
> |   For example, this request/response pair would constitute reasonable
> |   assurances for the origin "http://www.example.com" for any
> |   alternative service also on "www.example.com":
> |
> |   GET /.well-known/http-opportunistic HTTP/1.1
> |   Host: www.example.com
> |
> |   HTTP/1.1 200 OK
> |   Content-Type: application/json
> |   Connection: close
> |
> |   {
> |     "origins": ["http://example.com", "http://www.example.com:81"]
> |   }
> 
> 
> Origin "http://www.example.com" is mentioned on text,
> Origin "http://www.example.com" is NOT mentioned on /.well-known/http-opportunistic.

Thanks, fixed in -latest.


> 2) 
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-8
> 8. Security Considerations
> 
> For "Attacks from the same host" this makes silent assumption that
> /.well-known/http-opportunistic indicates that there is not injected
> bad Alt-Svc: -headers.
> 
> In other words Alt-Svc: -headers are assumed to be filtered 
> out from attackers (shared hosting), but that assumption is not
> spelled out on draft.

Yes. Any suggested text here (Kari or someone else)?



> 3) 
> 
> I disagree resolution of "Attacks from the same host".
> 
> My long explanation is on
> 
>   Re: [Moderator Action] #144: Attacks from Same Host (OppSec)
>   https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0411.html
>   Message-Id: <20160313174847.DD97B389F@welho-filter4.welho.com> 
> 
> Effectively browser's (or http client's) method to defend this 
> attack is still that browser ignores alternative service 
> if port >= 1024
> 
> If /.well-known/http-opportunistic does not include lists
> alternatives or list of valid ports where alternative service
> is supposed to be located, that ignoring port >= 1024 is best 
> guess what browser can do.
> 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0111.html
> 
> Patrick McManus wrote:
> 
> | I'm actually glad the port number nonsense got called out. It didn't have
> | real value and its the kind of window dressing only a committee could love
> | (I say lovingly, as member of said committee.).
> 
> I'm not sure about that because draft-ietf-httpbis-http2-encryption does not
> provide other defenses for browser.
> 
> I originally suggested that:
> 
> | How about requiring that alternative service are also listed on
> | /.well-known/alternative-services
> | 
> | Pre-Alt-Svc servers do not provide /.well-known/alternative-services
> | and eve can not provide /.well-known/alternative-services on
> | original service.
> | 
> | I think that this stops that attack if http client also checks
> | /.well-known/alternative-services when alternative service
> | does not provide strong auth. This of course adds additional delay
> | before alternative service is used.

Does anyone else agree with Kari's concerns around <https://github.com/httpwg/http-extensions/issues/144>?  If so, now is the time to speak up.

Mike, please track this issue as potentially contentious.


> Current draft does not provide for client means to do check with 
> /.well-known/http-opportunistic resource. Therefore port number
> check is still on table.

Can you please explain what you mean by "Current draft does not provide for client means to do check with /.well-known/http-opportunistic resource."? The draft requires http-opportunistic to be checked when strong authentication is not available. 


> 4)
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-5.1
> 5.1. Opportunistic Commitment
> 
> 
> |   An origin can reduce the risk of attacks on opportunistically secured
> |   connections by committing to provide an secured, authenticated
> |   alternative service.  This is done by including the optional "commit"
> |   member in the http-opportunistic well-known resource (see Section 6).
> 
> This does not make possible to specify "commit" without saying same time that 
> there is also reasonable assurance for alternative services for on same host
> which does not provide strong authentication.
> 
> There should be possible to give "commit" for authenticated alternatives
> WITHOUT giving also reasonable assurances for non-authenticated alternatives
> (on same host that origin).
> 
> /.well-known/http-opportunistic SHOULD include separate indication
> that for reasonable assurances. My suggestion for that parameter is same than 
> for "Attacks from the same host".

Raised as <https://github.com/httpwg/http-extensions/issues/160>. Please discuss.


> 5)
> 
> My suggestion for 
> 
>  3. Server Authentication
>  https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-3
> 
> |   When the client has a valid http-opportunistic response for an
> |   origin, it MAY consider there to be reasonable assurances when:
> |
> |   o  The origin and alternative service's hostnames are the same when
> |      compared in a case-insensitive fashion, and
> |
> |   o  The chosen alternative service returns the same response as above.
> +
> +   o  The "valid-ports" member of the root object on the http-opportunistic 
> +      response has a value of an array of numbers, one of which is same
> +      value than alternative service's port number.
> 
>   6. The "http-opportunistic" well-known URI
>   https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-6
> 
> -   This specification defines one additional, optional member of the
> -   root object, "commit" in Section 5.  Unrecognised members MUST be
> -   ignored.
> 
> ⇒
> 
> +   This specification defines two additional, optional members of the
> +   root object, "commit" in Section 5 and "valid-ports" in Section 3.  
> +   Unrecognized members MUST be ignored.
> 
> 
> That "valid-ports" member makes explicit which port numbers are under
> origin's control. So there not need make assumption like port numbers 
> <= 1024 are safe.
> 
> This also makes clear for which purpose /.well-known/http-opportunistic is.
> There is either "commit" or "valid-ports" member on http-opportunistic 
> response. (It is unlikely that both on same time makes sense. )
> 
> Because this also requires that origin and alternative service's hostnames 
> are same, listing port numbers effectively lists alternative
> services (except that protocol is not mentioned, "h2" is only 
> protocol which fulfills requirements). 
> 
> That list of port number or alternative services on http-opportunistic 
> response does not indicate that alternative service is provided on these
> ports, only that alternative services may be provided on these ports
> without valid certificate. This does not replace Alt-Svc: -header field.

This is a proposal for <https://github.com/httpwg/http-extensions/issues/144>, correct?


> 6)
> 
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-5.1
> 5.1. Opportunistic Commitment
> 
> 3. Server Authentication requires that
> 
> | The chosen alternative service returns the same response as above.
> 
> Should there be same requirement before "commit" is accepted ?
> Now that is not required for commit.

It's required for server authentication so that there's an assurance that both the origin and alternative opt into the equivalence.

What function would it serve for the commitment?


Thanks for the feedback,

--
Mark Nottingham   https://www.mnot.net/

Received on Friday, 18 March 2016 01:20:00 UTC