Return-Path: X-Original-To: web-bot-auth@mail2.ietf.org Delivered-To: web-bot-auth@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E676E11C2AD98 for ; Wed, 22 Jul 2026 03:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784717603; bh=1jgqGt6NwbNdBHXvLNIxI0tGKEpUTC8Yip2v7I/tbGk=; h=Date:Subject:To:References:From:In-Reply-To; b=rdmu9u42+JiiSkSrnOwJdG7AP+LmciP+ncBsgY5gEtiVru/U++ATzodXYRx30LwBa f3bbLf/b50SMHxU02Oc3vz0ErS484Mn/qqzst9cyCYoplMMubjFvaI4gC0l+6Gb1gy ZFKIyep/1jt9JRJdPhOr/CGNq2+RSUW0XMVaoodE= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=dennis-jackson.uk Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpwHJReWGpn1 for ; Wed, 22 Jul 2026 03:53:23 -0700 (PDT) Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 0285111C2AD91 for ; Wed, 22 Jul 2026 03:53:23 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4h4rh90wFnzMlGx for ; Wed, 22 Jul 2026 12:53:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dennis-jackson.uk; s=MBO0001; t=1784717593; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PNZFdmkUNak5VAPOz3FnF1d2vMKOQ5BaYYzrKSANems=; b=FnvnJPc2iJCX5RX5BlAM5FLYbQfKWSpmC1CELu5zA3JJIvBtGe3XtszbMekm38et6cz+Lz GI/uhiU/l7seh4ZDF4EBOEfv0Frqyfcf7/FAEgQ7NkCTmaQRJG5VYKJGQoHEWNcOiSvgsE c3WIy8rfiYEbZ1vE2bw0F0Y2da8e05ZsCVvaowm8qVgPwntfde1AIX97ZWBgUV4ppZmXwY beGGFIQHy1NZikaB4YsCqt74Wn6+Lzlrf8X7EcIdwJQdI35dUQG1OCTAUkzmQ/P9WSPikh clo7/lRIKSCDoGqcxPzoMGkDW7tk/sJF+k2hhxlEaYOVbVQKUKeEoiZGBCM7ZQ== Content-Type: multipart/alternative; boundary="------------Ili9zWPMpxX5Wk955HM9pxHg" Message-ID: <44cb8b7a-0737-4bbd-a3c2-f2d5bad6e4fa@dennis-jackson.uk> Date: Wed, 22 Jul 2026 12:53:11 +0200 MIME-Version: 1.0 To: web-bot-auth@ietf.org References: <13282f45-2b1e-409c-bbb6-4bfcbc0e60ba@dennis-jackson.uk> Content-Language: en-US From: Dennis Jackson In-Reply-To: Message-ID-Hash: ZH5TGTH5WO63QCZKLGN662WSCVIDXFZ4 X-Message-ID-Hash: ZH5TGTH5WO63QCZKLGN662WSCVIDXFZ4 X-MailFrom: ietf@dennis-jackson.uk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BWeb-bot-auth=5D_Re=3A_Signature_Misbinding_in_httpsig-protocol-?= =?utf-8?q?00?= List-Id: Authentication of non-human users to human-oriented Web sites Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------Ili9zWPMpxX5Wk955HM9pxHg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 22/07/2026 10:44, Max Gerber wrote: > In Thibault's draft, the second signature covers the original request > data, as well as the first signature. So I am not sure if the attack > applies here, but am very open to hearing where my interpretation is > wrong. This isn't required by the draft. The first signature and second signature can cover different fields and attacks are possible when there's fields in the first signature not also directly covered in the second signature. The second signature is also going to need to cover the first signer's public key and other identifying information. But even then the property doesn't strictly follow if the second signer is not trusted. For example, if the key is only authenticated by TLS fetch, it can plausibly change between when the second signer fetches it and the recipient fetches it. Consequently a recipient can't distinguish between a dishonest second signer lying about the first signer's public key and normal key rotation. Before trying to define the mechanism, I think it makes sense to clarify the exact security property this system needs when handling requests authenticated by multiple parties. Best, Dennis > > On Wed, Jul 22, 2026 at 10:13 AM Thibault Meunier > wrote: > > > > > > On Wednesday, July 22nd, 2026 at 10:05, Dennis Jackson > wrote: > > > In 4.2.2 of draft-meunier-webbotauth-httpsig-protocol-00 [1], > the draft > > proposes signing signatures: > > > >  > A signer MAY cover selected members from another signature label, > >  > including "signature";key=..., "signature-input";key=..., and > >  > "signature-agent";key=.... This lets a signer preserve > evidence that > >  > another signer contributed to the request. > > > > I don't think this is correct. > > > > RFC 9421 7.3.7 'Signing Signature Values' [2] recommends against > what's > > described in the draft, because it doesn't bind the message that > > corresponds to the inner signature: > > > >  > While it would seem that this practice would transitively > cover the > >  > components under the original signature in a verifiable > fashion, the > > attacks > >  > described in [JACKSON2019] can be used to impersonate a > signature output > >  > value on an unrelated message. > > > > If you only want to preserve evidence that a message was signed by > > another, you don't need to sign their signature, you just need to > > preserve their signature, message and public key, so removing > this text > > and stating that verifiers should check each signature independently > > would work and avoid these footguns. > > > > If you want a stronger property, like 'Party A only signed this > message > > because Party B signed it first', that requires some more > careful handling. > > The goal is Party A only signed because Party B signed first. I'll > check [JACKSON2019], but happy to get advice and pointers here. > I'll also correct the text to avoid going against RFC 9421 7.3.7 > > > > > Best, > > Dennis > > > > [1] > > > https://www.ietf.org/archive/id/draft-meunier-webbotauth-httpsig-protocol-00.html#name-multiple-signatures > > > > [2] > > > https://www.rfc-editor.org/rfc/rfc9421.html#name-signing-signature-values > > > > > > _______________________________________________ > > Web-bot-auth mailing list -- web-bot-auth@ietf.org > > To unsubscribe send an email to web-bot-auth-leave@ietf.org > > > > _______________________________________________ > Web-bot-auth mailing list -- web-bot-auth@ietf.org > To unsubscribe send an email to web-bot-auth-leave@ietf.org > > > _______________________________________________ > Web-bot-auth mailing list --web-bot-auth@ietf.org > To unsubscribe send an email toweb-bot-auth-leave@ietf.org --------------Ili9zWPMpxX5Wk955HM9pxHg Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 22/07/2026 10:44, Max Gerber wrote:

