|
Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]
2006-01-09 20:18:29
On Jan 9, 2006, at 2:07 PM, Jim Fenton wrote:
Douglas Otis wrote:
On Jan 5, 2006, at 10:08 PM, Jim Fenton wrote:
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.
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..."
4.2.3. Denial-of-Service Attack Against Signing Policy
4.2.4. Use of Multiple From Addresses
"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.
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
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.
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.
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.
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.
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.
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
"fenton(_at_)cisco(_dot_)com" 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?
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.
How is an email-address constrained by the signature? There is
_nothing_ within the base DKIM draft that does this.
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.
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.
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.
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.
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.
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.
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
_______________________________________________
ietf-dkim mailing list
http://dkim.org
|
|