Subject: [ietf-dkim] Feedback on open tickets, please!

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Apr 2011 11:25:43 -0700

Folks,

With four days left in the WGLC for our remaining two documents, there are several items still open in the trackers.  Only items that are either minor/editorial in nature or those that get working group consensus will make it in, so please weigh in on them soon.

The list of open tickets is available here: http://trac.tools.ietf.org/wg/dkim/trac/report/3

Items #19 and #20 are new, so they in particular need comments and review to indicate consensus.  (I think only the editors and chairs can actually alter the tickets themselves, so please comment on the list in appropriate threads or start new ones.)

-MSK

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 26 Apr 2011 19:42:59 -0400

I agree with Dave's changes, except that you need to sign Content-Type: if 
you use l=.  Otherwise it's trivial to replace the entire visible contents 
of the message by changing the MIME section separator, and adding new 
stuff at the end.

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: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 27 Apr 2011 11:09:24 +0200

Hi, Murray,

On 4/26/11 8:25 PM, Murray S. Kucherawy wrote:
>
> Folks,
>
>
> With four days left in the WGLC for our remaining two documents, there 
> are several items still open in the trackers.  Only items that are 
> either minor/editorial in nature or those that get working group 
> consensus will make it in, so please weigh in on them soon.
>
> The list of open tickets is available here: 
> http://trac.tools.ietf.org/wg/dkim/trac/report/3
>
> Items #19 and #20 are new, so they in particular need comments and 
> review to indicate consensus.  (I think only the editors and chairs 
> can actually alter the tickets themselves, so please comment on the 
> list in appropriate threads or start new ones.)
>

One comment on ticket #11: shouldn't that refer to section 3.5 instead 
of 2.5?

/rolf

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Apr 2011 20:40:44 +0200

On 27/Apr/11 01:42, John R. Levine wrote:
> I agree with Dave's changes,

+1, and also for Murray's advice of signing A-R fields.  However, in
such case, the last phrase in Sec 7.2 (INFORMATIVE ADVICE to MUA
filter writers) should be changed from

   To circumvent this attack, verifiers may wish to delete existing
   results header fields after verification and before adding a new
   header field.

to, e.g.,

   To circumvent this attack, verifiers may wish to delete counterfeit
   results header fields after verification and before adding a new
   header field.

> except that you need to sign Content-Type: if you use l=.

However, signing Content-Type affects a signature's robustness, due to
the possibility to add/remove quotes from MIME attributes during those
rewrites that l= is meant to pass through.

> Otherwise it's trivial to replace the entire visible contents of
> the message by changing the MIME section separator, and adding new
> stuff at the end.

"Content-Type" is not currently mentioned in Section 9.1.1. "Addition
of new MIME parts to multipart/*".  It should.  Because it is now the
27th, I dare propose a replacement for that section:

   If the body length limit does not cover a closing MIME multipart
   section (including the trailing ""--CRLF"" portion), then it is
   possible to add a new body part without breaking the signature.
   This possibility can be abused.  Depending on the details of the
   MIME type and the implementation of the verifying MTA and the
   receiving MUA, this could allow an attacker to change the
   information displayed to an end user from an apparently trusted
   source.

   For example, if a message has a "multipart/alternative" body part,
   an attacker might be able to add a new body part that is preferred
   by the displaying MUA.  Appending content to an existing body part
   can also have surprising effects, as exemplified in the next
   section 9.1.2.

   Furthermore, if the top Content-Type does not appear (possibly
   twice) in the h= tag, then it is possible to replace the entire
   visible contents of the message by defining a suitable MIME
   multipart/* and its boundary, so that the signed content appears to
   only cover a MIME preamble and/or invisible MIME entities.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Apr 2011 12:17:16 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Wednesday, April 27, 2011 11:41 AM
> To: [email-masked]
> Subject: [ietf-dkim] Two issues derived from Ticket #20: signature practices
> 

Actually if we're talking about A-R fields, RFC5451 talks plenty about this.  Rather than duplicating advice, we should just refer to it.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Apr 2011 12:29:46 -0700

> Actually if we're talking about A-R fields, RFC5451 talks plenty about this.  Rather than duplicating advice, we should just refer to it.

as long as it's informative rather than normative, that seems entirely constructive.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 27 Apr 2011 16:36:38 -0400

>> +1, and also for Murray's advice of signing A-R fields.

I still don't understand why, if you trust a signer enough to believe the 
mailing list A-R headers he signs, you don't trust him enough to deliver 
the mail, and, of course, why we now need to remotely verify contributor 
addresses when we've gotten along without it for 40 years, but whatever.

Keeping in mind that this is all non-normative, it seems harmless.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 Apr 2011 17:42:47 +0200

On 27/Apr/11 21:29, Dave CROCKER wrote:
>> Actually if we're talking about A-R fields, RFC5451 talks plenty
>> about this.  Rather than duplicating advice, we should just refer
>> to it.
> 

Yeah, the whole INFORMATIVE ADVICE to MUA can be safely replaced by
just mentioning RFC 5451.  That note has been there since 2006, when
draft-kucherawy-sender-auth-header was about version -03.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html