[ietf-dkim] Final update to 4871bis for working group review
chl at clerew.man.ac.uk
Tue Jul 12 12:02:30 PDT 2011
On Mon, 11 Jul 2011 14:56:26 +0100, Murray S. Kucherawy
<msk at cloudmark.com> wrote:
>> -----Original Message-----
>> From: ietf-dkim-bounces at mipassoc.org
>> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Monday, July 11, 2011 3:52 AM
>> > "Agents that evaluate or apply DKIM output need to be aware that a
>> > signer can sign messages that are malformed (e.g., violate RFC5322),
>> > become malformed in transit, or contain content that is not true or
>> > valid. Such an action might constitute an attack against a receiver,
>> > especially where additional credence is incorrectly given to a signed
>> > message without evaluation of the signer. Moreover, an agent would be
>> > incorrect to infer that all instances of a header field are signed
>> > because one is. Agents will need to account for these issues when
>> > deciding how to apply DKIM results to message, especially when
>> > displaying them to users."
>> OK, there is much good stuff in that. In particular, it makes it clear
>> that Bad Stuff can originate from the signer as well as from
>> men-in-the-middle and replayers. But I am still concerned that multiple
>> occurrences of "singleton" headers fields are not explicitly mentioned,
>> even as just one possible example.
>> I still don't think that paragraph is what we really need, but I will
>> withold judgement on that until I see how it gets incorporated into the
>> other bits of text that are around.
> Given that today's the deadline, we will have to go with something like
> this or nothing at all (which in fact I would prefer because I think all
> of this is adequately covered by existing text, and I believe consensus
> and the AD concurs), so withhold judiciously.
Essentially, my concern is that an implementor reading this section should
be able to infer the nature of the particular attack I have described (the
one where the signer is the BadGuy himself using a throwaway domain),
including spotting how and why it worked and how to protect against it.
Having now read your paragraph in the context of the rest of the material
in that section, I think it just about passes that test, but only by the
thinnest of margins, so I will let it go.
But as a piece of technical writing that section is a total mess, talking
around the problem, and seemingly more concerned with enabling timid
implementors to pass the buck around amongst themselves that with
protecting the ultimate users.
I see Doug has written a detailed critique of it, and I fully endorse most
of what he has said.
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Email: chl at clerew.man.ac.uk Snail: 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
More information about the ietf-dkim