Subject: [ietf-dkim] 5 outstanding issues with the threat review

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Mar 2006 20:48:54 -0800

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; see Opaque-ID.

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.

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

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.

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.

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.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Mar 2006 11:48:13 +0000

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

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

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

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 15 Mar 2006 09:06:33 -0500

I agree with what Stephen says about these, and in particular, that as 
we look at the threats doc we consider carefully what belongs there, as 
opposed to what should be brought up in discussion of the base doc.

Doug, if you decide to separate any of these out to ask that a new issue 
be opened, please really, really try to keep what you say concise -- I 
have trouble sifting through it, and I'm sure that the non-native 
English speakers have more trouble.

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

It's definitely not relevant to the threats doc, but I do think it could 
be a useful discussion to have about the base doc.  We've suggested that 
domains that want to divide their reputation create subdomains (the sort 
of thing like "official.bigbank.example" vs "users.bigbank.example"), 
but for various reasons not all domains want to do that.  It would be a 
reasonable discussion to have if one wanted to propose a tag in the key 
that defined the level of "officialness" or "trust" or some such that 
the signing domain places on the use of this key.  That allows the 
domain to use selectors, rather than subdomains, to make this division.

Doug's item 5 fits here too, but takes the discussion directly into the 
formation of reputation, which is out of this WG's scope.  I'd like to 
see more discussion of this in a separate group that addresses 
reputation and accreditation standards.

In any case, again, this is definitely NOT a threats doc issue.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 06:19:50 -0800

> domain to use selectors, rather than subdomains, to make this division.

That's more of an issue of SSP, right? It's with SSP that you'd
like to subdivide the policy (or pronouncement, or pedagogy, or
one of those P words). -Base doesn't really care one way or another
about this as it doesn't make any statement about the binding
of the identity to a policy.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Mar 2006 10:07:51 -0800

On Mar 15, 2006, at 6:06 AM, Barry Leiba wrote:

>>> 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  
> It's definitely not relevant to the threats doc, but I do think it  
> could be a useful discussion to have about the base doc.

The threat is to the trust value afforded by a DKIM signature.   
Creating sub-domains to isolate messages with different levels of  
trust is hazardous as this _will_ confuse many users.  Which domain  
should be trusted and which should be evaluated?  Don't forget many  
users also don't know the difference between "." and "-".  A  
proliferation in the use of sub-domains threatens the trust one may  
have in the message, as this expects the user to make assumptions  
about the delegation of domain zones.  This of course is a problem  
shared by the 'i=' construct in the signature header field.

> We've suggested that domains that want to divide their reputation  
> create subdomains (the sort of thing like  
> "official.bigbank.example" vs "users.bigbank.example"), but for  
> various reasons not all domains want to do that.  It would be a  
> reasonable discussion to have if one wanted to propose a tag in the  
> key that defined the level of "officialness" or "trust" or some  
> such that the signing domain places on the use of this key.  That  
> allows the domain to use selectors, rather than subdomains, to make  
> this division.

Explaining the threat to establishing trust still seems to belong in  
a threat document.  Details of a solution belongs in the base document.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Wed, 15 Mar 2006 14:04:56 -0500

> like to subdivide the policy

Mm, I see your point, but I don't know that we want SSP changing the key 
record, and that's where I'm thinking this would go ("This key is used 
for Really Serious Stuff"; "This key is used for Frivolous User Stuff"). 
  I'm not sure how to move that to SSP.

Barry

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 15 Mar 2006 12:37:32 -0800

> represents a primary area of concern not properly considered in the  

As an intellectual exercise I'll translate each of these into shorter 
pitches, appropriate for yelling semi-anonymously from the back of room 
during IETF meetings (I won't be in Dallas, so feel free to yell any of 
these on my behalf if you should feel so inclined.)

> 1) Access in the Signing-Domain's Administrative Unit

Somebody inside your network can do bad things inside your network!

> 2) Chosen Message Replay (High impact)

An edge case that we've known about since day 0 is still an edge case!

> 3) Increased Threats Due to Expedient Assessments (Why replay abuse  

Edge cases in SPF might reveal obscure problems with DNS!  (What does 
this have to do with DKIM?  Never mind, I don't want to know.)

> 4) Risks of Confusion Using Sub-domains

Users are confused by things they don't understand!

> 5) Preventing Spoofs from Untrusted Sources (Signing roles needed)

Bad MUA design is bad!

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Mar 2006 14:37:49 -0800

> Somebody inside your network can do bad things inside your network!

Conventions established with DKIM where third-parties can isolate  
accounts or internal sources for reporting and remediation, even when  
an account has been compromised, as many are.  This represents a  
substantial portion of the abuse dismissed in the threat review as  
being beyond the purview of DKIM.  It should not be.

> An edge case that we've known about since day 0 is still an edge case!

Viewed from the aspect of establishing trust or preventing a Denial  
of Services due to high levels of abuse, DKIM can still offer  
defensive strategies beyond ineffectual key revocation.

>> 3) Increased Threats Due to Expedient Assessments (Why replay  
>> abuse has a HIGH impact)
>
> Edge cases in SPF might reveal obscure problems with DNS!

DKIM remains prone to attack as does SPF which provides an ideal  
vehicle.  There is no sanctuary found relying upon SPF for protection  
which can target 100 DNS transactions for each domain-name evaluated  
at each location where an evaluation occurs.  There is a possible  
solution verifying the HELO and using forward reference PTR lists to  
associate the DKIM signature with the HELO.  Verifying the HELO and  
delayed acceptance can defeat most attack scenarios.  There is  
nothing in the threat view that provides a concept how DKIM is to be  
defended.  It seems there should be a more holistic view of security.

> Users are confused by things they don't understand!

Trust can not be established using sub-domains.  Not all email from a  
domain should be trusted, even when it is signed.  The signing domain  
can greatly improve upon trust by marking which keys are for  
trustworthy sources within their domain.  Yahoo.com signatures, in  
general, should not receive any assurances.  A special case can be  
made when special keys are used.  [email-masked] when used with a  
special key could be qualified as trustworthy, for example.

>> 5) Preventing Spoofs from Untrusted Sources (Signing roles needed)

When not all signed messages are to be considered trustworthy,  
sorting through the remainder will involve a user interface.  The  
number of prompts needed to administer trust locally must be  
minimized or security is diminished.  Signing Roles improves the MUA  
interface for administrating local trust.

-Doug