You keep mentioning it so let's see how it works...
Douglas Otis wrote:
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 have read it. I continue to believe its analagous to a
serialNumber with the MTA as a signer being analagous to a CA.
Requiring a signing domain to maintain such a revocation list
may be onerous. Say if I get a (bunch of) bogus accounts in order
to DoS this revocation scheme? Do you have any information about how
your approach scales in such a case? About other new DoSes it may
create? About how it might affect the DNS load or capacity for the
DNS server of a mail server from a domain under attack from inside?
(And thus publishing many revocations.) Simply asserting that there
are no problems in this respect isn't really credible.
There are more email messages in the world than x.509 certs (so
the differing validity periods may not be a saving grace), and
and I know that maintenance of CRLs is a problem for CAs. I really
can't see where you've found a magic bullet that makes your
idea that different. Having said that, the idea may be worth exploring,
but that's not really going to happen if its only viable as the
"one true answer" - there isn't one and presenting your idea that
way is a sure-fire way of just annoying people.
I don't see opaque-identifiers creating as much grief as mandating that
an email-address be coupled with the signing-domain.
Good. You do admit that there're two sides to this. Please continue
in that vein:-)
Yes, there are pros and cons to any approach to this. I'd really be
happy if we'd all stop pretending we've got the perfect solution
and that everyone who disagrees at all is totally wrong. It doesn't
help anyone. It certainly doesn't help DKIM.
> 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.
Perhaps yes. Perhaps as an option. Perhaps not.
Remains to be proven IMO.
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, the more words you write the less each is read. Its just a fact.
Please, please learn to be terse. Especially when saying something for
the n-th time.
You may have a point that binding to the From-domain isn't the best
idea. Others who think it is a good idea do also have a point.
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org