W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Summary of my answers | Re: 160 Re: draft-ietf-httpbis-http2-encryption-04

From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Date: Mon, 21 Mar 2016 05:18:11 +0000
To: Mike Bishop <Michael.Bishop@microsoft.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP working group mailing list <ietf-http-wg@w3.org>
Message-Id: <20160321051737.34849160B@welho-filter3.welho.com>

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

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


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
Received on Tuesday, 22 March 2016 13:25:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 13:25:50 UTC