Dave has already commented on the confusing and rambling nature of this document, so I'll focus only on the core claim.
In this document, Doug is re-raising an objection that was discussed long and hard in the DKIM working group during the development of RFC6376. The archives are still available for public review. The result of that discussion was the addition of Section 8.15 to that RFC, wherein the problem is described clearly to bring it to the attention of implementers, including mitigation steps an application might take if the application considers this scenario a real threat. I can speak for one implementation that included those steps even before the RFC was published; Doug even references it in his draft.
The few dissenters to the text that became Section 8.15 were given ample time to propose alternatives that could sway the consensus of the working group, but failed to do so.
As this draft presents no information that is new since working group consensus was reached, I don't believe there's any need to reopen the debate. It is still not a flaw in DKIM.
In this document, Doug is re-raising an objection that was discussed long and hard in the DKIM working group during the development of RFC6376. The archives are still available for public review. The result of that discussion was the addition of Section 8.15 to that RFC, wherein the problem is described clearly to bring it to the attention of implementers, including mitigation steps an application might take if the application considers this scenario a real threat. I can speak for one implementation that included those steps even before the RFC was published; Doug even references it in his draft.
The few dissenters to the text that became Section 8.15 were given ample time to propose alternatives that could sway the consensus of the working group, but failed to do so.
As this draft presents no information that is new since working group consensus was reached, I don't believe there's any need to reopen the debate. It is still not a flaw in DKIM.
On Sun, May 12, 2013 at 11:00 AM, Douglas Otis <doug.mtview@xxxxxxxxx> wrote:
Dear ietf,To better clarify elements within otis-ipv6-email-authent draft, a separate I-D is focused primarily on DKIM.Regards,Douglas Otis