Re: Aptness of DKIM for MLs

Hi,

On Sun 08/Jun/2014 00:46:02 +0200 Doug Otis wrote:
> On Jun 6, 2014, at 11:44 AM, Alessandro Vesely <[email protected]> wrote:
> 
>> 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.

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.

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

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?

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

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

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

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822