[ietf-dkim] Re: ISSUE: Better definition of "DKIM signing complete" required

[Hector Santos]

Charles Lindsey wrote:
> On Sun, 26 Nov 2006 21:37:37 -0000, Hector Santos 
> <hsantos at santronics.com> wrote:
> 
>> We must work on the basis that a DOMAIN may want to use DKIM in a 
>> highly exclusive, bar none, 1 to 1 communications environment only.  
>> That is the highest protection DKIM an offer.  We can't ignore this.
>>
>> After that, it gets relaxed and murky as to how to keep this DKIM 
>> security intact with various relaxed conditions.  But we must satisfy 
>> the ideal condition and that is the strong and/or exclusive SSP policy.
>>
>> At this point, we then look at new features to support the DKIM LS 
>> implementation such as:
> 
> AFAICS, a List Expander has the following options:
> 
> 1. Ignore DKIM. Pretend it doesn't exist.
>    The result of that is that list members (or their ISPs) will start 
> regarding some messages with "suspicion", and maybe drop them. List 
> members wll not be pleased.
> 
> 2. Refuse to subscribe (as contributors) sites with exclusive SSP policies.
>    Will work, but will piss off people from such domains who want to 
> participate.
> 
> 3. Manage the list so that signatures still work after passing through.
>    I.e. don't change 'critical' headers, don't add stuff at the end of 
> bodies, etc.
> 
> 4. Resign all messages yourself.
>    Essentially, you are saying "I realise I may have broken the existing 
> signature, but I assure you I verified the original signature and 
> checked that it complied with the sender's SSP, and my new signature 
> encompasses an X-verified header I added to testify to those checks. 
> Trust me! I am a Good Guy!"
> 
>    And then you hope that your reputation is good enough that your 
> highly suspicious recipients will indeed believe that you are a "Good Guy".
> 
> So, is that a good summary of strategies that have been discussed on 
> this list, or are there others? And are they good enough (#4 seems the 
> best approach to be, or maybe #3 and #4 together)?

I think #1 include those who are just unaware of DKIM, legacy software.

I think #2 is the most practical support and probably most likely the 
first thing a list server author will do. I'm speaking as one.  I think 
this is something all "signup concepts" will look at because it is very 
easy to do and helps "Email/Signup Verification" process.

I think once the decision is made to support DKIM, which inherently 
includes #2, is to begin offering options to not alter the integrity 
(#3) and also offer resigning (#4) when possible.

The 5th item is STRIP and RESIGN as 3rd party

The 6th item is STRIP and RESIGN as 1st party in behalf of the original 
domain.

So there are all known or already discussed scenarios.  These was 
written in various places, including the DSAP I-D.

However, the key, IMTO, is SSP. All middle ware interfacing is only 
technically and consistently correct if the DOMAIN allows for 3rd party 
senders and/or 3rd party DKIM resigning, fingerprints.


---
HLS