- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Fri, 19 Apr 2019 20:48:45 +0300 (EEST)
- To: HTTP Working Group <ietf-http-wg@w3.org>
- CC: Mike West <mkwst@google.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
HTTP State Tokens
https://tools.ietf.org/html/draft-west-http-state-tokens-00
3.3.1. Generate an HTTP State Token for an origin
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-3.3.1
| * "value": 256 cryptographically random bits.
In some cases server do not trust that these bytes are random.
That case server need defend agaist that two cliets issue
same token byte sequence (binary content) to token value on
Sec-HTTP-State: -request field.
| 4.2. The 'Sec-Http-State-Options' HTTP Header Field
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-4.2
| o Exactly one member whose key is "key", and whose value is binary
| content ([I-D.ietf-httpbis-header-structure], Section 3.10) that
| encodes an key which can be used to generate a signature over
| outgoing requests.
Key comes to play here.
Difficulty comes here that different client must got different key
but server can not trust that token is unique token value (because
purpose was defend agaist non-unique byte sequence (binary content).
Answer is not that "of course client generates unique tokens". But
that is how server can verify that. Not just trust.
Let's look options:
• Server gives same "key" for different http requests which
use same token=*xxxxx* value.
⇒ Two http clients which generate same token=t same *xxxxx* value
key.
⇒ FAILURE to defend agaist non-unique byte sequences.
• Server gives "key" once for same token=*xxxxx* value.
⇒ If that http esponse is interrupted (connection broken),
client does not got "key" at all
⇒ Generated token=*xxxxx* value is non-functional, and
site fails.
User CAN'T fix that by pressing reload.
Only fix is wait that Token Storage for that origin
is expired (after 1 hour with default "max-age"
value) or that user clears Token Storage.
• Server gives different "key" for same token=*xxxxx* value
on different requests.
⇒ Server needs allocate state for (token,key) pair
AND match "sig" again every key for given token
⇒ Browser may have lauched many concurrent
request for same origin, therefore same token
(and without sig, because key os not yet given).
⇒ This leads many (token,key) pairs and many states
on server.
⇒ This is make processing of request including
"sig" expensive and causes that different
request have used different state on server
(because different (token,key) pair) until
last key is received by browser.
My solution:
‣ Browser needs some URL which it uses only
to get key.
‣ Server gives different "key" for same token=*xxxxx* value
on different requests but only for that special URL.
On <20180819081635.7C1E4229D@welho-filter3.welho.com>
https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0222.html
I suggested /.well-known/ path for that.
But now I suggest another URL.
I have not determined what should be request method
for that URL and what to do with response (except that
Sec-Http-State-Options: response header is processed)
and response body (if request method is GET).
4.2. The 'Sec-Http-State-Options' HTTP Header Field
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-4.2
----
o Exactly one member whose key is "register" and whose value is an
string ([draft-ietf-httpbis-header-structure-10], Section 3.8)
representing a path which http request response will
give "key" for this Http State.
User Agent will use that path only when Http State does not
include value for "key". Value of "register" is NOT saved
HTTP State Token.
-----
6. Configuring HTTP State Tokens
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-6
( Assume changes for my suggestion "cross-site"
<20190414101536.3A23E45C0E@welho-filter4.welho.com>
https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0037.html
)
| 2. Return without altering "response-origin"'s HTTP State Token
| if any of the following conditions hold:
new substep
⇒
-----
+ "header" has a member named "register" whose value is not a
string ([draft-ietf-httpbis-header-structure-10], Section 3.8).
-----
| 6. If the response's header list contains "Sec-Http-State-Options",
| then:
new substep
⇒
-----
6. If "header" has a member named "register":
1. If value of "register" member does
not match syntax of origin-form
([RFC 7230], Section 5.3.1),
skip next steps.
2. Let "register URL" to be catenation
"response-origin" and value of "register" member.
3. If "token"'s "key" is set, skip next steps.
4. if "fetch register" is scheduled (but not completed)
for "response-origin", skip next steps.
5. If this "HTTP-network-or-cache fetch" is called
from "fetch register" algorithm, skip next steps.
Note: This prevents loop where every "fetch register"
causes new "fetch register" to be scheduled.
That happens if response still have "register"
on "Sec-Http-State-Options".
( TBD: Is this working? Should HTTP-network-or-cache fetch
have optional "register-fetch flag" ? )
6. Schedule "fetch register" for "response-origin"
with following parameters
+ "origin" is given "response-origin"
+ "URL" is given "register URL"
+ "client" is request's "client"
from this execution of HTTP-network-or-cache fetch
( ? TBD ? )
+ "credentials mode" is request's "credentials mode"
from this execution of HTTP-network-or-cache fetch
( ? TBD ? )
+ "destination" is request's "destination"
from this execution of HTTP-network-or-cache fetch
( ? TBD ? )
+ "window" is request's "window"
from this execution of HTTP-network-or-cache fetch
+ TBD
-----
Addition
⇒
-----
"fetch register" algorithm is following:
1. let "request" have following associated data:
+ "method" is "GET" if parameter "destination"'s value is "document"
"method" is "HEAD" otherwise
( TBD: what is correct "method" ? -- depends what we want to do with response body?
Or should methed be "OPTIONS" ? This is also likely avoid caches.
)
+ "origin" is parameter "origin"'s value
+ "URL" is parameter "URL"'s value
+ "client" is parameter "client"'s value
+ "credentials mode" is parameter "credentials mode"'s value
+ "destination" is parameter "destination"'s value
+ "window" is parameter "window"'s value
+ "referer" is "no-referrer"
+ "cache-mode" is "reload"
+ (TBD? should "redirect mode" be "error" ? )
+ (TBD? Maybe this)
"header list" includes
"Cache-Control" / "no-cache, no-store"
+ TBD
( TBD: Actually just is is wanted that
"Sec-Http-State" request header field is reached
server maintaining state, and
that "Sec-Http-State-Options" response header
field is one shot and comes from server maintaining state
and not cached.
Response may include
Cache-Control: no-cache=Sec-Http-State-Options
but is this implemented?
Cache on TLS terminator probably ignores requests
Cache-Control anyway.
In theory
Cache-Control: no-store
should be enough, because no-store forbid using cache
at all.
)
2. Assert: "credentials mode" of "request" is either
"include" or "same-origin"
3. Execute "HTTP-network-or-cache fetch" for "request"
Note: This causes that this Configuring HTTP State Tokens
-algorithm is executed also for that fetch register
-algorithm and therefore possible "key" is set if
returned on "Sec-Http-State-Options".
Because this uses "HTTP-network-or-cache fetch" and
not "HTTP fetch" algorithm, this is not exposed
to a service worker (but also redirects from
from the network are not exposed either).
3. TBD: handling of response body
Do we want this work as some kind redirection where response
replaces current document if there is response body ?
(and updates URL of that also)
Probably does not make sense.
Thish makes sense only when "destination" is "document"
on original fetch which caused "fetch register" scheduled.
Or is response body some kind special xml or json
type, which is parsed hdere.
Or shouild here show error message when that fetch fail
(probably just show that response body) ?
Received on Friday, 19 April 2019 17:49:18 UTC