ietf-smtp
[Top] [All Lists]

Re: Lose the time stamp in BATV

2008-05-20 02:19:04

John R Levine wrote:

It occurs to me that the majority of BATV's interoperability problems are due to the time stamp. Let's assume for the moment that we simplify a BATV signature to something like this:

  prv=DHHHH=local(_at_)host

The D is still a version number, and the HHH is a hash, but there's no timestamp. Now, unless you change your key, which seems pretty rare in practice, a given plain address always turns into the same BATV address.
The problem is that that's wide open for a replay attack

Personally I think that the prvs signature specification in the BATV standard is possibly superfluous. The local part meta-syntax section is useful as it allows the original local part to be extracted, and maybe the current prvs specification could be added as an example of how a private key could be implemented, but I think a private key signature specification would be just that, private. The data would be opaque to anything except the originating MTA, so it's irrelevant. There are lots of different ways of doing it, including some that would be better protected against replay attacks and could alleviate some problems with mailing lists etc, but wouldn't meet the 'prvs' specification.

Maybe only a 'private signature' type name should be specified, where the signature is opaque and can be up to, say, 16 characters long, and that's all that should be specified in the original BATV spec. Possible ways of implementing a private signature may be made available in other documents. The way the BATV spec is currently written, it looks like the prvs way is the only way that's allowed, but since the data in it is tag value generated is useless to anything except something which knows how it was made (i.e. the key) then the actual value of the tag value doesn't matter.

For instance, a server could have rules to use a certain key for all messages which are going to a certain domain, eg all messages to imc.org use the key 'bibble'. The server could check that any bounce messages which have the key 'bibble' are coming from imc.org, and reject them if they aren't, this would give that list server a constant (non-time-dependent) return-path to work with. Or, a server could use a different random key for each message which it stores in a database for a while, thus making replay attacks much harder since it could check how many bounce messages have come back for each key, and reject them if there are too many coming in. These things are possible within the BATV spec, but not within the prvs spec.


--
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

<Prev in Thread] Current Thread [Next in Thread>