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

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Mar 2016 13:14:27 +1100

On 18 March 2016 at 12:19, Mark Nottingham <[email-masked]> 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

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 18 Mar 2016 05:01:35 +0000

Martin Thomson <[email-masked]>: (Fri Mar 18 04:14:27 2016)
> processing (and passing) the "reasonable assurances" test.  We could

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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Mar 2016 22:21:44 +0000

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:[email-masked]] 
Sent: Thursday, March 17, 2016 10:02 PM
To: Martin Thomson <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; Kari Hurtta <[email-masked]>; HTTP working group mailing list <[email-masked]>; Mike Bishop <[email-masked]>
Subject: Re: 160 Re: draft-ietf-httpbis-http2-encryption-04

>>> There should be possible to give "commit" for authenticated 
>>> alternatives WITHOUT giving also reasonable assurances for 
>>> non-authenticated alternatives (on same host that origin).
>>> 
>>> that for reasonable assurances. My suggestion for that parameter is 
>>> same than for "Attacks from the same host".
>> 

5)

but also adding

HTTP/1.1 200 OK

{

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

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 21 Mar 2016 05:18:11 +0000

Summary of my previous answers (was not posted to list).

> Kari, do those two issues capture your concerns here?

Mostly (but not completely).

About

Separate lifetime from commitment element #162 
https://github.com/httpwg/http-extensions/issues/162

I also mentioned:

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

Separate lifitimes are not only issue here.

If "commit" part is not implemented, current
text makes all "http-opportunistic" act as
same-host which was not purpose.

> Explicitly state a desired mode of behavior (strong-auth only, same-host only, 
> same-host or strong auth, etc.) and optionally a lifetime. This is harder to extend 
> in the future, but may be the clearest today.

My suggestion was explicit parameter which presence tells
that "http-opportunistic" is used same-host.

Every usage of "http-opportunistic" opt-in with own paramater.

 - strong auth with "commit" parameter
 - same-host with new parameter (my suggestion is
       "valid-ports" but nobody seems agreed)

I think that this is clearest and easy to extend.
Every usage work on isolation and need not know
parameters used on other usage (if they are not 
implemented).

When "http-opportunistic" is used for strong auth, server
author sure things that Alt-Svc: header fields injected
by user are not problem. I considered that to be trap on here.
Explicit usage parameters solve this.

Explicit usage parameters also solve situation where client
implement only some usage of "http-opportunistic".

Remaining concern is that also browser should be possibility
to check validity that given Alt-Svc is authorative for
whole origin (and not something what should have authority
only for some subpart of path space.) But nobody seems agreed.

That  

Requirement to filter Alt-Svc header needs explicit normative text #161 

definately makes that my remaining concern smaller. 
Currently there no guarantees for browser. After that 
requirement there is less need for browser check 
validity that given Alt-Svc is authorative for whole origin.
( I like however that there is option for browser
 for that check. )

I have several posts which I have not addressed or
adressed only partially. So may be that this is not
all.

But looks better.

===========

Actually there is also third case

"commit" is only force after client 
received Alt-Svc: for strong auth

If before that client receives Alt-Svc:
for same host, that "http-opportunistic"
gives permission for weak same-host cross-port 
alternative service.

> it's possible for the end result to be that a client believes the
> server has consented to weak cross-port alternatives after the
> commitment has expired.

  ... OR before the commitment has started.

Problem is on both end of lifetime !

Summary:

    Client believes the server has consented to weak cross-port,
    if

    1)  commitment has not been started yet,
    2)  client does not implement commitment, or
    3)  commitment has expired

========================

> I think that I understand your concern now.  You are concerned that
> the server might advertise a weak signal: that port X is OK.  AND you
> want to have additional protection (strong authentication) required
> for that.

Server may advertise weak signal when it things that it is only
strong signal.  And therefore does not consider that Alt-Svc:
issued by users are problem.  After all /.well-known/http-opportunistic 
says "commit" so it looks that browser or http clients
will not use Alt-Svc: issued by http://homepages.example.com/~hurtta/

Therefore filtering of Alt-Svc: is not radar of
server admins and server authors.

===========================

Correspond mails should be includes on below (may
be visible as attachment on some mail clients. )

/ Kari Hurtta

Mostly (but not completely).

About

Separate lifetime from commitment element #162 
https://github.com/httpwg/http-extensions/issues/162

