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

Added https://github.com/httpwg/http-extensions/issues/161 and https://github.com/httpwg/http-extensions/issues/162 based on an offline fork of this thread.

Kari, do those two issues capture your concerns here?

-----Original Message-----
From: Kari Hurtta [mailto:hurtta-ietf@elmme-mailer.org] 
Sent: Thursday, March 17, 2016 10:02 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>; Kari Hurtta <hurtta-ietf@elmme-mailer.org>; HTTP working group mailing list <ietf-http-wg@w3.org>; Mike Bishop <Michael.Bishop@microsoft.com>
Subject: Re: 160 Re: draft-ietf-httpbis-http2-encryption-04

Martin Thomson <martin.thomson@gmail.com>: (Fri Mar 18 04:14:27 2016)
> On 18 March 2016 at 12:19, Mark Nottingham <mnot@mnot.net> wrote:
>>> 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.
> 
> HI Kari,
> 
> I'm having a lot of trouble parsing your request.  I don't know 
> exactly what you are asking for.
> 
> Do you want "commit" and "reasonable assurances" to be separable?  I 
> don't think that it is possible to process "commit" without first 
> processing (and passing) the "reasonable assurances" test.  We could 
> spell this out.
> 
> --Martin

1) "commit" requires that part:

| 6. The "http-opportunistic" well-known URI
| 
|    This specification defines the "http-opportunistic" well-known URI
|    [RFC5785].  An origin is said to have a valid http-opportunistic
|   resource when:
|
|   o  The client has obtained a 200 (OK) response for the well-known URI
|      from the origin, or refreshed one in cache [RFC7234], and
|
|   o  That response has the media type "application/json", and
| 
|    o  That response's payload, when parsed as JSON [RFC7159], contains
|      an object as the root.
|
|   o  The "origins" member of the root object has a value of an array of
|      strings, one of which is a case-insensitive character-for-
|      character match for the origin in question, serialised into
|      Unicode as per [RFC6454], Section 6.1, and
|
|   This specification defines one additional, optional member of the
|   root object, "commit" in Section 5.  Unrecognised members MUST be
|   ignored.

2) "commit" requires that part:

|   The value of the "commit" member MUST be ignored unless the
|   alternative service can be strongly authenticated. 

3) "commit" does not requre (and need not require) this part:

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

4) I suggested (or asked) that should commit require also that part:

|   o  The chosen alternative service returns the same response as above.


5)

I'm trying to say that there should be possible to say "commit"
without applying this part:

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


My suggestion was adding (to this part)

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

but also adding

+   o  The http-opportunistic response do not have "commit" as member of the 
+      root object.

does that. However, that later is more restrictive.

Note http-opportunistic may be valid when there is "commit" and "commit"
does not apply:

|   alternative will remain available for the commitment interval.  The
|   commitment interval starts when the commitment is received and
|   authenticated and runs for a number of seconds equal to value of the
|   "commit" member, less the current age of the http-opportunistic
|   response (as defined in Section 4.2.3 of [RFC7234]). 


GET /.well-known/http-opportunistic HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 14 Mar 2016 06:38:55 +0200
Expires: Tue, 14 Mar 2017 06:38:55 +0200
Age: 172800
Content-Type: application/json
Connection: close

{
 "origins": ["http://example.com", "http://www.example.com"],
 "commit": 86400
}


This now specifies reasonable assurances for unauthenticated alternative services on www.example.com.


Also it is possible that client is not implemented "commit" but is implemented reasonable assurances for unauthenticated alternative services. Implementing that "commit" part is optional. 

Or what I have missed?

( If "valid-ports" also was required for reasonable assurances  of unauthenticated alternative services, then this does  not happen accidentally. )


I think that Mike Bishop noted that also (with different suggestion).


/ Kari Hurtta

Received on Friday, 18 March 2016 22:22:14 UTC