[ietf-dkim] Yet another alternative mailing list approach

Alessandro Vesely vesely at tana.it
Wed Aug 4 05:22:41 PDT 2010


On 03/Aug/10 00:49, Douglas Otis wrote:
> On 7/30/10 1:05 PM, Alessandro Vesely wrote:
>>   I propose that, when a message is destined to a list, the author
>>   domain signs a few header fields only, not the body, and tags the
>>   message with a (signed) list-signature-required sort of advice.
>
> Changing signature behavior seems ill advised, as this will be more
> difficult to implement.  Not signing the body will also introduce
> security issues.

Signing software may also take signature properties, including key, 
from ad-hoc header fields.  Posters just have to set it adequately 
when they post to lists.  MLM should bounce the submission in case 
they forget, just like they do when posters pick up the wrong From.

The body will be signed by the MLM, so there is no security issue here.

>>   Another way of achieving the same effect would be to standardize all
>>   acceptable message changes, together with a MIME-compliant
>>   canonicalization.  We've already noted that in some cases (plain
>>   text, poster-added subject tags, not signing "Content-Type", l=) it
>>   may work as-is.  For the general case, and for the time being, the
>>   advice requiring the added list signature guards against replay
>>   attacks: Verifiers must ensure that both signatures are valid, unless
>>   they are the domain whose signature is missing.
>
> I don't wish to stand in the way of such a goal, but such a change may
> take many years to define, and at least as many to gain adoption.

Standardizing all acceptable message changes certainly will take 
years.  To the opposite, the joint-signature approach is 
straightforward.  Just like ADSP /requires/ one signature, the newly 
introduced "ADSP-Required" header field /requires/ one more (with the 
same meaning of /requires/.)  In case I haven't been clear, here is 
what the final recipient will get:

Delivered-To: someone at final.receiver.example
Authentication-Results: final.receiver.example
   dkim=pass header.i=@original.example
   dkim=pass header.i=@MLM.example
   dkim-adsp=pass header.from=author at original.example
Received: from MLM.example by final.example with ESMTP
DKIM-Signature: d=MLM.example ... this signs body, subject, etc.
Received: from original.example by MLM.example with ESMTPS
DKIM-Signature: d=original.example; l=0 ... signs few fields
ADSP-Required: MLM.example (*this is new*; signed by original.example)
From: author at original.example
To: post at MLM.example
Date: Wed, 04 Aug 2010 14:22:18 +0200
Subject: [tag] This field is not signed by original.example

The only changes are the addition of the ADSP-Required header field, 
and its interpretation by verifiers.  This is not difficult:

After retrieving the ADSP RR, and seeing it is "all" or "discardable", 
the verifier checks whether d=original.example occurs among the 
successfully verified signatures.  The additional step is simply to 
check that a signature by MLM.example (as mentioned in ADSP-Required) 
also occurs.  If the latter step fails, dkim-adsp also fails, unless 
the verifier _is_ MLM.example.

Isn't this simpler than TPA?



More information about the ietf-dkim mailing list