Re: [ietf-dkim] chained signatures, was l= summary

On Jun 5, 2009, at 6:36 AM, Charles Lindsey wrote:

> On Thu, 04 Jun 2009 20:19:34 +0100, Douglas Otis <dotis(_at_)mail- 
> abuse.org>
> wrote:
>
> > On Jun 4, 2009, at 5:20 AM, Charles Lindsey wrote:
> >
> > > On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy
> > > > You're not required to sign them, but it's not a bad idea.
> > > Then why are people on this list not trying to enocourage that  
> > > good practice? Indeed, why are they so vociferously trying to  
> > > DIScourage it?
> > Before A-R headers can be trusted, A-R headers MUST be removed by  
> > incoming border MTAs.  See section 1.6 of RFC 5451.
> No, that is NOT what section 1.6 of RFC 5451 says. It requires  
> removal of any pre-existing A-R header "claiming to be valid with in  
> its [the ADMD's] boundaries", which essentially means (AIUI) any A-R  
> header that might be mistaken for one that might/would/should have  
> been created within that same ADMD.
By selecting specific A-R headers to remove, header content might be  
processed post delivery, and then appear to match against some trusted  
domain.

The safest solution would be to remove _all_ A-R pre-existing A-R  
headers from different environments or not since they may not have  
been treated as trace headers or are encoded in some fashion.  It is  
hard enough to decide whether A-R headers that appear to be from the  
incoming domain can be trusted.  To better ensure trustworthiness of A- 
R headers, it seems wise to remove _all_ preexisting A-R headers.   
Until A-R handling has demonstrated consistent safety, and not just  
safe most of the time, it seems imprudent to trust foreign A-R  
headers.  YMMV.

> BUT the cases we are considering are where, in the course of its  
> travels,  a message has picked up two signatures, S_1 and S_2, but  
> where S_1 has (possibly) been invalidated by some change at an  
> intermediate site  (typically a mailing list expander) en route, and  
> even where S_1 has been removed at some point. So there are at least  
> three ADMDs involved:
>
> |    sending ADMD   |       Mail List ADMD        |       Receiving  
> ADMD     |
> | orig MUA orig MTA |                             |    Recv MTA      
> Recv MUA |
> |    M ---> M+S_1 --+-> M+S_1+A_1 -> M*+A_1+S_2 --+-> M*+A_1+S_2+A_2
> -->     |
>
> A_1 was added by a validator/assessor on the strength of S_1
> A_2 was added by a validator/assessor on the strength of S_2
> Observe that M was transmogrified into M* at some point, breaking S_1.
>
> If some "helpful" MTA, somewhere between the Mail List and Receiving  
> ADMDs, had also added an A_2, then THAT is the one that should be  
> removed by Recv MTA, before inserting its own (which it obviously  
> would not do if S_2 covered A_1, and A_1 was no longer there).
>
> What Recv MTA passes on to Recv MUA is entirely a matter to be  
> decided within the Receiving ADMD, but I hope it would be everything  
> that was available (even S_1 if it were still available).
>
> Note that Appendix B.6 of RFC 5451 contains an example exactly  
> equivalent to the one I have just given, including the retention of  
> A_1 (and even S_1).
IMHO, appendix B.6 is overly optimistic for today's environment.

-Doug


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