Re: DoS and Replay protection for message signatures

[Earl Hood <earl@xxxxxxxxxxxx>]

On August 5, 2005 at 00:26, "william(at)elan.net" wrote:

> > Perhaps as a diagnostic, a simple checksum of the body could 
> > be placed within the signature to confirm the body has been altered
> 
> "l" field is also this kind of diagnostic tool. Actually that is exactly
> what Content-Digest draft says in regards to its "s" parameter:

The l= tag is a major security problem if ever used for verification.
It must only be used for diagnostic purposes, or it should be dropped
entirely.

> > could be a reason the signature has failed.  I like the idea of dropping th
> e 
> > body hash into the signature header, but this seems to demand two separate 
> > signatures and this would be bad.
> 
> It does not demand separate signature. Properly it should be done with
> separate header field (which is NOT same as separate signature field).
> This is in fact good as for example when message is resigned this field 
> is reused and in such a way referenced by multiple signatures which saves 
> space in header and verifier system processing time.

Meta-Signatures does use a separate field to represent just the
hash of data.  However, from a DKIM perspective, the hash could
be placed in the DKIM-Signature field (base64 encoded of course).

>From a design perspective, I like the meta-signature approach of
making the digest/hash generation a separate component, allowing
for reusability for different applications.  However, some may not
like the idea of a separate header (which has been discussed before)
for DKIM, so placing it in DKIM-Signature should be sufficient.

> > Normally DKIM does not confirm the local-part of an email address.  DKIM 
> > verifies a domain that could be compared against various mailbox-domains.
> 
> I think this is bad. I believe the system should specify exactly which 
> mailbox address field it is authorizing and furthermore the signing system
> if it received message from authenticated user should indicate that (in
> such a way while you do not have direct authentication of the email address,
> you have indirect one from the signing system).

SSP has ties into user-based policies.  These ties are essential if
spoofing is to be avoided, something that DKIM proposes to address.

--ewh