On Fri, 2006-01-13 at 17:34 -0800, Jim Fenton wrote:
Douglas Otis wrote:
1. Introduction
...
"permitting a signing domain to claim responsibility for the use of a
given email address."
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".
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.
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.]"
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.
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.
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.
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.
No; the i= does not need to match any header. : (
So 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.
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.
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.
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.
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.
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?
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.
If anyone can claim to be a mediator, is the claim meaningful?
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 doug(_at_)example(_dot_)com 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.
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. : )
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.
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.
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.
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.
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.
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 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.
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.
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.
If the key being used is valid for the entire domain, the local part of
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).
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.
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.
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.
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.
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.
Spoofed messages can still have a valid signature. There is no definite
association between the email-address and the signature.
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.
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.
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.
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 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).
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
_______________________________________________
ietf-dkim mailing list
http://dkim.org