Subject: Re: DKIM Signatures now being applied to IETF Email

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 1 Aug 2011 08:48:04 -0400

I find it amazing how many different ways there are to criticize DKIM for not doing something it was never intended to do.  DKIM is a small building block that enables new functionality, but such functionality is beyond the scope of DKIM.

DKIM does one thing, and one thing only:  It uses a cryptographic signature to associate a domain with a message.  By doing so, it creates strong evidence that the message passed through that domain at some point and has not been significantly modified since.

Whether that domain is good guys or bad guys, senders or resenders, Coke or Pepsi, is completely irrelevant.  It is a small nugget of evidence to provide an anchor point for forensics stronger than what have come before.  It tells us that the named domain considered the message reasonable to send or resend, for its own reasons -- its own forensic evidence, its nefarious intent, or the phase of the moon.  With such an anchor, we can begin to build stronger and more robust systems for analyzing the desirability of messages, as we are now trying to do in the REPUTE work, because it allows us to push our forensic analysis upstream a bit.  It does not relieve downstream software of the need to decide how to feel about the signing domain, whether it's a spammer, a copy-cat, or anyone else.

If, for example, the IETF mailing list software only allows posting by list members, but itself trusts the sender's header fields, then an IETF DKIM signature tells me only that the IETF servers think a message passed that test.  That's obviously not perfect, but it's slightly stronger than what came before -- it is still possible to forge a message before sending it to the list, but much harder to forge a message to look as if it came from the list exploder.  That is progress -- very very small, slow, progress.  If, at some point, the list exploder starts only passing through messages that themselves have valid DKIM signatures, it will be significantly more progress, but it won't do anything to stop a spammer from subscribing to the IETF list and DKIM-authenticating himself.  For that we'll need reputation information -- another small step, which we're trying to initiate with REPUTE.

We've had a long history of grand plans for user authentication on the Internet.  Those plans have largely failed.  I think an incremental approach like DKIM has a better chance, but it is obviously vulnerable to being dismissed by those who see a small improvement as not worth bothering with.  The best is the enemy of the good.  -- Nathaniel

On Jul 31, 2011, at 6:12 AM, Hector Santos wrote:

> You continue to not comprehend (or rather ignore) what continues to plaque DKIM - the lack of fault detection. Its why it continues to have a hard time and have people who actually believe in this promising protocol "bitch" about it.  If these "big email" providers (or anyone for that matter) begin to make assertions about what is good about their mail then they better be ready for the violations of such assertions to be rejected.  You can't have it just one way and mandate this is the only way to process this overhead - looking for good mail only and ignoring all the violations and illogically treating it like it was never signed or compromised or attempted to be compromised.
> 
> The overall difficulty is that originality is lost - the original author or dkim signer has lost or lacks any protocol guidance to tell resigners that the mail they are about the process might be bad - according to the original author domain.
> 
> If the resigner is going to intentionally and neglectfully ignore all original claims about the original domain signing practice, then how do you expect the anonymous "copy-cat" abuse to be controlled?
> 
> 
> Murray S. Kucherawy wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of t.petch
>>> Sent: Saturday, July 30, 2011 3:26 AM
>>> To: Barry Leiba
>>> Cc: ietf
>>> Subject: Re: DKIM Signatures now being applied to IETF Email
>>> 
>>> Sadly, I do not see it being used in the mailing lists where an
>>> organisation is sending me directly data I would like to be able to rely on
>>> - which I think fits the applicability well - and instead, I see it
>>> being used on a mailing list such as those in the IETF where I
>>> believe that the costs outweigh the benefits - and I have no choice
>>> about that:-(.
>> There has been some post-DKIM talk recently about the idea of "transient trust", wherein (to use this example) ietf.org would verify the signature on an arriving list submission, attach an RFC5451 header field that indicates the results of that verification, then send the message out to the list with that added field and a new ietf.org signature that "covered" it.  Then, if you decide to believe ietf.org's claims about the original signature, you know more than you would otherwise.
>> This hasn't been widely deployed yet, but some big email providers are currently playing with the idea.
>> _______________________________________________
>> Ietf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> -- 
> Hector Santos, CTO
> http://www.santronics.com
> http://santronics.blogspot.com
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 1 Aug 2011 11:41:29 -0400

On Monday, August 01, 2011 08:48:04 AM Nathaniel Borenstein wrote:
> I find it amazing how many different ways there are to criticize DKIM for
> not doing something it was never intended to do.  DKIM is a small building
> block that enables new functionality, but such functionality is beyond the
> scope of DKIM.
> 
> DKIM does one thing, and one thing only:  It uses a cryptographic signature
> to associate a domain with a message.  By doing so, it creates strong
> evidence that the message passed through that domain at some point and has
> not been significantly m

...

In fairness to Hector, the functionality that he is complaining is missing was 
part of the original working group charter.  I think it's unfortunate (and I 
said so at the time) that the group chose to define a core DKIM protocol first 
and then attempt to bolt a policy mechanism on afterwards.  It's rather not 
suprising it didn't work out well (ADSP).

