ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] 8bit downgrades

2011-05-19 18:55:35
Pete Resnick wrote:
On 5/19/11 12:50 PM, Murray S. Kucherawy wrote:

Can anyone remember why there's a SHOULD for the downgrade to 7-bit in 
RFC4871 Section 5.3, rather than a MUST?  The likelihood of breakage 
is so high when sending 8-bit data that DKIM almost becomes pointless 
without the upgrade.


Not advocating for this to be changed in --bis (yet), but someone's 
asking me for the history behind that decision.


I can't speak directly to the history of why the WG *thought* they were 
putting in the SHOULD, but Michael, Wietse, Scott, and Hector seemed to 
have missed the point of why the SHOULD is absolutely appropriate:

In RFC 2119 (the document that defines MUST, SHOULD, etc.), "MUST" does 
not mean "vitally important" and "SHOULD" does not mean "really really 
important, but less important than MUST". "MUST" means "you have to do 
this or you're not going to interoperate." "SHOULD" means, "there are 
ways to not do this which will still interoperate, but you had better 
know what those ways are and you better be sure to do them, and if you 
don't, then you MUST NOT do this." That is, "SHOULD" is equivalent to 
"MUST unless you know exactly what you are doing."

In this case, the spec says that you MUST downgrade prior to signing 
*unless you know that the end-to-end path is 8-bit clean and will not 
downgrade later*. That's what SHOULD downgrade means. If there is an 
implementation that doesn't downgrade and sends a message without 
knowing that the path is end-to-end 8-bit clean, then it is in violation 
of the spec. Changing it to MUST doesn't change anything for such an 
implementation; it is already in full violation.

pr


Pete, it isn't that complicated:

MUST is a "throw in your face" requirement - don't follow, expect 
things to break and not match up with your peers - shame on you - a bug.

SHOULD is an optional requirement - Its a recommendation for the 
better, but things will not break things for your peers if you don't 
follow it.  You may be shamed but the person shaming you is the one 
wrong if they depended on a SHOULD operation as a MUST and his 
software broke.

SHOULD is appropriate here IMV because it approves things (for DKIM), 
but it can't be enforced for common sense historical reasons. 
Primarily, it can't enforce change.  Going to 8-bit MIME was an 
expensive and complex endeavor and now asking people they should 
downgrade and worst, tamper with passthru mail is hard to swallow.

In fact, I may even support a change to a MAY, simple because there is 
a natural expectation for non-tampering passthru mail and more and 
more systems are using 8 bit communications.

The problem isn't 8bit, the problem is DKIM and this topic is yet 
another example of the many WG contradictions.  Before we attempt to 
force change for the sake of DKIM verification, it might be a good 
idea to renew our focus on the serious repercussions for the already 
existing relaxations and marginally errors we have accepted for DKIM 
verification failures

If we change this downgrade to a MUST, then we must also fix the C14N 
problem we forgot about the extra <CRLF> possible at the top the 
message possible in IETF streams like IETF-SMTP.   Can't have it both 
ways: its important here, but not there.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>