Subject: [ietf-dkim] ISSUE: verifier message editing language

From: "John R. Levine" <[email-masked]>
Date: 12 Apr 2011 21:03:57 -0400

Per Murray's request, here's just the changes to take out the verifier 
message editing

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---------- Forwarded message ----------

I wish I could say this is ready to ship, but it's not.

It's still full of language in which a verifier creates an edited version of 
the message, and a few other lies.  Here's the fixes, most of which I think I 
sent in last time. Assuming we agree that the verifier does not, in fact, 
create an edited message, none of them should be contentious:

3.4.5, first INFORMATIVE IMPLEMENTATION NOTE, last sentence: delete "or remove 
text that appears after the specified content length" since verifiers do not 
produce an edited message.

3.5, d= and i= tags: references to RFC3490 should be RFC5890. The reference to 
ToASCII() should go, or else in both places say IDNs are represented as 
A-labels.

3.5, l= tag, INFORMATIVE IMPLEMENTATION WARNING, remove "or remove text that 
appears after the specified content length" since verifiers don't produce an 
edited message.

3.5, z= tag, remove paragraph "Header fields with characters requiring
  conversion (perhaps from legacy MTAs that are not [RFC5322] compliant)
  SHOULD be converted as described in MIME Part Three [RFC2047]."

DKIM only applies to RFC5322 compliant messages, RFC2047 only describes 
conversions for some, not all, of the fields that can be copied in a z= header, 
and as soon as the EAI RFCs come out, which is likely to be soon, this advice 
will be wrong anyway.

6.1.3, next to last paragraph, remove "by truncating the message at the 
indicated body length" since verifiers do not create an edited message.

6.1.3, remove the INFORMATIVE IMPLEMENTATION NOTE at the end, which is entirely 
about creating the edited message that verifiers don't create.

6.3, remove next to last pp, "The verifier MAY treat unsigned header fields 
with extreme skepticism, including marking them as untrusted or even deleting 
them before display to the end user."

That's both because the verifier doesn't create an edited message, and because 
verifiers don't treat any field with any degree of scepticism. They take what 
they get.

6.3, last sentence: "should be rendered" -> "should be treated"

There's other stuff I would remove or fix if we had unlimited time, but these 
are the important ones.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Apr 2011 21:45:22 -0400

John R. Levine wrote:
> Assuming we agree that the verifier does not, in fact,

I don't agree a verifier create edited messages but it should be 
recognized it may reasonable to suggest it does based on the idea it 
can add a DKIM related trace header (Authentication-Result).  But to 
me, that would be just another trace header like all others.

> 3.4.5, first INFORMATIVE IMPLEMENTATION NOTE, last sentence: 
> delete "or remove text that appears after the specified content 
> length" since verifiers do not produce an edited message.

If the concern is Verifier Edited text, then this will promote it. So 
+1 on that regard.   But I think the security design point is 
important and might be restated in another way.

First, I don't think the verifier SHOULD ignore the tag without 
additional insight.  For example, it MAY ignore it for non-mailing 
list streams since list streams is really the one of the main 
motivations for l=.

Second, an MUA or Message Display Renderer could be better candidates 
to hiding (not display) the text after l= length. MUAs already do 
hiding of some form or another.  A suggestion to focus on this angle 
might be better than just removing this security insight.

> 3.5, l= tag, INFORMATIVE IMPLEMENTATION WARNING, remove "or 
> remove text that appears after the specified content length" 
> since verifiers don't produce an edited message.

Same as above.

> indicated body length" since verifiers do not create an edited message.

Same as above.

> 6.3, remove next to last pp, "The verifier MAY treat unsigned 
> header fields with extreme skepticism, including marking them as 
> untrusted or even deleting them before display to the end user."

+1. I think maybe "deleting" would be the offending term as mail 
receivers are not in the (expected) practice of tampering with mail 
which deleting would imply is possible.  "Hiding" is the more 
appropriate term.

> That's both because the verifier doesn't create an edited message, 
> and because verifiers don't treat any field with any degree of 
> scepticism. They take what they get.

+1, we keep forgetting that ultimately MUAs (online or offline) will 
need to designed/updated to handle what verifiers produce and imported 
to the mail storage.  But there also the possibility to better support 
legacy offline MUAs, the MTA can (and many systems do) take "editing" 
action.

But I agree I don't think its the DKIM verifiers job to "edit 
messages." It might be but it shouldn't the main scope for DKIM verifiers.

> 6.3, last sentence: "should be rendered" -> "should be treated"

+1

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Apr 2011 22:24:26 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Tuesday, April 12, 2011 6:04 PM
> To: DKIM Mailing List
> Subject: [ietf-dkim] ISSUE: verifier message editing language
> 
> [...]

The stuff having to do with producing an alternate version of the text is certainly wrong insofar as there's no extra visible copy produced, but I've always interpreted that language as referring to the "internal" copy that gets fed to the hash function.  It certainly could be that I've just been around the text and the algorithms long enough to believe that must be what the current text means so I didn't think twice about it.

Anyway, I didn't omit this point intentionally last time.  It's a reasonable thing to clean up.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 13 Apr 2011 06:08:12 -0000

>The stuff having to do with producing an alternate version of the
>text is certainly wrong insofar as there's no extra visible copy
>produced, but I've always interpreted that language as referring to
>the "internal" copy that gets fed to the hash function.  It certainly
>could be that I've just been around the text and the algorithms long
>enough to believe that must be what the current text means so I
>didn't think twice about it.

I tried to be careful to distinguish between the language that
describes how the verifier uses l= to manage what's fed to the hash,
which is OK, and the language which suggests that it produces an
edited message, which is not.  Take a look and see if you agree.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 13 Apr 2011 10:27:53 -0700

> Per Murray's request, here's just the changes to take out the verifier 

+1 to these changes.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions