Re: [ietf-dkim] draft-fenton-dkim-threats-00
2005-10-05 19:09:08
On Oct 5, 2005, at 2:36 PM, Jim Fenton wrote:
Douglas Otis wrote:
On Oct 5, 2005, at 9:57 AM, Hallam-Baker, Phillip wrote:
I agree, there should be greater clarity with regard to realistic
defenses offered by the DKIM mechanism, especially in the third-
party scenario you described.
Do you really agree? I read Phill's comment as "we could go on
forever, but this is pretty good now" while I read yours as "needs
improvement".
I agreed with the focus and concern of there being possibly
indefinite discussion with respect to all possible exploits. Phillip
also highlighted the importance of establishing who accepts
"responsibility". I don't wish to demean your excellent work on this
draft, but I remain troubled by how threat protection is envisioned.
On good advice, I steered clear of the topic of repudiation. Is
there someplace the document implies repudiation protection?
Avoiding repudiation was not heeded within the DKIM draft abstract
that explains intent. : (
Clarity is also lacking within the threat document regarding what is
meant by the term identity or address. I assume without "IP"
prefixing address, address or identity means a header's mailbox
address such as RFC2822 From or Sender.
An excerpt from your draft:
------
5.1. Use of Arbitrary Identities
This class of bad acts includes the sending of messages which aim to
obscure the identity of the actual sender. In some cases the actual
sender might be the bad actor, or in other cases might be a third-
party under the control of the bad actor (e.g., a compromised computer).
DKIM is effective in mitigating against the use of addresses not
controlled by bad actors, but is not effective against the use of
addresses they control. In other words, the presence of a valid DKIM
signature does not guarantee that the signer is not a bad actor. It
also does not guarantee the accountability of the signer, since that
is limited by the extent to which domain registration requires
accountability for its registrants. However, accreditation and
reputation systems can be used to enhance the accountability of DKIM-
verified addresses and/or the likelihood that signed messages are
desirable.
------
A reputation mechanism can be safely established to accrue behavioral
information of the signer. How can reputation be extended to include
"addresses" and "identities"? What protection is possible without
reputation assessments?
A DKIM signature in fact _does_ guarantee the accountability of the
signer. It simply does not guarantee their behavior. That is why
reputation in the form of white-lists, accreditation, or reputation
services is _required_. Reputation is _not_ an enhancement.
By attempting to extend DKIM to include the protection of "addresses"
in the generic sense, there is danger entering into a quagmire.
Nothing can be accrued with respect to the "address" in terms of bad
behavior without implying the signer is also not trustworthy. This
creates a serious paradox.
Only when the "address" and the signer are the same, would it be
possible to safely make assertions of behavior, but then of course
extending assertions of behavior to the "address" would not be
required. I see little within the threat analysis that clarifies
this limitation. I am not comfortable with promises that "address"
protection is limited to just repudiation.
The threat draft makes what I see as rather dangerously broad
generalizations. It becomes a perilous situation to consider
establishing a matrix of authorizations with respect to signers.
Such an assessment scheme would depend upon an unaccounted signer
where repudiation _must_ be the sole objective. Just as "Repudiation
MailFrom" became "Sender Authentication", there is a real danger the
limited benefits of repudiation will be extended by unfair reputation
assessments.
Inappropriate use of reputation can be prevented by simply limiting
the purported protection to just the signing domain. Presume a fair
reputation scheme on the basis of the signer offers a full spectrum
of protections. This protection can be slightly enhanced by safe
assertions the domain signs all their own mail. Perhaps this type of
assertion could even be extended to also disallow the resending of
their mail.
On a related topic, adding an opaque-identifier greatly extends the
protections made possible by DKIM that are discounted in this draft.
Importantly, these identifiers permit replay abatement. Alas,
without prompt curtailment of abusive replays, reputation does not
offer dependable protection, nor will DKIM. Zombies are far too
prevalent.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org
|
|