Subject: Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]

From: Jim Fenton <[email-masked]>
Date: Thu, 05 Jan 2006 22:08:34 -0800

Douglas Otis wrote:

> Jim,
>
> Today I'll publish a rough-cut draft for the recognition options that 
> have been suggested.  Here is a quick review of your threat summary.
>
>
>
> 1.1.  Terminology and Model
>
> It would be better to put a place holder for the signer-practices 
> query as well.  An alternative to an authorization strategy would be 
> effective against many modes of attack.  Once a recognition strategy 
> is considered, this signer-practices mechanism changes substantially.

Do you mean that there should be some informative description of the
signer practices query here (as with the other placeholder)?

>
>
>
> 2.1.  Characteristics
>
> This talks about falsifying the "origin address" of messages.  Should 
> the base DKIM draft be seen as a means to ensure the identity of the 
> author, which I assume this "origin address" is intended to imply?  
> Any suggestion that a particular header _may_ have the email-address 
> restricted by DKIM  invites open-ended authorization mechanisms that 
> have in the past been used to unfairly shift the burden of 
> accountability, and may lead to highly dangerous assurances.

"Origin address" is defined in Appendix A (in fact, it's the only thing
defined in Appendix A at this point!).  Unlike S/MIME and PGP
signatures, DKIM signatures do not assert the identity of the author, so
the origin address does not imply that.  You're still missing me with
terms like "open-ended authorization mechanisms"; since you say they
have been unfairly used in the past, can you give an example?

>
>
>
> 2.3.1.  Externally-located Bad Actors
>
> As the majority of abusive email is being sent through compromised 
> systems, why should DKIM ignore what can be done to identify these 
> sources within the sending Administrative Unit?  That should be a 
> primary focus.

DKIM could be used within the sending Administrative Unit (AU), but to
fully do so would imply signing at the MUA.  Within the sending AU,
there are easier-to-use mechanisms available to achieve the same thing: 
for the originator to authenticate themselves to the first-hop MTA, for
example.  DKIM signatures come from the domain owner; this is most
easily (and most securely) administered if signing is done relatively
centrally.

>
>
>
> 2.3.3.  Within Recipient's Administrative Unit
>
> Rather than recommending [I-D.kucherawy-sender-auth-header] headers, 
> the MDA could sign and avoid many receiving Administrative-Unit attacks.

It could, but deployment would suffer because the MUA would need to
change in order to verify that signature.  DKIM can be deployed in that
manner, with no change to the specifications, if spoofed
Authorization-results headers get to be a problem.  Perhaps this should
be pointed out in the threat document.

>
>
>
> 3.1.  Use of Arbitrary Identities
>
> "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."
>
> This is a poor use of the word accountability.  Accountability 
> implies being held to an expectation.  The signer is always 
> accountable for their actions, however their actions may not always 
> be trustworthy.
>
> reworded:
> A valid signature can be used to properly assign accountability, 
> however a valid signature does not imply that the signer can be trusted.

I'll stipulate that accountability may be the wrong word.  However, your
rewording doesn't pick up the concept that the domain registration may
be fraudulent, and in that case I don't think it's properly assigning
accountability.  I was trying to convey that there is a dependency here
that puts an upper bound (a rather low upper bound, at that) on the
ability to identify the domain owner of a properly signed message.

>
>
>
> 3.2.  Use of Specific Identities
>
> This could be further illustrated by "online-example.com" where 
> people do not understand the significance of "-" from that of the 
> ".".  Continue by also reviewing unicode extensions related to 
> RFC2047 and RFC3492, (the Unicode TR 36 reference in the 
> international domain names section seems to imply this does not 
> affect non-internationalized domains).  Add further examples where 
> the domain name is in Puny-Code.  Considering that in most cases the 
> native character-repertoire would be different from that of the raw 
> Puny-Code, visual examination of the domain name becomes virtually 
> meaningless.  Unless DKIM avoids reliance upon visual examination, 
> little is gained.  Any DKIM assurances that a signature was verified 
> and was in compliance with some practice will only increases the 
> success of targeted attacks.

Thanks for the suggestions, although I thought that the "examp1e.com"
example made it clear that this isn't strictly an IDN problem.  Since
I'm not familiar with all of these, can you write some text for this?

>
>
>
> 3.2.1.  Exploitation of Social Relationships
>
> "DKIM would be effective in mitigating these acts by limiting the 
> scope of origin addresses for which a valid signature can be obtained 
> when sending the messages from other locations."
>
> What mechanism is this describing?  After completing section 3.2, 
> 3.2.1 can not make a statement of effectiveness, nor is this a direct 
> function of DKIM.

The concept is that if one of my correspondents with my address in their
address book gets compromised by malware, it currently is likely to
start sending messages from their system using "[email-masked]" as the
>From address.  DKIM is effective in that it is not possible for them to
send such a message with a DKIM signature from the cisco.com domain
owner.  If they want to send messages signed by the address of origin,
their choice of addresses is much more limited.

>
>
>
> 3.2.2.  Identity-Related Fraud
>
> This does not make any clear statement other than to say that the 
> "address of origin" may contribute to fraud.  How does this relate to 
> DKIM?

Agreed, this section needs to say something about DKIM effectiveness in
this case, like the other 3.x sections do.

>
>
>
> 3.2.3.  Reputation Attacks
>
> DKIM will not defeat a DSN with an invalid return-path, as the 
> content of the message would be expected to have been changed.  One 
> practice similar to or part of the "joe-job" (Spam appearing to be 
> from an innocent third party, and named after a victim Joes.com) is 
> to invoke a bounce where the return-path is also invalid and used to 
> eventually deliver the message.   This would work much like not 
> putting a stamp on a letter where the return-address contains the 
> desired recipient.  Unless DKIM signatures are checked within the 
> SMTP session, an invalid signature may generate the "desired" 
> bounce.  As reputation should be based upon verifiable source 
> identifiers within the message, reputation would not be effective at 
> dealing with invalid addresses when not used by the recipient 
> creating the DSN.  Reputation does not deal with message replay abuse 
> either.

I would probably characterize this as a different sort of attack, a
"reflection attack", and put it in its own section.  Sound OK?

>
>
>
> 4.1.  Attacks Against Message Signatures
>
> Why would a Signed message replay have a low impact when the 
> likelihood is high?  What identity is being used to accrue 
> reputations? The same issue would be involved with compromised 
> systems within the originators Administrative Unit.  The Display name 
> abuse is only indicated as having a Medium impact, but for the 
> majority of recipients, this would represent a significant risk, 
> especially if there was any assurances made.

The definitions of impact and likelihood are given at the beginning of
section 4.  For signed message replay, impact is low because the replay
affects only that message; it does not, for example affect other
messages from the domain.

DKIM does not define a reputation service, so the "what identity"
question is moot.

I tagged the impact of display name abuse as medium because it impacts
some MUAs more than others; those that hide the email address and only
show the display name are more problematic.

>
>
>
> 4.1.9.  Body Length Limit Abuse
>
> "Recipients need to use means to, at a minimum, identify the unsigned 
> content in the message."
>
> What is this assuming?

The problem here might be the assumption that the verifier (typically an
MTA) knows what the MUA is and whether it can distinctively display the
signed content distinguished from the unsigned content.  Another
approach is just to truncate the message at the signed content length
when it is verified.

>
>
>
> Consider dropping the following sections for now:
>
> 4.2.3.  Denial-of-Service Attack Against Signing Policy
> 4.2.4.  Use of Multiple From Addresses

Why?

> 5.  Derived Requirements

This section is incomplete, but was added in response to a specific
request.  It makes sense to me because we're doing this before the WG
takes up the base and SSP drafts.  To some extent we get to define
what's in the threat analysis document, so if there is consensus (and
agreement from the chairs) that we don't need this section, I'll make it
go away.

-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Jan 2006 08:20:29 +0100

> ability to identify the domain owner of a properly signed message.

How about the following:

    DKIM's ability to identify a domain owner is [also] bounded by
whatever checks a registration authority imposes.

Eliot

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 6 Jan 2006 01:00:29 -0800 (PST)

> whatever checks a registration authority imposes.

You're going in the wrong direction.

Even if it may have been original intent long ago, currently
domain registration authorities do not do any checking of the
domain owner's identify and the commodity of the provided services
clearly reflects that (as is the pricing for TLD domains; market
is used to this and situation is unlikely to change).

Domain identity is really self-identification and the same service
would be provided by domain-bound email signatures discussed on this
list - they allow domain owner to self-identify itself and provide
cryptographic means to link the email message to this self-identity.

The accountability of this identity is beyond the scope of the service 
provided by simple domain-based email signatures (at least based
on what is in scope within approved charter). This is something
that accreditation services supposed to do i.e. tell if the domain
owner is known and willing to take responsibility for the transactions
and who they really are (but if this is going to actually be of any
value depends on that accreditation providers do not just take money
from somebody willing to pay but actually do some sort of verification
of who they are dealing with). Now even when you having somebody who
you can hold accountable, that does not mean they are good player in
email arena (who is good and bad is area for reputation services).

Now can we please go back to your draft and make it clear that
signature only establishes link between email message and some
domain name. Anything further then that such as verifying
domain owner identity and accountability would have to be
provided by some other means and different service.

---

BTW - Personally I think the link should be provided not to domain
name but directly to email address level whenever possible. The
email address identities in messaging network are as host identities 
on the ip network and with SSL we almost always use "host.domain.com"
as appropriate identify for SSL certificates but do also allow for
wildcard certificates i.e. "*.domain.com".

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Jan 2006 11:40:44 +0100

Oddly I think we are agreeing, so perhaps we're both going in the wrong
way ;-)  I thought the point was to bound DKIM's capability.  On the
other hand, one could imagine a strict requirement for domain assignment
in some TLDs (perhaps this is already the case with .gov?).  Regardless,
absent that level of authentication between the registrar and the domain
"owner" you're left with reputation services...

Eliot

---

From: Andrew Newton <[email-masked]>
Date: Fri, 6 Jan 2006 09:21:01 -0500

> "owner" you're left with reputation services...

Actually, there are TLD registries that do have registration rules.   
This is true of many ccTLDs and some of the sTLDs (sponsored TLDs).   
But the vast majority of domain registrations are in TLDs that have  
no registration rules of the type being discussed here.

>> whatever checks a registration authority imposes.

could be read to mean some domain registration rules can be counted  
upon for this purpose.  Practically speaking, I don't think this is  
true at all.

-andy

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Jan 2006 15:28:05 +0100

> upon for this purpose.  Practically speaking, I don't think this is

Would s/bounded/limited/ fix the problem?

Eliot

---

From: Andrew Newton <[email-masked]>
Date: Fri, 6 Jan 2006 10:32:52 -0500

> Would s/bounded/limited/ fix the problem?

I am thinking "no."  DKIM's ability to identify a domain owner is not  
limited by registration authority rules because there may be or will  
be reputation services separate from the registration authority.

Besides, I don't think DKIM is ever identifying the owner of a domain  
name since that information is not in DNS.  If the Acme Widget  
company has the domains acmewidgets.com, acme-widgets.com, and acme- 
widgets-inc.com, there is nothing in DNS that tells me all three are  
owned by Acme Widgets (well, nothing you can rely upon).

-andy

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jan 2006 12:52:27 -0800

On Jan 5, 2006, at 10:08 PM, Jim Fenton wrote:

>> query as well.  An alternative to an authorization strategy would  
>> be effective against many modes of attack.  Once a recognition  
>> strategy is considered, this signer-practices mechanism changes  
>> substantially.
>
> Do you mean that there should be some informative description of  
> the signer practices query here (as with the other placeholder)?

DKIM could offer greater protection by making it practical for the  
protection to be generally applied.  An authorization scheme as  
envisioned in SSP limits applicability of DKIM's protection to  
domains willing to relinquish many services, such as mailing-lists or  
alternative providers.

As such, and with a general understanding signer-practices are still  
in transition, excluding conclusions or assurance related to this  
mechanism could be postponed until further progress in made in that  
area.  Much better protection generally applied is possible.  The  
focus should be on the base DKIM draft for the threat review.

>> 2.1.  Characteristics
>>
>> This talks about falsifying the "origin address" of messages.   
>> Should the base DKIM draft be seen as a means to ensure the  
>> identity of the author, which I assume this "origin address" is  
>> intended to imply?  Any suggestion that a particular header _may_  
>> have the email-address restricted by DKIM  invites open-ended  
>> authorization mechanisms that have in the past been used to  
>> unfairly shift the burden of accountability, and may lead to  
>> highly dangerous assurances.
>
> "Origin address" is defined in Appendix A (in fact, it's the only  
> thing defined in Appendix A at this point!).  Unlike S/MIME and PGP  
> signatures, DKIM signatures do not assert the identity of the  
> author, so the origin address does not imply that.  You're still  
> missing me with terms like "open-ended authorization mechanisms";  
> since you say they have been unfairly used in the past, can you  
> give an example?

"Origin address - The address on an email message, typically the RFC
  2822 From:  address, which is associated with the alleged author of
  the message and is displayed by the recipient's MUA as the source of
  the message."

This appendix definition is not a valid statement.  The author of a  
message is _not_ the source of the message.  The DKIM signature  
provides an indication of the source of a message.  It would be an  
assumption that some email-address was valid, even when within the  
same domain as the signature, unless there was some explicit  
assurance made by the signer with respect to this conclusion.   
Authorization may be seen as a method to communicate such assurances,  
but there are better ways that can be more generally applied and  
offer different gradations of assurances as well.

By "open-ended authorization" this means third-party signatures or no  
signatures are permitted.  Accruing reputation based upon discovery  
of an authorization, as with Sender-ID which described this as  
"authentication," would be an example of the unfair use of  
authorization.  The desire to shift accountability onto the email- 
address domain owner has caused a fair amount of equivocation with  
respect to what is authentication.  As a result, it would be rather  
foolish to assume that open-ended authorizations are innocuous.

>> sources within the sending administrative Unit?  That should be a  
>> primary focus.
>
> DKIM could be used within the sending Administrative Unit (AU), but  
> to fully do so would imply signing at the MUA.  Within the sending  
> AU, there are easier-to-use mechanisms available to achieve the  
> same thing: for the originator to authenticate themselves to the  
> first-hop MTA, for example.  DKIM signatures come from the domain  
> owner; this is most easily (and most securely) administered if  
> signing is done relatively centrally.

As an option, it should be possible to establish a convention noting  
the account used to access the MSA or which delegated key was used.   
If you review the DKIM-Options draft, this describes how this  
information may be carried in both centralized and non-centralized  
settings.  Again, as compromised systems within the originating AU  
represent where a substantial amount of spam originates, being able  
to track it systematically by third-parties should permit rapid  
curtailment.

>> Rather than recommending [I-D.kucherawy-sender-auth-header]  
>> headers, the MDA could sign and avoid many receiving  
>> Administrative-Unit attacks.
>
> change in order to verify that signature.  DKIM can be deployed in  
> that manner, with no change to the specifications, if spoofed  
> Authorization-results headers get to be a problem.  Perhaps this  
> should be pointed out in the threat document.

