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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html