Re: [yam] [secdir] secdir review of draft-ietf-yam-rfc1652bis-03

Ned Freed <ned.freed@mrochek.com> Fri, 05 March 2010 14:38 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037723A8CFE for <yam@core3.amsl.com>; Fri, 5 Mar 2010 06:38:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Org0xD60Clh for <yam@core3.amsl.com>; Fri, 5 Mar 2010 06:38:12 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 28FC93A8CCA for <yam@ietf.org>; Fri, 5 Mar 2010 06:38:12 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NKDPP3WC2800CGMV@mauve.mrochek.com> for yam@ietf.org; Fri, 5 Mar 2010 06:38:09 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NKBJE4B34000EMS2@mauve.mrochek.com>; Fri, 05 Mar 2010 06:38:06 -0800 (PST)
Message-id: <01NKDPP1YMZG00EMS2@mauve.mrochek.com>
Date: Fri, 05 Mar 2010 06:24:31 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 05 Mar 2010 09:15:31 -0500" <6c9fcc2a1003050615p651de616if1fa35e8d5569d40@mail.gmail.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4B8E515A.6060608@isode.com> <6.2.5.6.2.20100303103218.0ba092a0@resistor.net> <4B90ED1C.8040905@tana.it> <01NKDOIR3JA200EMS2@mauve.mrochek.com> <6c9fcc2a1003050615p651de616if1fa35e8d5569d40@mail.gmail.com>
To: Barry Leiba <barryleiba.mailing.lists@gmail.com>
Cc: Ned Freed <ned.freed@mrochek.com>, yam@ietf.org, Alessandro Vesely <vesely@tana.it>
Subject: Re: [yam] [secdir] secdir review of draft-ietf-yam-rfc1652bis-03
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Mar 2010 14:38:13 -0000

> >> RFC 4871 is of 2007 and reports an issue with it. Section 5.3
> >> practically says that 8bit SHOULD NOT be used.
> >
> > It's hardly the 8bitMIME extension's fault that DKIM is misdesigned - It
> > isn't at all difficult to define a signature mechanism capable of surviving
> > encoding changes. The DKIM group simply chose not to do it, making a
> > design tradeoff that severely limits DKIM's applicability.

> Don't confuse what's sent on the wire with what's done in the
> canonicalization.  DKIM doesn't prevent sending 8bitMIME...

Nobody said it did. But DKIM signatures break when downgrading or upgrading of
encodings is performed, so the recommendation in the DKIM specification is that
only 7bit should be used, making 8bitMIME unnecessary.

I happen to think this is going to prove to be a poor design choice in the long
run, but that's not relevant to the present discussion. The question at hand is
whether or not this deserves any sort of mention in the 8bitMIME specification.
I believe it does not. Again, tHe bottom line is that DKIM WG opted for
canonical form simplicity over a canonical form that's robust in the face of
encoding changes. It was their engineering choice to make and they made it. But
having made it, it is also their choice to document, justify, and defend.

We simply cannot go around trying to update every specification we have to make
each one forward-aware of all subsequent specifications that touch on that
application space. It's madness to even try.

> it just
> says that it had better be canonicalized with RFC 2047 encoding when
> you make (and verify) the signature.

Er, no, that's not what it says at all. From Section 5.2:

   Some messages, particularly those using 8-bit characters, are subject
   to modification during transit, notably conversion to 7-bit form.
   Such conversions will break DKIM signatures.  In order to minimize
   the chances of such breakage, signers SHOULD convert the message to a
   suitable MIME content transfer encoding such as quoted-printable or
   base64 as described in MIME Part One [RFC2045] before signing.  Such
   conversion is outside the scope of DKIM; the actual message SHOULD be
   converted to 7-bit MIME by an MUA or MSA prior to presentation to the
   DKIM algorithm.

This has nothing to do with RFC 2047 encoded words and everyything to do with
the recommended non-use of 8bitMIME.

				Ned