On 11/28/2022 12:14 AM, Murray S. Kucherawy wrote:
On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker <[email protected]> wrote:
This does not provide any real understanding of how replay is
accomplished. And since it's easy to explain and doesn't take much
text, I'll again encourage including that in the document that
defines
the nature of the problem we will be working on, namely the charter.
Doesn't the "A DKIM-signed message can be re-posted, ..." sentence do
that? I pulled it from your suggested text for that very reason.
Maybe add something to the second sentence making clear the roles in
the attack?
Your text:
A DKIM-signed message can be re-posted, to a different set of
recipients, without
disturbing the signature's validity. This can be used to confound
the engines that
identify abusive content.
If a reader is sufficiently knowledgeable and thoughtful, this text is
probably sufficient.
However...
While a charter typically should not do deep tutorials, it does have a
goal of being useful for a wide audience, such as helping to convince a
manager that their company should participate. To that end, a bit of
hand-holding in the charter can be helpful.
* What does it take to achieve malicious reposting? Collaborating
recipient.
* How does this differ from non-malicious re-posting? Mostly it
doesn't, except in scale of repostings. (And if I have that wrong,
we should make sure we have solid wg understanding of the
differences. And if there is not clear and immediate consensus
about it, then developing it should be explicitly part of the
charter, IMO.)
* How does it 'confound' analysis engines? By using the reputation of
a good source site and therefore by looking like it is legitimate.
(Same parenthetical comments as the previous bullet.)
Hence my text:
A DKIM-signed message can be re-posted, to additional recipients, in a fashion that
retains the original signature. With an author and a recipient collaborating, this can
"replay" the message, using the original signer's reputation to propagate email
with problematic content -- spam, phishing, and the like.
Generally, the technical characteristics of this form of abuse match that of
legitimate mail, making its detection or prevention challenging. Timestamps and
carefully-tailored message signing conventions are appealing approaches to
replay mitigation. Each has significant limitations.
> The DKIM working group will produce one or more technical
> specifications that
> describe the abuse and propose replay-resistant mechanisms that are
> compatible
> with DKIM's broad deployment. The working group may produce
documents
> describing
> relevant experimental trials first.
This draft doesn't include the 'preservation of installed base' cover
text that Barry's had and I forgot to include in mine. I think it's
important.
I had intended "compatible with DKIM's broad deployment" to cover
exactly this. Should I word it differently?
Looking over it less quickly, your text looks reasonable.
However...
Since this type of text is often important for controlling wg activity,
I'll raise the question about the possible problem of having the wg
decide that a significant change (not just addition) is needed that is
NOT 'compatible'. Imagine something that is permitted now, but isn't
used much, and creates problems. Making it no longer permitted might be
helpful for dealing with the current problem, but, obviously, is not
compatible with what is deployed, although actually affecting few
activities. The challenge, then, is to document the goal of
compatibility, without absolutely requiring it.
Yours:
The DKIM working group will produce one or more technical
specifications that
describe the abuse and propose replay-resistant mechanisms that are
compatible
with DKIM's broad deployment.
Perhaps:
The DKIM working group will produce one or more technical
specifications that
describe the abuse and propose replay-resistant mechanisms. The
working group will
seek compatibility with DKIM's broad deployment.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[email protected]
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
