Re: [ietf-822] Aptness of DKIM for MLs

[Alessandro Vesely <[e-mail]>]

Hi,

On Thu 05/Jun/2014 20:34:06 +0200 Doug Otis wrote:
> On May 9, 2014, at 3:23 AM, Alessandro Vesely <[e-mail]> wrote:
>>
>> To recap, assume a domain has a DB of (user, mailing list) pairs which
>> defines ML traffic.  Messages to ML are then sent in separate SMTP
>> transactions and weakly signed.  MLMs sign those messages in turn,
>> using strong signatures.  Verifiers derive the validity of MLM domains
>> by comparing d= against To: or Cc: mailboxes.
>>
>> Besides minor refinements, the major bar is to build that DB.  I
>> proposed to do it manually for starting, and then find out how to
>> automate its maintenance.
> 
> How can sending domains select the signature scheme?  For example,
> often there are other destinations cc'd.

An MTA can sign the message differently for different recipients.  If
all recipients are trusted, there is no need to do so.

> Conveying an alignment exception method to all parties is the
> intent behind TPA-Labels.  This avoids the need to apply weak
> signatures that can be maliciously replayed.  After all, DKIM does
> not constrain possible recipients.

Agreed.  I added TPA-Labels to the picture I posted on the ietf list
on May 14.  All three methods serve the same purpose, but they have
different pros and cons.  Roughly, TPA-Labels can aggregate domains
into federations, so they seem to be better for well established
lists.  Weak signatures provide for per-message control at the sender,
and are compatible with vanilla DKIM at the receiver.  For redundancy,
a sender can apply both of them at the same time.

> Good mailing lists are fairly keen at confirming subscriptions and
> do not represent a source of abuse.

Confirming subscriptions is part of the "manual process" in the
picture.  That seems to be the most difficult problem at this time.
DMARC reports can hardly be used to create a DB, IMHO.  However, a
sender could use reports from trusted receivers to verify it (that's
the yellow question mark in the picture).  Just mumbling...

> If a spear-phishing problem is confronted, authorizations could
> require an ORA header be added. An easy feature to add to this
> scheme.

If the spear-phisher can authenticate, I don't see how a possibly
spoofed ORA can help the receiver.

Ale