cross-site | Re: Formalizing the HTTP State Tokens proposal.

[Kari Hurtta <[e-mail]>]

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
<[e-mail]>
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
( <[e-mail]> 
  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
( <[e-mail]>
   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"].
( <[e-mail]> 
  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 <[e-mail]> )

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 <[e-mail]> )

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 <[e-mail]> )



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 <[e-mail]> )


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 <[e-mail]> )


/ Kari Hurtta