In Thibault's draft, the second signature covers the original request data, as well as the first signature. So I am not sure if the attack applies here, but am very open to hearing where my interpretation is wrong.

This isn't required by the draft. The first signature and second signature can cover different fields and attacks are possible when there's fields in the first signature not also directly covered in the second signature.  

The second signature is also going to need to cover the first signer's public key and other identifying information. But even then the property doesn't strictly follow if the second signer is not trusted. For example, if the key is only authenticated by TLS fetch, it can plausibly change between when the second signer fetches it and the recipient fetches it. Consequently a recipient can't distinguish between a dishonest second signer lying about the first signer's public key and normal key rotation. 

Before trying to define the mechanism, I think it makes sense to clarify the exact security property this system needs when handling requests authenticated by multiple parties.

Best,
Dennis


On Wed, Jul 22, 2026 at 10:13 AM Thibault Meunier <ot-ietf=40thibault.uk@dmarc.ietf.org> wrote:




On Wednesday, July 22nd, 2026 at 10:05, Dennis Jackson <ietf=40dennis-jackson.uk@dmarc.ietf.org> wrote:

> In 4.2.2 of draft-meunier-webbotauth-httpsig-protocol-00 [1], the draft
> proposes signing signatures:
>
>  > A signer MAY cover selected members from another signature label,
>  > including "signature";key=..., "signature-input";key=..., and
>  > "signature-agent";key=.... This lets a signer preserve evidence that
>  > another signer contributed to the request.
>
> I don't think this is correct.
>
> RFC 9421 7.3.7 'Signing Signature Values' [2] recommends against what's
> described in the draft, because it doesn't bind the message that
> corresponds to the inner signature:
>
>  > While it would seem that this practice would transitively cover the
>  > components under the original signature in a verifiable fashion, the
> attacks
>  > described in [JACKSON2019] can be used to impersonate a signature output
>  > value on an unrelated message.
>
> If you only want to preserve evidence that a message was signed by
> another, you don't need to sign their signature, you just need to
> preserve their signature, message and public key, so removing this text
> and stating that verifiers should check each signature independently
> would work and avoid these footguns.
>
> If you want a stronger property, like 'Party A only signed this message
> because Party B signed it first', that requires some more careful handling.

The goal is Party A only signed because Party B signed first. I'll check [JACKSON2019], but happy to get advice and pointers here. I'll also correct the text to avoid going against RFC 9421 7.3.7

>
> Best,
> Dennis
>
> [1]
> https://www.ietf.org/archive/id/draft-meunier-webbotauth-httpsig-protocol-00.html#name-multiple-signatures
>
> [2]
> https://www.rfc-editor.org/rfc/rfc9421.html#name-signing-signature-values
>
>
> _______________________________________________
> Web-bot-auth mailing list -- web-bot-auth@ietf.org
> To unsubscribe send an email to web-bot-auth-leave@ietf.org
>

_______________________________________________
Web-bot-auth mailing list -- web-bot-auth@ietf.org
To unsubscribe send an email to web-bot-auth-leave@ietf.org

_______________________________________________
Web-bot-auth mailing list -- web-bot-auth@ietf.org
To unsubscribe send an email to web-bot-auth-leave@ietf.org
--------------Ili9zWPMpxX5Wk955HM9pxHg--