Re: [ietf-dkim] chained signatures, was l= summary
On Mon, 08 Jun 2009 23:37:50 +0100, Murray S. Kucherawy wrote: >> The use of the DKIM l=, z= and x= features provide a means for >> recipients to separately evaluate DKIM signatures without reliance on >> intermediary assessors. In addition, the A-R header does not capture >> the IP address when assessing path registration protocols, which means >> that safe recipient reassessment might only be possible in the case of >> DKIM or reverse DNS. >> [...] > > Could we please not re-re-re-rehash these A-R issues on ietf-dkim? They > were already covered on mail-vet-discuss more times than I can count. > The archives of that list are public in case anyone really needs to go > through them all again. Actually, this discussion is a spin-off of the thread on the usefulness of the l= tag, which is definitely on topic for this group. What I think it makes clear that we are in serious need of some document to provide Best Practice for how mailing list expanders should handle DKIM, and I think that is something that this WG needs to take on board. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Mon, 08 Jun 2009 19:30:38 +0100, Doug Otis wrote: > On Jun 8, 2009, at 3:24 AM, Charles Lindsey wrote: >> For sure, individual recipients may wish to check signatures etc. >> for themselves, espeicially if they have doubts about the policies >> applied by their local assessors. If the local assessor has >> unnecessarily removed some A-R that is actually covered by the >> signature, then that becomes impossible. > > The use of the DKIM l=, z= and x= features provide a means for > recipients to separately evaluate DKIM signatures without reliance on > intermediary assessors. In addition, the A-R header does not capture > the IP address when assessing path registration protocols, which means > that safe recipient reassessment might only be possible in the case of > DKIM or reverse DNS. I accept that my remarks concerning the retention of A-R headers are directed at the case where those headers are confirming the analysis of some DKIM signature. Different considerations may well apply when the A-R is reporting on some other security mechanism. >>> The safest solution would be to remove _all_ A-R pre-existing A-R >>> headers from different environments ... >> >> But that's not what the standard says. > > Wrong. See RFC 5451 section 5, complete removal is suggested for > maximum security. It also suggests: When you first made your claim, you were relying on Section 4.1. Now I have shot that one down, you have transferred to Section 5. But section 5 merely says you MAY remove A-R headers, but then immediately goes on to warn you of two situations where this might be counter productive. Both of those situations arise in the scenarios I have been discussing. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
I think Murray's point is a fair one. This thread isn't really progressing in terms of what to in/exclude from 4871bis as far as I can see so let's leave it there. Stephen. Doug Otis wrote: > On Jun 8, 2009, at 3:37 PM, Murray S. Kucherawy wrote: > >>> The use of the DKIM l=, z= and x= features provide a means for >>> recipients to separately evaluate DKIM signatures without reliance >>> on intermediary assessors. In addition, the A-R header does not >>> capture the IP address when assessing path registration protocols, >>> which means that safe recipient reassessment might only be possible >>> in the case of DKIM or reverse DNS. >>> [...] >> Could we please not re-re-re-rehash these A-R issues on ietf-dkim? > > > This was in response Charles making the statement: > > "For such forensic investigations, removing useful information (aka > "dumbing down") is always a dumb thing." > > These headers represent an active and potentially hazardous component > used in email annotation. Unless the border MTA is willing to assert > the A-R headers not removed are safe, the A-R headers should be > removed. The point of "rehashing" information excluded from the A-R > header was to emphasize the point that these headers were not intended > to play a role in forensics. Otherwise, the source of a message would > have been important. > > -Doug > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Jun 8, 2009, at 3:37 PM, Murray S. Kucherawy wrote: >> The use of the DKIM l=, z= and x= features provide a means for >> recipients to separately evaluate DKIM signatures without reliance >> on intermediary assessors. In addition, the A-R header does not >> capture the IP address when assessing path registration protocols, >> which means that safe recipient reassessment might only be possible >> in the case of DKIM or reverse DNS. >> [...] > > Could we please not re-re-re-rehash these A-R issues on ietf-dkim? This was in response Charles making the statement: "For such forensic investigations, removing useful information (aka "dumbing down") is always a dumb thing." These headers represent an active and potentially hazardous component used in email annotation. Unless the border MTA is willing to assert the A-R headers not removed are safe, the A-R headers should be removed. The point of "rehashing" information excluded from the A-R header was to emphasize the point that these headers were not intended to play a role in forensics. Otherwise, the source of a message would have been important. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
> The use of the DKIM l=, z= and x= features provide a means for > recipients to separately evaluate DKIM signatures without reliance on > intermediary assessors. In addition, the A-R header does not capture > the IP address when assessing path registration protocols, which means > that safe recipient reassessment might only be possible in the case of > DKIM or reverse DNS. > [...] Could we please not re-re-re-rehash these A-R issues on ietf-dkim? They were already covered on mail-vet-discuss more times than I can count. The archives of that list are public in case anyone really needs to go through them all again. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Jun 8, 2009, at 3:24 AM, Charles Lindsey wrote: > On Fri, 05 Jun 2009 18:27:06 +0100, Doug Otis > wrote: > >> On Jun 5, 2009, at 6:36 AM, Charles Lindsey wrote: >> >> By selecting specific A-R headers to remove, header content might >> be processed post delivery, and then appear to match against some >> trusted domain. > > For sure, individual recipients may wish to check signatures etc. > for themselves, espeicially if they have doubts about the policies > applied by their local assessors. If the local assessor has > unnecessarily removed some A-R that is actually covered by the > signature, then that becomes impossible. The use of the DKIM l=, z= and x= features provide a means for recipients to separately evaluate DKIM signatures without reliance on intermediary assessors. In addition, the A-R header does not capture the IP address when assessing path registration protocols, which means that safe recipient reassessment might only be possible in the case of DKIM or reverse DNS. > And if they have doubts about the policies of sone earlier mailing > list expander, they might wish to see exactly what that expander had > actually done to the message. For such forensic investigations, > removing useful information (aka "dumbing down") is always a dumb > thing. Removal of foreign A-R headers provides better security. Since A-R header fails to capture source IP addresses for path registration schemes, the forensic value of this header is very limited, to the point of being dangerous. Reliance upon the A-R header offers providers permission to modify messages. Some providers offer their services free, however there remains a profit motive where their security may overlook embedded iFRAMEs referencing malware injected into one of their third-party ad servers. A-R header may indicate to recipients that the message originated from Big-Bank, but ads might appear from a different entity. In this case, the goal of DKIM is has been lost. Unfortunately, the introduction of ads is fairly common, and the authserv-ids may not offer a means to consolidate or identify who is being trusted. There are significant risks and problems created when dealing with A-R headers. DKIM without A-R headers does not invite questionable practices likely to create many duped victims. An appearance of a message being from someone trusted can be worse than a message with an unknown status when the content source is in doubt. >> The safest solution would be to remove _all_ A-R pre-existing A-R >> headers from different environments ... > > But that's not what the standard says. Wrong. See RFC 5451 section 5, complete removal is suggested for maximum security. It also suggests: "A more robust border MTA could allow a specific list of authenticating MTAs whose information should be let in, removing all others." >>> 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. > > Maybe so, but that document is a proposed standard, and unless you > have plans to get it revised, we must try and work with it as it > stands. Nothing in that example is contrary to what that standard > says normatively. No. Nor does the RFC warn of encoded headers or header reordering. Headers may be altered during handling. In addition, the "Trust Environment" can use any type of token, and not just those derived from a host name. The lack of uniformity or standardized means of ensuring uniqueness means little should be assumed regarding any A-R header not generated by the receiving MTA. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
> > By selecting specific A-R headers to remove, header content might be > > processed post delivery, and then appear to match against some trusted > > domain. I believe the Security Considerations of RFC5451 covers this adequately. > For sure, individual recipients may wish to check signatures etc. for > themselves, espeicially if they have doubts about the policies applied by > their local assessors. If the local assessor has unnecessarily removed > sone A-R that is actually covered by the signature, then that becomes > impossible. +1 > > The safest solution would be to remove _all_ A-R pre-existing A-R > > headers from different environments ... > > But that's not what the standard says. +1 > > IMHO, appendix B.6 is overly optimistic for today's environment. Have you seen actual attacks like this in the wild already? > Maybe so, but that document is a proposed standard, and unless you have > plans to get it revised, we must try and work with it as it stands. > Nothing in that example is contrary to what that standard says > normatively. +1 (BTW, does this still qualify as being "on topic" for this list?) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Fri, 05 Jun 2009 18:27:06 +0100, Doug Otis wrote: > On Jun 5, 2009, at 6:36 AM, Charles Lindsey wrote: >> 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. For sure, individual recipients may wish to check signatures etc. for themselves, espeicially if they have doubts about the policies applied by their local assessors. If the local assessor has unnecessarily removed sone A-R that is actually covered by the signature, then that becomes impossible. And if they have doubts about the policies of sone earlier mailing list expander, they might wish to see exactly what that expander had actually done to the message. For such forensic investigations, removing useful information (aka "dumbing down") is always a dumb thing. > > The safest solution would be to remove _all_ A-R pre-existing A-R > headers from different environments ... But that's not what the standard says. >> 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. Maybe so, but that document is a proposed standard, and unless you have plans to get it revised, we must try and work with it as it stands. Nothing in that example is contrary to what that standard says normatively. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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 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
Re: [ietf-dkim] chained signatures, was l= summary
On Thu, 04 Jun 2009 20:19:34 +0100, Douglas Otis 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. 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_! 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_!. 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). -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
> The issue of A-R headers being trusted only when signed by DKIM runs > counter to their intended use. That's not necessarily true. You're making hard assertions about a fuzzy situation. DKIM signing might work just fine in certain installations. That's why RFC5451 suggests doing this without requiring it. > Whatever leak that allows a bad actor's A-R header to appear > could also find itself inadvertently signed by the incoming domain. I agree that this is a security consideration, but it doesn't mean signing A-R headers is a waste of effort. At some sites it's probably the ideal solution. > Just check originating DKIM signatures, and ignore A-R headers would > be the safest solution. Use of A-R headers allow providers a means to > visibly modify messages without the recipient being aware that the > visible content had been added by the provider. In general, this > seems like a bad idea with respect to DKIM. I disagree with "in general". There seems to have been enough consensus to put A-R up to proposed standard status, and that seems to fly in the face of your claim that it's not useful. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Jun 4, 2009, at 5:20 AM, Charles Lindsey wrote: > On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy > wrote: > >>> WTF is the point of inserting an A-R header if you are not willing >>> to take responsibility for what you have done by signing it? >>> >>> And why should anyone else believe your A-R if you have omitted >>> that elementary step? >> >> Because, if you've followed the RFC defining it, the border MTA >> has removed any others present that could possibly be >> misinterpreted by internal agents. > > Yes, but that is the MTA at MY border. I would expect the assessor > at MY border to have indicated some degree of suspicion if the A_R > header it was about to remove (before substituting its own) was not > included in the signature that accompanied it. >> >> 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. Border MTAs may exchange messages with internal servers that might process filters where internal routes are influenced by message content. Whenever removing A-R headers is done on a conditional basis, this creates gaps in security, especially when trust is placed upon A-R headers added by a subsequent filtering process. Only removing A-R headers at the border exactly matching those added by the receiving domain invites trouble. There are many three-step tricks that thwart matching techniques, where these headers might appear differently at some later stage. The safest approach for handling A-R headers would be to remove _all_ of them as they arrive. After filtering messages, incoming MTA can decide what they wish to do with the message. When a filtering process decides to reject a message, this should be done prior to adding A-R headers, perhaps even after removing existing A-R headers. A safe process must ensure there is no overlap between where incoming A-R headers are removed, and where the incoming receivers add A-R headers to messages. The issue of A-R headers being trusted only when signed by DKIM runs counter to their intended use. When it is concluded that MUAs should independently check DKIM signatures that include A-R headers, this suggests A-R headers are not very trustworthy, which might be the case. Whatever leak that allows a bad actor's A-R header to appear could also find itself inadvertently signed by the incoming domain. Just check originating DKIM signatures, and ignore A-R headers would be the safest solution. Use of A-R headers allow providers a means to visibly modify messages without the recipient being aware that the visible content had been added by the provider. In general, this seems like a bad idea with respect to DKIM. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
Charles Lindsey wrote: > On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy > wrote: > >>> WTF is the point of inserting an A-R header if you are not willing to >>> take responsibility for what you have done by signing it? >>> >>> And why should anyone else believe your A-R if you have omitted that >>> elementary step? >> Because, if you've followed the RFC defining it, the border MTA has >> removed any others present that could possibly be misinterpreted by >> internal agents. > > Yes, but that is the MTA at MY border. I would expect the assessor at MY > border to have indicated some degree of suspicion if the A_R header it was > about to remove (before substituting its own) was not included in the > signature that accompanied it. The cases, IMO, of when a ar-header is useful from a foreign domain are vanishingly small, so removing it is just a matter of good hygiene. If capturing its essence is important, I suppose that we'll first see border mta software using it for something. To my knowledge, nobody is. (foreign a-r that is). >> 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? Because it's a marginal case. At Cisco, the only thing that I'm aware* that we were using a-r for was generating gross statistics, where what even a trusted foreign verifier -- which we had none -- were useless for what we were using it for. Maybe we were outliers, but I doubt it. [*] yes a couple of us were using ar to color messages in our muas, but we were a pretty self-selected, self-interested population Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy wrote: >> WTF is the point of inserting an A-R header if you are not willing to >> take responsibility for what you have done by signing it? >> >> And why should anyone else believe your A-R if you have omitted that >> elementary step? > > Because, if you've followed the RFC defining it, the border MTA has > removed any others present that could possibly be misinterpreted by > internal agents. Yes, but that is the MTA at MY border. I would expect the assessor at MY border to have indicated some degree of suspicion if the A_R header it was about to remove (before substituting its own) was not included in the signature that accompanied it. > > 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? -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Wed, 03 Jun 2009 14:58:06 +0100, John Levine wrote: > The most common use of A-R will likely involve a secure channel > between the place where it's applied and the place where it's > interpreted, e.g., it's applied at a border MTA and it's interpreted > in a downstream MTA or MUA within the same network. In that case, you > don't need a signature. Agreed, but that is not the situation of concern. > > If you imagine that there are strangers elsewhere in the world who > would be impressed by your opinion of a message you were forwarding, > you might want to sign it, but as I've noted before, if you're > forwarding it and mutating it enough that recipients wouldn't use an > incoming signature (i.e., you're a mailing list) you'd best take care > to send and sign only mail that recipients are likely to want. A competent mailing list admin would reject all messages from dubious sources. But it would be foolish to assume that all such admins are as competent as we would wish. So the mere fact that they (re)sign messages does not prove their origin, except insofar as you are prepared to have confidence in their competence. If they try to bolster your confidence in them by offering an A-R header to show their diligence in eliminating dubious messages, then that is well and good, but if they are unwilling to put their signature where their mouth is, then why should I be impressed? I don't see why you would choose to regard me, as a member of your mailing list, as some "stranger elsewhere in the world". -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Jun 3, 2009, at 9:13 AM, Murray S. Kucherawy wrote: >> WTF is the point of inserting an A-R header if you are not willing >> to take responsibility for what you have done by signing it? >> >> And why should anyone else believe your A-R if you have omitted >> that elementary step? > > Because, if you've followed the RFC defining it, the border MTA has > removed any others present that could possibly be misinterpreted by > internal agents. > > You're not required to sign them, but it's not a bad idea. ISPs seem unlikely sign incoming messages because they include their A- R headers. A-R headers are expected to be removed at border MTAs, so when forwarding, signatures intended to protect A-R headers will normally become invalid. One would not be able to tell whether these signature were being spoofed by the ISPs outbound server, or whether the signature represents a failed attempt to protect A-R headers. Should DKIM signatures not include missing A-R headers? -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
> WTF is the point of inserting an A-R header if you are not willing to > take responsibility for what you have done by signing it? > > And why should anyone else believe your A-R if you have omitted that > elementary step? Because, if you've followed the RFC defining it, the border MTA has removed any others present that could possibly be misinterpreted by internal agents. You're not required to sign them, but it's not a bad idea. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
>WTF is the point of inserting an A-R header if you are not willing to take >responsibility for what you have done by signing it? > >And why should anyone else believe your A-R if you have omitted that >elementary step? The most common use of A-R will likely involve a secure channel between the place where it's applied and the place where it's interpreted, e.g., it's applied at a border MTA and it's interpreted in a downstream MTA or MUA within the same network. In that case, you don't need a signature. If you imagine that there are strangers elsewhere in the world who would be impressed by your opinion of a message you were forwarding, you might want to sign it, but as I've noted before, if you're forwarding it and mutating it enough that recipients wouldn't use an incoming signature (i.e., you're a mailing list) you'd best take care to send and sign only mail that recipients are likely to want. I'm with Mike here -- signing A-R isn't important, because chained signatures won't be useful in practice. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Tue, 02 Jun 2009 14:24:43 +0100, Michael Thomas wrote: > Wietse Venema wrote: >> Charles Lindsey: >>> On Mon, 01 Jun 2009 15:49:28 +0100, Barry Leiba >>> >>> wrote: >>> I think it's a terrible idea to (1) leave signatures in a message after you break them, (2) add A-R without removing any already there, or (3) add A-R without a signature covering it. > > A signature covering it? That's quite a new requirement for a-r and > one that nobody that I'm aware is following. It is such a blatantly obvious necessity that I am surprised it is occasioning such surprise. WTF is the point of inserting an A-R header if you are not willing to take responsibility for what you have done by signing it? And why should anyone else believe your A-R if you have omitted that elementary step? > In any case, removing signatures seriously sucks from a forensics > standpoint. The DKIM rule is that if they're broken, they're equivalent > to not existing. Leaving signatures in hurts *nothing*, and > provides a lot of feedback to the original sender if needed to > diagnose why signatures failed. > +1. That is exact;y the point I was trying to make. > This shit happens in the real world. Often. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 2, 2009, at 5:05 AM, Wietse Venema wrote: > Charles Lindsey: >> On Mon, 01 Jun 2009 15:49:28 +0100, Barry Leiba > > >> wrote: >> >>> I think it's a terrible idea to (1) leave signatures in a message >>> after you break them, (2) add A-R without removing any already >>> there, >>> or (3) add A-R without a signature covering it. >> >> And I, on the contrary, believe it is a terrible idea EVER to >> remove a >> signature or an A-R header. There is never anything to be gained by >> throwing away information that someone more perceptive than >> yourself might >> find useful. > > Except, of course, when the bad guys use this to have their bogus > signatures and their bogus A-R headers "laundered" by naive signers. I agree with Wietse on the basic principle here. If one is providing an email service where one is *processing* a message, then removing old signatures and resigning is the best thing. For example, a mailing list server processes the message in that it takes incoming messages and then resends them in some similar-to- identical form. I believe it is ideal in this case to remove the old signature and resign. I as the ultimate receiver, filter and process those messages based upon the mailing list, not based upon the original sender. I'm on a number of lists with many of you and I want them organized by mailing list, not sending person. DKIM should be similar. However, if someone implemented a mailing list server that did its best to be invisible, I wouldn't say it was doing the wrong thing, either. The bad case is where I have a message that is signed by both parties and one signature is broken. That puts the message into some weird state. It's less weird when the person's signature is broken and the list signature isn't. The broken signature now just creates confusion. The other case is even more confusing, but yet the message is still cryptographically intact. That's why if I were the author of the list server, I'd strip and resign (or resend while preserving the signature). Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFKJZ5ssTedWZOD3gYRApmsAJ98y9PBd4AZinARHBHJsziUqeK3pgCff4QM zlbWthOHQspF35EhqHvchyk= =BRdV -END PGP SIGNATURE- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
Wietse Venema wrote: > Charles Lindsey: >> On Mon, 01 Jun 2009 15:49:28 +0100, Barry Leiba >> wrote: >> >>> I think it's a terrible idea to (1) leave signatures in a message >>> after you break them, (2) add A-R without removing any already there, >>> or (3) add A-R without a signature covering it. A signature covering it? That's quite a new requirement for a-r and one that nobody that I'm aware is following. >> And I, on the contrary, believe it is a terrible idea EVER to remove a >> signature or an A-R header. There is never anything to be gained by >> throwing away information that someone more perceptive than yourself might >> find useful. > > Except, of course, when the bad guys use this to have their bogus > signatures and their bogus A-R headers "laundered" by naive signers. People who use bogus information to make go/no-go decisions quite literally get what they deserve. Why single out DKIM? In any case, removing signatures seriously sucks from a forensics standpoint. The DKIM rule is that if they're broken, they're equivalent to not existing. Leaving signatures in hurts *nothing*, and provides a lot of feedback to the original sender if needed to diagnose why signatures failed. This shit happens in the real world. Often. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On 6/2/2009 08:05, Wietse Venema wrote: > Charles Lindsey: >> On Mon, 01 Jun 2009 15:49:28 +0100, Barry Leiba >> wrote: >> >>> I think it's a terrible idea to (1) leave signatures in a message >>> after you break them, (2) add A-R without removing any already there, >>> or (3) add A-R without a signature covering it. >> And I, on the contrary, believe it is a terrible idea EVER to remove a >> signature or an A-R header. There is never anything to be gained by >> throwing away information that someone more perceptive than yourself might >> find useful. > > Except, of course, when the bad guys use this to have their bogus > signatures and their bogus A-R headers "laundered" by naive signers. > I agree. DKIM is supposed to make it easier for recipients to recognize the few legitimate messages in the flood of unwanted, if not intentionally malicious, messages that are presented to our servers. I see little, if any, value in leaving broken signatures and the matching A-R headers in a message, and a great deal of potential for problems resulting from the flawed assumption that the signature must have been valid at some point in time, or it and its matching A-R headers would not be present. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame Just because you're paranoid doesn't mean they aren't out to get you. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
Charles Lindsey: > On Mon, 01 Jun 2009 15:49:28 +0100, Barry Leiba > wrote: > > > I think it's a terrible idea to (1) leave signatures in a message > > after you break them, (2) add A-R without removing any already there, > > or (3) add A-R without a signature covering it. > > And I, on the contrary, believe it is a terrible idea EVER to remove a > signature or an A-R header. There is never anything to be gained by > throwing away information that someone more perceptive than yourself might > find useful. Except, of course, when the bad guys use this to have their bogus signatures and their bogus A-R headers "laundered" by naive signers. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Mon, 01 Jun 2009 15:49:28 +0100, Barry Leiba wrote: > I think it's a terrible idea to (1) leave signatures in a message > after you break them, (2) add A-R without removing any already there, > or (3) add A-R without a signature covering it. And I, on the contrary, believe it is a terrible idea EVER to remove a signature or an A-R header. There is never anything to be gained by throwing away information that someone more perceptive than yourself might find useful. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
why? Paul Russell wrote: > On 6/1/2009 10:49, Barry Leiba wrote: >> On Fri, May 29, 2009 at 5:22 PM, John R. Levine wrote: >>> I would really like to remove l= from DKIM to make it clear that it is not a >>> good idea to even try to guess the history of a message based on signatures >>> that don't verify and cover the whole messag. >> Yes, that seems to be the consensus, and I agree with that. >> >> Barry, as participant > > It appears that you either missed or chose to ignore recent messages from > individuals who do not agree that l= should be removed. I have been reading > the arguments on both sides of this issue and lean towards leaving it in the > spec. > -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On 6/1/2009 10:49, Barry Leiba wrote: > On Fri, May 29, 2009 at 5:22 PM, John R. Levine wrote: >> I would really like to remove l= from DKIM to make it clear that it is not a >> good idea to even try to guess the history of a message based on signatures >> that don't verify and cover the whole messag. > > Yes, that seems to be the consensus, and I agree with that. > > Barry, as participant It appears that you either missed or chose to ignore recent messages from individuals who do not agree that l= should be removed. I have been reading the arguments on both sides of this issue and lean towards leaving it in the spec. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame pruss...@nd.edu ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Fri, May 29, 2009 at 5:22 PM, John R. Levine wrote: >> I don't understand what "cruft" you think I'm talking about. > > Telling people that it is reasonable to add a chain of A-R headers to > messages with broken signatures, and expecting recipients to apply some ill > defined algorithm to decide how much they believe each level of alleged > signature. What part of my message makes you think that's what I'm suggesting? Surely not the part where I say, "Chaining isn't the point.". And it certainly can't be the part where I say, "remove all previous sigs AND all previous A-R". I think it's a terrible idea to (1) leave signatures in a message after you break them, (2) add A-R without removing any already there, or (3) add A-R without a signature covering it. Or are you just trolling? > I would really like to remove l= from DKIM to make it clear that it is not a > good idea to even try to guess the history of a message based on signatures > that don't verify and cover the whole messag. Yes, that seems to be the consensus, and I agree with that. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of John R. Levine > Sent: Friday, May 29, 2009 5:22 PM > To: Barry Leiba > Cc: DKIM List > Subject: Re: [ietf-dkim] chained signatures, was l= summary > > >> DKIM is too complicated as it is, and it strikes me as an extremely > poor > >> idea to add yet more cruft to work around perverse situations that are > as > >> yet (and probably always) entirely hypothetical. > > > > I don't understand what "cruft" you think I'm talking about. > > Telling people that it is reasonable to add a chain of A-R headers to > messages with broken signatures, and expecting recipients to apply some > ill defined algorithm to decide how much they believe each level of > alleged signature. > > I would really like to remove l= from DKIM to make it clear that it is not > a good idea to even try to guess the history of a message based on > signatures that don't verify and cover the whole messag. > > R's, > John > +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Fri, 29 May 2009 22:22:11 +0100, John R. Levine wrote: > I would really like to remove l= from DKIM to make it clear that it is > not > a good idea to even try to guess the history of a message based on > signatures that don't verify and cover the whole messag. Speak for yourself. I see a message with a broken, but otherwise plausible, signature, and that seems on the face of it a genuine message that I might very well care about, then I might well start to play around to see if some small munge of the message might have caused the broken signature. I have often done this in the case of seemingly broken Usenet control messages. Just because a feature is likely to be used only rarely, and then only by people who have a good understanding of the protocol, is no reason to remove that possibility entirely from those people. That is just called "dumbing down", and "dumbing down" is a dumb idea. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On May 29, 2009, at 2:22 PM, John R. Levine wrote: >> I don't understand what "cruft" you think I'm talking about. > > Telling people that it is reasonable to add a chain of A-R headers > to messages with broken signatures, and expecting recipients to > apply some ill defined algorithm to decide how much they believe > each level of alleged signature. By having the l= value defined, the length of the message that was signed has been make explicit, where appended notices or ads can be omitted which is the intended use of this parameter. In the case of A- R permitted cruft, the l= value allows rechecking the body hash as a simple process when the DKIM header contains both the length and the signed body hash. MUAs annotating signed messages already must exclude portions of the message not included in the hash from being annotated as having been validated by a signature from the signing domain. The MUA may also check the reputation of the signing domain and wish to assert a green/red bar. Even with the A-R header, without some means to trim off appended messages, which is the original purpose of the l= feature, recipient may confuse which message content and reputation should this apply, that of the signer or that of the provider. They may easily be confused as to who they are trusting. Those purchasing ad space may even attempt to leverage the resulting confusion. Perhaps this issue should be reviewed in a few years. Making changes now would be based upon conjecture. > I would really like to remove l= from DKIM to make it clear that it > is not a good idea to even try to guess the history of a message > based on signatures that don't verify and cover the whole message. Without the l= feature, annotations based upon DKIM may prove uncertain whenever providers are lax at applying notifications or advertisements. It is purely guesswork as to how this situation might be best resolved. It seems appropriate to make statements about any attempt at message annotations covering all portions of a message based solely upon A-R headers. I don't think there is any burning need to add additional cautions about the use of the l= parameter. It seems such effort is aimed at allowing sloppy and likely dangerous annotation practices. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
>> DKIM is too complicated as it is, and it strikes me as an extremely poor >> idea to add yet more cruft to work around perverse situations that are as >> yet (and probably always) entirely hypothetical. > > I don't understand what "cruft" you think I'm talking about. Telling people that it is reasonable to add a chain of A-R headers to messages with broken signatures, and expecting recipients to apply some ill defined algorithm to decide how much they believe each level of alleged signature. I would really like to remove l= from DKIM to make it clear that it is not a good idea to even try to guess the history of a message based on signatures that don't verify and cover the whole messag. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
Barry Leiba wrote: >> DKIM is too complicated as it is, and it strikes me as an extremely poor >> idea to add yet more cruft to work around perverse situations that are as >> yet (and probably always) entirely hypothetical. > > I don't understand what "cruft" you think I'm talking about. Nothing > in my message needs anything added to DKIM, and no one is suggesting > removing anything from DKIM that will invalidate what my message said. Anybody who says that "DKIM is too complicated" has no perspective on internet protocols. SMTP, SIP, IKEv1 qualify as "too complicated". Would that all internet protocols were as "complicated" as DKIM. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
> DKIM is too complicated as it is, and it strikes me as an extremely poor > idea to add yet more cruft to work around perverse situations that are as > yet (and probably always) entirely hypothetical. I don't understand what "cruft" you think I'm talking about. Nothing in my message needs anything added to DKIM, and no one is suggesting removing anything from DKIM that will invalidate what my message said. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
> If you're going to send a message on and are not going to break the > signature, you do one of these: Sign or don't sign, it works fine either way. > If you're going to send a message on and ARE going to break the > signature, you do this: You're a mailing list, so filter, sign and earn your own reputation. DKIM is too complicated as it is, and it strikes me as an extremely poor idea to add yet more cruft to work around perverse situations that are as yet (and probably always) entirely hypothetical. How likely is it that a mail setup that break signatures will add all sorts of code to support DKIM, check incoming signatures, add A-R headers, and resign them, but won't filter and sign like a mailing list does? This is the kind of arcane situation for which the correct advice is "don't do that." R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
> Chaining signatures with Authentication-Results is unlikely to work, > since with two or more levels of chaining, there is no reliable way to > tell which A-R header goes with which signature. Chaining isn't the point. And mailing lists aren't the only forwarders (I agree with what you say about mailing lists). My address, at computer.org, is a forwarder. When the mail gets to my real mail server, it doesn't filter based on computer.org, but based on the original sender, of course. Now, computer.org won't break any DKIM sig that's already there, so there's no worry. But suppose it did. The model is this: If you're going to send a message on and are not going to break the signature, you do one of these: 1. do nothing to A-R or DKIM-Sig records that are there, and do not sign yourself, OR 2. do nothing to A-R or DKIM-Sig records that are there, and add your own sig. Your sig does NOT cover A-R. If you're going to send a message on and ARE going to break the signature, you do this: 1. verify all previous sigs, creating your own A-R in the process, then 2. remove all previous sigs AND all previous A-R, then 3. put in your own A-R, then 4. DKIM-sign the message, having the sig cover your A-R. If the process works like that, the verifier has exactly one signature that covers the authentication results, so it knows where they came from. It can use that extra information or not, as it chooses. We can argue about whether the information is useful in that case, but it's the verifier's choice. And it means that you don't leave signatures around that YOU broke, so if I get "one good signature and a bunch of broken signatures", it means the signatures were broken for some other reason. (I probably don't care about that, I'm just saying) > A-R can be useful in some very narrow circumstances, where the channel > between the agent that applies the header and the agent that uses it > is secure. The most likely setup is that it's applied as the message > is dropped into a mailbox on a server, and it's used by a MUA or local > filtering proxy that picks up the message via POP or IMAP. As I describe things above, A-R can be useful in more situations than that. If you (the verifier, the MUA, whatever) trusts the signer that signed the A-R, you have information you can use. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
>But it wasn't. The FUD was actually increased, because the DKIM-Signature >that was added doesn't cover the Authentication-Results header. Chaining signatures with Authentication-Results is unlikely to work, since with two or more levels of chaining, there is no reliable way to tell which A-R header goes with which signature. But since it is a Fundamentally Bad Idea, it doesn't matter, and there is no security issue to fix. If a message has one good signature and a bunch of broken signatures, as will generally be the case here, you ignore the broken ones and use the good one to evaluate the message. Everybody I know filters list mail based on the identity of the list, not the identity of the contributors, they have ever since there has been mail filtering, and there is no reason to expect that to change in the future. I am baffled that people have wasted so much effort on broken non-solutions to a non-existent problem. A-R can be useful in some very narrow circumstances, where the channel between the agent that applies the header and the agent that uses it is secure. The most likely setup is that it's applied as the message is dropped into a mailbox on a server, and it's used by a MUA or local filtering proxy that picks up the message via POP or IMAP. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
