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 "MUST"s 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)
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 "MUST"s 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)
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. Sorry, "MUST be done to a message" in the sense of dictating ultimate disposition thereof. 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)
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)
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)
>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 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 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 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)
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)
I'm going to reply to this message twice. This is a short note, but given the size of your critique and the fact that we got less than 24 hours to look at it before the meeting, I'm planning on doing a more detailed reply later. Briefly, please consider Patrick Peterson's response dated 12/4 02:18:51 AM to be included here. I agree with the gist of everything he and other people such as Scott and Wietse have to say. * 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. * You obviously dislike the way SSP handles multiple From field addresses, and yet you offer no alternative. I don't like it either, but just complaining isn't constructive. I will point out that using Sender: was considered and rejected, so unless we want to reexamine that, that's not the answer either. * I agree with the folks who say that "Suspicious" is simply a defined term in this document, and (as in any contract) it doesn't necessarily carry the connotative baggage of broader language. None the less I'm not wedded to that word; we can call it "Orange" if we want. * 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. * 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. * You suggest moving _ssp out of the _domainkey subdomain. However, I think it's worthwhile having it there in the event that the _domainkey subdomain is delegated. It seems logical to keep everything together. * 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. OK, that's it for comments for now. And really, this /is/ the short version. eric ___ 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)
hsbc.co.uk != hsbc.com. That they have layer 8+ ties to one another is not a problem SSP is trying to solve. Right. So forget that digression. 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. Apparently, detecting forgery of exact domain names isn't a problem that SSP is trying to solve either, unless you already happen to know that the domain signs their mail. I get a bunch of mail purporting to be from some bank. You said that since I've never seen any signed mail from them, don't bother to look up their SSP. Huh? 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 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)
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 then said well, if it's not a bank your users use, why do you care? I still have trouble reading that as other than deliver the phish if you don't think your users will be fooled. How exactly is your heuristic supposed to work? 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 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)
On Dec 4, 2007, at 9:49 AM, Michael Thomas wrote: 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? While clearly not a homogeneous world, a great many our customers care. 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. A single SSP record should have equal, and often significantly less overhead than SPF/SIDF (as typically used). An SSP transaction would be several orders of magnitude less than exploited macro expansions of SPF records. :^( That said, DKIM itself introduces a significant resource overhead. A well-known domain would be able to vouch for unknown domains when TPA- SSP is used. Conversely, TPA-SSP records also permit a common signing domain to be authorized by thousands of less well-known domains. This ability might be important when DKIM signatures are selectively evaluated, due to just DKIM's base overhead. Many systems are currently overwhelmed by abuse. Eyes may roll when suggesting addition of a resource intensive DKIM process. It is very likely resources needed for DKIM will be used selectively. There must be a bang for the buck. Those who ferret out phish may not understand every corner of world. The current SSP policy statement can help train how these filters should operate, without being checked when every message is received. Anti-phishing often needs to examine content look and feel, where SSP policy assertion might help prevent some false positives. On its own, even when expressed as Strict, this SSP policy will not prevent phishing. Strict policy can raise the bar, but without TPA-SSP, this Strict policy will likely create an unfortunate proliferation of email-addresses using some sub-domain of the otherwise well-known domain. A profusion of domain names will create more confusion for the average user and likely making them more prone. -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)
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)
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)
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)
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)
> 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: 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)
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 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)
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 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: 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)
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)
On Tue, 04 Dec 2007 04:23:27 -, John Levine <[EMAIL PROTECTED]> wrote:
The biggest problem with this draft is that it goes way beyond
defining a protocol.
True. Essentially. we have standards track documents and we have BCP (Best
Current Practice) documents, and indeed SSP could have been published as a
standards/BCP pair. However, I accept that including BCP material in a
standards track document is often more convenient and is reasonable
*provided* it is clearly delineated from the normative stuff.
So SSP can clearly define, Normatively, what signers can say in their SSP
records, and in what notation, and can say what their statements "mean"
(that is, the semantics). Thus SSP supplies a mechanism for signers to
transmit information with defined meaning to verifiers (and anyone else
who cares to look at it); and defining such mechanisms is exactly what
IETF standards are all about.
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.
{Actually, RFC 2119 does admit, in its usual woolly sort of way, that
MUST/SHOULD/MAY might be interpreted differently in non-standard
documents, so you might define those words as having a different
interpretation in BCP sections.}
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.
What it does (or should do) is to define, Normatively, what SSP signers
can say. That seems to cover two areas:
1. This is what we *do* (or do not do) when signing (or not) things.
2. This is what we *advise* (or even "expect") verifiers to do with the
information we provide.
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".
--
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)
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 > >
RE: [ietf-dkim] Review of DKIM Sender Signing Practices(draft-ietf-dkim-ssp-01)
> 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. For the 1000th time this is simply not true. Repeatedly stating SSP "dicates receiver behavior", "tells receivers what to do", etc doesn't make it true. I found two statements that advise receivers. They state: "The handling of such messages is at the discretion of the Verifier or final recipient." (Suspicious definition) "Messages which are Suspicious from this domain MAY be rejected, bounced, or otherwise not delivered at the option of the verifier." (deny) Here is the text from SSP that defines this guidance to receivers: 2.9. Suspicious Messages that do not contain a valid Originator Signature and which are inconsistent with a Sender Signing Practices check (e.g., are received without a Valid Signature and the sender's signing practices indicate all messages from the domain are signed) are referred to as "Suspicious". The handling of such messages is at the discretion of the Verifier or final recipient. "Suspicious" applies only to the DKIM evaluation of the message; a Verifier may decide the message should be accepted on the basis of other information beyond the scope of this document. Conversely, messages not deemed Suspicious may be rejected for other reasons. [There are other mentions of when to declare a message Suspicious but I reference the instructions to the receiver found here in the definition.] 4.3 Record Syntax ... deny Messages which are Suspicious from this domain MAY be rejected, bounced, or otherwise not delivered at the option of the verifier. NON-NORMATIVE EXPLANATION: The "deny" practice is intended for use by domains that value security over deliverability. For example, a domain used by a financial institution to send transactional email, which signs all of its messages, might consider their concern about phishing messages purporting to come from their domain to be higher than their concern about some some legitimate messages not being delivered. The "handling=deny" practice allows them to express that concern in a way that can be acted upon by verifiers, if they so choose. > 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. Many disagree. How about we let people publish their strict/deny preferences and those who wish to look up a policy and do nothing else to interoperate simply ignore strict/deny as allowed by SSP? pat ___ 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
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