So you are correct, it does one thing and one thing only, but that's because 
the WG decided to build it that way, not because the WG was limited to that.  

Of course, now, it is what it is and there's no changing that, but I also 
think it's reasonable to think it could have been done better.

Scott K

P.S. It's possible I may mis-remember WG versus pre-WG discussions here, but 
either way it was a poor (IMO) way to attempt to tackle the work.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 1 Aug 2011 11:50:27 -0700

My own recollection is that the working group originally had policy ideas in its charter, but as we went through the work it became evident that doing DKIM policy was increasingly hard to get right without creating something unreliable or even damaging to the current infrastructure.  Thus, I think the separation in scope became necessary as the base protocol developed and matured.

Unfortunately, there are a those who cling tenaciously to the original view and scope, and thus assert that anything less than the original goal set means DKIM is a failure.  But, also unfortunately, no workable solution has yet to be presented.

Nathaniel's statement is right on the money: DKIM, in its current form, is an important development enabling some important new functionality.  Rather than harping on the cruft that was cut away from DKIM along its path, we should be focusing on the new stuff, as that's what we really need, and that's what stands the greatest chance of success going forward.

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Aug 2011 14:59:40 -0400

> Nathaniel's statement is right on the money: DKIM, in its current form, is an important development enabling some important new functionality.  Rather than harping on the cruft that was cut away fr…

Perhaps.  But it's difficult to escape the impression that this is another example of IETF failing to solve an important problem by focusing on a portion of the problem that's easy to solve, and ruling the difficult part out of scope for the time being.  Repeat as needed; you can always partition the remaining part of the problem again.

Keith

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 1 Aug 2011 15:02:39 -0400

On Monday, August 01, 2011 02:50:27 PM Murray S. Kucherawy wrote:
> My own recollection is that the working group originally had policy ideas
> in its charter, but as we went through the work it became evident that
> doing DKIM policy was increasingly hard to get right without creating
> something unreliable or even damaging to the current infrastructure. 
> Thus, I think the separation in scope became necessary as the base
> protocol developed and matured.
> 
> Unfortunately, there are a those who cling tenaciously to the original view
> and scope, and thus assert that anything less than the original goal set
> means DKIM is a failure.  But, also unfortunately, no workable solution
> has yet to be presented.
> 
> Nathaniel's statement is right on the money: DKIM, in its current form, is
> an important development enabling some important new functionality. 
> Rather than harping on the cruft that was cut away from DKIM along its
> path, we should be focusing on the new stuff, as that's what we really
> need, and that's what stands the greatest chance of success going forward.

I agree.  The one thing I don't agree with in his statement is the never part 
of "... criticize DKIM for not doing something it was never intended to do."  
It is what it is, for better or worse and we need to move forward, but I don't 
think historical revisionism is appropriate (DomainKeys, which is the 
antecedent to DKIM, had a policy component, so expecting that to have been 
included in DKIM is not at all unreasonable).

We should move forward with what we have, but not forget how we got here.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 1 Aug 2011 22:57:57 -0000

>Perhaps.  But it's difficult to escape the impression that this is
>another example of IETF failing to solve an important problem by
>focusing on a portion of the problem that's easy to solve, and ruling
>the difficult part out of scope for the time being. 

It's definitely a case of the best being the enemy of the good.