The MUA should only see the MDA signature.  The MDA signature would  
specifically be declared as invalid in other domains to prevent this  
as a source for a replay attack.  If you review the DKIM-Options  
draft, this is clarified there.

>> "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."
>>
>> accountable for their actions, however their actions may not  
>> always be trustworthy.
>>
>> reworded:
> I'll stipulate that accountability may be the wrong word.  However,  
> your rewording doesn't pick up the concept that the domain  
> registration may be fraudulent, and in that case I don't think it's  
> properly assigning accountability.  I was trying to convey that  
> there is a dependency here that puts an upper bound (a rather low  
> upper bound, at that) on the ability to identify the domain owner  
> of a properly signed message.

Your concerns seem to be based upon assumptions related to assuring  
the identity of individuals.  This is well beyond what is expected of  
DKIM.  S/MIME or OpenPGP attempt to offer assurance of the  
individual.   It would seem greater clarity would be achieved by  
stating only the _domain_ is being held accountable without this  
implying there is any DKIM association whatsoever with individuals.   
The trustworthiness of the domain as an identifier and how it may  
relate to some individual (good or bad) would require subsequent  
evaluation independent of DKIM.

>> the domain name is in Puny-Code.  Considering that in most cases  
>> the native character-repertoire would be different from that of  
>> the raw Puny-Code, visual examination of the domain name becomes  
>> virtually meaningless.  Unless DKIM avoids reliance upon visual  
>> examination, little is gained.  Any DKIM assurances that a  
>> signature was verified and was in compliance with some practice  
>> will only increases the success of targeted attacks.
>
> Thanks for the suggestions, although I thought that the  
> "examp1e.com" example made it clear that this isn't strictly an IDN  
> problem.  Since I'm not familiar with all of these, can you write  
> some text for this?

Sure. : )

>> scope of origin addresses for which a valid signature can be  
>> obtained when sending the messages from other locations."
>>
>> 3.2.1 can not make a statement of effectiveness, nor is this a  
>> direct function of DKIM.
>
> The concept is that if one of my correspondents with my address in  
> their address book gets compromised by malware, it currently is  
> likely to start sending messages from their system using  
> "[email-masked]" as the From address.  DKIM is effective in that  
> it is not possible for them to send such a message with a DKIM  
> signature from the cisco.com domain owner.  If they want to send  
> messages signed by the address of origin, their choice of addresses  
> is much more limited.

Again that is assuming the use of a restrictive authorization mode  
(which would preclude your participation on this list, for example).   
This also assumes how SSP works.  Could this be postponed until SSP  
is better developed?

>> "address of origin" may contribute to fraud.  How does this relate  
>> to DKIM?
>
> Agreed, this section needs to say something about DKIM  
> effectiveness in this case, like the other 3.x sections do.

Focus upon only holding the signing-domain accountable.  There are  
many threats that need to be handled in this respect.  Any statements  
regarding the protection of email-addresses would be based upon  
conjecture at this point.  DKIM in and of itself offers significant  
value by providing stable source identifiers.  While a highly  
constraining authorization scheme may attempt to utilize the base  
DKIM signature, there are other mechanisms that can be more generally  
applied to increase protections obtained by DKIM without curtailing  
most of the freedoms users currently enjoy.

>> content of the message would be expected to have been changed.   
>> One practice similar to or part of the "joe-job" (Spam appearing  
>> to be from an innocent third party, and named after a victim  
>> Joes.com) is to invoke a bounce where the return-path is also  
>> invalid and used to eventually deliver the message.   This would  
>> work much like not putting a stamp on a letter where the return- 
>> address contains the desired recipient.  Unless DKIM signatures  
>> are checked within the SMTP session, an invalid signature may  
>> generate the "desired" bounce.  As reputation should be based upon  
>> verifiable source identifiers within the message, reputation would  
>> not be effective at dealing with invalid addresses when not used  
>> by the recipient creating the DSN.  Reputation does not deal with  
>> message replay abuse either.
>

It would seem that a recommendation to check signatures prior to  
message acceptance, as well as considering some form of return-path  
tagging would be needed.  Calling this a "reflection attack" seems okay.

>> systems within the originators Administrative Unit.  The Display  
>> name abuse is only indicated as having a Medium impact, but for  
>> the majority of recipients, this would represent a significant  
>> risk, especially if there was any assurances made.
>
> The definitions of impact and likelihood are given at the beginning  
> of section 4.  For signed message replay, impact is low because the  
> replay affects only that message; it does not, for example affect  
> other messages from the domain.

There are no limits for the number of times a message is replicated,  
so saying "that message" does not provide any perspective of the  
magnitude.  The impact upon the domain's reputation would be high  
when this attack causes the domain to be blocked.  Such a message  
replay attack could include multiple messages to make individual  
signature blocking seem fruitless.  Reputation on signatures would  
represent a substantially large database that would require a longer  
period of time to disseminate.  There are techniques that could buy  
precious time when the message may be a replay.  There are also  
strategies that could consolidate this data down to accounts, rather  
than individual signatures.  Even these accounts could include a  
"redeemed" code prefix (a table that contains the current try at  
being good, referenced by the account).  How this could work is  
explained in the DKIM-Option draft.

> DKIM does not define a reputation service, so the "what identity"  

The concern is whether there is a practical solution for this  
problem.  The identity being used to mitigate this problem will  
significantly impact practicality.

> I tagged the impact of display name abuse as medium because it  
> impacts some MUAs more than others; those that hide the email  
> address and only show the display name are more problematic.

This category of MUAs represents the majority being used and are not  
readily changed.  Assuming that MUAs will change opens up a  
significant number of far superior solutions.  Either assume the MUA  
do not change and the email-address is not seen, or consider what a  
modification to the MUA could achieve.  It should be fair to say that  
until the MUAs change, DKIM does not greatly mitigate the impact of  
spoofing.  There have been many examples of mind's ability to ignore  
misplaced characters and such.  I would also suggest that even when  
the email-address is displayed, the rich character-repertoire  
available to the sender, as well as areas depending upon Puny-Code,  
visual examination still leaves the recipient highly prone.  This  
exposure also requires legitimate senders to expend a fair amount of  
resources to obtain look-alike domains, which often involves  
litigation.  This is where DKIM can make a significant difference  
that would be greatly enhanced by providing information what elements  
can be used to isolate the source of a message.  This too has been  
clarified in the DKIM-Options draft.  Until then, the impact remains  
high and the likelihood is high.

>> "Recipients need to use means to, at a minimum, identify the  
>> unsigned content in the message."
>>
>> What is this assuming?
>
> The problem here might be the assumption that the verifier  
> (typically an MTA) knows what the MUA is and whether it can  
> distinctively display the signed content distinguished from the  
> unsigned content.  Another approach is just to truncate the message  
> at the signed content length when it is verified.

This is assuming MUAs change.  Truncation should be the rule without  
exceptions.   The sender should obfuscate the prior signature and  
resign the message with the correct message length.  Signature  
obfuscation reduces the number of sources for a replay attack,  
especially as this would be commonly done by a list server.

>> 4.2.4.  Use of Multiple From Addresses

As you and Stephen have indicated, this would be based upon  
conjecture.  It seems a separate draft that involves the concerns of  
SSP would be appropriate rather than prematurely assuming the outcome  
of the SSP effort.

> request.  It makes sense to me because we're doing this before the  
> WG takes up the base and SSP drafts.  To some extent we get to  
> define what's in the threat analysis document, so if there is  
> consensus (and agreement from the chairs) that we don't need this  
> section, I'll make it go away.

Good.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 07 Jan 2006 11:15:17 +0100

> be reputation services separate from the registration authority.

Precisely.  We need to separate what DKIM does from what reputation
services do.
> name since that information is not in DNS.  If the Acme Widget company
> has the domains acmewidgets.com, acme-widgets.com, and
> acme-widgets-inc.com, there is nothing in DNS that tells me all three
> are owned by Acme Widgets (well, nothing you can rely upon).
You're right.  The information is contained within the registries. 
Whether a recipient can access that information ALSO depends on the
registry policies.

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Sat, 07 Jan 2006 10:35:46 -0800

> Whether a recipient can access that information ALSO depends on the

Often, the extent of owner verification is limited to what can be
determined by payment methods and DNS server information, as no other
confirmations, such as web or email logs, are made available, even when
the information is shared.  As the typical fee could be missed in a
credit card report, even payment information remains dubious, and
permits deny ability.

If the substantially anonymous owner has not committed bad acts, the
identification utilized to accrue a history of use should only employ
verified identifications, such as a validated DKIM signature.  With a
potential replay problem, even validation may not be adequate without
some expectation of a practical replay control.

Assuming there is a verified identifier, where there is some expectation
of replay control, the extent of accountability ends at the domain name.
It would not be practical within the current system to extend DNS based
identification to individuals.  Perhaps in a few cases, in conjunction
with corroboration, such as a history of use, this information could be
applied to known entities.

The advantage afforded by DKIM is avoidance of a certificate authority
which would provide entity identification more reliably.  Certificates
for MTAs would add a significant recurring expense and has made this
avenue attractive only in specific cases through private agreement.
Even with a certificate authority vouching for the identity, as with the
registrar, there would be a conflict of interest to also expect them to
judge the history of use.

-Doug

---

From: John Levine <[email-masked]>
Date: 7 Jan 2006 18:59:39 -0000

>> whatever checks a registration authority imposes.

The most we can hope for from registration authorities is that domain
names are relatively stable: whoever blah.biz is today is probably
whoever it was last week.  Having watched ICANN up close for the past
year, I can assure you this will not change.  The WHOIS data argument
is deadlocked between two equal and opposing stupid positions, the IP
lawyers on one side that demand that every domain contain complete
info needed to sue them, and the EFF crowd on the other that demand
unlimited anonymous speech using anonymous domains.  (You may hope
that I am making this up, but I am not.)

There are some sponsored TLDs that actually do enforce registration
rules, but the largest of them .TRAVEL has only about 10K
registrations and all of them put together are far smaller than the
1.2 million registrations in .BIZ, the smallest of the generic TLDs
and always will be.  So forget that.

>Precisely.  We need to separate what DKIM does from what reputation

Yes indeed.  DKIM will be plenty useful in the short run to whitelist
domains that system managers already know they like.  Reputation
services will broaden its utilitiy, but they're not essential.  After
all, how many of us have private lists of good and bad IPs for our
mail servers, separate from what we get from DNSBLs?  Just about all
of us, I suspect.

R's,
John

---

From: Mark Delany <[email-masked]>
Date: Sat, 7 Jan 2006 22:48:08 +0000

> rules, but the largest of them .TRAVEL has only about 10K

Another orth to this oganal might be registrars that enforce
registration rules. "Hi, I'm blah.biz and I've registered with the
you-can-find-me-to-sue-me registrar".

Rather than try to impose one choice or another on ICANN/registrars,
why not make the choices available to domain owners and let them
choose between anonymized or sue-able?

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 07 Jan 2006 15:46:45 -0800

> choose between anonymized or sue-able?

Consider the dynamics that may be created by including reputations of
the registrar in conjunction with the domain names.  Registrars _may_
become more interested in improving their vetting practices, but
criminal blitz attacks with even modest TTLs would be adequate for their
activities.  Even high ownership turn-over, where the registrar
justifies termination based upon some use agreement, may still benefit
the registrar, but then does little to curtail the problem.

Require a CA certificate be used in conjunction with the domain to
establish secure islands, rather off of a root?

-Doug

---

From: John Levine <[email-masked]>
Date: 8 Jan 2006 01:15:02 -0000

>you-can-find-me-to-sue-me registrar".

Not a terrible idea, but there is no such registrar and I doubt there
ever will be.  The margins in the GTLD registar business are
vanishingly small.  

Sure, someone could charge an extra $N for a findability service, but
what's the advantage of bundling that with registrations?  You find
out who someone's registrar is by asking the domain's WHOIS server,
and if you're going to do that, it's just as easy to query a third
party reputation service.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Sun, 08 Jan 2006 10:56:26 +0100

> choose between anonymized or sue-able?

Right.  I would imagine that reputation services would take this into
account.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 08 Jan 2006 14:19:27 +0000

> agreement from the chairs) that we don't need this  section, I'll make 
> it go away.

Well, I'm not so sure about that, since that section could be useful
later on.

The idea is that that section would contain whatever security (or
other I guess) requirements that we derive whilst doing the threat
analysis. Then when we're about at last call on the standards track
documents, we can check back and see if that document meets the
relevant requirements derived from the threat analysis. If it does,
fine. If not, then we should justify the divergence or fix something.

I'd personally rather we tried this and if its not turning out to
be useful (i.e. if we can't fairly easily derive some testable
requirements) then at that point we can delete the section or put
in some text as to why we're not deriving requirements.

Stephen.

PS: The charter does say we'll do/try this too.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 08 Jan 2006 14:18:12 -0800

> PS: The charter does say we'll do/try this too.

Could threats and derived requirement issues be split into separate
drafts?

1) Threats and security concerns specific to the base DKIM
   signature.

2) Threats and security concerns related to DKIM extensions:
  a) authorization
  b) abusive replay abatement
  c) assurances for email-addresses

Splitting this effort should add clarity.  Open issues should be noted
in the first DKIM threat draft.   With a compilation of open issues
determined by this effort, extensions addressing these issues could be
analyzed in a subsequent and separate draft.  This should allow the base
draft to make better progress.  This would also delineate the benefits
and limitations of the base DKIM signature.  The alternative of
combining this effort into one draft would be discussing complex issues
as general concepts, with a strong presumption of there being a forgone
conclusion.

The current combined approach seems to have reached an erroneous
conclusion.  An email-address authorization scheme based upon the From
header does not provides adequate protections for the email-address
domain owner and the recipient.  This approach also currently overlooks
issues related to the disruption of current practices and the potential
for the misuse of open-ended authorizations.  Extensions to DKIM are
equally complex and deserve examination, just as the base draft does.
The base draft however is better defined with a better underlying
consensus, and thus more amenable to meaningful review.  Solutions to
the open issues hopefully are still on the table.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jan 2006 08:19:56 +0000

Doug,

> Could threats and derived requirement issues be split into separate

Unless there's a very strong consensus in that direction, I'd
really rather not deviate from the charter before its even been
posted on the IETF web site.

Let's try to work the current draft so that its in shape for a
wg last-call by the end of next month.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Jan 2006 10:25:43 -0800

> wg last-call by the end of next month.

In that case, there could be greater clarity provided in the threat  
draft by creating separate sections splitting out threats and  
purported benefits related to mechanisms that extend the base DKIM  
signature.

