Re: [Ietf-dkim] Rechartering

[Dave Crocker <[e-mail]>]

On 11/28/2022 12:14 AM, Murray S. Kucherawy wrote:
> On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker <[e-mail]> 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:@[e-mail]