Towards an HTTP signature FEP

ActivityPub Server to Server
1

Introduction

In light of the recent CVE-2024-23832 , me and @perillamint have been brainstorming about a standardisation of HTTP signatures in the Fediverse in form of an FEP.

Important to mention here is that this is in no way an attempt to undermine the work of FEP-8b32. It is a great attempt to move towards more W3C standardised works instead of continuing to grip onto a Draft RFC.
Instead we see this as a complementary work.

HTTP signatures, love or loathe them, are here to stay for a while. They are the only way you can communicate with 99% of the Fediverse.

The current status-quo and issues with it

The current status-quo of HTTP signatures is to point to Mastodon and essentially say “do what they do if you wanna be compatible”.
Maybe the new implementers get a link to the correct draft RFC and off they go.

Issues arise at this very stage already. One of the largest issue is overlooking very important possible security issues.

To name one, there is the case of the HTTP digest header. It is essential to either verify or recompute the Digest header and forcing the Digest header to be included in the HTTP signature when receiving a POST request to ensure authenticity of the body.

This is unfortunately overlooked too often. And I don’t fault any implementor. They implement the RFC and are happy when Mastodon finally accepts the signature after a lot of back and forth.
After they are done, they just commit their work and don’t ever want to look at the code ever again.

Another issue is the origin checks: Do the origin servers match? Do the actor IDs match? Does the actor ID match the signature key ID?

Those are things that are easily overlooked and missing readily available test vectors definitely don’t help the issue.

Potential solution

One solution we can try to work towards is the standardisation of the HTTP signatures.

Similar to FEP-7888, which aims to demystify the context property, our FEP would demystify the HTTP signatures and the required checks for ensuring authenticity and the origin of activities.

The standard would not only give a condensed version of the draft RFC for HTTP signatures, it would also provide ActivityPub-specific guidance on how to implement checks that proof your implementations against most known HTTP signature exploits and provide test vectors.

This post is mostly for seeking feedback, whether this is something the wider community thinks is worth investigating and following.
If we receive positive feedback, me and @perillamint would go ahead and attempt to draft an FEP.

4 Likes
2

I agree, HTTP signatures are not going anywhere. An FEP describing best practices would be very valuable.

1 Like
3

Just two disclaimers:

First, I believe writing a FEP based on an outdated draft would set a bad precedent. The RFC is almost ready, so we should strive to upgrade to it.

Second, I stated here

If we would want FEP to be gate kept, I would suggest first adding a disclaimer that FEP doesn’t accept security relevant topics, as the FEP editors cannot ensure that the new FEPs don’t create issues.

and it continues to be my believe that FEP is inappropriate for security related things. So if somebody writes a HTTP Signature Best Practice guide, there will be no guarantee that they are actually best practices.

1 Like
4

I think an FEP with guidance related to using the updated HTTP Signature RFC in a Fediverse context would be beneficial and could facilitate adoption when the RFC is approved. However, the RFC approval and widespread AP Fediverse adoption is probably years in the future.

I also think that an FEP documenting the current usage of HTTP Signatures would be beneficial for developers in the near term. I’d like to see:

  • Current HTTP Signature usage in the AP Fediverse and requirements for interoperability
  • Recommended practices with technical rationale for recommending them
  • Common developer issues and troubleshooting techniques

The problem with the label “best practice” is that “best” is subjective. A recommendation may also be at least partially subjective in some cases, but it’s clearer that it’s the author’s opinion whereas “best” often implies more than that.

If necessary, I’d prefer a standard disclaimer/warning be added to FEPs making security recommendations rather than banning all security-related FEPs.

3 Likes
5

First, I believe writing a FEP based on an outdated draft would set a bad precedent. The RFC is almost ready, so we should strive to upgrade to it.

