Signature | Re: Formalizing the HTTP State Tokens proposal.

HTTP State Tokens
https://tools.ietf.org/html/draft-west-http-state-tokens-00

5.2.  Generate a request's signature
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-5.2

|   1.  Let "cbor-request" be the result of building a CBOR
|       representation [RFC7409] of the given request, as specified in
|       the first element of the array described in Section 3.2 of
|       [I-D.yasskin-http-origin-signed-responses].

RFC 7409: Forwarding and Control Element Separation (ForCES)
          Packet Parallelization

I think that it is not this.

3.2.  CBOR representation of exchange response headers
https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-05#section-3.2

|   The CBOR representation of a set of response metadata and headers is
|   the CBOR ([RFC7049]) map with the following mappings:
|
|   o  The byte string ':status' to the byte string containing the
|      response's 3-digit status code, and
|
|   o  For each response header field, the header field's lowercase name
|      as a byte string to the header field's value as a byte string.

RFC 7049: Concise Binary Object Representation (CBOR)

So you perhaps mean RFC 7049 and not RFC 7409.

I'm not sure what you mean with "the first element of the array".

That section seems talk about the CBOR map. And it is for response
headers and response status (as ":status").

5.2.1.  Example
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-5.2.1

|   The following request:
|
|   GET / HTTP/1.1
|   Host: example.com
|   Accept: */*
|
|   results in the following CBOR representation (represented using the
|   extended diagnostic notation from Appendix G of
|   [I-D.ietf-cbor-cddl]):
|
|   {
|     ':method': 'GET',
|     ':token': 'hB2RfWaGyNk60sjHze5DzGYjSnL7tRF2HWSBx6J1o4k='
|     ':url': 'https://example.com/',
|     'accept': '*/*',
|   }

For example  Section 3.2 of [I-D.yasskin-http-origin-signed-responses]
seems not give ':method' and ':url'.

( These are not same than HTTP/2 pseudo-header fields either although
  they use same ':' -hack. )

These certain request headers must also excluded from CBOR representation
when calculating request's signature:

4.1.  Uncached header fields
https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-05#section-4.1


|   Hop-by-hop and other uncached headers MUST NOT appear in a signed
|   exchange.  These will eventually be listed in
|   [I-D.ietf-httpbis-cache], but for now they're listed here:
|
|   o  Hop-by-hop header fields listed in the Connection header field
|      (Section 6.1 of [RFC7230]).


Typical request for origin perhaps is

       [ browser ]
             
            ⇓ https

  [ TLS termination and load balancing ]

     ⇓ http                 ⇓ http

   [ cache ]               [ cache ]

      ⇓ http                  ⇓ http

  [ -----  reapplying TLS --------- ]

              ⇓  https

  [ TLS termination and load balancing ]

      ⇓ http                 ⇓ http

   [ origin web server ]  [ origin web server ]



In other words there may be several positions which process http
request header and look HTTP State Token. And may want check signature.

And because there is several http hops, hop-by-hop
header fields may be different here. Therefore they
must be exclude for signature calculation.

There is basically two options

•  exclude certain listed header fields and header fields
   listed in the Connection header field,  and/or

•  calculate signature only from header fields which are
   mentioned on Sec-Http-State request header field.

Also browser may use HTTP/2 and therefore
:authority pseudo header field, but later http
hops may use HTTP/1.1 and therefore Host
header field.

( Some TLS termination and load balancing -products
  downgrades HTTP/2 requests to HTTP/1.1 (or perhaps
  sometimes even to HTTP/1.0). In other words they supports
  HTTP/2 only on Internet facing side. )
  
This also must take account when selecting which request
header fields are included to CBOR representation as is.

On my "key, register" post (
https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0050.html
<20190419174852.39A7D45BE7@welho-filter4.welho.com> )
I expected to use signature to protect
origin from situation where several (faulty) clients
gives same random bits for HTTP State Token. Difficulty
here was guarantee that one client retrieves key for
signature from origin just once (therefore "register" -part).

In that usage CBOR representation does not need request headers.
Just token value and url with authority. And perhaps something
what acts as nonce.

If nonce is used, origin server which check signature needs
to know what acts as nonce so that it can check that nonce
is not reused.

That suggests "nonce" parameter for Sec-Http-State: -header field.
If browser/http-client retries (automatically) request, then it should reuse
"nonce" value, but otherwise increment "nonce" value on every
request.

If "nonce" parameter is added to  Sec-Http-State: -header field
specification, then I suggest also register new 4xx http status
code for indicate replayed request (reused "nonce" value).




/ Kari Hurtta

Received on Saturday, 4 May 2019 13:45:37 UTC