ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] brand protection, was Is anyone using ADSP?

2009-10-16 10:31:53
Ian Eiloart wrote:


--On 14 October 2009 15:39:12 -0400 hector 
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com> 
wrote:


It may never be. But, it's relatively new, so it doesn't surprise me that 
it's not in use. However, It's also not surprising that people who may use 
the RFCs wish to understand the implications, and explore the problems 
before implementing.


I couldn't agree more.

But I think the current advisement is not to use it, so R&D, 
exploration, experimentation, and developing corrective measures is 
next to nil.  Under such conditions most systems won't bother or can't 
afford to deal with alpha ware in a production environment.  So to me, 
it shouldn't be a surprise that there is little support, even thought 
that might be high interest.

Its not very hard to create a DKIM simulation based on establishing 
your boundary conditions for this process with the current specifications.

ADSP has three possible boundary conditions:

     unknown
     all
     discardable

DKIM-BASE has five possible boundary conditions:

      not signed
      signed by 1st party - valid
      signed by 1st party - invalid
      signed by 3rd party - valid
      signed by 3rd party - invalid

when can be reduced to three using the RFC 4871 semantics that 
promotes/demotes an invalid signature to no signature (never signed) 
status:

      not signed
      signed by 1st party - valid
      signed by 3rd party - valid

Therefore you have nine theoretical possible outcomes:

                       ADSP RECORD
      +=============================================+
      |       |  UNKNOWN  | ALL      |  DISCARDABLE |
      |=============================================|
   D  | NONE  |  pass     | discard? |   discard    |
   K  |-------+-----------+----------+--------------|
   I  | 1PS   |  pass     | pass     |   pass       |
   M  |-------+-----------+----------+--------------|
      | 3PS   |  pass     | discard? |   discard    |
      +=============================================+


IMO, we have seven high confidence deterministic possibilities.  For 
the DISCARD? results, as you said, DKIM=ALL is open-ended with no 
semantics (by design) so its left to ambiguous interpretation and 
local policy.

Now, consider the following:

IMV, I think the RFC 4871 semantics for promoting/demoting a broken 
signature to no signature is somewhat flawed.   IMV, it was not when 
policy was a major consideration of the DKIM specification and such a 
semantic naturally fit the valid signature requirement policies.

But when you separate POLICY from DKIM-BASE, "data" was now lost for 
augmented technologies to learn, explore, etc.  In other words, when 
the WG decided to separate the two developments, it invalidated this 
semantic. It should of been removed IMO. The reason is because we lost 
intent.

In the NONE/DKIM=ALL cell, this could be the result of two different 
mail scenarios:

      NO (REAL) SIGNATURE
      INVALID SIGNATURE

To me, that is two different classification or weights.

I don't have the answer, but I believe it begins with the question, 
which message do you trust more, one that didn't have a signature or 
one that was broken?

For the former (Missing), one can argue it is a genuine spoof or a 
roaming user using the domain address from some 3rd party service 
(i.e. hotel).  One can also say the roaming user is a thing of the 
pass as most users now have direct internet access to their main 
hosting service from anywhere in the world.

For the latter (broken), one can argue there was malicious intent but 
it could be some relay that innocently broke the integrity.

So the RFC 4871 promotion (or demotion depending on your POV) of 
Broken to no signature status hides intent.  This can become important 
if we are going to be looking at other evidence, headers, scoring or 
classification concept.

Anyway, my 2 pennies.

--
HLS


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>