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

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Jun 2014 11:34:06 -0700

On May 9, 2014, at 3:23 AM, Alessandro Vesely <[email-masked]> wrote:

> Hi SM,
> 
> On Thu 08/May/2014 19:59:19 +0200 S Moonesamy wrote:
>> At 03:06 07-05-2014, Alessandro Vesely wrote:
>>> to "standardize" its syntax.[3]  It seems to me that eliminating some
>>> of such gratuitous changes is the solution to DMARC-for-MLs which
>>> minimizes the alterations in MLM software.  Are you sure it won't
>>> work?
>> 
>> This mailing list breaks the DKIM Signature.
> 
> No, it doesn't.  It broke elandsys' signature, but check tana's
> signature on this message.  (I send this to ietf-822 only, to avoid
> any confusion.)
> 
> So it seems I could publish a strict DMARC policy right now, and cause
> minimal disruptions.  However, some verifiers (NetEase) consider
> tana's h= inadequate, see "objection" below.
> 
>> Gratuitous changes to a mailing list message is a matter of
>> opinion.
> 
> Well, not exactly.
> 
> For corrections, section 6.4 of RFC 5321 is rather clear that
> submission servers MAY, while intermediate relays MUST NOT, apply
> certain changes.  So the range where opinions may vary is whether an
> MLM is to be considered akin to submission servers or relays.
> 
> By /gratuitous/ changes, such as adding/removing double quote marks, I
> mean unnecessary embellishments that were already disputable before
> DKIM took root.
> 
>> I suggest reading the past discussions first if you are interested
>> in trying to make it work.
> 
> Yes, much of this discussion was recited at the time of ADSP, for
> example http://mipassoc.org/pipermail/ietf-dkim/2010q3/013829.html
> 
> The most relevant objection to weak signatures is why would domains so
> concerned about security as to publish a strong policy weaken their
> DKIM signatures?  A solution is to do so for ML messages only.
> 
> 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.

Dear Alessandro,

How can sending domains select the signature scheme?  For example, often there are other destinations cc'd.  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.  Good mailing lists are fairly keen at confirming subscriptions and do not represent a source of abuse.  If a spear-phishing problem is confronted, authorizations could require an ORA header be added. An easy feature to add to this scheme.

Regards,
Douglas Otis

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Jun 2014 12:44:32 +0200

Hi,

On Thu 05/Jun/2014 20:34:06 +0200 Doug Otis wrote:
> 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

---

From: Douglas Otis <[email-masked]>
Date: Sat, 7 Jun 2014 23:46:02 +0100

> all recipients are trusted, there is no need to do so.

Agreed.

> lists.

> Weak signatures provide for per-message control at the sender,

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.

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

> 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

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 08 Jun 2014 09:05:06 +0200

Hi,

On Sun 08/Jun/2014 00:46:02 +0200 Doug Otis wrote:
> 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.

That requires an addition to A-R, and thus to OAR, methinks.  DMARC
provides for policy overrides, so a DMARC-compliant receiver can
whitelist a trusted forwarder, for example.  In the A-R and OAR lines
it only writes that DKIM and SPF didn't pass.  Subsequent receivers of
the same message cannot distinguish that scenario from that of a non
DMARC-compliant receiver who still checks DKIM and SPF, and produces
A-R and OAR fields accordingly.

An indication that a trusted intermediary considered DMARC but applied
policy override might solve the riddle.  Anyway, OAR is not compatible
with the case of a mailing list sending to a second mailing list
(bullet #8 of "mailing list - assumptions"[1]).

> Weak signatures only invite abuse IMHO.

That is true for vanilla DKIM verifiers only.  It is the negative side
of being compatible with them.  The question is if those receivers
will upgrade their DKIM verification practices quickly enough.  They
already do DKIM, so they're not lost in a limbo.  But how many
evaluate the strength of DKIM signatures, currently?  I heard of no
replay attacks thus far, so I don't feel pushed to evaluating it.
Introducing weak signatures clarifies that area as a side effect.

> 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 point.  That definitely calls for discussing TTLs and dynamic
zones in the specs.  I imagine institutional spam-traps can issue a
suitable kind of alarm pretty soon after the flood starts.  Automated
reaction to the latter is crucial for this point to be effective.

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

Glad to hear that.  There are some proposals like [2], but I'd leave
integration with the subscription process for a later stage, to keep
the problem at hand simple.  A manual process should be enough to set
the ball rolling.

A plain text file consisting of lines of blank-separated fields which
detail subscriber address, list-post address, and maybe IP numbers to
whitelist?  But perhaps an XML model would be better.  Fancy working
up a draft on that?

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

It is not straightforward to prove that a broken signature was not
broken at the time the OAR was written.

> The general goal is to establish accountability using available

Yes, and the available methods also differ in how accountability is
transferred.

Ale

[1]
http://mailarchive.ietf.org/arch/msg/ietf-822/PUNFLLCj3R-vI38ZpSF5IrAY78c

[2] http://fixforwarding.org/wiki/Water_tight_opt-in