Skip to main content

Appeal of decision to advance RFC6376 (Douglas Otis; 2013-05-30) - 2013-05-30
Appeal - 2013-05-30

Dear IESG,

We are obligated to act on behalf of our customers and others to Appeal
IESG's decision to advance RFC6376 (DKIM) to an Internet Standard.

DKIM MUST NOT convey a valid signature status for messages that include
deceptive header fields!

The initially stated intent of DKIM was to allow deployment without
email otherwise being modified. The message fragment ensured by DKIM is
the From header field along with other optional message fragments, but
signature validation fails to ensure messages containing this header
field do not contain other deceptive header fields. DKIM's signing and
verification process must scan all header fields and process them bottom
to top, although likely selected for display from the top. Detecting
invalid repeated header fields within the message is trivial and
available as an option in open implementations.

Somehow evidence outlined in the addendum of draft-otis-dkim-harmful
illustrating the outlined vulnerability was ignored and the harmfully
deceptive messages were even purported to not even exist! Ongoing work
is even attempting to repair this vulnerability as illustrated in draft-
kucherawy-dmarc-base which requires header fields to be re-examined. It
should also be noted DMARC's repair can not be generally applied, such
as when the domain sends messages to mailing-lists. The SMTP transport
specifically DOES NOT check message format validity as a strategy
ensuring store-and-forward email processing is not problematic. No other
protocol layer can make this check. Since it is important for DKIM in
retaining the trust it attempts to convey, DKIM MUST make this check. It
is also painfully apparent a majority of email providers do not make
this check either.

DKIM's oversight of this extremely important detail is placing
recipients at risk, which in itself represents real harm. In brief time
between version 0 and 1 of the dkim harmful draft, abuse grew by a
factor of 10. The alluded "other" uses likely involve use of reputation,
but due to permitted deceptions, DKIM MUST NOT be used in conjunction
with reputation in its current form.

DKIM MUST NOT convey a valid signature status for messages that include
deceptive header fields!

Regards,
Douglas Otis