Subject: [ietf-dkim] Getting resolution on the "double header" issue

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Nov 2010 17:20:19 +0800

I have a chair statement to start with, and then the rest of this
message will be as a participant.

As chair:
We have gone off in the weeds on the "double header" issue, and are
fighting with ourselves.  The chairs need everyone to aim at getting
some rough consensus on this, so we're asking this: let's focus, as we
once did, on working together to achieve a result that most of us, at
least, can live with.  That means that many people will not get it
just the way they want it, and you might not see a result that you
consider ideal.  I think we're close enough, really, on this that we
can still get a result that we consider acceptable.

Because we're in the middle of the IETF meeting, some of us --
including the chairs -- are very busy this week.  Let's set a deadline
of 24 November, and say that by that date we will have an answer that
has rough consensus.  Please, folks, give and take, and work together
to reach that.

As a side issue, I would like the 4871bis editors to post a message by
that same date summarizing the other open issues with 4871bis, and
their assessment of the current consensus state of them.  We would
still like to get the issues resolved and get 4871bis to the IESG in
December, probably for the 16 Dec telechat.

As participant:

Here's how I see the situation.  It's purely as a participant, and has
no chair weight.  I think it does represent a compromise position that
should work.

Problem description:
An "attack" has been described that can be mounted by adding a second
"from", "subject", or possible other header field that is only
supposed to appear once.  This situation might fool a UA, filtering
software, or some other software into considering the added, unsigned
field as the "real" one.

Who is responsible for dealing with this situation?  If the DKIM spec
is at least partially responsible, to what extent, and what should it
say?

Proposal:

1. The DKIM spec is responsible for describing the problem in terms of
how it relates to signed and unsigned versions of the fields.  That's
the stuff in 8.14.

2. The DKIM spec should probably say that signers need to sign valid
messages, and, therefore, SHOULD NOT sign things like this.  Text
along the line of this might work well:
"Signers SHOULD take reasonable steps to ensure
that the messages they're signing are valid according to [RFC 5322,
etc]."  Leaving the definition of "reasonable" out allows flexibility.  It
may be waffly, but I like the approach in this case.

3. It'd be reasonable for the DKIM spec to remind verifiers that
signers aren't supposed to sign stuff like this, so they might
consider that when deciding what to do with it after verification.
It'd be reasonable to remind them of this particular case.  But
I think that all ought to be informative text.

4. We should agree to this or some variant of it, and then move on.
This is not meant to satisfy everyone.  In fact, it isn't what I'd prefer,
if I had my full choice.  But it takes care of the problem in a way
that I think is sufficient, and allows us to resolve the issue.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Nov 2010 13:50:37 +0100

On 08/Nov/10 10:20, Barry Leiba wrote:
> [...]

+1.  IMHO, 8.14 may avoid giving any advice, if we are unable to agree 
on any.  However, in such case, I'd recommend to take Julian's 
suggestion[1] of replacing "Comments" with "From" in the note that 
exemplifies the "ugly hack".
[1] http://mipassoc.org/pipermail/ietf-dkim/2010q4/014683.html

> may be waffly, but I like the approach in this case.

+1.  Enforcing some RFC conformance is a task that many MTAs can 
(optionally) do natively.  Perhaps this is an issue about MTA 
configuration, rather than specifically for the signing module.  For 
example, I'm quite happy that such tweaking occurs before signing, so 
that the signer signs the revised version.  However, since also the 
verifying filter is invoked after any optional modifications, I've had 
to enable them for MSA only.

> I think that all ought to be informative text.

This is again a question of roles.  John has (correctly) recommended 
that verifiers don't tamper with the message content, except for 
possibly adding an A-R field.  However, a DKIM verifier does not 
/have/ to act as a verifier only.  An additional role is the umbrella 
under which a filter module may discard suspicious messages, suppress 
unsigned singleton fields that occur more than once, or anything it 
deems cool.

I agree it should be informative, w.r.t. DKIM.

> that I think is sufficient, and allows us to resolve the issue.

+1.

---

From: <[email-masked]>
Date: Mon, 8 Nov 2010 08:01:19 -0500

works for me (to the mailing list this time)

---

From: Hector Santos <[email-masked]>
Date: Mon, 08 Nov 2010 09:18:36 -0500