There could be extension sections that speculate on:

  1) email-address based authorization
    a) first From
    b) multiple From
    c) Purported Responsible Address
    d) Return-Path
    e) role-based (MSA/MUA, Mediator, MDA/MUA)

  2) abusive replay abatement
    a) Per-user keys
    b) O-ID
    c) signature reputations
    d) call-back validation
    e) in-channel checks
    f) path registration
    g) key vectored aggregated revocation record (per OpenPGP)
       i. Assumes application vs DNS caching of user-keys
       ii. Assumes revocation record has short TTL

  3) email-address assurances (bindings)
    a) always signed
    b) verified local-part
    c) verified address
    d) account unique O-ID
    e) assurance verification

  4) Multiple signature handling
    a) Signing roles
    b) Header/Role relationships
    c) MDA signatures to mitigate replay sources

  5) DoS strategies
    a) use of EHLO (Also 2e)
    b) use of remote IP
    c) maximal limit of signatures

  6) Filter strategies
    a) use of signing-domain
    b) use of signatures
    c) use of O-ID
    d) use of revocation records
       i. local-part fingerprint
       ii. O-ID
       iii. (2g)

In several places within the current draft, declarations of benefits  
assume a particular extension, SSP.  The benefits, related  
limitations, caveats, and extension specific threats should be placed  
into separate sections.   The list of _possible_ extensions should  
not be limited to just that currently defined in SSP.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jan 2006 18:45:13 +0000

Doug,

Douglas Otis wrote:
> draft by creating separate sections splitting out threats and  purported 
> benefits related to mechanisms that extend the base DKIM  signature.

[...list deleted...]
> assume a particular extension, SSP.  The benefits, related  limitations, 
> caveats, and extension specific threats should be placed  into separate 
> sections.   The list of _possible_ extensions should  not be limited to 
> just that currently defined in SSP.

While I'm not sure I agree with your list (its too long for a start), I
do think that the less that the threats document assumes about ssp, the
better it'll be. So structuring it so as to be vague in respect of ssp
may be the right thing to do.

I also agree that the list of possible extensions should not be limited
so ssp-only, but I do not agree (if you're saying so) that the document
has to treat each potential extension equally.

I think the wg should guide the author on the level of detail, and
there are clearly more than a couple of folks who consider that
something-like-ssp is a fairly criticial extension (yes, I know there
is at least one who thinks the exact opposite:-), and something-like-ssp
was part of the BoF and is part of the charter so it won't go away just
now.

But before anyone starts drafting other extensions, I'd expect that any
other extension proposed would have to fit with the charter and be
addressed in sequence (i.e. earliest after the base is done) and needs
significant enough buy-in from the wg generally. If, for example, you
were to continue to develop your opaque-id ideas outside the wg and
then bring a more mature draft back to the wg after wg-last-call on
the base draft, then you might well get a much better reception than
if you tried to get that work done here and now. (Or maybe not, I
don't know.)

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Jan 2006 11:50:27 -0800

On Jan 9, 2006, at 10:45 AM, Stephen Farrell wrote:

>
> Doug,
>
> Douglas Otis wrote:
>>
>> In several places within the current draft, declarations of  
>> benefits  assume a particular extension, SSP.  The benefits,  
>> related  limitations, caveats, and extension specific threats  
>> should be placed  into separate sections.   The list of _possible_  
>> extensions should  not be limited to just that currently defined  
>> in SSP.
>
> While I'm not sure I agree with your list (its too long for a  
> start), I do think that the less that the threats document assumes  
> about ssp, the better it'll be. So structuring it so as to be vague  
> in respect of ssp may be the right thing to do.

The general sections should be vague (make no assumptions of  
benefits, etc),  but a section specific to a range of options that  
would fall under the general SSP email-address authorization scheme  
should be mentioned there.

> I also agree that the list of possible extensions should not be  
> limited so ssp-only, but I do not agree (if you're saying so) that  
> the document has to treat each potential extension equally.

The long list was to indicate the many possible uses of the base DKIM  
signature.  Compiling the list of positive and negative aspects of  
these various choices could help select/justify the final choice(s).   
There should not be any need to treat each option equally, as some  
will have disqualifying aspects which preclude any further exploration.

> something-like-ssp is a fairly criticial extension (yes, I know  
> there is at least one who thinks the exact opposite:-), and  
> something-like-ssp was part of the BoF and is part of the charter  
> so it won't go away just now.

Agreed.  This section for email-address authorization could include:

1) Risks associated with the misuse of "open-ended" authorizations.
2) The disruption caused by "closed" authorizations.
3) Possible coercive ratings when not publishing the record.
4) Exploitation of "open-ended" authorization being unfairly  
attributed to the mail-address domain owner.
5) Overhead when most records are not present for the email-addresses.
6) Label depth found in abusive email versus legitimate email.
7) Accommodating "closed" policies at the Mediator.
8) Increased overhead checking multiple From addresses. (Defeating 7)
9) Dictionary attacks of local-part authorizations.
10) Unintended DoS for short TTLs with authorizations.

> But before anyone starts drafting other extensions, I'd expect that  
> any other extension proposed would have to fit with the charter and  
> be addressed in sequence (i.e. earliest after the base is done) and  
> needs significant enough buy-in from the wg generally. If, for  
> example, you were to continue to develop your opaque-id ideas  
> outside the wg and then bring a more mature draft back to the wg  
> after wg-last-call on the base draft, then you might well get a  
> much better reception than if you tried to get that work done here  
> and now. (Or maybe not, I don't know.)

The threat draft should speculate about actions and counter-actions,  
so considering a wider range of mechanisms may help flush out  
neglected aspects to ensure there are fewer surprises.  Of course an  
individual writing an extensions draft to explain a mechanism does  
not mean this will become a WG draft.  Not writing the draft however  
would ensure just the opposite.

Consideration should be given with respect to rehabilitating a domain  
that has an inordinate number of signed messages being used  
abusively.  Any avenue where there is no defense will quickly become  
a busy highway of abusive traffic.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jan 2006 20:02:58 +0000

Doug,

> 4) Exploitation of "open-ended" authorization being unfairly  attributed 
> to the mail-address domain owner.

I'd love to see you write that text up that could be used in the
threats draft. I've yet to see it in a usable form.

Here's a challenge: can you do it using only 5 (I-D length:-) lines
each and so that they're all understandable?

If not, then maybe those are the wrong items.

If so, then we might be fairly easily able to determine whether
and how to incorporate them into the threat analysis.

Stephen.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Jan 2006 14:07:47 -0800

> focus should be on the base DKIM draft for the threat review.

I was hoping for a "yes" or "no".  Your initial comment sounded like it
was asking for a description of SSP to be included, and your last
paragraph sounds the opposite.

>>> unfairly shift the burden of accountability, and may lead to  highly
>>> dangerous assurances.
>>
>>
>> since you say they have been unfairly used in the past, can you  give
>> an example?
>
>

Help me clarify the definition then.  When a typical user looks at a
message, they decide "who it's from", as in "Oh, this is from Doug."  I
believe that with most MUAs this is the From address (or the display
name in the From address).   I have covered display name abuse in a
separate section.  There is no assertion of authorship from DKIM,
although I used the term "alleged author" to try to convey the "who it's
from" concept.  The address corresponding to "who it's from" is what I
want to call the Origin Address.

> foolish to assume that open-ended authorizations are innocuous.

Without SSP, third-party signatures and no signatures are also
permitted.  That's about as open-ended as it gets.  SSP closes that
loophole for certain domains that behave in particular ways.  That's
about as specific as I'd like to get until we get into the SSP
discussion in a few months.

>> AU, there are easier-to-use mechanisms available to achieve the  same
>> thing: for the originator to authenticate themselves to the 

I couldn't find this in the DKIM-Options draft. One way to look at this
might be to use the local part of the i= tag to indicate the account
accessing the MSA, although this might have problems if an
administrative assistant needs to send mail someone he or she supports. 
In that case if we used i=, it might cause the signature to be a
third-party sig.  It might also have privacy problems; that VP (let's
say) might not want it known that the message was sent by their
administrative assistant.

I'm thinking that it's up to the signing domain to include whatever
information (if any) they believe will help them track the source of
abuse.  It might be the submitter's username, or it might be an opaque
version that only the domain owner can associate with a real username,
for much the same reason as the opaque identifiers you have been
advocating are opaque.

> draft, this is clarified there.

This would require abandoning the concept that DKIM will be usable by
many legacy MUAs, since they will need to verify a signature.  I would
like to see substantial consensus that the additional security of
running signatures all the way to the MUA is worth it before we change
this.  Remember that the verifier can be the last MTA/MDA in the chain;
the opportunities for spoofing a verification header are fairly small at
that point.

>> upper bound, at that) on the ability to identify the domain owner  of
>> a properly signed message.
>
>

As you and several others have pointed out, it's not the role of DKIM to
identify the individual that is responsible for the domain, and
therefore responsible for signing.  It's really more like "this message
was signed by the owner of domain [foo], whoever that is."  I'll try to
rework that section to remove that implication.

>>> the native character-repertoire would be different from that of  the
>>> raw Puny-Code, visual examination of the domain name becomes 

Thanks for your text; I'll send a separate response to that message.

> This also assumes how SSP works.  Could this be postponed until SSP 

My wording doesn't depend on SSP; note the text, "limiting the scope of
origin addresses for which a valid signature can be  obtained".  This is
true with or without SSP.

>> Agreed, this section needs to say something about DKIM  effectiveness
>> in this case, like the other 3.x sections do.
>
>

When you're talking about holding some domain accountable, you're
getting into the realm of defining how reputation systems operate.  I,
too, think that a reputation system sould hold the signing-domain, and
not some other domain, accountable for messages it signs.  But we're not
designing the reputation system here, so let's let it drop.

>>> to invoke a bounce where the return-path is also  invalid and used
>>> to eventually deliver the message.   This would  work much like not
>>> putting a stamp on a letter where the return- address contains the
>>> identifiers within the message, reputation would  not be effective
>>> at dealing with invalid addresses when not used  by the recipient
>>> creating the DSN.  Reputation does not deal with  message replay
>>> abuse either.
>>
>>

Are you saying that you wouldn't accept messages without a valid
signature?  Sounds like a dangerous thing to do except in some very
specific cases.  Or that you would only generate bounce messages for
signed messages (and presumably ones signed by the RCPT-From domain)? 
That seems dicey too.

>>> name abuse is only indicated as having a Medium impact, but for  the

The degree to which a replay affects reputation depends on the way the
reputation system works.  It could, for example, only penalize the
reputation once for each unique signature.  I'm not saying this is the
right thing to do, just pointing out that this is reputation-system
dependent.

I'd be interested in opinions from others whether I mis-classified the
impact of replay attacks.

> high and the likelihood is high.

Outlook is the MUA I'm most familiar with that often doesn't display the
email address.  I'm not an Outlook user myself, so I don't know what the
circumstances are that it displays the address and when it doesn't; I'll
try to chat with some of the Outlookers (?) around here about what can
be done.

> especially as this would be commonly done by a list server.

An obfuscated signature is as good as no signature, so I gather you're
advocating that re-signers remove prior signatures.  Removing the prior
signature in order to avoid feeding a replay attack (presumably a Signed
Message Replay) is an interesting thought although I wonder if there
aren't better sources of signed messages available.

> SSP would be appropriate rather than prematurely assuming the outcome 

As Stephen has said, absent substantial consensus that we should
separate SSP from the threats document, we will continue to include it,
in as general terms as possible.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Jan 2006 19:08:40 -0800

On Jan 9, 2006, at 2:07 PM, Jim Fenton wrote:
>> domains willing to relinquish many services, such as mailing-lists  
>> or alternative providers.
>>
>> As such, and with a general understanding signer-practices are  
>> still in transition, excluding conclusions or assurance related to  
>> this mechanism could be postponed until further progress in made  
>> in that area.  Much better protection generally applied is  
>> possible.  The focus should be on the base DKIM draft for the  
>> threat review.
>
> I was hoping for a "yes" or "no".  Your initial comment sounded  
> like it was asking for a description of SSP to be included, and  
> your last paragraph sounds the opposite.

Per my understanding of Stephen's comments, a separate section  
specific to SSP would be useful.   Closed authorizations with SSP  
represent exceptional rather than general uses of DKIM.  Generalized  
statements regarding exceptional uses are misleading.  It would also  
add clarity to indicate the mechanism, beyond the general use of the  
DKIM signature, that offers the benefits.

Comments that reflect exceptional rather than general properties  
should be moved to a section specific to the exceptional mechanism:

1. Introduction
...
"permitting a signing domain to claim responsibility for the use of a  
given email address."

2.3.2.  Within Claimed Originator's Administrative Unit
...
"DKIM signatures can be used to distinguish between legitimate  
externally-originated messages [and attempts to spoof addresses in  
the local domain.]"

3.1.  Use of Arbitrary Identities
...
"DKIM is effective in mitigating against the use of addresses not  
controlled by bad actors..."

>> "Origin address - The address on an email message, typically the  
>> RFC 2822 From:  address, which is associated with the alleged  
>> author of the message and is displayed by the recipient's MUA as  
>> the source of the message."
>>
>> This appendix definition is not a valid statement.  The author of  
>> a message is _not_ the source of the message.  The DKIM signature  
>> Authorization may be seen as a method to communicate such  
>> assurances, but there are better ways that can be more generally  
>> applied and offer different gradations of assurances as well.
>
> Help me clarify the definition then.  When a typical user looks at  
> a message, they decide "who it's from", as in "Oh, this is from  
> Doug."  I believe that with most MUAs this is the From address (or  
> the display name in the From address).   I have covered display  
> name abuse in a separate section.  There is no assertion of  
> authorship from DKIM, although I used the term "alleged author" to  
> try to convey the "who it's from" concept.  The address  
> corresponding to "who it's from" is what I want to call the Origin  
> Address.

The recipient of a DKIM signed message can only verify the signature  
which then validates the accountable domain.  The "g=" (signer- 
address) parameter within the key does not impose any limitations  
upon what email-addresses may be found within headers.  This  
parameter simply provides additional information for review by the  
recipient, although how that information is used or even seen is  
questionable.   This means that the signer needs to signal (offer  
assurances) whether there was any email-address verifications being  
done on the sending side.

How about:
,---
| Account Specific Resource Identifier (ASRI)-  Depending upon
| the level of assurance being made, the email-address in
| conjunction with the signing-domain, or just the email-address
| domain in conjunction with the signing-domain indicates an
| account specific resource can be identified by the
| email-address.  In some cases, an O-ID may replace the role of
| the email-address as an ASRI.  When the appropriate assurance
| is provided, this identifier may be presumed to correlate with
| the entity or entities that uses or use the account associated
| with an email-address or a persistent O-ID.
'---

With a binding approach, a single letter code within the signature  
header 'w=' offers address assurances, for example: (per DKIM-Options)

Within signature header: 'w=b'  Always signed by MSA, broad ass.  
across email-domain

Translation: The sender validates permissions for the local-part of  
the associated domain.  Registering just the email-address domain, in  
conjunction with the signature, indicates a unique source for the  
message can be determined by the email-address and presumed to  
identify an entity or entities using an associated account.

With the SSP mechanism, it is not clear what assurance is being made.

Within SSP record: 'o=!'  All mail from the entity is signed; Third- 
Party signatures SHOULD NOT be accepted.

Translation: The sender signs all messages from this domain, but  
offers no assurances of permissions.  This assertion is only useful  
for rejecting unsigned messages.  There should be no presumption that  
the email-address identifies a unique source or that it pertains to a  
specific resource or entity.

