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

John C Klensin <> Fri, 05 March 2010 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD62228C116 for <>; Fri, 5 Mar 2010 06:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wEramIgLm1Di for <>; Fri, 5 Mar 2010 06:49:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EB3AA3A8CAB for <>; Fri, 5 Mar 2010 06:49:36 -0800 (PST)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1NnYqP-000P8h-Au; Fri, 05 Mar 2010 09:49:37 -0500
Date: Fri, 05 Mar 2010 09:49:35 -0500
From: John C Klensin <>
To: Ned Freed <>, Barry Leiba <>
Message-ID: <3DA3CA9EA920107C75BB0B11@[]>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc:, Alessandro Vesely <>
Subject: Re: [yam] [secdir] secdir review of draft-ietf-yam-rfc1652bis-03
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Mar 2010 14:49:47 -0000

(sorry - seriously fat fingers on posting addresses today)


I completely agree with Ned's analysis and conclusion

--On Friday, 05 March, 2010 06:24 -0800 Ned Freed
<> wrote:

>> >> 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
> _______________________________________________
> yam mailing list