> is at least partially responsible, to what extent, and what should it

Whether we have the guts to do what is correct as oppose of trying to 
"work it in" due to IETF meeting mile stones and time deadlines, is 
entirely different issue.

IMO, DKIM is responsible for the input that are part of is formula. 
Parts it MUST make sure are RFC5322 correct for consumption with its 
"purported trust" signature, especially its sole single input header 
requirement, 5322.From.

> how it relates to signed and unsigned versions of the fields.  That's

Who's version?

> may be waffly, but I like the approach in this case.

+1

> I think that all ought to be informative text.

+1

> that I think is sufficient, and allows us to resolve the issue.

+1

I believe I provided good text with the original ISSUE posting I made 
and also modifications along the threads.   This focus mainly with 
following up with the logic for the "last header" begins in Section 
5.4 and where the corrective text should be made.   Its a "do this 
...., but keep in mind that ...." semantic.

Overall I prefer to see an updated specification that will help 
developers write software consider options to deal with this 
correctness issue directly and independently from another protocol 
logic.  IMO, this is the proper Software Engineering approach to 
maximize a fix across all MTA of all kinds.   I prefer not to read 
text that tries to pass the buck, push the burden on to MTAs or MUAs 
solely.  That will minimize the adoption rate because they could be 
legitimate MTAs that are not capable to satisfy the "outside RFC5322 
correctness requirement or mandate" in order for DKIM to provide 
workable results.

At the end of the day, I believe that it is major goal to get ALL DKIM 
software to work with the same expectation here and not get into 
situations in the future where there are deviations.  It MUST become a 
mandate in order to build the initial trust required for DKIM.

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 08 Nov 2010 09:52:38 -0500

Alessandro Vesely wrote:

> (optionally) do natively.  

But DKIM can not make that presumption that is the prevailing nature 
of "many" MTAs.   At best, it can RECOMMEND that integration DKIM into 
a mail system that for BEST results, a general filter would address 
this issue.  But it can't assume that will be possible as it might 
mean a software change. Hence the better DKIM software will offer a 
direct solution that COULD be turned off when the MTA is capable of 
doing the filter itself.

For example, OpenDKIM is a package mainly for the Sendmail MTA. It may 
have or will have a MTA milter to check for RFC 5322 compliance. 
However, the I believe the software also allows has a DKIM only 
component that can be used in other MTAs.  You don't know if these 
other MTAs will have the same kind of filter DKIM is expecting in 
order to have clean results.

Now take Alt-N pure C/C++ DKIM API with no tie-ins to any MTA.  It has 
an non-overhead DKIM verifier option that deals this multiple 
5322.From issue  directly and independently from any other layered 
requirement.

To me, the latter is the best approach for the specification to take. 
Allow Readers of this document to decide how they will implement DKIM 
based on the MTA they are using or MTAs they are targeting.

> Perhaps this is an issue about MTA 
> configuration, rather than specifically for the signing module.  

Which is just as equal of saying MTAs may or may having RFC5322 
compliance checking.  DKIM can not be dependent for providing valid 
results only when working with MTA that have RFC5322 compliance checking.

> For 
> that the signer signs the revised version.  

Tampering with mail is not justified here.   Either the mail is good 
to sign or bad to sign when it comes to DKIM signing.

> unsigned singleton fields that occur more than once, or anything it 

Generally, the caller of the DKIM procedure would act on its results.

I prefer to see a "blackbox" model for DKIM where its interface points 
are well defined.  Its input was well described with stated boundary 
conditions and its output is well defined and described with a view on 
being a feed for possible message filters/handlers.

-- 
Sincerely

Hector Santos

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 8 Nov 2010 10:52:55 -0500

> that I think is sufficient, and allows us to resolve the issue.

I think this oversimplifies the issue from a DKIM perspective.  

If this were added, should signatures that sign a second (non-existant) from 
header specifically to ensure header addition breaks the signature verification 
be verified if in fact the message hasn't been modified?  

Rather than fall back purely on 5322, I'd prefer to see something in security 
considerations that says if the count of a particular header field that is 
supposed to be limited (e.g. From and Subject) present in a message exceeds 
the number of signed fields, then the signature shouldn't be verified.  

