Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
On Wed, 05 Dec 2007 14:18:09 -, Scott Kitterman [EMAIL PROTECTED] wrote: On Wednesday 05 December 2007 08:53, John Levine wrote: How would doing this work change what verifiers do after the RFC is deployed? Probably not much, but it will help rein in unwarranted expectations by senders that publishing SSP will affect what happens to their mail. Exactly. Verifier implementors who do not read the document carefully enough (Shock! Horror! they wouldn't to that would they!) will see all those Verifiers MUST statements and deduce that they are obliged to follow them exactly. Which will discourage them from trying innovative and imaginative techniques which might, in the long term, lead to impprved filtering of 'suspicious' (or even 'not so suspicious') messages. And let me remind you that this thread started exactly because Dave Crocker (who maybe should know better) misread those MUSTs in exactly that way. If even the people on this list can mis-read the draft, then that is a clear indication that its wording needs to be reviewed even though it does, when read carefully, say the right thing. It sounds like a lot of work to say the same thing to me. I don't think increasing the quantity and type of ways that the draft says it doesn't mandate what receivers will do is a value added use of anyone's time. Extra work that results in implementors making fewer mistakes is NEVER a waste of time. FYI, here is the wording that I suggested again. It isn't necessarily a pure addition, since it might enable some other less obvious statements of the situation to be taken out: This document describes processes for what verifiers are expected to do in order to achieve what the signers intend. But these descriptions are not Normative since there is no compulsion on verifiers to follow those processes exactly as described, or even at all. Therefore, use of the terms MUST and SHOULD in these descriptions merely indicate the steps verifiers need to take if they want to claim adherence to the particular set of processes described here. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
On Thursday 06 December 2007 07:12, Charles Lindsey wrote: On Wed, 05 Dec 2007 14:18:09 -, Scott Kitterman [EMAIL PROTECTED] wrote: On Wednesday 05 December 2007 08:53, John Levine wrote: How would doing this work change what verifiers do after the RFC is deployed? Probably not much, but it will help rein in unwarranted expectations by senders that publishing SSP will affect what happens to their mail. Exactly. Verifier implementors who do not read the document carefully enough (Shock! Horror! they wouldn't to that would they!) will see all those Verifiers MUST statements and deduce that they are obliged to follow them exactly. Which will discourage them from trying innovative and imaginative techniques which might, in the long term, lead to impprved filtering of 'suspicious' (or even 'not so suspicious') messages. And let me remind you that this thread started exactly because Dave Crocker (who maybe should know better) misread those MUSTs in exactly that way. If even the people on this list can mis-read the draft, then that is a clear indication that its wording needs to be reviewed even though it does, when read carefully, say the right thing. I agree that he chose to read them that way. It sounds like a lot of work to say the same thing to me. I don't think increasing the quantity and type of ways that the draft says it doesn't mandate what receivers will do is a value added use of anyone's time. Extra work that results in implementors making fewer mistakes is NEVER a waste of time. Agreed, but I don't think that's the case here. FYI, here is the wording that I suggested again. It isn't necessarily a pure addition, since it might enable some other less obvious statements of the situation to be taken out: This document describes processes for what verifiers are expected to do in order to achieve what the signers intend. But these descriptions are not Normative since there is no compulsion on verifiers to follow those processes exactly as described, or even at all. Therefore, use of the terms MUST and SHOULD in these descriptions merely indicate the steps verifiers need to take if they want to claim adherence to the particular set of processes described here. I don't think that really changes much. -1 Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
How would doing this work change what verifiers do after the RFC is deployed? Probably not much, but it will help rein in unwarranted expectations by senders that publishing SSP will affect what happens to their mail. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
On Tue, 04 Dec 2007 18:10:37 -, Jim Fenton [EMAIL PROTECTED] wrote: Charles Lindsey wrote: But it has no business whatsoever making normative statements about what verifiers are to do, so wording of the form Verifiers MUST is quite out pf place - that is BCP material. Somehow, we need to tell verifiers what they need to do in order to implement this specification. Nobody is saying that verifiers MUST implement SSP at all, but rather that if they want to implement SSP, this is how they MUST do it. Of course, verifiers are free to implement some other SSP-like thing, even one that acts on SSP records, but I feel we need to provide some precision in the thing we're calling SSP. Then do not use MUST language when speaking of verifiers. Or, alternatively, include wording of the form: This document describes processes for what verifiers are expected to do in order to achieve what the signers intend. But these descriptions are not Normative since there is no compulsion on verifiers to follow those processes exactly as described, or even at all. Therefore, use of the terms MUST and SHOULD in these descriptions merely indicate the steps verifiers need to take if they want to claim adherence to the particular set of processes described here. That essentially modifies the interpretations given in RFC 2119 (and 2119 already implies that such modifications are appropriate in non-normative contexts). There may be better ways to express all this. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
On Wednesday 05 December 2007 08:07, Charles Lindsey wrote: On Tue, 04 Dec 2007 18:10:37 -, Jim Fenton [EMAIL PROTECTED] wrote: Charles Lindsey wrote: But it has no business whatsoever making normative statements about what verifiers are to do, so wording of the form Verifiers MUST is quite out pf place - that is BCP material. Somehow, we need to tell verifiers what they need to do in order to implement this specification. Nobody is saying that verifiers MUST implement SSP at all, but rather that if they want to implement SSP, this is how they MUST do it. Of course, verifiers are free to implement some other SSP-like thing, even one that acts on SSP records, but I feel we need to provide some precision in the thing we're calling SSP. Then do not use MUST language when speaking of verifiers. Or, alternatively, include wording of the form: This document describes processes for what verifiers are expected to do in order to achieve what the signers intend. But these descriptions are not Normative since there is no compulsion on verifiers to follow those processes exactly as described, or even at all. Therefore, use of the terms MUST and SHOULD in these descriptions merely indicate the steps verifiers need to take if they want to claim adherence to the particular set of processes described here. That essentially modifies the interpretations given in RFC 2119 (and 2119 already implies that such modifications are appropriate in non-normative contexts). There may be better ways to express all this. How would doing this work change what verifiers do after the RFC is deployed? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
On Wednesday 05 December 2007 08:53, John Levine wrote: How would doing this work change what verifiers do after the RFC is deployed? Probably not much, but it will help rein in unwarranted expectations by senders that publishing SSP will affect what happens to their mail. It sounds like a lot of work to say the same thing to me. I don't think increasing the quantity and type of ways that the draft says it doesn't mandate what receivers will do is a value added use of anyone's time. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices(draft-ietf-dkim-ssp-01)
On Tue, 04 Dec 2007 16:22:16 -, J D Falk [EMAIL PROTECTED] wrote: Charles Lindsey suggested: And I am still happy to see BCP material which then, essentially, describes ways in which verifiers are expected to apply the advice. A fine idea -- except, how do we list Best Current Practices when there are no current practices yet? The particular practices I have in mind are those already in the draft, but currently confusingly described by the use of 2119-like MUSTard. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
Somehow, we need to tell verifiers what they need to do in order to implement this specification. Nobody is saying that verifiers MUST implement SSP at all, but rather that if they want to implement SSP, this is how they MUST do it. Of course, verifiers are free to implement some other SSP-like thing, even one that acts on SSP records, but I feel we need to provide some precision in the thing we're calling SSP. Exactly right! Please, Jim, keep it up. Folk on this list are confusing what the protocol states MUST be done in order to be implemented with what the protocol's algorithm states MUST be done to a message. Any protocol has to have language with respect to the former. This protocol has NO language with respect to the latter. There is nothing that needs to be done here. Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Review of DKIM Sender Signing Practices(draft-ietf-dkim-ssp-01)
My comments inline below. They can be summarized as follows: 1. SSP does not dictate receiver behavior. SSP bends over backwards to state receiver behavior is at receivers' discretion. If someone can find someplace where SSP dictates receiver behavior please identify it so it can be fixed. 2. Some IETF particiants believe certain SSP statements such as strict and deny are not useful SSP constructs for them. Some are explicit that these constructs would not be used by their own mail servers. However there is a large part of the Internet community that desires these constructs. The brilliance of strict and deny as defined in SSP is that a strict/deny proponent like myself can build a system using the strict/deny data provided by other strict/deny proponents' SSP records AND strict/deny opponents can simply publish unknown, all and process policies and then use their discretion to ignore results related to strict/deny. Everybody wins! I believe it would be an epic mistake for the strict/deny opponents to prevent others from utilizing these capabilities. I have no desire to prevent someone from ignoring strict/deny at their discretion; why can't I have a syntax I desire to state strict/deny for those who will use it? pat PS: SSP does not dicatate receiver behavior :) In general, the draft needs to consider adoption incentives for receivers. My guess is that such an analysis will show that there is a relatively small set of publishers and receivers who are highly motivated to implement the more advanced features -- advanced relative to earlier SSP drafts -- but that true, Internet-scale adoption will be elusive for quite some time. I strongly disagree. There are a significant number of large receivers that are highly motivated to adopt the draft. Take one example: Y! has been public about their work with PayPal to ensure non-delivery of unsigned or invalidly signed DK messages. (I know this is DK but the incentive of SSP is the same for DK or DKIM.) I have been very public about IronPort's desire to implement SSP based on the proxied desires of our customers. The 100 US Financial Services Roundtable companies (BITS) have also been public about their desires in this area. In my opinion, the draft should be broken into an initial core, with optional extensions. The core should define the publication mechanism and the smallest set of features that are deemed useful and likely to receive a broad base of initial adoption. The extensions would target the smaller set of adopters who are viewed as being strongly motivated for these enhancement. The core would be appropriate for direct standardization, while the options would be experimental. Again disagree. I feel the extensions are critical. 1. Signer/Validator practices negotiation scope SSP's description of itself as including how verifiers should... interpret those results states a scope of protocol semantics that is new to the IETF; the protocol is not constrained to interpret with respect to defining what the published information means, but rather is meant to guide, or even mandate, how the mail receive-side participant should handle messages. This is not true. draft-ietf-dkim-ssp-01 states: deny Messages which are Suspicious from this domain MAY be rejected, bounced, or otherwise not delivered at the option of the verifier. There is no mandate here. I believe the IETF has not previously standardized a specification which attempts to have one network participant dictate the internal operating behaviors of another, outside of the protocol interaction itself. As such, efforts in this direction need to be careful, modest and incremental. Again, there is obviously no dictation here. The ability for a sender to state a policy in such a manner that certain receivers find it most beneficial but in a way that does not constrain other receivers is a benefit, not a limitation. 2. Unsigned vs. Mismatched Signature The original SSP specification applied only to unsigned messages. The current version includes mail that is signed but has different domains between the DKIM i= attribute and the rfc2822.From field. Presumably, this new capability overrides whatever reputation is associated with the message signer. If a signer has a good reputation, then why is that not sufficient for enabling delivery? In other words, with a signature of a domain with a good reputation, what threats is SSP trying to protect against? Reputation systems are designed by organizations to optimize delivering good mail and stopping bad mail. They will design the reputation system however they see fit to achieve this goal. The market dynamics and innovation will define reputation systems' design, not SSP. Hypothetical statements about how reputation systems may develop aren't relevant to SSP 6. Signature Semantics DKIM was devised to provide a means of declaring an (organization's)
RE: [ietf-dkim] Review of DKIM Sender Signing Practices(draft-ietf-dkim-ssp-01)
Charles Lindsey suggested: It really needs to back up and define how a sender publishes its policy, how a recipient can look up a policy if it wants to do so, then stop. That's all they need to interoperate. But that is going too far. It covers my #1, but not my #2, which includes important stuff such as the 'strict' and 'deny' features. And I am still happy to see BCP material which then, essentially, describes ways in which verifiers are expected to apply the advice. A fine idea -- except, how do we list Best Current Practices when there are no current practices yet? -- J.D. Falk Receiver Products Return Path ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
Dave Crocker wrote: 2. Unsigned vs. Mismatched Signature The original SSP specification applied only to unsigned messages. The current version includes mail that is signed but has different domains between the DKIM i= attribute and the rfc2822.From field. Presumably, this new capability overrides whatever reputation is associated with the message signer. This is hardly new. In fact, this train has long since left this station as it's in rfc5016: 5.3: 2. SSP MUST provide a concise linkage between the [RFC 2822].From and the identity in the DKIM i= tag, or its default if it is missing in the signature. That is, SSP MUST precisely define the semantics of what qualifies as a first party signature. Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. I don't know why this is being brought up again after it was discussed and issue tracked for the requirements. If a signer has a good reputation, then why is that not sufficient for enabling delivery? In other words, with a signature of a domain with a good reputation, what threats is SSP trying to protect against? SSP doesn't dictate outcome. Never has, never will. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
On Dec 3, 2007, at 3:37 PM, Dave Crocker wrote: 3. Scope and scale of query traffic SSP originally was constrained to apply only to unsigned mail. The current specification applies to unsigned messages *and* signed messages where the DKIM i= domain name does not match the rfc2822.From addr-spec domain. This is a considerable change in the nature -- and potentially a considerable change in the amount of query traffic -- that SSP causes. The desire here is to qualify the From header for transactional messages. The draft does note that initial receive-side adopters of SSP will find no SSP DNS record. However the draft does not address the adoption and use impact of being expected to make a query that will almost always fail for a significant number of years into the future. A policy statement that can be applied more broadly, where benefits extend beyond just qualifying the From header, would suit more than transactional messages. Adding Scope to policy could more broadly apply to all originating headers when handling normal messages. This policy could also clarify what is implied by use of the i= parameter. The current use of the i= parameter is clumsy. Matching the i= parameter precludes use of a g= restricted keys from signing Sender headers to spoof a From header. The ALL or STRICT assertions must constrain the i= parameter to disqualify restricted keys not signing the From header. Adding scope can eliminate these constraints. Attempts at providing a minimal set of assertions has lead to this very sub-optimal policy mechanism this is only suitable for transactional messages. Most domains use the full set of originating headers. There is also a need to partition policy to suit how email is being used. Who is signing is the place to establish such a partition. Users SHOULD NOT see well-known domains use other domains to establish different policies. Policy partitions can transparent by introducing Scope and a TPA-SSP label. These two changes offer significant benefits. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
Dave Crocker wrote: 3. Scope and scale of query traffic SSP originally was constrained to apply only to unsigned mail. The current specification applies to unsigned messages *and* signed messages where the DKIM i= domain name does not match the rfc2822.From addr-spec domain. This is a considerable change in the nature -- and potentially a considerable change in the amount of query traffic -- that SSP causes. This has not changed in years. Maybe you've just become aware of it. And the problem here remains with unsigned traffic. Third party signatures are very rare beasts. The draft does note that initial receive-side adopters of SSP will find no SSP DNS record. However the draft does not address the adoption and use impact of being expected to make a query that will almost always fail for a significant number of years into the future. There is a trivial mechanism that can cut down SSP lookups to almost nothing: don't query domains from which you've never received a valid DKIM signature. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
John Levine wrote: In article [EMAIL PROTECTED] you write: Review of: DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) Wow, thanks for a very thorough review. The biggest problem with this draft is that it goes way beyond defining a protocol. Part of it describes the way that senders publish statements about their sending practices and the way that receivers can look for those statements, which is fine, but the rest attempts to tell receivers what to do with mail they have received, which is not. At this point, making sweeping condemnations is pointless. If you want something in the draft changed, suggest specifics. Better yet: use the ISSUE mechanism for which Eliot is still paying attention, I believe. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
There is a trivial mechanism that can cut down SSP lookups to almost nothing: don't query domains from which you've never received a valid DKIM signature. My network gets tons of fake mail from HSBC UK and no real mail from them since none of my North American users have an account there. How would I be able to tell that it should have been signed? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
John Levine wrote: There is a trivial mechanism that can cut down SSP lookups to almost nothing: don't query domains from which you've never received a valid DKIM signature. My network gets tons of fake mail from HSBC UK and no real mail from them since none of my North American users have an account there. How would I be able to tell that it should have been signed? If nobody cares about HSBC UK, why should you? In any case, this strikes me as a tempest in a well stirred teapot. The load on DNS is similar to SPF/SIDF and the world has continued its normal rotation. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
Charles Lindsey wrote: But it has no business whatsoever making normative statements about what verifiers are to do, so wording of the form Verifiers MUST is quite out pf place - that is BCP material. Somehow, we need to tell verifiers what they need to do in order to implement this specification. Nobody is saying that verifiers MUST implement SSP at all, but rather that if they want to implement SSP, this is how they MUST do it. Of course, verifiers are free to implement some other SSP-like thing, even one that acts on SSP records, but I feel we need to provide some precision in the thing we're calling SSP. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
There is a trivial mechanism that can cut down SSP lookups to almost nothing: don't query domains from which you've never received a valid DKIM signature. My network gets tons of fake mail from HSBC UK and no real mail from them since none of my North American users have an account there. How would I be able to tell that it should have been signed? If nobody cares about HSBC UK, why should you? Uh, because SSP is supposed to be able to help me tell that it's a phish? I can't believe you're saying that I should just deliver phishes if I don't think anyone's likely to fall for them, but it's hard to assign a different meaning to your question. As it happens, lots of people around here have HSBC US accounts, the two banks' branding is nearly identical, and it's not absurd to worry that if someone put HSBC US account info into the HSBC UK phish, the bad guys would be able to make use of it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
Michael Thomas wrote: At this point, making sweeping condemnations is pointless. If you want something in the draft changed, suggest specifics. Better yet: use the ISSUE mechanism for which Eliot is still paying attention, I believe. Indeed I am. All you need to do to create an issue is to send a note to this list with the subject NEW ISSUE and I will track it. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
John L wrote: As it happens, lots of people around here have HSBC US accounts, the two banks' branding is nearly identical, and it's not absurd to worry that if someone put HSBC US account info into the HSBC UK phish, the bad guys would be able to make use of it. This assumes that SSP tries to solve the lookalike domain problem. It doesn't. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
John L wrote: This assumes that SSP tries to solve the lookalike domain problem. Can we review the last couple of messages, please? You said that a way to avoid making useless SSP lookups was only look up a domain if you've previously seen a signed message from it. I said, I get a bunch of messages purporting to be from a bank I've never seen before. This isn't lookalike, this uses the actual domain (in this case hsbc.co.uk) but since I've never seen any mail from them before, good or bad, I won't do the lookup and I'll never know that their SSP says they sign all their mail. You said: As it happens, lots of people around here have HSBC US accounts, the two banks' branding is nearly identical, and it's not absurd to worry that if someone put HSBC US account info into the HSBC UK phish, the bad guys would be able to make use of it. hsbc.co.uk != hsbc.com. That they have layer 8+ ties to one another is not a problem SSP is trying to solve. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
Eric Allman responding to Dave's Review: * Several places you compare this version (unfavorably) to the original SSP specification. Which one would that be? There was _policy in DK, and some stuff in draft-allman-dkim-base that got pulled out, but I don't recall anything that got further than a very rough draft. Personally, I thought the original draft was very clear and concise. It simply lacked the 3rd party issues. * Several places you refer to reputation. But if I recall correctly we explicitly avoided using that word, at least in part because it's only one of a number of mechanisms. Making an assumption that SSP will be backed up by reputation dramatically expands the scope of the document in a way that doesn't seem productive. +1 * You seem to think that doing SSP lookups on third-party signatures will increase traffic dramatically. I don't think that's at all clear. By far the majority of the SSP traffic in the short run will be for messages that have no signature at all. In the longer run it comes down to what percentage of email traffic is one-to-some (i.e., a first-party signature) vs. how much goes through mailing lists or other cases that would have third-party signatures. Of course, the majority of email will be spam/phishes, and that's a bit harder to predict since they change so fast, but my first guess is that most of it will be unsigned and hence require an SSP lookup anyway. +1, There is a double edge sword here and I think it all depends on the type of policy domains begin or leans towards using, which is why I had an itch with the SSP only required if no signature and Ignore if Failure concept. The logical and reasonable premise is: Short Run -- More SSP lookups Long Run -- Less SSP Lookups The long run will include a higher rate of fraud, especially if there is relaxed policies which is the default, hence, most likely the long run will include more or equal me amount unsigned fraud attempts. IOW, the bad guy does not have to adapt to anything related to DKIM or relaxed policies. The more stronger policies exist, theoritcally we will get less fraud. However, two things might occur with the bad: a) Since there are more stronger policies, all he needs to do is create a fake signature. It doesn't have to be correct, and b) begin to target non-supportive DKIM/SSP systems. Therefore, IMO, there might be a tendency to do an SSP first in all cases (of course, the better system will cache this) to address the long run potential of higher fraud. IOW, short or long run, if the majority are relaxed policies, the bad guy doesn't had to anything. He doesn't need to adapt. We only begin to see a shift, a change in pattern as the policies become stronger. * You seem to think that declaring messages that come from domains that are not accessible (i.e., a reply would fail with NXDOMAIN) make(s) it clear that SSP has moved seriously into more general aspects of receive-side analysis. However, this step is required to make the algorithm work; without it there is an obvious security hole. However, I do agree that a flowchart would help. I think I have a fairly current around somewhere already, but it's not in ASCII. +1, the same applies to DKIM in the long run. The more DKIM signatures, the more potential for NXDOMAIN key lookups. This is partly why an upfront SSP lookup can assist in the process. The whole theory of DKIM success is based on the premise that in the long run, it will be standard practice to have DKIM VALID signatures in the majority of messages. The theory breaks down when the long run includes a signficant amount of invalid signatures. So SSP or no SSP, there will be a drastic overhead problem in HASH computation. In my view, the optimization will make it prudent that: - SSP is lookup first, and - we have stronger policies. The only argument against SSP being looked first, is when we have network wide design assumption of: invalid signatures valid signatures. But what if the long run shows? invalid signatures valid signatures. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
In article [EMAIL PROTECTED] you write: Review of: DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) Wow, thanks for a very thorough review. The biggest problem with this draft is that it goes way beyond defining a protocol. Part of it describes the way that senders publish statements about their sending practices and the way that receivers can look for those statements, which is fine, but the rest attempts to tell receivers what to do with mail they have received, which is not. It really needs to back up and define how a sender publishes its policy, how a recipient can look up a policy if it wants to do so, then stop. That's all they need to interoperate. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
On Monday 03 December 2007 23:23, John Levine wrote: In article [EMAIL PROTECTED] you write: Review of: DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) Wow, thanks for a very thorough review. The biggest problem with this draft is that it goes way beyond defining a protocol. Part of it describes the way that senders publish statements about their sending practices and the way that receivers can look for those statements, which is fine, but the rest attempts to tell receivers what to do with mail they have received, which is not. It really needs to back up and define how a sender publishes its policy, how a recipient can look up a policy if it wants to do so, then stop. That's all they need to interoperate. -1 While senders certainly can't dictate receiver policy, giving an indication of what they expect to have happen is perfectly reasonable and reduces uncertainty. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