There are some basic problems with any system of policy assertions:
the people making the assertions may be mistaken or lying (something
we've seen with ADSP), and there are precious few assertions that I
can make that are of any use to you in deciding how to deal with my
traffic.  Since you have no reason to believe my assertions unless you
already know me, you need mechanisms for third parties that can opine
about the credibility of self-assertions.  Inventing the mechanism is
only medium hard (see RFC 5518) but spinning up vouching services that
provide a usefully large amount of information is very hard.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Aug 2011 19:00:22 -0400

> provide a usefully large amount of information is very hard.

I buy all of the above.

Does it follow, then, that the Right Thing to do is to avoid building any other parts of the system (even, say, the reputation service query protocol) until the easiest part is finished?

Keith

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2011 00:40:46 -0000

> Does it follow, then, that the Right Thing to do is to avoid
> building any other parts of the system (even, say, the reputation
> service query protocol) until the easiest part is finished?

If we knew what to build, we'd build it.

We published RFC 5518 for VBR, a reputation system that sits on top of
DKIM, two years ago.  At this point I know of only one small VBR
provider, which I manage.

Also, even without general reputation systems, there are special cases
that are worth doing, e.g., there's a handful of large heavily phished
domains that sign all their mail, notably paypal.com and its ccTLD
variants.  For a medium or large mail system, it's worth adjusting the
spam filters to throw away mail purporting to be from Paypal that
doesn't have a signature.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 02 Aug 2011 00:52:03 -0400

Keith Moore wrote:

> another example of IETF failing to solve an important problem by focusing 
> on a portion of the problem that's easy to solve, and ruling the difficult 
> part out of scope for the time being.  Repeat as needed; you can always 
> partition the remaining part of the problem again.

It was not a difficult problem.  The issues were well understood long 
before Murray took over the DKIM specification. The WG security and 
requirements RFC productions clearly laid it out:

   RFC4686  Analysis of Threats Motivating DKIM
   RFC5016  Requirements for a DKIM Signing Practices Protocol

The remaining technical problem was how to scale the authorization of 
3rd party signer.   The proposals

   ASL  Allowed Signer List (good for small systems, does not scale)
   TPA  Third Party Authorization (appear to scale, but complex)
   ATPS Authorized Third Party Signer (easier version of TPA)

But there was a fundamental mindset and marketing conflict.  It was a 
conflict of 3rd party resigner market right to exist uncontrolled, 
unrestricted regardless of originating DKIM message claims.

The WG could not continue to complete RF5017 ADSP when the then out of 
scope Trust ideas took over and promoted a market of unrestricted 
resigners.  If ADSP became a standard then these resigners would be in 
violation of a security standard, and it would be a serious problem if 
they intentionally and neglected a security protocol when they 
resigned mail potentially distributing harmful mail

The easy solution is to toss out ADSP, like it never existed. No one 
should follow original domain policy declarations.

But this only shifted to the problem to the resigner who has no sort 
of policy wrappers.  What happens with resigners resign resigned mail? 
  Who will protect them?

Without based line protocol consistent controls and guidelines to 
follow, I'm afraid DKIM signing is fast becoming is rabid hop to hop 
message signature stamping broadcasting concept where the only 
remaining benefit is to make sense of the last signer which is never a 
problem in the authorized and known mail world.  Its a problem with 
the anonymous world and a DKIM-signature has no value here when the 
signer is unknown. Since DKIM-signature requires the 5322.From address 
to be hash bound to the signature, the lost of policy allowed the 
anonymous abuse of these domains to continue.

The issue is straight forward, either resigners support signing 
controls or not. Obviously the latter was the easy way for THEM but it 
didn't solve the problem.  No matter way a policy concept is required.

---

From: Hector Santos <[email-masked]>
Date: Tue, 02 Aug 2011 02:07:04 -0400

Nathaniel Borenstein wrote:
> I find it amazing how many different ways there are to criticize DKIM 
> for not doing something it was never intended to do.  DKIM is a small 
> building block that enables new functionality, but such functionality 
> is beyond the scope of DKIM.

Note: We have an advanced implementation of DKIM as a product line so 
my concerns are not outsider views.  My input is 100% based on 
implementation and field experiences.

Policy was very fundamental to the understanding of DKIM, it was part 
of the original DomainKeys and DKIM expanded this powerful concept 
with a wider range of Author Domain policies.

I never disputed the out of scope 3rd party trust policy model but it 
addressed a different problem - trust, if any, of a valid signature 
after the violations are filtered by author domain policies, if any. 
  Two different layers and this was outlined in my 2006 DKIM Signer 
Authorization Protocol (DSAP) I-D.

The problem was a conflict in different market ideas - an unrestricted 
resigner DKIM mail market which 1st party security controls would 
conflict with.  They  simply did not want the 1st party to override 
any 3rd party signers.  This conflict was highlighted in the SSP 
requirements with the last minute addition in RFC5016:

        "Requirements for a DKIM Signing Practices Protocol"

when item #10 was added in section 5.3 to appease the opponents of 1st 
party SSP polices:

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

          Refs: Deployment Consideration, Section 4.3.

This was unfortunate. On the one hand it suggest we should not meddle 
in how local receivers will behave yet it imposes a MUST NOT mandate 
in allowing the 1st party policy to override a 3rd party signature 
trust policy.

> to associate a domain with a message.  

It does more than that.  DKIM has a fundamental requirement to hash 
bound the 5322.From field to the signature.  Its the only header that 
MUST be signed. All others are optional.  This 5322.FROM bind provide 
the only anchor possible that can be repudiated.

So there are two principal domains associated with a signature:

    Signer        d= value in signature
    5322.From     DKIM requirement

> By doing so, it creates strong evidence that the message passed 
> through that domain at some point and has not been significantly 
> modified since.

I don't see this. The resigner can be totally opaque with no 
association with the original domain.  The signer::author association 
begins with the original signature creation by the author domain 
selecting a signer and/or prearranged with an outsource signing service.

Now, what people are looking for as well, is when there is 
resigner::author association when the author is participating in a 
resigner network.  Currently we call this a 3rd party Authorization.

> With such an anchor, we can begin to build stronger and more robust 
> systems for analyzing the desirability of messages, as we are now trying 
> to do in the REPUTE work, because it allows us to push our forensic 
> analysis upstream a bit.  

Heuristic wrappers are interesting but its a different problem. It 
doesn't adequately address what a deterministic solution can do for you.

> If, for example, the IETF mailing list software only allows posting 
> by list members, but itself trusts the sender's header fields, then 
> an IETF DKIM signature tells me only that the IETF servers think a 
> message passed that test.  

There you go, you made an POLICY STATEMENT - translate it into a 
protocol for everyone to follow and check.

> That's obviously not perfect, but it's slightly stronger than what came 
> before -- it is still possible to forge a message before sending it to the 
> list, but much harder to forge a message to look as if it came from 
> the list exploder.  

This is all besides the point. Its all about detection what YOU think 
is a violation of a protocol logic.  Whatever you produce in REPUTE, 
you are producing a idea for people to follow consistency based on 
some baseline rules established.

> We've had a long history of grand plans for user authentication on 
> the Internet.  Those plans have largely failed.  

There are plenty of authentication protocols that works very well, and 
fundamental to our current network.

The issue here is a DKIM signer market run wild uncontrolled and if we 
don't get our act together soon to put a security wrapper around it, 
it risk becoming yet another wasted header with little to no value and 
perhaps limited to exclusive communications in private communications 
networks.

> I think an incremental approach like DKIM has a better chance, 
> but it is obviously vulnerable to being dismissed by those who 
> see a small improvement as not worth bothering with.  The best is 
> the enemy of the good.  -- Nathaniel

I have invested dearly in dollars, time and energy and we have 
produced an advanced DKIM implementation into our product line with a 
high degree of mail component integration - its a commercial product, 
not just for our own use.

My concerns are 100% sincere as I believe that it might not be too 
late for DKIM to correct what has occurred - the deemphasis of the 
single DKIM requirement to hash bind the 5322.FROM author to the 
signature means.

This is an association you can not ignore because the entire mail 
infrastructure relies on the 5322.From as a fundamental header across 
all mail networks, all mail devices, etc, etc. etc.   This is a not a 
question that can be separated which unfortunately the DKIM 
specification Abstract states as a goal of DKIM:

    DKIM separates the question of the identity of the signer of the
    message from the purported author of the message.

What question is that? Is the question this?

    Do author domains have any say on who signs for them
    and who/what is considered unauthorized signatures
    versus authorized resigning?

Anyway, thanks for your comments.

---

From: "t.petch" <[email-masked]>
Date: Tue, 2 Aug 2011 10:11:40 +0200

----- Original Message -----
From: "Nathaniel Borenstein" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "ietf" <[email-masked]>
Sent: Monday, August 01, 2011 2:48 PM
Subject: Re: DKIM Signatures now being applied to IETF Email

> I find it amazing how many different ways there are to criticize DKIM for not
doing something it was never intended to do.  DKIM is a small building block
that enables new functionality, but such functionality is beyond the scope of
DKIM.

I agree that DKIM does exactly what it sets out to do, but am not amazed that it
attracts criticism.  When people have a need, and want a technical solution, and
then find that what at first sight appeared to be a solution is not one, then
they
may be disappointed, and be critical.  That is human nature.

When that happens is a time to reflect, to look at the requirements that were
not met.  If they  were captured and rejected, at least for the time being, then
noone has any
cause to be upset.  But if the requirements were not captured, then perhaps
it is a time to contemplate that, how were they missed, what else might have
been
missed and whether or not that should be acted upon in future.

And, as I said before, my criticism is of those who have imposed this technology
on the IETF lists, not of the technology itself.

Tom Petch
>
> DKIM does one thing, and one thing only:  It uses a cryptographic signature to
associate a domain with a message.  By doing so, it creates strong evidence that
the message passed through that domain at some point and has not been
significantly modified since.
>
> Whether that domain is good guys or bad guys, senders or resenders, Coke or
Pepsi, is completely irrelevant.  It is a small nugget of evidence to provide an
anchor point for forensics stronger than what have come before.  It tells us
that the named domain considered the message reasonable to send or resend, for
its own reasons -- its own forensic evidence, its nefarious intent, or the phase
of the moon.  With such an anchor, we can begin to build stronger and more
robust systems for analyzing the desirability of messages, as we are now trying
to do in the REPUTE work, because it allows us to push our forensic analysis
upstream a bit.  It does not relieve downstream software of the need to decide
how to feel about the signing domain, whether it's a spammer, a copy-cat, or
anyone else.
>
> If, for example, the IETF mailing list software only allows posting by list
members, but itself trusts the sender's header fields, then an IETF DKIM
signature tells me only that the IETF servers think a message passed that test.
That's obviously not perfect, but it's slightly stronger than what came
before -- it is still possible to forge a message before sending it to the list,
but much harder to forge a message to look as if it came from the list exploder.
That is progress -- very very small, slow, progress.  If, at some point, the
list exploder starts only passing through messages that themselves have valid
DKIM signatures, it will be significantly more progress, but it won't do
anything to stop a spammer from subscribing to the IETF list and
DKIM-authenticating himself.  For that we'll need reputation information --
another small step, which we're trying to initiate with REPUTE.
>
> We've had a long history of grand plans for user authentication on the
Internet.  Those plans have largely failed.  I think an incremental approach
like DKIM has a better chance, but it is obviously vulnerable to being dismissed
by those who see a small improvement as not worth bothering with.  The best is
the enemy of the good.  -- Nathaniel
> > You continue to not comprehend (or rather ignore) what continues to plaque
DKIM - the lack of fault detection. Its why it continues to have a hard time and
have people who actually believe in this promising protocol "bitch" about it.
If these "big email" providers (or anyone for that matter) begin to make
assertions about what is good about their mail then they better be ready for the
violations of such assertions to be rejected.  You can't have it just one way
and mandate this is the only way to process this overhead - looking for good
mail only and ignoring all the violations and illogically treating it like it
was never signed or compromised or attempted to be compromised.
> >
> > The overall difficulty is that originality is lost - the original author or
dkim signer has lost or lacks any protocol guidance to tell resigners that the
mail they are about the process might be bad - according to the original author
domain.
> >
> > If the resigner is going to intentionally and neglectfully ignore all
original claims about the original domain signing practice, then how do you
expect the anonymous "copy-cat" abuse to be controlled?
> >> There has been some post-DKIM talk recently about the idea of "transient
trust", wherein (to use this example) ietf.org would verify the signature on an
arriving list submission, attach an RFC5451 header field that indicates the
results of that verification, then send the message out to the list with that
added field and a new ietf.org signature that "covered" it.  Then, if you decide
to believe ietf.org's claims about the original signature, you know more than
you would otherwise.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 02 Aug 2011 15:27:57 +0200

On 02/Aug/11 06:52, Hector Santos wrote:
> Keith Moore wrote:
> 
>> Repeat as needed; you can always partition the remaining part of
>> the problem again.
> 
> It was not a difficult problem.  [...] how to scale the
> authorization of 3rd party signer. [...] But there was a
> fundamental mindset and marketing conflict.  It was a conflict of
> 3rd party resigner market right to exist uncontrolled, unrestricted
> regardless of originating DKIM message claims.

Marketing pressure on IETF protocols may be business as usual, but
DKIM managed to come out pretty cleanly neutral in this respect,
AFAICS[*].

IMHO, a scenario with a few big re-signers would pose more problems
than it can ever solve.  I wish they... resign.  However, managing
reputation without having recourse to a big brother of some sort is no
easy problem.  Since even governments are being blamed for pursuing
personal interests rather than people's needs, solving that will be a
major achievement in democracy.

-- 
[*] Let's draw a veil over that somewhat confused patent disclosure
https://datatracker.ietf.org/ipr/1547/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Aug 2011 10:10:43 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, August 02, 2011 6:28 AM
> To: [email-masked]

I think the claim that marketing somehow entered into the guidance of DKIM's evolution is specious, and that's being polite.  I've yet to see any evidence at all, short of unfounded assertions about the unspoken agendas of the participants, to back it up.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 02 Aug 2011 13:45:36 -0700

On 8/1/2011 8:41 AM, Scott Kitterman wrote:
> part of the original working group charter.

please cite the text from the original charter that promises such work and, just 
to be safe, please cite the current text that claims it should be there.

In other words, the current complaint is about something missing.  Please quote 
the specification of that and then the part of the original charter that said we 
would do it.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Tue, 02 Aug 2011 17:32:40 -0400

Dave CROCKER wrote:

> please cite the text from the original charter that promises such work 
> and, just to be safe, please cite the current text that claims it should 
> be there.
> 
> In other words, the current complaint is about something missing.  
> Please quote the specification of that and then the part of the original 
> charter that said we would do it.

We are perfectly aware you never believed in policy, never really 
acknowledge it, fought hard against its progress. I can respect that 
position. But I am bit vex as to why you are questioning its existence 
as an original and still current WG work item.

The DKIM WG always had among its charter work items to produce a 
Domain Policy standard and even thought the charter was revised over 
the years, Policy is still today among the WG chartered item today. I 
personally have not seen or read of any official statement to conclude 
the WG and stop all remaining work, nor a change in the charter to 
official remain policy as a work item.

Attached is 2005 copy of the charter I have on disk. Please note how 
reputation was declared of out of scope, yet it continued to disrupt 
the WG and revamped DKIM to its present condition.

Two other WG RFC work items were completed; one directly related to 
producing the "Requirements for a DKIM Signing Practices Protocol" 
RFC5016, and a Threat Analysis RFC4686 which includes among its 
analysis how policy can mitigate certain security threats using Policy.

You, yourself, wrote a RFC5585 called

     "DomainKeys Identified Mail (DKIM) Service Overview"

with signing practices peppered over all the document as a major piece 
of the system. This sentence is found in the abstract:

    DKIM also enables a mechanism that permits potential email signers to
    publish information about their email signing practices; this will
    permit email receivers to make additional assessments about messages.

And the RFC includes a spiffy process flow illustration titled

       "DKIM Service Architecture"

with a Checking Signing Practice component as a major piece of this 
design.

So I am "scratching my head" here wondering why you are now 
questioning how a framework designed over 5 years had major work 
productions dismissed, especially those related to security, in the 
pursuit of the unrestricted resigner and 3rd party trust vendor 
service market and now seem to suggest the DKIM WG Domain Signing 
Practices standardization efforts was not a work item and never 
existed in the first place as a charter item, when in fact, it is 
still today a WG charter item.

Very odd.

DRAFT IETF WORKING GROUP CHARTER  
14 Oct 2005

Domain Keys Identified Message (DKIM)

CHAIRS: 
     TBD
AREA DIRECTORS: 
     Russell Housley, Sam Hartman
AREA ADVISOR: 
     Russell Housley <[email-masked]>
MAILING LISTS: 
    General Discussion: [email-masked]
    To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim
    Archive: http://mipassoc.org/pipermail/ietf-dkim/

DESCRIPTION OF WORKING GROUP:

The Internet mail protocols and infrastructure allow mail sent from one 
domain to purport to be from another.  While there are sometimes legitimate 
reasons for doing this, it has become a source of general confusion, as well 
as a mechanism for fraud and for distribution of spam (when done 
illegitimately, it's called "spoofing").  The DKIM working group will 
produce standards-track specifications that allow a domain to take 
responsibility, using digital signatures, for having taken part in the 
transmission of an email message and to publish "policy" information about 
how it applies those signatures.  Taken together, these will
assist receiving domains in detecting (or ruling out) certain forms of 
spoofing as it pertains to the signing domain.

The DKIM working group will produce summaries of the threats that are 
addressed by the standards-track specifications, while acknowledging their 
limitations and scope.  The DKIM working group will also produce security 
requirements to guide their efforts, and will analyze the impact on senders 
and receivers who are not using DKIM, particularly any cases in which
mail may be inappropriately labeled as suspicious or spoofed.

While the techniques specified by the DKIM working group will not prevent 
fraud or spam, they will provide a valuable tool for defense against them by 
allowing receiving domains to detect spoofing of known domains.  The 
standards-track specifications will not mandate any particular action by the 
receiving domain when spoofing is detected.  The DKIM working group will not 
attempt to define such actions, to establish requirements for trust 
relationships between domains, or to specify reputation or accreditation 
systems.  

The signatures will use public-key cryptography and will be based on domain 
name identifiers.  Public keys needed to validate the signatures will be 
stored in the responsible identity's DNS hierarchy.  The specifications will 
be based on the following Internet Drafts: 

* draft-fenton-dkim-threats
* draft-allman-dkim-base
* draft-allman-dkim-ssp

which represent experimentation and consensus from a number of designers and 
early implementors.  
 
Since experimentation resulted in significant Internet deployment of these 
specifications, the DKIM working group will make every reasonable attempt to 
keep changes compatible with what is deployed, making incompatible changes 
only when they are necessary for the success of the specifications.  

The resulting protocols must meet typical criteria for success.  In addition 
to security, these include usability, scalability, ease of deployment, and 
cryptographic algorithm independence.  

To prevent this task from becoming unwieldy, several related topics are
considered out of scope for the DKIM working group.  These topics include:

* Reputation and accreditation systems.  While we expect these to add value 
  to what is defined by the DKIM working group, their development will be 
  separate, and is out of scope for the DKIM working group.  

* Message content encryption.  

* Additional key management protocols or infrastructure.  

* Signatures that are intended to make long-term assertions beyond the 
  expected transit time of a message from originator to recipient, which is 
  normally only a matter of a few days at most.  

* Signatures that attempt to make strong assertions about the identity of 
  the message author, and details of user-level signing of messages (as 
  distinguished from domain-level keys that are restricted to specific 
  users).

* Duplication of prior work in signed email, incuding S/MIME and OpenPGP.  

Once the primary goals are met, the DKIM working group may also study 
whether to adopt a work item for specifying a common mechanism to 
communicate the results of message verification to the message recipient.  
The generation of a standards-track specification will require an update to 
the DKIM working group charter.  

The deliverables for the DKIM working group are: 

* an informational RFC providing an overview of DKIM, how it can fit
  into overall messaging systems and outlining potential DKIM applictions
  and future extensions
* an informational RFC presenting a detailed threat analysis of, and 
  security requirements for, DKIM
* a standards track specification for DKIM signature and verification
* a standards track specification for DKIM policy handling
* a standards track specification for a DKIM DNS Resource Record

GOALS AND MILESTONES:

02/06     WG last call on DKIM threats and security requirements
05/06     WG last call on DKIM signature specification
09/06     WG last call on DKIM policy specification
12/06     WG last call on DKIM DNS Resource Record
12/06     WG last call on overview document

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Aug 2011 14:58:54 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Tuesday, August 02, 2011 2:33 PM
> To: [email-masked]

Where I come from, personal attacks don't support your position; they degrade your credibility.

> official remain policy as a work item.

There is no rule anywhere that I've seen requiring a working group to complete all of its chartered items if one of them turns out to be a bad or dangerous idea, especially if the sponsoring Area Director concurs.  It doesn't matter what other informational documents it may have produced prior to that point.  This is also true if the working group runs out of steam to keep working on something.  All of those things happened here.
 
The ongoing claims that the working group was guided by sinister designs to benefit from some specific alternate market are simply absurd.

---

From: Hector Santos <[email-masked]>
Date: Wed, 03 Aug 2011 07:43:17 -0400

> position; they degrade your credibility.

And with your personal animosity towards me, I'm sure you will repeat 
this to negate concerns.

I don't view expressing a public recorded oppositional stance as an 
attack.

> The ongoing claims that the working group was guided by sinister 
> designs to benefit from some specific alternate market are simply absurd.

No one stated it was sinister.  That blab always came from your 
description whenever anyone dared to state the obviousness of the 
conflict of interest in the WG.

1) I always stated both security and trust ideas are necessary and 
should of been incorporated. I opposed eliminating author domain 
semantics and security and especially opposed the rewrite and limiting 
the protocol specification to exclusively only 3rd party TRUST Service 
Engine integration out of the box,

2) I illustrated two examples of how unrestricted resigner creating 
mail integration problems, effectively making it impossible for any 
kind of policy to work reliably outside prearranged known communications.