Additionally, signing a message with (for example) two From: fields is not a 
problem in the context of this issue, so the advice not to sign such messages 
isn't particularly related.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Nov 2010 18:28:26 +0100

On 08/Nov/10 15:52, Hector Santos wrote:
> this issue.

Yes.  If there will ever be an "MTA considerations" appendix, it may 
prompt MTA developers to provide for filtering callbacks at the right 
points.

> But it can't assume that will be possible as it might mean a
> software change. Hence the better DKIM software will offer a direct
> solution that COULD be turned off when the MTA is capable of doing
> the filter itself.

Anything we change in the protocol may imply software changes.

> order to have clean results.

Yes, the library component of OpenDKIM provides for just DKIM (well, 
it also has some generic utilities, e.g. for parsing mailboxes.)  It 
works equally well with different MTAs as offline.

> 5322.From issue  directly and independently from any other layered

However, that feature makes for more difficult usage.  It tells the 
caller that a given signature failed to verify by delivering a status 
of DKIM_UNSIGNED_FROM.  Now, suppose the caller is a forensic tool, 
rather than an MTA filter.  The tool is interested in knowing whether 
the signature validates, but it cannot be sure that the reported 
status was the /only/ problem with that signature.  In facts, it'd be 
better off disabling such verifier option.  (And it can be disabled 
because it is not mandated.)

Now for MTA message filters.  Why should a DKIM library hide the 
simple facts and opt for telling them what to do instead?  It is quite 
trivial to count the "From" fields in the header.  A library can 
provide a function that tells whether a given field was signed by a 
given signature.  Based on such simple facts, a filter may make 
various decisions.  It may turn out that an unsigned "From" deserves 
the same treatment as a failed signature, but are we sure that that is 
the only one option whatever the circumstances?  Actually, we haven't 
observed many occurrences of that attack in the wild.

> based on the MTA they are using or MTAs they are targeting.

However, if that behavior were mandated, it would affect all compliant 
libraries, forensic tools notwithstanding.

+1.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Nov 2010 10:26:43 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Monday, November 08, 2010 1:20 AM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Getting resolution on the "double header" issue
> 
> Proposal:
> 

Concur.  I worked through an 8.14 proposal a couple of weeks ago using input from the list.  The last text I have was:

8.14 Malformed Inputs

DKIM allows additional header fields to be added to a signed message without breaking the signature.  This tolerance can be abused, e.g. in a replay attack, by adding additional instances of header fields that are displayed to the end user or used as filtering input, such as From or Subject, to an already signed message in a way that doesn't break the signature.

The resulting message violates section 3.6 of [MAIL].  The way such input will be handled and displayed by an MUA is unpredictable, but in some cases it will display the newly added header fields rather than those that are part of the originally signed message alongside some "valid DKIM signature" annotation. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field.

Because of this, DKIM implementers are strongly advised to reject or treat as suspicious any message that has multiple copies of header fields that are disallowed by section 3.6 of [MAIL], particularly those that are typically displayed to end users (From, To, Cc, Subject).  A signing module could return an error rather than generate a signature;  a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates.

Senders concerned that their messages might be particularly vulnerable to this sort of attack and who do not wish to rely on receiver filtering of invalid messages can ensure that adding additional header fields will break the DKIM signature by including two copies of the header fields about which they are concerned in the signature (e.g. "h= ... from:from:to:to:subject:subject ...). See Sections 3.5 and 5.4 for further discussion of this mechanism.

Specific validity rules for all known header fields can be gleaned from the IANA "Permanent Header Field Registry" and the reference documents it identifies.

> etc]."  Leaving the definition of "reasonable" out allows flexibility.
> It may be waffly, but I like the approach in this case.

Works for me.  How about:

3.10. Input Requirements

DKIM's design is predicated on valid input.  Therefore, signers and verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [MAIL], [MIME], and any other relevant message format standards.  See Section 8.14 for additional discussion and references.

> I think that all ought to be informative text.

Yup; the above two amendments cover both cases.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Nov 2010 12:26:30 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Monday, November 08, 2010 9:28 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Getting resolution on the "double header" issue
> 

Two points about that:

1) The proposed 8.14 does bring up some MTA considerations relevant to the issue we've been discussing.

