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

John C Klensin <john-ietf@jck.com> Fri, 05 March 2010 14:49 UTC

Return-Path: <john-ietf@jck.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 CD62228C116 for <yam@core3.amsl.com>; Fri, 5 Mar 2010 06:49:47 -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 wEramIgLm1Di for <yam@core3.amsl.com>; Fri, 5 Mar 2010 06:49:47 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id EB3AA3A8CAB for <yam@ietf.org>; Fri, 5 Mar 2010 06:49:36 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com 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 <john-ietf@jck.com>
To: Ned Freed <ned.freed@mrochek.com>, Barry Leiba <barryleiba.mailing.lists@gmail.com>
Message-ID: <3DA3CA9EA920107C75BB0B11@[10.3.0.41]>
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: 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:49:47 -0000

(sorry - seriously fat fingers on posting addresses today)

+1

I completely agree with Ned's analysis and conclusion
    john

--On Friday, 05 March, 2010 06:24 -0800 Ned Freed
<ned.freed@mrochek.com> 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
> yam@ietf.org
> https://www.ietf.org/mailman/listinfo/yam