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

[Jim Fenton]

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

>