Re: [ietf-dkim] Re: "I sign everything" yes/no
Jim Fenton <fenton@cisco.com> Sat, 25 November 2006 06:28 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnr1B-0002jZ-2g for ietf-dkim-archive@lists.ietf.org; Sat, 25 Nov 2006 01:28:05 -0500
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gnr19-00046r-Il for ietf-dkim-archive@lists.ietf.org; Sat, 25 Nov 2006 01:28:05 -0500
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kAP6PpAL003407; Fri, 24 Nov 2006 22:25:52 -0800
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kAP6Pj2n003385 for <ietf-dkim@mipassoc.org>; Fri, 24 Nov 2006 22:25:45 -0800
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2006 22:25:31 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAP6PVAS012724; Fri, 24 Nov 2006 22:25:31 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAP6PUin009750; Fri, 24 Nov 2006 22:25:31 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 22:25:30 -0800
Received: from [10.32.251.5] ([10.32.251.5]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 22:25:30 -0800
Message-ID: <4567E1D7.6050002@cisco.com>
Date: Fri, 24 Nov 2006 22:25:27 -0800
From: Jim Fenton <fenton@cisco.com>
User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025)
MIME-Version: 1.0
To: Charles Lindsey <chl@clerew.man.ac.uk>
Subject: Re: [ietf-dkim] Re: "I sign everything" yes/no
References: <198A730C2044DE4A96749D13E167AD37E7E714@MOU1WNEXMB04.vcorp.ad.vrsn.com> <91A3FD7B-8B4A-4F78-9C5F-9BC66F86614D@mail-abuse.org> <4563C8D8.40909@santronics.com> <45647C86.36F3@xyzzy.claranet.de> <45648A1A.9030302@santronics.com> <op.tjg51tkv6hl8nm@clerew.man.ac.uk>
In-Reply-To: <op.tjg51tkv6hl8nm@clerew.man.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Nov 2006 06:25:30.0424 (UTC) FILETIME=[8135DB80:01C7105A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2842; t=1164435931; x=1165299931; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:=20Jim=20Fenton=20<fenton@cisco.com> |Subject:=20Re=3A=20[ietf-dkim]=20Re=3A=20=22I=20sign=20everything=22=20y es/no |Sender:=20; bh=EoPrWtMiU7bKiMhw/OY8VFN4s6C7gFxK9m6yhsjN3Cs=; b=q+CURE+fR/AIegcPKCqIohjZZacUZqNTTkKTbbEUgKMJCvCZoXTesYwKYDyyC3nxdiyMTQkv I54SwsbNwbXmmC2/NpU8njEj/GolDUKdcbNrNYWgEHed4UxAvj+DNjUl;
Authentication-Results: sj-dkim-1; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; );
X-Songbird: Clean, Clean
Cc: DKIM <ietf-dkim@mipassoc.org>
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Charles Lindsey wrote: > > On the contrary, it is the Sender header if present that should be the > decider, and only the From if Sender is absent. People keep ignoring > the fact that there can be several addresses in a From header (in > which case Sender is obligatory). It's not entirely forgotten; section 2.3 of draft-allman-dkim-ssp-02 discusses multiple From addresses. We thought about resolving the ambiguity by (1) arbitrarily picking the first address in the From header field, (2) picking the address in the Sender header field, or (3) querying SSP for all addresses in the From header field, and combining them somehow. We picked (1), because we don't know whether the MUA is going to display the Sender address or not, and we felt that it is likely that it will display the first From address regardless. But we don't know how this will be displayed, and who the recipient is likely to consider the author of the message, so it's very difficult to decide the right thing to do. It's currently a very rare circumstance, so our main priority here is to minimize the possibility that it becomes common by virtue of becoming an SSP exploit, which we (the authors, not the WG) felt favored (1). > > On top of that, the message might also be Resent, as Frank has pointed > out. Hopefully, the resender will have preserved the Signature put > there on behalf of the original Sender. If the Resender also "signs > everything", then an extra signature should be picked up there. There is a lot of question in my mind whether the fact that the resender signs everything is relevant to the verifier. Since the Resent-From header field is not very visible to recipients in my experience, an attacker is just likely to pick a Resent-From domain that doesn't make any SSP assertions. > > BTW, the bit in the base document that says the "From" MUST always be > signed is wrong. It should have been the Sender, and maybe any > Resent-From too. And that MUST is going to haunt us again when EAI > happens, because both From and Sender may well get changed in transit. > Not clear how EAI is going to get around that, but that obligatory > From signing is not going to make that job any easier. The language here was discussed and determined by WG consensus. Personally, I favored the language in -base-03 and earlier that says, "any header field that describes the role of the signer (for example, the Sender or Resent-From header field if the signature is on behalf of the corresponding address and that address is different from the From address) MUST also be included." But that was not the WG consensus; instead, it was decided that this was an aspect of how the signature is used and interpreted rather than the validity of the signature itself. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
- [ietf-dkim] "I sign everything" yes/no J.D. Falk
- Re: [ietf-dkim] "I sign everything" yes/no Stephen Farrell
- Re: [ietf-dkim] "I sign everything" yes/no Dave Crocker
- Re: [ietf-dkim] "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] "I sign everything" yes/no Douglas Otis
- Re: [ietf-dkim] "I sign everything" yes/no Paul Hoffman
- RE: [ietf-dkim] "I sign everything" yes/no Hallam-Baker, Phillip
- Re: [ietf-dkim] "I sign everything" yes/no Douglas Otis
- Re: [ietf-dkim] "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] "I sign everything" yes/no Douglas Otis
- [ietf-dkim] Re: "I sign everything" yes/no Frank Ellermann
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- RE: [ietf-dkim] "I sign everything" yes/no Hallam-Baker, Phillip
- [ietf-dkim] ISSUE: Better definition of "DKIM sig… Frank Ellermann
- Re: [ietf-dkim] "I sign everything" yes/no Douglas Otis
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Stephen Farrell
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Charles Lindsey
- [ietf-dkim] Re: Role of Sender header as signing … Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Douglas Otis
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Douglas Otis
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Stephen Farrell
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- [ietf-dkim] Re: "I sign everything" yes/no Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Stephen Farrell
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- [ietf-dkim] OT: Return-Path considerations (was: … Frank Ellermann
- [ietf-dkim] EAI + SSP status (was: "I sign everyt… Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Stephen Farrell
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Stephen Farrell
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Stephen Farrell
- [ietf-dkim] Last calls for lemonade (was: ISSUE: … Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- [ietf-dkim] ISSUE: Is "sender" in 4.1 4th paragra… Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Stephen Farrell
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Stephen Farrell
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Eliot Lear
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Michael Thomas
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… william(at)elan.net
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… John Levine
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Jim Fenton
- Re: [ietf-dkim] Re: "I sign everything" yes/no Jim Fenton
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… william(at)elan.net
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Michael Thomas
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Eliot Lear
- Re: [ietf-dkim] Re: "I sign everything" yes/no Eliot Lear
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- RE: [ietf-dkim] Re: "I sign everything" yes/no Hallam-Baker, Phillip
- Re: [ietf-dkim] Re: news and lists again, was "I … John Levine
- Re: [ietf-dkim] Re: ISSUE: Better definition of"D… Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- [ietf-dkim] Resend-cruft (was: ISSUE: Better defi… Frank Ellermann
- Re: [ietf-dkim] Re: "I sign everything" yes/no Jim Fenton
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Stephen Farrell
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Stephen Farrell
- [ietf-dkim] Future uses of DKIM in Netnews (was: … Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Douglas Otis
- Re: [ietf-dkim] Future uses of DKIM in Netnews (w… Charles Lindsey
- [ietf-dkim] Role of Sender header as signing doma… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- Re: [ietf-dkim] Role of Sender header as signing … Scott Kitterman
- Re: [ietf-dkim] Re: "I sign everything" yes/no Eliot Lear
- Re: [ietf-dkim] Role of Sender header as signing … Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- [ietf-dkim] Re: Role of Sender header as signing … Frank Ellermann
- Re: [ietf-dkim] Role of Sender header as signing … John Levine
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- Re: [ietf-dkim] Role of Sender header as signing … Steve Atkins
- Re: [ietf-dkim] Re: "I sign everything" yes/no Michael Thomas
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Michael Thomas
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Damon
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- Re: [ietf-dkim] Role of Sender header as signing … Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- Re: [ietf-dkim] Re: Role of Sender header as sign… Michael Thomas
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Role of Sender header as signing … Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Eliot Lear
- Re: [ietf-dkim] Role of Sender header as signing … Hector Santos
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- Re: [ietf-dkim] Role of Sender header as signing … Stephen Farrell
- Re: [ietf-dkim] Re: Role of Sender header as sign… william(at)elan.net
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Damon
- Re: [ietf-dkim] Re: Role of Sender header as sign… Eliot Lear
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- RE: [ietf-dkim] Re: Role of Sender header as sign… Bill.Oxley
- Re: [ietf-dkim] Re: Role of Sender header as sign… Michael Thomas
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Wietse Venema
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- Re: [ietf-dkim] Re: Role of Sender header as sign… Hector Santos
- RE: [ietf-dkim] Re: Role of Sender header as sign… Bill.Oxley
- Re: [ietf-dkim] Re: Role of Sender header as sign… John Glube
- Re: [ietf-dkim] Re: Role of Sender header as sign… Hector Santos
- Re: [ietf-dkim] Re: Role of Sender header as sign… John Glube
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Hector Santos
- Re: [ietf-dkim] Re: Role of Sender header as sign… Damon
- Re: [ietf-dkim] Re: Role of Sender header as sign… Stephen Farrell
- Re: [ietf-dkim] Re: Role of Sender header as sign… Steve Atkins
- [ietf-dkim] receiver role in ssp Bill.Oxley
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Damon
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis