[ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // Attacks Involving Additional Header Fields

[Rolf E. Sonneveld]

On 4/26/11 8:20 PM, Barry Leiba wrote:
> I will repeat that this issue was discussed at length, and
> working-group rough consensus was reached.  None of the recent
> discussion brings up any new points that merit re-opening it, nor is
> there sufficient support for re-opening it to cause me to think that
> we need to reconsider the consensus.
>
> Therefore, discussion of the multiple-header-field issue is closed;
> please do not bring it up again.
>
> Exception: I am aware that Charles and Doug want the issue re-opened.
> Anyone else who wants to see it re-opened and discussed again may post
> a message to this thread that says "Consensus needs to be
> re-evaluated."  I will reconsider this if there's a demonstration of
> real support for me to do so.

Consensus needs to be re-evaluated. Two reasons:

   1. as Doug pointed out: the basis DKIM spec needs to be such, that
      any technologies, that will use DKIM core as its basis (ADSP, ATP,
      reputation, authorization to use a mailing list, etc. etc.) must
      be able to rely on a single outcome of the DKIM verification
      process. As par. 5.1 of 4871bis provides a wealth of examples why
      there can be multiple signatures and par. 5.2 provides the
      recommendation (SHOULD) to '...continue to check signatures until
      a signature successfully verifies to the satisfaction of the
      verifier', it seems to me that bad guys adding a set of header
      fields (like From, Subject) can create a 2nd, 3rd, ..., n-th)
      signature (using their own d=) that may verify successfully 'to
      the satisfaction of the verifier'. Furthermore, as par. 7.2 does
      not define the exact information that is to be communicated to
      other parts of the mail system, it is possible that a 'verified
      successfully' outcome is communicated to downstream mail agents,
      without information about d=. And with 'downstream agents' I do
      not mean only UA's, I mean ANY agent consuming the verification
      result as determined by the verifier.
   2. in addition to the above, I fail to see why
      - on one hand 4871bis goes to great lengths regarding security
      related aspects ('sha-256 is strongly encouraged' and 'signers
      MUST use RSA keys of at least 1024 bits'),
      - while on the other hand not enforcing the 'multiple header'
      check. In my view 4871bis must either assign a PERMFAIL
      verification outcome for messages that fit the description of par.
      9.14 and 9.15, or it should use a MUST for the h=From:From:To:To:
      construct.


Granted, under normal circumstances I hate layering violations, but in 
my view this duplicate header check is essential for DKIM to be useful. 
Compare it to the Jericho security model: in these days of 
virtualization, DHCP etc. etc., a company can no longer simply rely on 
the IP firewall rules, each system has to become a self containing 
security ecosystem, which can easily be moved from one location to 
another. Likewise DKIM can not simply rely on MTAs/UAs properly 
implementing RFC5322, for a few essential things in RFC5322 DKIM has to 
doublecheck.

/rolf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20110427/0fda0eb1/attachment.html