Subject: [ietf-dkim] Issue: 6.5. Recommended Signature Content - Order and Message-ID

From: Hector Santos <[email-masked]>
Date: Fri, 29 Apr 2011 09:22:15 -0400

I think the rev8 version of section 6.5 is much better, but I have a 
change proposal with the background reasoning listed below it:

o proposed change:

                 ------------------

    The basic rule for choosing fields to include is to select those
    fields that constitute the "core" of the message content with high
    authenticity value and high targets for malicious attacks.
    Included in the core are the required fields as defined in
    RFC5322 section 3.6.

    Common examples of "core" fields with addresses and fields listed
    in order of authenticity strength and introduction:

    o  From (RFC5322 and DKIM REQUIRED; see Section 6.4)
    o  Date (RFC5322 REQUIRED)
    o  Message-id
    o  Subject
    o  To, Cc

    For replies and resent mail, the "core" fields may include:

    o  Reply-To
    o  References
    o  Resent-Date, Resent-From, Resent-To, Resent-Cc
    o  In-Reply-To,

    For messages signed by Mailing List Managers, the "core" fields may
    include:

    o  List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
       List-Owner, List-Archive

                 ------------------

o Background reasoning:

In 2nd paragraph, 1st sentence:

    The basic rule for choosing fields to include is to select those
    fields that constitute the "core" of the message content.

I think for most mail system experts "core" can be understood but also 
comes with different reasonable levels of what constitutes "core", 
especially when it comes to gateways, transformations and the most 
common fields to display.

The section does follows up with examples of the core not expected to 
fail or fail authenticity only with malicious intent.  But a few of 
the "core" fields can change such as Subject and Reply-to with 
industry acceptable MLM streams.

So it may help separate the core using order of importance with 
including text regarding required RFC5322 headers as stated in RFC5322 
section 3.6 (3rd paragraph, 1st sentence)

     The only required header fields are the origination date field
     and the originator address field(s).

These would be Date: and From:

I also think the Replay Attack sentence (as worded) is not necessary 
and I think important Message ID should be added back in as it is a 
critical important authenticity field especially in the area of 
duplicate mail detection.

Message-id is required by all message creators and/or added by 
submission servers and its a fundamental expected in all mail 
networks.  The commonality has been a construct of:

      local-unique-serialize-id @ originating-host-domain

The basic requirement is that only the LHS is locally unique at the 
original host and together, worldly unique.

This is never expected to be modified or stripped which will 
constitute a new message. Mail Dupe detections are very fundamental in 
all mail systems (regardly if they use it or not) and they use a 
message-id as a fundamentally input. IBM even has a patent on using 
authenticated Message-ID feedback verification method:

     http://www.google.com/patents/about?id=NXSGAAAAEBAJ

So in my strong opinion, the RFC5322 Message-ID is a traditional 
strong original mail authenticity identity and should be included in 
the "core" group.

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

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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 29 Apr 2011 09:37:02 -0400

> change proposal with the background reasoning listed below it:
...

I've had no time recently, so I've been attempting to avoid looking at last 
call messages since I didn't have time to follow it closely.  In this case I 
failed....

Looking at 6.5, and then looking back at 6.4 (Determine the Header Fields to 
Sign), it seems to me that the "INFORMATIVE OPERATIONS NOTE" in 6.4 attempts 
to describe the considerations that are normatively described in 6.5.  It's 
redundant and ought to be deleted.  Given what's in 6.5 now, it's just a 
potential source of confusion.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 29 Apr 2011 11:36:07 -0400

> potential source of confusion.

I see your point.

I think the note saying about "not-obvious" is generally true, but we
do have a pretty strong mail system insight to have a top DKIM strategy.

For me, dependent of DKIM, the end game in a heterogeneous mail 
network was always about WYSIWYG and the ability to reply back, so:

   - end to end persistency expectation, i.e. WYSIWYG, and
   - transport (network controls) persistency expectation.

The note does reflect this in show many words and in mixed strategies,
but there should be one top DKIM strategy that offers the best
technical and DKIM results.

If that can be stated in 6.5, I agree the 6.4 note would become redundant.

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