Re: [ietf-dkim] DKIM and patents
On Sat, Oct 16, 2010 at 02:54:13PM +1200, Franck Martin allegedly wrote: I found today this patent: US PATENT 7487217 http://www.docstoc.com/docs/57449330/Network-Domain-Reputation-based-Spam-Filtering---Patent-7487217 but then it seems prior art existed in the form of DKIM (which was started around 2004 http://news.domainmonster.com/dkim-email/) DKIM largely derives from DomainKeys which largely derives from US Patent 6,986,049 filed in Sep 2003. In 2004 the IPR was bequeathed to the IETF by the Assignee (aka my employer at the time). See: https://datatracker.ietf.org/ipr/693/ and http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=%2Fnetahtml%2FPTO%2Fsearch-bool.htmlr=9f=Gl=50co1=ANDd=PTXTs1=delany.INNM.OS=IN/delanyRS=IN/delany Given the timing, clearly the 2005 filing of 7,487,217 you mention cannot encroach on the prior filings of DomainKeys. If anything it's around the other way as 6,986,049 could invalidate 7,487,217. But, IANAL and I never want to be one. I am just stating known facts here. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and patents
US PATENT 7487217 http://www.freepatentsonline.com/7487217.html but then it seems prior art existed in the form of DKIM (which was started around 2004 http://news.domainmonster.com/dkim-email/) This isn't a patent about authentication, it's about spam filtering using the reputation of domains associated with mail. Since it's from Microsoft, the description uses Sender ID but the claims, which are what counts, are phrased more generally. It was filed in 2005, so offhand I don't know how hard it would be to find earlier discussions of reputation based filtering. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] sophistry is bad, was Data integrity claims
Yes, it ties an identifier to a bag of bits, and yes it specifies what those bits are, but it really does deal only with those bits and not (necessarily) the entire message. Technically. you are correct. Semantically, that's silly. We went through backflips trying to figure out how to design the signatures so that the message modifications they allowed would preserve the same message, for an ill defined but I think well understood version of the same. While it's always been possible to sign messages in ways that allow gross changes, e.g. don't sign the subject or MIME headers, set l=0, if you sign a message using a normal set of options, the idea was always that the message the recipient saw would be the one you signed. Throwing up our hands at the double header trick is, one might say, ahistoric. Claiming it's an MUA problem is simply wrong. For the umpteenth time, we don't need to change the bits on the wire for a valid signed RFC 5322 message. But we really need to give some advice about how to defend against it. Jim's proposed language with SHOULD seems right to me. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] sophistry is bad, was Data integrity claims
On 10/16/2010 10:26 AM, John R. Levine wrote: Yes, it ties an identifier to a bag of bits, and yes it specifies what those bits are, but it really does deal only with those bits and not (necessarily) the entire message. Technically. you are correct. Semantically, that's silly. We went through backflips trying to figure out how to design the signatures so that the message modifications they allowed would preserve the same message, for an ill defined but I think well understood version of the same. Yes that was the goal. No that was not the result. Which header fields are essential to protect? How much of the message body is essential to protect? The current DKIM spec does not answer these questions and easily permits protecting very little of the message. Almost certainly too little to ensure the protection you assert. That's an example of what I mean when I says that there are assumptions about DKIM that go beyond what it (always) delivers. I guess I should thank you for demonstrating my point. While it's always been possible to sign messages in ways that allow gross changes, e.g. don't sign the subject or MIME headers, set l=0, if you sign a message using a normal set of options, the idea was always that the message the recipient saw would be the one you signed. Throwing up our hands at the double header trick is, one might say, ahistoric. Claiming it's an MUA problem is simply wrong. 1. Your first sentence concedes my basic point 2. There is no commonly-agreed upon and documented concept of normal set of options that I'm aware of. What is normal for you might or might not be normal for the next person configuring DKIM. 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] sophistry is bad, was Data integrity claims
On 10/16/10 4:50 PM, Dave CROCKER wrote: On 10/16/2010 10:26 AM, John R. Levine wrote: Yes, it ties an identifier to a bag of bits, and yes it specifies what those bits are, but it really does deal only with those bits and not (necessarily) the entire message. Technically. you are correct. Semantically, that's silly. We went through backflips trying to figure out how to design the signatures so that the message modifications they allowed would preserve the same message, for an ill defined but I think well understood version of the same. Yes that was the goal. No that was not the result. Which header fields are essential to protect? How much of the message body is essential to protect? The current DKIM spec does not answer these questions and easily permits protecting very little of the message. Almost certainly too little to ensure the protection you assert. That's an example of what I mean when I says that there are assumptions about DKIM that go beyond what it (always) delivers. I see your point. But there is a big difference between a) the assumption that DKIM always protect an entire message (which it obviously does NOT) and b) the assertion that DKIM delivers some basic functionality + can be used in different modi operandi These modi operandi, which probably need to be worked out in the deployment documents (not in 4871bis) enable organizations to use DKIM (among others) to protect specific parts of a message, which can be very interesting for some organizations, as it won't require a complex PKI to deploy. Another (important) use case will be using DKIM as an enabler for reputation services. And there will probably be more use cases for DKIM. I guess I should thank you for demonstrating my point. While it's always been possible to sign messages in ways that allow gross changes, e.g. don't sign the subject or MIME headers, set l=0, if you sign a message using a normal set of options, the idea was always that the message the recipient saw would be the one you signed. Throwing up our hands at the double header trick is, one might say, ahistoric. Claiming it's an MUA problem is simply wrong. 1. Your first sentence concedes my basic point 2. There is no commonly-agreed upon and documented concept of normal set of options that I'm aware of. What is normal for you might or might not be normal for the next person configuring DKIM. Right, this is in line with what I wrote above, about different kinds of DKIM use. So let's not confuse things: DKIM itself does not provide a useful minimum protection but can be used by applying the right parameters and configuration to protect specific parts of a message (after all, S/MIME and PGP also provide only protection of part of a message). /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
SM wrote: You can tell me if I am wrong here cause I am trying to make sure I It is not up to me to determine whether you are wrong. :-) From an IETF procedural angle. :) 1) Verifier TXT record parsing I checked for this, but did not find it, but was a quick scan. If the DKIM specs says that verifiers MUST be ready for different TXT records merged in the DNS Query response, it MUST parse for the string v=DKIM1 If this is the case, then I don't think we need to add anything. Its all good. That tag isn't always included in the DNS record for backward compatibility with DomainKeys. And it is optional. As you are doing a query for a TXT RR, expect garbage. However, in my personal engineering opinion, it probably should add a note for verifiers to be ready for multiple string responses. From RFC 3833: Much discussion has taken place over whether and how to provide data integrity and data origin authentication for wildcard DNS names. Conceptually, RRs with wildcard names are patterns for synthesizing RRs on the fly according to the matching rules described in section 4.3.2 of RFC 1034. While the rules that control the behavior of wildcard names have a few quirks that can make them a trap for the unwary zone administrator, it's clear that a number of sites make heavy use of wildcard RRs, particularly wildcard MX RRs. Regards, -sm The difference is that MX records are well structured fixed RR records, where merged TXT records have a multi-technology mix with multiple non-fixed structured definitions. So the client has to be aware of all of them or be savy enough to look for what for what it wants. But my question was: If 4871 does not speak of requiring the DKIM client of parsing merged TXT records to look for its specific inputs, then section 3.6.2.1 needs to make up for this dearth of verifier design information. I ask because in Murray's suggested text: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. I like it, but from an IETF standpoint, doesn't the last sentence imply a 'change of code' thing that we try to avoid here? I think the way it is stated was design to avoid this. Right? -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Saturday, October 16, 2010 2:39 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Data integrity claims On Sat, Oct 16, 2010 at 12:10:48AM -0400, Dave CROCKER allegedly wrote: On 10/15/2010 8:32 PM, Mark Delany wrote: Therefore one could argue that DKIM is protecting that relationship between the message and identifier. Clever phrasing. Might be too subtle for general use, but I think it offers a perspective that could be useful. I think the issue here is that when people talk about protecting a message, they tend to have in mind all sorts of attacks designed to trick users. DKIM actually does not have much to say about such things. Yes, it ties an identifier to a bag of bits, and yes it specifies what those bits are, but it really does deal only with those bits and not (necessarily) the entire message. I have a problem with this approach and I don't pretend to know the right answer. My problem is that if some valuable domain like paypal sends me a bunch of bits that I or my MUA or my MTA ties to paypal.com then the end goal of DKIM is, IMO, that those bunch of bits I see are the ones that paypal sent. No more, no less. To murder another idiom: What you see is what they sent is I believe the ultimate goal of DKIM. Or, what you complain about is what they sent. Whatever. So anything that circumvents what you see is what they sent I think is in scope for DKIM to eliminate or mitigate. Is that requirement solved in the verification protocol of DKIM or is that solved in advice to MTAs/MUAs? I don't know. But I am sure that if we don't end up with that guarantee, then I do wonder what we are offering. Mark is more clearly articulating what I have been struggling with. This is also one of the reasons I have always felt that 1st party signatures are inherently a different value proposition from 3rd party signatures. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] sophistry is bad, was Data integrity claims
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Saturday, October 16, 2010 10:50 AM To: John R. Levine Cc: DKIM List Subject: Re: [ietf-dkim] sophistry is bad, was Data integrity claims On 10/16/2010 10:26 AM, John R. Levine wrote: Yes, it ties an identifier to a bag of bits, and yes it specifies what those bits are, but it really does deal only with those bits and not (necessarily) the entire message. Technically. you are correct. Semantically, that's silly. We went through backflips trying to figure out how to design the signatures so that the message modifications they allowed would preserve the same message, for an ill defined but I think well understood version of the same. Yes that was the goal. No that was not the result. Which header fields are essential to protect? How much of the message body is essential to protect? The current DKIM spec does not answer these questions and easily permits protecting very little of the message. Almost certainly too little to ensure the protection you assert. That's an example of what I mean when I says that there are assumptions about DKIM that go beyond what it (always) delivers. I guess I should thank you for demonstrating my point. While it's always been possible to sign messages in ways that allow gross changes, e.g. don't sign the subject or MIME headers, set l=0, if you sign a message using a normal set of options, the idea was always that the message the recipient saw would be the one you signed. Throwing up our hands at the double header trick is, one might say, ahistoric. Claiming it's an MUA problem is simply wrong. 1. Your first sentence concedes my basic point 2. There is no commonly-agreed upon and documented concept of normal set of options that I'm aware of. What is normal for you might or might not be normal for the next person configuring DKIM. d/ -- Dave, This is disingenuous on your part. It is akin to saying that although the common usage of hammers is to hit nails, we must accept within the definition of normal the usage of beating people on the head with a hammer simply because some people do and it is not documented through warnings on hammers that this is not normal. There is a subset of headers that the vast majority of informed (even semi-informed) implementers would agree on. Perhaps we need to reach a consensus and document this to protect the children. Mike ___ 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 15, 2010 5:10 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing MH Michael Hammer (5304): -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Friday, October 15, 2010 11:59 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I'm sure this was discussed before, but perhaps a refresher helps. How would the DKIM validator know the difference between: A: The message had a valid signature, but it was broken after signing. B: The message is a forgery with a bogus signature. If the DKIM validator cannot make that distinction, then the bad guys will do B and the validator will treat it as A. Wietse Multiple headers are a specific class of problem. The signature is not, in fact, broken. It validates. The described attack actually leverages this. We are left in the realm of the operation was a success but the patient died. If this where we want to be? How often do we see multiple From headers where the From was added (as opposed to the original From was modified) after the message was signed? How often do we see this without malicious intent in the wild? Same question for other headers? What is the value proposition that DKIM offers that incentivizes people to adopt it? I remember similar discussions back in the 2004 timeframe when we didn't have practical experience with DKIM. This theme was in fact touched on at the Marketing DKIM dinner that Dave organized after the FTC workshop in DC. I am not suggesting that we boil the ocean. I am suggesting that we can realistically address this class of problem without having to fix the world. Failure to address it significantly alters the value proposition of DKIM. in a negative manner. I've never been happy with the choice to have fails to validate == no signature. This is what invites your question about A or B. Your question A begs the question of how the signature was broken. If we never see a certain type of brokenness in the wild in normal usage but only (potentially) see it in abusive usage, why would we not recognize and address this? Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On 10/16/2010 1:07 PM, MH Michael Hammer (5304) wrote: This is disingenuous on your part. It is akin to saying that although the common usage of hammers is to hit nails, we must accept within the definition of normal the usage of beating people on the head with a hammer simply because some people do and it is not documented through warnings on hammers that this is not normal. There is a subset of headers that the vast majority of informed (even semi-informed) implementers would agree on. Perhaps we need to reach a consensus and document this to protect the children. Wow. From sophistry to disingenuous. Today seems to be when people think that tossing in slams at motives, legitimacy and style somehow facilitates discussion. It invites all sorts of responses in kind, none of which would be constructive. And I've tossed in this comment merely to note how irritating today's vocabulary choices are and suggest folks make more judicious choices. My postings have constructive intent and serious thought behind them. The might be wrong, but they are not naive, frivolous, poorly intentioned, or any of the other things that permit superficial dismissal. Please debate them on substance; if you've missed the substance, please show the courtesy of simply asking for clarification. In any event, it's clear that at least two of you have entirely missed my point. So let's try this again, more carefully: There is a fundamental difference between saying something bad might happen versus do this specific thing to provide this specific protection. One is a generic warning. The other is a spec. The difference is not subtle. Re-read my questions. They werequite precise. The text in the spec does not provide precise answers; when it appears to provide precise answers, they were not the result of informed thought: Which header fields are essential to protect? How much of the message body is essential to protect? Let me emphasize: Most of the advice in the spec is not useful, except as basic reminders to an already-knowledgeable reader. Useful means that someone who does not already knows the answer is able to figure out the answer from the guidance that is given or the guidance tells them how to go about finding out the answer. They can't do that with what is in the spec. I don't mean we should rip out all the advice, merely that we need to distinguish between soft advice and serious, technical specification. 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] sophistry is bad, was Data integrity claims
On Saturday, October 16, 2010 10:50:25 am Dave CROCKER wrote: On 10/16/2010 10:26 AM, John R. Levine wrote: Yes, it ties an identifier to a bag of bits, and yes it specifies what those bits are, but it really does deal only with those bits and not (necessarily) the entire message. Technically. you are correct. Semantically, that's silly. We went through backflips trying to figure out how to design the signatures so that the message modifications they allowed would preserve the same message, for an ill defined but I think well understood version of the same. Yes that was the goal. No that was not the result. -1. I think we did that just fine. Which header fields are essential to protect? How much of the message body is essential to protect? This is completely orthogonal to the question. As long as a receiver can reliably determine what is protected and what is not, then the protection goal is achieved. It does not require that there is agreement on what that should be. The current DKIM spec does not answer these questions and easily permits protecting very little of the message. Almost certainly too little to ensure the protection you assert. One can also point a gun at ones own head. That doesn't make a gun a suicide device of no value for anything else. The spec does permit people to do silly things, but so what. That's an example of what I mean when I says that there are assumptions about DKIM that go beyond what it (always) delivers. Saying it's possible to use DKIM in ways that doesn't support this is not the same as saying DKIM doesn't support it. It's possible to operate any modern MTA as an open relay, but it doesn't follow that all MTAs are open relays or that they fail to protect against open relaying. I guess I should thank you for demonstrating my point. If you had one that relevant to the discussion, it's not at all clear to me what it was or how it was demonstrated. While it's always been possible to sign messages in ways that allow gross changes, e.g. don't sign the subject or MIME headers, set l=0, if you sign a message using a normal set of options, the idea was always that the message the recipient saw would be the one you signed. Throwing up our hands at the double header trick is, one might say, ahistoric. Claiming it's an MUA problem is simply wrong. 1. Your first sentence concedes my basic point 2. There is no commonly-agreed upon and documented concept of normal set of options that I'm aware of. What is normal for you might or might not be normal for the next person configuring DKIM. True, but irrelevant. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] sophistry is bad, was Data integrity claims
Far be it for me to defend Dave, but I think you two are in violent agreement. I think you misread some of Dave's comment because they were posed as rhetorical. Mike On 10/16/2010 11:56 AM, Scott Kitterman wrote: On Saturday, October 16, 2010 10:50:25 am Dave CROCKER wrote: On 10/16/2010 10:26 AM, John R. Levine wrote: Yes, it ties an identifier to a bag of bits, and yes it specifies what those bits are, but it really does deal only with those bits and not (necessarily) the entire message. Technically. you are correct. Semantically, that's silly. We went through backflips trying to figure out how to design the signatures so that the message modifications they allowed would preserve the same message, for an ill defined but I think well understood version of the same. Yes that was the goal. No that was not the result. -1. I think we did that just fine. Which header fields are essential to protect? How much of the message body is essential to protect? This is completely orthogonal to the question. As long as a receiver can reliably determine what is protected and what is not, then the protection goal is achieved. It does not require that there is agreement on what that should be. The current DKIM spec does not answer these questions and easily permits protecting very little of the message. Almost certainly too little to ensure the protection you assert. One can also point a gun at ones own head. That doesn't make a gun a suicide device of no value for anything else. The spec does permit people to do silly things, but so what. That's an example of what I mean when I says that there are assumptions about DKIM that go beyond what it (always) delivers. Saying it's possible to use DKIM in ways that doesn't support this is not the same as saying DKIM doesn't support it. It's possible to operate any modern MTA as an open relay, but it doesn't follow that all MTAs are open relays or that they fail to protect against open relaying. I guess I should thank you for demonstrating my point. If you had one that relevant to the discussion, it's not at all clear to me what it was or how it was demonstrated. While it's always been possible to sign messages in ways that allow gross changes, e.g. don't sign the subject or MIME headers, set l=0, if you sign a message using a normal set of options, the idea was always that the message the recipient saw would be the one you signed. Throwing up our hands at the double header trick is, one might say, ahistoric. Claiming it's an MUA problem is simply wrong. 1. Your first sentence concedes my basic point 2. There is no commonly-agreed upon and documented concept of normal set of options that I'm aware of. What is normal for you might or might not be normal for the next person configuring DKIM. True, but irrelevant. Scott K ___ 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] yet more sophistry, was Data integrity claims
Which header fields are essential to protect? How much of the message body is essential to protect? Your questions are noted. Other than the MUST to sign the From: header, the DKIM spec offers the technical latitide to create a totally worthless signature. I don't know anyone who disagrees with that. Since I think we're only proposing some more SHOULD advice on how to create robust signatures, I don't really see how they're relevant to the question of double signing. I don't mean we should rip out all the advice, merely that we need to distinguish between soft advice and serious, technical specification. Sorry, we also need specificity. Since we are in the process of preparing 4871bis, precisely which soft advice in 4871 should we remove? Section 1, on page 4, includes an attempt to distinguish DKIM from S/MIME. That doesn't affect signing or verification, so should we remove it? Section 1.1 has an INFORMATIVE RATIONALE saying what the signing identity doesn't mean. That doesn't affect signing or verification, so should we remove it? Section 1.2 is non-operational history about intended scaling. That doesn't affect signing or verification, so should we remove it? In section 2.6, in item 2 on page 8, the last two sentences describe a putative motivation for the first sentence. That doesn't affect signing or verification, so should we remove it? I'll let you go through the rest of the spec. R's, John smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
