[ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

[Murray S. Kucherawy]

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Barry Leiba
> Sent: Tuesday, October 12, 2010 8:48 AM
> To: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
> 
> Hector says...
> > If DKIM designers knew there were many email implementations with less
> > than strict enforcement and strictness was an requirement, then DKIM
> > started with a problem it ignored to address.  Either it was ignorant
> > or poor engineering.
> 
> That's not true at all.  It's common and reasonable for newer
> protocols to tighten things up and require stricter adherence to the
> older protocols.  New features often make it unwise or incorrect to
> treat earlier requirements loosely.  This is one of those cases, and
> in earlier versions of DKIM work there was certainly wording about
> requiring valid RFC 2822 (at the time) messages.

Indeed, the advancement from PS to DS is the perfect time to tighten up requirements.  It's not any kind of re-engineering.

> > 2) There is no intent.
> 
> There is, quite often.  It's very often the case that things on the
> receiving side tolerate malformed messages *specifically* to avoid
> rejecting more messages than necessary.  "With the intent of providing
> a better user experience," is absolutely correct in a great many
> cases.  And we're telling verifiers that when you add DKIM, that
> tolerance might now be unwise.

Concur here as well.  "Be liberal in what you accept, be strict in what you send" has some very clear intent behind it.

> > 3) Philosophical conflictive parenthetical sentence:
> >
> >   (This can also be taken as a  demonstration that DKIM is not designed
> >    to support author validation.)
> 
> Yeh, that's the only part I agree on (though not with the reasoning
> that follows).  I'm ambivalent about having that parenthetical
> statement in there.  I'd like to see some consensus about whether to
> leave it or keep it.

Also +0.

> > Here is my reworded text. I would not give the "How to Exploit." Let
> > the bad guy figure it out.  No blaming anyone.
> 
> -1; I like the wording that's there.

Concur; -1 on the change.  I furthermore submit that we are compelled to describe the known "attack", as that's precisely what we are supposed to include in Security Considerations.

-MSK