Doug,
I'd appreciate it if you could raise each of these (that survive
this reply:-) as separate issues according to the scheme we've
set out. And don't forget to include specific alternate text for
each.
Otherwise you're making my agenda-building life harder (and
therefore your issues won't appear on the agenda:-)
As far as I can see at the moment, only one of them (#2, as
rephrased below) should create a new issue for the threats
draft.
Douglas Otis wrote:
As other avenues close, the Signing-Domain's Administrative Unit
represents a primary area of concern not properly considered in the
threat draft.
1) Access in the Signing-Domain's Administrative Unit
Bad actors in the form of rogue or unauthorized users or
malware-infected computers can exist within the administrative unit
corresponding to a message's origin address. Although the submission of
messages in this area generally occurs prior to the application of a
message signature, DKIM can offer a means to detect and implement
controls against these bad actors;
IMO there's nothing in the above that's not covered in the threats
draft already.
> see Opaque-ID.
This, I believe, is your point, but you're misdirecting your comment
since this is really an issue you have with the base draft.
So, I'd be of a mind to not open a new issue in response to the above
(i.e. to immediately dispose of it as rejected).
2) Chosen Message Replay (High impact)
The rapid pace at which the message might be replayed (especially with
an army of "zombie" computers), compared with the time required to
detect the attack and implement key revocation, is likely to be
ineffectual. A related problem is the likelihood that domains will use
a small number of signing keys for a large number of customers, where
key revocation will also result in collateral blocking of messages.
At the extreme, verifiers might be required to check a listing for each
signature verified, which would result in significant transaction
rates. An alternative, "revocation identifiers", has been proposed
which would permit revocation on an intermediate level of granularity,
perhaps on a per-account basis. Messages containing these identifiers
would result in a query to a revocation database, which might be
represented in the sender's DNS.
Primarily due to many users having compromised systems, block-lists
still permit a substantial amount of email abuse to be emitted from
large domains. Block-listing large domains remains problematic, as this
often interferes with millions of user messages. Often larger domains
apply rate-limiting to keep this abuse from exceeding a reasonable
portion of the overall messages. These abusive messages are however a
ready source of signed messages that could enable chosen message replay
abuse. Similar sources of signed messages could be obtained from
email-address providers or list-servers, as there is _no_ practical
means to vet individuals for low cost or often free services. One
motivation for chosen message replay abuse would be to evade typical
rate restrictions while having the message appear to be from a respected
source.
Sigh. That could all be stated as: "Issue: replay threats can be
countered in other ways than key revocation - the draft should allow
for such possibilities, e.g. schemes based around some form of
revocation label being included in/with the signature."
If you did that, I think you would be raising a genuine issue,
that although it has been mentioned (by you, repeatedly:-), hasn't
hit the issue list, and should.
Opaque-ID:
By including a persistent identifier within the signature header field,
the specific source of abuse emerging from signing domains can be
identified and succinctly reported. With this identifier, the
signing-domain would also be able to self block-list or revoke these
internal sources without requiring the expiry of a key TTL, or consuming
large amounts of DNS cache. The self block-list would also provide
essential feedback to a reputation service that actions were taken, as
the replay abuse may still persist. A reputation service must be
responsive to their subscribers who will demand that excessive amounts
of abuse be blocked.
A convention could be established where immediate acceptance of a
message requires that the HELO be verified and associated with the
signing-domain. Otherwise, delayed acceptance permits the needed time
for a third-party or self block-listing of abusive sources. The
stability of the DNS is highly indicative of abusive behaviors. The DNS
is succinctly identified when the HELO is verified.
(Cisco is recommending Sender-ID with DKIM. This recommendation may
create conflicts when dealing with the topic of DKIM DoS susceptibility.)
None of the above is related to the threats draft.
3) Increased Threats Due to Expedient Assessments (Why replay abuse has
a HIGH impact)
Bad acts related to the message envelope represents a potential threat
when the signing-domain is held liable for these acts. A forward
referenced DNS PTR list of HELO domains minimizes any impact. The
alternative of having each node of an SMTP message from anonymous
clients potentially trigger SPF script's maximals of 122 DNS
transactions (100) from foreign domains, when evaluating _each_ message
related domain-name, must be strongly discouraged. SMTP readily
distributes an SPF trigger to cascade targeted UDP traffic and enable
various dangerous attacks and exploits. Fortunately, HELO verification
only needs one lookup and can not lead to targeted network
amplification. When the HELO is within the signing domain, even a
lookup of the HELO domain list in the signing domain can be skipped.
The worst case DNS traffic amplification for a forward reference PTR
HELO list is 1 DNS transaction for a known and accepted sending-system.
There is _no_ means to defend the alternative practice that executes
script from anonymous clients which sequentially invokes hundreds of DNS
transactions per SMTP node.
And what's wrong with issue #1172? Again, my current plan is to
expediently assess this as a duplicate and reject.
4) Risks of Confusion Using Sub-domains
Not all users or sources sending messages within an email-address domain
may be trustworthy enough to meet stringent requirements needed for
retaining trust. There is also often a desire to retain current
email-address assignments and also claim all messages from a domain are
signed. Without a means to group the trustworthiness of various email
sources within a domain, the overall trustworthiness of the domain is
significantly diminished. There should be a method, perhaps with a tag
within the DKIM key, to indicate whether the signing domain itself
considers the source of the message trustworthy. This trust assertion
mechanism could provide a means for a domain to retain their trustworthy
assessment, while still signing all messages. Messages sent from
trustworthy domains, but where the key is not also marked trustworthy,
should not convey assurances to the recipient unless overridden by a
local database maintained by the recipient.
Providers offering low cost or free services will not be able to
adequately vet their many users, who often number in the millions. This
same provider may wish to send messages from the same domain and have
these messages receive a trustworthy evaluation. Perhaps these would be
messages from a system administrator indicating that the user's system
appears compromised or that their payment information is no longer
valid. The use of trusted/non-trusted keys would permit the signing
domain to both retain their trustworthy status and prevent un-vetted
users within the same domain from spoofing with "trusted" messages.
That's largely sales talk and I can't see any valid issue applying
to the threats draft. Another expedient assessment.
5) Preventing Spoofs from Untrusted Sources (Signing roles needed)
In addition to the MDA marking messages as "trusted" based upon the
history of a domain's behavior and the status of the key, the
recipient's MUA could also perform a similar function using a locally
maintained list of trustworthy sources. The locally maintained list
could include additional information beyond just the domain name itself
to elevate the level of trust for specific email sources, even when not
indicated as trustworthy by the signing domain. This additional
information might relate to the account used to access the signing
domain and possibly the purported role of the signing domain.
Out-of-band source confirmation would be needed for a locally maintained
list. Without a purported role of the signing-domain being noted,
maintenance of a local list would become a nuisance resolving conflicts
when the same email-address appears from both MSAs and mediators.
As above.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html