As a DKIM implementor and one of those "sinister" capitalist creating 
products that include allowing a business to create trust services as 
well,  the above has made it very difficult and I see little to no 
payoff in DKIM future - as it currently written in its limited nature 
to only trust and for writing software with no design considerations 
for controlling and restricting resigning.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Aug 2011 08:38:14 -0700

On 8/2/2011 1:11 AM, t.petch wrote:
> When people have a need, and want a technical solution, and then find that
> what at first sight appeared to be a solution is not one, then they may be
> disappointed, and be critical.  That is human nature.
 >
> When that happens is a time to reflect, to look at the requirements that
> were not met.

Tom, one of the other, preferred characteristics of human nature is to take 
constructive action upon identifying a problem.  So I look forward to seeing 
your proposal and pursuit of a solution to this important problem that DKIM does 
not try to solve.

> And, as I said before, my criticism is of those who have imposed this
> technology on the IETF lists, not of the technology itself.

Indeed.  It really is irresponsible of them to improve the accountability of 
email going out through the IETF.

d/
-- 

   Dave Crocker

---

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 9 Aug 2011 14:30:33 -0400

> Perhaps.  But it's difficult to escape the impression that this is another example of IETF failing to solve an important problem by focusing on a portion of the problem that's easy to solve, and ru…
.....
> Does it follow, then, that the Right Thing to do is to avoid building any other parts of the system (even, say, the reputation service query protocol) until the easiest part is finished?

