On Dec 14, 2005, at 9:42 AM, william(at)elan.net wrote:
And as far as my opinion using BATV/SES together with SPF makes more
sense - both in reducing computation cryptographic computation when
it does not have to be used and also because by itself BATV/SES are
easily susceptible to a replay attack.
An anonymous replay attack would require harvesting. Obfuscating
signatures within a return-path tag could become a normal practice
without affecting the value of any archive. The signature also
allows harvesting to be traced. As this information is temporal, it
would require an ongoing criminal activity, which works in favor of
tracing bad actors. : )
Private key one-way hash computational overhead is much less than
making even a single DNS lookup. The prominent syntax difference
between SES and BATV reflects a desire to nest the entire
encapsulation resembling Russian matryoshka nesting dolls, whereas
this free-form nesting was avoided in the BATV format. Tony Finch
made a security argument against the SES encapsulation, as it would
also make visual exploits easier. The difference does not result in
any specific limitation of one syntax over the other except, for
ensuring the mode tag is defined and can extend beyond the use of a
single character. : )
SES:
=<mode><glob>=<local-part>@<domain>
=<mode'><glob'>=<local-part'>=<mode><glob>=<local-part>@<domain>
BATV:
<prvs>=<local-part>/<glob>@<domain>
<nest>=<local-part>/<glob>/<mode'>/<local-part'>/<glob'>@<domain>
If desired, a nested version of BATV could encapsulate a prior local-
part based upon a "defined" mode.
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf