ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Message Replay Abuse and Acceptance of a Signature

2006-01-22 23:30:37
On Mon, 2006-01-23 at 01:21 +0000, Stephen Farrell wrote:

Would the term signature-overlay or perhaps signature-masking be okay?

Were it me, I'd first consult the literature before inventing
any new terminology related to digital signatures. At the least,
I'd first ask someone who's familiar with that literature.

Without having checked, I can't say either of those terms ring
a bell, but using clear, unambiguous terms is a good thing and
[ab|re]using existing terms in odd ways is a bad thing.

Sorry, I was attempting to convey a concept.  The dkim-options draft
already uses the term overlay. 


What is being proposed is _not_ a new header or a fundamental change to
the DKIM signature.  This proposal involves an introduction of a single
character 'w=' parameter added to the signature.  

Part of the problem with this proposal is the sales-talk that
accompanies it. You clearly know that it is not significant that
"w=" rather than "malarkey=" is just a few characters shorter and
you also know that that fact is totally unworthy of mention.

As I was not including the entire table, this was to indicate that it
would be a single character combined with 'w=' such as 'w=d' or 'w=a'.
The reason for mentioning the number of added characters was to indicate
the amount of information being added is minimal.


The current base DKIM draft does not define how multiple signatures are
handled, how mediators are recognized, or how replay abuse can be
prevented.  

IMO, none of the above necessitate assertions made on behalf of
MDAs (to use your term).

The role of the MDA is to provide anti-spoofing protection within the
MDA AdmD when signature overlays are used.  Many may not include this
added layer of protection.  The signature overlay with results however
still provides abusive replay protection.  The same role and essential
source identification scheme can be used to identify a mediator or
MSA/MUA, as well as information the signer claims to have verified.


The rather simple 'w=' parameter adds to the DKIM signature
a basis for solutions for resolving these open issues.  This simple
option should not demand a recharter in order to resolve some rather
basic issues, some of which were raised in the initial review conducted
by Russ.  This option is also upwardly compatible with the current
implementations.

I personally don't agree. Any DKIM-defined assertion on behalf of the
verifier of a message is complicated. Luckily, our charter says this
pretty clearly, so to the extent that replay is an issue (and my gut
tells me it is), other anti-replay mechanisms are preferable.

Perhaps simple is not a good description.  The significant value that
DKIM offers is from the concise identification of the message source,
where the recipient can be assured when sources match that of a prior
correspondent.  This identification can be augmented with email-
addresses, portions of email-addresses, or perhaps opaque-identifiers.

When the binding advice within the signature indicates the email-address
has not been verified, but that the opaque-identifier has been verified
instead, this improves upon the reliability of the source information
being conveyed.  Even when the email-address domain matches that of the
signer, only the opaque-identifier may have been verified.  Of course,
nothing within the message could have been verified, and that too can be
conveyed with the binding information added to the signature.

Any additional information found within the signature depends upon the
role and reputation of the signer, where in some cases an increased
level of trust may be assumed when the email-address domains are shared
by the signature.   When the signer is not claiming the role of the MSA,
or does not share the same domain as the email-address, the level of
trust depends upon the weight given the signer.  This assumes the
verification process must consider the trustworthiness of the signer.

With respect to signing and the trustworthiness of the recipient, the
dkim-option draft provides several solutions in this area, as there is
no reason not to expect that replay abuse will not become a problem. 

Upon review of these options, compare the level of administration and
timeliness of the response required to abate an abusive replay problem
using a signature overlay strategy.   A consistent use of a signature
overlay practice allows abuse assessments to be made at the domain,
rather than at the signature or a email-address.  This closely mirrors
the same strategy used assessing the sender when receiving a message,
which is a well understood and stable.

-Doug
 




_______________________________________________
ietf-dkim mailing list
http://dkim.org