Subject: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03 submitted

From: Dave CROCKER <[email-masked]>
Date: Wed, 16 Feb 2011 09:18:21 -0800

Folks,

A new version of rfc4871 has just been posted as an I-D.  A diff is attached.

The draft is available at:

    <http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-03>

This version does NOT contain text that resolves two outstanding issues:

> Subject: [ietf-dkim] Focusing on 4871bis
> Date: Fri, 22 Oct 2010 11:28:10 -0400
> From: Barry Leiba <[email-masked]>
...
> 2. Advice about wildcards in TXT records.
> Proposed change: Add a note in section 6.1.2 warning about the effect
> of wildcard TXT records on finding DKIM key records.
>
> 3. The issue of multiple occurrences of header fields that may only occur once.
> Proposed change: Add text to section 5.3 recommending that verifiers
> check that the message complies with specs, and that they not validate
> a non-compliant message.  Add a new section 8.14 to the Security
> Considerations, explaining the attacks that can be done using this
> exposure.

I was not able to determine what the wg rough consensus is, for either of these 
points, and am unable to formulate a proposal that might move towards resolution.

The best I can suggest is that Barry tell us what text to add when consensus on 
the relevant changes is reached.

d/
-- 

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

---

From: John Levine <[email-masked]>
Date: 17 Feb 2011 05:55:11 -0000

>> of wildcard TXT records on finding DKIM key records.

Section 3.6.2.1 currently says:

      INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g.,
      *.bar._domainkey.example.com) do not make sense in this context
      and should not be used.  Note also that wildcards within domains
      (e.g., s._domainkey.*.example.com) are not supported by the DNS.

That first sentence is just plain wrong.  I have been using wildcard
DNS records of exactly that form for months, and they work fine.  I
put a unique selector on each message, and when I get around to it
will extract the DNS lookup info to figure out how many people are
looking at my signatures.  This may be morally reprehensible, but it
does make sense.

I suggest we delete the whole note.

Section 6.1.2 says:

   NOTE:  The use of wildcard TXT records in the DNS will produce a
      response to a DKIM query that is unlikely to be valid DKIM key
      record.  This problem applies to many other types of queries, and
      client software that processes DNS responses needs to take this
      problem into account.

This is only true if the name of the record doesn't include
_domainkey, so *._domainkey.example.com or
*.foo._domainkey.example.com is OK, but *.example.com is not.  So I
suggest we rewrite it as:

   NOTE: Wildcard TXT records whose names are not in the _domainkey
      subdomain will generally produce a response to a DKIM query that
      is not a valid DKIM key record.  This problem applies to many
      other types of queries, and client software that processes DNS
      responses needs to take this problem into account.

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: Wietse Venema <[email-masked]>
Date: Thu, 17 Feb 2011 08:42:04 -0500 (EST)

> I suggest we delete the whole note.

I suggest replacing this with the replacement 6.1.2 text proposed
below, but I would not object to John's proposed changes either.

So that's a +1 from me.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Feb 2011 15:31:32 -0800

On 2/16/11 9:18 AM, Dave CROCKER wrote:
> > Subject: [ietf-dkim] Focusing on 4871bis Date: Fri, 22 Oct 2010
> > 11:28:10 -0400 From: Barry Leiba <[email-masked]>
>  ...
> > 2. Advice about wildcards in TXT records. Proposed change: Add a
> > note in section 6.1.2 warning about the effect of wildcard TXT
> > records on finding DKIM key records.
> >
> > 3. The issue of multiple occurrences of header fields that may only
> > occur once. Proposed change: Add text to section 5.3 recommending
> > that verifiers check that the message complies with specs, and that
> > they not validate a non-compliant message. Add a new section 8.14
> > to the Security Considerations, explaining the attacks that can be
> > done using this exposure.

As John Levine noted, there is incorrect text in 3.6.2.1. Namespace.

,--
'--

Change to:
,==
Wildcard DNS records (e.g., *.bar._domainkey.example.com) could be used 
for logging purposes.
'==

3.6.1. Textual Representation

t= Flags, ...

There might be some informative text added to clarify repeated use of a 
tag-list identifiers, unlike tags, is allowed.   It seems some domains 
create separate t=y and t=s entries rather than t=y:s, for example.

6.1.2. Get the Public Key
...
Was:
,--
NOTE:  The use of wildcard TXT records in the DNS will produce a
    response to a DKIM query that is unlikely to be valid [a] DKIM key
    record.  This problem applies to many other types of queries, and
    client software that processes DNS responses needs to take this
    problem into account.
'--

Change to:
,==
NOTE:  The use of wildcard TXT records in the DNS might be used for 
logging proposes, but its use is discouraged as it will have a 
detrimental effect on DNS caching.
'==

CHARTER FAIL:

8.14. Attacks Involving Addition of Header Fields

