MSC3062: Bot verification

[uhoreg]

Rendered

[piegamesde]

What is the purpose of this? What is the motivation on a security model level?

[Cadair]

If you can verify the bot is being run by a trusted party (and therefore trust the device) you can detect if the homserver admin creates a malicious device to decrypt messages to the bot.

[piegamesde]

Basically the bot authenticates by saying "I own the content on this domain", and then I trust the bot if I trust that domain? In that case, the "Proposal" section might benefit from being split up in a user-centric description and the low-level protocol messages.

[penn5]

Perhaps note that Punycode has caused security issues relating to humans verifying URLs, and that clients need to be careful when decoding it.

[uhoreg]

Yes, that is sort of implied by the part in the "Security considerations" section that says that it depends on "the human being able to distinguish a trusted URL from an untrusted URL", but it may be worth calling this out as an example, as well as other similar things (such as "paypaI", where that last character is an upper-case "i" rather than a lower-case "L")

[turt2live]

There's a few issues with using webservers:

1. Most bots don't have them today.
2. They can be load balanced or serverless (AWS Lambda), and trying to direct that request through to the right backend involves either breaking the load balancing/underlying tech or exposing internal infrastructure externally (ie: returning https://bot.nyc3.i2.example.org for a bot running in a NYC3 DC as instance 2). This then means exposing DDOS endpoints to bring down targeted parts of the infrastructure, or scraping for infrastructure.
3. Because the backend can't be guaranteed to be the bot, the user is actually verifying a provider/website with arbitrary backend. For larger providers (like if Discord were to switch wholesale to Matrix) they may very well end up with a backend service that handles all of these verification requests without ever actually talking to the bot. This means the bot could still be malicious but the service provider is hiding the details of that.

I don't really have alternatives at the moment, but the use of HTTP for verification doesn't feel like a safe route. Possibly for bots it might be sane enough to verify based purely off the ability to establish an Olm session?

[kevincox]

1. This is an annoying requirement. But it seems like the only widely-available trust source today is DNS names and the web PKI. The only alternatives I can think of are email signing certs and DNSSEC. Both of the others seem harder for the average bot to manage.
2. I'm not really sure if I understand your point. Likely if you are load balanced you want to be able to do this verification on any backend so this seems reasonable. If you are sharding in a way that this isn't possible you have likely already solved this problem to manage incoming events.
3. I'm not sure what you mean by this. You "know" it is the bot because it gave you the URL. If you were given a URL that the bot doesn't control then they have no way to get the provided information and do the verification. (Some exceptions may be using a pastebin to receive the "upload" and retrieve it later. I've raised another comment about this.

One alternative would be:

The bot sticks a public key in DNS (not web-compatible) or at an well-known HTTP endpoint. This cert is downloaded and used to send signed data to the bot. If the bot can read the data it is assumed to control that domain and that case be used as an identity.

The benefit here is that the data hosted on HTTP is static, which makes it far easier to host. You just need to keep it up with a fresh TLS cert.

[kevincox]

1. This is an annoying requirement. But it seems like the only widely-available trust source today is DNS names and the web PKI. The only alternatives I can think of are email signing certs and DNSSEC. Both of the others seem harder for the average bot to manage.
2. I'm not really sure if I understand your point. Likely if you are load balanced you want to be able to do this verification on any backend so this seems reasonable. If you are sharding in a way that this isn't possible you have likely already solved this problem to manage incoming events.
3. I'm not sure what you mean by this. You "know" it is the bot because it gave you the URL. If you were given a URL that the bot doesn't control then they have no way to get the provided information and do the verification. (Some exceptions may be using a pastebin to receive the "upload" and retrieve it later. I've raised another comment about this.

One alternative would be:

The bot sticks a public key in DNS (not web-compatible) or at an well-known HTTP endpoint. This cert is downloaded and used to send signed data to the bot. If the bot can read the data it is assumed to control that domain and that case be used as an identity.

The benefit here is that the data hosted on HTTP is static, which makes it far easier to host. You just need to keep it up with a fresh TLS cert.

[kevincox]

We should require more than just a 200. Otherwise the bot could pretend to be a pastebin service or similar as long as they find a service that:

1. Returns a 200 for JSON posts.
2. Makes that data available.

For example this can almost be done with pastebin.com. The only problem is that it requires Content-Type: application/x-www-form-urlencoded. (Although I don't actually see an explicit requirement for application/json in this MSC.) This works by using the bot-controlled transaction_id to pass required parameters. You can imagine that this would be even easier if the endpoint just accepted raw content.

% curl -iX POST --data-binary '{"transaction_id":"=bar&api_dev_key=REDACTED&api_option=paste&api_paste_code=","nonce":123,"from_device":"devid","keys":{"a":1}}' -HContent-Type:application/x-www-form-urlencoded "https://pastebin.com/api/api_post.php"
HTTP/2 200 
date: Sat, 28 Aug 2021 16:37:43 GMT
content-type: text/html; charset=UTF-8
x-custom-api-dev-id: 362667
set-cookie: pastebin_posted=REDACTED; expires=Sat, 28-Aug-2021 17:37:43 GMT; Max-Age=3600; path=/; HttpOnly
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 685ef7407fc02962-ORD

https://pastebin.com/SrNSQGBV

[uhoreg]

The user is supposed to verify that the URL looks legitimate.

Also, the attacker wouldn't be able to get the data that was POSTed without the URL that the pastebin returned.

[kevincox]

IIUC the transaction_id is not forbidden from including the | character, however I don't think this is exploitable. But maybe it would be a good idea to require escaping anyways just to be extra sure.