What I suspect you are attempting to define is whether the signing- 
domain has verified the permissions for the use of the email- 
address.  This assurance however is not a property of the SSP  
mechanism, but this is a property of the binding assertion. : )

>> By "open-ended authorization" this means third-party signatures or  
>> no signatures are permitted.  Accruing reputation based upon  
>> discovery of an authorization, as with Sender-ID which described  
>> this as "authentication," would be an example of the unfair use of  
>> respect to what is authentication.  As a result, it would be  
>> rather foolish to assume that open-ended authorizations are  
>> innocuous.
>
> loophole for certain domains that behave in particular ways.   
> That's about as specific as I'd like to get until we get into the  
> SSP discussion in a few months.

Nevertheless, this is a threat review and there should be some  
explanation of the risks associated with "open-ended" authorizations  
when they are misused as an accountable identifier.

This may influence decisions regarding open-ended assertions, and  
whether assertions apply to sub-domains or not.  For example, if a  
TLD published a policy 'o=.' which could be valid, all sub-domains  
must then publish a policy to be able to send email.  If the SSP used  
its own RR, then the TLD may publish this policy to ensure the search  
is terminated before impacting their servers.  If the TLD published  
an "open-ended" policy, this may become the spoofed address of  
choice, which would then destroy the TLD's ability to also send mail.

>> As an option, it should be possible to establish a convention  
>> noting the account used to access the MSA or which delegated key  
>> was used.  If you review the DKIM-Options draft, this describes  
>> how this information may be carried in both centralized and non- 
>> centralized settings.  Again, as compromised systems within the  
>> originating AU represent where a substantial amount of spam  
>> originates, being able to track it systematically by third-parties  
>> should permit rapid curtailment.
>
> I couldn't find this in the DKIM-Options draft. One way to look at  
> this might be to use the local part of the i= tag to indicate the  
> account accessing the MSA, although this might have problems if an  
> administrative assistant needs to send mail someone he or she  
> supports.  In that case if we used i=, it might cause the signature  
> to be a third-party sig.  It might also have privacy problems; that  
> VP (let's say) might not want it known that the message was sent by  
> their administrative assistant.

The account used to access the MSA may not constrain the email- 
address being used within the message, and may not associate a unique  
email-address with the account.  In addition, exposing additional  
email-addresses within an email relinquishes more of the account  
holder's privacy than would a persistent O-ID as defined in the DKIM- 
Options draft for this purpose.

> information (if any) they believe will help them track the source  
> of abuse.  It might be the submitter's username, or it might be an  
> opaque version that only the domain owner can associate with a real  
> username, for much the same reason as the opaque identifiers you  
> have been advocating are opaque.

Unlike the 'i=', the 'u=' parameter does not expose an email-address  
and is assured to be valid as a single name label.  This identifier  
also indicates whether it is persistent with the account or not.  The  
'i=', by its nature of being an email-address, exposes a greater  
amount of information for less benefit when used in conjunction with  
other mechanisms related to account revocation.  In addition, the  
'i=' parameter could not function for delegated keys but would need  
to depend upon the 'g=' parameter instead.

>> The MUA should only see the MDA signature.  The MDA signature  
>> would specifically be declared as invalid in other domains to  
>> prevent this as a source for a replay attack.  If you review the  
>> DKIM-Options draft, this is clarified there.
>
> This would require abandoning the concept that DKIM will be usable  
> by many legacy MUAs, since they will need to verify a signature.  I  
> would like to see substantial consensus that the additional  
> security of running signatures all the way to the MUA is worth it  
> before we change this.  Remember that the verifier can be the last  
> MTA/MDA in the chain; the opportunities for spoofing a verification  
> header are fairly small at that point.

Any MTA within the MDA domain could add the signature and obfuscate  
the other signatures after determining whether they were valid.   
Introducing a MDA signature as described in the DKIM-Options draft  
would not preclude the use of legacy MUAs at all, but would replace  
the use of the results header that can be easily spoofed within the  
AU.  The reason for signing within the AU (AdmD per Dave's new  
terminology), would be to allow the verification process be done at  
the edge of the AU (where it would need to be if to avoid excessive  
DSN traffic) and then allow that information to be safely relayed to  
the MDA.  Whether the MUA also checks the MDA signature (signature  
for the MDA) would be immaterial.  The significant difference however  
is this prevents intra-domain attacks and precludes the recipient  
obtaining headers that could be used in a replay attack.

>>>> "DKIM would be effective in mitigating these acts by limiting  
>>>> the scope of origin addresses for which a valid signature can be  
>>>> What mechanism is this describing?  After completing section  
>>>> 3.2, 3.2.1 can not make a statement of effectiveness, nor is  
>>>> this a direct function of DKIM.
>>>
>>>
>>> The concept is that if one of my correspondents with my address  
>>> in their address book gets compromised by malware, it currently  
>>> is likely to start sending messages from their system using  
>>> "[email-masked]" as the From address.  DKIM is effective in  
>>> that it is not possible for them to send such a message with a  
>>> DKIM signature from the cisco.com domain owner.  If they want to  
>>> send messages signed by the address of origin, their choice of  
>>> addresses is much more limited.
>>
>>
>> (which would preclude your participation on this list, for  
>> example).  This also assumes how SSP works.  Could this be  
>> postponed until SSP is better developed?
>
> My wording doesn't depend on SSP; note the text, "limiting the  
> obtained".  This is true with or without SSP.

How is an email-address constrained by the signature?  There is  
_nothing_ within the base DKIM draft that does this.

>>>> This does not make any clear statement other than to say that  
>>>> the "address of origin" may contribute to fraud.  How does this  
>>>> relate to DKIM?
>>>
>> many threats that need to be handled in this respect.  Any  
>> statements regarding the protection of email-addresses would be  
>> based upon conjecture at this point.  DKIM in and of itself offers  
>> significant value by providing stable source identifiers.  While a  
>> highly constraining authorization scheme may attempt to utilize  
>> the base DKIM signature, there are other mechanisms that can be  
>> more generally applied to increase protections obtained by DKIM  
>> without curtailing most of the freedoms users currently enjoy.
>
> getting into the realm of defining how reputation systems operate.   
> I, too, think that a reputation system sould hold the signing- 
> domain, and not some other domain, accountable for messages it  
> signs.  But we're not designing the reputation system here, so  
> let's let it drop.

This difference of opinion seems to be related to some property for  
DKIM that does not seem to exist when reading the draft.  Perhaps you  
can explain how an email-address is constrained by a signature.  At  
this point, the suggestion was to move these assertions to the  
section related to the SSP mechanism.  Perhaps there is another  
mechanism within DKIM I have been overlooking.

>> message acceptance, as well as considering some form of return- 
>> path tagging would be needed.  Calling this a "reflection attack"  
>> seems okay.
>
> specific cases.  Or that you would only generate bounce messages  
> for signed messages (and presumably ones signed by the RCPT-From  
> domain)? That seems dicey too.

If messages are rejected due to an invalid signature (perhaps in  
combination with other factors), then this rejection should be done  
within the SMTP session prior to message acceptance.

Messages returned by auto-responders are creating substantial  
problems.  When these messages pummel a site adding DKIM signatures,  
differentiating these types of messages could be aided by return-path  
tagging.  Of course, spoofed return-paths could also be identified  
using this return-path tagging technique as well.  The DKIM signature  
would not be expected to survive an auto-responder, and thus could be  
rather easily spoofed to look real when returned to the supposed  
signing-domain.

> The degree to which a replay affects reputation depends on the way  
> the reputation system works.  It could, for example, only penalize  
> the reputation once for each unique signature.  I'm not saying this  
> is the right thing to do, just pointing out that this is reputation- 
> system dependent.

This strategy would seem rather easy to exploit.  A message sent to  
every email-address in the world would only count as a single  
message?  A large domain exposed to compromised systems could easily  
generate enough of these messages that would both out-run a reporting  
service and over-whelm an admin who attempts to filter based upon the  
signature.  Until there are reasonable methods to deal with a replay  
problem, reputation based upon the DKIM signature will offer little  
value.  Much of the abuse originates from these large domains that  
are extremely prone to this exploit.

> I'd be interested in opinions from others whether I mis-classified  
> the impact of replay attacks.

DKIM without reputation of course offers value in other ways.   
Perhaps that value is enough.

> Outlook is the MUA I'm most familiar with that often doesn't  
> display the email address.  I'm not an Outlook user myself, so I  
> don't know what the circumstances are that it displays the address  
> and when it doesn't; I'll try to chat with some of the Outlookers  
> (?) around here about what can be done.

Depending upon the version of Outlook, there are various ways to  
investigate the email address which remains out of view.  A right  
click and selecting properties may show the email address, and the  
Send to parameter may also show the email address.   This requires  
additional effort by the recipient to find this information.

>> This is assuming MUAs change.  Truncation should be the rule  
>> without exceptions.   The sender should obfuscate the prior  
>> signature and resign the message with the correct message length.   
>> Signature obfuscation reduces the number of sources for a replay  
>> attack, especially as this would be commonly done by a list server.
>
> An obfuscated signature is as good as no signature, so I gather  
> you're advocating that re-signers remove prior signatures.   
> Removing the prior signature in order to avoid feeding a replay  
> attack (presumably a Signed Message Replay) is an interesting  
> thought although I wonder if there aren't better sources of signed  
> messages available.

Obfuscation would occur when the signature is being replaced.  The  
obfuscation could indicate the results of a prior check.  If this  
overlaying of signatures, together with the use of an MDA signature  
(read "for the MDA signature") then as DKIM becomes popular and is  
more widely implemented by list servers, the number of sources for  
signatures that could be replayed would be significantly reduced.   
Tracking the source of abusive replay signatures may indicate where  
not to send signed messages as a precaution.

Thanks you for your time and effort.   I will attempt to respond to  
Stephen's last message shortly.  (When I have the time to be both  
brief and intelligible.  ;-)

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Jan 2006 10:30:34 -0800

> threats draft. I've yet to see it in a usable form.

Terminology:
    The terms "open-ended" and "closed" authorization are defined as:

       A basic function of email authorization referenced by way of an
       identity is to influence the acceptance or rejection of a  
message.
       The term "closed" indicates acceptance is based upon the identity
       being found within a defined set of identifiers.  When acceptance
       does not require that the identity be contained within a defined
       set, this is described as open-ended authorization.  This
       definition is not altered by the rating of messages once they are
       accepted.

    SSP 'o=' Qualifiers:
          "~" Signs some (open)
          "-" All signed & allow other signatures. (open)
          "!" All signed. (closed)
          "." Never sends mail. (closed)
          "^" Check user specific policy (deferred)

3.  SSP Related Threats

3.1  Risks associated with the misuse of "open-ended" authorizations

    Administrators often block abusive messages using lists of sources
    with a history of sending abusive messages.  Within email, the  
client
    IP address or verified host-name could be used to fairly identify
    sources.  Assuming a mechanism will deal with abusive replays, even
    the DKIM signature could be fairly used.
    Alas, an administrator may also consider acceptance granted by an
    email-address authorization as verification of this as a source
    identifier.  This strategy has the effect of holding the email-
    address domain owner culpable for authorizations that permit
    acceptance of abusive messages.  When the authorization is open-
    ended, the email-address domain owner is therefore exposed to unfair
    accruals of abuse based upon authorization.

3.2  Disruption caused by "closed" authorizations

    When closed authorizations are used, mediators or users obtaining
    access from other providers will likely be outside the set of
    identifiers contained within the authorization.  Closed
    authorizations will therefore disrupt common practices such as
    posting to list servers, use of e-invites, and other similar
    services.

3.3  Accommodating "closed" policies at the mediator

    When the mediator is a list server, one technique to ensure delivery
    may be to modify the header being checked to reference a different
    authorization record.  One form of this technique may introduce
    multiple From email-addresses where the first address conforms to  
the
    identity of the list-server.  A similar technique could be used to
    overcome closed authorizations imposed by providers where the user
    may also utilize two From addresses.  This could be needed when the
    second address is recognizable to the recipient, but otherwise
    prohibited by closed authorization.

3.4  Increased overhead checking multiple From addresses

    The From header within a message may contain any number of  
addresses.
    Some consider use of multiple addresses a valid means to overcome
    limitations of an authorization mechanism.  Alternatively, some wish
    to check authorizations for every From address to preclude this
    strategy being used to overcome the limitations imposed by
    authorizations.  Multiple From addresses could be confusing for the
    recipient and poorly handled by the email applications.  Precluding
    acceptance of any From address that would be in conflict with the
    specific email-address authorization further increases the overhead
    associated with searching for authorizations.

3.5  Coercive ratings when not publishing an authorization record

    Email-address authorization provides advantages for large domains.
    Large domains are much less sensitive to abuse histories as they are
    often excluded from block-lists due to their size.  However, smaller
    domains are much more prone to being negatively impacted by unfair
    accruals.

    Down-rating domains without email-address authorization by larger
    domains is a technique used to coerce other domains into publishing
    authorizations.  Open-ended authorizations are needed to permit
    current practices expected by customers, but then these
    authorizations may fall prey to bad actors who will utilize these
    authorizations for their abuse.  When these smaller domains become
    placed within block-lists, there will be an exodus over to the  
larger
    domains.  Coercing the use of the email-address authorization also
    mitigates the overhead associated with searching for these records.

3.6  Exploitation of "open-ended" authorization being unfairly
      attributed to the mail-address domain owner

    When messages obtain improved ratings which depend upon the email-
    address having been authorized, then open-ended authorization  
records
    will allow bad actor to use these authorization records to improve
    upon their message acceptance ratings.  To ensure messages are
    accepted after passing through other mediators, an open-ended
    authorization is required of the email-address domain owner.
    Unfortunately, the email-address domain owner is unable to control
    whether their authorization is seen as a "weak" form of
    authentication and subsequently used to accrue abuse from all
    permitted sources.  As a result of message ratings based upon
    authorization, open-ended authorizations, and the assumption of
    authorization being a "weak" identifier, the email-address domain
    owner may find their domain subsequently block-listed.

3.7  Overhead of  email-address authorization retrivial

    The overhead related to a defensive strategy should not increase the
    burden of the recipient as opposed to that of the sender.
    Unfortunately, walking up label trees searching for email-address
    authorization records imposes a relatively high overhead.  This
    overhead is kept high as few lookups return an authorization record
    and therefore the lack of a record will be retained only briefly
    within the DNS cache.

3.8  Label depth found in abusive email versus legitimate email

    Bad actors take advantage of an evolving structure of top, second,
    third, and forth level domains.  Often bad actors create a series of
    random labels above some domain to make it difficult to filter, as
    the significant level where the direct registration is made becomes
    difficult to determine algorithmically.  This practice tends to
    increase the number of labels found in abusive messages.

3.9  Dictionary attacks of local-part authorizations

    Defensive programs currently defend against dictionary attacks being
    attempted at the SMTP server.  DNS however is not normally designed
    to identify such searches, and with the lower latency of DNS, these
    searches can be more productive at determining valid email-addresses
    when user specific authorizations are being published.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jan 2006 09:18:08 +0000

