Change HTTPS requirement to be MUST for publicly facing servers

[ThisIsMissEm]

In a recent Data Portability thread, it was mentioned that currently the ActivityPub spec only has HTTPS as a SHOULD not a MUST requirement, in 2024 that seems like an unwise decision given:

• Most AP software mandates HTTPS connections when sending
• Most browsers enforce HTTPS now and warn on insecure connections
• It is very straightforward to get a free SSL certificate provisioned via LetsEncrypt

Would it be an idea to change this to a SHOULD when deployed publicly on the web? (i.e., localhost & private testing networks don't need HTTPS, but servers that are publicly federating do)

As @evanp noted,

It's a normative change, not backwards compatible, so it would need to wait until a Working Group is chartered to publish a future version of ActivityPub.

[trwnh]

Changing it to a MUST breaks potential futures over other transport protocols, or with alternative URI schemes or DIDs. This isn't purely a hypothetical, either -- there are already FEPs trying to build this future.

IMO the SHOULD SHOULD stay.

[ThisIsMissEm]

Changing it to a MUST breaks potential futures over other transport protocols, or with alternative URI schemes or DIDs. This isn't purely a hypothetical, either -- there are already FEPs trying to build this future.

IMO the SHOULD SHOULD stay.

@trwnh perhaps we just specify "If you're using HTTP-based transport, then the value MUST be via HTTPS if publicly available"?

[marnanel]

@trwnh perhaps we just specify "If you're using HTTP-based transport, then the value MUST be via HTTPS if publicly available"?

1. Yes. And perhaps add a general case, that all transmissions must be encrypted to a certain level.

2. Is this specific to listening? Should we also have a note that the connecting host should be trying https in the first instance, rather than assuming http will give a redirect?

3. Does it make a difference whether we're talking inter-server or client-server AP? Probably not.

[mro]

perhaps we just specify "If you're using HTTP-based transport, then the value MUST be via HTTPS if publicly available"?

• the publisher may have good reasons you and me cannot imagine,
• additional constraints reduce interoperability,
• the SHOULD already expresses clear preference,
• no additional constraints can prevent all misuse,
• let's not get overly paternalistic and leave the publishing decisions to the publishers.

P.S.: I'd throw in sustainabilty constraints, so as it has to work on low bandwidth and low carbon footprint. They are a huge problem compared to non-ssl deployment-induced harm in the wild.

[bumblefudge]

stepping back a little from the proposed change itself, maybe we're getting into the fine-grained distinction between a low-level standard and a stack-sized profile of that standard? i.e., "to interop with masto and threads and comply with their security policies/expectations, you need to do X, Y and Z" is a requirement that profiles the standard but requires no standard-level changes, and it is entirely fair-game to publish a list of such requirements and constraints as a FEP or CG Note. With enough market power/network effects behind it, such a profile actually "standardizes" (or more precisely, harmonizes) developer choices and software behavior more effectively than a low-level/protocol-level/more-flexible standard would, in the short-term, without changing anything about upgrade paths and futures. Maybe that's an easier option anyways, given Evan's point about normative changes being on a slower timeline?

[bumblefudge]

1. perhaps add a general case, that all transmissions must be encrypted to a certain level.

fwiw i also love this as a separate and additional profile requirement, although I'm not sure it makes sense at the protocol/lowest layer either, even if a WG authorized to make normative changes spins up tomorrow.

[mro]

another problem: tls sounds secure, but isn't. There are a quite a few dubious candidates among the 'trusted' CAs of your Browser and OS. You may not gain as much as you may think making tls mandatory.

What is your threat model?

[tesaguri]

Changing it to a MUST breaks potential futures over other transport protocols, or with alternative URI schemes or DIDs. This isn't purely a hypothetical, either -- there are already FEPs trying to build this future.

I think the Onion Services are a good example of that. When connecting to an .onion service, you don't need TLS because the Tor Protocol handles the integrity and privacy business which is usually done by HTTPS (cf. https://community.torproject.org/onion-services/advanced/https/).

For example, Mastodon uses cleartext HTTP connections for .onion domains, as the best practice suggests (mastodon/mastodon#15560). Unfortunately, however, the WebFinger protocol mandates the use of HTTPS scheme (RFC 7033 has at least 6 normative requirements on the use of HTTPS), which makes the Mastodon patch in violation of the spec. I think this gives a valuable lesson to ActivityPub too.

[jenniferplusplus]

Yes, using transport layer security should be a MUST requirement. I don't understand how this could be a controversial proposal.

[bleonard252]

My insignificant suggestion: perhaps not "MUST use HTTPS" and instead "SHOULD use HTTPS but MUST use a secure transport". That at least solves the concerns about breaking federation over Tor.

I don't think low-bandwidth federating servers are a concern here because they're impossible at a practical level: they'd be clogged out of relevance as soon as they're found anyway. And about low-carbon servers: you still need encryption to effectively federate in 2024, so this is where you'd instead pick an efficient cipher, such as Ed25519.

[dclements]

Strong agree that using a secure transport layer should be a MUST requirement. It's fairly odd to think of that requirement as remotely controversial, especially sitting on top of a protocol like ActivityPub.

I personally think it makes sense to continue to state HTTPS specifically as a SHOULD due to the abundance of phrases like these in the spec:

SHOULD result in a 405 Method Not Allowed response.

Servers MUST return a 201 Created HTTP code, and unless the activity is transient, MUST include the new id in the Location header.

[mro]

fairly odd to think of that requirement as remotely controversial

framing controversy unthinkable makes decisions easy. No need to bother with arguments one would have to think about. I call such cargo cult, not engineering.

If there is interest in arguments, I am happy to deliver.

[tesaguri]

Yes, using transport layer security should be a MUST requirement. I don't understand how this could be a controversial proposal.

Do you mean the Transport Layer Security? If so, I don't think requiring it to be uncontroversial at the very least, since it's not the only way of preventing eavesdropping and/or tampering. (Tor doesn't use TLS, for example.)

And even if you mean a secure transport layer protocol (as written in the later comments), the transport layer isn't the only layer responsible for preventing eavesdropping and/or tampering. (Again, Tor is an application layer protocol.)

Well, enough of the pedantry. Now I vaguely assume that you all mean requiring some sort of a secure mechanism. But even so, as an absolute requirement of the spec as specified by RFC 2119, I think we should clarify what exactly secure means here. In other words, what's our threat model, as already pointed out by Marcus in https://github.com/w3c/activitypub/issues/429#issuecomment-1995810710?

For example, is eavesdropping of public posts considered a threat? Well, that may well be a threat as it can affect privacy of clients. But, is the concern universal enough to warrant an absolute requirement? Is that relevant for communication between large servers, for example? Well, I personally believe that's still relevant, but I don't think that it's obviously uncontroversial, and I think it deserves consideration at least.

[jenniferplusplus]

@tesaguri I mean what I said. The security mechanisms provided by the transport(s) the application uses. So, yeah, if the transport is HTTP, as the spec says it SHOULD be, then the secure transport is TLS, and MUST be used.

is eavesdropping of public posts considered a threat?

yes

But, is the concern universal enough to warrant an absolute requirement?

also yes

Is that relevant for communication between large servers, for example?

extremely yes, it just gets more relevant as the involved parties get larger and become responsible for more people

Security at the transport layer (aka transport layer security) prevents the tampering and interception of messages, and it prevents the impersonation of the destination server. Those threats are perpetually relevant.

[tesaguri]

But, is the concern universal enough to warrant an absolute requirement?

also yes

Could you elaborate on that? It's important because it relates to the reason why we shouldn't use the SHOULD key word of RFC 2119.

As a refresher on RFC 2119 just in case, the key word is defined as the following:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

So, we need to refute the existence of valid reasons in order to confirm the illegibility of a SHOULD requirement.

Is that relevant for communication between large servers, for example?

extremely yes, it just gets more relevant as the involved parties get larger and become responsible for more people

I was thinking about eavesdropping which object an end user is fetching (as I was specifically talking about public posts), and assumed that it'd be harder to figure out who triggered the servers' requests, if the servers are sufficiently large. Well, I think it's guessable by some sort of sophisticated analysis, however.

Anyway, I was only intending it as an example of how the design decisions are not uncontroversial, so the specifics of the example isn't important, as long as it's debatable. (I admit it was distracting and I'm sorry about that!)

So, why I'm so obsessed about the controversiality is that I believe the concerns are so important that they deserve a discussion in the Security Considerations section.

For example, the Security Considerations section of RFC 7033 describes the rationale behind the requirement of HTTPS: The use of HTTPS is REQUIRED to ensure that information is not modified during transit. While it discusses the problem of tampering, it doesn't mention anything about confidentiality. That might be fine in the case of WebFinger, because it mandates the use of HTTPS, which ensures confidentiality anyway.

But if we were to do the same while preserving the SHOULD requirement on the use of HTTPS, it might be read as allowing strategies like "just add a signature to ensure integrity alone," which is also why I'm obsessed about the exact properties we'd require of the supposed security mechanism. Although I'm personally still not fully confident that there's no valid reasons for such a strategy, I believe that we should be explicit about it either way.

---

@mattly @dclements Does the above argument cover your objections? Asking it since you :-1:-ed https://github.com/w3c/activitypub/issues/429#issuecomment-2006789416, and I cannot guess your objections for sure by those emoji reactions alone (especially since my argument was admittedly misleading). No offense intended; I'm just trying to make sure that I'm addressing your concerns right :)

[mro]

Security at the transport layer (aka transport layer security) prevents the tampering and interception of messages, and it prevents the impersonation of the destination server.

No, it doesn't. Many firewalls successfully and wide-spreadedly break TLS to do deep-packet-inspection and filtering. Also look at the list of trusted CAs and decide if everybody really should trust them all. (I don't) I vaguely remember criminal investigations in which this was successfully used to track down a ransomware gang recently.

But this only as a side note, because this thread really isn't about TLS and it's merits or fallacies, but about SHOULD or MUST, as @tesaguri points out.

[TallTed]

So, we need to refute the existence of valid reasons in order to confirm the illegibility of a SHOULD requirement.

+1000

Many theoretically better-knowing consumers treat SHOULD as if it were MAY, but that SHOULD NOT cause spec authors to pretend SHOULD doesn't exist. MUST and MAY are insufficient; there were many good reasons for the original uses of SHOULD, and they apply here as there.

Regarding the posted title of this issue: the HTTPS requirement SHOULD (dare I say, MUST) remain a SHOULD, not be changed to a MUST

[jenniferplusplus]

Many firewalls successfully and wide-spreadedly break TLS

Firewalls don't "break TLS". Enterprise sysadmins use fleet management tools to configure their own root CA, and use that to issue valid certificates to their network appliances which allows them to MITM their own internal traffic. This is not thing that does or can happen outside of that environment.

This is a communication protocol, the the threat model is that a third party would eavesdrop, divert, alter, or spoof messages sent to or from an insecure end point. Those are all catastrophically bad things. If the protocol permits that to happen, then it's not fit for purpose.

[mro]

Firewalls don't "break TLS". Enterprise sysadmins use fleet management tools to configure their own root CA, and use that to issue valid certificates to their network appliances which allows them to MITM their own internal traffic.

That how TLS is not 'preventing eavesdropping and/or tampering' as hoped for. Surely intended by the enterprise sysadmins but maybe not the people communicating. Ant they are the ones to be protected.

[jenniferplusplus]

The traffic between AP servers doesn't pass through those corporate firewalls. And even if it did, the AP servers won't be configured to trust that cert. And anyway, none of this is the point, as you already pointed out.

[tesaguri]

The traffic between AP servers doesn't pass through those corporate firewalls. And even if it did, the AP servers won't be configured to trust that cert.

Note that ActivityPub also defines a client-to-server protocol, which can be affected by the problem.

That said, neither do I think there's anything we can do regarding that problem in this issue, although it might be a good topic to consider somewhere else.

[evanp]

As mentioned in the initial issue, this would be a normative change, so we can't actually update the doc with it until we have a working group chartered. (Which we should do soon.)

I will note in the Primer, for https://www.w3.org/wiki/ActivityPub/Primer/Object_identifiers, that HTTPS is strongly preferred for most applications.

[evanp]

We'll leave this open for a future version to address.