Subject: [ietf-dkim] Revision to draft-ietf-dkim-mailinglists posted

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Apr 2011 00:30:26 -0700

A new version of draft-ietf-dkim-mailinglists has been posted.  This document is in WGLC, closing 4/30; this new version contains those changes that are shown in the WG's issue tracker for which there appears to be consensus or are otherwise uncontested, and I've closed them in the tracker.  You can use the datatracker link (http://datatracker.ietf.org/doc/draft-ietf-dkim-mailinglists/; click on the History tab) to get a view of the diffs to make sure we have them right.  Things that have been edited or added as a result of tracker items are marked with "{DKIM #}" tags.  Text that has been removed has, well, been removed.

The only suggested change not yet made has to do with the choice of fields to sign.  Section 5.5 of RFC4871 (6.5 in bis) lists header fields to sign, something the IESG had us add as I recall.  Section 6.8 of the MLM draft extends that list slightly, falling back on the justification given in RFC4871.  It does so largely with the intent of taking responsibility for fields it added, especially Authentication-Results, so that downstream agents can have some faith that they're "real".

As Dave pointed out (and he's free to correct me if I have this wrong), we never ascribed any semantics to header fields covered by a signature.  For X to trust Y's signing of an Authentication-Results field, there's meaning being assigned by both to a valid signature from X.  But that's out-of-band as far as DKIM is concerned, and to go back and add it now in bis would require recycling at Proposed Standard.  So, although there are people that want to (or maybe even do) use DKIM this way, it's outside of DKIM's scope and the MLM document shouldn't make this specific statement about which fields to sign.

At the same time, a lot of this document talks about possible applications of DKIM that go beyond the scope defined in RFC4871 and bis to help MLMs in a DKIM world, so maybe leaving it in is just fine, perhaps making that caveat explicit yet again at that point in the draft.  This is my (current) preference.

Suggestions welcome.

-MSK

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

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Apr 2011 09:11:27 -0700

On 4/25/2011 12:30 AM, Murray S. Kucherawy wrote:
> The only suggested change not yet made has to do with the choice of fields to
> sign. Section 5.5 of RFC4871 (6.5 in bis) lists header fields to sign, something
> the IESG had us add as I recall.

The original specification provided a very modest list of 'required' fields to 
cover.  In fact I think it was only From.  One AD held a Discuss until we added 
more; in order to get the document out quicker, the current list was formulated.

The AD's core error was in thinking that DKIM was providing classic content 
authentication and protection, rather than merely affixing an identifier to a 
message.

 >  Section 6.8 of the MLM draft extends that list
> slightly, falling back on the justification given in RFC4871. It does so largely
> with the intent of taking responsibility for fields it added, especially
> Authentication-Results, so that downstream agents can have some faith that
> they’re “real”.

The dilemma is that it's natural to extend the set of fields in this way and 
especially for an additional set like the List-* set.  The problem is that the 
DKIM Signing specification provides no semantics to the distinction between what 
is and is not signed.  DKIM merely attaches an identifier to the /message/, not 
a subset of the /message/.

> As Dave pointed out (and he’s free to correct me if I have this wrong), we never
> ascribed any semantics to header fields covered by a signature. For X to trust
> Y’s signing of an Authentication-Results field, there’s meaning being assigned
> by both to a valid signature from X. But that’s out-of-band as far as DKIM is
> concerned, and to go back and add it now in bis would require recycling at
> Proposed Standard. So, although there are people that want to (or maybe even do)
> use DKIM this way, it’s outside of DKIM’s scope and the MLM document shouldn’t
> make this specific statement about which fields to sign.
>
> At the same time, a lot of this document talks about possible applications of
> DKIM that go beyond the scope defined in RFC4871 and bis to help MLMs in a DKIM
> world, so maybe leaving it in is just fine, perhaps making that caveat explicit
> yet again at that point in the draft. This is my (current) preference.

My own primary concern, here, is that the document clearly mark the difference 
between what is currently withing the DKIM specification and what goes beyond it.

-- 

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Apr 2011 15:28:36 -0700

I don't so much view DKIM as protecting content; rather, my current view of its semantics aligns with the whole "taking some responsibility for" approach.  In essence, when an agent conducts verification, it is presenting the hashed content to the signer and asking, "Did you take some responsibility for this?"  A successful verification is an implicit "yes".  And thus, a signer should only sign those parts of the header and body for which it wants to accept responsibility.  Most of the time that should be most or all of the message, but there might be a point at which an intermediary or relay doesn't want to do that, but rather just wants to sign the parts it added or changed (as much as it's possible to do so).

In the MLM's case, the entire body plus any fields it added or changed seems like the appropriate content over which to make some assertion of responsibility.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Apr 2011 14:59:42 -0700

On 4/25/2011 2:07 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
>> Sent: Monday, April 25, 2011 9:11 AM
>> To: [email-masked]
>> Subject: Re: [ietf-dkim] Revision to draft-ietf-dkim-mailinglists posted
>>
> So maybe just this (note the trailing paragraph):
>
>     Section 5.5 of [DKIM] includes a list of header fields that a
>     signature SHOULD include in its header hash and discusses reasons for
>     doing so.  MLMs that sign MUST adhere to those guidelines, extended
>     as follows: {DKIM 12}
>
>     o  Any [AUTH-RESULTS] fields added by the MLM;
>
>     o  Any [LIST-ID] or [LIST-URLS] fields added by the MLM;
>
>     o  Any [MAIL] fields, especially Sender and Reply-To, added or
>        replaced by the MLM.
>
>     Note that [DKIM] does not ascribe any specific meaning to what is or is
>     not included in the hashes that make up the signature.  This is an extension
>     to DKIM's semantics insofar as the MLM is taking responsibility for the
>     specific fields it added or altered.

I'm really sorry to be doing this, at this stage, but as long as the issue of 
this section has come up, it ought to get cleaned up. This section contributes 
to the continuing misunderstanding of DKIM semantics, since it promotes the view 
that there is differential "protection" being offered. The MLM text demonstrates 
this problem, I believe.  The 4871 text It also contains a technical error.

Existing text in RFC 4871:

>    In order to maximize compatibility with a variety of verifiers, it is

Recommending a list of header fields to hash has nothing at all to do with 
compatibility with verifiers.  Presumably what was meant by this text was 
compatibility with "expectations" among assessment mechanisms, but that's both 
different and also wrong.

>    recommended that signers follow the practices outlined in this
>    section when signing a message.  However, these are generic
>    recommendations applying to the general case; specific senders may
>    wish to modify these guidelines as required by their unique

This sentence was the only reason I kept quiet during the original error is 
placating the AD.  In effect, it emasculates the normative aspect of the 
section... as it shuld.

>    situations.  Verifiers MUST be capable of verifying signatures even
>    if one or more of the recommended header fields is not signed (with
>    the exception of From, which must always be signed) or if one or more

And this sentence provide the technical meat that offsets any potential problems 
when a signer chooses to deviate from the list.  In effect, it further lessens 
the import of the list.

>    of the dis-recommended header fields is signed.  Note that verifiers
>    do have the option of ignoring signatures that do not cover a
>    sufficient portion of the header or body, just as they may ignore
>    signatures from an identity they do not trust.
>
>    The following header fields SHOULD be included in the signature, if
>    they are present in the message being signed:
>
>    o  From (REQUIRED in all signatures)
>
>    o  Sender, Reply-To
>
>    o  Subject
>
>    o  Date, Message-ID
>
>    o  To, Cc
>
>    o  MIME-Version
>
>    o  Content-Type, Content-Transfer-Encoding, Content-ID, Content-
>       Description
>
>    o  Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc,
>       Resent-Message-ID
>
>    o  In-Reply-To, References
>
>    o  List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
>       List-Owner, List-Archive

In other words, this was an attempt to exhaustively list all potential 
content-related "semantic" fields, and a few more (like MIME-Version) that 
promote an erroneous sense of "protection".

>    The following header fields SHOULD NOT be included in the signature:
>
>    o  Return-Path
>
>    o  Received
>
>    o  Comments, Keywords
>
>    o  Bcc, Resent-Bcc
>
>    o  DKIM-Signature

What is missing from all of this is any basic statement of guiding principle or 
theory.  Why should BCC not be signed?  Why should MIME-Version be signed.

>    Optional header fields (those not mentioned above) normally SHOULD
>    NOT be included in the signature, because of the potential for
>    additional header fields of the same name to be legitimately added or
>    reordered prior to verification.  There are likely to be legitimate
>    exceptions to this rule, because of the wide variety of application-
>    specific header fields that may be applied to a message, some of
>    which are unlikely to be duplicated, modified, or reordered.
>
>    Signers SHOULD choose canonicalization algorithms based on the types
>    of messages they process and their aversion to risk.  For example,
>    e-commerce sites sending primarily purchase receipts, which are not
>    expected to be processed by mailing lists or other software likely to
>    modify messages, will generally prefer "simple" canonicalization.
>    Sites sending primarily person-to-person email will likely prefer to
>    be more resilient to modification during transport by using "relaxed"
>    canonicalization.

Strictly speaking, the above paragraph is not appropriate to this section, since 
it is not about "content".  Since I don't see another, more appropriate venue 
for this otherwise reasonable text, perhaps the easiest solution is to re-name 
the sub-section to something like "Signature Practices".

>    Signers SHOULD NOT use "l=" unless they intend to accommodate
>    intermediate mail processors that append text to a message.  For
>    example, many mailing list processors append "unsubscribe"
>    information to message bodies.  If signers use "l=", they SHOULD
>    include the entire message body existing at the time of signing in
>    computing the count.  In particular, signers SHOULD NOT specify a
>    body length of 0 since this may be interpreted as a meaningless
>    signature by some verifiers.

So with all that in mind, here's my suggestion for replacing the first part of 
this section:

<<<<<<<<<<<

6.5 Signature Practices

      The purpose of the DKIM cryptographic algorithm is to affix an identifier 
to the message in a way that is both robust against normal transit-related 
changes and resistant to kinds of replay attacks.  An essential aspect of 
satisfying these requirements is choosing what header fields to include in the 
hash and what fields to exclude.

      The basic rule for choosing fields to include is to select those fields 
that constitute the "core" of the message content.  Hence any replay attack will 
have to include these in order to have the signature succeed; but with these 
included, the core of the message is valid, even if sent on to new recipients. 
Common examples of fields with addresses and fields with textual content related 
to the body are:

    o  From

    o  Reply-To

    o  Subject

    o  Date,

    o  To, Cc

    o  Resent-Date, Resent-From, Resent-To, Resent-Cc

    o  In-Reply-To, References

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

    The basic rule for choosing field to exclude is to select those fields for 
which there are multiple fields with the same name, and fields that are modified 
in transit.  Examples of these are:

    o  Return-Path

    o  Received

    o  Comments, Keywords

      Note that the DKIM-Signature field is also excluded from the header-field 
hash, because its handling is specified separately.

      Typically, it is better to exclude other, optional fields because of the 
potential that additional fields of the same name will be legitimately added or 
re-ordered prior to verification.  There are likely...

Folks will note that I've dropped a few, extraneous fields from each list.  In 
terms of the rules for going to Draft, this should be acceptable.  Dropping 
things is ok.  Adding them is not.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Apr 2011 14:07:05 -0700

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Apr 2011 19:54:16 -0400

> In the MLM's case, the entire body plus any fields it added or changed seems like the appropriate content over which to make some assertion of responsibility.

I never did like the term Responsibility in DKIM.

Is this a technical responsibility or legal/moral/ethical responsibility?

Some may view a technical responsibility as leading to or less than a 
technical requirement.  The only technical responsibility I see is the 
required From: binding, and I think we should continue to look at the 
other binding options as helping "responsible" technical designs for 
optimal and secured DKIM mail integration.

So in that vain, with all the legal/moral/ethical responsibility 
connotations aside, from a technical standpoint, it seems to be very 
logical for an MLM resigner to consider the inclusion of headers 
directly related to it:

   Authentication-Result:  helps with "chain of trust" ideas
   List-*:                 Its describes the list!
   Subject:                simply because a MLM may change it
   Reply-To:               simply because a MLM may change it

 From a verifier standpoint, in my opinion.  I know is responsible for 
sending a message, and I know that DKIM wants me to think the signer 
is responsible for "somethings" but is it really?

I was thinking of UPS as a good analogy.

Each parcel has a "standard" insurance but you can purchase extra 
insurance for the entire package. But the only "standard" bit signing 
insurance that comes with all parcels (messages) is the required 
"From:" binding.

Now, if you do get the extra insurance and there are delivery damages, 
UPS will only reimbursed you for the damages parts, not the entire 
package, up to the maximum extra insurance offered.  So in that way, 
one may suggest, one is only responsible when damages occur.  The 
verifier may ask

     "Who is responsible for this broken signature?"

and for valid messages it passing the buck to trust signers:

     "You are now responsible for this valid DKIM message."

Its crazy :)

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2011 02:20:24 -0000

>I don't so much view DKIM as protecting content; rather, my current view
>of its semantics aligns with the whole "taking some responsibility for"
>approach.

So far, so good, the signer takes some responsibility for the message.

> And thus, a signer should only sign those parts of the header and
> body for which it wants to accept responsibility.

Good lord, no.  Taking some reponsibility for the message is not the
same as taking responsibility for some of the message.

If you do that, that pretty much requires that we put back the stuff
that says that a verifier produces an edited verision of the message,
and you better be prepared to have a very, very, very long discussion
about how much of a message a signature has to include for it to be
"enough" and how to design various metrics about the relative value of
signatures that cover more or less of the message.

If you think a message is worth signing, sign it.  If you don't,
don't.  Those are the only two options. When a list manager's domain
signs a message, it's not asserting anything about the literary merit
of the message, it's just saying the message satisfied whatever criteria
it uses to select and pass along the messages it signs.  (Yes, this is
fairly tautological.)

The reason you might not include part of a message in the signature is
that you don't care if someone changes it.  I don't sign Received: or
X-Mailer: headers, because changing or deleting them is harmless.  I
do sign nearly everything else.  This also suggests why the l= option
is not useful, since it says "I don't care if other people add stuff
to the end of the message."

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Apr 2011 22:09:54 -0700

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Monday, April 25, 2011 3:00 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

s/kinds/some kinds/

> included, the core of the message is valid, even if sent on to new recipients.

...or the header and/or body is otherwise modified.

>     o  List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,

One could argue that the MIME fields (omitted here) constitute the core of the message as they go to the representation of the content.  However, they haven't been precluded by the above text so it's probably fine.

I'd actually like to add Authentication-Results because an agent that wishes to claim that observed authentication meta-data should become part of the message core certainly should sign such a field, but that's not worth recycling at Proposed and basically RFC5451 already says that anyway.

> re-ordered prior to verification.  There are likely...

Works for me.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Apr 2011 22:32:50 -0700

On 4/25/2011 10:09 PM, Murray S. Kucherawy wrote:
> One could argue that the MIME fields (omitted here) constitute the core of
> the message as they go to the representation of the content.  However, they
> haven't been precluded by the above text so it's probably fine.

I should at least explain the logic I used in deciding to exclude some items
that were in the original list, where the MIME header fields are perhaps the
most surprising:

      Simply put, they are structural, not semantic.

      Mess with them and the signature breaks, rather than false content getting
accepted.

      So there's no incentive to worry about "protecting" them.

> I'd actually like to add Authentication-Results because an agent that wishes
> to claim that observed authentication meta-data should become part of the
> message core certainly should sign such a field, but that's not worth
> recycling at Proposed and basically RFC5451 already says that anyway.

Interesting.  Hadn't thought about any "newer" fields.  I think the premise, for 
this one, is that security-related fields should be included (other than 
DKIM-Signature).

I suggest folks think about this carefully a bit.  I'm not sure it's 
automatically correct to include these, but I can't think of an argument 
against, in terms of spec basics.

The only wrinkle that I /can/ think of is procedural: /adding/ isn't supposed to 
happen when going to Draft...

  d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Apr 2011 02:26:04 -0400

Murray S. Kucherawy wrote:
>> Common examples of fields with addresses and fields with 
>> textual content related to the body are:
>>
>>     o  From

-1 with the removal of the original text of:

The 5322.From header is a fundamental binding requirement in DKIM 
signatures.

Removing the "(REQUIRED in all Signature)" increases incorrect reading 
of the DKIM specification that 5322.From is not required.  This 
increase potentials for future interoperability issues when a FROM is 
not bound and it will fail validation.

There is clearly no reasonable explanation to remove this strong 
emphasis and just continues to promote negative intent views.  Please 
stop introducing changes that is clearly sensitive and known to create 
a WG conflict and the only way to solve that thorn is to ignore the 
posted concerns.  This a serious WG protest problem with the on-going 
concerns of creeping in removals of all things related to the AUID and 
the required 5322.From bound association with the signature.

Please don't remove this critical requirement text.

> I'd actually like to add Authentication-Results because an agent 
> that wishes to claim that observed authentication meta-data should 
> become part of the message core certainly should sign such a field, 
> but that's not worth recycling at Proposed and basically RFC5451 
> already says that anyway.

IMO, you should as it will help with DKIM Mail Integration.  If you 
think this current non-standard header is IETF RFC material fit issue, 
then is it possible to use a generalized text:

     o Any DKIM related verification results and trace fields

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

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Apr 2011 05:06:21 -0400

This is the problem with this ambiguous "responsibility" term in DKIM 
and it becomes worst when blame or credit is distributed.

IMO, you can't have it both ways.

Sure, you are saying if unsigned parts altered or removed, then the 
mail is still valid, everything is still A O K.  You don't care, you 
are not responsible for these unsigned parts and most important of 
all, the message is trusted if the signer is vouched for some way, 
even if all unsigned parts is removed or altered!

But that can only be true specifically because of the hash bound PARTS 
you signed and took responsibility for.  So in this vain, Murray 
definition sound to be logical and technically correct:

     The signer is only accepting responsibility for the authenticity
     of the specific parts it bound to the signature.

That is much clear than saying:

     "The signer takes some responsibility for the message."

when it doesn't care for what has changed in the message payload as it 
travels.

Another perspective with be a DKIM ready MUA display.

The MUA at ESP1 displays:

     Date: Whatever
     From:  Joe
     To:  Larry
     Subject: Bananas
     Signed by: trustme.com

then I can see your viewpoint better.  There is something about
the signer that it is claiming some responsibility for the message.

But the MUA at ESP2 displays:

     Date: Whatever
     From:  Joe  (Signed by: trustme.com. Click for Details)
     To:  Larry
     Subject: Bananas

     Signer Details:

        Voucher:  ESP2 likes Trustme.com

        Trustme.com has authenticated the following fields:

        From:
        Date:
        Subject:
        To:
        List-ID:

Then Murray is again correct.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Apr 2011 05:32:41 -0400

As a follow up, here is a reason why I think Murray's definition is 
better using a twist on the MUA at ESP2 example:

      Date: Whatever
      From:  Joe  (Signed by: trustme.com. Click for Details)
      To:  Larry
      Subject: Your account is about to expire.

      Signer Details:

         From:
         Date:
         To:
         List-ID:

For some stupid reason, the trustme.com signer did not include the 
subject to be hash bound to signature and we have no idea if the 
subject was modified in transit or reception.  But since the signer is 
not taking responsibility for subject alterations, the user will at 
least now some idea the subject can't be trusted.  Without the details 
like this, the user would not have any idea what could be wrong with 
this trusted message.

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Apr 2011 14:22:15 +0200

On 26/Apr/11 07:09, Murray S. Kucherawy wrote:
>> [...]

I guess Message-ID is among those "structural, not semantic" fields.
I concur.  However, we miss a field that says an MTA is _knowingly_
breaking whatever signatures may be present.

>>     o  List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,

Does List-Id deserve its own bullet?

> already says that anyway.

It is clear that when DKIM talks about "taking some responsibility",
it means it is the MTA as a whole who takes any responsibility, not
the signing agent.  Any field semantics might be documented in some
MLM-policy documentation, if there is a need to make it clear /what/
responsibility is being taken.

A-R is peculiar because it is often added by the very DKIM agent.
However, strictly speaking, the field is not added by the signer, but
by the verifier.

More confusion originates from the fact that MLMs keep lots of
original fields, including From.  I'd propose to replace the last
phrase in the last paragraph of Section 2.1 "Background", so that it
reads something like so, for example:

 The DKIM signing specification deliberately rejects the notion of
 tying the signing {DKIM 12} domain (the "d=" tag in a DKIM signature)
 to any other identifier {DKIM 12} within a message; any ADMD that
 handles a message could sign it, regardless of its origin or author
 domain.  In particular, DKIM does not define any meaning to the
 occurrence of a match between the content of a "d=" tag and the value
 of, for example, a domain name in the RFC5322.From field, nor is
 there any obvious degraded value to a signature where they do not
 match.  An ADMD can thus let an MLM add DKIM signatures to posts
 that originated from other domains, thereby asserting "some"
 responsibility for handling them.  The exact semantics of the signed
 contents is usually documented elsewhere.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Apr 2011 10:02:04 -0700

> From: Hector Santos [mailto:[email-masked]]
> Sent: Monday, April 25, 2011 11:26 PM
> To: Murray S. Kucherawy
> Subject: Re: [ietf-dkim] ISSUE: Updating Section 6.5: Recommended
> Signature Content
> 

It is redundant to the first sentence in the text of Section 6.4 which already says From MUST be signed; there's no reason to repeat it here, especially since this section is clearly advisory in nature only, and thus there's no harm in removing it.

>      o Any DKIM related verification results and trace fields

That's not correct; RFC5451 is standards track.

The issue is that adding things to DKIM now will prevent its progress toward Draft Standard, which is something we're trying to avoid.  Removing things, on the other hand, doesn't introduce any backward compatibility issues, and so that's allowed.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Apr 2011 14:25:06 -0400

> It is redundant to the first sentence in the text of Section 6.4 which already
> says From MUST be signed; there's no reason to repeat it here, especially
> since this section is clearly advisory in nature only, and thus there's no
> harm in removing it.

Perhaps, but I agree that it would be useful to remind people.  Why
not leave it there, with a reference to the normative statement?

>> > already says that anyway.
...
> The issue is that adding things to DKIM now will prevent its progress toward
> Draft Standard, which is something we're trying to avoid.  Removing things, on
> the other hand, doesn't introduce any backward compatibility issues, and so
> that's allowed.

I don't think so.  This section is not normative -- we've already
*removed* the SHOULD in it, and that's the removal.  After that,
anything we add is an idle suggestion, and doesn't affect conformance.
 I think we can put anything we want in here, informatively.  We can
even be general -- that is, we can say "Authentication-Results [tm]",
or we can say, "any header field that conveys authentication results,"
or some such.

Barry, as participant

---

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Tuesday, April 26, 2011 11:25 AM
> To: Murray S. Kucherawy
> Subject: Re: [ietf-dkim] ISSUE: Updating Section 6.5: Recommended Signature Content
> 

With the back-reference, I guess I feel better about it.  Without it, in my head it's akin to repeating normative assertions in different places, begging for divergence.

> or we can say, "any header field that conveys authentication results,"

If consensus concurs with that view, then I would indeed like to add something like "any header field that conveys important meta-information about the message, such as authentication information from a relay (e.g., [RFC5451])".

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 27 Apr 2011 15:10:22 +0100

> breaking whatever signatures may be present.

The Message-ID gets copied into the References of replies. I can imagine a  
situation where a scammer changed the Message-ID in order to make a  
message appear in the wrong thread (most MUAs try to display messages in  
threads, and do it in a sufficiently similar manner that such a scam might  
work).

The same might even be true of Content-Type (though the scammer would have  
to be pretty smart to dream up a viable mechanism). But, sadly, scammers  
ARE smart :-( .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Apr 2011 10:56:03 -0700

Recommend adding the following paragraph (excuse the XML markup):

<t> There are tradeoffs in the decision of what constitutes
the "core" of the message, which for some fields is a
subjective concept.  Including fields such as "Message-ID"
for example is useful if one considers a mechanism for
being able to distinguish separate instances of the same
message to be core content.  Similarly, "In-Reply-To"
and "References" might be desirable to include if one
considers message threading to be a core part of the
message. </t>

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 29 Apr 2011 16:40:29 -0700

> Recommend adding the following paragraph (excuse the XML markup):

+1

the text is modest and meaningful.  it highlights things without belaboring them.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Fri, 29 Apr 2011 20:33:52 -0400

> considers message threading to be a core part of the

hmmm, "if one considers...."  Oy vey.

Message-id is a "core" header in mail systems as part of the 
authenticity of the message and highly used as part of dupe checking 
algorithms. That is not subjective concept. It is part of robust mail 
system designs. Its very vexing to me to understand how this is being 
contested.  What is subjective is the above text with an inference the 
Message-ID is of low utility and low deployment for message 
identification.

The goal for DKIM is to increase verifiable authenticity and the 
Message-ID is one of those persistent header expectations. It is never 
expected to be changed or removed.

Besides, where was the WG consensus for the removal in the first 
place?  You can't just remove something and force everyone to waste 
time proving why it should be added. It was added in the first place 
since the original document for good reason and remain there all these 
years until this WGLC last minute.

That's just not right.

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 29 Apr 2011 20:56:25 -0400

My preference would be Message-Id SHOULD be part of the top core 
listing and if wish to add text to explain use cases when/why it 
should|may not considered be hashing, that would be make more DKIM 
engineering sense to me.

It should be the exception and not the rule to not consider a 
Message-ID as part of the "core" group. So if anything,

    There are tradeoffs in the decision of what constitutes
    the "core" of the message, which for some fields is a
    subjective concept with use cases where modifications
    or removals are possible. For example, excluding fields
    such as "Message-ID" may apply under certain scenario
    where it is known this header may be altered, such as
    under a resigner creating a new message.

Whatever.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 30 Apr 2011 12:52:29 -0400

> considers message threading to be a core part of the

I like this.

Barry, as participant