Re: [ietf-dkim] detecting header mutations after signing
A) You have to sign either all occurences of a header or none of them, ... B) Same as A, but limited to an enumerated set of headers that are supposed to occur only once. c) Same as B, but tell signers to use the h= trick to make verification fail if extra headers show up. Realistically useful advice probably has to influence rendering of messages. That might mean MUA participation or it might mean mailstore participation that removes all (typically) rendered headers that are unsigned. Gosh, I hope not. I'd like DKIM to be sturdy enough that I can trust stuff signed by people I know and not have to backstop it by tricks elsewhere to defend against malicious changes that DKIM didn't notice. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John R. Levine: a) Author creates a 100% compliant message b) Signer signs 100% compliant message c) Bad guy adds an extra header, making it non-compliant, and sends it to someone ... Mike, I only have vague recollection of the h= trick anymore... You list all the headers you sign in h= list, and you can include headers that don't exist, which means that they can't exist when verified either. So for a header that occurs N times, you can list it N+1 times in h= to ensure that more aren't added. The original motivation was usually N=0 to avoid games played by adding MIME headers to messages that don't have them, but it's generally applicable. With this signer-side configuration solution, the verifier can detect attempts to spoof any header that was covered by the DKIM signature (spoof as in add a forged header, and hope that naive programs will use the forged header instead of the authentic one). So the solution is already available in DKIM. We just need to use the solution, and make it part of routine DKIM tests. Having the signer put the extra junk in h= should make existing verifiers do the right thing, although I doubt the bit of verification code that checks for the non-existence of the N+1st header for N0 is well tested in DKIM implementations. To address this, make this solution part of routine DKIM test suites. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Fwd: Re: THIS IS A MULTIPLE 5322.FROM MESSAGE
On Thu, 07 Oct 2010 17:09:14 +0100, Michael Thomas m...@mtcc.com wrote: I'm with Steve on this one. Forcing implementations of DKIM to determine whether a message is compliant is a pretty high bar. ... How can you claim it is a high bar when clearly it isn't.? All that the implementor of a verifier has to do is: 1: Construct a list of all the RFC5322 headers which can occur at most once. FYI, that is Orig-Date, From, Sender, Reply-To, To, Cc, Bcc, Nessage-ID, In-Reply-To and References. For good measure, add the once-only headers defined in all the other RFCs that you can locate (which would give you, for a start, MIME-Version, Content-Type and Content-Transfer-Encoding). 2. Your implementation already needs to scan all the headers in order to identify the ones it needs to hash in order to verify the signature. It is a pretty trivial addition to count the occurrences of each one mentioned in the h= tag as part of your scan, and to check whether any of the ones in the list have occured twice. ... I for one wouldn't be in any particular big hurry to add a batch of code to insure that that MUST was fulfilled. I doubt anyone else would be either. The net effect of this MUST would be to make a lot of compliant DKIM implementations non-compliant. And for what? Yes, existing verifiers will become non-compliant, but that will not cause the sky to fall in overnight. They will still continue to verify as at present, but they will also remain vulnerable to the scam that has been identified, which should be a pretty good incentive to get them fixed ASAP. I'd say that it would be better to just say that if you sign a non-compliant 5322 message that its verification is undefined, and move on. That at least matches reality, and hasn't hurt anything that I'm aware of. And that indicates that you have not realised the nature or the significance of this scam. Let me describe it again. 1. A phisher creates a throwaway domain, e.g. ebay.phish.com. 2. He creates a signing key for his domain, and advertises the key in the usual manner. 3. For good measure, he might also create an ADSP discardable policy for his domain, just to give an added air of respectability. 4. He then creates and sends emails of the following form: From: i...@ebay.com Subject: Your ebay account is about to expire DKIM-Signature: d=ebay.phish.com; h=From,Subject,...; From: i...@ebay.phish.com . Typical phish requesting Password, etc. 5. Note that the phisher signs it with his own key (and it is the 2nd From that gets hashed). All current verifiers that are strictly compliant with RFC4871 will report the signature as valid (except for the few that have already been patched by people aware of the scam). 6. Many, if not most, current MUAs will show only the first signature From: i...@ebay.com 7. The email never goes anywhere near ebay, so their signing practices are irrelevant. There is absolutely nothing that ebay can do to prevent 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] detecting header mutations after signing
Michael Thomas wrote: On 10/07/2010 05:01 PM, John R. Levine wrote: Nobody has signed a non-compliant message, so while there is nothing wrong with Mike's advice, it completely misses the point. You're right, it does miss the point. What I'm trying to get my head around is whether this is a real problem in the real world. Not yet, but this has a higher risk of occurrence in the future than let's say, SHA1 exploits which required us to incorporate SHA256 into the options mix. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Wietse Venema wrote: With this signer-side configuration solution, the verifier can detect attempts to spoof any header that was covered by the DKIM signature (spoof as in add a forged header, and hope that naive programs will use the forged header instead of the authentic one). So the solution is already available in DKIM. We just need to use the solution, and make it part of routine DKIM tests. Having the signer put the extra junk in h= should make existing verifiers do the right thing, although I doubt the bit of verification code that checks for the non-existence of the N+1st header for N0 is well tested in DKIM implementations. To address this, make this solution part of routine DKIM test suites. +1, however. This is only part of the solution. A temporary one to allow current operators to cover themselves using their Required Header configuration, if any. The real solution is to void double 5322.From messages. Either the DKIM compliant MSA, MDA do it or the better DKIM signer/verification engine does it to cover for legacy MSA, MDA or to make sure customers using a 3rd party signing engine are sending the proper mail to sign. Can someone come up with IETF amenable copy text for Dave to add to 4871bis that won't prohibit or slow it down its progress? IMV, all would be implementers need to read is a basic idea of: Make sure there are no two or more 5322.From headers when signing or verifying. These messages should be voided. and thats it. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Thu, 07 Oct 2010 19:18:19 +0100, Michael Thomas m...@mtcc.com wrote: The larger issue here is would anybody rush out to close this MUST. I think that it is highly unlikely that anybody is going to care at this point. That goes for *any* new MUST, IMO: unless it's really a serious protocol endangering problem, it shouldn't be in the -bis document. Save new MUST's for genuine emergencies. But it IS a serious protocol endangering problem. -- 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] detecting header mutations after signing
On 08/Oct/10 07:00, John R. Levine wrote: Having the signer put the extra junk in h= should make existing verifiers do the right thing, although I doubt the bit of verification code that checks for the non-existence of the N+1st header for N0 is well tested in DKIM implementations. +1, and the revised example proposed by Julian can be enough. The whole discussion on multiple Froms then boils down on whether it is worth to change the protocol so that, for example, h=from:subject:date:message-id:to MUST be interpreted by the verifier to mean h=from:from:subject:subject:date:date:message-id:message-id:to:to, a handy abbreviation for known fields. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Friday, October 08, 2010 8:34 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing The whole discussion on multiple Froms then boils down on whether it is worth to change the protocol so that, for example, h=from:subject:date:message-id:to MUST be interpreted by the verifier to mean h=from:from:subject:subject:date:date:message-id:message-id:to:to, a handy abbreviation for known fields. I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Dave CROCKER: On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Friday, October 08, 2010 12:33:38 pm Dave CROCKER wrote: On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? d/ Detecting modification in transit is outside the scope of what DKIM is trying to achieve? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Friday, October 08, 2010 10:01 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? Detecting modification in transit is outside the scope of what DKIM is trying to achieve? Doesn't DKIM try to detect modification of the portion covered by the hashes, which is unchanged in this scenario? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. The standard advice has always been to accept malformed mail and render it as best you can, on the theory that it was probably from a legit but buggy sender. Other than this DKIM issue, that's still good advice. Here's another way to look at it: if we think that adding extra headers is a significant threat, someone's going to have to check for them. History suggests that in the absence of DKIM, it's not worth doing since nobody does it. That also suggests that all the places other than a DKIM verifier will continue not to do it, since it's still of no great benefit. So if we don't do it in the verifier, it's not going to happen. Our software works, but you have to make changes of no direct benefit to yourself to plug a hole we could have plugged has rarely been a winning argument in the past. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Friday, October 08, 2010 01:41:15 pm Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Friday, October 08, 2010 10:01 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? Detecting modification in transit is outside the scope of what DKIM is trying to achieve? Doesn't DKIM try to detect modification of the portion covered by the hashes, which is unchanged in this scenario? For what I view as a very abstract definition of unchanged, sure. I think adding additional From or Subject does change the content of the message From or Subject. If one takes the view that we've defined things such that this is OK from a protocol definition perspective, so it's not an issue, I think we've lost sight of the original goal of this requirement in the protocol. I think that this can be dealt with through an additional security consideration and doesn't have to disrupt the rush to get this advanced through the standards process. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 08/Oct/10 18:33, Dave CROCKER wrote: On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I don't know of a precedent standard, but I recall of an MTA that did bother to enforce normative portions. Users periodically complained, because it is not quite practical to not be liberal in what we accept. The best of users' protests that I recall was No, just to deliver mail rather than being a pedantic-mode SMTP debugger. [http://www.mail-archive.com/courier-us...@lists.sourceforge.net/msg16896.html] I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? Hmm... it is only theoretical until it becomes productive to put it into practice, and at that point it will be too late. No doubt most of us will update their to-be-signed field lists during the next few weeks. However, introducing what I called a handy abbreviation would be a source of confusion. When h=from:from will be automatically assumed by verifiers on seeing h=from, will we still have to specify h=from:from in case we hit an older verifier? Otherwise, just to be safe, we may end up with h=from:from; h2=from; :-/ In addition, the current style of the DKIM specs doesn't dig into the meaning of fields. Rather than being layered on top of 5322, DKIM looks parallel to it: In case one does sign multiple Froms --as it happened upthread-- the resulting signature looks unambiguously valid. If anything is undefined, it is the 5322 semantics, not that of 4871. Introducing knowledge of what fields may occur what number of times would alter that style. Why not also take into account MIME preambles and epilogues, then? After all, I'd keep that handy abbreviation for a revised canonicalization, whenever it will come. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Wietse Venema wrote: If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. It depends on the Application implementation of DKIM. How are you doing it or offering DKIM signer configuration in postfix? Do you have a Required Headers to sign operation option? Let me give you a summary background of events leading up to this. We began to finally go full steam with DKIM integration into our integrated mail framework. I had explored the 2006 revision of the Alt-N open source API to explore all this, and to begin the effort in earnest, I upgraded the API to latest 2009 version which included ADSP support. There were one thing I noticed when I did a diff between the two API versions. The one that stood out was a new signer options: int nAllowUnsignedFromHeaders; // 0 = From headers not included in the // signature are not allowed, 1 = allowed Note I wasn't aware of this multiple from issue yet, so I presumed this was an implementator field experience after three years with a need to relax the RFC 4871 requirement to hash the 5322.From. After all, with the direction to disassociate the author and signer, it felt that was all part of it. There was another related header hashing option that was both in the old and new versions: char szRequiredHeaders[256]; // colon-separated list of headers that // must be signed The API also provides a callback where it passes each 5322 header as it parsed the 5322 message where it wants a TRUE or FALSE function response. This allows an application to prepare a callback to determine what specific headers to sign. The difference is: With a CALL BACK, application be be specific with the headers to sign and only these headers appear in the tag h= values list. With szRequireHeaaders defined, it was not exclusive but added headers that by default the API didn't sign. In other would, by default, the signing function signed ALL headers excluding X-* Authentication-Results: Return-Path: Using szRequiredHeader, would allow you to sign other headers not already signed. But for the application which imports the API into a p-code language for SMTP receiver (verify) and SMTP router (signing) shimming, I could not use the call back method and I needed a way to give operators a configuration method way to allow them which headers should be signed. So I added an option: int nUseRequiredHeadersOnly; // 1 - used szRequireHeaders and exclude the rest which says if szRequiredHeaders is set, then only those headers are signed. I then ask Alt-N about the nAllowUnsignedFromHeaders feature and to inform them if the change I made with nUseRequiredHeadersOnly. That is why I found out why they needed nAllowUnsignedFromHeaders because a customer incident reported the multiple 5322.From issue. I was able to confirm this and I traced the logic of nAllowUnsignedFromHeaders and saw that it doesn't stop multiple 5322.From (N) but rather it enforces that each one was included in the h= tag. So while the trick to add N+1 from values to the h= tag would help mitigate this, we don't know if most applications give an operators option to set the exclusive headers to sign. I did because I wanted to explore different h= headers signing setup especially with integrated list operations. For example, the operator configuration default: #- # Signing Options for author-domain section # # Possible values for canon= # # DKIM_CANON_SIMPLE # DKIM_CANON_NOWSP # DKIM_CANON_RELAXED # DKIM_SIGN_SIMPLE # DKIM_SIGN_SIMPLE_RELAXED # DKIM_SIGN_RELAXED # DKIM_SIGN_RELAXED_SIMPLE # # [AUTHOR-DOMAIN] # signer = SIGNER-DOMAIN# this is the signature d= tag # selector = SELECTOR # this is the signature s= tag # Canon = DKIM_SIGN_SIMPLE # canonization # IncludeBodyLengthTag = 0 # opt, 1 - include l= tag body size # IncludeTimeStamp = 1 # opt, 1 - include t= tag timestamp # IncludeQueryMethod = 0 # opt, 1 - include q= tag # Hash = 1 # req, 1 - SHA1, 2 - SHA256 # IncludeCopiedHeaders = 0 # opt, 1 - use z= tag # Identity =# opt, i= tag # ExpireTime = 0 # opt, days, adds x= tag # UseRequiredHeadersOnly = 1 # opt, 1 - used szRequireHeaders # RequiredHeaders= From:To:Date:Message-Id:Organization:Subject:List-ID
Re: [ietf-dkim] detecting header mutations after signing
Scott Kitterman wrote: Murray S. Kucherawy wrote: Doesn't DKIM try to detect modification of the portion covered by the hashes, which is unchanged in this scenario? For what I view as a very abstract definition of unchanged, sure. I think adding additional From or Subject does change the content of the message From or Subject. If one takes the view that we've defined things such that this is OK from a protocol definition perspective, so it's not an issue, I think we've lost sight of the original goal of this requirement in the protocol. I think that this can be dealt with through an additional security consideration and doesn't have to disrupt the rush to get this advanced through the standards process. +1. Well, then again, one side of my is trying to be cooperative and sensitive of those who want to rush the document. Minimize text with not saying too much. But the other side is saying technically Fix this ASAP - get the proper protocol semantics in in the 4871bis specs and use this incident or at least prepare a response ready against any negative PR that could emerge as a plus to enhancing the marketability of DKIM as a tool that helps solved a 25+ year old problem. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. It depends on the Application implementation of DKIM. What I describe would be a best practice application of DKIM mechanisms that already exist. Mail is signed as if there are N+1 instances of each header that is covered by the DKIM signature. The verifier will then fail if any such header is added after-the-fact. With this, there is no need to rely on enforcement mechanisms outside DKIM, such as the correct implementation of RFC 5322. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Wietse Venema Sent: Friday, October 08, 2010 1:16 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing What I describe would be a best practice application of DKIM mechanisms that already exist. Mail is signed as if there are N+1 instances of each header that is covered by the DKIM signature. The verifier will then fail if any such header is added after-the-fact. With this, there is no need to rely on enforcement mechanisms outside DKIM, such as the correct implementation of RFC 5322. I would suggest constraining that to include only those fields that are 0-or-1 in RFC5322 Section 3.6. For example, doing this with Received: is begging for signature invalidation on otherwise unaltered messages. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Wietse: What I describe would be a best practice application of DKIM mechanisms that already exist. Mail is signed as if there are N+1 instances of each header that is covered by the DKIM signature. The verifier will then fail if any such header is added after-the-fact. With this, there is no need to rely on enforcement mechanisms outside DKIM, such as the correct implementation of RFC 5322. Murray S. Kucherawy: I would suggest constraining that to include only those fields that are 0-or-1 in RFC5322 Section 3.6. For example, doing this with Received: is begging for signature invalidation on otherwise unaltered messages. I see your point, but there are more sensitive headers than the 0-or-1 headers in RFC 5322 (IIRC, the N+1 signing method was introduced to protect MIME headers). I suppose that the guidelines for best practice application of DKIM could recommend what headers to sign with the N+1 signing method. These guidelines can be updated as RFC 5322 evolves, and as standards that extend RFC 5322 introduce new sensitive headers. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Wietse Venema Sent: Friday, October 08, 2010 1:26 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Dave CROCKER: On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. Wietse Whether this is the correct solution or not, I want to thank everyone from moving away from kick the can somewhere else to discussing the issue with a view to resolving the problem. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Hence my original post with the suggested special consideration text for section 5.4 in regards to 5322.from. -- HLS Wietse Venema wrote: Wietse: What I describe would be a best practice application of DKIM mechanisms that already exist. Mail is signed as if there are N+1 instances of each header that is covered by the DKIM signature. The verifier will then fail if any such header is added after-the-fact. With this, there is no need to rely on enforcement mechanisms outside DKIM, such as the correct implementation of RFC 5322. Murray S. Kucherawy: I would suggest constraining that to include only those fields that are 0-or-1 in RFC5322 Section 3.6. For example, doing this with Received: is begging for signature invalidation on otherwise unaltered messages. I see your point, but there are more sensitive headers than the 0-or-1 headers in RFC 5322 (IIRC, the N+1 signing method was introduced to protect MIME headers). I suppose that the guidelines for best practice application of DKIM could recommend what headers to sign with the N+1 signing method. These guidelines can be updated as RFC 5322 evolves, and as standards that extend RFC 5322 introduce new sensitive headers. Wietse ___ 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
[ietf-dkim] Inadvertent Spoof
Jeff Macdonald wrote: Hence my original post with the suggested special consideration text for section 5.4 in regards to 5322.from. -- My apology to Jeff. It was not Jeff Macdonald who wrote the text above. This was not an attempt at a spoof. I somehow replied to the wrong message and my MUA (ThunderBird) somehow used the wrong From: address with the text I was writing. My Apology to Jeff. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
With this, there is no need to rely on enforcement mechanisms outside DKIM, such as the correct implementation of RFC 5322. I would suggest constraining that to include only those fields that are 0-or-1 in RFC5322 Section 3.6. For example, doing this with Received: is begging for signature invalidation on otherwise unaltered messages. Signed Received headers at all is asking for trouble, but I take your point. So here's a 0th cut at a list of headers where we should recommend N+1 entries in the h= rfc 5322 From Sender Reply-To (maybe not, since often smashed by mailing lists) To Cc(not Bcc even though it's 0/1) Message-ID Subject Date rfc 4021 MIME-Version Content-Type R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
