ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?

2006-07-13 14:22:12
-1.

In my view any DKIM entity on both sides of the coin, must be consistent in
all expectations.  Verifiers shouldn't be able to do what they please and
you ready dictating policy by the mere suggestion one is not required.

Since the signer already drives the verification process, there is already a
policy in place.  Suggesting the verifier can do what it please, is yet
another ambiguous policy.

IMV, there should be a minimum requirement that has nothing to with
"subjective policies" but part of the fundamental mechanism of the x821/x822
EMAIL process and that includes having such fields as a FROM: (for DKIM
signing).

I suggest that we become consistent with the 20+ year infrastructure where
there is a minimum requirement for headers, and expectations for all parts
of the framework, including display systems.

With RFC 822/821, we have a requirement of FROM: TO: and DATE:

With RFC 2822/2821, it was relaxed to just FROM: and DATE:

I don't see this as a "policy" but just part of the fitting the equation.

Just consider when you don't require atleast the FROM:.  This means we can
have systems creating non-originating (3rd party) DKIM messages with any
FROM address.

Of course, I already felt that signature authorization should be a natural
part of the DKIM protocol since it will help maintain the expectation of the
so called "responsible" signer.  Without signature authorization, dropping
the FROM: hashing is highly vulnerable to exploitation.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



----- Original Message -----
From: "Eric Allman" <eric+dkim(_at_)sendmail(_dot_)org>
To: "IETF DKIM WG" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Thursday, July 13, 2006 4:00 PM
Subject: [ietf-dkim] drop requirement to sign "From" or other "originator"
headers?


I've heard some discussion the last couple of days that we should
drop the MUST for signing originator headers and Resent-* blocks,
since this isn't an interoperability issue (but is perhaps a
usefulness issue).  This is, in some sense, dictating policy instead
of being confined to mechanism, which we've been assiduously
avoiding.  Viewed that way, it seems inappropriate to have this
requirement.

Of course, a verifier would be completely within reason to ignore
signatures that didn't sign the From header, but that's up to them.

If we can get a very quick consensus I can get this into base-04
(which is going to be submitted today come hell or high water --- oh
wait, that was Dallas).  It seems consistent with the other changes
we've been making, which is why I have some small hope we can get
this through in just a couple of hours.

Thoughts?

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



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