Brian Candler wrote:
Hashes are much simpler and faster to implement than public key
cryptography, but sufficient for the purpose here. The same secret
key used to sign a hash is used to verify it (but the systems which
forward a message and receive a bounce in reply to a forwarded message
are either the same system, or two systems under the same
administrative
control). The keys are not distributed elsewhere.
I think the contrary was actually the original point. Consider the
scenario where you have a small business that actually does manage its
own mail host handling both inbound and outbound mail, however it also
receives secondary MX service from it's upstream ISP, should it's
primary MX be unavailable. The ISP's server just stores and forwards
mail for the small business' domains to the small business' primary MX
when it does again become available. In this scenario, you have an
outbound and inbound mail host under the administrative control of the
small business, and a secondary MX under the administrative control of
the upstream ISP. I believe the issue was, should the ISP trust the
company enough to accept a shared secret from the company, or should the
company trust the ISP enough to accept a shared secret from the ISP?
Either way, your sharing a secret across an administrative boundary. I
don't know how common this scenario is today, but I have personally seen
it quite frequently back when I used to do some consulting around the
turn of the millennium.
IMO, for the intended purpose of the shared secret, and if the secret is
rotated fairly frequently, I think the amount of trust required between
parties is negligible because you really don't gain much from
discovering or finding an exposed secret, except for the immediate
short-term, which does not seem to even make it worth your while. What
may be even more of a concern is how to rotate secrets in a synchronized
manner between mail hosts.
---
Dustin D. Trammell
Vulnerability Remediation Alchemist
Citadel Security Software, Inc.