How should hubs decide which hash algorithm to use in signing? SHA-1 may be breakable in practice soon (see SHAttered) but how can a hub know which subscribers can do verification with the other ones? Should hubs just assume subscribers can verify sha-256?

The spec avoids saying clients MUST implement all four algorithms, although it's kind of implied. But (1) requesting signing is optional, and (2) checking signatures is also optional. So I see why the requirement to implement all four was left out.

Even if we solved that, what happens when SHA-1, SHA-256, SHA-384, and SHA-512 are all too weak? How can a hub know which subscribers implement whatever new algorithm comes along? Until the hub switches to some new algorithm, it'll be less insecure than some customers want. On the day it does switch, all the subscribers who haven't yet upgraded will break, leaving other customers quite unhappy.

I think the long term solution is to allow the subscription to include "hub.hash_algorithms: x", where x is a comma-separated list of names from https://www.w3.org/TR/WebCryptoAPI/#sha-registration or its successors. Subscribers use that to say which algorithms they can validate, then the hub can use the best implemented one of those in sending to that subscriber. This can be added at any time in the future.

Short term, I see the implementation report showing three hubs (Superfeedr, Mastodon, and Google) send SHA-1 while two others (Promulgate and Switchboard) send SHA-256. That makes me think there are probably subscribers that only understand SHA-1. Does anyone have data about that? The validation suite hasn't been checking that, I guess. @julien51 would you be hesitant to switch Superfeedr to SHA-256 for fear of breaking subscribers? I'll assume so.

Given that, I suggest for now we change https://www.w3.org/TR/2017/CR-websub-20170411/#recognized-algorithm-names :

remove:

In the future, any algorithm added to [FIPS PUB 180-4] SHOULD be supported by hubs and subscribers.

replace with:

In the future, an extension may be specified allowing subscribers to indicate which algorithms they can use for validation. As of this writing, most hubs sign with SHA-1, despite its known cryptographic weakness, in order to be interoperable with older subscribers.

Another issue for the longer-term pile is what to call the algorithms in the X-Hub-Signature header. FIPS, IETF, and W3C Web Crypto agree on naming like "SHA-1", but pubsubhubbub used "sha1", and this spec has been saying sha256, sha386, and sha512 for a few months, so it's a mess. My best hack idea is that the hub should re-use whatever name the subscriber used in hub.hash_algorithms, and for its own comparison, it ignores case and hyphens. That should work, I think, at some cost in hub complexity.