We are living in a world where the most significant portion of the Fediverse does not even support the updated version of signature (ref: Update HTTP signatures to support IETF draft from October 2021 · Issue #21429 · mastodon/mastodon · GitHub, Performance: çœČćă‚ąăƒ«ă‚ŽăƒȘă‚șăƒ ăźć€‰æ›Ž / é”ăźă‚”ă‚€ă‚șăźć€‰æ›Ž (Change of signature algorithm/cryptographic key size) · Issue #11129 · misskey-dev/misskey · GitHub) and it would not disappear in one day. This FEP is addressing that problem. Even after RFC9421 is ready, we need to implement a Cavage signature to communicate with them properly.

Also, we cannot stuff RFC9421 and Cavage in the same Signature header (if you can’t believe me, try it. It isn’t too hard), so we need another FEP for protocol negotiation and the other, which defines a new Signature scheme based on the protocol negotiation. (that’s why this FEP does not mention httpbis at all. It should be separated in different FEP)

and it continues to be my believe that FEP is inappropriate for security related things. So if somebody writes a HTTP Signature Best Practice guide, there will be no guarantee that they are actually best practices.

This FEP does not intend to be “The Ultimate Guide to implementing HTTP signature.”. Instead, it provides some DON’Ts and DOs to prevent something like CVE-2023-49079 and CVE-2024-23832. If someone wants to implement a Fediverse server for the current Fediverse, the best guide is, well
 a tiny bit of Mastodon documentation and a bunch of other implementation source codes to learn what I should do and don’t. It is not an ideal situation. We need some official documents for now.

Even worse, most Fediverse instances do not accept RFC3230 with a non-SHA-256 algorithm or do not comply with RFC3230 properly (only accept some particular form of RFC3230). This FEP is intended to address those problems by properly formalizing current authentication methods.

5 Likes
6

I think FEP is actually a better medium for security related things than a personal blog because FEPs are peer-reviewed and are more likely to attract scrutiny. If there is a disagreement about what constitutes a best practice, a competing proposal could be submitted.

1 Like
7

Given the expectation of future revisions, consider adding a version to FEP title, e.g. “HTTP signature guide 2024”. Tracking changes in a living document could be difficult for implementers.

Later you can publish “HTTP signature guide 2025”, which will supersede the current one.

8

The Social CG is currently working on a official Community Group Report for a spec on how to use HTTP Signatures with ActivityPub, which I agree is long overdue. you can follow the progress and file issues for things you’d want to see included at https://github.com/swicg/activitypub-http-signature

9

FEPs are for extensions, I agree that they’re a bad format for documenting best practices or a survey of existing implementations.

10

A collection of “DON’Ts and DOs” is something, I’m much more comfortable with than a best practice guide. In particular, if one can provide (as you have done) links to the incidents, when mishandling the “DON’Ts and DOs” has caused problems.

1 Like
11

FEPs are for much more than that (maybe you were saying they should be just for that?).
See the FEP Process Description.

3 Likes
12

In general I’m most comfortable with, in approximate order:

  1. Implementation reports (we implemented it in service X this way)
  2. Lessons learned (this is our postmortem on what went sideways in our implementation)
  3. Do’s and Don’ts

I’m extremely uncomfortable with:

  1. Best Practice Guides
  2. Full-blown standards or things that present themselves as full-blown standards, especially around security.
13

Note (since this has come up a lot): The name “Best Practices” in the title was just added because I wrote a title down quickly so I could generate the slug. Not a lot of thought went into the title itself.

Fully my bad.

The general idea was reviewing current implementations, finding a common ground to define in a document, and giving guidance to implement those things in a way that steers you away from things that will expose you to unnecessary risk (such as broken hash digests, weak signatures, symmetric authentication algorithms which expose one to key confusion attacks, etc.)

Also something we used the opportunity for is to restrict the algorithm variety of some protocols. Crypto agility is
 let’s say a double edged sword.

An example here is to restrict the key sizes of RSA to 2048 to 8192. This is done to avoid keys which could run the risk of being insufficient for authenticity in the future, and preventing people from going the “more is better route”, and prevents people from getting DoS’d by too large keys.

Or by restricting the digests for the HTTP Digest header to the SHA-2 digests (and a quick idea to extend it by BLAKE2, which offers great performance even via purely software implementations; just an idea for now).

Again, if the consensus by the team of stakeholders here is to not accept these types of proposals, they can just tell us. No hard feelings.

1 Like
14

Also, excuse the possibly silly question, but what exactly is the difference between “Do’s and Don’ts” and “Best Practice Guides” to you? In my mind the result is almost the exact same thing, just with different names.

15

The FEP system does not operate on consensus, and there are no stakeholders in the process. That’s why I don’t think the FEP route is the right option.

16

@aumetra I assure you that your FEP does not violate the rules of the FEP process in any way. Proposals with security implications have been submitted in the past (FEP-8b32 is among them).

As stated in FEP-a4ed, FEP editors / facilitators should take a neutral stance and only reject submissions “when a proposal amounts to blatant misuse of the process”.

Also, I’d like to re-iterate that, despite @nightpool’s claims here and on other forums, FEP process is:

  • Not only for extensions.
  • Has stakeholders: authors, facilitators, implementers.
  • Receives wide community review, as demonstrated by SocialHub topic stats.
2 Likes
17

It’s not a silly question, it’s a good one :slight_smile:

It’s the level of presented authority.

Saying “here are some dos and don’ts that I/we found for signatures”: A++ I like it as a FEP.

Saying “these are some best practices” presumes an authoritative position, and I don’t think FEPs are authoritative in that sense and we as a community should be careful about presenting them as such. I don’t know who (by way of example) you are, if you have relevant credentials in this field (you may have a long list, but it doesn’t matter for my example), etc: presenting it as “best practices” without a broader consensus or documented authority just feels jarring to me, personally.

That said, I also stridently disagree with nightpool’s interpretation and agree with silverpill’s assertion here: they receive wide community review, they just don’t represent a consensus position (which is a different problem), there are stakeholders (just not a dedicated board of them), and they are not only for extensions by any stretch of the imagination.

I think a Dos and Don’ts on this topic is a great FEP, personally.

1 Like