Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
+1 from me as well. Arvel Tony Hansen wrote: > +1 > > Eric Allman wrote: >> Folks OK with that? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other"originator" headers?
+1 Damon Sauer On 7/14/06, Hector Santos <[EMAIL PROTECTED]> wrote: - Original Message -From: "Eric Allman" < [EMAIL PROTECTED]>To: "Mark Delany" <[EMAIL PROTECTED]>> 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+1. The key is if we manage situations that are created by relaxed provisions ofthe 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.--Hector Santos, Santronics Software, Inc.http://www.santronics.com___ NOTE WELL: This list operates according tohttp://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other"originator" headers?
- Original Message - From: "Eric Allman" <[EMAIL PROTECTED]> To: "Mark Delany" <[EMAIL PROTECTED]> > 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 +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. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
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 + Mark Delany <[EMAIL PROTECTED]> wrote: Eric Allman wrote: > 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. ___ 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
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
On Friday 14 July 2006 01:51, Mark Delany wrote: > > Eric Allman wrote: > > > 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. > > >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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
> Eric Allman wrote: > > 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
+1 Eric Allman wrote: > Folks OK with that? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
On Jul 13, 2006, at 11:40 PM, Scott Kitterman wrote: On Thursday 13 July 2006 23:19, Dave Crocker wrote: Eric Allman wrote: Folks OK with that? +1 d/ +1 +1 -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
On Thursday 13 July 2006 23:19, Dave Crocker wrote: > Eric Allman wrote: > > Folks OK with that? > > +1 > > d/ +1 Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
Eric Allman wrote: > Folks OK with that? +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
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? +1 Ned ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
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 Jim Fenton wrote: > 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. >> >> 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? > > 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 > ___ > 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
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
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. > > 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? 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
-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 PROTECTED]> To: "IETF DKIM WG" 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
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
> 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
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
On Thu, Jul 13, 2006 at 04:00:18PM -0400, Eric Allman allegedly 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. > > 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. +1 Mechanism vs policy is a good argument. As you say, let the receiver apply their policy as they see fit. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
On Jul 13, 2006, at 4:00 PM, 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. 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? I agree with making this change. These are considerations better handled elsewhere. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
