- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Sun, 14 Apr 2019 13:15:29 +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
Servers assume that client does not support HTTP State Tokens
when request does not include Sec-Http-State: header field, I
assume.
Then server generate session state itself and includes
Set-Cookie: response header. In that situation it does
not make sense to add Sec-Http-State-Options: response
header, because Cookie is already requested (with associated
session state).
Therefore there is also two problems with cross-site
requests (and not only with delivery=same-origin).
1) "delivery=cross-site" case:
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 "delivery", and whose value is one
| of the following tokens ([I-D.ietf-httpbis-header-structure],
| Section 3.9): "same-origin", "same-site", or "cross-site".
This does not work for delivery=cross-site
Default is delivery=same-site and therefore initial request
does not include Sec-Http-State: header field. Server
can not just return Sec-Http-State-Options: response
header field, because server does not know that is this
initial request or was server already returned
Sec-Http-State-Options: response header field.
Therefore server needs return Set-Cookie: response header field
(and allocate state for client).
Because state for client is allocated and Set-Cookie: response
header field is added to response, it does not make sense
also add Sec-Http-State-Options: response
header field.
Therefore initial request needs
Sec-HTTP-State: token=query
also on cross-site requests.
2) cross-site requests when state is not wanted:
Server (probably) does not know that request is cross site
and because request does not include Sec-Http-State: header field
server assumes that HTTP State Tokens are not supported.
Therefore server adds Set-Cookie: response
header field (with SameSite flag) to response and
allocate state for client. That state is wasted.
Therefore cross-site requests needs
Sec-HTTP-State: token=void
when "delivery" is know (and "delivery" is not "none" (1)) and
token value is not allowed to be returned.
Note: Of course that same problem for server is also
when client does not support HTTP State Tokens.
But using of HTTP State Tokens need to provide
some advantage for server, otherwise server
make sense use only cookies. Code for cookies
is needed anyway, because all clients does not
support HTTP State Tokens.
3) also same-domain requests when state is not wanted:
Server have returned
Sec-Http-State-Options: delivery=same-origin
on first request.
Second request does not include Sec-Http-State: header field.
Also here server (probably) does not know that request
is not same-origin request and because request does not
include Sec-Http-State: header field server assumes that
HTTP State Tokens are not supported.
Therefore server adds Set-Cookie: response
header field (with host cookie) to response and
allocate state for client. That state is wasted.
Therefore same domain (but not same origin) requests needs
Sec-HTTP-State: token=void
when "delivery" is know (and "delivery" is not "none" (1)) and
token value is not allowed to be returned.
(*) delivery=none, where server want mimize request size, is exception.
This delivery=none is not state for user opt out. Suggested on
<20190328190729.F36474EEEA@welho-filter4.welho.com>
https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0251.html
Giving
Sec-HTTP-State: token=void
may also deflect some attacks, where otherwise server is tricked
to use data from less secure Cookie: -request header field.
If server uses HTTP State Tokens and Cookie for similar purpose,
server should ignore correspond Cookie: -request header field
when Sec-HTTP-State: -request header field is present (even when token
does not include base64 encoded byte sequence).
Sec-HTTP-State: -request header field's token values are
syntactically different, when it is a byte sequence (sh-binary,
[draft-ietf-httpbis-header-structure-09], Section 3.10) and
when it is a token (sh-token, [draft-ietf-httpbis-header-structure-09],
Section 3.9).
This solution extens my "delivery=same-origin" suggestion
( <20190410165945.583F545C5D@welho-filter4.welho.com>
https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0026.html
)
Changes mentioned on my "delivery=same-origin" suggestion should
also be assumed.
This solution is also variant of my "Server/Site opt-in" suggestion
( <20190403182945.069B4C3F26@welho-filter2.welho.com>
https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0007.html
That my "Server/Site opt-in" suggestion also needs
some changes yet. It does not work well on subresources
which need user opt in / opt out.
)
On another mail I suggested to replace "same-site" with "same-domain".
I mark this now as "same-site" [or "same-domain"].
( <20190407171006.AD9EEB38@welho-filter3.welho.com>
https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0013.html
)
To avoid initial
Sec-HTTP-State: token=query
wanted "delivery" value for origin need to be cached separatetely
from Token Storage and with longer cache time than 1 hour (for
example 50 hours). That may be then used when HTTP State Token is
generated for origin. However I do NOT now include changes
for separate "delivery" value for origin cache.
Changes are:
3.1. HTTP State Tokens
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-4.2
( as on "delivery=same-origin" suggestion <20190410165945.583F545C5D@welho-filter4.welho.com> )
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
( as on "delivery=same-origin" suggestion <20190410165945.583F545C5D@welho-filter4.welho.com> )
4.1. The 'Sec-Http-State' HTTP Header Field
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-4.1
4.1. The 'Sec-Http-State' HTTP Header Field
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-4.1
| o Exactly one member whose key is "token", and whose value is binary
| content ([I-D.ietf-httpbis-header-structure], Section 3.9) that
| encodes the HTTP state token's value for the origin to which the
| header is delivered.
|
| If the "token" member contains more than 256 bits of binary
| content, the member MUST be ignored.
⇒
----
o Exactly one member whose key is "token". Value of this key
is either a byte sequence (sh-binary,
[draft-ietf-httpbis-header-structure-09], Section 3.10) or a
token (sh-token, [draft-ietf-httpbis-header-structure-09], Section 3.9).
The byte sequence encodes the HTTP state token's value for the origin to which the
header is delivered. This is a binary content.
If the "token" member contains more than 256 bits of binary
content, the member MUST be ignored.
The token value (as sh-token) is "query" or "void".
Value "query" indicates that http client supports HTTP state tokens, but
needs value for "deliver".
Value "void" indicates that http client supports HTTP state tokens, but
"deliver" does not allow returning of a byte sequence.
4.2. The 'Sec-Http-State-Options' HTTP Header Field
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-4.2
( as on "delivery=same-origin" suggestion <20190410165945.583F545C5D@welho-filter4.welho.com> )
5.1. Attach HTTP State Tokens to a request
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-5.1
| 5. If "request-token" is "null", then:
|
| 1. If "request"'s delivery scope is "cross-site", return
| without modifying the request.
|
| Note: As the default "delivery" for HTTP State Tokens is
| "same-site", we return early rather than generating a token
| for a cross-site request.
|
| 2. Set "request-token" to the result of generating an HTTP
| State Token for "target-origin", as defined in
| Section 3.3.1.
⇒
----
5. If "request-token" is "null", then:
1. If "request"'s delivery scope is "cross-site", then
execute "attach query" and skip the remaining steps in this
algorithm.
2. Set "request-token" to the result of generating an HTTP
State Token for "target-origin", as defined in
Section 3.3.1.
-----
After step 5 add following steps:
⇒
----
5a. If "request-token"'s "delivery" is "null", then skip the remaining steps in
this algorithm, and return without modifying the request.
5b. If "request-token"'s "delivery" is "query", then
execute "attach query" and skip the remaining steps in this
algorithm.
----
| 6. Return without modifying the request if either of the following
| statements are true:
|
| * "request-token"'s "delivery" is "same-origin", and
| "request"'s delivery scope is not "same-origin".
|
| * "request-token"'s "delivery" is "same-site", and "request"'s
| delivery scope is neither "same-origin" nor "same-site".
⇒
----
6. Execute "attach void" and skip the remaining steps in this
algorithm if either of the following statements are true:
* "request-token"'s "delivery" is "same-origin", and
"request"'s delivery scope is not "same-origin".
* "request-token"'s "delivery" is "same-site" [or "same-domain"] ,
and "request"'s delivery scope is neither "same-origin" nor
"same-site" [or "same-domain"].
----
( Step 8. as on "delivery=same-origin" suggestion <20190410165945.583F545C5D@welho-filter4.welho.com> )
Addition:
⇒
----
"attach query" algoritm is following:
1. The user agent MAY omit generating Sec-Http-State: request
header if it determines that origin does not support
HTTP State Tokens.
It is not required that all URL's for the origin
responds with Sec-Http-State: response header
for query.
Note: Sec-Http-State: response header for query
may be genrated only for certain URLs
(for example login and/or front page's
URLs).
2. Insert a member into "header-value" whose key is "token" and
value is "query" (using sh-token syntax). Note that sh-syntax
does not use quotes.
"attach void" algoritm is following:
1. Insert a member into "header-value" whose key is "token" and
value is "void" (using sh-token syntax). Note that sh-syntax
does not use quotes.
----
6. Configuring HTTP State Tokens
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-6
( Original step 5. does not make sense, there is no request to modify !!!
This is response processing !!!
)
| 5. If "token" is "null", then:
|
| 1. If "request"'s delivery scope is "cross-site", return without
| modifying the request.
|
| Note: As the default "delivery" for HTTP State Tokens is
| "same-site", we return early rather than generating a token
| for a cross-site request.
|
| 2. Set "token" to the result of generating an HTTP State Token
| for "target-origin", as defined in Section 3.3.1.
⇒
-----
5. If "token" is "null", then:
1. If "request"'s delivery scope is "cross-site" and
response's header list does not contain "Sec-Http-State-Options",
return without altering "response-origin"'s HTTP
State Token.
2. Set "token" to the result of generating an HTTP State Token
for "response-origin", as defined in Section 3.3.1.
-----
( Step 6. substep 2. "delivery" check as as on "delivery=same-origin"
suggestion <20190410165945.583F545C5D@welho-filter4.welho.com> )
/ Kari Hurtta
Received on Sunday, 14 April 2019 11:34:46 UTC