Hi Doug,

Thanks for making the effort - I do appreciate it & will
post a substantive response later on today (gotta go
inflict myself on some unfortunate students in the
meantime:-)

Cheers,
S.

Douglas Otis wrote:
>       identity is to influence the acceptance or rejection of a  message.
>    with a history of sending abusive messages.  Within email, the  client
>    multiple From email-addresses where the first address conforms to  the
>    The From header within a message may contain any number of  addresses.
>    placed within block-lists, there will be an exodus over to the  larger
>    address having been authorized, then open-ended authorization  records

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jan 2006 14:17:32 +0000

Doug,

Thanks again for trying to be brief. I think it did make you
easier to understand.

>       definition is not altered by the rating of messages once they are

I don't think the term authorization is being properly applied
there. To me at least authorization is what's happening when
a policy enforcement point uses a policy decision point to get
a yes/no answer about some requested action.

For example, I could imagine a totally separate set of technologies
being used to decide whether or not a given message can be
delivered to a certain recipient (say if the message has a
security label like "restricted"). In such cases it'd be much
more natural to talk about something having authorized the message.

I think talking in terms of sender signing policy is clearer (in
the abstract I mean, not only nor exactly as currently specified
in the SSP draft).

>          "^" Check user specific policy (deferred)

The open/close/deferred distinction makes sense I guess.

Restated: "Policies can be open or closed. Open policies
define a set of conformant messages and are silent about
other messages. Closed policies define the set of
conformant messages and other messages do not conform to
the policy."

> 3.1  Risks associated with the misuse of "open-ended" authorizations

That'd be better put as "Consequences of "open" sender signing policies"
IMO. "Risk" and "misuse" are mostly pejorative terms here, since
some people want exactly this behaviour, though I agree that some
other people don't.

>    accruals of abuse based upon authorization.

Restated: "If a domain owner publishes an open policy, and if some
"bad" unsigned messages apparently emanate from that domain then
the domain owner's reputation may suffer." I think that that's true,
but of course its already true today without DKIM or SSP.

>    posting to list servers, use of e-invites, and other similar

s/authorizations/policies/ and s/disruption/consequences/ and
I'd agree. I'd also probably agree if someone said that the
domains who'll operate closed policies won't care since that
is just what they want for those domains.

Restated: "Closed policies can disrupt practices such as
posting to list servers, use of e-invites, and other similar
services."

>    prohibited by closed authorization.

I don't see the need to encourage >1 From here. Is this just you
finding fault with ssp or are you really saying that this is what
should be done? Anyway, >1 From is already mentioned in the
threats draft.

>    associated with searching for authorizations.

So don't do it! If your 3.3 didn't make it into the I-D then I
guess this wouldn't either since its contingent.

>    mitigates the overhead associated with searching for these records.

