On 4/27/11 2:21 AM, SM wrote:
Hi Doug, At 18:43 26-04-2011, Douglas Otis wrote:
Not validating input creates a bigger mess when used in conjunction
with RFC5336bis. As such, it seems unfair for the DKIM WG
operating within the Security area to close and then hand a mess
over to the Applications area EAI WG.
I thought that the advancement of the specifications from Proposed to
Draft would not be too much of an effort as there are existing
implementations of RFC 4871. But then, this is the DKIM WG.
DKIM represents a security measure intended to have minimal impact on
existing email infrastructure. When moving to draft collides with
repairing deficiencies found, whether due to DKIM errors, unanticipated
encoding changes, or unexpected deficiencies with dependent protocols,
then this move is clearly premature. The substantially greater
resources expended to support DKIM overwhelmingly justify minor
adjustments necessary to better restore security. Whether this might
mean incrementing singleton header counts, or detecting Fake A-Labels by
checking symmetry with existing libraries. IMHO, it would also improve
security by indicating these additional checks are in place. When doing
what is best is hindered by being associated with a "standard", then
something has gone wrong.
I don't see any issue between the Security Area and the Applications
Area. I don't recall DKIM being discussed in the EAI WG. I read
draft-ietf-dkim-rfc4871bis during the last WGLC in October 2010 and
commented on the draft (
http://mipassoc.org/pipermail/ietf-dkim/2010q4/014696.html ).
DKIM is briefly discussed in the Framework document where it indicates
DKIM is an open issue for both groups where changes ARE needed.
IDNA and EAI are not the same. You are going to break stuff if you
want to DKIM support for RFC5336bis. It's up to the DKIM WG to see
whether it wants to do that or not.
DKIM would be deficient blaming deceptive output on name or transport
services. DKIM binds elements of the message with a recognizable domain
contained within the DKIM-Signature "d=" parameter. When recipients are
expected to compare the output of a Punycode algorithm against the UTF-8
IDNs, then clearly DKIM will have failed. When DKIM does not ensure
resources are only obtained from DNS using NR-LDH or Valid A-Labels,
then clearly DKIM will have failed. When the only header field required
to be signed is not guarded against deceptive pre-pended header fields
(by incrementing the signed header count), then clearly DKIM has failed.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html