I also mentioned:

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

Separate lifitimes are not only issue here.

If "commit" part is not implemented, current
text makes all "http-opportunistic" act as
same-host which was not purpose.

> Explicitly state a desired mode of behavior (strong-auth only, same-host only, 
> same-host or strong auth, etc.) and optionally a lifetime. This is harder to extend 
> in the future, but may be the clearest today.

My suggestion was explicit parameter which presence tells
that "http-opportunistic" is used same-host.

Every usage of "http-opportunistic" opt-in with own paramater.

 - strong auth with "commit" parameter
 - same-host with new parameter (my suggestion is
	"valid-ports" but nobody seems agreed)

I think that this is clearest and easy to extend.
Every usage work on isolation and need not know
parameters used on other usage (if they are not 
implemented).

When "http-opportunistic" is used for strong auth, server
author sure things that Alt-Svc: header fields injected
by user are not problem. I considered that to be trap on here.
Explicit usage parameters solve this.

Explicit usage parameters also solve situation where client
implement only some usage of "http-opportunistic".

Remaining concern is that also browser should be possibility
to check validity that given Alt-Svc is authorative for
whole origin (and not something what should have authority
only for some subpart of path space.) But nobody seems agreed.

That  

Requirement to filter Alt-Svc header needs explicit normative text #161 

definately makes that my remaining concern smaller. 
Currently there no guarantees for browser. After that 
requirement there is less need for browser check 
validity that given Alt-Svc is authorative for whole origin.
( I like however that there is option for browser
 for that check. )

I have several posts which I have not addressed or
adressed only partially. So may be that this is not
all.

But looks better.

/ Kari Hurtta

Actually there is also third case

"commit" is only force after client 
received Alt-Svc: for strong auth

If before that client receives Alt-Svc:
for same host, that "http-opportunistic"
gives permission for weak same-host cross-port 
alternative service.

> it's possible for the end result to be that a client believes the
> server has consented to weak cross-port alternatives after the
> commitment has expired.

  ... OR before the commitment has started.

Problem is on both end of lifetime !

Summary:

    Client believes the server has consented to weak cross-port,
    if

    1)  commitment has not been started yet,
    2)  client does not implement commitment, or
    3)  commitment has expired

>> Explicitly state a desired mode of behavior (strong-auth only, same-host only, 
>> same-host or strong auth, etc.) and optionally a lifetime. This is harder to extend 
>> in the future, but may be the clearest today.
> 
> My suggestion was explicit parameter which presence tells
> that "http-opportunistic" is used same-host.
> 
> Every usage of "http-opportunistic" opt-in with own paramater.
> 
>  - strong auth with "commit" parameter
>  - same-host with new parameter (my suggestion is
> 	"valid-ports" but nobody seems agreed)
> 
> I think that this is clearest and easy to extend.
> Every usage work on isolation and need not know
> parameters used on other usage (if they are not 
> implemented).
> 
> When "http-opportunistic" is used for strong auth, server
> author sure things that Alt-Svc: header fields injected
> by user are not problem. I considered that to be trap on here.
> Explicit usage parameters solve this.

/ Kari Hurtta

Server may advertise weak signal when it things that it is only
strong signal.  And therefore does not consider that Alt-Svc:
issued by users are problem.  After all /.well-known/http-opportunistic 
says "commit" so it looks that browser or http clients
will not use Alt-Svc: issued by http://homepages.example.com/~hurtta/

Therefore filtering of Alt-Svc: is not radar of
server admins and server authors.

I'm saying that multi-purpose of /.well-known/http-opportunistic
is trap. Specially when it is advertising that all ports on server
are OK and port advertising is implicit (not explicitly marked on
/.well-known/http-opportunistic).

> That isn't the intent of the document.  The commitment is there to
> protect against downgrade, not provide the server additional
> protection against itself.  If the server can't filter Alt-Svc
> advertisements, and if the server can't protect .well-known, then it
> can't stop someone with shell or CGI access from hijacking the server.
> Commit won't help.
> 
> Think of this as a migration path:
> 
> http in the clear -> https with no authentication -> https with
> authentication and commitment
> 
> Any weakness in the first upgrade is inherited by the second upgrade;
> you can't use properties of the second upgrade to "fix" the first
> upgrade.  It only stops a downgrade to the initial state.

/ Kari Hurtta