Improvements for Chip Channel

[tybritten]

We're looking at using the Chip channel with our own web front end, and we were interested in discussing some improvements and PRing them if they're agreeable.

Here's what we have so far. Open to others as well.

• add support for quickreplies in the message event
• another authentication mechanism besides shared secret in the body? potentially auth header, body signature, etc.

[rowanseymour]

Quick replies is a no brainer. What's the rational for moving the channel secret to an auth header? I guess would be nice having it be more consistent with the shared secret passing between RP and mailroom, mailroom and courier etc.

[tybritten]

I was thinking more like some of the providers do where they sign a copy of the body and include it in the header, that way the raw secret isn't passed in the message, but you can confirm the sender and content. @chris-erickson thoughts here?

[rowanseymour]

We use the same shared secret mechanism for calls from RP to mailroom endpoints and from mailroom to courier (to fetch attachments), so if that's something we need to improve it'd be good to do it everywhere. But don't forget also there's an expectation that you're networking these services in a way that these calls aren't happening over the internet.

[chris-erickson]

I tend to just look at what Stripe does, and they sign payload and provide it in a header like Tyler notes. It also has provisions for secret rotation. Probably other ways, but I would imagine there's a risk to passing the actual secret in the body. Notable one being that the secret is literally floating around in logs and whatnot in various systems. Key rotation support with a phased window is helpful too because otherwise you have to find a way to hard cut things, or do multiple checks downstream and shepherd key changes down the line until everyone is happy again. We have some internal systems that rotate keys like every hour and update a var in RP globals. Just a big reduction in risk with a token that leaks out into logs, sentry, etc.

https://docs.stripe.com/webhooks?verify=verify-manually

[rowanseymour]

We're definitely open to PRs and suggestions on strengthening the security between RP services. I do wonder if communication between internal services is a bit a different situation to something like Stripe (and maybe we should be thinking about network architecture? AWS IAM roles? Mutual TLS?) but at the same time there would be little downside to doing something a bit more sophisticated in the app layer like HMAC signatures.