Was:
,--
For example, a message with multiple From: header fields violates
Section 3.6 of [RFC5322].  With the intent of providing a better user
experience, many agents tolerate these violations and deliver the
message anyway.  An MUA then might elect to render to the user the
value of the last, or "top", From: field.  This may also be done
simply out of the expectation that there is only one, where a "find
first" algorithm would have the same result.  Such code in an MUA can
be exploited to fool the user if it is also known that the other
From: field is the one checked by arriving message filters.  Such is
the case with DKIM; although the From: field must be signed, a
malformed message bearing more than one From: field might only have
the first ("bottom") one signed, in an attempt to show the message
with some "DKIM passed" annotation while also rendering the From:
field that was not authenticated.  (This can also be taken as a
demonstration that DKIM is not designed to support author
validation.)

To resist this specific attack the signed header field list can
include an additional reference for each field that was present at
signing.  For example, a proper message with one From: field could be
signed using "h=From:From:..."  Due to the way header fields are
canonicalized for input to the hash function, the extra field
references will prevent instances of the cited fields from being
added after signing, as doing so would render the signature invalid.

The From: field is used above to illustrate this issue, but it is
only one of > several fields that Section 3.6 of [RFC5322] constrains
in this way.  In reality any agent that forgives malformations, or is
careless about identifying which parts of a message were
authenticated, is open to exploitation.
'--

Change to:
,==
A message with multiple From: header fields violates Section 3.6 of
[RFC5322].  With the intent of providing a better user experience,
many agents tolerate these violations and deliver the message anyway.
Any message containing multiple orig-date, from, sender, reply-to,
to, cc, message-id, in-reply-to, and subject header fields will not
produce a valid signature.  See Section 5.3.  Verification and
presentation layers will not always process headers in the same order
or confirm content synchronicity.  Allowing multiple singleton
header fields within a message to verify as having a valid DKIM
signature enables trivial spoofing exploits not always remedied by use
of h=from:from, for example.
'==

From: [email-masked] (Displayed)
From: [email-masked] (Not Displayed)
DKIM-Signature: d=mallory-bank.com... (signature valid when From: 
[email-masked] not prefixed.)

Users may expect DKIM messages from big-bank.com to be rejected when not 
signed by big-bank.com on the basis of ADSP or ISP policy.  Unless 
multiple-singleton headers are prohibited from receiving DKIM pass 
results, then users are likely to believe a message with a prefixed 
From: [email-masked] will be assumed to have been signed by 
big-bank.com.  Use of h=From:From: would be controlled by 
mallory-bank.com, and not big-bank.com, which could simply use h=From.

The primary use of DKIM was to serve as protection from phishing, where 
checking for multiple singleton header fields represents a trivial 
amount of overhead compared against signature validation.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Feb 2011 13:08:08 +0100

On 22/Feb/11 00:31, Douglas Otis wrote:
> produce a valid signature.  See Section 5.3.

The current Section 5.3 says:

   Therefore, a verifier SHOULD NOT validate a message that is not
   compliant with [RFC5322, RFC2045 and RFC2047] specifications.

IMHO, it is somewhat vague.  That SHOULD-NOT could be "promoted" to a
MUST-NOT for a finite number of specific features --to be explicitly
listed for readers' convenience.  Since it is a verifier's action,
this consideration should perhaps be moved somewhere toward the end of
Section 6.  Anyway, it is vital to keep such issues related to
5322-semantics clearly separated from crypto-mechanical
signature-validity specifications.  Collecting them into their own
section(s) may ease a future split.

BTW, Section 5.3 has some other paragraphs on 7-bit encoding that may
deserve revisions, also in view of EAI.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Feb 2011 10:56:25 -0800

> deserve revisions, also in view of EAI.
Agreed.

SHOULD NOT in 5.3 should be promoted to MUST NOT for specific features 
as suggested, simply to ensure security.  It is wrong to describe 
acceptance of messages having multiple From header fields, especially 
when this creates a significant security exposure.  DKIM does not 
specify how users know a message's status.  Users might use something as 
simple as the sorting of messages based upon the From address, where 
they know acceptance criteria for specific domains ensures a valid DKIM 
signature.  They might assume there is only a single From header in a 
message having a valid DKIM signature.

EAI has also made enough progress to deserve closer review as well.

-Doug

---

From: John Levine <[email-masked]>
Date: 26 Feb 2011 15:27:03 -0000

>listed for readers' convenience.

I'm pretty sure we already had this argument, and SHOULD NOT was the
rough consensus.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Sun, 27 Feb 2011 13:42:13 -0500

> I'm pretty sure we already had this argument, and SHOULD NOT was the

The chairs are pretty sure that's correct.

Barry, as chair

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 28 Feb 2011 14:12:14 -0000

> I'm pretty sure we already had this argument, and SHOULD NOT was the

It may or may not be the consensus, but it does not solve the problem.

Essentially, the simpler you make the check required to be done, the more  
easily you can make it a MUST. The minimum check to solve the problem is  
to say that, for all the headers mentioned in the 'h=' tag and which are  
supposed to occur only once, verifiers MUST check that they occur only  
once (pointing to RFC 532 et al for an explanation of the rule).

-- 
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