Douglas Otis wrote:
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.
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.
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."
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".
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.
3.1. Use of Arbitrary Identities
...
"DKIM is effective in mitigating against the use of addresses not
controlled by bad actors..."
I'll mention that SSP plays a role there.
4.2.3. Denial-of-Service Attack Against Signing Policy
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]
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.
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.
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.
'---
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.
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? 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?
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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).
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.
Yes, a dependency on explicit investigation by the recipient is bad.
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.
There is definitely work still to be done on best practices for re-signing.
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. ;-)
Thanks, Doug.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org