On Jun 6, 2014, at 11:44 AM, Alessandro Vesely <vesely(_at_)tana(_dot_)it>
wrote:
Hi,
On Thu 05/Jun/2014 20:34:06 +0200 Doug Otis wrote:
On May 9, 2014, at 3:23 AM, Alessandro Vesely <vesely(_at_)tana(_dot_)it>
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
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822