ietf-clear
[Top] [All Lists]

[ietf-clear] more on no callbacks, please

2004-10-04 23:44:54
From: Dave Crocker
Sent: Tuesday, October 05, 2004 2:20 AM


On Tue, 5 Oct 2004 01:56:52 -0500, Seth Goodman wrote:
 so I wouldn't bet my life on it.  What we have done instead
 is to sidestep this problem by dropping unique message ID's
 and instead including a SHA1 digest of the canonicalized
 message in the signature.  The message digest is signed by an
 HMAC and the signature is verified by callback.  The recipient

I am not understanding how this "bypasses" the concerns that John
is raising.

What you have described is:

1. a per-message hash that is registered in a query service
maintained by the source.

I'm sorry for leaving out some key details.  The sender does not store the
per-message hash anywhere.  The hash is signed with an HMAC-SHA1, and both
are included in the return-path or signature header.  To validate this
signature, the validation server only needs to know the secret key and the
signature format for the domain.  The key is either static or changes
algorithmically on a fixed schedule, so key rotation takes place without
communication between nodes.  The only communication necessary is during
initial setup or after a major security compromise when a new global shared
secret is distributed.


2. a per-message query to that service by the delivery agent
(final receiving smtp server, or the like).

This means per-message updates and per-message, cross-net
queries.

This all sounds like it has exactly the performance and scaling
concerns that John raised.

There is a per-message query to the validation server to obtain a pass/fail
result.  This is typically a DNS "A" query and response.  However, there is
no per-message update.

--

Seth Goodman