Signature | Re: Formalizing the HTTP State Tokens proposal.
Kari Hurtta <hurtta-ietf@elmme-mailer.org> Sat, 04 May 2019 13:47 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5421200B1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 4 May 2019 06:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level:
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K8D66Nrft6s for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 4 May 2019 06:47:30 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3534120091 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 4 May 2019 06:47:30 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hMuyy-0001OM-Sf for ietf-http-wg-dist@listhub.w3.org; Sat, 04 May 2019 13:45:40 +0000
Resent-Date: Sat, 04 May 2019 13:45:40 +0000
Resent-Message-Id: <E1hMuyy-0001OM-Sf@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <khurtta@welho.com>) id 1hMuyv-0001NS-OT for ietf-http-wg@listhub.w3.org; Sat, 04 May 2019 13:45:37 +0000
Received: from welho-filter4.welho.com ([83.102.41.26]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <khurtta@welho.com>) id 1hMuyt-0004XY-Gd for ietf-http-wg@w3.org; Sat, 04 May 2019 13:45:37 +0000
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 38AF24F94E; Sat, 4 May 2019 16:45:12 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id j-OdmGI45Ooc; Sat, 4 May 2019 16:45:10 +0300 (EEST)
Received: from kasvihuone.keh.iki.fi (89-27-39-95.bb.dnainternet.fi [89.27.39.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPS id 6C7E572; Sat, 4 May 2019 16:45:06 +0300 (EEST)
In-Reply-To: <CAKXHy=d3xmsaCGYmnvDQXegMNf1j0gLbpRiLCaT1yr1r=jeueA@mail.gmail.com>
References: <CAKXHy=d3xmsaCGYmnvDQXegMNf1j0gLbpRiLCaT1yr1r=jeueA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Date: Sat, 04 May 2019 16:45:06 +0300
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Mike West <mkwst@google.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
X-Mailer: ELM [version ME+ 2.5 PLalpha49+]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20190504134512.38AF24F94E@welho-filter4.welho.com>
Received-SPF: none client-ip=83.102.41.26; envelope-from=khurtta@welho.com; helo=welho-filter4.welho.com
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: AWL=0.989, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hMuyt-0004XY-Gd e7a2b8bf4eeb3709ea33cb4290e9ae61
X-Original-To: ietf-http-wg@w3.org
Subject: Signature | Re: Formalizing the HTTP State Tokens proposal.
Archived-At: <https://www.w3.org/mid/20190504134512.38AF24F94E@welho-filter4.welho.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36604
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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
- Formalizing the HTTP State Tokens proposal. Mike West
- Re: Formalizing the HTTP State Tokens proposal. Kari Hurtta
- Re: Formalizing the HTTP State Tokens proposal. Kari Hurtta
- Re: Formalizing the HTTP State Tokens proposal. Ilari Liusvaara
- Server/Site opt-in | Re: Formalizing the HTTP Sta… Kari Hurtta
- same-site |Re: Formalizing the HTTP State Tokens … Kari Hurtta
- delivery=same-origin | Re: Formalizing the HTTP S… Kari Hurtta
- cross-site | Re: Formalizing the HTTP State Token… Kari Hurtta
- key, register | Re: Formalizing the HTTP State To… Kari Hurtta
- Server/Site opt-in #2 | Re: Formalizing the HTTP … Kari Hurtta
- Signature | Re: Formalizing the HTTP State Tokens… Kari Hurtta
- Signature #2: No CBOR | Re: Formalizing the HTTP … Kari Hurtta