From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org Thu Feb 2 00:10:45 2023 Return-Path: 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 D3BAFC14F747 for ; Thu, 2 Feb 2023 00:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dennis-jackson.uk 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 I_bX1ICWIQpv for ; Thu, 2 Feb 2023 00:10:41 -0800 (PST) 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 520A7C14F6EC for ; Thu, 2 Feb 2023 00:10:40 -0800 (PST) Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1pNUf7-003CUZ-Oj for ietf-http-wg-dist@listhub.w3.org; Thu, 02 Feb 2023 08:09:41 +0000 Resent-Date: Thu, 02 Feb 2023 08:09:41 +0000 Resent-Message-Id: Received: from www-data by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1pNUf5-003CSb-LV for ietf-http-wg@listhub.w3.org; Thu, 02 Feb 2023 08:09:39 +0000 Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pNAdh-0003V2-CA for ietf-http-wg@listhub.w3.org; Wed, 01 Feb 2023 10:46:53 +0000 Received: from mout-p-101.mailbox.org ([2001:67c:2050:0:465::101]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pNAdc-008Uuc-4I for ietf-http-wg@w3.org; Wed, 01 Feb 2023 10:46:52 +0000 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4P6JWF0m2hz9sZ1; Wed, 1 Feb 2023 11:46:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dennis-jackson.uk; s=MBO0001; t=1675248393; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=mE0tS3esxheZHbgJKWNXXUU+d+1LZoRnq00B/arI86o=; b=2Cfkjtg1OayROW1hOJVCa8Srpxlj0CYRiRdo2ZocpSK2s+u5LGX7vgDukaY3tCHiu68ybb +rTxl1AfXw18bTE5zvIfusXEV4DNQCAllcRdNWALh4yXBW7/X6LvDnfNT4HvsS9nrsDFIt sz4I+zNphzkrNwPDZQYPySy1ScBCn8d3XLJFqhIOLLFImo4ylvFVFqmfCdoCdwhFIDGAX1 YO5eeV+B3ipn6tkt3sVQy16Lo6drnII3DXB4iMp42ugIMq0tfGrqsVI+9P10O8ioFuh5wQ 3+XjOam7yt+7RPuVFtN8MEHlM9AjNDkkfJmEcu7OyWFYheYIVLJKqHXy6S+Liw== Content-Type: multipart/alternative; boundary="------------MnTI0N2u0fmc5gSQIlk51hGX" Message-ID: Date: Wed, 1 Feb 2023 10:46:30 +0000 MIME-Version: 1.0 Content-Language: en-US From: Dennis Jackson To: HTTP Working Group X-Rspamd-Queue-Id: 4P6JWF0m2hz9sZ1 Received-SPF: pass client-ip=2001:67c:2050:0:465::101; envelope-from=ietf@dennis-jackson.uk; helo=mout-p-101.mailbox.org X-W3C-Hub-DKIM-Status: validation passed: (address=ietf@dennis-jackson.uk domain=dennis-jackson.uk), signature is good X-W3C-Hub-Spam-Status: No, score=-1.8 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_NW=1 X-W3C-Scan-Sig: titan.w3.org 1pNAdc-008Uuc-4I eb642f3ba33bbb7ea985093163a97be1 X-caa-id: 2173219024 X-Original-To: ietf-http-wg@w3.org Subject: Request-Response Binding Issues in httpbis-message-signatures-15 Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/50669 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: This is a multi-part message in MIME format. --------------MnTI0N2u0fmc5gSQIlk51hGX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I think there are some issues which lead to practical attacks in the Request-Response Binding section of httpbis-message-signatures-15 . I took a look through recent github issues and mailing list discussions and I didn’t see anyone raise similar issues before, but apologies if this is a duplicate. My understanding is based purely on a read of the spec, I haven’t messed around with the implementations. *Problems* httpbis-message-signatures-15 specifies a scheme for binding requests and responses together (Sect 2.4 ) where the response includes components from the request which are tagged with |req|. The example provided in the draft uses the signature component from the request: Request: {"Hello, World"} Signature-Input: sig1=("@method" "@authority" "@path" \ "content-digest" "content-length" "content-type")\ ;created=1618884475;keyid="test-key-rsa-pss" Signature: sig1=:LAH8BjcfcOcL... ​ Response: {"Your call is important to us"} Signature-Input: reqres=("@status" "content-length" "content-type" \ "signature";req;key="sig1" "@authority";req "@method";req)\ ;created=1618884479;keyid="test-key-ecc-p256" Signature: reqres=:mh17P4TbYYB... Creating a signature over a signature from another party is a cryptographic mistake. This is because the security definition of most common signature schemes does not cover the case where the signer is malicious and so leaves the resulting behavior undefined. Practically, this allows for a couple of different attacks. Firstly, it means that when using RSA-PKCS / RSA-PSS signatures. an attacker who witnesses the above request-response pair and can register a new public key, can choose a public key such that sig1 is valid for a different message [1]. For example, they could choose {“Goodbye, World”} or any other string and then produce the faked transcript: Request: {"Goodbye, World"} Signature-Input: [...] keyid="attackerKey" Signature: sig1=:LAH8BjcfcOcL... (unchanged) ​ Response (unchanged): {"Your call is important to us"} Signature-Input: [...] Signature: reqres=:mh17P4TbYYB... The responder (or any third party) would verify this transcript successfully. The responder’s signature validates because it is unaltered as are its inputs. The request signature validates because the attacker has chosen their public key such that it is valid for the alternative message content which contains their keyid and their own choice of message. This allows the attacker to take a legitimate response from the server to a different user and apply it to a request of their choice. A similarly powerful attack is also possible without access to a request-response pair from another party. The attacker registers a malicious public key in advance, such as the all-zero Ed25519 key. When using this public key, it is trivial to generate signatures which validate for any message. The attacker engages in the request-response protocol and stores the transcript. Later, the attacker change their request to be whatever message they like and the resulting transcript will still validate. Depending on the application, this could allow them to equivocate, change their vote, alter a timestamp, etc. This type of attack is very similar to a previous one we found and formally modeled in 2019 on WS-Security, which also used a signature of a signature to bind request-response pairs. See the discussion and protocol diagram in 5.2 of Seems Legit . In the Security Considerations section of the draft (Sect 7.3.1 ), the existence of signature collisions is acknowledged but the impact is largely dismissed and it is suggested the user only use vetted public keys and signature algorithms in the draft’s registry. However, at least half of the algorithms in the HTTP Signature Algorithms Registry are known to suffer from these kinds of problems [2] and I am unaware of any IETF standard which specifies how to vet public keys to avoid these kinds of attacks. The draft also suggests that the inclusion of the signature parameters in the signature base may foil these types of attack but I’m quite doubtful as many of the attacks allow for a arbitrary choice of message content, meaning that the signature parameters can be freely replaced by the attacker. *Suggested Fixes* The minimal fix would be to rework the example in 2.4 to avoid a signature over a signature and the guidance in 7.3.1 adjusted. This could be a simple as just highlighting that signing signature components doesn’t bind the message contents and that if the response signature is to include the request signature, it should also include the request signature’s components directly. However, I think the draft would be much improved if it gave users a sensible default mechanism for how to use request-response signing in a robust / secure way via a SHOULD recommendation. Users could choose to apply request-response binding differently but should only do so on the understanding that they need to do their own security analysis and can’t rely on any included within the draft. A sensible default would be that all signed components of the request should be included in the response signature, as well as the request’s signature and signature components. This avoids any surprising mismatches between what the requester and responder were authenticating. This could be done either by explicitly including every signed request field in the responder’s signature components (increases message size, simplifies implementation) or implicitly by defining special rules for interpreting a “signature;req” component in a signature components(saves space, adds small amount of implementation complexity). Specifically, the implementation would replace "signature;req" by looking up the signature component for the associated signature and process each element of that, as well as the signature and associated public key. I would lean towards the latter because its less sharp edges for the user and I’m struggling to think of any situation in which you would want to include a signature, but not the contents of a signature. *Further Reading* * In 2005, Pornin and Stern introduced some of the key concepts around these kind of signature behaviors and show in Sect 2.1 how to construct malicious RSA public keys with the necessary properties. [PDF ] [1] * In 2019, we looked at how how these types of attack impact protocols in Seems Legit [PDF ] [2]. Table 1 provides a summary of the different signature schemes and their properties. Section 3 explores how the different properties impact various simple request-response protocols. Section 5 describes some practical real world attacks on deployed protocols. * In 2020, we looked at the case of Ed25519 specifically [PDF ] and gave a proof that with sufficient additional checks which are not part of RFC 8032, these behaviors can be removed from Ed25519. Best, Dennis --------------MnTI0N2u0fmc5gSQIlk51hGX Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think there are some issues which lead to practic= al attacks in the Request-Response Binding section of httpbis-message-signatures-15. I took a look thr= ough recent github issues and mailing list discussions and I didn=E2=80=99= t see anyone raise similar issues before, but apologies if this is a dupl= icate. My understanding is based purely on a read of the spec, I haven=E2= =80=99t messed around with the implementations.

Problems=

httpbis-message-signatures-15 specifies a scheme for binding= requests and responses together (Sect 2.4) where the response incl= udes components from the request which are tagged with re= q. The example provided in the draft uses the signature component from th= e request: 

=C2=A0Request: =


      =C2=A0{"Hello, World"}

      =C2=A0Signature-Input: sig1=3D("@method"
        "@authority" "@path" \

      =C2=A0 "content-digest" "content-length"
        "content-type")\

      =C2=A0
        ;created=3D1618884475;keyid=3D"test-key-rsa-pss"

      =C2=A0Signature: sig1=3D:LAH8BjcfcOcL...<=
br>
      =C2=A0=E2=
=80=8B

      =C2=A0Response: 

      =C2=A0{"Your call is important to us"} 
      =C2=A0Signature-Input: reqres=3D("@status"
        "content-length" "content-type" \

      =C2=A0 "signature";req;key=3D"sig1"
        "@authority";req "@method";req)\

      =C2=A0
        ;created=3D1618884479;keyid=3D"test-key-ecc-p256"

      =C2=A0Signature: reqres=3D:mh17P4TbYYB...=

Creating a signature over a signature from another party is = a cryptographic mistake. This is because the security definition of most = common signature schemes does not cover the case where the signer is mali= cious and so leaves the resulting behavior undefined.

Practically, this allows for a couple of different attacks. = Firstly, it means that when using RSA-PKCS / RSA-PSS signatures. an attac= ker who witnesses the above request-response pair and can register a new = public key, can choose a public key such that sig1 is valid for a differe= nt message [1]. For example, they could choose {=E2=80=9CGoodbye, World=E2= =80=9D} or any other string and then produce the faked transcript: 

=C2=A0Request: =


      =C2=A0{"Goodbye, World"}

      =C2=A0Signature-Input: [...]
        keyid=3D"attackerKey"

      =C2=A0Signature: sig1=3D:LAH8BjcfcOcL...
        (unchanged)

      =C2=A0=E2=
=80=8B

      =C2=A0Response (unchanged): 

      =C2=A0{"Your call is important to us"} 
      =C2=A0Signature-Input: [...]

      =C2=A0Signature: reqres=3D:mh17P4TbYYB...=

The responder (or any third party) would verify this transcr= ipt successfully. The responder=E2=80=99s signature validates because it = is unaltered as are its inputs. The request signature validates because t= he attacker has chosen their public key such that it is valid for the alt= ernative message content which contains their keyid and their own choice = of message. This allows the attacker to take a legitimate response from t= he server to a different user and apply it to a request of their choice. =

A similarly powerful attack is also possible without access = to a request-response pair from another party. The attacker registers a m= alicious public key in advance, such as the all-zero Ed25519 key. When us= ing this public key, it is trivial to generate signatures which validate = for any message. The attacker engages in the request-response protocol an= d stores the transcript. Later, the attacker change their request to be w= hatever message they like and the resulting transcript will still validat= e. Depending on the application, this could allow them to equivocate, cha= nge their vote, alter a timestamp, etc.

This type of attack is very similar to a previous one we fou= nd and formally modeled in 2019 on WS-Security, which also used a signatu= re of a signature to bind request-response pairs. See the discussion and = protocol diagram in 5.2 of Seems Legit.

In the Security Considerations section of the draft (Sect = 7.3.1), the existence of signature collisions is acknowledged but the= impact is largely dismissed and it is suggested the user only use vetted= public keys and signature algorithms in the draft=E2=80=99s registry. Ho= wever, at least half of the algorithms in the HTTP Signature Algorithms R= egistry are known to suffer from these kinds of problems [2] and I am una= ware of any IETF standard which specifies how to vet public keys to avoid= these kinds of attacks. The draft also suggests that the inclusion of th= e signature parameters in the signature base may foil these types of atta= ck but I=E2=80=99m quite doubtful as many of the attacks allow for a arbi= trary choice of message content, meaning that the signature parameters ca= n be freely replaced by the attacker.

Suggested Fixes=

The minimal fix would be to rework the example in 2.4 to avo= id a signature over a signature and the guidance in 7.3.1 adjusted. This = could be a simple as just highlighting that signing signature components = doesn=E2=80=99t bind the message contents and that if the response signat= ure is to include the request signature, it should also include the reque= st signature=E2=80=99s components directly.

However, I think the draft would be much improved if it gav= e users a sensible default mechanism for how to use request-response sign= ing in a robust / secure way via a SHOULD recommendation. Users could cho= ose to apply request-response binding differently but should only do so o= n the understanding that they need to do their own security analysis and = can=E2=80=99t rely on any included within the draft.

A sensible default would be that all signed compon= ents of the request should be included in the response signature, as well= as the request=E2=80=99s signature and signature components. This avoids= any surprising mismatches between what the requester and responder were = authenticating. This could be done either by explicitly including every s= igned request field in the responder=E2=80=99s signature components (incr= eases message size, simplifies implementation) or implicitly by defining = special rules for interpreting a =E2=80=9Csignature;req=E2=80=9D componen= t in a signature components(saves space, adds small amount of implementat= ion complexity). Specifically, the implementation would replace "signatur= e;req" by looking up the signature component for the associated signature= and process each element of that, as well as the signature and associate= d public key.

I would lean towards the latter because its less sharp edges= for the user and I=E2=80=99m struggling to think of any situation in whi= ch you would want to include a signature, but not the contents of a signa= ture.

Further Reading=

  • In 2005, Pornin and Stern introduced some of the key concepts around these kind of signature behaviors and show in Sect 2.1 how to construct malicious RSA public keys with the necessary properties. [PDF] [1]

  • In 2019, we looked at how how these types of attack impact protocols in Seems Legit [P= DF] [2]. Table 1 provides a summary of the different signature schemes and their properties. Section 3 explores how the different properties impact various simple request-response protocols. Section 5 describes some practical real world attacks on deployed protocols.

  • In 2020, we looked at the case of Ed25519 specifically [PDF] and gave a proof that with sufficient additional chec= ks which are not part of RFC 8032, these behaviors can be removed from Ed= 25519.

Best,
Dennis

--------------MnTI0N2u0fmc5gSQIlk51hGX--