Everything there that I understood was already implied in 3.1 above
(that's after I applied the s/pejorative// filter:-)

>    owner may find their domain subsequently block-listed.

Restated: "If unsigned mail from domains with open policies is treated
any better on the basis that the policy exists, then bad actors will
search for open policies in order to select the value for a falsified
 From header." I think that that's true and points up that SSP will
have to carefully say what not to do.

>    and therefore the lack of a record will be retained only briefly

Restated: "Policy statement retrieval has a cost." But I guess
I knew that so I wouldn't think its worth saying. If SSP ends up
being too costly then it won't be used and will therefore do
no harm.

>    increase the number of labels found in abusive messages.

Restated: "Searching for a policy statement may have a significant
cost and bad actors can select messages so as to maximise this cost
in an attempt at DoS." Which if true means that SSP has to include
anti-DoS at design time, which is a good statement to make.

>    when user specific authorizations are being published.

There's already anothter thing which is called a dictionary attack
so I wouldn't use the term.

Restated: "Policy statements inherently expose information about
the domain to which the policy is intended to apply. Bad actors
can use this information to select values for inclusion in messages."

So, if I collect together those restatements then my synopsis
of your suggested text would be:

   "Policies can be open or closed. Open policies define a set of
   conformant messages and are silent about other messages. Closed
   policies define the set of conformant messages and other messages
   do not conform to the policy.

   If a domain owner publishes an open policy, and if some "bad"
   unsigned messages apparently emanate from that domain then the
   domain owner's reputation may suffer.

   Closed policies can disrupt practices such as posting to list
   servers, use of e-invites, and other similar services.

   If unsigned mail from domains with open policies is treated
   any better on the basis that the policy exists, then bad actors
   will search for open policies in order to select the value for a
   falsified From header.

   Searching for a policy statement may have a significant cost and
   bad actors can select messages so as to maximise this cost in
   an attempt at DoS.

   Policy statements inherently expose information about the domain
   to which the policy is intended to apply. Bad actors can use
   this information to select values for inclusion in messages."

I think (not that confidently mind you) that those statements
are correct, and if so, could imagine a wordsmithed version
ending up in the threats draft. Be interested in what others
think.

Cheers,
Stephen.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 12 Jan 2006 16:33:40 +0100

> ending up in the threats draft. Be interested in what others

Jim could copy it as is to his draft, I like it, no further
wordsmithing needed.
                           Bye, Frank

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Jan 2006 08:22:12 -0800

>   domain owner's reputation may suffer.

Why would any rational reputation system make such an assertion?
It is as stupid as holding domain holders responsible in the
absense of dkim or some other identification mechanism: the
domain holder has no way to prevent it. If this is a threat,
then so is "receivers may trash DKIM-signed messages just because
they feel like it", which is true but useless.

		Mike

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jan 2006 16:38:57 +0000

I dunno, I was paraphrasing. And that's why I also said:

 > I think that that's true,

(Are reputation systems really rational - must get that Turing
test dusted down so:-)

S.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Jan 2006 08:55:33 -0800

> (Are reputation systems really rational - must get that Turing

Sorry, I was mainly reacting to Frank's endorsement of your
list's inclusion. I don't really think this point is a valid
threat.

		Mike

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jan 2006 17:02:02 +0000

> list's inclusion. I don't really think this point is a valid

No probs.

S.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Jan 2006 20:38:02 +0100

Mike,

I think it depends on the prevalence of DKIM and the parameters of the
reputation service, which is out of scope and cannot be standardized.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Jan 2006 11:56:06 -0800

>reputation service, which is out of scope and cannot be standardized.

I'm not suggesting it's in scope for anything here, just that as a _threat_
it's akin to any other kind of threat of people doing something Really 
Stupid(tm).
And, as well all know, an infinite number is impossible to enumerate. In 
this
particular case, it would be the threat of somebody in the business that 
really
ought not be if they can't understand why this the wrong behavior.

If this belongs anywhere, it's in a BCP.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Jan 2006 13:02:25 -0800

On Jan 12, 2006, at 6:17 AM, Stephen Farrell wrote:

> there. To me at least authorization is what's happening when a  
> policy enforcement point uses a policy decision point to get a yes/ 
> no answer about some requested action.

I think I understand this perspective.  I will use terminology that  
perhaps more accurately reflects the actual mechanism.  I have looked  
at your restatements, but I feel much of the concern is being  
missed.  I have attempted to remove some of the offensive terminology  
and then emphasize what seems to have been overlooked.

   The terms "open-ended" and "closed" affirmation:

    A basic function of email-address affirmation referenced by way of
    a derived identity is to influence the acceptance or rejection of
    a message.  The term "closed" indicates acceptance is based upon a
    concurrent identity being found within a defined set of
    identifiers.  When acceptance does not require that the identity
    be contained within a defined set, this is described as open-ended
    affirmation.  This definition is not altered by the rating of
    messages once accepted.

   SSP 'o=' Qualifiers:
         "~" Signs some (open)
         "-" All signed & allow other signatures. (open)
         "!" All signed. (closed)
         "." Never sends mail. (closed)
         "^" Check User specific policy (deferred)

3.  SSP Related Threats

3.1  Risks associated with the misuse of "open-ended" affirmations

   Alas, an administrator may also consider acceptance granted as a
   result of an email-address affirmation as "verification of the
   reference identity as a source identifier".  This strategy has the
   effect of holding the email-address domain owner culpable for
   affirmations that lead to acceptance of abusive messages.  When the
   affirmation is open-ended, the email-address domain owner is
   therefore exposed to unfair accruals of abuse based upon
   affirmations.

3.2  Consequences of "closed" affirmations

   When closed affirmations are used, mediators or users obtaining
   access from other providers will likely be outside the set of
   identifiers contained within the affirmation.  Closed affirmations
   will therefore disrupt common practices, such as posting to list
   servers, use of e-invites, and other similar services.

3.3  Impact of accommodating "closed" affirmations

   As a result of affirmations being withheld, the use of multiple
   email-addresses could be employed.  When the mediator is a list
   server, one technique that could be used to ensure delivery would be
   to modify the header being checked to reference a different
   affirmation record.  One form of this technique may introduce
   multiple From email-addresses, where the first email-address conforms
   to the identity of the list-server.  A similar technique could be
   used to overcome closed affirmations imposed by providers where the
   user may also utilize two From addresses.  This could be needed when
   the second address is recognizable to the recipient, but otherwise
   prohibited by closed affirmation.

   The From header within a message may contain any number of addresses.
   Some may consider multiple email-addresses a valid means to overcome
   limitations imposed by an affirmation mechanism.  An email-address
   affirmation strategy should either recommend the selection of the
   first email-address or recommend all email-addresses be checked.  To
   permit a method for conveying the purported author, affirmations
   could be limited to the first email-address.  However, multiple From
   addresses creates risks by confusing the recipient and may be poorly
   handled by the email applications.  Precluding acceptance of any From
   address in conflict with an affirmation further increases the
   overhead associated with searching for affirmations.

3.5  Coercive ratings when not publishing an affirmation record

   Email-address derived affirmations provides advantages for large
   domains.  Large domains are much less sensitive to abuse histories as
   they are often excluded from block-lists due to their size.  However,
   smaller domains are much more prone to being negatively impacted by
   unfair accruals.

   Down-rating domains without email-address affirmations by larger
   domains is a technique used to coerce other domains into publishing
   affirmations.  Open-ended affirmations are needed to permit current
   practices expected by customers, but then these affirmations may fall
   prey to bad actors who utilize them for their abuse.  When these
   smaller domains become placed within block-lists, there will be an
   exodus over to the larger domains.  Coercing the use of the email-
   address affirmation also mitigates the overhead associated with
   searching for these records.

3.6  Exploitation of "open-ended" affirmation being unfairly attributed
      to the mail-address domain owner

   When messages obtain improved ratings which depend upon the email-
   address having been affirmed, then open-ended affirmation records
   will allow bad actor to use these affirmation records to improve
   their message acceptance ratings.  To ensure messages are accepted
   after passing through other mediators, an open-ended affirmation is
   required of the email-address domain owner.  Unfortunately, the
   email-address domain owner is unable to control whether their
   affirmation is seen as a "weak" form of authentication and
   subsequently used to accrue abuse from all permitted sources.  As a
   result of message ratings based upon affirmation, open-ended
   affirmations, and the assumption of affirmation being a "weak"
   identifier, the email-address domain owner may find their domain
   subsequently block-listed.

3.7  Overhead of email-address affirmation retrivial

   The overhead related to a defensive strategy should not increase the
   burden of the recipient as opposed to that of the sender.
   Unfortunately, walking up label trees searching for email-address
   affirmation records imposes a relatively high overhead.  This
   overhead is kept high as few lookups return an affirmation record and
   therefore the lack of a record will be retained only briefly within
   the DNS cache.  This increased overhead must be mitigated or this
   will increase the susceptibility of being overwhelmed by abusive
   messages.

3.9  Email-address guessing attacks of local-part affirmations

   Defensive programs currently defend against email-address guessing
   attacks being attempted at the SMTP server.  DNS however is not
   normally designed to identify such searches, and with the lower
   latency of DNS, these attacks can be more productive at determining
   valid email-addresses when user specific affirmations are being
   published.

> So, if I collect together those restatements then my synopsis of  
> your suggested text would be:
>

Open policies (open affirmations) affirm the use of the email-address  
by indicating what signatures or lack of signatures are acceptable.   
In the case of an open affirmation, the use of any email-address is  
equally affirmed.  The reference identifier is derived from the email- 
address which is affirmed when the signature is within the set of  
concurrent identifiers determined by the SSP record.  On the other  
hand, a closed policy only affirms with specific signatures.   
Assuming there is value associated with the email-address domain  
matching the signing-domain, this value would be independent of the  
affirmation derived from the email-address.

The value of the email-address domain matching that of the signing  
domain depends upon the usage patterns.  If it becomes common for  
large providers to sign any and all email-addresses, and for bad- 
actors to sign their own messages, the value obtained when these  
domains match would be hard to quantify.  This value would not be a  
function of the affirmation record however.

> domain owner's reputation may suffer.

The email-address domain owner's reputation may unfairly suffer.   
This seems to have missed the problem.

> servers, use of e-invites, and other similar services.

This should be stated as _common_ practices in the impact statement.

> If unsigned mail from domains with open policies is treated any  
> better on the basis that the policy exists, then bad actors will  
> search for open policies in order to select the value for a  
> falsified From header.

Perhaps signed or unsigned email from email-address domains with open  
affirmations.  The open affirmation indicates what signatures are  
acceptable.  SSP looks at the email-address and then decides if the  
signature is acceptable as a means to affirm the use of the email- 
address by the signer.

> bad actors can select messages so as to maximise this cost in an  
> attempt at DoS.

This misses much of the concern.  The result of using more than  
normal labels is independent of the desire to create a DoS.  In fact  
most bad actors would want their email accepted, but employ a common  
strategy to avoid being easily identified.  The DoS concern should be  
focused upon the ability to extend current equipment to handle  
increased recipient burdens.  DKIM requires the entire message be  
accepted before the signature can be checked.  Checking will require  
the lookup of a public key that hopefully will be cached.  This  
caching may not be practical when per-user keys are used.  SSP  
however adds searches which comprise a sequence of rather expensive  
lookups, as most will return no-record not likely be cached.  Of  
course the per-user aspect of caching pertains to the affirmation  
records as well.  This overhead could be exasperated by demanding all  
 From email-addresses should be checked.

> Policy statements inherently expose information about the domain to  
> which the policy is intended to apply. Bad actors can use this  
> information to select values for inclusion in messages."

The exposure of email-addresses is impacted by the use of 'g=' within  
the key, the 'i=' within the signature, and the 'o=^' in the SSP  
record.  There is active and illicit trading of email-addresses which  
are used for the targets of abusive messages.  It seems rather ironic  
that an effort to abate abuse adds new ways to expose more targets  
for abuse.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Jan 2006 13:59:34 -0800

On Jan 12, 2006, at 11:56 AM, Michael Thomas wrote:

> Eliot Lear wrote:
>
>> Mike,
>>
>> I think it depends on the prevalence of DKIM and the parameters of  
>> the reputation service, which is out of scope and cannot be  
>> standardized.
>
> I'm not suggesting it's in scope for anything here, just that as a  
> _threat_ it's akin to any other kind of threat of people doing  
> something Really Stupid(tm).

While this misuse of identifiers would be rather stupid, email  
unfortunately is replete with Really Stupid(tm) tools.  : (

> In this particular case, it would be the threat of somebody in the  
> business that really ought not be if they can't understand why this  
> the wrong behavior.

This concern was raised as there are motivators for doing the Really  
Stupid(tm) things.  When this creates added revenue and redirects  
complaints to other hapless entities, then Really Stupid(tm) may look  
Really Clever(tm).

> If this belongs anywhere, it's in a BCP.

This was being raised in the threat review for the consideration of  
the use of "open-ended" affirmations used by SSP.  Only allowing the  
publishing of "closed" affirmations avoids this risk.  SSP should  
also  be able to indicate that the record does not apply to sub- 
domains for the same reasons.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 12 Jan 2006 16:49:18 -0800

> a yes/no answer about some requested action.

I agree with Stephen; my disagreements over the use of the term
"authorization" for this are:

Let's compare DKIM without SSP with DKIM+SSP.  DKIM-base makes a
positive statement about messages that are signed.  Not that they're
"good" messages, but that the signing domain actually signed them.  If
the signature address matches some other header in the message, it's
claiming that it had that role -- sender, resender or "from" (presumably
the originator of the message).

SSP adds the ability to provide some advice on what to do about unsigned
messages.  It doesn't authorize anything -- depending on the policy, it
may determine that certain messages are "suspicious".  It never makes a
positive assertion.  A "signs some" policy is the same as not having SSP
at all; the other policies are more restrictive.

The threats here go something like this:

1. Attacker finds a domain that publishes a "signs some" policy (or
doesn't publish a policy at all, since this is the default, currently at
least).  Attacker spoofs these addresses, since it isn't possible for
the recipient to know whether they should have been signed.  This attack
exists whether or not SSP exists.

2. Attacker finds a domain that publishes a "-" policy (allows
signatures from other domains).  Attacker registers a disposable domain
and signs messages "from" the found domain using the disposable domain. 
Attacker may even add headers pretending that the disposable domain is a
mailing list or similar role.  The messages will appear to be legitimate
to the verifier, unless the verifier uses a reputation system (either
local or shared) to determine that the signing domain does this sort of
thing.

3. Attacker registers a bunch of domains to do attack #2.  This is more
of an attack on the reputation system than on DKIM itself.

So, to summarize, SSP only makes negative assertions: it calls certain
messages "suspicious".  Calling it an authorization system distorts its
role.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Jan 2006 02:24:01 -0800

> the originator of the message).

The signature itself proclaims the role of being accountable for the
message.  A signing-domain matching the domain of some email-address
does not mean the signing-domain has verified permissions for the email-
address.  In addition, the 'i=' parameter does not need to exist or
match any email-address.  When the 'i=' parameter does match some
address, reliance upon this parameter must be conditioned upon whether
the key is delegated, and whether the header is included within the
signature.

>   It doesn't authorize anything -- depending on the policy, it

This is really a matter of semantics.  The glass half full or empty, or
in this case, affirmed acceptable (authorized) or not.

When the signing-domain matches the email-address domain, the SSP record
plays no role.  The SSP record may affirm that the message is still
acceptable when the email-address domain owner approves the lack of
signatures or the signatures of foreign domains.

> exists whether or not SSP exists.

A default for when the record does not exist still does not change the
affirmation that a lack of signatures or foreign signatures are
acceptable.  Unfortunately, because this record may also remove the
affirmation, there is some risk to email-address domain owner of being
inappropriately held accountable, as affirmation may permit possible
abuse by third-parties.  

> local or shared) to determine that the signing domain does this sort of

It is rather meaningless to offer such policy distinction.  A bad actor
can sign messages.  If the message goes through a mediator, the
signature could be damaged and thus considered to not exist.  This
policy makes little sense.

> messages "suspicious".  Calling it an authorization system distorts its

DKIM can not instantly proclaim all messages must be signed by a
matching domain.  Of course this mechanism could be viewed as _only_
offering "must be signed by a matching domain" proclamation.  If that
were true, there would be much less concern about the possible misuse of
this record.  However, this record can also proclaim and affirm that the
lack of a signature or a foreign signature is completely and absolutely
acceptable!

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jan 2006 12:17:22 +0000

Doug,

I've read your restatement of this but I'd still summarise it
in just the same way (again talking about policy rather than
affirmations). Since there's no point in doing that again, I'm
happy just see where the consensus ends up,

Stephen.

Douglas Otis wrote:
>> I don't think the term authorization is being properly applied there. 
>> To me at least authorization is what's happening when a policy 
>> enforcement point uses a policy decision point to get a yes/no answer 
>> about some requested action.
> 
> perhaps more accurately reflects the actual mechanism.  I have looked at 
> your restatements, but I feel much of the concern is being missed.  I 
> have attempted to remove some of the offensive terminology and then 
> emphasize what seems to have been overlooked.
> 
>> So, if I collect together those restatements then my synopsis of your 
>> suggested text would be:
>>
>> policies define the set of conformant messages and other messages do 
>> not conform to the policy.
> 
> Open policies (open affirmations) affirm the use of the email-address by 
> indicating what signatures or lack of signatures are acceptable.  In the 
> case of an open affirmation, the use of any email-address is equally 
> affirmed.  The reference identifier is derived from the email-address 
> which is affirmed when the signature is within the set of concurrent 
> identifiers determined by the SSP record.  On the other hand, a closed 
> policy only affirms with specific signatures.  Assuming there is value 
> associated with the email-address domain matching the signing-domain, 
> this value would be independent of the affirmation derived from the 
> email-address.
> 
> domain depends upon the usage patterns.  If it becomes common for large 
> providers to sign any and all email-addresses, and for bad-actors to 
> sign their own messages, the value obtained when these domains match 
> would be hard to quantify.  This value would not be a function of the 
> affirmation record however.
> 
> 
>> If a domain owner publishes an open policy, and if some "bad" unsigned 
>> messages apparently emanate from that domain then the domain owner's 
>> reputation may suffer.
> 
> The email-address domain owner's reputation may unfairly suffer.  This 
> seems to have missed the problem.
> 
> 
>> Closed policies can disrupt practices such as posting to list servers, 
>> use of e-invites, and other similar services.
> 
>> If unsigned mail from domains with open policies is treated any better 
>> on the basis that the policy exists, then bad actors will search for 
>> open policies in order to select the value for a falsified From header.
> 
> signature is acceptable as a means to affirm the use of the 
> email-address by the signer.
> 
> 
>> Searching for a policy statement may have a significant cost and bad 
>> actors can select messages so as to maximise this cost in an attempt 
>> at DoS.
> 
> This misses much of the concern.  The result of using more than normal 
> labels is independent of the desire to create a DoS.  In fact most bad 
> actors would want their email accepted, but employ a common strategy to 
> avoid being easily identified.  The DoS concern should be focused upon 
> the ability to extend current equipment to handle increased recipient 
> burdens.  DKIM requires the entire message be accepted before the 
> signature can be checked.  Checking will require the lookup of a public 
> key that hopefully will be cached.  This caching may not be practical 
> when per-user keys are used.  SSP however adds searches which comprise a 
> sequence of rather expensive lookups, as most will return no-record not 
> likely be cached.  Of course the per-user aspect of caching pertains to 
> the affirmation records as well.  This overhead could be exasperated by 
> demanding all From email-addresses should be checked.
> 
> 
> that an effort to abate abuse adds new ways to expose more targets for 
> abuse.
> 
> -Doug
> 
> 
> 
>

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 13 Jan 2006 06:55:52 -0600

> Calling it an authorization system distorts
 > its role.

That is correct and I like Stephen's summarized version of Doug's 
concerns too.

-- 
Arvel

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Jan 2006 13:44:27 -0800

Stephen,

I will concede the term "policy" generally describes the SSP record.   
The term policy does not offer any connotation of this record  
offering an affirmation that no signature or a foreign signature is  
okay, or instead a denial that no signature or a foreign signature is  
okay.  The authorization or affirmation term used in the summary was  
specifically aimed at creating a specific connotation to assist in  
conveying the concern.  Affirmation is the mode carrying risk due to  
misuse.  There have been Really Stupid(tm) misapplications of this  
type of "open" policy which have had the effect of unfairly holding  
the email-address domain owner accountable.

There are several factors which invite this type of misuse where any  
published "open" policy (which allows abuse) could be held against  
the email-address domain owner.  SSP provides a clear indication for  
one such inviting factor, as the email-address domain owner receives  
complaints.  The only means a concerned email-address domain owner  
prevents abuse is by publishing a "closed" policy.  As it so happens,  
a "closed" policy also means the signer could also be an appropriate  
recipient for complaints.  Any "open" policy exposes the email- 
address domain owner to unjustified complaint traffic.  However,  
"closed" policies also disrupt common email practices, and therefore  
are not suitable for general use.

A large domain has an advantage that a smaller domain does not.  A  
large domain is less likely held accountable and may even be commonly  
white-listed to override negative reputations, even when a fair  
amount of abuse is emitted by the large domain.  This typical  
consideration allows large domains far greater latitude with respect  
to "open" policies, than a smaller domain would ever enjoy.  In  
general, "open" policies impose an unfair competitive disadvantage  
for smaller domains.

SSP should ensure it is impossible to publish "open" policies to  
avoid this potential problem.  "Closed" policies still permit  
rejection of unsigned messages for those domains willing to forego  
services of any mediator or third-party provider.  When only a few  
domains publish a policy, the SSP overhead increases.   This overhead  
is also confounded by the lack of a mechanism to indicate that a  
policy does not apply to any sub-domain.  This problem in general  
also runs afoul of a desire to not force the publication of "open"  
policies creating a paradox.

There is a practical alternative to the SSP policy approach described  
in the dkim-options that would entail far far less overhead and would  
not impose the need for "open" policies.

> do not conform to the policy.

Policy is not checked when the email/signing domains match.   Policy  
is therefore silent when email/signing domains match.  When email/ 
signing domains do not match, SSP indicates whether unsigned or  
foreign signed messages are acceptable.   With respect to open  
policies, _all_ such messages are conformant and acceptable.

> domain owner's reputation may suffer.

Should be:

If an _email-address_ domain owner publishes...
... then the _email-address_ domain owner's reputation may suffer.

> servers, use of e-invites, and other similar services.

Should be:

Closed policies can disrupt _common_ practices...

> search for open policies in order to select the value for a  

Should be:

If _third-party_ signatures or _unsigned_ messages from _email- 
address_ domains with open...

> bad actors can select messages so as to maximise this cost in an  

Should be:

...and common strategies used by bad actor's to obfuscate the domain  
level used for direct registration may have the effect of increasing  
the average number levels that need searched.

> information to select values for inclusion in messages."

Should be:

Bad actors can use this information to increase the number of targets  
for abuse.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jan 2006 23:23:09 +0000

Hi Doug,

> I will concede the term "policy" generally describes the SSP record.  

Good. I think its easier if we use the same terms.

> [...]  Any "open" policy exposes the email-address
> domain owner to unjustified complaint traffic.

No more than could happen today. I don't see any reason why complaints
will rise that couldn't happen right now.

 > However, "closed"
> policies also disrupt common email practices, and therefore are not 
> suitable for general use.

Probably not. But as I understand it, those are designed for special
(and not general) cases.

> A large domain has an advantage that a smaller domain does not.[...]

I don't see how we can design a protocol to level that playing
field.

> ... This problem in general also runs afoul of a desire to 
> not force the publication of "open" policies creating a paradox.

I don't see any paradox unless you want one domain with both
an open and a closed policy.

> There is a practical alternative to the SSP policy approach described in 
> the dkim-options that would entail far far less overhead and would not 
> impose the need for "open" policies.

I'll take a look.

> Policy is not checked when the email/signing domains match.   Policy is 
> therefore silent when email/signing domains match.  When email/signing 
> domains do not match, SSP indicates whether unsigned or foreign signed 
> messages are acceptable.   With respect to open policies, _all_ such 
> messages are conformant and acceptable.

Nope. You're confusing the sender's policy statement with what
the verifier considers acceptable, which is out of scope.

I guess Jim can handle your other wordsmithing changes which
seem fine,

Cheers,
Stephen.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 13 Jan 2006 17:34:56 -0800

> DKIM signature, that offers the benefits.
I'm not enthusiastic about the idea of reorganizing the document to
separate out all the SSP stuff.  But if there are places where the
benefit derives from SSP (especially when it comes from very restrictive
signing policies which are likely not to be in wide use), I think it's
reasonable to mention that.
> "permitting a signing domain to claim responsibility for the use of a
This wasn't intended to refer to SSP at all. In order to refer to SSP,
it would have to be the converse "permitting a sending domain to deny
responsibility for unsigned messages".
> externally-originated messages [and attempts to spoof addresses in the
> local domain.]"
Within the claimed originator's AU, publication of SSP isn't needed --
the domain knows what it does and doesn't need to incur the risk of
having a restrictive SSP inhibit delivery of its messages.
> controlled by bad actors..."
I'll mention that SSP plays a role there.
> 4.2.4.  Use of Multiple From Addresses
All of the 4.2.x attacks are already under section 4.2, "Attacks Against
Message Signing Policy".  I don't think any more needs to be said.
[regarding Origin Address]
>> message, they decide "who it's from", as in "Oh, this is from Doug." 
>> I believe that with most MUAs this is the From address (or the
>> display name in the From address).   I have covered display name
>> abuse in a separate section.  There is no assertion of authorship
>> from DKIM, although I used the term "alleged author" to try to convey
>> the "who it's from" concept.  The address corresponding to "who it's
>> from" is what I want to call the Origin Address.
>
> which then validates the accountable domain.  The "g="
> (signer-address) parameter within the key does not impose any
> limitations upon what email-addresses may be found within headers. 
> This parameter simply provides additional information for review by
> the recipient, although how that information is used or even seen is
It does impose limitations on what may be considered an Originating
Address signature.  If g= for the key isn't a wildcard, it must match
the local part of i= of the signature [dkim-base section 6.3 step 5],
and i= must match the From address to be considered an OA signature.  So
while it may not limit what email addresses may be found in the header
fields, it does have an effect on the interpretation of the signature.
> | with an email-address or a persistent O-ID.
Opaque IDs solve a different problem.  In order to do its job, g= and
the local part of i=, if any, must not be opaque.  Which is unfortunate,
because you might want to publish an email address in the key record.
> identify an entity or entities using an associated account.
I have been trying to sort out what DKIM Options says, and just haven't
been able to yet.  But what do you do with unsigned messages from a
domain you haven't received anything from before?  I'm also concerned
that an attacker could use the mechanism described there (if I
understand it right) to assert that they're a mediator for the domain. 
If anyone can claim to be a mediator, is the claim meaningful?

> Within SSP record: 'o=!'  All mail from the entity is signed;
> Third-Party signatures SHOULD NOT be accepted.
>
> What I suspect you are attempting to define is whether the
> signing-domain has verified the permissions for the use of the
> email-address.  This assurance however is not a property of the SSP
I'm not sure to what 'permissions' you refer.  The intent of o=! is that
the domain wants to emphasize security over deliverability, and
therefore would rather that a message signed by a third party (e.g.,
mailing list) be considered unsigned than that the third-party signature
be considered valid.
> when they are misused as an accountable identifier.
You have a valid point here.  I would probably state it differently (as
I usually do): When policies permit third-party signing, an attacker may
pose as a third-party signer.  I still consider the misuse of addresses
other than the signing address to establish accountability to be an
issue with reputation systems, and not DKIM/SSP itself.
> whether assertions apply to sub-domains or not.  For example, if a TLD
> published a policy 'o=.' which could be valid, all sub-domains must
> then publish a policy to be able to send email.  If the SSP used its
> own RR, then the TLD may publish this policy to ensure the search is
> terminated before impacting their servers.  If the TLD published an
> "open-ended" policy, this may become the spoofed address of choice,
> which would then destroy the TLD's ability to also send mail.
>
>
> The account used to access the MSA may not constrain the email-address
> being used within the message, and may not associate a unique
> holder's privacy than would a persistent O-ID as defined in the
> DKIM-Options draft for this purpose.
I don't see any reason why the account used to access the MSA needs to
be in the signature at all.  If they need to establish who authenticated
to submit the message, there are lots of other ways to do that, such as
to look up the message-ID in log files.
>> abuse.  It might be the submitter's username, or it might be an
>> username, for much the same reason as the opaque identifiers you have
>> been advocating are opaque.
>
> other mechanisms related to account revocation.  In addition, the 'i='
> parameter could not function for delegated keys but would need to
> depend upon the 'g=' parameter instead.
If the key being used is valid for the entire domain, the local part of
i= isn't usually needed.  One time when it might be is when the
originator and a mailing list exist within the same domain.  It may be
desirable to distinguish between the originator's signature and the
list's in such cases.  But i= wouldn't expose any new addresses that
aren't already in one of the header fields.
>> many legacy MUAs, since they will need to verify a signature.  I
>> would like to see substantial consensus that the additional security
>> of running signatures all the way to the MUA is worth it before we
>> change this.  Remember that the verifier can be the last MTA/MDA in
>> the chain; the opportunities for spoofing a verification header are
>> fairly small at that point.
>
> the MDA.  Whether the MUA also checks the MDA signature (signature for
> the MDA) would be immaterial.  The significant difference however is
> this prevents intra-domain attacks and precludes the recipient
In situations where there is a risk of spoofing the results header, why
not just do the verification (and apply the results header) at the MDA? 
The MUA could do whatever it wants, including use TLS to retrieve
messages, to control spoofing on that last hop.
>>
>> My wording doesn't depend on SSP; note the text, "limiting the scope
>> of origin addresses for which a valid signature can be obtained". 
>> This is true with or without SSP.
>
No, but whether the signature is valid or not is constrained by the
email address.  Spoofed messages won't be able to get the positive
assertion associated with a valid signature.
>>> highly constraining authorization scheme may attempt to utilize the
>>> base DKIM signature, there are other mechanisms that can be more
>>> generally applied to increase protections obtained by DKIM without
>>> curtailing most of the freedoms users currently enjoy.
>>
>> I, too, think that a reputation system sould hold the signing-domain,
>> and not some other domain, accountable for messages it signs.  But
>> we're not designing the reputation system here, so let's let it drop.
>
> this point, the suggestion was to move these assertions to the section
> related to the SSP mechanism.  Perhaps there is another mechanism
> within DKIM I have been overlooking.
The 3.x sections discuss attacks that exist absent DKIM or a similar
technology.  But when I add the text I mentioned about discussing DKIM's
effectiveness, I'll mention that SSP has a role too.
> rather easily spoofed to look real when returned to the supposed
I generally agree with this.  Let me try putting some text together in
the next revision and revisit this if it doesn't capture the idea.
>> is the right thing to do, just pointing out that this is
>> reputation-system dependent.
>
> value.  Much of the abuse originates from these large domains that are
> extremely prone to this exploit.
I said "it could" not "it would".  A lot of the subtlety in running a
reputation system (as I'm sure you're very aware!) is preventing people
from "gaming the system".  This is an example of such gaming; I don't
pretend to know the answer (although I have a few, probably flawed, ideas).

> DKIM without reputation of course offers value in other ways.  Perhaps
> that value is enough.
>
>
>> Outlook is the MUA I'm most familiar with that often doesn't display
>> the email address.  I'm not an Outlook user myself, so I don't know
>> what the circumstances are that it displays the address and when it
>> doesn't; I'll try to chat with some of the Outlookers (?) around here
>> about what can be done.
>
Yes, a dependency on explicit investigation by the recipient is bad.
>> you're advocating that re-signers remove prior signatures.  Removing
>> the prior signature in order to avoid feeding a replay attack
>> (presumably a Signed Message Replay) is an interesting thought
>> although I wonder if there aren't better sources of signed messages
>> available.
>
There is definitely work still to be done on best practices for re-signing.
> brief and intelligible.  ;-)
Thanks, Doug.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Jan 2006 17:35:37 -0800

