Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
On 6/20/2014 12:13 AM, Stephen J. Turnbull wrote: Hector Santos writes: > The DNS-based author domain defined policy is the only common > approach we have now. "To a man with a hammer, every problem looks like a nail." Yes, indeed, in this case, it is that simple -- Occam's razor. Quite often, a hammer is all this is needed. -- Hector Santos http://www.santronics.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
Hector Santos writes: > The DNS-based author domain defined policy is the only common > approach we have now. "To a man with a hammer, every problem looks like a nail." But unfortunately, use of strict policy in the current environment can be antisocial behavior, and therefore it is going to be ignored (as a policy) by socially responsible recipients. Viz, GMail.[1] And it leads to avoidance behavior (From-corruption, encapsulation) by third parties (at least mailing lists). "Avoidance" is also anti-social IMO, even though it's my constituency that's doing it. Those same socially responsible recipients will, of course, use it as an (important) input into their *heuristic, reputation-based* decisions about filtering. Viz. again, GMail. Third-party authorization just pushes the heuristic, reputation-based decision-making off onto the third parties you want to authorize, and doesn't scale to precisely the large mailbox providers who can cause widespread consternation by publishing "p=reject" policies. Footnotes: [1] While I have my reservations about the CSR of all billion-dollar companies, including Google, GMail's handling of p=reject is socially responsible behavior. IMHO YMMV. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
Let me clarify it. From a deterministic protocol standpoint, depending only on base signing analysis has no payoff, i.e. no filtering is legitimately possible with high confidence and zero/low false positive. What is left is non-deterministic, heuristic, classification Bayesian scoring, learning, "fuzzy, neural net, expert system" and similar AI-like logic methods, including SA like methods. Sure, you can learn from weighting indeterminate results. But it's not deterministic, not 1 nor 0, but in between. Not yes/no, but maybe. I agree this method were always possible, and expected it in order to deal with these unknowns "in-between" results, the ones that result from relaxed or no policies. The only real issue with this method is that it's not shareable. It could not be a network persistent and consistent protocol method unless there was a centralized repository concept/service everyone can check with similar results. If a site depends on such a method, then the sites that do no sign up for this central reputation lookup service will become targets. It has long been shown that bad guys do target "weaker" sites especially when it's well known a common reputation method doesn't exist in practice for everyone to use. The DNS-based author domain defined policy is the only common approach we have now. -- Hector Santos http://www.santronics.com > On Jun 19, 2014, at 2:45 PM, "Murray S. Kucherawy" > wrote: > >> On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos wrote: >> While DKIM-BASE tried to clean up this separation of the author domain >> policy, it could not because of all the past existing ADSP or SSP references >> in the many DKIM related RFCs, see RFC6376, section 1.1. But conceptually, >> it didn't matter what you called it. It was an author domain signing policy >> protocol and today, it's called DMARC. DKIM has no payoff with just base >> signing analysis . It was separated but with all the intentions of sticking >> secondary author policy and signer trust layers on it before a payoff was >> realized. > > There are reputation systems -- I built one, and I know others exist -- that > use DKIM as the identifier on which reputation is built, and they've been > effective in experimental environments at identifying what's good and what's > outside of "good". > > The difference here is between active and passive determination of what's > good and what's not good. If you want active, I agree that DKIM by itself > isn't enough. But I disagree, with evidence, that DKIM "has no payoff with > just base signing analysis". > > If that's not convincing enough, consider that IP reputation has been largely > successful, and the input to such systems is a verified identifier, which is > the same class of output DKIM provides. > > -MSK > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
On Thu, Jun 19, 2014 at 12:36 PM, Douglas Otis wrote: > Our company has had extensive experience dealing with email spoofing. > While reputation is able to deal with bulk spamming, it is ineffective at > dealing with a phishing problem, the intent behind DMARC. It is a basic > information issue. Those offering a reputation for a domain have no way to > judge which of their identifiers are being spoofed for messages handled by > third-parties. Only the spoofed domain can be considered authoritative. > To suggest otherwise implies the sharing of PII, which is not acceptable > in many regions. > DKIM coupled with reputation can only tell you if a given message was handled by a source with a good reputation. It doesn't evaluate any visible identifiers. I don't really understand the rest of what you're talking about here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
On Jun 19, 2014, at 11:45 AM, Murray S. Kucherawy wrote: > On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos wrote: > While DKIM-BASE tried to clean up this separation of the author domain > policy, it could not because of all the past existing ADSP or SSP references > in the many DKIM related RFCs, see RFC6376, section 1.1. But conceptually, > it didn't matter what you called it. It was an author domain signing policy > protocol and today, it's called DMARC. DKIM has no payoff with just base > signing analysis . It was separated but with all the intentions of sticking > secondary author policy and signer trust layers on it before a payoff was > realized. > > There are reputation systems -- I built one, and I know others exist -- that > use DKIM as the identifier on which reputation is built, and they've been > effective in experimental environments at identifying what's good and what's > outside of "good". > > The difference here is between active and passive determination of what's > good and what's not good. If you want active, I agree that DKIM by itself > isn't enough. But I disagree, with evidence, that DKIM "has no payoff with > just base signing analysis". > > If that's not convincing enough, consider that IP reputation has been largely > successful, and the input to such systems is a verified identifier, which is > the same class of output DKIM provides. Dear Murray, Our company has had extensive experience dealing with email spoofing. While reputation is able to deal with bulk spamming, it is ineffective at dealing with a phishing problem, the intent behind DMARC. It is a basic information issue. Those offering a reputation for a domain have no way to judge which of their identifiers are being spoofed for messages handled by third-parties. Only the spoofed domain can be considered authoritative. To suggest otherwise implies the sharing of PII, which is not acceptable in many regions. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos wrote: > While DKIM-BASE tried to clean up this separation of the author domain > policy, it could not because of all the past existing ADSP or SSP > references in the many DKIM related RFCs, see RFC6376, section 1.1. But > conceptually, it didn't matter what you called it. It was an author domain > signing policy protocol and today, it's called DMARC. DKIM has no payoff > with just base signing analysis . It was separated but with all the > intentions of sticking secondary author policy and signer trust layers on > it before a payoff was realized. > There are reputation systems -- I built one, and I know others exist -- that use DKIM as the identifier on which reputation is built, and they've been effective in experimental environments at identifying what's good and what's outside of "good". The difference here is between active and passive determination of what's good and what's not good. If you want active, I agree that DKIM by itself isn't enough. But I disagree, with evidence, that DKIM "has no payoff with just base signing analysis". If that's not convincing enough, consider that IP reputation has been largely successful, and the input to such systems is a verified identifier, which is the same class of output DKIM provides. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
Let us remember that DKIM+Policy were separated into two protocols; a DKIM-BASE layer and a secondary domain signing practice layer (SSP which evolved to ADSP). Making an invalid signature equal to a missing signature concept was a security logic which allowed for the exclusive or strict signing domain policies to exist and work with one single short circuiting policy handling state/event condition: If policy.strict and signature.missing or invalid then negatively classify; You must make invalid be the same as missing from a rejection or functional equivalent negative classification standpoint otherwise you have a security loophole. While DKIM-BASE tried to clean up this separation of the author domain policy, it could not because of all the past existing ADSP or SSP references in the many DKIM related RFCs, see RFC6376, section 1.1. But conceptually, it didn't matter what you called it. It was an author domain signing policy protocol and today, it's called DMARC. DKIM has no payoff with just base signing analysis . It was separated but with all the intentions of sticking secondary author policy and signer trust layers on it before a payoff was realized. -- Hector Santos http://www.santronics.com > On Jun 19, 2014, at 12:49 PM, S Moonesamy wrote: > > Hi Matt, > At 18:58 15-06-2014, Matt Simerson wrote: >> Yes, it does. But SA uses the results of Mail::DKIM heuristically and a DKIM >> failure is frequently not a sufficient basis for rejection. > > During the (old) DKIM discussions there was a view that the result of a DKIM > verification was to be used as input for policy decisions. That is similar > to the above. This was also discussed on a SMTP mailing list [1]. There is > the following recommendation in RFC 6376: > > "Therefore, a Verifier SHOULD NOT treat a message that has one or more > bad signatures and no good signatures differently from a message with > no signature at all." > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/mail-archive/web/ietf-smtp/current/msg01487.html > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
Hi Matt, At 18:58 15-06-2014, Matt Simerson wrote: Yes, it does. But SA uses the results of Mail::DKIM heuristically and a DKIM failure is frequently not a sufficient basis for rejection. During the (old) DKIM discussions there was a view that the result of a DKIM verification was to be used as input for policy decisions. That is similar to the above. This was also discussed on a SMTP mailing list [1]. There is the following recommendation in RFC 6376: "Therefore, a Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all." Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/ietf-smtp/current/msg01487.html ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
>Yes, it does. But SA uses the results of Mail::DKIM heuristically and a DKIM >failure is frequently not a >sufficient basis for rejection. I should hope not. The DKIM spec is crystal clear that an invalid signature is equivalent to no signature. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
John Levine writes: > >Spamassassin does not pretend to be a DKIM (or DMARC) policy engine, > >so of course it "accepts" weak signatures. It accepts invalid and > >nonexistent signatures, too. > > No, it doesn't. It calls Mail::DKIM to validate the signatures. Indeed, it validates the signatures. I should have written "'accept' and 'reject' are not appropriate for use in discussing SpamAssassin's processing at the level of message features". The question I'd like to ask is "how hard would it be to get SpamAssassin to evaluate the features it knows about (eg, 'valid DKIM signature') in conformance with each of the proposals?" That is, is it possible for SpamAssassin to independently assign a score (presumably a fairly large negative one) to the specific feature - This field is DKIM-Delegate to example.com, AND - there is a valid DKIM signature from example.com for the whole message body and appropriate headers, AND - the DKIM-Delegate field is signed with a valid signature, AND - RFC5322.From is aligned with the valid signature on DKIM-Delegate and other such (complex) features? Is it more straightforward if DKIM-Delegate is self-signed as I proposed? Etc. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
On Jun 15, 2014, at 6:02 PM, John Levine wrote: >>> Your plan, as I understand it, was that verifiers will ignore a >>> signature that is too weak. One might argue clients that accept weak >>> signatures are already broken, but in that case there are an awful lot >>> of broken clients, starting with spamassassin. (I just checked.) >> >> Spamassassin does not pretend to be a DKIM (or DMARC) policy engine, >> so of course it "accepts" weak signatures. It accepts invalid and >> nonexistent signatures, too. > > No, it doesn't. Yes, SpamAssassin does "accept" weak, invalid, and nonexistent signatures. > It calls Mail::DKIM to validate the signatures. Yes, it does. But SA uses the results of Mail::DKIM heuristically and a DKIM failure is frequently not a sufficient basis for rejection. http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Plugin_DKIM.html Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
> > Your plan, as I understand it, was that verifiers will ignore a > > signature that is too weak. One might argue clients that accept weak > > signatures are already broken, but in that case there are an awful lot > > of broken clients, starting with spamassassin. (I just checked.) > >Spamassassin does not pretend to be a DKIM (or DMARC) policy engine, >so of course it "accepts" weak signatures. It accepts invalid and >nonexistent signatures, too. No, it doesn't. It calls Mail::DKIM to validate the signatures. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
John Levine writes: > >I do not understand this predilection for trying to change the DKIM base > >engine. It doesn't need it. > > Actually, I claim that a version bump is the approach least likely to > break existing clients. The point is to avoid breaking the anti-spam *system*. If the system continues to work (in some appropriate sense) in the presence of clients "broken" in some sense, that's a win. > I think we agree that the goal here is to have a weak signature that > verifiers disregard unless it's associated with a delegated signature. > Your plan, as I understand it, was that verifiers will ignore a > signature that is too weak. One might argue clients that accept weak > signatures are already broken, but in that case there are an awful lot > of broken clients, starting with spamassassin. (I just checked.) Spamassassin does not pretend to be a DKIM (or DMARC) policy engine, so of course it "accepts" weak signatures. It accepts invalid and nonexistent signatures, too. By this I suppose you mean that spamassassin does not distinguish among levels of content coverage of signatures it detects and verifies, so different spamminess coefficients can't be assigned? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
signatures are already broken, but in that case there are an awful lot of broken clients, starting with spamassassin. (I just checked.) Out of curiousity, did you try having two signatures in various different orders and combinations of validity? No, but from looking at the code, I don't think that would matter. It makes a table of the signatures (just the valid ones, I believe) and then applies various rules about signers and pseudo-ADSP. Exactly why I think that as long as we're bumping the version, building in some additional extensibility seems like a really good idea. The only question is how much and in what form. Suggestions welcome. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
> >I do not understand this predilection for trying to change the DKIM base > >engine. It doesn't need it. > Actually, I claim that a version bump is the approach least likely to > break existing clients. > >I also don't understand the construct of 'special handling', never mind > >not liking the idea of it, especially since it explicitly creates the > >complexity of "depends on the header field". > I think we agree that the goal here is to have a weak signature that > verifiers disregard unless it's associated with a delegated signature. > Your plan, as I understand it, was that verifiers will ignore a > signature that is too weak. One might argue clients that accept weak > signatures are already broken, but in that case there are an awful lot > of broken clients, starting with spamassassin. (I just checked.) Out of curiousity, did you try having two signatures in various different orders and combinations of validity? Mind you, even if this leads to a way of structuring these things that "works" for the current crop of clients, I would not be inclined to trust it. I'm just curious. > Until now there's been no reason other than playing games to use weak > signatures, so in practice it hasn't mattered. Now it does, so > clients have to change their code to check for "too weak", probably in > inconsistent ways, to check for l= and what headers are signed and so > forth. Agreed. Like it or not, this calls for, let's call it a "clarification" of existing DKIM semantics. And to do that you either bump the version or overload some other existing field in the protocol. > Murray's trick, add a new canonicalization that's only valid if > there's a paired signature, many not require a version bump, but to be > useful it does require a change to the verifier library interfaces. Six of one, half a dozen of the other. > Libraries and clients are not upgraded in sync, so there will be old > clients calling upgraded libraries. The libraries can't just accept > the new canon and return "valid", since old clients won't know to look > for the paired signature. They can't return "conditionally valid", > since clients won't know what to do with it. So the libraries will > need a new entry point, or at least a new option, for the client to > say that it understands a conditionally valid result. A few moments > thought should confirm that's semantically the same as an option for a > client to say it understands v2 signatures, just kludgier. Exactly. > With respect to Stephen's concern about libraries knowing when to > construct v1 or v2 signatures, really, that's no big deal. We've been > doing that sort of stuff for version bumps since approximately > forever, and it's a nit compared to the other stuff it'll have to do > to interpret the conditional signatures. > It also occurs to me that there are all sorts of ways that a > conditionally valid signature would be useful. For example: > * valid if this DNS lookup resolves, for per-signature revocation > * valid if the body has this S/MIME signature, to allow for list > software that reformats the message but keeps the signed body part > (mailman and mj2, for example) or that resigns with its own S/MIME > signature (sympa) > * valid if the body has this PGP signature (mailman's working on it) > Some of these can be done with kludges, but most can't. Exactly why I think that as long as we're bumping the version, building in some additional extensibility seems like a really good idea. The only question is how much and in what form. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version
>I do not understand this predilection for trying to change the DKIM base >engine. It doesn't need it. Actually, I claim that a version bump is the approach least likely to break existing clients. >I also don't understand the construct of 'special handling', never mind >not liking the idea of it, especially since it explicitly creates the >complexity of "depends on the header field". I think we agree that the goal here is to have a weak signature that verifiers disregard unless it's associated with a delegated signature. Your plan, as I understand it, was that verifiers will ignore a signature that is too weak. One might argue clients that accept weak signatures are already broken, but in that case there are an awful lot of broken clients, starting with spamassassin. (I just checked.) Until now there's been no reason other than playing games to use weak signatures, so in practice it hasn't mattered. Now it does, so clients have to change their code to check for "too weak", probably in inconsistent ways, to check for l= and what headers are signed and so forth. Murray's trick, add a new canonicalization that's only valid if there's a paired signature, many not require a version bump, but to be useful it does require a change to the verifier library interfaces. Libraries and clients are not upgraded in sync, so there will be old clients calling upgraded libraries. The libraries can't just accept the new canon and return "valid", since old clients won't know to look for the paired signature. They can't return "conditionally valid", since clients won't know what to do with it. So the libraries will need a new entry point, or at least a new option, for the client to say that it understands a conditionally valid result. A few moments thought should confirm that's semantically the same as an option for a client to say it understands v2 signatures, just kludgier. With respect to Stephen's concern about libraries knowing when to construct v1 or v2 signatures, really, that's no big deal. We've been doing that sort of stuff for version bumps since approximately forever, and it's a nit compared to the other stuff it'll have to do to interpret the conditional signatures. It also occurs to me that there are all sorts of ways that a conditionally valid signature would be useful. For example: * valid if this DNS lookup resolves, for per-signature revocation * valid if the body has this S/MIME signature, to allow for list software that reformats the message but keeps the signed body part (mailman and mj2, for example) or that resigns with its own S/MIME signature (sympa) * valid if the body has this PGP signature (mailman's working on it) Some of these can be done with kludges, but most can't. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