2) I just introduced a draft intended to become a place to collect discussion about how best to handle common malformations, and this could include the case we've been discussing.  It's intended to get BCP status, but I don't think we want to work on it in this working group.  (draft-kucherawy-mta-malformed if anyone wants to provide feedback.)

> works equally well with different MTAs as offline.

Just to be precise:  OpenDKIM includes a filter that uses the milter protocol to talk to MTAs, but is not "mainly for" any one MTA.  Postfix and Oracle's MTA (formerly Sun JMS) can both use it as well since they have adopted milter.

But it also includes a library that is completely MTA agnostic, and in fact is in use in production at AOL and Yahoo with whatever MTAs they're using there.

The filter already does the RFC5322 checking, but the library currently doesn't (apart from erroring out if the input message doesn't contain a From field, since RFC4871 needs that).  It's deliberately a pretty pure partition wherever possible.  However, I have opened an RFE to add the more thorough checking as an option to the library in case a filter developer doesn't want to bother but is concerned about this issue.

-MSK

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 8 Nov 2010 16:29:42 -0800

+1

> I think that all ought to be informative text.

Seems unnecessary per #2 above, but I don't care all that much either way.

+1

> the number of signed fields, then the signature shouldn't be verified.  

I'd have no objection to this either.

At this point the only strong objection I'd have would be if the consensus measurement were based on one or two people repeatedly expressing Very Strong Feelings while the rest (like me) mostly don't care.  A "meh" result is not the same as a yes or no.

---

From: "John R. Levine" <[email-masked]>
Date: 8 Nov 2010 21:05:09 -0500

> may be waffly, but I like the approach in this case.

This is OK, but it misses the scenario where a bad guy takes an existing 
signed message and prepends another Subject: or From: header.  It's more 
effective to address this in the verifier.

> I think that all ought to be informative text.

I don't feel strongly about how normative we make the language, but I do 
think it would be a good idea to encourage verifiers not to say the 
signature is valid on a message with extra headers, even if it 
mechanically verifies.  This catches both the sloppy signer and the 
hostile intermediary.

FWIW, my DKIM verifier has for several weeks rejected anything which has 
an extra of any of these headers:

>From Sender Subject Date To Cc MIME-Version Content-Type Content-Transfer-Encoding

I haven't collected detailed statistics, but I can report that nothing 
horrible has happened.  It's Mail::DKIM, the changes are about eight 
lines.  Anyone else wants it, just ask.

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: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Nov 2010 13:25:05 +0100

> effective to address this in the verifier.

I'd agree on the effectiveness of that approach from a software design 
POV only.  Designing specifications may involve different 
considerations...

> an extra of any of these [omitted] headers:

Thanks for putting it that way, John.  It makes it easier to clear the 
issue:  I think everybody agrees that DKIM specifications say nothing 
about rejecting.  Therefore, John's software is called a "DKIM 
verifier" somewhat improperly.  It /includes/ a DKIM verifier, but 
also acts as a band-pass message filter.

IMHO, strong feelings about this issue come up from misunderstandings 
about these roles.  On the one hand we have a normative definition of 
the mechanical properties of signatures.  On the other hand we want to 
deal with MTA behavior, since that is the mechanism's semantics.  One 
problem of tackling both topics within the same document is that 
making normative statements about MTA behavior may result in confusion 
between semantic validation and mechanical verification.

At this point I would rephrase the third paragraph of Murray's "Take 
two" for 8.14 Malformed Inputs, as follows:

  Because of this, DKIM implementations for MTAs are strongly advised
  to couple with message filters who can complement their MTA's native
  checks and reject or treat as suspicious any message that has
  multiple copies of header fields that are disallowed by section 3.6
  of [MAIL], particularly those that are typically displayed to end
  users (From, To, Cc, Subject).  A signing module could return an
  error rather than generate a signature;  a verifying module might
  return a syntax error code or arrange not to return a positive
  result even if the signature validates according to normative DKIM
  specification.

However, referring to another document --either ADSPbis or 
draft-kucherawy-mta-malformed-- may allow for stronger and clearer 
language.  For example, setting "dkim=fraud" in an A-R field would not 
be confused with broken signatures like "dkim=fail (technically pass)".
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Todd Lyons <[email-masked]>
Date: Mon, 8 Nov 2010 20:13:39 -0800