No extreme is likely to work, because this is essentially an optimization question for standards processes.	   We worry too little about the opportunity cost of the passage of time, so we fight time-consuming battles.  We should instead be trying to build an optimal pipeline of incremental progress in a generally positive direction, acknowledging inevitable mistakes along the way.

I'd like to view the IETF as a standards factory, with a certain optimal level of throughput that we're trying to achieve.  As with, say, a sausage factory, you don't just take in a single opinion, chop it up to bits, and deliver a snack-sized bit of RFC before moving on to process the next opinion.  The economic benefits of parallelism are so large that they dwarf all but the worst mistakes, so we accept the inevitability of a flawed process that lets a few bugs get through.  As a technologist I hate that(*), but it's true.   And it means that, if you can look back on a standard you worked on a few years ago and not have any regrets, you spent too much time on it.

So while we obviously need to focus on smallish, core chunks of technology like DKIM before devoting a lot of effort to building on top of them, we also need to start the latter before the former are completely finished. 

If anything, we're late.  DKIM is almost a decade old.  It's pretty good, and we've long since reached diminishing returns.  There's plenty more to do.  It's time to move on.  -- Nathaniel

_____
(*) As a vegetarian I just feel smug. :-)

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Aug 2011 20:46:11 +0200

On Aug 9, 2011, at 20:30, Nathaniel Borenstein wrote:

