Re: [ietf-dkim] "I sign everything" is not a useful policy
On 8/4/06, Michael Thomas <[EMAIL PROTECTED]> wrote: What seems abundantly clear is that the unqualified policy "I sign everthing" is not useful as is, and is most likely harmful due to differences in the way that people interpret what that statement means. I invite people for the requirements to make *precise* statements of the fully qualified meaning in their heads about "I sign everything", and preferably in a sentence or less as that is what the world is going to actually think of when they deploy this. Mike It is my opinion that in its current state "I SIGN ALL" is inferring an absolute and will most likely be treated by both senders and receivers as such. Therefore, a failure will likely be treated with extreme prejudice by the receiver regardless of this groups suggested usage and will completely undermine the senders expected value of signing in this manner. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
Mike, As the topic title is stated it is a open-ended totally mangled concept. "I sign everything" is not very clear and specific so as you saw, it is open to a wide range of interpretations and I suggested asking for a "definition" is not going to give you the result you are seeking. The commonality in all the semantics is the idea of exclusive 1st party only domain signatures versus allowing for 3rd party signatures. That's been the argument say day one with the SSP stated policy tags: ! All mail from the entity is signed; Third-Party signatures SHOULD NOT be accepted Which I labeled for ease of communications, the EXCLUSIVE signing policy. Yet, according to you, this semantic is not quite correct. It is not an exclusive policy. We made it more clear by breaking it up into two axle which many here got excited with added their own ideas for describing it, including Tony Hansen, Frank Ellerman, William, among others. In DSAP, I wrote it up as: OP=ALWAYS;3P=NEVER; All the combinations are possible with using OP vs. 3P methodology and what is really great about it is that the signer is free is to use whatever he wants and it covers ALL possible USE CASES. 4.2. DSAP Tags: op=; 3p=; From the viewpoint of the verifier, when a message is received, there are two basic pieces of signature information to be of interest when analyzing the transaction: o Original Party Signatures (OP) * never expected * always expected * optional o 3rd Party Signatures (3P) * never expected * always expected * optional When the two signature types are combines, the possible policies are listed in this following table: +=+ | op= | 3p=| Domain Policy Semantics | |=| | empty | empty | No mail expected | |-| | never | never | No signing expected | | never | always | Only 3P signing expected | | never | optional | Only 3P signing optional | |-| | always | never | OP signature expected| | always | always | Both parties expected| | always | optional | OP expected, 3P may sign | |-| | optional| never | Only OP signing expected | | optional| always | OP expected, 3P expected | | optional| optional | Both parties may sign. | +-+ -- Hector Santos, Santronics Software, Inc. http://www.santronics.com - Original Message - From: "Michael Thomas" <[EMAIL PROTECTED]> To: "IETF DKIM pre-WG" Sent: Friday, August 04, 2006 5:58 PM Subject: [ietf-dkim] "I sign everything" is not a useful policy > > What seems abundantly clear is that the unqualified policy "I sign > everthing" > is not useful as is, and is most likely harmful due to differences in > the way > that people interpret what that statement means. > > I invite people for the requirements to make *precise* statements of the > fully qualified meaning in their heads about "I sign everything", and > preferably in a sentence or less as that is what the world is going to > actually think of when they deploy this. > > Mike > ___ > 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] "I sign everything" is not a useful policy
The matrix only enumerates the possibilities, not who or why one would select those possibilities, and what they're hoping a reciever will do with the information. It's the who and why we need answers for. Mike Hector Santos wrote: Mike, As the topic title is stated it is a open-ended totally mangled concept. "I sign everything" is not very clear and specific so as you saw, it is open to a wide range of interpretations and I suggested asking for a "definition" is not going to give you the result you are seeking. The commonality in all the semantics is the idea of exclusive 1st party only domain signatures versus allowing for 3rd party signatures. That's been the argument say day one with the SSP stated policy tags: ! All mail from the entity is signed; Third-Party signatures SHOULD NOT be accepted Which I labeled for ease of communications, the EXCLUSIVE signing policy. Yet, according to you, this semantic is not quite correct. It is not an exclusive policy. We made it more clear by breaking it up into two axle which many here got excited with added their own ideas for describing it, including Tony Hansen, Frank Ellerman, William, among others. In DSAP, I wrote it up as: OP=ALWAYS;3P=NEVER; All the combinations are possible with using OP vs. 3P methodology and what is really great about it is that the signer is free is to use whatever he wants and it covers ALL possible USE CASES. 4.2. DSAP Tags: op=; 3p=; From the viewpoint of the verifier, when a message is received, there are two basic pieces of signature information to be of interest when analyzing the transaction: o Original Party Signatures (OP) * never expected * always expected * optional o 3rd Party Signatures (3P) * never expected * always expected * optional When the two signature types are combines, the possible policies are listed in this following table: +=+ | op= | 3p=| Domain Policy Semantics | |=| | empty | empty | No mail expected | |-| | never | never | No signing expected | | never | always | Only 3P signing expected | | never | optional | Only 3P signing optional | |-| | always | never | OP signature expected| | always | always | Both parties expected| | always | optional | OP expected, 3P may sign | |-| | optional| never | Only OP signing expected | | optional| always | OP expected, 3P expected | | optional| optional | Both parties may sign. | +-+ -- Hector Santos, Santronics Software, Inc. http://www.santronics.com - Original Message - From: "Michael Thomas" <[EMAIL PROTECTED]> To: "IETF DKIM pre-WG" Sent: Friday, August 04, 2006 5:58 PM Subject: [ietf-dkim] "I sign everything" is not a useful policy What seems abundantly clear is that the unqualified policy "I sign everthing" is not useful as is, and is most likely harmful due to differences in the way that people interpret what that statement means. I invite people for the requirements to make *precise* statements of the fully qualified meaning in their heads about "I sign everything", and preferably in a sentence or less as that is what the world is going to actually think of when they deploy this. Mike ___ 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] "I sign everything" is not a useful policy
On Aug 4, 2006, at 4:35 PM, Hector Santos wrote: As the topic title is stated it is a open-ended totally mangled concept. "I sign everything" is not very clear and specific so as you saw, it is open to a wide range of interpretations and I suggested asking for a "definition" is not going to give you the result you are seeking. An "I sign everything" would be perfect as a DKIM client policy. This is not very suitable for a DKIM From policy. A DKIM From policy should be little more than a list of authoritative domains with a flag that indicates whether the list is complete. All the combinations are possible with using OP vs. 3P methodology and what is really great about it is that the signer is free is to use whatever he wants and it covers ALL possible USE CASES. 4.2. DSAP Tags: op=; 3p=; This approach is clumsy when attempting to handle a list of designated signing domains that may or may not include the From domain. : ( Consider a list _is_ the policy where a period "." indicates that a list is complete. In other words, a period "." would provide the verifier a stipulation that various services such as mailing-lists or e-invites are not used. With this list, there is no need for a complex matrix of never, always, optional, or sometimes. With a list, DKIM From policy becomes: (example.com, dkim-from-policy) "DKIM-FP: ." -> No authoritative sources used. Sends no mail. (example.com, dkim-from-policy) "DKIM-FP: *.example.com, my-isp.com, my-ad-agency.com, my-other- isp.com, my-collection-agency.com, ." -> Uses the listed authoritative domains and no non-complaint services. (example.com, dkim-from-policy) "DKIM-FP: *.example.com, ." -> Only example.com and its subdomains are authoritative and no non- complaint service used. (example.com, dkim-from-policy) "DKIM-FP: my-work-domain.com, ." -> Only my-work-domain.com is authoritative and no non-complaint service used. The default: (example.com, dkim-from-policy) "DKIM-FP:" -> Uses undefined sources that may or may not sign. The recommended method for listing policy would be: (example.com, dkim-from-policy) "DKIM-FP: *.example.com" -> Only example.com and its subdomains are authoritative, but non- complaint service are also used. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
From: "Michael Thomas" <[EMAIL PROTECTED]> > The matrix only enumerates the possibilities, not who or why one > would select those possibilities, and what they're hoping a > reciever will do with the information. It's the who and why > we need answers for. Mike, You are 100% correct and if it makes it easier I will do this in more detail. If you check out the DSAP section 5, the draft does begin to offer some "who and whys". I felt from a protocol standpoint it really should not matter. The main goal with DSAP and SSP for that matter was to describe the boundary conditions. The compromise and solution here is to go thru the technical possibilities, locking them down, including removing ones we don't think is appropriate. But we would need to also document the PAIRs which will not be supported because if we don't, that opens a threat entry point for abuse. Ok, let me put my business hat on and describe the WHO/WHY for each. Of course, I will not cover all possible creative uses, but I do have a few good ideas on how they can be used, and I will submit that some that are probably not necessary or can be folded. Also, the syntax shown is for illustration. I am not locked into any specify form, but it was an agreed upon format among reviewers. Overall there are ten policies: OP=;3P=; | Empty, No Mail Policy This is for domains which are not used for email. The spectrum of users is across the board, specifically those who have a web, ftp domain or other service type but email. This will help address the spoofing of domains by bad guys using domains that were not intended for email against other DKIM-SSP compliant verifiers. OP=NEVER;3P=NEVER; | No signing expected This is for domains that fall into two possible categories; those who have no interest in DKIM and it is telling the world DO NOT expect anyone to be signing mail from these domains. This will help verifiers filter the spoofers using this domains inappropriately. In addition, it will help serve the ISP/ESP market who will begin to offer signing services. The domain may not want to pay for signing? The domain may want to turn off any ISP/ESP signing. These DOMAIN/ESP service contract ideas were covered the old mailing. If a domain is using a ISP/ESP bent on signing all mail, should this be forced down the domain throat? Of course, he can leave the ISP/ESP if he doesn't like the new ISP/ESP policy, but why lose customers if the domain doesn't want his mail signed? Just allow the domain to declare this policy and the verifiers will help protect against any DKIM spoofing. OP=NEVER;3P=ALWAYS;| Only 3P signing expected OP=NEVER;3P=OPTIONAL; | Only 3P signing optional This pair is designed for Service Bureaus, IPS or EPS who offer 3rd party signing services. The EPS/ISP may offer a free or fee base signing service targeted at local hosted domains and/or users. The business opportunities here are great. Please note that the ISP/ESP market can offer and support all policies so I won't bother to mention this market in detail again. OP=ALWAYS;3P=NEVER; | OP signature expected only This is what I call the "Exclusive Policy" for domains who do not want to have any risk whatsoever in sending an email directly to a user. ISP this is highly desirable policy across the board, I can see high-value organization taken advantage of this policy. John's lawyer, Jill's Bank, Billy's doctor in the next generation eMedical market. All these domains want 100% surviability and they will probably be more prudent on who they send this type of mail too. So they might be adding failure pre-emption methods. However, as well noted in the group, survivability may not guaranteed depending the path, the hops, etc. Thus success rate is increased as more DKIM-SSP compliant systems are adopted and they begin to honor the exclusive policy. The short term workaround is the next two policies. OP=ALWAYS;3P=ALWAYS;| Both parties expected OP=ALWAYS;3P=OPTIONAL; | OP expected, 3P may sign This are for domains who want to sign all their mail but are going to allow or may expect middle ware applications to make any corrections, if need be. Although I consider this increases the potential for unknown abuse, it also increases the survivability of the transport. OP=OPTIONAL;3P=NEVER;| Only OP signing expected, if any This policy can probably be used by a single domain who wishes to signed mail for private direct email conversations, and also use the same domain for unsigned messages for external public use (i.e. mailing list) where survivability is low. This is implementation based with the software allowing the domain to select or exclude which target domains are signed or not. OP=OPTIONAL;3P=ALWAYS; | OP may sign, 3P always expected This falls into the ISP/ESP business market I described above, in the case, the ISP/ESP has sold or has mandated an also signed concept for his system. Howe
Re: [ietf-dkim] "I sign everything" is not a useful policy
On Fri, Aug 04, 2006 at 02:58:30PM -0700, Michael Thomas allegedly wrote: > I invite people for the requirements to make *precise* statements of the > fully qualified meaning in their heads about "I sign everything", and > preferably in a sentence or less as that is what the world is going to > actually think of when they deploy this. "I sign all": Your users and my business may be harmed by accepting unverified mail claiming to originate from my domain. It is in our mutual interest for you to not deliver such mail to your users. I am an adult of voting age and accept the possibility that deliverability of my traffic may reduce as a consequence. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] "I sign everything" is not a useful policy
+1 Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Delany Sent: Friday, August 04, 2006 10:58 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy On Fri, Aug 04, 2006 at 02:58:30PM -0700, Michael Thomas allegedly wrote: > I invite people for the requirements to make *precise* statements of the > fully qualified meaning in their heads about "I sign everything", and > preferably in a sentence or less as that is what the world is going to > actually think of when they deploy this. "I sign all": Your users and my business may be harmed by accepting unverified mail claiming to originate from my domain. It is in our mutual interest for you to not deliver such mail to your users. I am an adult of voting age and accept the possibility that deliverability of my traffic may reduce as a consequence. Mark. ___ 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] "I sign everything" is not a useful policy
> "I sign all": Your users and my business may be harmed by accepting > unverified mail claiming to originate from my domain. It is in our > mutual interest for you to not deliver such mail to your users. > > I am an adult of voting age and accept the possibility that > deliverability of my traffic may reduce as a consequence. Yes, +1. This is the way I've understood the "I sign all" policy since forever. -- Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
>"I sign all": Your users and my business may be harmed by accepting >unverified mail claiming to originate from my domain. It is in our >mutual interest for you to not deliver such mail to your users. > >I am an adult of voting age and accept the possibility that >deliverability of my traffic may reduce as a consequence. If "I sign all" means anything at all, this is what it means. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] "I sign everything" is not a useful policy
Your assertion in the subject is an opinion. I find the statement below to be useful. I think we have a subtle point here. "I sign everything so please discard unsigned mail apparently from me" could be useful to recipients. Plain "I sign everything" isn't. R's, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Levine Sent: Saturday, August 05, 2006 1:41 PM To: ietf-dkim@mipassoc.org Cc: [EMAIL PROTECTED] Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy "I sign all": Your users and my business may be harmed by accepting unverified mail claiming to originate from my domain. It is in our mutual interest for you to not deliver such mail to your users. I am an adult of voting age and accept the possibility that deliverability of my traffic may reduce as a consequence. If "I sign all" means anything at all, this is what it means. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] "I sign everything" is not a useful policy
Your assertion in the subject is an opinion. I find the statement below to be useful. Thanks, Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Levine Sent: Saturday, August 05, 2006 1:41 PM To: ietf-dkim@mipassoc.org Cc: [EMAIL PROTECTED] Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy >"I sign all": Your users and my business may be harmed by accepting >unverified mail claiming to originate from my domain. It is in our >mutual interest for you to not deliver such mail to your users. > >I am an adult of voting age and accept the possibility that >deliverability of my traffic may reduce as a consequence. If "I sign all" means anything at all, this is what it means. R's, John ___ 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] "I sign everything" is not a useful policy
No point at all, that is what we are supposed to be doing here, defining policy then hashing out what that policy clearly means with a consensus of the WG. I don't want to be on a technical call 2 years from now discussing what the policy means like I had to do with WICIS. Lets set an agreeable policy, discuss what it means (like the statement below) and the write the document with the clear expectation of what it means. 1. I sign all The above means "I sign everything so please discard unsigned mail apparently from me" There, one policy statement done. Thanks, Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -Original Message- From: John L [mailto:[EMAIL PROTECTED] Sent: Saturday, August 05, 2006 7:28 PM To: Oxley, Bill (CCI-Atlanta) Cc: ietf-dkim@mipassoc.org; [EMAIL PROTECTED] Subject: RE: [ietf-dkim] "I sign everything" is not a useful policy > Your assertion in the subject is an opinion. I find the statement below > to be useful. I think we have a subtle point here. "I sign everything so please discard unsigned mail apparently from me" could be useful to recipients. Plain "I sign everything" isn't. R's, John > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Levine > Sent: Saturday, August 05, 2006 1:41 PM > To: ietf-dkim@mipassoc.org > Cc: [EMAIL PROTECTED] > Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy > >> "I sign all": Your users and my business may be harmed by accepting >> unverified mail claiming to originate from my domain. It is in our >> mutual interest for you to not deliver such mail to your users. >> >> I am an adult of voting age and accept the possibility that >> deliverability of my traffic may reduce as a consequence. > > If "I sign all" means anything at all, this is what it means. > > R's, > John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
On Aug 5, 2006, at 10:41 AM, John Levine wrote: "I sign all": Your users and my business may be harmed by accepting unverified mail claiming to originate from my domain. It is in our mutual interest for you to not deliver such mail to your users. I am an adult of voting age and accept the possibility that deliverability of my traffic may reduce as a consequence. If "I sign all" means anything at all, this is what it means. To prevent DKIM from creating delivery problems for those wanting to indicate a signing domain relationship with their From domain, "I sign all" should be couched slightly differently. Policy assertion suitable for normal use: "Listed domains sign all messages for From domain" Any message appearing to be issued directly from one of the listed domains SHOULD have a valid DKIM signature. It would be in the signing and verifying domain's mutual interest for messages with invalid signatures that are subject to this policy to not be delivered, unless they appear to be on behalf of this domain from a known reputable source. Suitable for domains that are phishing targets: "Listed domains sign all messages for From domains _and_ non- complaint services are not used" Any message from one of the listed domains MUST have a valid DKIM signature. It would be in the signing and verifying domain's mutual interest for messages with invalid signatures that are subject to this policy to not be delivered. No exceptions! -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
- Original Message - From: "John Levine" <[EMAIL PROTECTED]> To: Sent: Saturday, August 05, 2006 1:41 PM Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy > >"I sign all": Your users and my business may be harmed by accepting > >unverified mail claiming to originate from my domain. It is in our > >mutual interest for you to not deliver such mail to your users. > > > >I am an adult of voting age and accept the possibility that > >deliverability of my traffic may reduce as a consequence. > > If "I sign all" means anything at all, this is what it means. > That is what it meant since day one. There was absolutely no FOG in that view because Local policy always dictate what's acceptable or not. But if its gets a domain hint for what was expected or not expected, rest assured it will be subject to rejection with no qualms about it. As it is now, we have to accept the PAYLOAD failure and let the user decide if its BAD or GOOD. What's change? The problem? This is the bad guys' cat's meow! Fake it to you make it, random unsolicited attacks based on an unprotected DKIM "ignore failure" methodology. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
John L wrote: >> Your assertion in the subject is an opinion. I find the statement below >> to be useful. > > I think we have a subtle point here. > > "I sign everything so please discard unsigned mail apparently from me" > could be useful to recipients. > > Plain "I sign everything" isn't. Having the signer or the ssp publishes tell the evaluator what they should do with a message is not a good idea, even though it might well seem obvious what they should do. That is why my wording for 'i sign everything' is phrased rather differently than folks are bandying about in this thread. 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] "I sign everything" is not a useful policy
On Aug 5, 2006, at 4:37 PM, <[EMAIL PROTECTED]> wrote: No point at all, that is what we are supposed to be doing here, defining policy then hashing out what that policy clearly means with a consensus of the WG. I don't want to be on a technical call 2 years from now discussing what the policy means like I had to do with WICIS. Lets set an agreeable policy, discuss what it means (like the statement below) and the write the document with the clear expectation of what it means. 1. I sign all The above means "I sign everything so please discard unsigned mail apparently from me" Where "unsigned" means any mail other than DKIM signed mail which validates correctly when received by the recipient. (It seems a minor point, but several people here have asserted that mail for which the signature doesn't validate is not "unsigned"). There, one policy statement done. Well, a use case to go with it would be nice. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
On Sat, Aug 05, 2006 at 04:57:23PM -0700, Dave Crocker allegedly wrote: > > > John L wrote: > >> Your assertion in the subject is an opinion. I find the statement below > >> to be useful. > > > > I think we have a subtle point here. > > > > "I sign everything so please discard unsigned mail apparently from me" > > could be useful to recipients. > > > > Plain "I sign everything" isn't. > > > Having the signer or the ssp publishes tell the evaluator what they should do > with a message is not a good idea Why do you say that Dave? If SSP is not giving guidance/information to receivers/evaluators, who then is the target audience for SSP? And what do we want them to do with the information? An interesting twist to "telling evaluators", as you put it, is that SSP is a negative indicator. It's telling evaluators *not* to deliver unless the right conditions are met. Why would an "evaluator" be suspicious of a domain that encourages non-delivery of its own traffic when in doubt? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] "I sign everything" is not a useful policy
An invalid signature is not unsigned, but we are not discussing that policy point yet :-) Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Atkins Sent: Saturday, August 05, 2006 7:51 PM To: DKIM List Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy On Aug 5, 2006, at 4:37 PM, <[EMAIL PROTECTED]> wrote: > No point at all, that is what we are supposed to be doing here, > defining > policy then hashing out what that policy clearly means with a > consensus > of the WG. I don't want to be on a technical call 2 years from now > discussing what the policy means like I had to do with WICIS. Lets set > an agreeable policy, discuss what it means (like the statement below) > and the write the document with the clear expectation of what it > means. > > 1. I sign all > > The above means "I sign everything so please discard unsigned mail > apparently from me" Where "unsigned" means any mail other than DKIM signed mail which validates correctly when received by the recipient. (It seems a minor point, but several people here have asserted that mail for which the signature doesn't validate is not "unsigned"). > There, one policy statement done. Well, a use case to go with it would be nice. Cheers, Steve ___ 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] "I sign everything" is not a useful policy
Mark Delany wrote: >> Having the signer or the ssp publishes tell the evaluator what they should do >> with a message is not a good idea > > Why do you say that Dave? > > If SSP is not giving guidance/information to receivers/evaluators, who > then is the target audience for SSP? And what do we want them to do > with the information? > > An interesting twist to "telling evaluators", as you put it, is that > SSP is a negative indicator. It's telling evaluators *not* to deliver > unless the right conditions are met. Why would an "evaluator" be > suspicious of a domain that encourages non-delivery of its own traffic > when in doubt? The signer knows everything there is about their own behaviors. They cannot know very much about the context, needs, preferences, or much else about the evaluator. Therefore they cannot know very much about what the evaluator "should" do with a message. Seriously. SSP can be entirely useful when stated in terms of the sender's perspective. It does not need to pretend that is knows enough to give directions to an evaluator. We have done quite a good job, so far, of distinguishing statements about signing from statements about delivery or non-delivery. The issue is not whether the evaluator might be "suspicious" of a direction to perform non-delivery. It is that it crosses a line into making presumptions about the evaluator that a) the Internet technical community does not have experience with, and b) we do not need to cross. 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] "I sign everything" is not a useful policy
On Sat, Aug 05, 2006 at 06:06:59PM -0700, Dave Crocker allegedly wrote: > Seriously. SSP can be entirely useful when stated in terms of the sender's > perspective. It does not need to pretend that is knows enough to give > directions to an evaluator. Sorry for being dense, but I have to ask the question again. Who is the target audience for the "sender's perspective" if not the evaluator? Put in my blunt language. Why publish an SSP if no one listens? Dave, I know you are subtle about such things and the purposeful disconnect that is lost on me, clearly has merit to you. Can you use simple words and help me out? Of course SSP can only be advisory at best, but is their more to your perspective than that? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
Mark Delany wrote: > On Sat, Aug 05, 2006 at 06:06:59PM -0700, Dave Crocker allegedly wrote: >> Seriously. SSP can be entirely useful when stated in terms of the sender's >> perspective. It does not need to pretend that is knows enough to give >> directions to an evaluator. > > Sorry for being dense, but I have to ask the question again. Who is the > target audience for the "sender's perspective" if not the evaluator? Put in > my blunt language. Why publish an SSP if no one listens? Mark, it's ok if you are dense. It forces me to (try to) be more clear: I did not say that the evaluator should or would pay no attention to the SSP information. What I am saying is that there is a difference between telling someone what *I* do versus telling them what *they* should do. If I choose to deliver unsigned mail that purports to be from a domain that says it signs everything, but I mark it up with flashing lights that say "spoofed" do you want that to be a protocol violation? What about my choosing to send it to my sysadmin for special handling for spoofed mail? What about... In other words, there are lots of things that I might reasonably choose to do with mail that I receive that violates one or another SSP statement. It is not the publisher's right or responsibility to tell me what to do with information. By contrast it is entirely reasonable for them to provide me with information that I am likely to find helpful. > Dave, I know you are subtle about such things and the purposeful disconnect > that is lost on me, clearly has merit to you. Can you use simple words and > help me out? Of course SSP can only be advisory at best, but is their more to > your perspective than that? A signer should make statements that a) the signer believes to be important, and b) there is a good basis for believing that evaluators will consider important. A signer should not direct the evaluator what is to be done with that information. I do not see this distinction as small or subtle. John Levine's note: >> When I think of SSP records saying dump mail if it's not signed, I see a >> bunch of tiny gorillas*, beating their teensy chests and saying in high >> squeaky voices, "Beware, oh Internet, of the Scourge of Criminals >> attempting to forge the image of my Inestimable Personage, and do not >> DARE to be fooled by these Base Mockeries of Communication!" The only >> reasonable response from everyone else is somewhere between "Huh?" and >> "Get real." >> >> If the ABA or the FDIC published a list of domains used by member banks >> to send signed transactional mail, I would find that really useful. A >> list of people who think they are as threatened by forgery as those >> banks is useless other than for entertainment value. >> >> So that's the problem with SSP. Whatever your policy is, unless you're >> someone I already have reason to be interested in, I don't care. seems to be getting at the same point: It's fine for you to tell me interesting stuff, but please do not pretend to tell me what to do with it. 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] "I sign everything" is not a useful policy
- Original Message - From: "Dave Crocker" <[EMAIL PROTECTED]> > If I choose to deliver unsigned mail that purports to be from a > domain that says it signs everything, but I mark it up with flashing > lights that say "spoofed" do you want that to be a protocol violation? Yes. I am not what you mean by "But i mark it up with.." by yes, if the domain expectations for a valid transactions are broken, in order to protect his reputation inherited by a DKIM-BASE mandate, he would prerfer it to be a protocol violation. > What about my choosing to send it to > my sysadmin for special handling for spoofed mail? What about... Thats up to you and local system policy. That should take away the domain declaration for his expectatons for a valid transaction. > In other words, there are lots of things that I might reasonably > choose to do with mail that I receive that violates one or > another SSP statement. I am not sure I follow the logic, but this is all really simple. The domain told you want is expected for a valid message. It went thru all the work on signing messages for some reason that hopefully has some payoff when things go wrong with it. Isn't the essense of a security protocol? When the protocol is not followed? > It is not the publisher's right or responsibility to tell me what to do with > information. By contrast it is entirely reasonable for them to provide me with > information that I am likely to find helpful. Agree. And sure, as a receiver, you can decide to do what you want. But if we are talking about helping to stop or control abuse, then I think most receivers are very interested in technology that will help in the area. > A signer should make statements that a) the signer believes to > be important, and b) there is a good basis for believing that > evaluators will consider important. Isn't this what SSP draft, including DSAP I-D draft already does and documents? Have you looked at this documents? What is wrong with them? Do you trust the engineering done? What's missing? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] "I sign everything" is not a useful policy
Dave, You may deliver anything you wish, in any manner. It will only be a protocol violation when a scmuddle determines that it may not have been a very good idea. Policies and protocols are rules to ensure that finger pointing is accurate. Thanks, Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos Sent: Sunday, August 06, 2006 12:01 AM To: [EMAIL PROTECTED]; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy - Original Message - From: "Dave Crocker" <[EMAIL PROTECTED]> > If I choose to deliver unsigned mail that purports to be from a > domain that says it signs everything, but I mark it up with flashing > lights that say "spoofed" do you want that to be a protocol violation? Yes. I am not what you mean by "But i mark it up with.." by yes, if the domain expectations for a valid transactions are broken, in order to protect his reputation inherited by a DKIM-BASE mandate, he would prerfer it to be a protocol violation. > What about my choosing to send it to > my sysadmin for special handling for spoofed mail? What about... Thats up to you and local system policy. That should take away the domain declaration for his expectatons for a valid transaction. > In other words, there are lots of things that I might reasonably > choose to do with mail that I receive that violates one or > another SSP statement. I am not sure I follow the logic, but this is all really simple. The domain told you want is expected for a valid message. It went thru all the work on signing messages for some reason that hopefully has some payoff when things go wrong with it. Isn't the essense of a security protocol? When the protocol is not followed? > It is not the publisher's right or responsibility to tell me what to do with > information. By contrast it is entirely reasonable for them to provide me with > information that I am likely to find helpful. Agree. And sure, as a receiver, you can decide to do what you want. But if we are talking about helping to stop or control abuse, then I think most receivers are very interested in technology that will help in the area. > A signer should make statements that a) the signer believes to > be important, and b) there is a good basis for believing that > evaluators will consider important. Isn't this what SSP draft, including DSAP I-D draft already does and documents? Have you looked at this documents? What is wrong with them? Do you trust the engineering done? What's missing? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ 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] "I sign everything" is not a useful policy
Hector, The engineering part is easy, what is extremely difficult is the policy. After spending a long period of time debating what the word UNIQUE means in a policy document that has some similarities to email, I want to get it right the first time. Make sure the rules are simple. Ensure there is agreement. Make sure a clean unambiguous meaning is set to every possibility. Its harder than it looks. Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos Sent: Sunday, August 06, 2006 12:01 AM To: [EMAIL PROTECTED]; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy - Original Message - From: "Dave Crocker" <[EMAIL PROTECTED]> > If I choose to deliver unsigned mail that purports to be from a > domain that says it signs everything, but I mark it up with flashing > lights that say "spoofed" do you want that to be a protocol violation? Yes. I am not what you mean by "But i mark it up with.." by yes, if the domain expectations for a valid transactions are broken, in order to protect his reputation inherited by a DKIM-BASE mandate, he would prerfer it to be a protocol violation. > What about my choosing to send it to > my sysadmin for special handling for spoofed mail? What about... Thats up to you and local system policy. That should take away the domain declaration for his expectatons for a valid transaction. > In other words, there are lots of things that I might reasonably > choose to do with mail that I receive that violates one or > another SSP statement. I am not sure I follow the logic, but this is all really simple. The domain told you want is expected for a valid message. It went thru all the work on signing messages for some reason that hopefully has some payoff when things go wrong with it. Isn't the essense of a security protocol? When the protocol is not followed? > It is not the publisher's right or responsibility to tell me what to do with > information. By contrast it is entirely reasonable for them to provide me with > information that I am likely to find helpful. Agree. And sure, as a receiver, you can decide to do what you want. But if we are talking about helping to stop or control abuse, then I think most receivers are very interested in technology that will help in the area. > A signer should make statements that a) the signer believes to > be important, and b) there is a good basis for believing that > evaluators will consider important. Isn't this what SSP draft, including DSAP I-D draft already does and documents? Have you looked at this documents? What is wrong with them? Do you trust the engineering done? What's missing? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ 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] "I sign everything" is not a useful policy
Bill, Actually, IMV, the POLICY is the easiest part because that is already define by the potential DKIM-BASE may exhibit. It will be the engineering to get it done properly that may ultimately tell us of the feasbiliity of it all which I am 100% capability of accepting way away or another. No, I don't think it is hardr at all. The possible policies are fixed. Where did that come from anyway? "I sign all mail" That isn't in SSP DRAFT, in fact the SSP says for the o= tag: o= Outbound signing policy for the entity (plain-text; OPTIONAL, default is "~"). Possible values are as follows: ~ The entity signs some but not all email. - All mail from the entity is signed; unsigned email MUST NOT be accepted, but email signed with a Verifier Acceptable Third Party Signature SHOULD be accepted. ! All mail from the entity is signed; Third-Party signatures SHOULD NOT be accepted . This entity never sends email. The "." policy can be used to "short circuit" searches from subdomains; for example, the "ad.jp" domain might use this. If an initial policy search receives this policy then the email SHOULD NOT be accepted; if found while searching parent domains then the search should terminate as though no policy record was found. ^ Repeat query at user level. This value MUST NOT be used in user-level policy records. A Verifier MUST look up the selector for "._policy" where is the local-part of the Originator Address (i.e., the portion of the address before the "@" character). These is the SEMANTICS people should be debating. Once you think about the engineering to statisfy these requirement, including problems from a security standpoint, the loopholes, etc, then you see my position better and why DSAP was done. There is alot of time being wasted here by people who saying they don't understand and then suggest it is the status quo, therefore lets water it down without thinking about the security implications which are pretty major. No, it is extremely simple yet powerful concept. The issue? It is feasible. Can it work? What will it take to work? Is there a revamp and/or migration issue here? etc. No, the policies are simple. In short, watering it down make be as bad as having nothing at all. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; Sent: Sunday, August 06, 2006 12:23 AM Subject: RE: [ietf-dkim] "I sign everything" is not a useful policy Hector, The engineering part is easy, what is extremely difficult is the policy. After spending a long period of time debating what the word UNIQUE means in a policy document that has some similarities to email, I want to get it right the first time. Make sure the rules are simple. Ensure there is agreement. Make sure a clean unambiguous meaning is set to every possibility. Its harder than it looks. Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos Sent: Sunday, August 06, 2006 12:01 AM To: [EMAIL PROTECTED]; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy - Original Message - From: "Dave Crocker" <[EMAIL PROTECTED]> > If I choose to deliver unsigned mail that purports to be from a > domain that says it signs everything, but I mark it up with flashing > lights that say "spoofed" do you want that to be a protocol violation? Yes. I am not what you mean by "But i mark it up with.." by yes, if the domain expectations for a valid transactions are broken, in order to protect his reputation inherited by a DKIM-BASE mandate, he would prerfer it to be a protocol violation. > What about my choosing to send it to > my sysadmin for special handling for spoofed mail? What about... Thats up to you and local system policy. That should take away the domain declaration for his expectatons for a valid transaction. > In other words, there are lots of things that I might reasonably > choose to do with mail that I receive that violates one or > another SSP statement. I am not sure I follow the logic, but this is all really simple. The domain told you want is expected for a valid message. It went thru all the work on signing messages for some reason that hopefully has some payoff when things go wrong with it. Isn't the essense of a security protocol? When the protocol is not followed? > It is not the publisher's right or responsibility to tell me what to do with > information. By contrast it is entirely reasonable for them to pro
RE: [ietf-dkim] "I sign everything" is not a useful policy
On Sat, 5 Aug 2006 20:48:05 -0400 <[EMAIL PROTECTED]> wrote: >An invalid signature is not unsigned, but we are not discussing that >policy point yet :-) OK. If you have a useful distinction that can be made without creating a trivially exploitable trivial hole, I think that now, when requirements are being discussed, is the right time to do it. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
> If I choose to deliver unsigned mail that purports to be from a domain that > says > it signs everything, but I mark it up with flashing lights that say "spoofed" > do > you want that to be a protocol violation? What about my choosing to send it to > my sysadmin for special handling for spoofed mail? What about... Well sure, but how about treating it the same as an IP checksum failure? You may divert it to some port for analysis - especially in the early days - but what sort of stack delivers a known damaged packet to the end point when the transmitter/protocol says to discard known damaged packets? DKIM+SSP is defining "damaged". Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
- Original Message - From: "Mark Delany" <[EMAIL PROTECTED]> To: Sent: Sunday, August 06, 2006 8:38 AM Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy > DKIM+SSP is defining "damaged". +1 SSP does not attempt to evaluate the reputation of the sender or client. A good intention client can use SSP as well as the bad intention client. The main objective of SSP is to establish a protocol consistency and to use the deviation from the consistency as part of a failure detection system. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
Dave Crocker wrote: Mark Delany wrote: Having the signer or the ssp publishes tell the evaluator what they should do with a message is not a good idea Why do you say that Dave? If SSP is not giving guidance/information to receivers/evaluators, who then is the target audience for SSP? And what do we want them to do with the information? An interesting twist to "telling evaluators", as you put it, is that SSP is a negative indicator. It's telling evaluators *not* to deliver unless the right conditions are met. Why would an "evaluator" be suspicious of a domain that encourages non-delivery of its own traffic when in doubt? The signer knows everything there is about their own behaviors. They cannot know very much about the context, needs, preferences, or much else about the evaluator. Therefore they cannot know very much about what the evaluator "should" do with a message. Seriously. SSP can be entirely useful when stated in terms of the sender's perspective. It does not need to pretend that is knows enough to give directions to an evaluator. From what I can see, we are converging on a policy/practice where most domains could make a completely correct statement: "I sign everything" and never want to publish that policy given that the normal and expected transit damage of remailers, etc. That tells me that as stated "I sign everything" is wrong. What people really seem to be meaning is "you should find a valid (verifyable) first party dkim signature" which is a lot different statement than "I sign everything". It's the expectation that this all really hinges on. This toes the line of telling the receiver what to do, but it at least doesn't go over the line by pointing out an acceptable form of execution (550, leathal injection, etc). So it seems to me that what we really need here is some finesse of informing the receiver of the sender's transit expectations without outright saying what to do. Mike We have done quite a good job, so far, of distinguishing statements about signing from statements about delivery or non-delivery. The issue is not whether the evaluator might be "suspicious" of a direction to perform non-delivery. It is that it crosses a line into making presumptions about the evaluator that a) the Internet technical community does not have experience with, and b) we do not need to cross. d/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
Mark Delany wrote: If I choose to deliver unsigned mail that purports to be from a domain that says it signs everything, but I mark it up with flashing lights that say "spoofed" do you want that to be a protocol violation? What about my choosing to send it to my sysadmin for special handling for spoofed mail? What about... Well sure, but how about treating it the same as an IP checksum failure? What this analogy is missing is that the checksum is being grafted on after the fact such communication that used to get through stops happening in erratic and unexplainable ways if the receiver just throws damaged messages away. Worse, is that parts of the infrastructure do this kind of damage and think it is not only a feature, but that it's their god-given right. If DKIM were part of RFC822 like checksums were in IP this would be a different situation, but it missed that by about 25 years. Mike You may divert it to some port for analysis - especially in the early days - but what sort of stack delivers a known damaged packet to the end point when the transmitter/protocol says to discard known damaged packets? DKIM+SSP is defining "damaged". Mark. ___ 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] "I sign everything" is not a useful policy
On Sat, 05 Aug 2006 19:21:59 -0700 Dave Crocker <[EMAIL PROTECTED]> wrote: >A signer should not direct the evaluator what is to be done with that information. Is anyone arguing that they should? Setting expectations does not equal direction. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
Arvel Hathcock wrote: > "I sign all": Your users and my business may be harmed by accepting > unverified mail claiming to originate from my domain. It is in our > mutual interest for you to not deliver such mail to your users. > > I am an adult of voting age and accept the possibility that > deliverability of my traffic may reduce as a consequence. Yes, +1. This is the way I've understood the "I sign all" policy since forever. Arvel: I'm pretty sure that Altn.com signs all of its mail. If that's the case, then why are you publishing this SSP record: _policy._domainkey.altn.com text "o=~; [EMAIL PROTECTED]" Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
Scott Kitterman wrote: On Sat, 05 Aug 2006 19:21:59 -0700 Dave Crocker <[EMAIL PROTECTED]> wrote: A signer should not direct the evaluator what is to be done with that information. Is anyone arguing that they should? Setting expectations does not equal direction. Yes, a surprising number of people are. There must be rent in the universe because it's been odd how strangely aligned my thinking has been with Dave's, even as I struggle to come up with the right way to describe this. I'm hopeful about the formulation of a signer's expectation of verification success rather than "I sign everything" finesses this. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
On Aug 6, 2006, at 8:26 AM, Michael Thomas wrote: Scott Kitterman wrote: On Sat, 05 Aug 2006 19:21:59 -0700 Dave Crocker <[EMAIL PROTECTED]> wrote: A signer should not direct the evaluator what is to be done with that information. Is anyone arguing that they should? Setting expectations does not equal direction. Yes, a surprising number of people are. There must be rent in the universe because it's been odd how strangely aligned my thinking has been with Dave's, even as I struggle to come up with the right way to describe this. I'm hopeful about the formulation of a signer's expectation of verification success rather than "I sign everything" finesses this. I agree with Dave, although it is easy to slip, and I am perhaps just as guilty as others. It would be good to keep the policy definitions based upon just the domain-of-policy actions. There should be a section that reviews what might be expected verifier actions based upon these definitions. Expectations will be more realistic and review will be easier when the defined set of domain-of-policy actions are not merged with that of the verifiers actions from the definitional standpoint. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
> Arvel: I'm pretty sure that Altn.com signs all of its mail. If that's > the case, then why are you publishing this SSP record: > > _policy._domainkey.altn.com text "o=~; [EMAIL PROTECTED] I suspect we could probably change that now. My postmaster had asked for a relaxed policy during the past year mostly because I keep changing the code and have had a couple of instances where I rendered our signer incompatible with our verifier for a short time (Doh!). -- Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
Mark Delany wrote: >> If I choose to deliver unsigned mail that purports to be from a domain that >> says >> it signs everything, but I mark it up with flashing lights that say >> "spoofed" do ... > Well sure, but how about treating it the same as an IP checksum > failure? > > You may divert it to some port for analysis - especially in the early > days - but what sort of stack delivers a known damaged packet to the > end point when the transmitter/protocol says to discard known damaged > packets? Mark, I am a great fan of looking to the experience of the lower layers, when trying to develop mechanisms for applications, especially email. So your suggestion is an important one to consider. I think the problem is that email's variations in the handling of its "packets" make its environment too vastly different from the much simpler world of IP. (I'll skip over my recollection that there have been activities that do partial delivery on damaged IP datagrams. The standard says what you cite and it is a more useful place to start, I think.) What you espouse is probably where we all want this to get to. The question is whether we can get there with a directive, at this point, in an adjunct protocol that operates in the realm of a contingent, remote, partially-adopted mechanism that changes the fundamentals of Internet mail delivery? And, of course, the way I've phrased it, here, makes clear my own view of the answer. In other words, having a sender give contingent -- in the sense that some senders will give it and others won't -- directions about delivery is a very new realm, not just for email but for Internet protocols in general. Rather than cross over the line into that bit of architecturally experimental specification, why is is not sufficient to leave things with the simpler -- albeit more passive -- stance that a sender talks about themselves but refrains from telling the evaluator what to do with the information? Yes, that is at odds with a classic model of protocol specification, but we are juggling among constraints, here. 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] "I sign everything" is not a useful policy
Why not take an AIN approach? An SSP query to determine how to route the message, with additional signatures, without and directly? Thanks, Bill Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Sunday, August 06, 2006 5:38 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy Mark Delany wrote: >> If I choose to deliver unsigned mail that purports to be from a domain that says >> it signs everything, but I mark it up with flashing lights that say "spoofed" do ... > Well sure, but how about treating it the same as an IP checksum > failure? > > You may divert it to some port for analysis - especially in the early > days - but what sort of stack delivers a known damaged packet to the > end point when the transmitter/protocol says to discard known damaged > packets? Mark, I am a great fan of looking to the experience of the lower layers, when trying to develop mechanisms for applications, especially email. So your suggestion is an important one to consider. I think the problem is that email's variations in the handling of its "packets" make its environment too vastly different from the much simpler world of IP. (I'll skip over my recollection that there have been activities that do partial delivery on damaged IP datagrams. The standard says what you cite and it is a more useful place to start, I think.) What you espouse is probably where we all want this to get to. The question is whether we can get there with a directive, at this point, in an adjunct protocol that operates in the realm of a contingent, remote, partially-adopted mechanism that changes the fundamentals of Internet mail delivery? And, of course, the way I've phrased it, here, makes clear my own view of the answer. In other words, having a sender give contingent -- in the sense that some senders will give it and others won't -- directions about delivery is a very new realm, not just for email but for Internet protocols in general. Rather than cross over the line into that bit of architecturally experimental specification, why is is not sufficient to leave things with the simpler -- albeit more passive -- stance that a sender talks about themselves but refrains from telling the evaluator what to do with the information? Yes, that is at odds with a classic model of protocol specification, but we are juggling among constraints, here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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] "I sign everything" is not a useful policy
http://www.intel.com/network/csp/solutions/ngn/7643gls.htm Advanced Intelligent Network (AIN) The Advanced Intelligent Network (AIN) is a telephone network architecture that separates service logic from switching equipment, allowing new services to be added without having to redesign switches to support new services. Developed by Bell Communications Research, AIN is recognized as an industry standard in North America. Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -Original Message- From: william(at)elan.net [mailto:[EMAIL PROTECTED] Sent: Sunday, August 06, 2006 7:26 PM To: Oxley, Bill (CCI-Atlanta) Cc: ietf-dkim@mipassoc.org Subject: RE: [ietf-dkim] "I sign everything" is not a useful policy On Sun, 6 Aug 2006 [EMAIL PROTECTED] wrote: > Why not take an AIN approach? An SSP query to determine how to route the > message, with additional signatures, without and directly? AIN? -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] "I sign everything" is not a useful policy
On Sun, 6 Aug 2006 [EMAIL PROTECTED] wrote: Why not take an AIN approach? An SSP query to determine how to route the message, with additional signatures, without and directly? AIN? -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
- Original Message - From: "Dave Crocker" <[EMAIL PROTECTED]> To: Sent: Sunday, August 06, 2006 5:37 PM Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy > Rather than cross over the line into that bit of architecturally > experimental specification, why is is not sufficient to leave things > with the simpler -- albeit more passive -- stance that a sender talks > about themselves but refrains from telling the evaluator what to do > with the information? Yes, that is at odds with a classic model of > protocol specification, but we are juggling among > constraints, here. In my view, the power of DKIM-SSP is 100% about protocol consistency. I don't wish to be redundant, but this is how the DSAP introduction concludes: [you may substitute DSAP for SSP] DSAP does not attempt to evaluate the reputation of the sender or client. A good intention client can use DSAP as well as the bad intention client. The main objective of DSAP is to establish a protocol consistency between all client types and to use the deviation from the consistency as part of a failure detection system This is not different than any other C/S negotiation handshake concept such as with the PPP protocol where there is a LCP stage to negotiate the link. If the expected link attributes are not met, the connection is not made. It was not different as with IEMSI (pronounced I-EM-SI) in the old fidonet days where the common storage, the NodeList (akin to DNS) describes the host server capabilities and attributes. Both the client and server know what was expected. Similarly, it is no different when an SMTP client calls a SMTP host and the host exposes its EHLO capabilites which the client works with. If the client does something the server did not expect, we can presume there will be some level of protocol inconsistency and failure. But if the client sends a fraudulent HELO or a RETURN PATH and the server doesn't check them, well, then we have problems like we have today. SSP Policies and attributes are defined by the owner in some common storage we call DNS, The owner uses them to create DKIM data. The verifier, if it cares for security, which I presume it will, will uses them to confirm the DKIM data, if any. If something is not quite kolsher, the natural presumption is to assume a failure. Now the real question here, is it practical? Is it feasible? It is doable? For me, as a practioneer in the field, I say yes. It is possible and the implementation code is really quite simple. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
+1 I don't agree with everything in DSAP and would take you to task on one or two. However, I believe that it is doable in our lifetimes and if we worked really hard, could be worked out in this working session. Without it, SSP's a big piece of duct tape. Regards, Damon Sauer On 8/6/06, Hector Santos <[EMAIL PROTECTED]> wrote: - Original Message - From: "Dave Crocker" <[EMAIL PROTECTED]> To: Sent: Sunday, August 06, 2006 5:37 PM Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy > Rather than cross over the line into that bit of architecturally > experimental specification, why is is not sufficient to leave things > with the simpler -- albeit more passive -- stance that a sender talks > about themselves but refrains from telling the evaluator what to do > with the information? Yes, that is at odds with a classic model of > protocol specification, but we are juggling among > constraints, here. In my view, the power of DKIM-SSP is 100% about protocol consistency. I don't wish to be redundant, but this is how the DSAP introduction concludes: [you may substitute DSAP for SSP] DSAP does not attempt to evaluate the reputation of the sender or client. A good intention client can use DSAP as well as the bad intention client. The main objective of DSAP is to establish a protocol consistency between all client types and to use the deviation from the consistency as part of a failure detection system This is not different than any other C/S negotiation handshake concept such as with the PPP protocol where there is a LCP stage to negotiate the link. If the expected link attributes are not met, the connection is not made. It was not different as with IEMSI (pronounced I-EM-SI) in the old fidonet days where the common storage, the NodeList (akin to DNS) describes the host server capabilities and attributes. Both the client and server know what was expected. Similarly, it is no different when an SMTP client calls a SMTP host and the host exposes its EHLO capabilites which the client works with. If the client does something the server did not expect, we can presume there will be some level of protocol inconsistency and failure. But if the client sends a fraudulent HELO or a RETURN PATH and the server doesn't check them, well, then we have problems like we have today. SSP Policies and attributes are defined by the owner in some common storage we call DNS, The owner uses them to create DKIM data. The verifier, if it cares for security, which I presume it will, will uses them to confirm the DKIM data, if any. If something is not quite kolsher, the natural presumption is to assume a failure. Now the real question here, is it practical? Is it feasible? It is doable? For me, as a practioneer in the field, I say yes. It is possible and the implementation code is really quite simple. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ 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] "I sign everything" is not a useful policy
Friends, Let it never be said that I am inflexible and can't change my mind from good arguments. After a restless night thinking about this, I am going to change my thoughts just slightly. All email that has a munged sig or no sig that comes from an "I sign all" domain should be expected not to reach its destination. I want to see: "I sign all" and/or these domains can sign for me. If the message is not signed, it is expected by me that the messages will not reach its destination. "I sign none" Nothing from me at this domain should be signed. If it is, it is expected by me that the message will not reach its destination. "I sign all" only from this domain(s) or _FDQN(s)_. Messages from this domain(s) or FDQN(s) that are not signed are expected by me not to reach their destination. However, messages coming from everywhere else may or may not be signed. I expect that these messages will not be effected under this policy. I think that these policies should cover every scenario I can think of. The FDQNs are important. As an admin who has several gateways at the same domain, it would be nice to be able to route some mail fitting a policy to a particular MTA to have it signed and delivered without effecting my other mail. If munging is too much of an issue, turn the policies off, fix the problem, turn them back on. I don't think we should stop work just because this _might_ happen. The benefits outweigh the risks. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
Again - this raises no new technical issue. So, let's please wait and work on reqs-00's text, Stephen. Damon wrote: Friends, Let it never be said that I am inflexible and can't change my mind from good arguments. After a restless night thinking about this, I am going to change my thoughts just slightly. All email that has a munged sig or no sig that comes from an "I sign all" domain should be expected not to reach its destination. I want to see: "I sign all" and/or these domains can sign for me. If the message is not signed, it is expected by me that the messages will not reach its destination. "I sign none" Nothing from me at this domain should be signed. If it is, it is expected by me that the message will not reach its destination. "I sign all" only from this domain(s) or _FDQN(s)_. Messages from this domain(s) or FDQN(s) that are not signed are expected by me not to reach their destination. However, messages coming from everywhere else may or may not be signed. I expect that these messages will not be effected under this policy. I think that these policies should cover every scenario I can think of. The FDQNs are important. As an admin who has several gateways at the same domain, it would be nice to be able to route some mail fitting a policy to a particular MTA to have it signed and delivered without effecting my other mail. If munging is too much of an issue, turn the policies off, fix the problem, turn them back on. I don't think we should stop work just because this _might_ happen. The benefits outweigh the risks. Regards, Damon Sauer ___ 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] "I sign everything" is not a useful policy
S.. How's the weather? Nice and HOT here in Atlanta :) Damon On 8/8/06, Stephen Farrell <[EMAIL PROTECTED]> wrote: Again - this raises no new technical issue. So, let's please wait and work on reqs-00's text, Stephen. Damon wrote: > Friends, > Let it never be said that I am inflexible and can't change my mind > from good arguments. > > After a restless night thinking about this, I am going to change my > thoughts just slightly. > > All email that has a munged sig or no sig that comes from an "I sign > all" domain should be expected not to reach its destination. > > I want to see: > > "I sign all" and/or these domains can sign for me. If the message is > not signed, it is expected by me that the messages will not reach its > destination. > > "I sign none" Nothing from me at this domain should be signed. If it > is, it is expected by me that the message will not reach its > destination. > > "I sign all" only from this domain(s) or _FDQN(s)_. Messages from this > domain(s) or FDQN(s) that are not signed are expected by me not to > reach their destination. However, messages coming from everywhere else > may or may not be signed. I expect that these messages will not be > effected under this policy. > > I think that these policies should cover every scenario I can think of. > > The FDQNs are important. As an admin who has several gateways at the > same domain, it would be nice to be able to route some mail fitting a > policy to a particular MTA to have it signed and delivered without > effecting my other mail. > > If munging is too much of an issue, turn the policies off, fix the > problem, turn them back on. I don't think we should stop work just > because this _might_ happen. The benefits outweigh the risks. > > > Regards, > Damon Sauer > ___ > 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] "I sign everything" is not a useful policy
>> Since someone who doesn't sign anything wouldn't publish any keys, how >> could this possibly be useful? Where would these rogue signatures >> come from, and how is a recipient going to verify a signature that has >> no key record? > > This was put in because I was reading threads where they wanted to be > able to say "I sign no mail". From what I read, this was for domains > that expliciately do not send _any_ mail what-so-ever. "I sign no mail" is quite different from "I send no mail." The latter says to throw away unsigned mail. >> >"I sign all" only from this domain(s) or _FDQN(s)_. Messages from this >> >domain(s) or FDQN(s) that are not signed are expected by me not to >> >reach their destination. However, messages coming from everywhere else >> >may or may not be signed. I expect that these messages will not be >> >effected under this policy. >> >> It should be obvious that "domain" and "FQDN" are exact synoyms in >> this discussion. With that in mind, how does this differ from the >> first "I sign all"? Nobody's going to be looking at your SSP for >> any domains other than yours. > > I do not see them as being exact but fdqn being a subset. In the DNS, a domain is a domain. Subdomains are useful when you think about organizing your network, but when we're talking protocols, a query for dsl-467.podunk.someisp.com is no different from one for someisp.com. It is if there is a policy record at dsl-467.podunk.someisp.com I have some real life examples if you would like to see them. > For instance, all the messages I send come from the mta: > mail1.bigbank.com which are not signed and have a mail from: of > /at/bigbank.com except for my transactional messages. These > come from the mta: reciepts.bigbank.com which has a mail from: > customer_service/at/bigbank.com for which I want to apply the policy > of "I sign all" with the expected result of do not deliver anything > that is not signed. Please send that scenario in to the list so someone other than me can tell you that path authentication is completely off the table. If you want your transactional mail treated differently from your employee mail, put them in different domains, e.g. [EMAIL PROTECTED] This is *exactly* my problem with SSP. Without being able to state the above, it makes it unwieldly. My example shows just one domain but what if I have 132 peppered within these, 1 to 10 mta's some I would want to sign for, some I would not. So now I would have to have all email sent to postmaster/at/svc.bigbank.com forwarded to postmaster/at/bigbank.com, plus every address that may be signing mail. As an administrator, I would like the policy that says any time I send to XYZ.com from bigbank.com due to a content policy or because the email was sent between 3:15 and 3:17pm, whatever... I want to be able to point that email at my "signing mta" and not break my return-paths or add extra work for myself. Why is it completely off the table? I will let you send to the list if you'd like so that it is not assumed that I am blindsiding you. :) ..on second thought... I will go ahead and post it. Since I feel this _may_ be a new way of looking at the problem, I believe that it follows Stephan's rules. Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
On 8/8/06, Damon <[EMAIL PROTECTED]> wrote: > >> Since someone who doesn't sign anything wouldn't publish any keys, how > >> could this possibly be useful? Where would these rogue signatures > >> come from, and how is a recipient going to verify a signature that has > >> no key record? > > > > This was put in because I was reading threads where they wanted to be > > able to say "I sign no mail". From what I read, this was for domains > > that expliciately do not send _any_ mail what-so-ever. > > "I sign no mail" is quite different from "I send no mail." The latter > says to throw away unsigned mail. > > >> >"I sign all" only from this domain(s) or _FDQN(s)_. Messages from this > >> >domain(s) or FDQN(s) that are not signed are expected by me not to > >> >reach their destination. However, messages coming from everywhere else > >> >may or may not be signed. I expect that these messages will not be > >> >effected under this policy. > >> > >> It should be obvious that "domain" and "FQDN" are exact synoyms in > >> this discussion. With that in mind, how does this differ from the > >> first "I sign all"? Nobody's going to be looking at your SSP for > >> any domains other than yours. > > > > I do not see them as being exact but fdqn being a subset. > > In the DNS, a domain is a domain. Subdomains are useful when you think > about organizing your network, but when we're talking protocols, a query > for dsl-467.podunk.someisp.com is no different from one for someisp.com. It is if there is a policy record at dsl-467.podunk.someisp.com I have some real life examples if you would like to see them. > > > For instance, all the messages I send come from the mta: > > mail1.bigbank.com which are not signed and have a mail from: of > > /at/bigbank.com except for my transactional messages. These > > come from the mta: reciepts.bigbank.com which has a mail from: > > customer_service/at/bigbank.com for which I want to apply the policy > > of "I sign all" with the expected result of do not deliver anything > > that is not signed. > > Please send that scenario in to the list so someone other than me can tell > you that path authentication is completely off the table. > > If you want your transactional mail treated differently from your employee > mail, put them in different domains, e.g. > [EMAIL PROTECTED] > This is *exactly* my problem with SSP. Without being able to state the above, it makes it unwieldly. My example shows just one domain but what if I have 132 peppered within these, 1 to 10 mta's some I would want to sign for, some I would not. So now I would have to have all email sent to postmaster/at/svc.bigbank.com forwarded to postmaster/at/bigbank.com, plus every address that may be signing mail. As an administrator, I would like the policy that says any time I send to XYZ.com from bigbank.com due to a content policy or because the email was sent between 3:15 and 3:17pm, whatever... I want to be able to point that email at my "signing mta" and not break my return-paths or add extra work for myself. Why is it completely off the table? I will let you send to the list if you'd like so that it is not assumed that I am blindsiding you. :) ..on second thought... I will go ahead and post it. Since I feel this _may_ be a new way of looking at the problem, I believe that it follows Stephan's rules. Damon Or how about a useful example: I run my eBay business out of my webmail account. I know that one of the domains that I send to, for reasons of security or insanity, requires that all email be signed. My webmail service does not want to sign every piece of email that goes out the door, so they offer an option in the form of a checkbox that says "sign this email". This email is then diverted to a signing MTA which adds the sig. The policy for _that_ mta is "I sign all mail". This is just a generic scenario, but I have no doubt that something like this could be applied somewhere quite usefully. Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
This strikes me as more repetition. Please justify why its not and/or recast it specifically addressing our requirements draft. We need to move beyond everyone's favorite idea of what's a good idea and onto something that garners wider support. Stephen. Damon wrote: On 8/8/06, Damon <[EMAIL PROTECTED]> wrote: > >> Since someone who doesn't sign anything wouldn't publish any keys, how > >> could this possibly be useful? Where would these rogue signatures > >> come from, and how is a recipient going to verify a signature that has > >> no key record? > > > > This was put in because I was reading threads where they wanted to be > > able to say "I sign no mail". From what I read, this was for domains > > that expliciately do not send _any_ mail what-so-ever. > > "I sign no mail" is quite different from "I send no mail." The latter > says to throw away unsigned mail. > > >> >"I sign all" only from this domain(s) or _FDQN(s)_. Messages from this > >> >domain(s) or FDQN(s) that are not signed are expected by me not to > >> >reach their destination. However, messages coming from everywhere else > >> >may or may not be signed. I expect that these messages will not be > >> >effected under this policy. > >> > >> It should be obvious that "domain" and "FQDN" are exact synoyms in > >> this discussion. With that in mind, how does this differ from the > >> first "I sign all"? Nobody's going to be looking at your SSP for > >> any domains other than yours. > > > > I do not see them as being exact but fdqn being a subset. > > In the DNS, a domain is a domain. Subdomains are useful when you think > about organizing your network, but when we're talking protocols, a query > for dsl-467.podunk.someisp.com is no different from one for someisp.com. It is if there is a policy record at dsl-467.podunk.someisp.com I have some real life examples if you would like to see them. > > > For instance, all the messages I send come from the mta: > > mail1.bigbank.com which are not signed and have a mail from: of > > /at/bigbank.com except for my transactional messages. These > > come from the mta: reciepts.bigbank.com which has a mail from: > > customer_service/at/bigbank.com for which I want to apply the policy > > of "I sign all" with the expected result of do not deliver anything > > that is not signed. > > Please send that scenario in to the list so someone other than me can tell > you that path authentication is completely off the table. > > If you want your transactional mail treated differently from your employee > mail, put them in different domains, e.g. > [EMAIL PROTECTED] > This is *exactly* my problem with SSP. Without being able to state the above, it makes it unwieldly. My example shows just one domain but what if I have 132 peppered within these, 1 to 10 mta's some I would want to sign for, some I would not. So now I would have to have all email sent to postmaster/at/svc.bigbank.com forwarded to postmaster/at/bigbank.com, plus every address that may be signing mail. As an administrator, I would like the policy that says any time I send to XYZ.com from bigbank.com due to a content policy or because the email was sent between 3:15 and 3:17pm, whatever... I want to be able to point that email at my "signing mta" and not break my return-paths or add extra work for myself. Why is it completely off the table? I will let you send to the list if you'd like so that it is not assumed that I am blindsiding you. :) ..on second thought... I will go ahead and post it. Since I feel this _may_ be a new way of looking at the problem, I believe that it follows Stephan's rules. Damon Or how about a useful example: I run my eBay business out of my webmail account. I know that one of the domains that I send to, for reasons of security or insanity, requires that all email be signed. My webmail service does not want to sign every piece of email that goes out the door, so they offer an option in the form of a checkbox that says "sign this email". This email is then diverted to a signing MTA which adds the sig. The policy for _that_ mta is "I sign all mail". This is just a generic scenario, but I have no doubt that something like this could be applied somewhere quite usefully. Damon ___ 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