On Mon, Nov 8, 2010 at 6:05 PM, John R. Levine <[email-masked]> wrote:
> horrible has happened.

I have an exim system that I've enforced rfc5322 on for a few days
now.  I quarantine, but still deliver as well (for now).  So far I've
seen emails from the following well known sources that failed this
test.
1. [email-masked] (multiple To, one is blank)
2. [email-masked] (same as #1)
3. University of Montana tuition bill (multiple To)
4. sendmail DSN's from my own sendmail system (multiple To) (ok, not
well known, but I'm the source and I'm aware of it)

>  It's Mail::DKIM, the changes are about eight

I'd be interested in that.

-- 
Regards...      Todd
I seek the truth...it is only persistence in self-delusion and
ignorance that does harm.  -- Marcus Aurealius

---

From: "John R. Levine" <[email-masked]>
Date: 9 Nov 2010 20:20:51 -0500

> also acts as a band-pass message filter.

Um, no.  When I said "DKIM verifier" I meant DKIM verifier.

Please avoid speculating when you could just ask.

R's,
John

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 11 Nov 2010 11:47:37 -0000

> can still get a result that we consider acceptable.

OK. Here is a suggestion. I think it is broadly in line with your  
"proposal", but it includes various almost-orthogonal parameters that can  
be tweaked independently of each other to provide a final version.  
Word-smithing can come later, and it will also need NOTEs and Security  
Considerations to explain the problem(s) and how they are covered. But be  
clear that this is an unashamedly Normative proposal.

1. Framework:

o Signers MUST/SHOULD do "something" (see below) in the event that the
   message contains multiple "once-only" headers.
       PLUS
   Verifiers MUST/SHOULD check that "something" had been correctly applied
   (else PERMFAIL). Note that this will catch both headers maliciously added
   in transit/replay and malicious signers.

o As above, but covering other RFC 5322 violations as well as "once-only"
   headers.

2. Normativeness:

o MUST

o SHOULD

3. Definintion of "something"

o Refuse to sign (i.e. reject) if multiple "once-only" found [or other 5322
   violations]. I had a wording for this.

o Permit signing of multiple "once-only" (even though violating 5322), but
   require ALL those headers to be signed (i.e. included in 'h=' tag).
   Hector has a wording for this.

4. Scope of "something"

o Apply the above to ALL multiple "once-only" headers found.

o Apply the above only to those headers actually mentioned in the 'h=' tag.
   (e.g. allow multiple Subject:s if Subject entirely absent from 'h='.)

5. Definition of "once-only"

o Just the From: header

o All headers defined as once-only in RFC 5322.

o As above, but include RFC 2045

o As above, but include at least some List-* headers

o Other, please specify

I count the permutations of those as leading to 80 different proposals,  
though I suspect some of them are not meaningful. But they cover most of  
the normative-style proposals that have been made during the dicussion.

And note that there are no layering violations (since the one protocol  
simply introduces a requirement to be applied at one stage and checked at  
another).

-- 
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: Douglas Otis <[email-masked]>
Date: Thu, 11 Nov 2010 11:55:55 -0600

rfc4871bis-02 Introduction:
,---
...
DKIM:

  o  is compatible with the existing email infrastructure and
       transparent to the fullest extent possible;

  o  requires minimal new infrastructure;

  o  can be implemented independently of clients in order to reduce
       deployment time;

  o  can be deployed incrementally;

  o  allows delegation of signing to third parties.
...
'---

DKIM establishes additional trust based upon a signature's domain, where 
DKIM MUST protect use of this trust without assuming  changes will be 
made to existing email infrastructure.  Some have suggested new 
mail-filtering should be added to MUAs, MTAs, and other mail agents to 
prevent exploits of DKIM trust allowed by DKIM's verification having 
neglected essential checks for multiple singleton header fields.

Once one DKIM verification vendor includes these necessary checks that 
suppress DKIM PASS, and another vendor does not, DKIM implementations 
are no longer compatible.  IMHO, this represents a DKIM protocol failure 
to properly define elements that MUST BE checked to qualify a DKIM PASS 
verification result.  The DKIM protocol may require future updates as 
new exploits are discovered, or a significant design goal will have been 
lost.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 12 Nov 2010 17:35:52 -0000

> new exploits are discovered, or a significant design goal will have been