> We worry too little about the opportunity cost of the passage of time, so we fight time-consuming battles.  We should instead be trying to build an optimal pipeline of incremental progress in a generally positive direction, acknowledging inevitable mistakes along the way.

Nathaniel,

this (and the rest of your message) is probably the most profound observation I've heard about the IETF process for quite a while.

For another perspective on this, see section 2.7 "The fallacy of perfection" in "Garrulity and Fluff".
(http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf)

Gruesse, Carsten

---

From: SM <[email-masked]>
Date: Tue, 09 Aug 2011 23:58:27 -0700

Hi Carsten,
>(http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf)

That's an interesting document.  From Section 2.1:

   "The worst source of complexity, however, is the need to appease 
stakeholders."

As the draft points out, the cost of achieving consensus is to accept 
changes even though it only serves to make the protocol more 
complex.  Some of these changes are not even implemented when they 
are optional or else they are only actually useful for one implementation.

Ignoring MUSTs (Section 2.3) invites long debates.  Instead of having 
the RFC align with implementations in the wild, the situation is such 
that implementers are pressured to adhere to the RFC.

It is quite a feat to make a protocol future-proof (Section 
2.5).  Unfortunately, the process pushes specifications in such a 
direction due to the misguided belief that a perfect protocol is an 
attainable goal.  The fact that specifications are initially of a 
higher quality encourages less flexibility.  In other words, the 
committee is more reluctant to accept changes at a later stage.

