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

(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