Re: Signing Set-Cookie

Justin Richer <jricher@mit.edu> Mon, 06 June 2022 20:52 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 9D69AC14F745 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 Jun 2022 13:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.759
X-Spam-Level:
X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mit.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lq8DlrUNQSg for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 Jun 2022 13:52:51 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C34C14F744 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 6 Jun 2022 13:52:51 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1nyJg9-0004Ja-PQ for ietf-http-wg-dist@listhub.w3.org; Mon, 06 Jun 2022 20:50:25 +0000
Resent-Date: Mon, 06 Jun 2022 20:50:25 +0000
Resent-Message-Id: <E1nyJg9-0004Ja-PQ@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <jricher@mit.edu>) id 1nyJg7-0004IQ-Sn for ietf-http-wg@listhub.w3.org; Mon, 06 Jun 2022 20:50:23 +0000
Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <jricher@mit.edu>) id 1nyJg6-0002WW-F8 for ietf-http-wg@w3.org; Mon, 06 Jun 2022 20:50:23 +0000
Received: from smtpclient.apple (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 256Ko8AC029992 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jun 2022 16:50:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1654548609; bh=6y3i+aiPNsWsdIdP1oLzY/bQQqLdHhrTUpxphRhrI/E=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=CYkAJRQoSrN7VjAC+hsSu6vPo3UKJhbQE1QQ7atHTWBZNIveQlFUFio0Dm+9n8etw vqWA39J3zS5NAlESktLHidjuuDgFmRwpVhhJieWd6Ao12Ssfq6Kf9z9ZbVf+NIxhWN zXR+8MdffSKVqsef0jfW7BHEVlcpHyopE3jLmLvGf2LcEYTIN9DOzADOl/7X4vT/bf Lxb5sgyQ7lyReoa6H6oMgidpVJfnNPf3nS/AWLHz8MWlgCn+anig5eeiV0j8T/RMWJ 7zvOTyOOryBxTdtyZ1hcYLVM12FOuygZOszD2zXRJ2Y+V1h6fhFSNdffD33Q4dgt6D ip39+Ik+MfkoA==
From: Justin Richer <jricher@mit.edu>
Message-Id: <A659F1C6-97D6-48FB-BDED-B885AF93E553@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0CC55A0D-62EA-4A10-A3D9-273EFD4E388F"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Mon, 06 Jun 2022 16:50:08 -0400
In-Reply-To: <7dff30c8-faac-413f-8387-f0a5a51fc6ff@beta.fastmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Martin Thomson <mt@lowentropy.net>
References: <A0601849-2870-4150-9926-5FA706D7F6DE@mit.edu> <CACcvr==K0gjhOaBaxt8vK80UYo1tAHVrh78yCcAEMvwx4tT=ag@mail.gmail.com> <7dff30c8-faac-413f-8387-f0a5a51fc6ff@beta.fastmail.com>
X-Mailer: Apple Mail (2.3696.100.31)
X-W3C-Hub-DKIM-Status: validation passed: (address=jricher@mit.edu domain=mit.edu), signature is good
X-W3C-Hub-Spam-Status: No, score=-7.4
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1nyJg6-0002WW-F8 5dbd7a67de92fcf9c00ca1c9650a3423
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Signing Set-Cookie
Archived-At: <https://www.w3.org/mid/A659F1C6-97D6-48FB-BDED-B885AF93E553@mit.edu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40073
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>

What I’ve done is create a new security consideration for this, and discussing how it might possibly lead to the foothold for an attack.

https://github.com/httpwg/http-extensions/pull/2143/files#diff-1d57bca6223a0fee3ef29148c2550c0f862e72f67a56cc7f57b5a72fbd8320e3R1802 <https://github.com/httpwg/http-extensions/pull/2143/files#diff-1d57bca6223a0fee3ef29148c2550c0f862e72f67a56cc7f57b5a72fbd8320e3R1802>

— Justin

> On Jun 1, 2022, at 7:58 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> Yeah, what Nick said.
> 
> Cookie concatenation has a special carve-out in all HTTP versions past 1.x; I see no real harm in making another for Set-Cookie.
> 
> On Thu, Jun 2, 2022, at 09:20, Nick Harper wrote:
>> A Set-Cookie header could have a comma in it (e.g. in the Expires= or 
>> Path= parts), which means that it's probably possible for two different 
>> combinations of Set-Cookie headers to be concatenated/canonicalized to 
>> the same value. I'm not certain there's an attack here, but this seems 
>> potentially problematic enough that this should be given more 
>> consideration.
>> 
>> On Wed, Jun 1, 2022 at 2:39 PM Justin Richer <jricher@mit.edu> wrote:
>>> The Set-Cookie header syntax is weird in that it doesn’t allow for concatenation in the normal List syntax. The Signature spec relies on this concatenation for the combination of values of headers that show up multiple times. This discrepancy is called out in this issue:
>>> 
>>> https://github.com/httpwg/http-extensions/issues/1183
>>> 
>>> However, on further investigation, I don’t think this actually causes a problem. The concatenation process outlined in Signatures still works on multiple Set-Cookie values, the only weird thing is that the RESULT of that process cannot itself be parsed as a valid Set-Cookie header. 
>>> 
>>> But the thing is, it doesn’t have to be parsed. It just has to exist as a string in the signature base, and be re-created by both signer and verifier in a consistent way. 
>>> 
>>> I’m planning on closing this issue with a note in the appropriate section of the signature spec, but if there’s something I’m missing about this, please chime in.
>>> 
>>> — Justin
>