Re: Binding HTTP signatures (RFC 9421) to TLS

The process you’re describing has also been tried a few times, one of the most notable being SHTTP all the way back in RFC2660 (https://www.ietf.org/rfc/rfc2660.txt). Clearly, the approach never caught on. A more modern take on encapsulated messages is found in OHTTP, which is currently working on this. You might want to join that conversation. https://datatracker.ietf.org/group/ohttp/about/


For HTTPSig (RFC9421) we deliberately did NOT sign the “raw bytes of the message” because, as it turns out, those bytes are not often readily available at either end of an HTTP request due to intermediaries and even HTTP application stacks getting in the way. The only time you can reliably sign the actual bytes on the wire, you’re better off using TLS in practice — so go do that where it makes sense to. Thus HTTPSig was designed explicitly as a detached signature method. This has its tradeoffs, of course, but we tried very hard to make sure that those were both clear and accounted for in its design.

 — Justin

On Oct 31, 2025, at 9:54 PM, Demi Marie Obenour <demiobenour@gmail.com> wrote:

On 10/31/25 07:23, Anders Rundgren wrote:
Hi Chris,
I have not evaluated your solution for replay protection, I have rather thought a bit about possible issues with bot security and signatures.

HTTP Signatures (RFC 9412) are fine but lack one item: a serialization format.  Due to this I'm working with signature schemes that are more adapted for Embedding, Counter-signatures, Multi-hop, and Archival:
https://github.com/cyberphone/cbor-everywhere/tree/main?tab=readme-ov-file#signed-http-requests


It’s worth noting that trying to sign an abstract message
massively increases the room for implementations to err, often in
exploitable ways.  See the numerous vulnerabilities in XML signature
implementations for examples, as well as various vulnerabilities in
Hashicorp Vault.  Instead, one should sign the data as raw bytes,
and encapsulate it in a form that will pass through intermediates
unchanged.  In the case of HTTP, this would correspond to wrapping
an HTTP request inside another.
Is this something that could be used instead?
--
Sincerely,
Demi Marie Obenour (she/her/hers)<OpenPGP_0xB288B55FFF9C22C1.asc>