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

[Douglas Otis <[e-mail]>]

On Jun 6, 2014, at 11:44 AM, Alessandro Vesely <[e-mail]> wrote:

> 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.

Agreed.

>> 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.

If there is a problem, OAR can ensure messages have been issued by the domain requesting DMARC compliance even when DMARC is not directly applied by the third-party service. DKIM modifications will not add much since TPA-Label already involves reliable information.  Weak signatures only invite abuse IMHO. TPA-Label is also able to respond after a message has been signed unlike potential floods caused by an exploited DKIM signature where they will then soon be ignored as a method.

>> 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...

It would be nice to have a subscription process communicate with a DMARC domain.  Perhaps there could be a message structure defined.  This would better ensure initial messages are not lost prior to  DMARC feedback or user complaints that indicate the need. 

>> 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.

Making an OAR requirement of TPA-Label authorization should add a conditional review of a separate DMARC review one-level removed. If the OAR headers are shown forged by a validated TPA-Label authorized domain in a abuse report, its authorization should be denied and require a remediation process before there is a change in status.  Such policy better ensures OARs are protected from forgery.

The general goal is to establish accountability using available validation methods.

Regards,
Douglas Otis