Section 2.7 discusses about the tendency to ignore aspects of reality 
that are unpleasant.  On an unrelated note, I would like to 
congratulate NAT operators for the universal deployment of NAT. 
:-)  The reality is whatever the IETF thinks of the principles of 
Internet architecture, operators will violate those principles when 
the latter conflicts with their core value; which is about making 
money.  In simple terms, that protocol that has been designed to do 
almost everything won't gain traction if the input from operators is 
not taken into account.

Quoting Section 2.7:

   "In the IETF, the desire for high quality often leads to a struggle
    at the end to convince the IESG to accept the result. See "appeasing
    stakeholders", "big design up front", "check-mark requirement" above
    for some of the results. It may be better for a protocol to leave a
    flank wide open, and look for the actual requirements to be fulfilled
    in its actual use, then to design in a half-hearted solution appeasing
    the blocking IESG member that then quickly becomes a piece of fluff
    when it is replaced (or, worse, over-painted) by the real thing. (The
    stick of keeping a protocol "experimental" instead of "standards track"
    is then often used to push those "solutions" through.)"

As much as I agree with the above, it in unconceivable that 
draft-bormann-core-6lowpan-fluff-minus would be considered for 
publication in the IETF Stream as such an uncomfortable truth might 
be deemed as unacceptable.

