Hi,
On Sun 08/Jun/2014 00:46:02 +0200 Doug Otis wrote:
On Jun 6, 2014, at 11:44 AM, Alessandro Vesely <vesely(_at_)tana(_dot_)it>
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
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822