On Jan 13, 2006, at 3:23 PM, Stephen Farrell wrote:

>
>> [...]  Any "open" policy exposes the email-address domain owner to  
>> unjustified complaint traffic.
>
> No more than could happen today. I don't see any reason why  
> complaints will rise that couldn't happen right now.

The mechanism directs complaints to the email-address domain owner,  
rather than the signing-domain.  Unfortunately, a published "open"  
policy will attract more abuse.

>> However, "closed" policies also disrupt common email practices,  
>> and therefore are not suitable for general use.
>
> Probably not. But as I understand it, those are designed for  
> special (and not general) cases.

I don't think there is any question that a closed policy will prevent  
the use of most list servers, for example.  Posting to a list is a  
common use.

> I don't see how we can design a protocol to level that playing field.

The concern is not about leveling the playing field, but rather not  
giving the large domain a powerful club with which to beat the heck  
out of smaller domains.  This requires avoiding any reason or excuse  
for an open policy to be published.

>> ... This problem in general also runs afoul of a desire to not  
>> force the publication of "open" policies creating a paradox.
>
> I don't see any paradox unless you want one domain with both an  
> open and a closed policy.

For example, a second level domain "co.jp"  publishes the 'o=.'  
policy.  This would mean all sub-domains must then also publish a  
policy or forgo expectations of having their email accepted.  The  
second level domain may have been motivated into publishing a policy  
in order to squelch a high level of traffic, as no-records are not  
cached very long and each and every message instigates a new lookup.   
A mechanism to indicate the SSP record does not apply to sub-domains  
would ensure the search could end, but would then not be applied to  
the sub-domains.  A separate mechanism not part of the 'o=' could be  
used, such as 'i=y' or 'i=n' for sub-domains inherit policy (yes/ 
[no]).  The paradox occurs when co.jp wishes to use email normally.   
Their record could be "i=n" (nothing more).

>> Policy is not checked when the email/signing domains match.    
>> Policy is therefore silent when email/signing domains match.  When  
>> email/signing domains do not match, SSP indicates whether unsigned  
>> or foreign signed messages are acceptable.   With respect to open  
> Nope. You're confusing the sender's policy statement with what the  
> verifier considers acceptable, which is out of scope.

I understand your position.  A policy that says "signs some" also  
says "some legitimate messages are not signed or are signed by  
others."  Language is important when attempting to convey concepts.   
When the signing/email domains don't match and "some legitimate  
messages are not signed or are signed by others" policy is  
discovered, how does this relate to what what messages are  
conformant?  Clearly not being signed could be an indication of  
conforming to the statement.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 14 Jan 2006 05:40:23 +0100

Douglas Otis wrote:

>>> [...]  Any "open" policy exposes the email-address domain
>>> owner to unjustified complaint traffic.

> The mechanism directs complaints to the email-address domain
> owner, rather than the signing-domain.  Unfortunately, a
> published "open" policy will attract more abuse.

IBTD strongly.  First thing, it's nice to have this new term
"open-ended".  In the context of SPF it's "any policy with a
_potential_ result NEUTRAL".  In the context of SSP it's "any
policy _allowing_ unsigned mails".

SPF has it clear that NEUTRAL results MUST (2119) be treated
like NONE.  Of course receivers are free to do whatever they
like not limited to "treat NEUTRAL like FAIL if it's for @AOL"

Utter dubious idea, it violates a MUST.  I'm too lazy to check
it now, but it would be trivial to add a similar MUST to SSP.

Further, just because a policy is "open-ended" doesn't mean
that all results are inconclusive, a PASS is still a PASS, a
FAIL is still a FAIL, and a valid signature is still a valid
signature.

If there's no signature, or an invalid signature, then it just
makes no sense to send complaints to the domain owner.  It's
also pointless to bother the "signing-domain" without a valid
signature.  Receivers could try to figure out where on their
side something destroyed the signature, that's their problem.

Like receivers should make sure where they test SPF FAIL, if
they don't do it ar their border MTA it generally won't work.

That leaves us with one interesting case, "open-ended" signing
policy without related signature, but a PASS for a third party
signature.  In that case complaints should be of course sent
to the signing-domain, not to the signing policy domain owner
(or to the From address, maybe replacing the LHS by abuse@).

I don't see any specific threat here related to "open-ended"
or "closed" policies.  No signature is like NEUTRAL, receivers
can't do much with it (except from screwing-up), it's a polite
form of saying "thanks for supporting DKIM or SPF resp., but
for this mail you wasted your time".

Finally, why should bad actors intentionally try to abuse
addresses with "open-ended" policies ?  IMO that's a stupid
plan, receivers used to get "SPF PASS" or "DKIM valid" or what
else would of course look twice if they suddenly get only a
NEUTRAL or no signature or a broken signature.

> I don't think there is any question that a closed policy will
> prevent the use of most list servers, for example.  Posting
> to a list is a common use.

Nothing forces domain owners to publish closed policies, we've
already discussed this.  The WG charter says that the WG will
consider mailing lists, and that's a topic for the SSP draft.

And also for the base draft wrt invalidated signatures.  But
IMO not for the threats draft.  Unrelated, there are now some
IETF pages for the WG:  <http://tools.ietf.org/wg/dkim>  Bye

---

From: Douglas Otis <[email-masked]>
Date: Sat, 14 Jan 2006 14:56:29 -0800

> responsibility for unsigned messages".

The DKIM signature clearly indicates which domain should be held
accountable for the message, but this statement is about an email-
address.  It may well become common for providers to sign messages for
any email-addresses contained within the message.  If the provider
receives complaints, they disable the offensive account.  In this case,
the provider would not wish to claim responsibility for any specific
email-address, perhaps even when the domains match.

> having a restrictive SSP inhibit delivery of its messages.

You mean the policy could be applied internally within the domain?  This
limits this intra-domain spoofing detection ability to those within this
domain.  Perhaps you could make a statement for internal policies and
limited protections versus another for SSP related policies.   

> and i= must match the From address to be considered an OA signature.

No; the i= does not need to match any header. : (

> So it may not limit what email addresses may be found in the header

There needs to be a better method to communicate what assurances the
sender is making with respect to email-addresses as well as where the
email-addresses may be found.  I still do not see how DKIM currently
accomplishes this goal.

> because you might want to publish an email address in the key record.

Once you consider what assurance can be safely made to the recipient, an
O-ID or an explicit binding (not currently in the DKIM draft) would need
to be made.  With this added information, the recipient could be
notified that the source of the message has been recognized.  It would
be extremely dangerous to signal that some email-address matches some
elements within a signature, even assuming an MUA gets modified to
support such a notification scheme.

> domain you haven't received anything from before?

Checking email-addresses will not be effective at eradicating phishing
attempts, quickly after DKIM has been established.  When the email-
address domain uses a closed policy _and_ the recipient suffers the
overhead finding this occasional closed policy, then yes the message
could be blocked outright.  As I said, that works for only a short
while.    

Secondly, when the spoof is related to ongoing commerce, there will be
prior messages.  To answer the question however, if this was a spoof not
previously seen, there should still be filtering that checks for
deceptive links and comparing these links against the DKIM signature as
a means to lower false positives.

When the 'w=b' is captured at the MTA, then spoofs of the email-address
could be blocked at the MTA.  Perhaps there could be bindings that
prevent the use of a mediator as well, and that too could be captured.
For the long term, filtering at the MTA would be depreciated once
spoofing becomes impractical at the MUA.

> I'm also concerned an attacker could use the mechanism described there
> (if I it right) to assert that they're a mediator for the domain. 

The notification of assurances given the recipient should be based upon
recognition and definitely not the result of some conformance check.
Bad actors would have no difficulty in achieving such notifications.

The reason for including a signing role in the binding is to isolate
source identifiers.  Seeing [email-masked] come from harry.example.com
versus sb7.some-list.com is clarified by the claimed signing role.
Rather than issuing a warning of a possible spoof, a message could
indicate nothing, or that there appears to be another mediator source
for a registered correspondent.  Only registered sources would be
signaled (highlighted) to the recipient, making list-servers innocuous
simply by indicating the role of the signer.

> mailing list) be considered unsigned than that the third-party signature

It is not clear how this information can be safely used.  Without
spending time discussing semantics, focus upon safety.  There are no
assurances clearly made by DKIM regarding what the sender is attempting
to assure.  Specifically, does the email-address identify a unique
source, or does just the email-address domain, or something else.  There
should be a method to assure the source of the message, independent of
the email-address, especially when email-addresses from different
domains are permitted by the sender.  This is also important with
respect to privacy concerns.

> issue with reputation systems, and not DKIM/SSP itself.

How reputation is applied is beyond the sender's control, but what
policy is published _is_ within their control.  Caution should preclude
the publishing of open-ended policies as they add no value, only risk.

> to look up the message-ID in log files.

Establish a convention for an optional identifier to assure a unique
message source.  This option enables the highlighting of recognized
correspondents without exposing additional email-addresses.

> i= isn't usually needed.

When a provider accepts all email-addresses and signs the messages, the
i= can not be used.  A key does not indicate what verified resource at
the sender was used, and where the message-id was created, etc.

> One time when it might be is when the originator and a mailing list
> exist within the same domain.  It may be desirable to distinguish
> between the originator's signature and the list's in such cases.  But
> i= wouldn't expose any new addresses that aren't already in one of the
> header fields.

Going back to the premise DKIM could be used to sign messages carrying
any email-address, in this case the account used to gain access would be
meaningful.  Offering an email-address that is valid for the the account
within the provider's domain increases the exposure of private
information.  By offering an O-ID and registering this identifier, the
recipient could detect the spoofing of foreign email-addresses.  (email-
addresses not within the signing-domain). 

> messages, to control spoofing on that last hop.

For the same reasons DKIM is being used over TLS, the use of the MDA
signature would have similar value.  Where messages are received and
verified at the edge of an AdmD to mitigate DSNs, obfuscating the
initial signatures at this point also prevents replay abuse.  The MDA
signature retains the security that DKIM offers.  Any access within the
AdmD would make a results-header a prime candidate for spoofing.

> assertion associated with a valid signature.

