On Nov 1, 2005, at 10:15 AM, Stephen Farrell wrote:
Douglas Otis wrote:
On Oct 31, 2005, at 2:24 PM, Dave Crocker wrote:
I didn't see anything in the
spec about verifying that the arbitrary text matches the
purported From
address. Is this correct? Perhaps this could be addressed as a
possible threat in the analysis?
SSP deals with matching the From to the DKIM identity. Did you
have any
other matching in mind?
Although many wish to attribute an ability to directly relate the
From header with the DKIM signing-domain as a means to abate
abuse, this is a foolish quest.
You keep saying that. But there're clearly folks who disagree.
I suspect repetition won't change minds.
And while there may be cases where the current version is
problematic, there may also be cases where your alternative
is similarly problematic - e.g. your opaque identifier may
turn out to be the same as the X.509 serialNumber field,
which field has been involved in lots of grief in terms of
handing revocation - will such a field require the definition
of a CRL/OCSP/SCVP equivalent? (Is that a fair comparison?)
The expiry of DKIM signatures should be within a few days where
tracking revoked opaque-identifiers would be required. Unlike the X.
509 serial-number, this identifier could relate to accounts used by
the access server or derived in any number of ways proving convenient
for the provider, due to the short revocation period required.
Publishing the revocation has been described in:
http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-03.txt
I don't see opaque-identifiers creating as much grief as mandating
that an email-address be coupled with the signing-domain. Even
adding the Sender header will create an inordinate number of support
calls, where even still, the message may be rejected or deleted.
Evaluating acceptance of the message should be based upon the signing-
domain.
For now though, (i.e. prior to becoming a wg) we only
really need to recognise this as an issue (which I at any
rate, have) but we don't need to solve it, right?
The concept behind SSP is to refute messages not signed or that have
invalid signatures. Refuting unsigned-messages or invalid-signatures
is justification for coupling some email-address with the signing-
domain. However, SSP made the _most_ disruptive choice possible by
selecting the From header as being coupled to the signing-domain.
This will greatly slow the needed deployment of DKIM.
SSP refuting of unsigned-messages and invalid-signatures must
overcome an initial deployment period where many signatures will be
invalid and many messages will not be signed or may have had the
signature removed. This could occur when messages are modified to
indicate scanning results, a list-service modifying the message for
normalized presentation, or unexpected handling at some gateway, as
well as many other situations. Review the section on multiple
signatures in my threat review for other concerns.
When considering an opportunistic approach, the discovery of a valid
signature would allow the capturing of policies directly from the
message as well as noting that a signature can be expected to survive
a particular provider. Using this approach would lessen many of the
problems associated with deployment, and rule out the need for
extensive out-of-band processes that already expect many DNS
lookups. The number of these lookups should be expected to grow
substantially, should this approach be allowed.
The binding of the signature to a specific header email-address is
where DKIM/SSP creates an inordinate amount of damage. There are few
claims that support directly coupling the signing-domain to an email-
address where there is significant redeeming value. Permitting just
an indirect coupling will avoid much of problems that could be
created, and perhaps head off well justified opposition. I would not
what this scheme employed, as it would disrupt the way I use email
substantially. I suspect it would disrupt most of those involved
with the IETF as well.
Adding information directly within the message replaces the flawed
out-of-band scheme, where the information collected from the message
will have been provided greater security. If you trust the signing-
domain, then an opaque-identifier only offers greater assurances when
selectively bound to an email-address. This opaque-identifier offers
protection from intra-domain spoofing and protection from message
replay abuse. MUA and MTA developers should make accommodations for
multiple <opaque-identifiers>:<sigining-domain> identifiers to be
related to a particular email-address.
PS: I still think Dave's right in that dkim can't do anything
directly about the problem in the subject line other than maybe
exhort others to think about it as they implement products.
I think that binding the From header to the Signature does nothing
about the problem either. This is an unfounded attempt to shift the
burden onto the email-address domain owner, rather than the email
message transport system administrator. I would not expect less from
a strategy developed by providers. : )
If a message containing links to ebay.com is not signed by ebay.com,
where there were prior messages that had valid ebay.com signatures
claiming all messages are signed, then DKIM will play a significant
role at eradicating phishing attacks in the hands of message
filtering. This is not done by binding the From header address to
the signature however. This attempt at binding the signature to a
header causes more harm that good, and may be perhaps the greatest
reason DKIM may be met with distain.
The scope of DKIM should be limited to verifying an accountable
domain for the email message transport system. SSP is a highly
flawed and disruptive attempt at extending accountability onto the
email-address. Trust should be limited to the signing-domain when
deciding whether to accept a message. Allow an opaque-
identifier:signing-domain identification scheme alert the recipient
to any possible attempts at spoofing the author.
I want DKIM deployment to go smoothly. This is not possible with SSP
as defined.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org