On Jun 17, 2009, at 8:08 AM, Dave CROCKER wrote:
So, here's a suggested merging of the two:
This currently leaves signers and assessors with the potential for
making different interpretations between the two identifiers and may
lead to interoperability problems. A signer could intend one to be
used for assessment, and have a non-reputation intent in setting the
value in the other. However the verifier might choose the wrong value
to deliver to the assessor, thereby producing an unintended (and
inaccurate) assessment.
Can you provide examples of interoperability problems?
Any reputation assessment system should not:
1) limit what is to be assessed.
2) allow inclusion of un-assessed information used to provide
annotation!
The change being recommended reduces intended protections.
This update resolves that confusion. It defines additional, semantic
labels for the two values, clarifies their nature and specifies their
relationship. More specifically, it clarifies that the identifier
intended for delivery to the assessor -- such as one that consults a
white list -- is the value of the "d=" tag. However, this does not
prohibit message filtering engines from using the "i=" tag, or any
other information in the message's header, for filtering decisions.
This statement is wrong because:
1) Any white-listing practice based upon replayable signatures _will_
be abused.
2) Use of the i= value is being defined as permission to discard email!
This is creating an operational problem by having email is accepted
and then having it discarded. This creates a disincentive for signers
to offer additional intra-domain information.
So, this Update clarifies the formal interface to DKIM, after
signature verification has been performed. It distinguishes DKIM's
internal signing and verification activity, from its standardized
delivery of data to that interface.
What interface, the presentation layer?
The focus of the Update is on the portion of DKIM that is much like
an API definition. If DKIM is implemented as a software library for
use by others, it needs to define what outputs are provided, that is,
what data that an application developer who uses the library can
expect
to obtain as a result of invoking DKIM on a message.
This Update draft defines the output of that library to include the
yes/no result of the verification and the "d=" value.
It would be inherently unsafe to intentionally ignore information used
for presentation. As such, the i= value (or its default) SHOULD be
assessed. It can be and I'll be happy to describe an API that meets
the requirement.
Such an API can avoid the inter-operational problems your change will
create.
This does not state what the implicit value of "i=" is, relative to
"d=". In this context, that fact is irrelevant.
The i= value clarifies the entity on whose behalf the signature was
added, and directs annotation process. The d= value is irrelevant to
an assessment of behavior history, especially when the d= value might
combine the behaviors of millions. This change to DKIM is simply
wrong, since the goal of DKIM is to defend against spoofing. This
change invites massive intra-domain spoofing.
Another example is the difference between the socket interface to
TCP versus the TCP protocol itself. There is the activity within the
protocol stack, and then there is the activity within in the software
libraries that are actually used.
The TCP socket does not acknowledge TCP packets and then discard them
before being presented, and yet this is the change being advocated. :^(
Measures that email must take to fend off massive abuse should not
then result in email becoming even more unreliable.
Public MTAs (port 25) should explicitly declare an intent to issue
email. It may not be too late to resurrect your CVS effort. Once
public MTAs can be identified and consolidated, the overall size of
public MTA assessments is likely around 8 million. This would exclude
servers that depend upon email for monitoring purposes. These sources
will likely require specific ACLs.
Anti-abuse schemes that attempt to redirect assessments to customers
of public MTAs will not scale, especially when they involve dozens of
transactions. Each transaction or cryptographic operation will be
abused a million fold.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html