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
