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

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2006 16:00:18 -0400

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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 Jul 2006 16:09:19 -0400

On Jul 13, 2006, at 4:00 PM, Eric Allman wrote:

> 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.
>
> (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?

I agree with making this change.  These are considerations better  
handled elsewhere.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Thu, 13 Jul 2006 20:21:43 +0000

> this through in just a couple of hours.

+1 Mechanism vs policy is a good argument. As you say, let the
   receiver apply their policy as they see fit.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jul 2006 16:30:55 -0400

> 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.
...
>   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?

+1

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 13 Jul 2006 17:11:39 -0400

-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" <[email-masked]>
To: "IETF DKIM WG" <[email-masked]>
Sent: Thursday, July 13, 2006 4:00 PM
Subject: [ietf-dkim] drop requirement to sign "From" or other "originator"
headers?

---

From: Barry Leiba <[email-masked]>
Date: Thu, 13 Jul 2006 17:15:32 -0400

Oops... I didn't get to this yet when I made my last post, so I'm sorry 
for adding another subject line for the same thread.  I hope people have 
the sense to ignore me, and to post here.  :-)

Barry

---

From: Jim Fenton <[email-masked]>
Date: Thu, 13 Jul 2006 14:50:44 -0700

Eric Allman wrote:
> 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.
>
> we've been making, which is why I have some small hope we can get this
> through in just a couple of hours.
>
> Thoughts?

If we do this, there needs to be some strongly-worded but non-normative
guidance that reminds people that if they want their signature to be
useful, there are some header fields they really ought to sign,
including From, Subject, Date, and probably Sender (the latter on
account of Outlook clients).  Otherwise, the signature really doesn't
mean much, and if the verifier does something like remove unsigned
header fields, the recipient is going to see a lot of blanks.

In other words, it doesn't need to be a normative MUST because not
signing From doesn't break the protocol.  Whether it's a normative
SHOULD, a should (note lower case) or a non-normative note I'm not sure.

-Jim

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Jul 2006 18:15:07 -0400

I have a problem with dropping mention of the originator headers. I can
live with them moving to SHOULD be signed in place of MUST be signed.

	Tony

---

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2006 18:14:49 -0400

In listening to the responses and looking over the text, I see 
general agreement, except for Hector --- but only from a very small 
set of people.  Also, saying everything is optional creates an 
interesting glitch in the text: currently at least one header field 
must be included, and changing h= so it can be empty will require 
more thought.

So, for -04 I change my proposal to go back to the wording that says 
that From MUST be signed (since, as Hector points out, From is 
required, we don't have to worry about what to do if it is missing). 
We also said in -03 that "any header field that describes the role of 
the signer" MUST be signed; I'm inclined to leave that out of -04. 
There will informative commentary about what a signer probably wants 
to do.

Folks OK with that?

eric

---

From: [email-masked]
Date: Thu, 13 Jul 2006 20:13:36 -0700 (PDT)

+1

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jul 2006 23:19:45 -0400

+1

d/
-- 

  Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 13 Jul 2006 23:40:20 -0400

+1

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Fri, 14 Jul 2006 00:08:56 -0400

+1

-Doug

---

From: Mark Delany <[email-masked]>
Date: Fri, 14 Jul 2006 05:51:55 +0000

> > Folks OK with that?

-1

If a verifier has a verified email with a d= what is the fundamental
value-add on insisting that From: is a signed header? After all, a
minimalist verifier is going to query some database to ask the
question: Do I like d=?

Will that query be influenced by a From: header? I'd think not. A
minimalist verifier could care less. All they want to know is, who is
the responsible domain and how much do I like them?

It still seems to me that enforcing a From: is a vestigial attempt to
protect MUAs. But I thought we had decided that we weren't in the
business of solving that problem? Is that true?

If we are truly out of the business of protecting MUAs, then I see no
rationale for enforcing From: signing.

If we are in the business of protecting MUAs then we need to re-visit
that whole can of worms around Sender: and Resent: and all those other
potential MUA originators and triggers.

Mark.

---

From: Tony Hansen <[email-masked]>
Date: Fri, 14 Jul 2006 00:38:55 -0400

+1

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 14 Jul 2006 02:27:41 -0400

On Friday 14 July 2006 01:51, Mark Delany wrote:
>From my perspective we should be, at a minimum signing 'the message'.  Since 
>From required by both RFCs 822 and 2822, then without including it, what is 
signed isn't a valid e-mail message.

I think it's more, at this level, a question of protecting the message from 
in-transit modification than protecting the MUA.  So, put another way, I 
think you need to sign From for the same reason you sign the body of the 
message.

Scott K

---

From: Eric Allman <[email-masked]>
Date: Fri, 14 Jul 2006 05:07:07 -0400

Mark,

Frankly, my main reason for doing it this way right now is that 
saying you don't have to sign anything puts us in the weird position 
that the spec then says you have to sign /some header/ but doesn't 
mandate any, and that seems to be a source of latent problems.  I 
don't have any serious objection to removing From, but at the same 
time in order for it to make sense we should make an empty h= list a 
possibility.  That's a big enough change that I think we should think 
it through more carefully.

As for whether we protect MUAs, my answer is no, but maybe yes.  That 
is, protecting MUAs isn't DKIM's primary intent, but the verifier 
might want to use information conveyed by DKIM to in some way protect 
the MUA --- or more precisely, the MUA might want to use the DKIM 
information to protect the end user.  But that doesn't make it a 
MUST, just a good idea.

So, keeping From: in is just a matter of yielding to pragmatics, 
specifically in avoiding an edge condition that I think we should 
think through a bit more.  I'm happy to change it in -05 if we decide 
we can manage the situation.

eric

--On July 14, 2006 5:51:55 AM +0000 Mark Delany 
<[email-masked]> wrote:

> minimalist verifier could care less. All they want to know is, who
> is the responsible domain and how much do I like them?
>
> It still seems to me that enforcing a From: is a vestigial attempt
> to protect MUAs. But I thought we had decided that we weren't in the
> If we are truly out of the business of protecting MUAs, then I see
> no rationale for enforcing From: signing.
>
> If we are in the business of protecting MUAs then we need to
> re-visit that whole can of worms around Sender: and Resent: and all
> those other potential MUA originators and triggers.
>
>
> Mark.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 14 Jul 2006 06:50:47 -0400

----- Original Message -----
From: "Eric Allman" <[email-masked]>
To: "Mark Delany" <[email-masked]>

> we can manage the situation.

+1.

The key is if we manage situations that are created by relaxed provisions of
the protocol, only then should you allow relaxed designs.

IMV, we only need to point to SMTP with all its uncontrollable relaxed
provisions that help get us here in the first place.

---

From: Damon <[email-masked]>
Date: Fri, 14 Jul 2006 08:43:15 -0400

+1

Damon Sauer

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 14 Jul 2006 13:47:40 -0600

+1 from me as well.

Arvel