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