Actually, for the particular problem we are considering, this will not  
arise.

In the scheme I have proposed, the Signer MUST do X and the Verifier MUST  
check that the Signer had done X.

However, X only arises where there are multiple once-only headers (so the  
message is already 5322 incompatible). So even if the (old) signer fails  
(to sign both in this case), the (new) verifier is then merely rejecting a  
message that was 5322-incompatible anyway, which is no big deal.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 15 Nov 2010 12:00:19 -0800

On 11/12/10 9:35 AM, Charles Lindsey wrote:
> On Thu, 11 Nov 2010 17:55:55 -0000, Douglas Otis<[email-masked]>
> wrote:
>
Disagree. Unless a DKIM verifier MUST NOT return PASS for messages with 
multiple once-only (singleton) headers, DKIM results can not be 
trusted.  In such a scenario, pre-pended singleton header fields are 
beyond the control of an Author Domain when two From header fields exist.

For example:
  From: [email-masked]
  From: [email-masked]
  DKIM-Signature: d=big-isp.com; ...

It does not matter how big-bank.com signs, the verification process MUST 
check for multiple singleton header fields to prevent many types of 
exploits.  Double entries for all singleton header fields within the h= 
parameter is wasteful, where full protection requires universal 
adoption.  It would be ridiculous to expect adoption by bad actors.

Only by the DKIM protocol mandating a MUST check for multiple singleton 
header fields by the verifier, will these exploits be prevented.  
Without this requirement, DKIM has little meaning.  DKIM's design goals 
can not be met by expecting critical checks to be made elsewhere.  These 
checks are normally not needed and not made since without DKIM, there is 
no trust based upon the DKIM signing domain to be exploited.

Clearly, the DKIM protocol failed to be explicit about this 
requirement.  Only by making the verifier requirement explicit, can DKIM 
compliance provide trustworthy results and compatible implementations.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 22 Nov 2010 14:32:41 -0800

Murray argued singleton header checks to qualify DKIM signatures 
violates protocol layering.  SMTP messages are exchanged in two parts, a 
header and a body section. The header section should conform with 
RFC5322, and the body should conform with RFC2045.  RFC2047 and RFC2231 
define header encoding for non US-ASCII repertoire using US-ASCII, and 
RFC1652 relaxes restrictions on the body.

Section 6.4 of RFC5321 makes it clear that non-compliance with RFC5322 
occurs, and that there is no consensus whether to reject, repair, or 
accept such messages.  RFC1847 (Security Multiparts for MIME), RFC4880 
(PGP), or RFC3851 (S/MIME) authenticates the source and integrity of the 
message body, whereas DKIM retains the integrity of trusted portions of 
the header section, specifically the From header field, and perhaps others.

Whenever message acceptance is based upon valid DKIM signatures by 
trusted domains, defeating trivial exploitation of DKIM's bottom-up 
header selection requires exclusion of multiple singleton header fields 
from being considered having valid DKIM signatures.  Otherwise, this 
would permit inappropriate header fields to be conveyed using top-down 
selections.  It is imperative that DKIM's verification process defeat 
such exploits, since DKIM does not assume applications conveying the 
header section is DKIM aware.

Expecting consumers of DKIM results to re-evaluate the header section 
eliminates DKIM's value proposition.  Recommending subsequent checks for 
multiple singleton headers represents poor protocol layering, since this 
would expect consumers of DKIM results to recheck the header section 
being associated with a DKIM domain.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 23 Nov 2010 10:38:48 -0000

On Mon, 22 Nov 2010 22:32:41 -0000, Douglas Otis <[email-masked]>  
wrote:

> violates protocol layering.

Which is why I want to fix this problem with normative wording that does  
not violate protocol layering.

Quite simple:

Signers MUST/SHOULD not sign messages with multiple <0nce-only> headers  
(detailed wording to be discussed).

Verifiers MUST/SHOULD check that signing requirement has been met (i.e.  
that no multiple <once-only> headers, or whatever the detailed wording  
says, are present).

No protocol layering violation, because the verifier is just checking  
something laid down for signers in the same protocol. RFC 5322 hardly gets  
mentioned, except presumably when defining <Once-only> or in eplanatory  
NOTEs, secutiy considerations, etc. All the scams under discussion still  
get caught.