Spoofed messages can still have a valid signature.  There is no definite
association between the email-address and the signature.   

> effectiveness, I'll mention that SSP has a role too.

I'll leave structuring the document to you.  I think there would be
greater clarity by moving the SSP related benefits and threats to an SSP
section.

> pretend to know the answer (although I have a few, probably flawed, ideas).

There could be some benefit considering how bad actors can be identified
when DKIM signatures are being used.  A reasonable method for good
actors to quickly squelch replay abuse, or a means to mitigate the
overhead defending against abusive replay attacks would help retain the
distinctions between good and bad actors.  The underlying hope behind
the dkim-options draft was with these mechanisms in place, the resulting
level of abuse would not impose large administrative burdens, although
some automation would be needed.

When a good actor receives a report that their signature is being abused
by replay activity, they should be able to respond.

Not being able to answer what this response entails means that DKIM will
have great difficulty serving as a basis for assessing sources and is
open to gaming.  However, DKIM will still offer value identifying
sources.  One must then hope this is fairly used.

Sorry this is so long, but I think there was some progress made. ;)

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 14 Jan 2006 19:33:42 +0000

Doug,

Since there's no point in just repeating stuff, I won't. But you've
not convinced me about the additional abuse from open policies nor
that closed policies are problematic. I haven't heard anyone else
yelling eureka! either.

> giving the large domain a powerful club with which to beat the heck out 
> of smaller domains.  This requires avoiding any reason or excuse for an 
> open policy to be published.

I don't get your logic there. What is the relationship between domain
size and SSP that gives rise to a (technical) threat? I don't believe
there is one.

[...paradox lost...]
> For example, a second level domain "co.jp"  publishes the 'o=.' policy.  
 > This would mean all sub-domains must then also publish a policy or
 > forgo expectations of having their email accepted.

"o=." states that nothing in co.jp sends email (I hate those terse
labels being used in discussion, whatever about in the DNS.) I assume
that some enterprises in co.jp would complain mightily,  i.e. that's
not going to happen.

 > A mechanism to indicate the
> SSP record does not apply to sub-domains would ensure the search could 
> end, but would then not be applied to the sub-domains.  A separate 
> mechanism not part of the 'o=' could be used, such as 'i=y' or 'i=n' for 
> sub-domains inherit policy (yes/[no]).  

Maybe. I could imagine some benefit were SSP to include allow inclusion
of something like a "depth" value which'd say that this policy applies
here and N more levels down. Sort of like the pathLenConstraint in
X.509. But thats for later in any case when we're doing SSP.

 > The paradox occurs when co.jp wishes to use email normally.

Nope. That's not a paradox at all.

 > messages are not signed or are signed by others" policy is discovered,
 > how does this relate to what what messages are conformant?

That's up to the verifier and not in scope of threats. We might want
to discuss a bit when its time to do SSP, but absent any demonstrated
threat, its definitely for later I believe.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 14 Jan 2006 11:26:42 -0800

> (or to the From address, maybe replacing the LHS by abuse@).

Absolutely.  Which is why it is wrong to include a reporting vector in
the email-address domain owner's policy statement.  The reporting vector
should be solely defined for the signing domain.

> for this mail you wasted your time".

The email-address domain owner _may_ be held culpable for "open-ended"
policies as these allow abuse.  Although such treatment would be unfair,
nevertheless being unfair, intentionally or not, would be beneficial to
larger domains.  Not defining the publishing any "open-ended" policies
within the SSP draft would prevent this concern, as would removing the
reporting vector.  DKIM should make it clear the signing-domain and
_not_ the email-address domain must be held accountable.

> NEUTRAL or no signature or a broken signature.

Consider the situation where the majority of email with a DKIM signature
is done by providers that place no restrictions upon the email-address.
Of those emails where the email-address has a policy record that affirms
third-party signatures are used, this will likely obtain a higher
ratings over email-addresses where nothing has been affirmed.  Just as
not publishing a reporting vector in the email-address policy prevents
Really Stupid(tm) behavior, not publishing "open-ended" policies
prevents the same Really Stupid(tm) behavior.

> consider mailing lists, and that's a topic for the SSP draft.

Publishing a closed policy is okay for those domains that do not mind
disrupting common practices.  At the same time, those domain owners
should also be aware this may only change the nature of abuse, such as
increasing the prevalence of display-name, look-alike, tld, and
hyphenated attacks. 

For those domains, such as access providers, that do not wish to disrupt
their customers use of email, the act of the provider signing email (a
good thing) may put their customers at risk when their customers are
coerced into publishing some type of open policy.  Not providing any
open-ended, or third-party signer listings mechanisms should curtail
coercive tactics or unfair reputations placed upon the email-address
domain owner.  This can be done while _still_ allowing closed polices.

> IETF pages for the WG:  <http://tools.ietf.org/wg/dkim>  Bye

Thank you for the link. : )

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sun, 15 Jan 2006 16:43:37 -0800

On Jan 14, 2006, at 11:33 AM, Stephen Farrell wrote:
>>
>> The concern is not about leveling the playing field, but rather  
>> not giving the large domain a powerful club with which to beat the  
>> heck out of smaller domains.  This requires avoiding any reason or  
>> excuse for an open policy to be published.
>
> I don't get your logic there. What is the relationship between  
> domain size and SSP that gives rise to a (technical) threat? I  
> don't believe there is one.

a) The severity of the threat of being held culpable for an open-end  
policy reduces as the domain size increases.

b) When publishing a policy increases the rating of a message,  
accountability will effectively move to the email-address domain,  
which is exacerbated as the signing-domain gets larger.

Identities exposed by DKIM beyond the signing-domain are email- 
addresses: the key's 'g=' and the signatures 'i=' parameters, or  
discovery of a published policy referenced from a header's email- 
address.   Common practices require an open-ended policy to avoid  
disruption.  Despite this, finding a policy for an email-address will  
also likely increase the rating of the message.  An increased rating  
could be done to encourage the publishing of policies which mitigate  
the policy search overhead.  In the case of a foreign email-address  
being signed, neither the 'g=' or the 'i=' parameters can be used as  
an identifier.  When the signing-domain represents tens of millions  
of users, and there is a targeted abuse by compromised systems with  
access (perhaps a result of the increased rating), acceptance due to  
a policy will then likely require the affected email-addresses be  
selectively blocked.  For very large domains, blocking at the  
signature would not be practical, as this would disrupt messages from  
tens of millions of users.

The threat document speculates on the risks created by bad-actors.   
It seems appropriate to consider possible DKIM related dynamics,  
especially when there is a history that supports this concern.  Many  
administrators consider an ideal system would _only_ hold the email- 
address domain owner accountable.  Unfortunately, fairness would then  
rapidly become a casualty.  DKIM can be engineered to avoid this  
unfairness.  To do so, an open-ended policy should be avoided.

>> policy or forgo expectations of having their email accepted.
>
> labels being used in discussion, whatever about in the DNS.) I  
> assume that some enterprises in co.jp would complain mightily,   
> i.e. that's not going to happen.

The SSP draft does not offer concise terminology, so the symbols are  
used instead.  The second level domain may feel justified when the  
traffic becomes onerous.  The paradox is that avoiding the use of  
open-ended policies to terminate the search has not been accommodated  
in the current design.  As you suggested, closed policies would be  
highly disruptive.  Fixing this problem only requires a minor change.

>> A mechanism to indicate the SSP record does not apply to sub- 
>> domains would ensure the search could end, but would then not be  
>> applied to the sub-domains.  A separate mechanism not part of the  
>> 'o=' could be used, such as 'i=y' or 'i=n' for sub-domains inherit  
>> policy (yes/[no]).
>
> Maybe. I could imagine some benefit were SSP to include allow  
> inclusion of something like a "depth" value which'd say that this  
> policy applies here and N more levels down. Sort of like the  
> pathLenConstraint in X.509. But thats for later in any case when  
> we're doing SSP.

This level complexity is not needed.  "From here down", or "just  
here" should be sufficient.

>> conformant?
> That's up to the verifier and not in scope of threats. We might  
> want to discuss a bit when its time to do SSP, but absent any  
> demonstrated threat, its definitely for later I believe.

Contemplating how DKIM may be implemented is beyond consideration?   
This is not suggesting that any particular method be used by the  
verifier.  This concern is based upon logical and possible scenarios  
and outcomes.  Excluding possible behaviors by verifiers ignores some  
potentially serious issues.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Sun, 15 Jan 2006 13:40:47 -0800

> the key is delegated, and whether the header is included within the
I'm not sure how one tells that the key is delegated, nor why that is
relevant to the verifier.
> signatures or the signatures of foreign domains.
I basically agree.  It's a fine point, but what the email-address domain
is actually doing is describing its practices, since it doesn't have any
standing to approve anything for the verifier.
> inappropriately held accountable, as affirmation may permit possible
As I mentioned above, I'm not sure how accurate it is to characterize
the SSP record as an "affirmation" -- it's a description of what an
email domain does.
> policy makes little sense.
This is a good topic for discussion when we are discussing SSP itself,
not the threats document.
> lack of a signature or a foreign signature is completely and absolutely
Again, this is more relevant to the design of SSP (or the wording of the
-ssp document) than to the threats document.  Hopefully my comments
above explain my position.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Sun, 15 Jan 2006 13:50:08 -0800

> email-address, perhaps even when the domains match.
It's not clear to me who you mean by the "provider" here.  But it's
entirely up to any signer which messages they want to sign.  Perhaps
they only sign messages that were submitted in an authenticated way. 
Perhaps they only sign messages that come from certain users that have
undergone certain vetting to establish who they really are.
> limited protections versus another for SSP related policies.   
I'm saying that SSP need not be the only source of information about the
domain that feeds into decisions about how given messages are handled.

[much omitted here]

> Sorry this is so long, but I think there was some progress made. ;)
I think we are making some progress, although we are getting somewhat
far afield from the threats document on much of this.  It's about time
for me to crank out a revision of the threats document, rather than to
respond on a point-by-point basis.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jan 2006 08:06:59 +0000

Doug,

> policy reduces as the domain size increases.

Ok. So this is purely subsidiary to your point about open policies
being unfair. I understand now. As I'm not convinced that that point
represents a valid threat I personally don't think that this one
warrants mention either.

>>> discovered, how does this relate to what what messages are conformant?
>>

(Feel free to be contemplative! I'd imagine that involves less typing:-)

If you have some precise, realistic scenario to propose that's ok. But
I for one won't answer inexact open questions such as the above since
I'm not interested in prolonging this thread - which would be the
inevitable consequence of attempting an answer. No thanks.

I think we're done on this in terms of being productive, so I suggest
we give people a chance to catch up, and Jim a chance to get another
revision out (as he's asked).

Stephen.

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 16 Jan 2006 10:48:48 -0500

> that closed policies are problematic. I haven't heard anyone else

That's because it takes a while to digest what Doug is trying to say. So
while I'm not saying 'eureka!', I'm also not saying 'nonsense!'. I suspect
that this may be true of others who are lurking.

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: www.e-dialog.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jan 2006 15:56:07 +0000

Hi Jeff,

> that this may be true of others who are lurking.

Fair enough. This thread has clarified Doug's position for me too.

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 16 Jan 2006 11:49:07 -0500

----- Original Message -----
From: "Jeff Macdonald" <[email-masked]>

> that this may be true of others who are lurking.

Well, my lurking only shows I see this as an exercise of repeated, over
and over and over again of "closed minded" "open-ended nonsense."
Atleast 3-4 different approaches has been tried to blunt SSP - all
failed. I can't wait in see the next approach.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Jan 2006 10:20:17 -0800

On Jan 15, 2006, at 1:40 PM, Jim Fenton wrote:

>> The signature itself proclaims the role of being accountable for  
>> the message.  A signing-domain matching the domain of some email- 
>> address does not mean the signing-domain has verified permissions  
>> for the email-address.  In addition, the 'i=' parameter does not  
>> need to exist or match any email-address.  When the 'i=' parameter  
>> does match some address, reliance upon this parameter must be  
>> conditioned upon whether the key is delegated, and whether the  
>> header is included within the signature.
>
> I'm not sure how one tells that the key is delegated, nor why that  
> is relevant to the verifier.

With DKIM and SSP, the verifier has few reliable elements of  
information beyond the verification of the signature.  When a key has  
been delegated, additional elements within the signature itself are  
therefore less reliable.  There is no clear indication within DKIM  
when this information is or is not reliable.  There is not even a  
strong statement the 'i=' element should be used.

>>> SSP adds the ability to provide some advice on what to do about  
>>> unsigned messages.  It doesn't authorize anything -- depending on  
>>> the policy, it may determine that certain messages are  
>>> "suspicious".  It never makes a positive assertion.  A "signs  
>>> some" policy is the same as not having SSP at all; the other  
>>> policies are more restrictive.
>>>
>>
>> This is really a matter of semantics.  The glass half full or  
>> empty, or in this case, affirmed acceptable (authorized) or not.
>>
>> When the signing-domain matches the email-address domain, the SSP  
>> record plays no role.  The SSP record may affirm that the message  
>> is still acceptable when the email-address domain owner approves  
>> the lack of signatures or the signatures of foreign domains.
>
> I basically agree.  It's a fine point, but what the email-address  
> domain is actually doing is describing its practices, since it  
> doesn't have any standing to approve anything for the verifier.

A domain does have the standing to proclaim messages using email- 
addresses within their domain will not always include their  
signature, an open-ended policy.  This proclamation could be called  
any number of things.  Even when restricted to semantics of actions  
rather than authorizations or affirmations for these types of  
messages, the same information is conveyed.  I agree _how_ this  
information gets used is well beyond the control of the sender.  As  
such, publishing closed policies offers _less_ risk of being block- 
listed than publishing open-ended policies.   Fortunately, DKIM  
should not require the use of open-ended policies.

There are no protective benefits obtained publishing open-ended  
policies.  The crux of the concern appears to be whether there is any  
risk of being held culpable for the abuse permitted when publishing  
an open-ended policy.  The basis for this concern only requires that  
verifiers increase the ratings of messages when a policy is obtained  
for an email-address.  This is not inconceivable, and is perhaps even  
likely, as there are major providers already making this type of  
assessment.  Not allowing the publishing of open-ended policies by  
design better ensures this type of coercion (holding the email- 
address domain owner culpable rather than the signing-domain) is  
avoided.

>> It is rather meaningless to offer such policy distinction.  A bad  
>> actor can sign messages.  If the message goes through a mediator,  
>> the signature could be damaged and thus considered to not exist.   
>> This policy makes little sense.
>
> This is a good topic for discussion when we are discussing SSP  
> itself, not the threats document.

This statement was directed specifically to the purported purpose of  
an open-ended policy, as compared to risks publishing open-ended  
policies.   Allowing the publishing of open-ended policies makes it  
far more difficult to ensure a major domain will not take advantage  
of this lowered threshold and increase the ratings for a message when  
any type of policy is found.  The risks related to this possible and  
perhaps even probable behavior should be apparent.

Just as the verifier's behavior can not be predicted, statements  
related to the protection of an email-address should be equally  
couched, but they are not.

-Doug