Subject: Re: [ietf-dkim] New Issue: Misleading figure in 1.1

From: Jim Fenton <[email-masked]>
Date: Sun, 05 Mar 2006 16:14:28 -0800

Frank Ellermann wrote:
> Hector Santos wrote:
>  
>   
>> ProcessB() - SSP lookup
>>     
>  
>   
>>     - Message Arrives
>>     - OA SSP Policy lookup
>>        - EXCLUSIVE
>>            - Two Signers found --> REJECT
>>     
>  
>   
>> I would think ProcessB() is more ideal, more efficient and
>> 100% DKIM/SSP compatible, and more importantly with a
>> rejection result that is mostly likely to be more correct
>> than ProcessA() acceptance of an OA domain policy voilation.
>>     
>
> IBTD for your "Two Signers found --> REJECT" shortcut.  It's
> enough to reject it if no signature matches the SSP domain.
>
> BUT I think anything else you said here is correct, and this is
> not reflected in the first figure of the "threats" draft.  I've
> now stated this at least five time, time to get a ticket.  Bye
>   
I thought about this while working on the forthcoming revision to the
threats document, and decided not to change the diagram.  I agree that
there are perhaps more optimal ways of doing the verification, but the
lead-in to the diagram says it is a "typical usage flowchart" for DKIM. 
It's setting the context for the rest of the threat analysis, so it's
just showing how signing and verification could be done, not necessarily
the best way.  I think it's beneficial to go with the simplest example
possible here.

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

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Mar 2006 08:13:38 +0100

Jim Fenton wrote:

> I agree that there are perhaps more optimal ways of doing the
> verification, but the lead-in to the diagram says it is a
> "typical usage flowchart" for DKIM.

Yes, but too simple for what we need for the {censored] mailing
lists mutilating mail bodies and doing interesting "things" wrt
PRA in the header.

For the threats draft not absolutely necessary, but somewhere
we need it, it's also related to the terminology question, and
other discussions about "strong" policies.

Excluding MSAs and MDAs all MTAs get mail from another MTA and
(try to) forward it to the next MTA (if they haven't rejected
it.  The typical flow is therefore receive before send even if
you look only at a single MTA.

If you aggregate them into (first) MON / mediator / (final) MRN
it starts to get important, the MX(s) of the mediator check the
signatures if they wish to reject "strong" problems, and the
(re)signing comes much later after the mailing list modified
the mail.

> I think it's beneficial to go with the simplest example
> possible here.

Generally I like KISS, but with bounce messages (instead of a
clean reject at the border MX) details matter.  Admittedly no
point for the threats draft, "DKIM could cause more bounces if
implemented in some naive ways" is no interesting threat.  Bye