Five years ago, a BCP was published to describe the best current 
practice for a widely deployed Experimental protocol.  The working 
group "came up with modifications to the protocol that the WG thought 
made it better but that implementors didn't see any reasons to deploy".

This thread was initially about DKIM Signatures now being applied to 
IETF Email.  Some people from the IETF sausage factory are aware that 
DKIM is broken; i.e. DKIM signatures will fail to verify when a 
message goes through a mailing list.  Some people might call that a 
flaw, others might say that it is by design.  The point is that it is 
not possible to address all cases.  As Nathaniel Borenstein put it, 
can we accept the inevitability of a flawed process that lets a few 
bugs get through?

These multi-year "big design up front" efforts favor high quality of 
documents at the expense of timeliness.  The longer the design effort 
takes, the shorter the incremental benefit.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Wed, 10 Aug 2011 04:57:44 -0400

> That's an interesting document.  From Section 2.1:

Yes, it is a interesting document.

> .... In simple terms, that 
> protocol that has been designed to do almost everything won't gain 
> traction if the input from operators is not taken into account.

+1 and this, in my opinion, is the blessing and curse of the IETF and 
when coupled with the outdated Rough Consensus decision making 
guideline, it can have had a negative impact in the final outcome.

I have been part of several open technical standard organizations 
where the philosophical difference of the mixed discipline 
environment, i.e. Administrators vs Developers was the source of doom, 
especially when the art of compromising is lacking or unachievable.

My view, it all begins with the main source. It is very important the 
editor(s) recognize input is coming from all sides.  Once they shun 
one group over another and use Rough Consensus (RC) as the measuring 
stick to shun others, its over.  Everyone loses.

RC is ok when everyone in the group (team) have a similar discipline 
or mindset.  But when there extreme mindsets, it simply doesn't work 
for the benefit of the main WG or protocol goal. This is like 
prematurely inviting a technical sales team, documentation team or 
help desk to a project R&D effort.  They might fit better during a 
early functional requirement stage or Product R&D effort, but when 
conflicts mindset are smack in the middle of a protocol design, that 
spells problems.

Of course, All input is input so generally, at the end of the day, 
this is more about a management problem - a.k.a IETF WG Chairs. 
Ideally, the editors should be very keen to these differences

Anyway, today, I don't think Rough Consensus is a good decision 
making, issues settling tool that can resolve problems by blowing away 
a good size minority out the door.  That causes problems. When there 
is disperse group, I believe a super majority is a fundamental and 
statistically correct requirement that have a maximum beneficial 
outcome.   This is akin to adding features to a product; when there is 
no clear answer - you make it optional.  Throwing it away will invite 
support issues. :)

I said more than I wanted to, but its just my opinion.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 10 Aug 2011 19:49:35 +0200

On 10.08.2011 08:58, SM wrote:
> The reality is whatever the IETF thinks of the principles of Internet
> architecture, operators will violate those principles when the latter
> conflicts with their core value; which is about making money.  In simple
> terms, that protocol that has been designed to do almost everything won't
> gain traction if the input from operators is not taken into account.

An operator is whoever operates the Internet, including IETFers and
programmers, besides telecoms.  Money is an inheritance from pre-existing
establishments, and one that doesn't work very well.  IMHO, the Internet can
be considered part of the world's effort to limit its exceeding power.