key, register | 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

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