From owner-ietf-mailsig Mon Aug 2 11:13:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72ID7VI076483 for ; Mon, 2 Aug 2004 11:13:07 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72ID7Et076482 for ietf-mailsig-skb; Mon, 2 Aug 2004 11:13:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72ID741076468 for ; Mon, 2 Aug 2004 11:13:07 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Aug 2004 11:15:12 +0000 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i72ICvYp014223 for ; Mon, 2 Aug 2004 11:13:02 -0700 (PDT) Received: from fenton-w2k01.cisco.com (sjc-vpn5-349.cisco.com [10.21.89.93]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i72IgakZ011062 for ; Mon, 2 Aug 2004 11:42:39 -0700 Message-Id: <4.3.2.7.2.20040802111011.03b11790@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Aug 2004 11:13:42 -0700 To: ietf-mailsig@imc.org From: Jim Fenton Subject: Draft working group charter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-IMAIL-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1091472159.686870"; x:"432000"; a:"rsa-sha1"; b:"0:4060"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"ug2SryPW9XRXtz/DpX5D5kONvtQtwSvYRbelfLyGiNvNxY4rtqPuV7lQ5OfgC" "c4oaphQhVTQMFZZE3XuhRC2De7ifvK6fAaJjevO9TajDqLSz4e+8ffrnFdcUz" "P+o/S8kUGCYCdeVIY0wzE7Z8uPpTZS75MmHm6V4m1Z+JmO6Ys="; c:"Date: Mon, 02 Aug 2004 11:13:42 -0700"; c:"From: Jim Fenton "; c:"Subject: Draft working group charter" X-IMAIL-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com" Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Welcome to the ietf-mailsig mailing list. Below is the draft working group charter we will be discussing at Thursday's MASS BoF at IETF-60. -Jim ----- Working Group Name: STRIVERS (Signatures for Transport Recognition of Imposture in Viral Email and Repugnant Spam) IETF Area: SEC Working Group Chairs: Document Editors: (some subset of Jim Fenton, Mark Delany, Phill-Hallam Baker, Nathaniel Borenstein, George Webb, ???) Problem statement and WG Goals: One of the many promising approaches to beating back the tide of spam, and in particular to thwarting the insidious impersonation practice known as "phishing," is the widespread adoption of digital signatures on email messages. However, for over a decade the advocates of interpersonal digital signatures have struggled with issues of adoption and use, so that only a small portion of today's email messages are cryptographically authenticated in any way. Several proposals have recently been published for a simple and automatic mechanism by which outgoing messages may offer limited proof of potentially-verifiable identity. Although there are already more than a few mechanisms for attaching a digital signature to an email message, none meet the particular set of constraints that are ideal for spam fighting. The ideal signing mechanism for spam fighting would: -- Facilitate automated signing of outgoing messages by any SMTP-initiating entity. -- Minimize computational and transactional overhead for high-volume email servers. -- Permit a high degree of anonymity when desired by the sender. Several excellent proposals of this general nature have been published recently, including: DomainKeys, draft-delany-domainkeys-base-00.txt Identified Internet Mail, draft-fenton-identified-mail-00.txt E-mail Postmarks, http://www.lessspam.org/EmailPostmarks.pdf MTA Signatures, http://www.elan.net/~william/mta_signatures.htm Entity-to-Entity S/MIME, draft-hallambaker-entity-00.txt The importance of converging on a single standardized mechanism is difficult to overstate. This group will define such a mechanism. Deliverables and Milestones: The STRIVERS working group will design extensions to SMTP, RFC 2822, and MIME that will enable any SMTP-sending entity to: -- Convey the fact that a cryptographic signature is associated with the message being delivered -- Convey the identity and public key of the signing entity -- Identify the precise message contents being signed (notably which headers) -- Deliver the signature along with the message Additionally, it will define a possibly-optional mechanism by which an SMTP receiver may verify the public key of an SMTP sender. Finally, it will specify the appropriate best practices for SMTP senders when they encounter (legacy) SMTP receivers that do not support the STRIVERS mechanisms The following work items are explicitly ruled out of the scope of STRIVERS: -- Address-based authentication; STRIVERS is intended to complement MARID, and to be compatible with it if the two overlap or intersect in any way. -- Rating services for conveying reputational information about the signing entities Proposed Timeline: Jul 04 Establishment of mailing list, preliminary discussion Aug 04 BOF meeting at San Diego IETF. Selection of WG leaders & document editors Sep 04 Publish signature syntax proposals for discussion Sep 04 Publish protocol extension proposals for discussion Oct 04 Interim meeting. Identification of major open issues Nov 04 WG meeting at Washington IETF. Resolution of major open issues. Jan 05 Publish first drafts of "consensus" documents Feb 05 Publish more drafts of "consensus" documents Mar 05 Publish more drafts of "consensus" documents WG Last Call Mar 05 WG meeting at IETF conference. Publication of RFC as Proposed Standard. Mar 06 Publication of RFC as Draft Standard. Mar 07 Publication of RFC as Full Standard. From owner-ietf-mailsig Mon Aug 2 17:52:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i730q7F6008637 for ; Mon, 2 Aug 2004 17:52:07 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i730q7lx008636 for ietf-mailsig-skb; Mon, 2 Aug 2004 17:52:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i730q6mH008630 for ; Mon, 2 Aug 2004 17:52:06 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i730xkh7022112; Mon, 2 Aug 2004 17:59:46 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i730xk38022109; Mon, 2 Aug 2004 17:59:46 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 2 Aug 2004 17:59:46 -0700 (PDT) From: "william(at)elan.net" To: Jim Fenton cc: ietf-mailsig@imc.org Subject: Re: Draft working group charter In-Reply-To: <4.3.2.7.2.20040802111011.03b11790@mira-sjc5-1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have number of problems with draft charter... 1. First and main one is that we're not leaving any time in the beginning of the group to discuss set of requirements for the solution. We need to understand what is expected from the end-solution and what are minimum and desired features we want to have (different proposal authors seems to have different set of requirements and "signature signing" is just way too general, we need to ping point what signature signing requirements are). This will help both proposal authors in how the proposals are constructured and more importantly it'll help in evaluating those proposals. I remember CRISP which had multiple proposals for solutions and talk of requirements there was very important as well as creating matrix for evaluation. We should nor rush things so quickly completely fogetting about things like this. 2. I think charter mentions spam bit too many times. I don't know if ADs and IESG like to see this word in the charter, but I suspect it has potential to bring bunch of people who just want to discuss spam and will hurt our work. I suggest rewring things with focus on "email security" in automated way by mail servers as being main point rather then "spam prevention". 3. You're rushing with schedule in the beginning especially. See #1 really but I think choosing editors, should be done on next IETF meeting after requirements have been discussed and major ways to solve it are also clear. Then based on these major ways we can choose which and how proposals will be writted and then discuss which is better. 4. Without discussing requirements, we cant decide which headers should be signed (and I'm not certain we should be deciding it or should let this capability and provide recomendations only without MUST). 5. You mention way for SMTP receiver to verify public key of SMTP sender. I do not agree with putting it this way. This automaticly puts us into situation that proposals are for one-hope security which should not be our goal at all (and we already have TLS SMTP extension for that). We need to talk about how one SMTP mail server in general can verify public key of another SMTP mail server that was involved in email transmission. 5. The mention is that we will create extensions for SMTP, RFC2822 and MIME. First of if you already mention SMTP, there is no need to mention RFC2822. Second I think we may end up doing extensions to CMS syntax as well, this should be mentioned. 6. I do not agree that rating services are out of scope. It may not become a requirement, but if solution supports it as an option, this is better solution then then the one that does not and this should be considered. Thats all for now (since its only been two hours after long drive to San Diego... i might have more when after I've had enough time to review all other email and could go back to this draft charter :) > Welcome to the ietf-mailsig mailing list. Below is the draft working group charter we will be discussing at Thursday's MASS BoF at IETF-60. > > -Jim > > ----- > Working Group Name: STRIVERS (Signatures for Transport Recognition of Imposture in Viral Email and Repugnant Spam) > > IETF Area: SEC > > Working Group Chairs: > Document Editors: > > (some subset of Jim Fenton, Mark Delany, Phill-Hallam Baker, Nathaniel Borenstein, George Webb, ???) > > Problem statement and WG Goals: > > One of the many promising approaches to beating back the tide of spam, > and in particular to thwarting the insidious impersonation practice > known as "phishing," is the widespread adoption of digital signatures > on email messages. However, for over a decade the advocates of > interpersonal digital signatures have struggled with issues of adoption > and use, so that only a small portion of today's email messages are > cryptographically authenticated in any way. > > Several proposals have recently been published for a simple and > automatic mechanism by which outgoing messages may offer limited proof > of potentially-verifiable identity. Although there are already more > than a few mechanisms for attaching a digital signature to an email > message, none meet the particular set of constraints that are ideal for > spam fighting. The ideal signing mechanism for spam fighting would: > > -- Facilitate automated signing of outgoing messages by any > SMTP-initiating entity. > > -- Minimize computational and transactional overhead for high-volume > email servers. > > -- Permit a high degree of anonymity when desired by the sender. > > Several excellent proposals of this general nature have been published > recently, including: > > DomainKeys, draft-delany-domainkeys-base-00.txt > Identified Internet Mail, draft-fenton-identified-mail-00.txt > E-mail Postmarks, http://www.lessspam.org/EmailPostmarks.pdf > MTA Signatures, http://www.elan.net/~william/mta_signatures.htm > Entity-to-Entity S/MIME, draft-hallambaker-entity-00.txt > > The importance of converging on a single standardized mechanism is > difficult to overstate. This group will define such a mechanism. > > Deliverables and Milestones: > > The STRIVERS working group will design extensions to SMTP, RFC 2822, and > MIME that will enable any SMTP-sending entity to: > > -- Convey the fact that a cryptographic signature is associated with > the message being delivered > -- Convey the identity and public key of the signing entity > -- Identify the precise message contents being signed (notably which > headers) > -- Deliver the signature along with the message > > Additionally, it will define a possibly-optional mechanism by which an > SMTP receiver may verify the public key of an SMTP sender. > > Finally, it will specify the appropriate best practices for SMTP senders > when they encounter (legacy) SMTP receivers that do not support the > STRIVERS mechanisms > > The following work items are explicitly ruled out of the scope of > STRIVERS: > > -- Address-based authentication; STRIVERS is intended to > complement MARID, and to be compatible with it if the two overlap or > intersect in any way. > > -- Rating services for conveying reputational information about > the signing entities > > Proposed Timeline: > > Jul 04 Establishment of mailing list, preliminary discussion > Aug 04 BOF meeting at San Diego IETF. Selection of WG leaders & document > editors > Sep 04 Publish signature syntax proposals for discussion > Sep 04 Publish protocol extension proposals for discussion > Oct 04 Interim meeting. Identification of major open issues > Nov 04 WG meeting at Washington IETF. Resolution of major open issues. > Jan 05 Publish first drafts of "consensus" documents > Feb 05 Publish more drafts of "consensus" documents > Mar 05 Publish more drafts of "consensus" documents WG Last Call > Mar 05 WG meeting at IETF conference. Publication of RFC as Proposed > Standard. > Mar 06 Publication of RFC as Draft Standard. > Mar 07 Publication of RFC as Full Standard. > -- William Leibzon Elan Networks william@elan.net From owner-ietf-mailsig Thu Aug 5 11:30:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75IUAEe022886 for ; Thu, 5 Aug 2004 11:30:10 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75IUAGM022885 for ietf-mailsig-skb; Thu, 5 Aug 2004 11:30:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75IUAkt022876 for ; Thu, 5 Aug 2004 11:30:10 -0700 (PDT) (envelope-from dwing@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Aug 2004 11:31:20 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i75IU7na012739 for ; Thu, 5 Aug 2004 11:30:07 -0700 (PDT) Received: from DWINGW2K4 (sjc-vpn5-806.cisco.com [10.21.91.38]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA10618 for ; Thu, 5 Aug 2004 11:30:06 -0700 (PDT) From: "Dan Wing" To: Subject: raw jabber log of MASS BoF at IETF60 Date: Thu, 5 Aug 2004 11:30:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (08:43:11) danwing entered the room. (08:43:11) mass (08:43:11) galvinjamesm entered the room. (2004-07-27 07:49:13) stpeter has set the topic to: Message Authentication Signature Standards BOF (08:44:35) warlord entered the room. (08:44:58) fenton entered the room. (08:46:48) danwing: MSS BoF. Chairs: Jim Fenton and Nathaniel Borenstein. (08:50:40) kivinen entered the room. (09:00:36) danwing: room is full (09:00:55) danwing: Nathaniel starting BoF, reviewing agenda (09:01:40) danwing: Nathaniel: stating clearly: We don't want to do the same thing the 16th time and fail. We believe the problem we're solving has different constaints than the problems that have been solved 15 times unsucessfully. (09:02:32) danwing: Nathaniel: we will review 6 proposals. (09:02:34) johnt entered the room. (09:02:43) danwing: one, domain keys, has seen a good amount of deployment. (09:02:51) waynet entered the room. (09:02:58) SAH entered the room. (09:03:02) rand@sendmail.com entered the room. (09:03:45) danwing: Ted Hardie: agenda bashing: describe characteristic that makes these 6 proposals a common class of proposals. (09:04:04) mass entered the room. (09:04:04) danwing: Nathaniel: yes, that's in the slide deck. (09:04:12) danwing: (slide 2) (09:04:37) danwing: Nathaniel describing WG Goals. (09:05:01) fluffy entered the room. (09:06:32) danwing: rand wacker: anonymity concern. We need to clarify what we're identifying -- an email address, not necessarily a person. (09:06:46) danwing: Nathaniel: agrees, and says we're going into some detail shortly. (09:06:55) rand@sendmail.com left the room (Disconnected.). (09:07:00) danwing: we're changing rooms.... (09:09:46) sakai entered the room. (09:11:04) danwing: . (09:11:09) rand@sendmail.com entered the room. (09:12:26) paf entered the room. (09:13:46) danwing: we're restarting in the new, improved room. (09:14:12) pigdog entered the room. (09:14:21) danwing: Nathaniel discussing slide on WG non-goals. (09:15:11) NFreed entered the room. (09:15:28) danwing: Nathaniel discussing difference between MASS and MARID (09:15:54) danwing: complementary technoligies which provide different forms of evidence about the sender. The combination of MASS and MARID will be more useful than either by itself. (09:16:11) danwing: next slide: potential commonalities between MASS and MARID (09:17:07) danwing: 7 representative proposals. (09:17:10) danwing: - domainkeys (09:17:14) danwing: - identified internet mail (09:17:17) danwing: - email postmarks (09:17:21) danwing: - entity-to-entity s/mime (09:17:24) danwing: - mta signatures (09:17:29) danwing: - bounce address tag validation (09:18:03) hartmans entered the room. (09:18:14) jis entered the room. (09:18:34) danwing: Rohan Mahy asked for the charter to be discussed before the 7 representative proposals. (09:18:35) mass left the room (Logged out). (09:18:47) mass entered the room. (09:18:52) resnick entered the room. (09:19:15) mengwong entered the room. (09:19:37) danwing: Charter being displayed for a few minutes; no consensus to discuss charter before the 7 representative proposals (09:20:12) danwing: - domainkeys (09:20:16) danwing: Mark Delaney, Yahoo. (09:20:25) tonyhansen entered the room. (09:21:23) danwing: Yahoo has concluded they need a signature-based technique. (09:21:44) danwing: must be transparent to existing infrastructure; Yahoo can't start sending S/MIME everywhere on a day (09:21:45) danwing: KISS (09:21:47) resnick: Is that giant "Y!" part of the ABNF (09:21:49) resnick: ? (09:21:57) resnick: ;) (09:22:03) randy entered the room. (09:22:07) danwing: No fees. (09:22:23) hardie entered the room. (09:22:27) danwing: framework: public keys for a domain go into DNS. (09:23:12) danwing: 200401._domainkey.example.net in txt "g=;k=rsa;p=jkejfkejkf..jkjjk" (09:23:31) danwing: signature is stored in an RFC2822 header (09:23:49) danwing: new "DomainKey-Signature:" header (09:24:30) danwing: canonicalization needs to be worked out. (09:24:55) danwing: a more liberal canonicalization form can be used as well, to just sign a subset of signatures. (09:26:32) danwing: 4 independent implementations based on -00 specification (09:26:36) danwing: -01 due out ina few days (09:27:10) danwing: question from floor: why not use S/MIME. (09:27:42) danwing: Mark, Nathaniel: we can't send S/MIME without messing up receivers. (09:28:02) jhutz entered the room. (09:28:08) danwing: Nathaniel: there is a particular constraint: we want to deploy this and not generate any complaints from users that aren't on S/MIME-compliant mailers. (09:28:12) jhutz: who are the chairs of this BOF? (09:28:26) pigdog left the room. (09:28:36) danwing: Nathaniel: one large ISP said that if 1% of users complained support costs would be millions of dollars. (09:28:43) Eliot Lear entered the room. (09:28:45) danwing: (Chairs are listed at beginning of this Jabber session) (09:28:57) danwing: (or see ) (09:29:05) hartmans: How much of the message is signed? Will signatures be screwed up by quoted-unprintable transformations? (09:28:04) danwing: Dave Crocker: defer enumerating differences between 7 proposals unitl the end. (09:28:55) danwing: Mark: one thing that messes up S/MIME is mailing lists that can't handle S/MIME-signed SUBSCRIBE/UNSUBSCRIBE. (09:29:02) danwing: Nathaniel agreed. (09:29:20) danwing: Richard Shockey: use of TXT for holding keys should be Considered Harmful (09:29:46) danwing: Nathaniel: yes, the use of DNS is unresolved, and many of these proposals put the keys into DNS. (09:30:04) danwing: question from floor: Domainkeys says 'no derivative works allowed; will you give IETF change control?' (09:30:14) danwing: Mark: we will give IETF change control. (09:30:54) ekr entered the room. (09:31:06) danwing: Fred Baker: close the microphones until chairs are ready for Q&A to keep meeting on topic. (09:31:15) danwing: Jim Fenton: identified email is similar to domainkeys. (09:31:39) danwing: difference from domainkeys is public key itself is in the message, and DNS is used indirectly to find authorization of that key. (09:31:51) danwing: explicitly supports user- and domain-level signatures (09:32:22) danwing: originator can sign specific header, and those headers are included in the signature. This allows recipient's system to decide which headers to display to user. (09:32:35) danwing: signing and verifying in MTAs (09:32:50) danwing: although it's also possible to sign in an MUA, and to verify in an MUA. (09:33:19) danwing: a header has been defined to communicate MTA's verification, but as mentioned earlier this should be common between groups. (09:33:34) danwing: There is an ability to query originating domain's policy. (09:33:46) danwing: Jim now describing why user-level keying is important. (09:34:08) danwing: Affinity addresses (@ieee.org) (09:34:46) danwing: MTA restrictions - can only use your company's outgoing email servers (09:35:22) danwing: some functions are outsourced, such as benefits@example.com, and you want to authorize that outsourced provider to send mail directly without sending it through your domain. (09:35:32) danwing: A user-level key allows these functions. (09:35:44) danwing: We expect many domains will have only domain-level keys, (09:35:50) danwing: some will have a few user-level keys (09:35:56) danwing: and some domains will key entirely at the user level. (09:36:03) danwing: -00 was published in June. (09:36:10) danwing: a few changes have been made in the implementation since -00. (09:36:33) danwing: one change is "body counts", where you can specify a subset of the body to sign. This allows mailing lists to append stuff without breaking signatures. (09:36:51) danwing: original proposal was to base signature on envelope-from, but have changed it to sender: or From: (09:37:08) danwing: keys can now be stored in DNS or KRS. KRS is an HTTP-based key verification (09:37:34) danwing: next up: e-mail postmarks. Jim Lyon, Microsoft. (09:37:50) danwing: Nathaniel asked for clarifying questions on Jim Fenton's proposal - there were none. (09:37:55) danwing: Jim Lyon: (09:38:36) danwing: Will spend 4 minutes describing why a different proposal. (09:38:44) danwing: Goal: have domain attach a signature to a message. (09:38:59) danwing: attest this mail has passed through the offical mail servers of this domain (09:39:22) danwing: and to attest to various other things (the mail adheres to the antispam rules of that domain) (09:39:43) danwing: This proposals utilizes S/MIME because many MTAs don't send messages unchanged. (09:39:51) danwing: in the wild, some MTAs munge headers: (09:39:52) danwing: reordered (09:39:53) danwing: removed (09:39:54) danwing: changed (09:40:04) hartmans: OK, finally someone admits the implementations problems of previous proposals. (09:40:33) danwing: changed: whitespace and comments are lost, unfolding / refolding, ambiguous folding, character decoding and re-encoding (09:40:46) danwing: body munging: (09:40:54) danwing: end of line whitespace gets added / removed (09:41:00) danwing: transfer decoding and re-encoding (09:41:04) danwing: loss of mime prolog / epilog (09:41:10) danwing: rewriting MIME multipart delimiters (09:41:13) hp entered the room. (09:41:14) danwing: MIME body part elision (09:41:17) danwing: content format conversion (09:41:22) danwing: html sanitization (09:41:32) danwing: add tag lines to content (09:41:36) danwing: . (09:42:12) danwing: The mistake of the world, is that with S/MIME, we have trained MTAs to not modify messages with content-type=multipart/signed (09:42:46) danwing: most of the MUAs have been trained to use S/MIME, although there are still some that aren't using S/MIME (09:43:08) danwing: issues: what does it mean if a message is already signed (by the user) and the domain signs it again (09:43:41) danwing: We concluded it's innocuous if the signerInfos is zero, and use a new certificate type. (09:44:04) danwing: existing code ignores certs it doesn't understand. (09:44:19) danwing: more information: http://www.lessspam.org/EmailPostmarks.pdf (09:44:28) danwing: question: does Microsoft claim any IPR (09:44:34) danwing: Jim: I dont know (09:44:52) danwing: Jim: I'm not the person who originally did this, that person is on LOA. I will find out if Microsoft has IPR on this. (09:45:00) danwing: next up: PHB from Verisign. (09:45:15) danwing: main issue is phishing: banks are being impersonated. (09:45:23) danwing: PHB=Phillip Hallam-Baker (09:45:39) danwing: The banks won't use S/MIME; if they won't use S/MIME, who will? (09:45:46) danwing: - mitigate phishing (09:45:49) danwing: - create signed email market (09:46:03) danwing: make it easy and free to sign email. Get past the S/MIME versus PGP standards war (09:46:14) danwing: problems with S/MIME are described in detail in the Draft. (09:46:33) danwing: unacceptable end user experiences; signatures are optional; end-to-end or nothing attitude. (09:46:45) danwing: The unacceptable end user experience is why banks won't send email using S/MIME (09:47:39) danwing: XKMS 2.0 slide (09:48:01) danwing: you get to the point where you have DomainKeys in the DNS. (09:48:08) danwing: DNS is a bad place to put information on users (09:48:23) danwing: it's a good idea to have a DNS entry to point to a server which contains user keys. (09:48:42) danwing: in large organizations the DNS people aren't involved with users. (09:49:05) danwing: XKMS is W3C candidate recommendation. (09:49:14) danwing: has been reviewed by PKI folks (09:49:40) danwing: manages whole key lifecycle. Original draft was 10 pages, current draft is 30 pages with lots of example. (09:50:08) danwing: To reuse XKMS for MASS, we need only define a URI as a MASS key and use XKMS as the repository to check signatures or to provision keys to the server. (09:50:21) danwing: there are alternatives to XKMS: (09:50:31) danwing: WS-Trust, PKIX SCVP, something new. (09:50:39) danwing: WS-Trust only addresses part of what XKMS does (09:51:12) danwing: SCVP delivers X.509 certificates (09:51:42) danwing: something new will take a long time if designed in MASS. (09:51:56) danwing: keep the key management piece out of the charter (09:52:10) danwing: Nathaniel: it is the chair's intent to not devolve into key management (09:52:20) danwing: Rohan Mahy: what would you do with keys retrieved with XKMS? (09:53:12) danwing: PHB: use a message encapsulation format, and use XKMS to retrieve the key. PHB says that using domainkeys or S/MIME for per-user keying isn't relevant to PHB's presentation. (09:53:22) danwing: next up: Bill Leibzon (09:53:27) danwing: MTA Signature Proposal (09:53:58) danwing: Goals: don't break email system, transparent to end users, any MTA in email path can check signature for any other MTA. Possible to implement using existing libraries. (09:54:19) danwing: slide: 'from S/MIME to MTA Signatures' (09:54:47) danwing: Looked at S/MIME and PGP as a mechanism to attach signature. Wanted to use one of those approaches automatically. (09:54:53) nsb entered the room. (09:54:57) danwing: didn't want the new signatures to be confused with existing signatures (09:55:39) danwing: two ways with S/MIME: new MIME type, or embedded as part of unknown multipart MIME type. (09:56:14) danwing: MTA signature details slide: (09:56:29) danwing: create new MIME type, multipart/x-postal-data (09:56:55) danwing: headers are not signed, only the body is signed. (09:57:07) danwing: the headers are moved into the body to be signed there. (09:57:18) danwing: this is done because headers are modified by intermediate MTAS. (09:57:57) danwing: some mail servers remove certain MIME types from the body, such as .EXE attachments. (09:58:18) danwing: for verification, S/MIME depends on certificate of the vendor. (09:58:27) NFreed left the room (Disconnected). (09:58:33) danwing: so a new type of signature verification method is defined. (09:59:01) danwing: X-Certificate-Verification-Service: "domain:key:email_key1._certs; http:download:der _certs completewhois-com-test1.cer" (09:59:26) danwing: only part of the DNS name is put in -- the prefix. The full DNS name is composed by taking the domainname out of the signature. (10:00:02) danwing: Email Verification slide: (10:00:12) danwing: proposal describes how to verify a signature (10:00:28) danwing: and a method exists to indicate if mail is always or sometimes signed. (10:00:33) danwing: . (10:00:58) danwing: next up: Dave Crocker (10:01:38) danwing: this proposal uses similar technology as previous presentations, but solves a different problem. (10:01:55) danwing: BATV: Bounce Address Tag Validation (10:02:34) danwing: A specification is almost complete. What exists today isn't a specification. (10:02:42) danwing: digitally sign mailfrom (10:03:00) danwing: identity is right-hand-side of mail domain. (10:03:12) danwing: puts its signature into left-hand side. (10:03:35) danwing: hard limit of 64 bytes for total of local-part. (10:04:33) danwing: throughout the mail system everyone can find the localpart without understanding signatures. (10:04:50) paf left the room (Disconnected). (10:04:58) danwing: mailbox@example.com -> batv=mailbox/scheme/parms@example.com (10:05:36) danwing: The receiver of a bounce can determine if it's a bad bounce. (10:06:10) danwing: if you can fix the bounce generation problem, you can look at the address anywhere and detect a forged MAIL FROM. (10:06:20) danwing: if it's a forged MAIL FROM, the rest of it is probably forged. (10:06:48) danwing: benefit: it's only visible to the domain that generated it, so is opaque to everyone else. (10:07:02) danwing: very serious replay protection issues: solution is don't try to be perfect. (10:07:52) danwing: floor: one of the goals is to detect if a bounce that comes back is a message from you, or someone that tried to spoof you. (10:08:23) danwing: floor: when a message is coming inbound, how do you know if it's a BATV legitimate message or a spoofed BATV message. (10:08:41) danwing: Crocker: you have heuristics to detect if it's spoofed (10:11:33) danwing: next up: Jon (10:11:53) danwing: no slides, describing a whitepaper at http://eprivacygroup.net (10:12:06) danwing: implemented as commercial product called postiva (?spelling) (10:12:41) danwing: takes digest of the message, some information from the headers, and assertions from the sender, puts it into XML, signs the XML, and puts all of that into the header. (10:12:51) kei entered the room. (10:13:13) danwing: receiver sees the header, pulls the domains key, and validates the XML. The MUA can then display this to the user. (10:13:06) danwing: PHB asks: is there IPR around this? (10:13:23) danwing: Jon: yes, there are patents pending. However, head of the company is committed to giving open-source compatible license to the patents. (10:14:06) danwing: open request made to disclose any other patents. No response from presenters. (10:14:18) danwing: Nathanial moving to next agenda item: (10:14:23) danwing: "Issues for WG to resolve" (10:14:32) danwing: - signature encapsulation (10:14:35) danwing: - key management (10:14:40) danwing: - canonicalization (10:14:45) jhutz is now known as jhutz2 (10:14:45) danwing: - behavior through mailing lists (10:15:02) jhutz2 is now known as jhutz (10:15:05) farias555 entered the room. (10:15:19) danwing: Rohan: before you can answer these questions, you need to decide the requirements on backward compatibility and what is scope. (10:15:22) danwing: Nathaniel agrees. (10:15:38) danwing: floor: why do you think this will work? (10:16:08) danwing: Nathaniel: rule that concern out of scope. There are complimentary technologies here which will work in different threat models. (10:16:17) danwing: I agree we should make that explicit, but if this is useful or not isn't in scope. (10:16:32) danwing: Nathaniel says there is a threat model in the slide deck. (10:16:52) jhutz: Uhh. This is a BOF. It's purpose is to determine whether to form a working group. (10:16:57) Eliot Lear: ***PLEASE*** don't get hung up on Threat Model docs. (10:17:05) jhutz: How can "is the work useful" possibly _not_ be in scope? (10:17:12) danwing: Jim Fenton, speaking as author of one of the drafts: there is a threat section. (10:17:52) danwing: rand wacker: issues. Behavior through mailing lists, does this mean survival through mailing lists, or does it mean what should a mailing list do? (10:17:57) danwing: Answer from audience: yes, both. (10:18:43) danwing: Mike Thomas: define as part of charter is the transport issue. DNS was alluded to, but we need to be clearer in the charter. This WG needs to look more in-depth on the appropriate transport. (10:18:53) danwing: Nathaniel: you mean key transport? Mike: yes. (10:18:57) ekr: I've read the threat section: it's clearly after the fact. What I want to see is: why is this supposed to work? (10:19:42) danwing: Nathanial discussing WG name. Ted says 'call the WG name 'HUM''. (10:19:57) danwing: Deliverables slide: (10:20:06) Eliot Lear: any solution the WG considers should clearly demonstrate that it can fix the problem, but that's not a WG item, right (10:20:08) Eliot Lear: ? (10:20:20) ekr: Well, first you need to describe what the problem is! (10:20:34) danwing: enable any SMTP-sending entity to: (10:20:38) randy: For name, how about "MESS": MEssage Signature Specification (or some such) (10:20:44) danwing: - convey that a crypto sig. is associated with message being delivered (10:20:53) danwing: - convery the identity and public key of the signing entity (10:21:10) danwing: - identify the precise message contents being signed (notably which headers) (10:21:16) danwing: - deliver the signature along with the message (10:21:54) danwing: And a mechanism allowing recipient to verify the public key of SMTP sender. (10:21:54) tonyhansen left the room (Disconnected). (10:21:58) danwing: Ted: need to clarify if this is intended to work with MTAs or SUBMIT servers. (10:22:26) danwing: it's a critical question to determine which of these M*A entities need to do the signing. (10:22:55) danwing: Nathaniel: absolutely. We worded it as 'any SMTP-sending entity' to be inclusive. (10:23:17) danwing: But specifying just SMTP SUBMIT could be overly restrictive where there isn't a SUBMIT server. (10:23:30) danwing: Dave Crocker: this is about the message contents. Why refer to SMTP at all? (10:24:28) danwing: Nathaniel: you're probably right. If we can do this only changing RFC822, that would probably be better. (10:25:42) danwing: Crocker: second point: the deliverable "deliver the signature along with the message" constrains the behavior of the working group. (10:25:46) danwing: Nathaniel: point taken. (10:26:37) danwing: Jim Lyon: MUA behavior needs to be discussed. (10:26:42) danwing: Nathaniel: agreed. (10:26:52) danwing: Chris Lonvick: non-email messaging in scope? (10:26:59) danwing: Nathaniel: gray area. (10:27:26) danwing: Nathaniel: has been encourgaing folks in instant messaging to look for commonalities. (10:27:36) danwing: Rand: disassociate MTA / MUA (10:28:15) danwing: Eric Burger: what this WG does is going to make a difference. Before talking about Charter and Milestones, talk about the problem, how we're approaching it, and how this will fix it. (10:28:36) danwing: Nathaniel: we should get into the explicit threat model shortly, and we will in a few minutes. (10:28:37) rand@sendmail.com: not disassociate, clarify who can/should check these signatures (10:28:42) danwing: (thanks) (10:28:45) tonyhansen entered the room. (10:29:16) danwing: PHB: problem is working with legacy MTAs, particularly forwarding. SMTP MTAs are routinely broken and they mangle bits. (10:30:17) danwing: Mike Thomas: re: deliverables. Two problems going on: 1. a domain has authorized a piece of mail to be sent (canonicalization, where signatures go), 2. you need a service to ask 'do you authorize this'? (10:30:21) danwing: These problems are disjoint. (10:30:55) danwing: Have a profile for email for this, and a profile for other services (instant messaging?). (10:31:01) danwing: Nathaniel: point taken. (10:31:46) danwing: Randy Gellans: one of Dave Crocker's proposals would be a simpler subset of the other one, and can be implemented without changing anyone else's infrastructure. (10:31:52) danwing: would that be handled in this group, or another group? (10:31:57) danwing: Nathaniel: I'm agnostic. (10:32:24) danwing: Nathaniel: if we decide Dave Crocker's proposal is in scope, the Deliverables is too restrictive. (10:33:41) danwing: Bill Leibzon: two points, 1. we might be changing crypto behavior of S/MIME syntax. (10:33:45) danwing: (sorry, missed his second point) (10:33:51) hp left the room (Disconnected). (10:34:25) danwing: Dave Crocker: what's value of signing content? (10:34:35) danwing: Nathaniel: threat model answers this, so let's talk about it then. (10:35:12) danwing: Michael Thomas: asking Ted Hardie: a receiving entity are not concerned with who (or where) something was injected. Is rather more concerned if sending domain approved of the message. (10:35:23) kivinen left the room. (10:36:10) danwing: Randy: useful to describe if we are changing SUBMIT agents, or MTAs? Because the SUBMIT agent is also the only entity that does the authorization for that message to be submitted. (10:36:45) danwing: Mike Thomas: receiving side can't tell if the SUBMIT agent or a different MTA actually did the signing. (10:36:59) danwing: Nathaniel: it's important to know if a message is supposed to be signed, but isn't. (10:37:52) danwing: Jim Fenton: a domain might choose a policy that says 'all our messages are signed', and they might do that at their egress, or where the messages are archived (such as a stockbroker). Other cases, the SUBMIT server makes the most sense. (10:38:39) danwing: . (10:38:42) danwing: Threat model: (10:38:52) leg entered the room. (10:38:59) danwing: Nathaniel: phishing. (10:40:16) danwing: Jim Fenton: phishing - characterized by attacks on a small # of domains that are being phished. Financial losses to those domains is high. (10:40:37) danwing: other threat is a broad, but low-cost per domain threat -- spam and bounces as a result of your domain being spoofed. (10:41:01) danwing: phishing can be addressed directly by these proposals, aside from human-engineered look-alike domains. (10:41:28) danwing: the second threat (spam and bounces) will require accrediation and reputation services to indicate if the address is well-behaved. (10:41:40) danwing: floor: why do you think this will work with phishing? (10:41:45) danwing: Nathaniel: we'll get back to that. (10:42:03) danwing: Randy: instead of phishing, say 'spoofing'. phishing is a social engineering attack. (10:42:17) danwing: Nathaniel: we can train users to recognize citibank.com (10:42:55) danwing: Bill Leibzon: the authentication permitted by these proposals allows determing if phishing is occuring. (10:43:15) danwing: Michael Thomas: currently, with email, there is no authentication of senders. We need a way to go after people that send email. (10:43:59) rand@sendmail.com: "Its about the brand" (10:44:25) danwing: PHB: direct losses to banks aren't what worry banks. It's the several $B each they have invested into online banking. Phishing reduces confidence and trust, which moves smart folks away from online banking and into lines at physical banks. (10:45:24) danwing: Eric Burger: S/MIIME isn't working because we need to update keys and be changed; how is that different from these proposals which also require the same changes? (10:45:41) danwing: Nathaniel: most of these proposals don't require changing the MUAs. (10:46:25) danwing: Your MTA would do the authz for you -- by the time an MUA receives a message with a signature, it's mostly irrelevant because the MTA has already done the authz. (10:46:37) danwing: Michael Thomas: S/MIME solved a different problem. (10:47:12) danwing: (?): Phishing works because of human-engineering -- a domain looks like paypal.com, but isn't paypal.com. (10:47:42) danwing: The phisher could then send with paypal1.com. (10:48:08) danwing: Nathaniel: this proposal allows a bank to tell customers to 'look carefully at the domain.' (10:49:07) danwing: Fenton: we expect the bad guys to adapt. Currently, 95% of phishing is from spoofed addresses. The reason phishers are using a spoofed address, instead of a human-engineered address, is because it's easier. But we're going to break phishing based on current traffic. (10:49:41) danwing: Fenton: in some of these proposals, the recipient can check the domain's policy. (10:50:05) danwing: Nathaniel, Fenton: agreed that if the domain is socially engineered, we can't solve the problem. (10:50:33) danwing: Ted Hardie: cites www.qualcomm-is-hiring.com (10:50:45) danwing: Ted asks: should we really declare reputation out-of-scope for this WG? (10:51:40) danwing: Nathaniel: I see reputation services as part of the ultimate solution. I'm trying to divide and conquer. (10:51:50) danwing: Rohan Mahy: standard, bcp, informational, experimental? (10:51:56) danwing: Nathaniel: standards-track. (10:52:23) sakai left the room. (10:53:10) danwing: Rohan Mahy: some of the specific proposals don't describe the problem they're solving. This WG needs to scope its work better: which problem it solves and how well (70%, 80%). (10:53:16) danwing: Nathaniel: would saying 'we're preventing spoofing of known domains, but not social engineered domains' be useful? (10:53:17) danwing: Rohan: yes. (10:53:47) danwing: (?): earlier someone said MARID and MASS are different, but that's not true. There is overlap. Describe why MARID doesn't solve the problem. (10:54:06) danwing: Nathaniel: there are at least 3 commonalities (PRA, message marking, accredidation) (10:54:32) danwing: PHB: accreditation issue is important. want to bind logo to a key. (10:56:37) danwing: PHB: there are proposals to make it easier to track registration of look-alike domains, and companies that offer this as a service. (10:57:12) danwing: PHB: it must be possible to link to accreditation service. But IETF shouldn't be describing how to *do* accreditation, don't duplicate X.509's expression of, but need to link to it. (10:57:59) randy: "Marking message to indicate successful/unsuccessful verification" has a spoofing problem -- I get tons of crap with "x-virus-check: passed (no virus found)" in it (10:58:41) danwing: Dave Crocker: this BoF is blowing off important issues. (10:58:10) danwing: Crocker: don't react to today's spammer's behavior, and add genuine utility. (10:59:17) danwing: Crocker: MTA-to-MTA use of S/MIME and PGP has been done and works fine. (10:59:53) danwing: Crocker: We have had difficulty in managing S/MIME and PGP keys. The approaches described here are described for high-volume and high-scale environments. (11:00:47) danwing: Crocker: independant of phishing and spam, it is useful to sign messages. However, we need to discuss carefully how the current proposals solve the problem better than PGP or S/MIME. (11:00:53) danwing: Nathaniel: agreed (11:01:31) danwing: (missed name), Yahoo: signing gives tracability to whoever is phishing using "paypal1.com". (11:02:19) danwing: Cullen Jennings: there are comments about level of requirements: The requirements need to be at the (a) reduce phishing or (b) reduce spam level, not at the prevent spoofing one header level. (11:02:42) danwing: Jon Callas: phishing is a human engineering problem. (11:03:04) danwing: Jon Callas: this is a security method that signs messages in a new way. (11:03:34) danwing: Nathaniel: good point. (11:04:03) danwing: Dave Crocker: responding to Ted's comment on accreditation services: (11:04:38) danwing: any accreditation system has to be based on an identity you believe. What we're building is a building block to such a system. (11:04:48) danwing: Nathaniel: yes. (11:05:00) danwing: Rohan Mahy: have we articulated requirements? (11:05:09) danwing: Nathaniel: we'll have to finish on the mailing list (11:05:55) danwing: PHB: phishing is getting more sophisticated using trojans. (11:06:09) danwing: PHB: the gap between perceived security of email and actual security of email is significant. (11:06:28) danwing: PHB: we can't tell the user 'you're too stupid'. (11:06:41) waynet left the room. (11:07:14) danwing: PHB: concentrate on the domain level identity, as that has historically been successful. (11:07:51) danwing: PHB: witness SSL and the padlock icon. (11:09:29) danwing: Mike Thomas: regarding reputation/accreditation: we need a way to detect forgery. Once we have that, the spammers and forgers have to get throw-away domains. (11:09:55) danwing: problems between domain-level authz and accreditation are similar, but there may be legal differences we're not aware of. (11:10:32) danwing: Mike Thomas: divide the problem into two things: authz mail, and later in this WG take on accreditation. (11:11:08) danwing: Nathaniel: wants to narrow goal of WG. Nathaniel wants reputation addressed separately. (11:11:35) danwing: Fenton: 1. can we do good with a crypto approach w/o accreditation? A: Yes. (11:11:56) danwing: 2. Would accreditation fragment this group? Yes, so keep it out. (11:12:19) danwing: 3. This BoF is under the Security area (instead of applications). Accreditation seems more an applications-area problem. (11:12:50) danwing: Nathaniel: word-smithing charter will be done on the mailing list. (11:13:01) danwing: http://www.imc.org/ietf-mailsig/ (11:13:36) danwing: mailing list: ietf-mailsig@imc.org (11:13:43) mengwong: "i would like to encourage those of you who are interested, to participate more on the mailing list; i would also like to encourage those of you who think all this is a total waste of time, to not waste your time." (11:13:47) mengwong: -- nsb (11:14:34) danwing: (sorry, missed name): we can build goals only by knowing what the problem we're trying to solve is. (11:14:56) danwing: Nathaniel: we need a reference arch. for spam finding, and the output of this WG will fit in. (11:15:02) danwing: (): I don't see how this WG fits in. (11:15:05) danwing: Nathaniel: fair enough. (11:15:40) danwing: hum vote: consensus is to move this BoF forward. (11:16:17) danwing: Mark (?): some spam traffic is originating from within someone's network via trojans that have been compromised. (11:16:19) jis: Apparently subscription to ietf-mailsig doesn't require confirmation (11:16:33) jis: (Marcus Leech) (11:16:41) danwing: (tx) (11:17:24) danwing: Eric Burger: I hummed because this work should be done. Something is better than nothing. But I don't like the existing charter. (11:19:21) danwing: PHB: we need a requirements document that shows how this BoF -- and everything else -- fits into the overall architecture to block phishing, spamming. (11:19:21) fluffy left the room (Disconnected). (11:19:30) danwing: Nathaniel: 34 consortia working on spam. (11:19:50) danwing: Nathaniel: yes, we need an architecture. The criticism applies to MARID and MASS. (11:19:59) SAH left the room. (11:20:44) danwing: Crispin (?), IACA: much spam doesn't spoof a legitimate address at all. But they generally cannot respond to the proported address they're spoofing. None of the proposals here take that weakness into account. Folks should consider this weakness into a mechanism to formulate this solution. (11:21:07) danwing: Nathaniel: challenge-response could resolve this. Expects to see WGs that address C/R. (11:22:01) danwing: : In favor of moving this BoF forward we can resolve the underlying problem. (11:22:11) danwing: wants to see threat model. (11:23:19) danwing: Russell Housley:: deliver a threat and requirements document. (11:24:12) tonyhansen left the room (Disconnected). (11:24:29) danwing: Bellovin: requirements document needs to make hard decisions. Stress MTAs or MUAs, for example. (11:25:12) danwing: PHB: security isn't the hard part (signature, From: address, etc.), but the big issue is the message encapsulation formats. This encapsulation format is where the proposals diverge in substance. (11:25:54) danwing: S/MIME versus headers, based on the 'yuck' in the system. We need to decide which types of canonicalization survive and which don't. (11:25:57) hartmans: I think I agree with phb here; a study in what is possible to get through email would be useful (11:26:08) hartmans: And may well be necessary. (11:26:12) danwing: Nathaniel: that's where Yahoo's DomainKeys deployment can teach us. (11:26:53) danwing: Mike Thomas: lock-stepping requirements documents and our work is too slow. (11:27:28) danwing: Nathaniel: yes, we need to do this in parallel fashion. Other groups will do a worse job than us. (11:27:29) kei: ( Thanks a lot for your contribution(logging)! > danwing ) (11:27:45) danwing: (sure, no extra charge!) (11:27:55) jis left the room (Disconnected). (11:27:59) hardie left the room. (11:28:06) danwing: this Jabber log will be posted to the mailing list. (11:28:16) farias555 left the room. (11:28:18) rand@sendmail.com left the room (Disconnected.). (11:28:19) johnt left the room. From owner-ietf-mailsig Fri Aug 13 16:50:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DNolfE075588 for ; Fri, 13 Aug 2004 16:50:47 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DNolnJ075587 for ietf-mailsig-skb; Fri, 13 Aug 2004 16:50:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DNokx9075578 for ; Fri, 13 Aug 2004 16:50:46 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2004 16:53:34 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7DNn3oG027221; Fri, 13 Aug 2004 16:49:26 -0700 (PDT) Received: from fenton-w2k01.cisco.com (dhcp-128-107-163-140.cisco.com [128.107.163.140]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7E0MgkZ004724; Fri, 13 Aug 2004 17:22:45 -0700 Message-Id: <4.3.2.7.2.20040813164445.03fe0978@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Aug 2004 16:51:06 -0700 To: ietf-mailsig@imc.org From: Jim Fenton Subject: Viewgraphs from MASS BoF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-IMAIL-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1092442965.163204"; x:"432000"; a:"rsa-sha1"; b:"0:403"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"SyMDWRQrnfutL8dcvQTOAcQh2eIo/podlZ53oT0M0mqnU/i/72ZFmrffZ0ZC7" "el5pynbK0J9lLzkhT2BRh8J5ILQrBQzVVsZmS16UGIUpjxZp65NE016PlEno3" "CJTFd2dBsIOuIi/OWYf3hTpkD1A9lhWbx0s9ZCSXqsqCNyioI="; c:"Date: Fri, 13 Aug 2004 16:51:06 -0700"; c:"From: Jim Fenton "; c:"Subject: Viewgraphs from MASS BoF" X-IMAIL-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com" Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nathaniel Borenstein has posted viewgraphs from the MASS BoF on his website at: http://guppylake.com/~nsb/mass60/ The main presentation is at http://guppylake.com/~nsb/mass60/MASS-BoF.pdf; the others in the directory are the presentations on individual signing proposals given at the BoF. These presentations have also been submitted to appear in the Proceedings of the 60th IETF. -Jim From owner-ietf-mailsig Wed Aug 18 12:51:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJpgrS027066 for ; Wed, 18 Aug 2004 12:51:42 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJpg6w027065 for ietf-mailsig-skb; Wed, 18 Aug 2004 12:51:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJpefh027049 for ; Wed, 18 Aug 2004 12:51:41 -0700 (PDT) (envelope-from Atul.Sharma@nokia.com) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7IJphB19438 for ; Wed, 18 Aug 2004 22:51:44 +0300 (EET DST) X-Scanned: Wed, 18 Aug 2004 22:51:41 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7IJpeGY031344 for ; Wed, 18 Aug 2004 22:51:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00yF7jSI; Wed, 18 Aug 2004 22:51:40 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7IJpcn17371 for ; Wed, 18 Aug 2004 22:51:38 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 18 Aug 2004 14:50:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Anonymous signed mail Date: Wed, 18 Aug 2004 15:50:47 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Anonymous signed mail Thread-Index: AcSFXKd/g7KHnAF8TuiCN5ZN/JKo5w== From: To: X-OriginalArrivalTime: 18 Aug 2004 19:50:48.0470 (UTC) FILETIME=[A88FD360:01C4855C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IJpffh027059 Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I was going through the slides presented at IETF-60. One of the goals listed there was: "Preserve Anonymity if requested by the sender" I had some questions regarding this: * Won't allowing anonymous mails defeat the anti-spam quality of MASS? * What does it mean to have a "signed" anonymous mail? MTA authenticates that it is sent by an anonymous sender? or MTA authenticates that it is sent from a valid email address, it is just that sender does not want the identity to be revealed to the end recepient, the MTA is aware of the sender identity? May be this issue was discussed at IETF-60 meeting. Since I came in late, and was not discussed while I was there, it will be great if someone could answer these questions. Thanks, Atul From owner-ietf-mailsig Wed Aug 18 13:44:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKi0m4035347 for ; Wed, 18 Aug 2004 13:44:00 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IKi0Qw035346 for ietf-mailsig-skb; Wed, 18 Aug 2004 13:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKi0CV035338 for ; Wed, 18 Aug 2004 13:44:00 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7IKi1j07937; Wed, 18 Aug 2004 13:44:02 -0700 Date: Wed, 18 Aug 2004 13:43:58 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1459678407.20040818134358@brandenburg.com> To: Atul.Sharma@nokia.com CC: ietf-mailsig@imc.org Subject: Re: Anonymous signed mail In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Atul, By way of priming the discussion pump: ASnc> I was going through the slides presented at IETF-60. One of the goals ASnc> listed there was: "Preserve Anonymity if requested by the sender" ASnc> I had some questions regarding this: ASnc> * Won't allowing anonymous mails defeat the anti-spam quality of MASS? I believe that spam control is about accountability and does not automatically require directly identifying the agent that created or posted the message. Accountability can be quite indirect, as long as it involves real substance. By way of an extreme example, if a sender is required to post a US$1M bond that is at risk if there are complaints against messages from that sender, then we are not likely to care whether we can directly identify the sender. The assumption is that risking that much money will dissuade rogue senders from doing nasty things that would prompt us to make complaints. ASnc> * What does it mean to have a "signed" anonymous mail? It means that a responsible agent is doing the signing. Who that is is a separate matter. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mailsig Wed Aug 18 13:59:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKxdmI037824 for ; Wed, 18 Aug 2004 13:59:39 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IKxdqA037823 for ietf-mailsig-skb; Wed, 18 Aug 2004 13:59:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKxcSO037816 for ; Wed, 18 Aug 2004 13:59:39 -0700 (PDT) (envelope-from Atul.Sharma@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7IKxe313619; Wed, 18 Aug 2004 23:59:40 +0300 (EET DST) X-Scanned: Wed, 18 Aug 2004 23:59:22 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7IKxMfi007819; Wed, 18 Aug 2004 23:59:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Z7JTbs; Wed, 18 Aug 2004 23:59:21 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7IKxJn09642; Wed, 18 Aug 2004 23:59:20 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 18 Aug 2004 15:59:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Anonymous signed mail Date: Wed, 18 Aug 2004 16:59:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Anonymous signed mail Thread-Index: AcSFZCzGi8IXpyJpTs60PQX/5sDOKwAARG2g From: To: Cc: X-OriginalArrivalTime: 18 Aug 2004 20:59:19.0287 (UTC) FILETIME=[3ACCB870:01C48566] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IKxdSO037817 Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Dave, Thanks for the quick response. To dissuade spammers, we shall need a way to be able to identify them direct or indirect. Agreed it need not be direct. If we can indirectly identify the sender, then the message was not truely anonymous after all. Atul > -----Original Message----- > From: ext Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Wednesday, August 18, 2004 4:44 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: ietf-mailsig@imc.org > Subject: Re: Anonymous signed mail > > > Atul, > > > By way of priming the discussion pump: > > > ASnc> I was going through the slides presented at IETF-60. > One of the goals > ASnc> listed there was: "Preserve Anonymity if requested by > the sender" > > ASnc> I had some questions regarding this: > ASnc> * Won't allowing anonymous mails defeat the > anti-spam quality of MASS? > > I believe that spam control is about accountability and does not > automatically require directly identifying the agent that created or > posted the message. Accountability can be quite indirect, as > long as it > involves real substance. > > By way of an extreme example, if a sender is required to post a US$1M > bond that is at risk if there are complaints against messages > from that > sender, then we are not likely to care whether we can > directly identify > the sender. The assumption is that risking that much money will > dissuade rogue senders from doing nasty things that would prompt us to > make complaints. From owner-ietf-mailsig Wed Aug 18 16:58:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INw1ob066702 for ; Wed, 18 Aug 2004 16:58:01 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7INw1Nf066701 for ietf-mailsig-skb; Wed, 18 Aug 2004 16:58:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7INw0BW066681 for ; Wed, 18 Aug 2004 16:58:00 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 18 Aug 2004 17:02:12 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7INvtH6027377; Wed, 18 Aug 2004 16:57:56 -0700 (PDT) Received: from fenton-w2k01.cisco.com (dhcp-128-107-163-140.cisco.com [128.107.163.140]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7INwAkZ031436; Wed, 18 Aug 2004 16:58:12 -0700 Message-Id: <4.3.2.7.2.20040818164645.041db1e0@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Aug 2004 16:59:28 -0700 To: Dave Crocker , Atul.Sharma@nokia.com From: Jim Fenton Subject: Re: Anonymous signed mail Cc: ietf-mailsig@imc.org In-Reply-To: <1459678407.20040818134358@brandenburg.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-IMAIL-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1092873493.60922"; x:"432000"; a:"rsa-sha1"; b:"0:2408"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"vW411nCgrTMrWu1PXi54qSyMfA8X9hhAhTehlL3sAMfYp948v5vBQgCyj02qy" "4OeHilnaPTrA8IPtEiiJVlZBrnC+YyccSY31+UlY76VpqDZLcJqrreRZyMrxi" "hmiUtL+7LVG0IawVX1QCHhVTvvKcMb7yYkOGlFcqhfk6boC/w="; c:"Date: Wed, 18 Aug 2004 16:59:28 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: Anonymous signed mail" X-IMAIL-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com" Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Exactly. [Below describing properties of the Identified Internet Mail proposal; don't know whether all of these properties are shared by the others that were presented]: To state it a different way, what's important isn't who the sender is, but whether the sender is authorized to use that email address. In a sense we're making the domain administrator responsible for messages sent by the domain, and trying to empower the administrator to regulate the domain. Future accreditation/reputation systems will motivate the administrator to do that regulation. To look at it another way, identity by itself isn't enough. I could sign this message with my PGP key which shows my address as , but if that address wasn't valid any more, there is nothing that the domain can do about my use of that PGP key anyway. This is good news for privacy advocates (we aren't changing the anonymity properties of email) as well as for specialized situations where anonymity is important (whistle-blower hotlines, for example). -Jim At 01:43 PM 8/18/2004 -0700, Dave Crocker wrote: >Atul, > > >By way of priming the discussion pump: > > >ASnc> I was going through the slides presented at IETF-60. One of the goals >ASnc> listed there was: "Preserve Anonymity if requested by the sender" > >ASnc> I had some questions regarding this: >ASnc> * Won't allowing anonymous mails defeat the anti-spam quality of MASS? > >I believe that spam control is about accountability and does not >automatically require directly identifying the agent that created or >posted the message. Accountability can be quite indirect, as long as it >involves real substance. > >By way of an extreme example, if a sender is required to post a US$1M >bond that is at risk if there are complaints against messages from that >sender, then we are not likely to care whether we can directly identify >the sender. The assumption is that risking that much money will >dissuade rogue senders from doing nasty things that would prompt us to >make complaints. > > >ASnc> * What does it mean to have a "signed" anonymous mail? > >It means that a responsible agent is doing the signing. Who that is is >a separate matter. > > >d/ >-- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA From owner-ietf-mailsig Wed Aug 18 17:31:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J0VR7X071872 for ; Wed, 18 Aug 2004 17:31:27 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7J0VR2L071871 for ietf-mailsig-skb; Wed, 18 Aug 2004 17:31:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7J0VQ1j071865 for ; Wed, 18 Aug 2004 17:31:26 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7J0UTj23653; Wed, 18 Aug 2004 17:30:29 -0700 Date: Wed, 18 Aug 2004 17:30:24 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <104406302.20040818173024@brandenburg.com> To: Jim Fenton CC: Atul.Sharma@nokia.com, ietf-mailsig@imc.org Subject: Re: Anonymous signed mail In-Reply-To: <4.3.2.7.2.20040818164645.041db1e0@mira-sjc5-1.cisco.com> References: <4.3.2.7.2.20040818164645.041db1e0@mira-sjc5-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jim, JF> To state it a different way, what's important isn't who the sender is, but whether the JF> sender is authorized to use that email address. In a sense we're making the domain Actually, I don't find "authorization" all that interesting. Necessary, perhaps, but not interesting. What is interesting is whether a gross violator can be properly penalized. That's different than saying that someone gave the permission (authorization) before they screwed up. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mailsig Thu Aug 19 14:00:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JL0YgS067945 for ; Thu, 19 Aug 2004 14:00:34 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JL0YDB067943 for ietf-mailsig-skb; Thu, 19 Aug 2004 14:00:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JL0Y7u067932 for ; Thu, 19 Aug 2004 14:00:34 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 Aug 2004 14:06:04 +0000 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7JK0VH6009823; Thu, 19 Aug 2004 13:00:31 -0700 (PDT) Received: from fenton-w2k01.cisco.com (dhcp-128-107-163-140.cisco.com [128.107.163.140]) by imail.cisco.com (8.12.5/8.12.10) with ESMTP id i7JL10kZ020449; Thu, 19 Aug 2004 14:01:02 -0700 Message-Id: <4.3.2.7.2.20040819135431.035f4230@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Aug 2004 14:02:03 -0700 To: Dave Crocker From: Jim Fenton Subject: Re: Anonymous signed mail Cc: Atul.Sharma@nokia.com, ietf-mailsig@imc.org In-Reply-To: <104406302.20040818173024@brandenburg.com> References: <4.3.2.7.2.20040818164645.041db1e0@mira-sjc5-1.cisco.com> <4.3.2.7.2.20040818164645.041db1e0@mira-sjc5-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-IMAIL-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1092949263.27894"; x:"432000"; a:"rsa-sha1"; b:"0:1100"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"As3F/yGGWsSlAtOP8egOaSvxgbcdkq1hStxAYpXU7jfe8CXdJQ2mdTlYU75ED" "G+RuV6mSChB+xMcYw03XHOUBnZ1vpJS8YexRkYs6RNchSgZXYsjR+/s9M18NW" "0zrgx7XnRbF/mUbB0tm305CliP+tAQRgxJHknD9/OcE90F+6A="; c:"Date: Thu, 19 Aug 2004 14:02:03 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: Anonymous signed mail" X-IMAIL-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com" Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 05:30 PM 8/18/2004 -0700, Dave Crocker wrote: >Jim, > >JF> To state it a different way, what's important isn't who the sender is, but whether the >JF> sender is authorized to use that email address. In a sense we're making the domain > > Actually, I don't find "authorization" all that interesting. > Necessary, perhaps, but not interesting. > > What is interesting is whether a gross violator can be properly > penalized. That's different than saying that someone gave the > permission (authorization) before they screwed up. "Interesting", I presume, refers to how effective this mechanism is against spam. I completely agree that authorization is necessary, but not sufficient; we will need accreditation/reputation services as well. The penalty will be a lower rating. But there are other problems we could be solving as well, such as to aid enforcement of audit mechanisms at financial institutions (if the message is signed, it got archived for the regulators). That isn't as urgent a problem to solve as spam/phishing to most of us, but it's a side benefit. -Jim From owner-ietf-mailsig Thu Aug 19 17:56:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K0uHLR003332 for ; Thu, 19 Aug 2004 17:56:17 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7K0uHDh003331 for ietf-mailsig-skb; Thu, 19 Aug 2004 17:56:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7K0uGpX003324 for ; Thu, 19 Aug 2004 17:56:17 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7K0s7j24446; Thu, 19 Aug 2004 17:54:07 -0700 Date: Thu, 19 Aug 2004 17:54:03 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1337991884.20040819175403@brandenburg.com> To: Jim Fenton CC: Atul.Sharma@nokia.com, ietf-mailsig@imc.org Subject: Re: Anonymous signed mail In-Reply-To: <4.3.2.7.2.20040819135431.035f4230@mira-sjc5-1.cisco.com> References: <4.3.2.7.2.20040818164645.041db1e0@mira-sjc5-1.cisco.com> <4.3.2.7.2.20040818164645.041db1e0@mira-sjc5-1.cisco.com> <4.3.2.7.2.20040819135431.035f4230@mira-sjc5-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jim, >> Actually, I don't find "authorization" all that interesting. >> Necessary, perhaps, but not interesting. >> >> What is interesting is whether a gross violator can be properly >> penalized. That's different than saying that someone gave the >> permission (authorization) before they screwed up. JF> "Interesting", I presume, refers to how effective this mechanism is against spam. yeah, that probably summarizes it. anything that has a primary, desired effect, against spam or anything that is... interesting. JF> But there are other problems we could be solving as well, such as to aid enforcement of JF> audit mechanisms at financial institutions (if the message is signed, it got archived for JF> the regulators). In my experience, there needs to be a very, very big separation between the work done for the primary goal and the benefits that might accrue from it for other situations. It's not that the other situations are not important or that having a mechanism work for multiple situations is not a good thing. JF> That isn't as urgent a problem to solve as spam/phishing to most of us, JF> but it's a side benefit. I think your wording is exactly right. Paying attention to too many immediate goals usually dilutes the work, typically producing cumbersome solutions and usually taking longer to get out the door. However, I LIKE having those derivative benefits around for follow-on work, since that tends to produce designs with practical extensibility. But "follow-on" is very different than "part of the initial solution" I can ramble on about this point more, if I'm not making enough sense, but it sounds as if we are in agreement about priorities. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mailsig Fri Aug 27 14:14:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLEXcU062332 for ; Fri, 27 Aug 2004 14:14:33 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RLEXRI062331 for ietf-mailsig-skb; Fri, 27 Aug 2004 14:14:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from web40404.mail.yahoo.com (web40404.mail.yahoo.com [66.218.78.101]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RLEXPm062316 for ; Fri, 27 Aug 2004 14:14:33 -0700 (PDT) (envelope-from domainkeys-feedbackbase01@yahoo.com) Message-ID: <20040827211433.2641.qmail@web40404.mail.yahoo.com> Received: from [216.145.52.229] by web40404.mail.yahoo.com via HTTP; Fri, 27 Aug 2004 14:14:33 PDT Date: Fri, 27 Aug 2004 14:14:33 -0700 (PDT) From: Reply-To: domainkeys-feedbackbase01@yahoo.com Subject: domainkeys-base-01 now available on IETF website To: ietf-mailsig@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As alluded to at MASS a few weeks back, we have posted the -base-01 draft. http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt Mark. From owner-ietf-mailsig Fri Aug 27 14:25:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLP5b3062825 for ; Fri, 27 Aug 2004 14:25:05 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RLP5SF062824 for ietf-mailsig-skb; Fri, 27 Aug 2004 14:25:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RLP5pU062816 for ; Fri, 27 Aug 2004 14:25:05 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 27 Aug 2004 17:25:06 -0400 id 0016BD65.412FA6B2.00001BB2 In-Reply-To: <20040827211433.2641.qmail@web40404.mail.yahoo.com> References: <20040827211433.2641.qmail@web40404.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <900A4D45-F86F-11D8-9196-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: ietf-mailsig@imc.org From: Andrew Newton Subject: Re: domainkeys-base-01 now available on IETF website Date: Fri, 27 Aug 2004 17:25:04 -0400 To: domainkeys-feedbackbase01@yahoo.com X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Aug 27, 2004, at 5:14 PM, domainkeys-feedbackbase01@yahoo.com wrote: > > As alluded to at MASS a few weeks back, we have posted > the -base-01 draft. > > http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt Do you intend to take the "no derivative works" off only if MASS get to WG? -andy From owner-ietf-mailsig Fri Aug 27 16:53:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RNrZbt072953 for ; Fri, 27 Aug 2004 16:53:35 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RNrZ4k072952 for ietf-mailsig-skb; Fri, 27 Aug 2004 16:53:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from web40404.mail.yahoo.com (web40404.mail.yahoo.com [66.218.78.101]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7RNrZOH072943 for ; Fri, 27 Aug 2004 16:53:35 -0700 (PDT) (envelope-from domainkeys-feedbackbase01@yahoo.com) Message-ID: <20040827235335.24929.qmail@web40404.mail.yahoo.com> Received: from [216.145.52.229] by web40404.mail.yahoo.com via HTTP; Fri, 27 Aug 2004 16:53:35 PDT Date: Fri, 27 Aug 2004 16:53:35 -0700 (PDT) From: Reply-To: domainkeys-feedbackbase01@yahoo.com Subject: Re: domainkeys-base-01 now available on IETF website To: ietf-mailsig@imc.org In-Reply-To: <20040827234730.1987.qmail@jobs.emu.st> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Do you intend to take the "no derivative works" off only if MASS get to WG? There is no bearing on MASS per se, it's more whether this I-D becomes the basis for an IETF standard or not. If that's via MASS, fine. If it's via some other means, likewise fine. At the point at which it becomes that basis, the "no derivative works" has to be removed as the IETF needs editorial control, right? Mark. From owner-ietf-mailsig Sun Aug 29 08:22:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TFM2af088683 for ; Sun, 29 Aug 2004 08:22:02 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7TFM2dU088681 for ietf-mailsig-skb; Sun, 29 Aug 2004 08:22:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7TFM0wI088659 for ; Sun, 29 Aug 2004 08:22:01 -0700 (PDT) (envelope-from nsb@guppylake.com) Received: from [192.168.0.102] [68.42.70.186] by mail.optistreams.net with ESMTP (SMTPD32-8.04) id AE756DEF00C8; Sun, 29 Aug 2004 07:55:49 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: , From: Nathaniel Borenstein Subject: Re: Anonymous signed mail Date: Sat, 28 Aug 2004 12:32:46 -0400 To: X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Aug 18, 2004, at 4:59 PM, wrote: > To dissuade spammers, we shall need a way to be able to identify > them direct or indirect. Not necessarily. I agree that in practice most "anonymous" mail really is traceable, i.e. "indirectly traceable," but you can make tracing require rather more than a casual effort. More abstractly, though, sender identification is only one of three major general strategies that people are taking to fight spam: -- identifying spam senders -- filtering spam content -- disrupting spam economics I think most of us would agree that the second strategy, filtering, is a running-in-place palliative rather than a solution, with Moore's Law working against it. Unfortunately in most circumstances today it's almost the only thing we have, which is why we're here trying to build something else even while most of us explore ever-cleverer filtering as well. Most of the non-filtering approaches, including MASS, are in the "identifying senders" category, but I believe that the third (economic) alternative has its value, particularly in facilitating anonymous mail. There are still a wild variety of economically-oriented proposals, most but not all of them nearly hopelessly implausible. Schemes that seek to charge postage for every email message are a long way from reality, but there are other approaches. At the ISP level, a simple metering strategy can change the economics of spam originating with customers who are either spammers or zombies -- simply give each email account an outgoing mail quota, set generously enough to let any non-bulk mail users just slip on by, and with special rules/mechanisms for mailing lists. This requires no standards setting at all, and is being implemented in primitive form by several mass market ISPs already. Most interesting to me, however, is the use of computational challenges for the purpose of "economic filtering" of spam. I'm willing to let anyone in the world send me email if they're willing to invest, say, 60 CPU seconds in the effort, because I know it isn't worth it to spammers. That's no big deal for legitimate users, although clearly they'll prefer to avoid the 15 second penalty and use authentication-based approaches when they aren't trying to be anonymous. But such computational challenges are, to my mind, the key technology that will permit us to preserve privacy in an era of stricter spam control. None of this places any limits on what we're trying to do in the MASS group, but I'd prefer for us to try to view our authentication mechanisms as part of a larger picture that preserves computational or economic alternatives to sender identification. And I'd particularly like to try to build a consensus understanding that anonymity *can* be preserved in an era of spam control, rather than letting spam be used as an excuse for killing off anonymity. -- Nathaniel From owner-ietf-mailsig Mon Aug 30 13:10:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKAUUO002028 for ; Mon, 30 Aug 2004 13:10:30 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UKAU1S002027 for ietf-mailsig-skb; Mon, 30 Aug 2004 13:10:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKAT0m002021 for ; Mon, 30 Aug 2004 13:10:29 -0700 (PDT) (envelope-from richard@shockey.us) Received: from RSHOCKEY-LTXP.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7UKASc06698; Mon, 30 Aug 2004 13:10:28 -0700 Message-Id: <6.1.0.6.2.20040830154858.04806eb0@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 30 Aug 2004 16:10:22 -0400 To: Nathaniel Borenstein , From: Richard Shockey Subject: Re: Anonymous signed mail Cc: , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >None of this places any limits on what we're trying to do in the MASS >group, but I'd prefer for us to try to view our authentication mechanisms >as part of a larger picture that preserves computational or economic >alternatives to sender identification. And I'd particularly like to try >to build a consensus understanding that anonymity *can* be preserved in an >era of spam control, rather than letting spam be used as an excuse for >killing off anonymity. -- Nathaniel I'm thinking out loud here so to sp[eak but I'm wondering if there is some parellel's here to the authentication and authorization problems some of us in the SIP community are struggling with and is an investigation of SAML based Identity technology for the MASS Problem Statement warranted. A variety of cryptographic materials could be stored in the signed assertion. Title : Using SAML for SIP Author(s) : H. Tschofenig, et al. Filename : draft-tschofenig-sip-saml-00.txt Pages : 33 Date : 2004-7-13 This document describes how to use the Security Assertion Markup Language (SAML) to offer trait-based authorization. As such, it provides an alternative to existing authorization mechanisms for SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-00.tx ########## On a related subject ..I'm assuming that there is already general consensus that the use of TXT for storing public keys as described http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt shall be considered harmful. I've often thought it was time to start thinking of using NAPTR records for such things as PKI since the represent the most powerful and flex able RR records we have as in for instance and now would be a good time to start using them as in, for example. order pref flags service regexp replacement IN NAPTR 100 10 "n" "PK2U+smime:pkcs7:https" "" "pkinfo.example.bar/[input]". IN NAPTR 90 10 "n" "PK2U+smime:pkcs7:ldaps" "" "pkinfo2.example.bar/[input]". Some of these concepts are also outlined in. http://www.ietf.org/internet-drafts/draft-daigle-snaptr-01.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From owner-ietf-mailsig Mon Aug 30 13:47:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKlkL0009320 for ; Mon, 30 Aug 2004 13:47:46 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UKlkHR009319 for ietf-mailsig-skb; Mon, 30 Aug 2004 13:47:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from web40401.mail.yahoo.com (web40401.mail.yahoo.com [66.218.78.98]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7UKlkI6009280 for ; Mon, 30 Aug 2004 13:47:46 -0700 (PDT) (envelope-from domainkeys-feedbackbase01@yahoo.com) Message-ID: <20040830204744.29948.qmail@web40401.mail.yahoo.com> Received: from [216.145.52.229] by web40401.mail.yahoo.com via HTTP; Mon, 30 Aug 2004 13:47:44 PDT Date: Mon, 30 Aug 2004 13:47:44 -0700 (PDT) From: Reply-To: domainkeys-feedbackbase01@yahoo.com Subject: Re: Anonymous signed mail To: ietf-mailsig@imc.org In-Reply-To: <6.1.0.6.2.20040830154858.04806eb0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Richard Shockey wrote: > On a related subject ..I'm assuming that there is > already general consensus > that the use of TXT for storing public keys as > described > > http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt > > shall be considered harmful. I don't think that's entirely clear at all. It depends on whether you're asking the question as to whether DNS is the right place for storing such material in the short or long term and whether TXT is the right type in the short or long term. I believe the answer to those four points can all be different. > > I've often thought it was time to start thinking of > using NAPTR records for > such things as PKI since the represent the most > powerful and flex able RR > records we have as in for instance and now would be > a good time to start > using them as in, for example. Above and beyond relevance of the feature-set of NAPTR to this application, is the question of whether indirection through the DNS to a TCP based content server create too high an impact on the Internet at large. Some claim that even a single additional DNS lookup imposed by this and similar systems (SPF, SENDER-ID) create an as-yet unknown and possibly unacceptable load on the DNS infrastructure. In that context, adding a TCP lookup on top of an additional DNS lookup adds quiet a load. Regards. From owner-ietf-mailsig Mon Aug 30 14:59:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ULxk1J023926 for ; Mon, 30 Aug 2004 14:59:46 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ULxkbi023925 for ietf-mailsig-skb; Mon, 30 Aug 2004 14:59:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ULxjgf023913 for ; Mon, 30 Aug 2004 14:59:45 -0700 (PDT) (envelope-from richard@shockey.us) Received: from RSHOCKEY-LTXP.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7ULxmc21190; Mon, 30 Aug 2004 14:59:48 -0700 Message-Id: <6.1.0.6.2.20040830172010.04c04070@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 30 Aug 2004 17:58:55 -0400 To: domainkeys-feedbackbase01@yahoo.com, ietf-mailsig@imc.org From: Richard Shockey Subject: Re: Anonymous signed mail In-Reply-To: <20040830204744.29948.qmail@web40401.mail.yahoo.com> References: <6.1.0.6.2.20040830154858.04806eb0@joy.songbird.com> <20040830204744.29948.qmail@web40401.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_18954915==.ALT" Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=====================_18954915==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:04 PM 8/30/2004, domainkeys-feedbackbase01@yahoo.com wrote: >--- Richard Shockey wrote: > > > On a related subject ..I'm assuming that there is > > already general consensus > > that the use of TXT for storing public keys as > > described > > > > >http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt > > > > shall be considered harmful. > >I don't think that's entirely clear at all. > >It depends on whether you're asking the question as to >whether DNS is the right place for storing such >material in the short or long term and whether TXT is >the right type in the short or long term. What I'm saying is that A. the DNS is NOT the right place for directly storing such material period irrespective of the underlying RR. This was the principal problem we saw in the DNSSEC debates and that time it was made quite clear that cryptographic material not directly related to the proper, secure functioning of the DNS should not be stored in the DNS. The short term vs long term issues are IMHO relevant. I belive this argument has already been decided and the IAB and IESG will not accept further specifications that are based on the use of the TXT RR with the singular exception for MARID for the well know reasons outlined in the San Diego meetings. >I believe the answer to those four points can all be >different. > > > > > > I've often thought it was time to start thinking of > > using NAPTR records for > > such things as PKI since the represent the most > > powerful and flex able RR > > records we have as in for instance and now would be > > a good time to start > > using them as in, for example. > >Above and beyond relevance of the feature-set of NAPTR >to this application, is the question of whether >indirection through the DNS to a TCP based content >server create too high an impact on the Internet at >large. Please ... see RFC 3761. If we have agreed we are using the DNS to essentially set up every phone call on the planet ( two look ups BTW, TN to URI and then URI to SRV ) and our bizarre friends in the product goods industry have decided they want to do a DNS look up ( the Object Name Service) to find product information on every soup can on earth.... http://www.epcglobalus.org/Network/how_works.html have already overloaded the Internet at large and additional look ups for PKI material is not going to do any more damage. >Some claim that even a single additional DNS lookup >imposed by this and similar systems (SPF, SENDER-ID) >create an as-yet unknown and possibly unacceptable >load on the DNS infrastructure. In that context, >adding a TCP lookup on top of an additional DNS lookup >adds quiet a load. again if the DNS is broken its already WAY WAY broken and indeed you are correct the MARID specifications add several orders of magnitude to the problem ..but that said I think the general sense of the DNS Ops and Ext community has been enough is enough and requirements for additional key material stored in the DNS itself must prove its case to a very very high level . Conclusion its time to recognize the need for pointers for these types of objects and NAPTR records represents the most flexible and extensible RR we have for that. Yes and NAPTR's work ..the support is already in all the DNS reference models and resolvers. >Regards. My pleasure. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --=====================_18954915==.ALT Content-Type: text/html; charset="us-ascii" At 08:04 PM 8/30/2004, domainkeys-feedbackbase01@yahoo.com wrote:


--- Richard Shockey <richard@shockey.us> wrote:

> On a related subject ..I'm assuming that there is
> already general consensus
> that the use of TXT for storing public keys as
> described
>
>
http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt
>
> shall be considered harmful.

I don't think that's entirely clear at all.

It depends on whether you're asking the question as to
whether DNS is the right place for storing such
material in the short or long term and whether TXT is
the right type in the short or long term.

What I'm saying is that A. the DNS is NOT the right place for directly storing such material period irrespective of the underlying RR. This was the principal problem we saw in the DNSSEC debates and that time it was made quite clear that cryptographic material not directly related to the proper, secure functioning of the DNS should not be stored in the DNS.

The short term vs long term issues are IMHO relevant. I belive this argument has already been decided and the IAB and IESG will not accept further specifications that are based on the use of the TXT RR with the singular exception for MARID for the well know reasons outlined in the San Diego meetings.


I believe the answer to those four points can all be
different.


>
> I've often thought it was time to start thinking of
> using NAPTR records for
> such things as PKI since the represent the most
> powerful and flex able RR
> records we have as in for instance and now would be
> a good time to start
> using them as in, for example.

Above and beyond relevance of the feature-set of NAPTR
to this application, is the question of whether
indirection through the DNS to a TCP based content
server create too high an impact on the Internet at
large.

Please ... see RFC 3761. If we have agreed we are using the DNS to essentially set up every phone call on the planet ( two look ups BTW, TN to URI and then URI to SRV ) and our bizarre friends in the product goods industry have decided they want to do a DNS look up ( the Object Name Service) to find product information on every soup can on earth....

http://www.epcglobalus.org/Network/how_works.html

have already overloaded the Internet at large and additional look ups for PKI material is not going to do any more damage.


Some claim that even a single additional DNS lookup
imposed by this and similar systems (SPF, SENDER-ID)
create an as-yet unknown and possibly unacceptable
load on the DNS infrastructure. In that context,
adding a TCP lookup on top of an additional DNS lookup
adds quiet a load.

again if the DNS is broken its already WAY WAY broken and indeed you are correct the MARID specifications add several orders of magnitude to the problem ..but that said I think the general sense of the DNS Ops and Ext community has been enough is enough and requirements for additional key material stored in the DNS itself must prove its case to a very very high level .

Conclusion its time to recognize the need for pointers for these types of objects and NAPTR records represents the most flexible and extensible RR we have for that.

Yes and NAPTR's work ..the support is already in all the DNS reference models and resolvers.



Regards.

My pleasure.



>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141@fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 --=====================_18954915==.ALT-- From owner-ietf-mailsig Mon Aug 30 15:44:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UMiFVt032332 for ; Mon, 30 Aug 2004 15:44:15 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UMiFfc032331 for ietf-mailsig-skb; Mon, 30 Aug 2004 15:44:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from web40405.mail.yahoo.com (web40405.mail.yahoo.com [66.218.78.102]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7UMiFPu032304 for ; Mon, 30 Aug 2004 15:44:15 -0700 (PDT) (envelope-from domainkeys-feedbackbase01@yahoo.com) Message-ID: <20040830224415.2177.qmail@web40405.mail.yahoo.com> Received: from [216.145.52.229] by web40405.mail.yahoo.com via HTTP; Mon, 30 Aug 2004 15:44:15 PDT Date: Mon, 30 Aug 2004 15:44:15 -0700 (PDT) From: Reply-To: domainkeys-feedbackbase01@yahoo.com Subject: Re: Anonymous signed mail To: ietf-mailsig@imc.org In-Reply-To: <6.1.0.6.2.20040830172010.04c04070@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Richard Shockey wrote: > NAPTR > >to this application, is the question of whether > >indirection through the DNS to a TCP based content > >server create too high an impact on the Internet at > >large. > > Please ... see RFC 3761. If we have agreed we are > using the DNS to > essentially set up every phone call on the planet ( > two look ups BTW, TN to > URI and then URI to SRV ) and our bizarre friends in > the product goods > industry have decided they want to do a DNS look up > ( the Object Name > Service) to find product information on every soup > can on earth.... > > http://www.epcglobalus.org/Network/how_works.html > > have already overloaded the Internet at large and > additional look ups for "have already overloaded the Internet at large"? I was not aware that E.NUM and EPC already have wide-scale deployment and queries at anything approaching the rate the current email infrastructure will generate. I see no evidence that anyone knows for sure what the load impact will be. Even so, my point was not questioning the DNS infrastructure issue, it was raising the implications of NAPTR: namely that your redirection example implies a TCP query in addition to DNS queries for every key lookup. The ramp-up of a non-existent infrastructure to support the possible TCP query rate does concern me a lot - which is precisely why we suggest using TXT as a starting trial point with every intention of moving to something "sanctified" in the long-term. Regards. From owner-ietf-mailsig Mon Aug 30 15:58:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UMwSXU034990 for ; Mon, 30 Aug 2004 15:58:28 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UMwSsG034989 for ietf-mailsig-skb; Mon, 30 Aug 2004 15:58:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UMwSEi034981 for ; Mon, 30 Aug 2004 15:58:28 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 30 Aug 2004 18:58:25 -0400 id 0015FA77.4133B111.00000F32 In-Reply-To: <6.1.0.6.2.20040830172010.04c04070@joy.songbird.com> References: <6.1.0.6.2.20040830154858.04806eb0@joy.songbird.com> <20040830204744.29948.qmail@web40401.mail.yahoo.com> <6.1.0.6.2.20040830172010.04c04070@joy.songbird.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <178A7A8C-FAD8-11D8-94D9-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: ietf-mailsig@imc.org From: Andrew Newton Subject: Re: Anonymous signed mail Date: Mon, 30 Aug 2004 18:58:22 -0400 To: Richard Shockey X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Aug 30, 2004, at 5:58 PM, Richard Shockey wrote: > I belive this argument has already been decided and the IAB and IESG > will not accept further specifications that are based on the use of > the TXT RR with the singular exception for MARID for the well know > reasons outlined in the San Diego meetings. I hope this is true. > again if the DNS is broken its already WAY WAY broken and indeed you > are correct the MARID specifications add several orders of magnitude > to the problem ..but that said I think the general sense of the DNS > Ops and Ext community has been enough is enough and requirements for > additional key material stored in the DNS itself must prove its case > to a very very high level . what about sshfp? > Yes and NAPTR's work ..the support is already in all the DNS > reference models and resolvers. NAPTR's are good. Another possibility is a new modifier (pointing to the place where the key material) in existing SPF records. There are two benefits of putting the key material in DNS: 1) everybody is already running DNS, and 2) if it is small enough, it is lickity-split fast. If it can't fit into a DNS packet, I actually favor an ESMTP extension for dialback use. This means no new DNS records of any type, no additional records, etc... I've talked to some email hosting providers that have a fairly big hill to climb around the administration of adding another record (its type doesn't matter). Their issue is that forward DNS is under the control of another entity and just getting the MX to point to the right place is headache. -andy From owner-ietf-mailsig Mon Aug 30 16:23:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UNNa9v038127 for ; Mon, 30 Aug 2004 16:23:36 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UNNa4L038126 for ietf-mailsig-skb; Mon, 30 Aug 2004 16:23:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UNNZ9Q038120 for ; Mon, 30 Aug 2004 16:23:35 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7UNWbTF025491; Mon, 30 Aug 2004 16:32:37 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7UNWbl8025488; Mon, 30 Aug 2004 16:32:37 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 30 Aug 2004 16:32:37 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: ietf-mailsig@imc.org Subject: Re: Anonymous signed mail In-Reply-To: <178A7A8C-FAD8-11D8-94D9-000A95B3BA44@hxr.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 30 Aug 2004, Andrew Newton wrote: > On Aug 30, 2004, at 5:58 PM, Richard Shockey wrote: > > I belive this argument has already been decided and the IAB and IESG > > will not accept further specifications that are based on the use of > > the TXT RR with the singular exception for MARID for the well know > > reasons outlined in the San Diego meetings. > > I hope this is true. I also hope that we'll stop abusing TXT records and either create new or use other appropriate DNS record types or new protocol. I would point out that there is no necessity to actually use DNS pointer at all and that pointer to correct root certificate or public key can be part of the signature itself (as I did with Certificate-Verification-Service header or S/MIME attribute in MTA Signatures draft) and this allows to support multiple schemes of verifying signatures and/or obtaining public key at the same time (one can be through http and one through dns for example) and support for slow upgrade paths to new verification methods in the future. We do still need an optional way to identity of domain or MTAs that are ALWAYS using signature mechanism to be able to reject email that is supposed to be signed but was not (for this mail policy record such as SFP can be good fit). > If it can't fit into a DNS packet, I actually favor an ESMTP extension > for dialback use. I would generally be opposed to SMTP Callback, it does not buy us anything that we can't do with one of the other protocols which could potentially be developed in eithier way. HTTP XML based protocol extensions could work better and be lot more extendeable. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mailsig Mon Aug 30 17:02:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V02meR039870 for ; Mon, 30 Aug 2004 17:02:48 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V02m4M039869 for ietf-mailsig-skb; Mon, 30 Aug 2004 17:02:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V02mHc039862 for ; Mon, 30 Aug 2004 17:02:48 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 30 Aug 2004 20:02:50 -0400 id 0015FA73.4133C02B.000013D2 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <17E0E91E-FAE1-11D8-94D9-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: ietf-mailsig@imc.org From: Andrew Newton Subject: Re: Anonymous signed mail Date: Mon, 30 Aug 2004 20:02:48 -0400 To: "william(at)elan.net" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Aug 30, 2004, at 7:32 PM, william(at)elan.net wrote: > I would generally be opposed to SMTP Callback, it does not buy us > anything > that we can't do with one of the other protocols which could > potentially > be developed in eithier way. HTTP XML based protocol extensions could > work > better and be lot more extendeable. Who says that an SMTP callback can't hand back XML? How is HTTP more extensible than SMTP? The point of an SMTP callback is that only one service gets modified and no new DNS records need to be added. With an HTTP service, you need a new DNS record (SPF, NAPTR, SRV, or SHINEY-NEW) and you either need a new HTTP service or modify the existing one. -andy From owner-ietf-mailsig Mon Aug 30 18:09:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V19gAb045650 for ; Mon, 30 Aug 2004 18:09:42 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V19gcb045649 for ietf-mailsig-skb; Mon, 30 Aug 2004 18:09:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V19foX045643 for ; Mon, 30 Aug 2004 18:09:41 -0700 (PDT) (envelope-from richard@shockey.us) Received: from RSHOCKEY-LTXP.shockey.us (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7V19ic06790; Mon, 30 Aug 2004 18:09:44 -0700 Message-Id: <6.1.0.6.2.20040830205943.04ff40c0@joy.songbird.com> X-Sender: richard@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 30 Aug 2004 21:09:25 -0400 To: domainkeys-feedbackbase01@yahoo.com, ietf-mailsig@imc.org From: Richard Shockey Subject: Re: Anonymous signed mail In-Reply-To: <20040830224415.2177.qmail@web40405.mail.yahoo.com> References: <6.1.0.6.2.20040830172010.04c04070@joy.songbird.com> <20040830224415.2177.qmail@web40405.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 06:44 PM 8/30/2004, domainkeys-feedbackbase01@yahoo.com wrote: >--- Richard Shockey wrote: > > > NAPTR > > >to this application, is the question of whether > > >indirection through the DNS to a TCP based content > > >server create too high an impact on the Internet at > > >large. > > > > > > have already overloaded the Internet at large and > > additional look ups for > >"have already overloaded the Internet at large"? I was >not aware that E.NUM and EPC already have wide-scale >deployment and queries at anything approaching the >rate the current email infrastructure will generate. I agree but watch out .. these are protocols in nascent stages of deployment and could increase dramatically within 24 months. Look at SIP based VoIP itself ..it is clearly beginning an exponential growth curve. TN to URI mapping is now inevitable. >I see no evidence that anyone knows for sure what the >load impact will be. Even so, my point was not >questioning the DNS infrastructure issue, it was >raising the implications of NAPTR: namely that your >redirection example implies a TCP query in addition to >DNS queries for every key lookup. I believe it is worth exploration and needs to be put on the table of options to consider when the WG is formally charted which is my ultimate point. I'm convinced the use of TXT will be considered "harmful" by the IESG and this is clearly the point in time where alternatives must be explored. >The ramp-up of a non-existent infrastructure to >support the possible TCP query rate does concern me a >lot - which is precisely why we suggest using TXT as a >starting trial point with every intention of moving to >something "sanctified" in the long-term. were we to live in a perfect world ... I'm very afraid of the issue we see MARID concluding on ..we use TXT "for now" but the historical record indicates once you put it in place it will be nearly impossible to remove it from the system. >Regards. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From owner-ietf-mailsig Tue Aug 31 00:47:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V7lKZs025304 for ; Tue, 31 Aug 2004 00:47:20 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V7lKuw025303 for ietf-mailsig-skb; Tue, 31 Aug 2004 00:47:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from web40402.mail.yahoo.com (web40402.mail.yahoo.com [66.218.78.99]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7V7lKaP025275 for ; Tue, 31 Aug 2004 00:47:20 -0700 (PDT) (envelope-from domainkeys-feedbackbase01@yahoo.com) Message-ID: <20040831074716.16062.qmail@web40402.mail.yahoo.com> Received: from [64.142.52.9] by web40402.mail.yahoo.com via HTTP; Tue, 31 Aug 2004 00:47:16 PDT Date: Tue, 31 Aug 2004 00:47:16 -0700 (PDT) From: Reply-To: domainkeys-feedbackbase01@yahoo.com Subject: Re: Anonymous signed mail To: mailsig In-Reply-To: <6.1.0.6.2.20040830205943.04ff40c0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Richard Shockey wrote: > >I see no evidence that anyone knows for sure what > the > >load impact will be. Even so, my point was not > >questioning the DNS infrastructure issue, it was > >raising the implications of NAPTR: namely that your > >redirection example implies a TCP query in addition > to > >DNS queries for every key lookup. > > I believe it is worth exploration and needs to be > put on the table of > options to consider when the WG is formally charted > which is my ultimate > point. I totally agree. I'm no doubt jumping the gun here, but my "gut" feel is that a combo of DNS for high volume queries and "some other probably TCP mechanism" might be appropriate for low volume queries - such as per-user key lookups? But who knows? In ten years, the cost of a TCP connection may be moot? > >lot - which is precisely why we suggest using TXT > as a > >starting trial point with every intention of moving > to > >something "sanctified" in the long-term. > > were we to live in a perfect world ... > > I'm very afraid of the issue we see MARID concluding > on ..we use TXT "for > now" but the historical record indicates once you > put it in place it will > be nearly impossible to remove it from the system. That is a risk, for sure. One thought is that if TXT is so bad, then the pressure to remove the experimental phase will be high. Conversely, if no one cares enough, then who cares if it stays in TXT? Nonetheless, let me make it very clear that I perceive TXT as an evil, but necessary expedient that should have as short a life-span as possible. I have zero motivation for staying in TXT apart from short-term pragmatic reasons. Whilst I don't feel the same urgency that the MARID folk feel - to wait for a new DNS type or a new infrastructure rollout prior to any field tests seems to me an unreasonable burden that serves no real purpose. The middle ground seems to me that we need field tests to refine ideas and there are some risks that the field tests might stick. That seems like a lesser risk than designing perfection in a vacuum. Mark. From owner-ietf-mailsig Tue Aug 31 00:57:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V7v0Zc027791 for ; Tue, 31 Aug 2004 00:57:00 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V7v0ad027790 for ietf-mailsig-skb; Tue, 31 Aug 2004 00:57:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from web40414.mail.yahoo.com (web40414.mail.yahoo.com [66.218.78.111]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7V7uxee027754 for ; Tue, 31 Aug 2004 00:56:59 -0700 (PDT) (envelope-from domainkeys-feedbackbase01@yahoo.com) Message-ID: <20040831075653.16422.qmail@web40414.mail.yahoo.com> Received: from [64.142.52.9] by web40414.mail.yahoo.com via HTTP; Tue, 31 Aug 2004 00:56:53 PDT Date: Tue, 31 Aug 2004 00:56:53 -0700 (PDT) From: Reply-To: domainkeys-feedbackbase01@yahoo.com Subject: Re: Anonymous signed mail To: mailsig In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- "william(at)elan.net" wrote: > We do still need an optional way to > identity of domain or MTAs > that are ALWAYS using signature mechanism to be able > to reject email that > is supposed to be signed but was not (for this mail > policy record such as > SFP can be good fit). FWIW. I've tried to make it as clear as I can that policy is entirely a generic matter and that if, eg, SPF were to create a place-holder for mailSIG I would try and adopt it in an instant. In fact, about 3-4 months ago I sent Meng Wong a technical proposal that would incorporate DomainKeys policy in SPF. It would trivially adapt to any mailsig solution. Bottom line? I want to get out of policy. It's a big issue that I don't feel competent to address. Mailsig needs to know that its output will be used for policy, but in general, mailsig is subservient to policy. Regards. From owner-ietf-mailsig Tue Aug 31 10:09:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VH9fIw040152 for ; Tue, 31 Aug 2004 10:09:41 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VH9ftN040151 for ietf-mailsig-skb; Tue, 31 Aug 2004 10:09:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VH9fcu040131 for ; Tue, 31 Aug 2004 10:09:41 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 31 Aug 2004 10:09:53 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7VH9Tt2000095 for ; Tue, 31 Aug 2004 10:09:30 -0700 (PDT) Received: from fenton-w2k01.cisco.com (stealth-10-32-245-98.cisco.com [10.32.245.98]) by imail.cisco.com (8.12.5/8.12.10) with SMTP id i7VHDTkZ004207 for ; Tue, 31 Aug 2004 10:13:29 -0700 Message-Id: <4.3.2.7.2.20040831100340.0408dc10@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Aug 2004 10:09:37 -0700 To: ietf-mailsig@imc.org From: Jim Fenton Subject: Draft minutes for MASS BoF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-IMAIL-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1093972410.566183"; x:"432000"; a:"rsa-sha1"; b:"0:15267"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"Ad6XbgJxcFr21MZyDpqhdmCpWJWrQe6JRsqF5/yv4bQoTDOk2XUOopUcRfEdP" "WI/htUzMhHCwdG2HeiWxP+AwslutITLqBbrVwIYRQMWIuUnmhNVqSS7YiHlk9" "oDagw89L1aIUCA0qx9nsPyxvGI3sC810DmF5gzG+b8shFAsYc="; c:"Date: Tue, 31 Aug 2004 10:09:37 -0700"; c:"From: Jim Fenton "; c:"Subject: Draft minutes for MASS BoF" X-IMAIL-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com" Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In the nick of time, here are the draft minutes from the MASS BoF in San Diego. Please let me know if you have any corrections; I will send these in to the Secretariat in a couple of days. We do have an opportunity to send corrections until 17 September so feel free to send me corrections even if it's not in the next couple of days. -Jim Minutes of the Message Authentication Signature Standards (MASS) BoF, 60th IETF, held Thursday, 5 August 2004, 0900 - 1130 PDT Chairs: Nathaniel Borenstein Jim Fenton Scribe: Dan Wing Jabber Log: http://www.xmpp.org/ietf-logs/mass@ietf.xmpp.org/2004-08-05.html 1. Agenda Bashing and Introduction Nathaniel Borenstein presented a list of goals and non-goals for the proposed Working Group, and the positioning of MASS with respect to the work being done in the MARID WG. Many of the goals are the same as those of MARID, but would be accomplished by means of a signature attached to each message rather than an IP address check; it is a different form of evidence and in many ways complementary to MARID. There are a number of areas where MARID and MASS may use common mechanisms, such as marking of messages to indicate the verification result. Brief descriptions of seven such proposals were to be presented. Rohan Mahy suggested we first discuss the draft WG charter, which was shown for information, but there was not consensus to discuss it prior to the proposal overviews. 2. Representative Proposals 2.1 DomainKeys (Mark Delany) DomainKeys is a signature-based technique designed to be as transparent as possible to existing infrastructure. Public keys used by the domain are stored in DNS TXT records (e.g., 200401._domainkey.example.net IN TXT "g=;k-rsa;p=MHww...IDAQAB"). The signature is stored in an RFC2822 header, DomainKey-Signature. Several methods of canonicalization to minimize message breakage are being tried out. Some senders might want to be more liberal than others. There are 4 Corporate Dev Consulting Eng independent implementations based on the -00 specification, including a sendmail milter available on Sourceforge and a qmail patch. A -01 revision to the draft is due out in a few days. Q: Why not use S/MIME? A: Yahoo, for example, can't suddenly start sending S/MIME without generating complaints from users that aren't expecting it. One large ISP had said that if 1% of users complains, the support costs would be in the millions of dollars. Another problem is that many mailing lists can't handle S/MIME encapsulated SUBSCRIBE and UNSUBSCRIBE messages. Q: The draft says 'no derivative works allowed'; will you give IETF change control? A: Yes. [Floor closed to further questions until presentations are complete] 2.2 Identified Internet Mail (Jim Fenton) Identified Internet Mail (IIM) is similar to DomainKeys; the primary difference is that the public key is sent in the message itself and DNS is used to find the authorization of the key. It explicitly supports both user- and domain-level signatures. The originator can decide which headers to include in the signature, and copies of the signed headers are included with the signature. Signing and verification normally happens in MTAs, although possible to do in an MUA as well. A header has been defined to convey the results of verification from an MTA to the MUA (or to a later MTA). User level keys are important for "affinity domains" like ieee.org, and outsourced functions like benefits@example.com where someone outside the domain needs to send messages using a specific address. Many domains won't support user-level keying because they don't need them and/or want to force outgoing messages through their own MTAs for archiving, compliance checking, virus scanning. Many domains will have only domain-level keys, and some will have some user-level keys and a few will key entirely at the user level. The -00 draft (draft-fenton-identified-mail-00) was published in June, and a few changes have been made since. One is the ability to sign a portion of the body, to allow some mailing lists to append to the message. Also, the Sender: or From: address will be used rather than envelope-from as in the original draft. 2.3 E-mail Postmarks (Jim Lyon) The goal is to have a domain attach a signature to a message, attesting that the mess has passed through the official mail servers of the domain and perhaps attest to other things we well. This proposal uses S/MIME because many MTAs munge headers (reorder, remove, etc.) and whitespace changes, character mapping, MIME delimiter rewriting, format conversion, HTML sanitization, etc. Many MTAs are trained not to modify messages with content-type=multipart/signed. Many MUAs (but not all) have been trained to use S/MIME. Messages which have been signed by the user and signed again by the domain can be handled correctly. For more information, see http://www.lessspam.org/EmailPostmarks.pdf Q: Does Microsoft claim any IPR on this? A: Don't know. The original author is on LOA. 2.4 Entity to entity S/MIME (Phillip Hallam-Baker) The banks are being impersonated in phishing attacks; and if they won't use S/MIME, who will? The goal here is to make it easy and free to sign email, and get past the S/MIME vs. PGP standards war. The Draft (draft-hallambaker-entity-00) describes the problems with S/MIME in detail. Rather than put user-level information (such as keys) in DNS, it's a better idea to have a DNS entry point to a server which contains user keys. XKMS 2.0 is a W3C candidate recommendation which might be used as a repository to check signatures. Some alternatives are WS-Trust (which only does part of XKMS), SCVP (delivers X.509 certificates), or something new (which will take a long time). We should keep the key management piece out of the charter. 2.5 MTA Signatures (William Leibzon) William looked at S/MIME and PGP as mechanisms to attach a signature; S/MIME was chosen because it was more extensible. It would be desirable to use one of these mechanisms automatically, but it's important that these new signatures be confused with existing signatures. Two ways this could be done with S/MIME are to invent a new MIME type or embed the signature as part of an unknown multipart MIME type. Decided to create a new MIME type, multipart/x-postal-data. Since only the body is signed, headers to be signed would need to be copied into the body to be signed there. Since S/MIME depends on the use of certificates, a new method of signature verification is proposed. The X-Certificate-Verification-Service provides a number of ways (http, ftp, etc.) the signature can be verified. It's also possible to determine if mail from a given domain should always be signed. 2.6 Bounce Address Tag Validation (Dave Crocker) BATV uses similar technology to previous presentations, but solves a different problem. The idea is to digitally sign the MAIL FROM address by putting a signature into the left side (local part) of the address. There is a hard limit of 64 bytes for the local part; we want everyone throughout the mail system to be able to find the local part so an address like mailbox@example.com would map into batv-mailbox/scheme/parms@example.com . The goal is for the receiver of a bounce to be able to determine if it's a bad bounce. You should be able to look at the address and determine if MAIL FROM is forged; if so, it's likely that the rest of the message is forged as well. There are very serious replay protection issues, but this isn't trying to be a perfect solution. 2.7 Trusted Email Open Standard (John Levine) [There were no slides for this presentation; this describes a white paper at http://eprivacygroup.net] TEOS is implemented as a commercial product known as Postiva. It takes a digest of the message, some information from the headers, and assertions from the sender, puts it in XML, signs the XML, and puts all of that into a header. The recipient sees the header, gets the key of the sending domain, and validates the XML. The MUA can display this to the user. Q: Is there IPR around this? A: There are patents pending, but the head of the company is committed to giving open-source compatible licenses. 3. Issues for WG to resolve These include: Signature encapsulation key management canonicalization Behavior through mailing lists Q: (Rohan Mahy) Need to decide the requirements on backward compatibility and what the scope is. The chair agreed. Q: (Eric Rescorla) Why do you think this will work? The chair (Nathaniel) ruled this out of scope; different technologies presented here will work in different threat models. Agreed that we need to make the response to threats explicit. A: (Jim Fenton) There is a threat discussion in the draft I co-authored. Q: (Rand Wacker) Does "behavior through mailing lists" mean survival of messages through mailing lists, or what mailing lists should do? A: Both Q: (Mike Thomas) The charter should address the key transport issue. DNS was alluded to, but we need to be clearer in the charter. 4. WG Name Two names were proposed: Message Authentication Signature Standards (MASS) and Signatures for Transport Recognition of Imposture in Viral Email and Repugnant Spam (STRIVERS). Ted Hardie suggested we just call it "HUM". 5. Deliverables A list of deliverables was presented (extensions to SMTP, etc.) on slide 17. Comments on the list of deliverables: - (Ted Hardie) Need to clarify is his is to work with MTAs or SUBMIT servers. Need to determine which M*A entities need to sign. - (Dave Crocker) This is about message contents, why refer to SMTP at all? - (Dave Crocker) Delivering the signature along with the message constrains the behavior of the working group. - (Jim Lyon) MUA behavior needs to be discussed. - (Chris Lonvick) Clarify whether non-email messaging is in scope. - (Rand Wacker) Clarify who can/should check these signatures - (Phillip Hallam-Baker) Define how this will work with legacy MTAs that are routinely broken and mangle bits. - (Mike Thomas) Need to define encapsulation and canonicalization in messages, and a way of checking the authorization of the message. These are disjoint problems. - (Randy Gellans) Dave Crocker's proposal is somewhat different from the others; need to determine if it is in scope. If so, the deliverables are too restrictive. - (Randy Gellans) Need to clarify if signing is done at SUBMIT agents or MTAs, since SUBMIT agents are the only entities that determine authorization. 6. Threat Model (Jim Fenton) Two main kinds of threats, phishing (fraud) characterized by large financial losses to the affected domains, and spam, characterized by small losses to virtually everyone. Human-engineered look-alike domains will remain a problem for phishing attacks. Accreditation and reputation services will be required (especially for spam) to indicate whether the address is well-behaved. Q: (Eric Burger) S/MIME isn't working because of the need to update clients, send keys, etc,; how is this different? A: Most of these proposals don't require MUA changes; the MTA would typically do the authorization check for you. And S/MIME solved a different problem. Q: (Eric Rescorla et al) Why do you think this will work with phishing? Phishing works because of social engineering; a domain looks like paypal.com, but isn't paypal.com. The phisher could send with paypal1.com. We need an estimate for how much phishing would be reduced by any of these proposals. A: Allows banks to say "look carefully at the domain" (which won't be 100% effective). While it's dangerous to cite current behavior, something like 95% of phishing emails are currently spoofed. They use spoofed addresses because they're more effective than other human-engineered addresses. But if the domain is socially engineered, this can't solve the problem by itself. Q: (Ted Hardie) Should we really consider reputation to be out of scope for this WG? A: We're trying to divide-and-conquer. Q: (Rohan Mahy) Do you intend the product of this WG to be standards-track, BCP, informational, or experimental? A: Standards-track Q: (Rohan Mahy) Need to describe the problem you're solving, and how well. A: How about "preventing spoofing of known domains, but not socially engineered ones". Q: There is overlap between MARID and MASS. Describe why MARID doesn't solve the problem. A: Potential commonalities include PRA, message marking, and accreditation. (Phillip Hallam-Baker): Accreditation is important, but we shouldn't be describing how to do accreditation, but rather how to link to it. (Dave Crocker) Concerned that the BoF is ignoring important issues; need to make sure that we're not reacting just to today's spammer behavior. MTA-to-MTA use of S/MIME and PGP has been done and works fine, but there is difficulty in managing the keys. It is useful to sign messages independently of phishing and spam. But we need to understand how the current proposals do a better job than PGP and S/MIME. (Cullen Jennings) The requirements need to be at the "reduce spam or phishing" level, not at the "prevent spoofing one header" level. (Dave Crocker) Responding to Ted on accreditation services, any such system has to be based on an identity you believe. What we're building is the foundation for such a system. (Nathaniel) Requirements discussion will need to be finished on the mailing list. (Phillip Hallam-Baker) Phishing is getting more sophisticated, using trojans. We should concentrate on domain-level security, where we have been successful in the past (SSL, padlock icon, etc.) (Mike Thomas) Once we have a way to detect forgery, the spammers and frauds will need to get throw-away domains. Domain-level reputation may have legal problems we're not aware of. Divide the problem and deal with authorization first, and later on accreditation. (Jim Fenton) 1. Will a crypto approach without accreditation be beneficial? Yes. 2. Would accreditation fragment this group? Perhaps. 3. This BoF is under Security, not applications. Accreditation seems more like an applications-area problem. (Marcus Leech) This won't work for traffic originating within someone's network via trojans. (Phillip Hallam-Baker) The big issue is the message encapsulation formats; that's where these proposals differ in substance. S/MIME vs. headers, and need to find what types of canonicalization work and which don't. 7. Conclusion Word-smithing the charter will be done on the mailing list, which is ietf-mailsig@imc.org (see http://www.imc.org/ietf-mailsig/) Consensus via hum that effort in this area should go forward. (Russell Housley/Steve Bellovin) We need a threat and requirements document, but one that makes hard decisions and isn't just the union of everyone's requirements. From owner-ietf-mailsig Tue Aug 31 15:53:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VMrt9u007930 for ; Tue, 31 Aug 2004 15:53:55 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VMrtMH007929 for ietf-mailsig-skb; Tue, 31 Aug 2004 15:53:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VMrsLf007922 for ; Tue, 31 Aug 2004 15:53:54 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i7VN3Aoq008578 for ; Tue, 31 Aug 2004 16:03:10 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i7VN3Ad2008575 for ; Tue, 31 Aug 2004 16:03:10 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 31 Aug 2004 16:03:10 -0700 (PDT) From: "william(at)elan.net" To: ietf-mailsig@imc.org Subject: Early work on mail server signatures Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As I just posted to MARID, early work on header-based mail server signatures and signing of entire email (yahoo like) can be found in this paper: http://www.chaoszone.org/misc/spam.html This can proof quite usefull in the future as reference of prior work if we have the same problems as MARID currently does with somebody improperly claiming patent rights and creating problems with protocol deployment with restrictive implementation licensing requirements. (This link came from my old my asrg summary at: http://www.elan.net/~william/asrg/asrg-may2003-summary.htm but I totally forgot about it and actually since its not a link to asrg archive I may have found out about it in some other way) --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mailsig Tue Sep 7 03:11:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87AB5fS092510 for ; Tue, 7 Sep 2004 03:11:05 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87AB5gv092509 for ietf-mailsig-skb; Tue, 7 Sep 2004 03:11:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87AB5a8092502 for ; Tue, 7 Sep 2004 03:11:05 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i87AB4a13925; Tue, 7 Sep 2004 03:11:05 -0700 Date: Tue, 7 Sep 2004 19:10:53 +0900 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <167502538.20040907191053@brandenburg.com> To: ietf-mailsig@imc.org CC: John Levine , Tony Finch , Sam Silberman Subject: at last: draft-levine-mass-batv-00 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, We have finally posted the initial, honest-to-goodness specification of BATV. It is much more constrained that the "description" that I posted some time ago, but it also is complete, qualifying as a specification. > Abstract > > The envelope of Internet mail contains an RFC2821.MailFrom command, > which may supply an address to be used as the recipient of > transmission and delivery notices about the original message. > Existing Internet mail permits unauthorized use of addresses in the > MailFrom command, causing notices to be sent to unwitting and > unwilling recipients. Bounce Address Tag Validation (BATV) defines > an extensible mechanism for validating the MailFrom address. It also > defines an initial use of that mechanism which requires no > administrative overhead and no global implementation. In case you simply cannot wait for the Internet-Draft folks to announce it, you can find it at: d/ ----- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA ; From owner-ietf-mailsig Tue Sep 7 05:52:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87CqSr6024215 for ; Tue, 7 Sep 2004 05:52:28 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87CqS33024214 for ietf-mailsig-skb; Tue, 7 Sep 2004 05:52:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87CqR8K024201 for ; Tue, 7 Sep 2004 05:52:27 -0700 (PDT) (envelope-from mike@mtcc.com) Received: from mtcc.com.mtcc.com (fasolt.mtcc.com [216.102.208.10]) by mtcc.com (8.12.10/8.12.10) with ESMTP id i87Cq3xq015281; Tue, 7 Sep 2004 05:52:03 -0700 From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16701.44787.905804.971494@mtcc.com> Date: Tue, 7 Sep 2004 05:52:03 -0700 To: Dave Crocker Cc: ietf-mailsig@imc.org, John Levine , Tony Finch , Sam Silberman Subject: at last: draft-levine-mass-batv-00 In-Reply-To: <167502538.20040907191053@brandenburg.com> References: <167502538.20040907191053@brandenburg.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! IIM-SIG: v:"1"; h:"fasolt.mtcc.com"; d:"mtcc.com"; z:"home"; m:"krs"; t:"1094561524.381526"; x:"432000"; a:"rsa-sha1"; b:"0:2412"; e:"Iw=="; n:"nVv0qboMtb/jcj1UT0mvfTvYyyFXXGzpd98dYJEDa/uux2xfeB+A0e9dSQ07c" "42LbmgdqdIvWuQzlXIdGJ77Qy9oz3RP5a38E2H5O9oPfQNGtaKOiJ6/gELwFy" "6wij+H/UTnHFcKILxF9lBlB7xIoFrXH675Blkho/iM/LDLxNk="; s:"EFpcMWhp8ClrhOH2mZkJ4bSDLzYCH518IWxRdrp2UkrOrSfzYaR4XZnBXe2+A" "IIWGltYVUBP5NZedrLZg17Prn3nSu9QjKh7PnMNLXQvvhBZw/zXKV/0pmQ6gE" "WAoD5lr5uj6GOtU1chT22I3375XLNPHxLmEpMBrsNzy8KAwGM="; c:"From: Michael Thomas "; c:"Date: Tue, 7 Sep 2004 05:52:03 -0700"; c:"Subject: at last: draft-levine-mass-batv-00" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"fasolt.mtcc.com"; c:"message from fasolt.mtcc.com verified; " Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave -- Perhaps it's not obvious, but the identified mail draft can also support the functionality you're after here with BATV. It's essentially a matter of inspecting the bounce at the purported home of the bounce of the bounced message itself and doing the normal anti-forgery KRS check. These reflection attacks, after all, are simply forgery attacks that you wish had been discarded at the bounce relay. What I'm not convinced is that as instantiated it is _robust_ enough. The bounce relays I tried dutifully copy all of the bytes of the bounced message, but I don't think that's a great assumption (don't some bounce generators truncate after some configurable number of bytes?) Also: they may well not all be mime bounces, etc, etc. My general take is that as a requirement the base MASS protocol MUST provide bounce reflection attack protection. I'm not sure why you'd need a separate mechanism, if that is indeed what you're proposing. Mike Dave Crocker writes: > > Folks, > > We have finally posted the initial, honest-to-goodness specification > of BATV. It is much more constrained that the "description" that I > posted some time ago, but it also is complete, qualifying as a > specification. > > > > Abstract > > > > The envelope of Internet mail contains an RFC2821.MailFrom command, > > which may supply an address to be used as the recipient of > > transmission and delivery notices about the original message. > > Existing Internet mail permits unauthorized use of addresses in the > > MailFrom command, causing notices to be sent to unwitting and > > unwilling recipients. Bounce Address Tag Validation (BATV) defines > > an extensible mechanism for validating the MailFrom address. It also > > defines an initial use of that mechanism which requires no > > administrative overhead and no global implementation. > > > In case you simply cannot wait for the Internet-Draft folks to > announce it, you can find it at: > > > > > d/ > ----- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA ; From owner-ietf-mailsig Tue Sep 7 06:38:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87DcRrT029009 for ; Tue, 7 Sep 2004 06:38:27 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87DcRdw029008 for ietf-mailsig-skb; Tue, 7 Sep 2004 06:38:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87DcQZb029001 for ; Tue, 7 Sep 2004 06:38:26 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:54864) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp (Exim 4.34) id 1C4gAp-0003rm-TK (return-path fanf2@hermes.cam.ac.uk) for ietf-mailsig@imc.org; Tue, 07 Sep 2004 14:38:15 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4gAp-0003C1-Lr; Tue, 07 Sep 2004 14:38:15 +0100 Date: Tue, 7 Sep 2004 14:38:15 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Michael Thomas cc: Dave Crocker , ietf-mailsig@imc.org, John Levine , Tony Finch , Sam Silberman Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: <16701.44787.905804.971494@mtcc.com> Message-ID: References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 7 Sep 2004, Michael Thomas wrote: > > Perhaps it's not obvious, but the identified mail draft can > also support the functionality you're after here with > BATV. It's essentially a matter of inspecting the bounce at > the purported home of the bounce of the bounced message > itself and doing the normal anti-forgery KRS check. Inspecting the body of the bounce is not sufficient, because there are bounce-like messages such as vacation notices which do not include any of the original message, but which you still want to receive. It is also cheaper to detect backscatter at envelope time, and it has the side-benefit of working well with callback verification. Tony. -- f.a.n.finch http://dotat.at/ ARDNAMURCHAN POINT TO CAPE WRATH INCLUDING THE OUTER HEBRIDES: VARIABLE 3 BECOMING SOUTH OR SOUTHEAST. FAIR. GOOD. SLIGHT TO MODERATE. From owner-ietf-mailsig Tue Sep 7 06:47:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87DlwuM029972 for ; Tue, 7 Sep 2004 06:47:58 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87DlwJ3029970 for ietf-mailsig-skb; Tue, 7 Sep 2004 06:47:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Dluaq029944 for ; Tue, 7 Sep 2004 06:47:57 -0700 (PDT) (envelope-from sb0-0668d08819-johnl@iecc.com) Received: (qmail 17993 invoked from network); 7 Sep 2004 13:47:58 -0000 Received: (ofmipd 127.0.0.1); 7 Sep 2004 13:47:36 -0000 Date: 7 Sep 2004 09:47:58 -0400 Message-ID: From: "John R Levine" To: "Tony Finch" Cc: "ietf-mailsig@imc.org" Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Inspecting the body of the bounce is not sufficient, because there are > bounce-like messages such as vacation notices which do not include any of > the original message, but which you still want to receive. It is also > cheaper to detect backscatter at envelope time, Having been using a prototype of BATV for a while, I can confirm that you cannot count on finding anything consistent or mechanically testable in the bodies of mail sent to bounce addresses. Also, BATV is designed to be extremely lightweight in its simplest form. My prototype is only a dozen or so lines of code in my SMTP client and about 100 in the SMTP daemon. To date it works very well. > and it has the side-benefit of working well with callback verification. Considering how pernicious callback verification is, I see that as a minor drawback. Those of us whose addresses are forged on millions of spams a day realize that callbacks are just another kind of DDOS. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mailsig Tue Sep 7 06:51:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Dpbgn030371 for ; Tue, 7 Sep 2004 06:51:37 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87DpbvR030370 for ietf-mailsig-skb; Tue, 7 Sep 2004 06:51:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87Dpao1030364 for ; Tue, 7 Sep 2004 06:51:36 -0700 (PDT) (envelope-from mike@mtcc.com) Received: from mtcc.com.mtcc.com (fasolt.mtcc.com [216.102.208.10]) by mtcc.com (8.12.10/8.12.10) with ESMTP id i87DpXxq022718; Tue, 7 Sep 2004 06:51:33 -0700 From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16701.48357.274821.69478@mtcc.com> Date: Tue, 7 Sep 2004 06:51:33 -0700 To: Tony Finch Cc: Michael Thomas , Dave Crocker , ietf-mailsig@imc.org, John Levine , Sam Silberman Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! IIM-SIG: v:"1"; h:"fasolt.mtcc.com"; d:"mtcc.com"; z:"home"; m:"krs"; t:"1094565093.364538"; x:"432000"; a:"rsa-sha1"; b:"0:1348"; e:"Iw=="; n:"nVv0qboMtb/jcj1UT0mvfTvYyyFXXGzpd98dYJEDa/uux2xfeB+A0e9dSQ07c" "42LbmgdqdIvWuQzlXIdGJ77Qy9oz3RP5a38E2H5O9oPfQNGtaKOiJ6/gELwFy" "6wij+H/UTnHFcKILxF9lBlB7xIoFrXH675Blkho/iM/LDLxNk="; s:"OYgB66koRQYSWYGRMeoryFd6hxozfFFqkKKYwIDlOBWKFUoWrml4/ivGztcxf" "fzOT1fopuzE9Oyjci3tXoxKeenPx89YA3zIqI4ANqIEL27sESVdrVXRMfN5nF" "QHjcrbPswwQ03a/tRA3J3Nt6EUm6qQiL/LcHlg2g+vBjy/89Q="; c:"From: Michael Thomas "; c:"Date: Tue, 7 Sep 2004 06:51:33 -0700"; c:"Subject: Re: at last: draft-levine-mass-batv-00" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"fasolt.mtcc.com"; c:"message from fasolt.mtcc.com verified; " Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tony Finch writes: > On Tue, 7 Sep 2004, Michael Thomas wrote: > > > > Perhaps it's not obvious, but the identified mail draft can > > also support the functionality you're after here with > > BATV. It's essentially a matter of inspecting the bounce at > > the purported home of the bounce of the bounced message > > itself and doing the normal anti-forgery KRS check. > > Inspecting the body of the bounce is not sufficient, because there are > bounce-like messages such as vacation notices which do not include any of > the original message, but which you still want to receive. It is also > cheaper to detect backscatter at envelope time, and it has the > side-benefit of working well with callback verification. To the degree that you don't include original text, is the degree that you are subject to cut and paste attacks. This is true for all signing proposals, but simply cutting out the bounce verifier and adding your spam body is an attack vector. And I think that things that don't include any of the text should be treated like... a fresh message. Which means that the vacation program owner should sign its messages. Since it's not relaying potentially spamful text, I don't see how this raises to the level of the bounce reflection attack which takes advantage of that property. Mike From owner-ietf-mailsig Tue Sep 7 06:58:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87DwVld030955 for ; Tue, 7 Sep 2004 06:58:31 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87DwVVC030954 for ietf-mailsig-skb; Tue, 7 Sep 2004 06:58:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87DwUVP030948 for ; Tue, 7 Sep 2004 06:58:30 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58816) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp (Exim 4.34) id 1C4gUL-0003z2-63 (return-path fanf2@hermes.cam.ac.uk) for ietf-mailsig@imc.org; Tue, 07 Sep 2004 14:58:25 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1C4gUI-0006tP-NP; Tue, 07 Sep 2004 14:58:22 +0100 Date: Tue, 7 Sep 2004 14:58:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Michael Thomas cc: Tony Finch , Dave Crocker , ietf-mailsig@imc.org, John Levine , Sam Silberman Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: <16701.48357.274821.69478@mtcc.com> Message-ID: References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 7 Sep 2004, Michael Thomas wrote: > > To the degree that you don't include original text, is the > degree that you are subject to cut and paste attacks. BATV is not a message data verification system. It simply allows you to link a bounce to an original message sent by you. It would suck if the link is via a virus or a spammer, but experience suggests that this will be very rare in practice because bounce addresses don't get out much. > And I think that things that don't include any of the text should be [...] BATV is designed to work in the real world not an ideal world. Tony. -- f.a.n.finch http://dotat.at/ COLWYN BAY TO THE MULL OF GALLOWAY INCLUDING THE ISLE OF MAN: EAST 3 OR 4. FAIR. GOOD. SLIGHT. From owner-ietf-mailsig Tue Sep 7 07:12:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87ECqoi032667 for ; Tue, 7 Sep 2004 07:12:52 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87ECqW2032666 for ietf-mailsig-skb; Tue, 7 Sep 2004 07:12:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87ECpEA032660 for ; Tue, 7 Sep 2004 07:12:51 -0700 (PDT) (envelope-from mike@mtcc.com) Received: from mtcc.com.mtcc.com (fasolt.mtcc.com [216.102.208.10]) by mtcc.com (8.12.10/8.12.10) with ESMTP id i87ECjxq025319; Tue, 7 Sep 2004 07:12:45 -0700 From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16701.49629.838294.283453@mtcc.com> Date: Tue, 7 Sep 2004 07:12:45 -0700 To: Tony Finch Cc: Michael Thomas , Dave Crocker , ietf-mailsig@imc.org, John Levine , Sam Silberman Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! IIM-SIG: v:"1"; h:"fasolt.mtcc.com"; d:"mtcc.com"; z:"home"; m:"krs"; t:"1094566365.933343"; x:"432000"; a:"rsa-sha1"; b:"0:1338"; e:"Iw=="; n:"nVv0qboMtb/jcj1UT0mvfTvYyyFXXGzpd98dYJEDa/uux2xfeB+A0e9dSQ07c" "42LbmgdqdIvWuQzlXIdGJ77Qy9oz3RP5a38E2H5O9oPfQNGtaKOiJ6/gELwFy" "6wij+H/UTnHFcKILxF9lBlB7xIoFrXH675Blkho/iM/LDLxNk="; s:"J91pN6Jp+nM5Y9fc4ssAwb0xa4dJ3U34QlLdFlbQhHeGGsQdCKafkJk46tW2T" "OLSyzV6sQMFljnid6AGasnWyajsmOIu686g5wz9TjQ0HCo7DgWMQ0gp4V4lQs" "3rzRmleDC9wgFIdP4hqObTTIqSlQQQ9W86PJ53GaqKRT/FD5Y="; c:"From: Michael Thomas "; c:"Date: Tue, 7 Sep 2004 07:12:45 -0700"; c:"Subject: Re: at last: draft-levine-mass-batv-00" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"fasolt.mtcc.com"; c:"message from fasolt.mtcc.com verified; " Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tony Finch writes: > On Tue, 7 Sep 2004, Michael Thomas wrote: > > > > To the degree that you don't include original text, is the > > degree that you are subject to cut and paste attacks. > > BATV is not a message data verification system. It simply allows you to > link a bounce to an original message sent by you. It would suck if the > link is via a virus or a spammer, but experience suggests that this will > be very rare in practice because bounce addresses don't get out much. If I as a spammer simply need to capture a *single* BATV verification header for, oh say, aol.com and attach whatever spam content I desire and bounce it through some dupe relay, that is a *significant* problem. The draft says that this deserves further investigation. Well, I'm all ears. > > And I think that things that don't include any of the text should be [...] > > BATV is designed to work in the real world not an ideal world. Something that will allow trivial cut and paste attacks like this sound perfectly real world exploitable to me. In particular, suppose a financial signed all of its mail and had a posted policy to the effect. Could BATV admit messages as genuinely from that financial which would violate that policy? If it's not considering the body, how could it do otherwise? Mike From owner-ietf-mailsig Tue Sep 7 08:33:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87FX9u7038863 for ; Tue, 7 Sep 2004 08:33:09 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87FX9h9038862 for ietf-mailsig-skb; Tue, 7 Sep 2004 08:33:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87FX8l7038855 for ; Tue, 7 Sep 2004 08:33:08 -0700 (PDT) (envelope-from sb0-0668d08819-johnl@iecc.com) Received: (qmail 25007 invoked from network); 7 Sep 2004 15:33:11 -0000 Received: (ofmipd 127.0.0.1); 7 Sep 2004 15:32:49 -0000 Date: 7 Sep 2004 11:33:11 -0400 Message-ID: From: "John R Levine" To: "Michael Thomas" Cc: "Tony Finch" , "Dave Crocker" , "ietf-mailsig@imc.org" , "Sam Silberman" Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: <16701.49629.838294.283453@mtcc.com> References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> <16701.49629.838294.283453@mtcc.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> BATV is not a message data verification system. It simply allows you to >> link a bounce to an original message sent by you. ... > If I as a spammer simply need to capture a *single* BATV > verification header for, oh say, aol.com and attach whatever > spam content I desire and bounce it through some dupe relay, > that is a *significant* problem. I think you're reading way too much into BATV. It's just a way to deal with forgery blowback, basically to make it so that people can only send you a bounce if they have a message from you to respond to. My prototype only checks the signature on mail with null envelopes or mail from addresses that start mailer-daemon@. If the signature fails, it rejects the message. If the signature is OK, my MTA strips off the signature and treats it the same as any other mail. This works very well, since I can reject most of the virus and spam blowback at SMTP time without reading the message. The hooks for public keys are there so that friendly remote systems can check the signature remotely and not send bogus bounces in the first place. It's not intended as strong validation for incoming mail. The reason I put in a timestamp is so that viruses that scrape web pages and come across old mail messages with signed addresses in the return-path: don't find addresses that will validate. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mailsig Tue Sep 7 08:50:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87FofnH040736 for ; Tue, 7 Sep 2004 08:50:41 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i87FofsB040735 for ietf-mailsig-skb; Tue, 7 Sep 2004 08:50:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i87FoeO1040717 for ; Tue, 7 Sep 2004 08:50:40 -0700 (PDT) (envelope-from sb0-0668d08819-johnl@iecc.com) Received: (qmail 26168 invoked from network); 7 Sep 2004 15:50:42 -0000 Received: (ofmipd 127.0.0.1); 7 Sep 2004 15:50:20 -0000 Date: 7 Sep 2004 11:50:42 -0400 Message-ID: From: "John R Levine" To: "Michael Thomas" Cc: "Tony Finch" , "Dave Crocker" , "ietf-mailsig@imc.org" , "Sam Silberman" Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: <16701.48357.274821.69478@mtcc.com> References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > And I think that things that don't include any of the text > should be treated like... a fresh message. Which means that > the vacation program owner should sign its messages. Since > it's not relaying potentially spamful text, I don't see how > this raises to the level of the bounce reflection attack > which takes advantage of that property. The problem with bounce blowback isn't that the bounces are forged, because they're not. They're real bounces (or vacation messages or whatever) responding to bogus messages. The point of BATV is to detect that the real vacation message is a response to a bogus original. The problem with blowback isn't that the individual messages are dangerous. It's that there's so many of them. On a particularly bad day I've gotten 300,000 bounces due to spam with forged abuse.net addresses. Now it's down to about 5000 a day, but that's still 10% of my incoming mail on that server, so it's quite useful to be able to detect and reject that much useless mail with essentially no false positives. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mailsig Fri Sep 17 03:54:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HAsOu3048635 for ; Fri, 17 Sep 2004 03:54:24 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HAsObe048634 for ietf-mailsig-skb; Fri, 17 Sep 2004 03:54:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HAs6i0048490 for ; Fri, 17 Sep 2004 03:54:18 -0700 (PDT) (envelope-from SRS0+91e1762fa1729a0111fb+390+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8GNB-0008LL-QU; Fri, 17 Sep 2004 11:53:49 +0100 Subject: Re: at last: draft-levine-mass-batv-00 From: David Woodhouse To: John R Levine Cc: Michael Thomas , Tony Finch , Dave Crocker , "ietf-mailsig@imc.org" , Sam Silberman In-Reply-To: References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> <16701.49629.838294.283453@mtcc.com> Content-Type: text/plain; charset=UTF-8 Message-Id: <1095418429.31730.76.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Fri, 17 Sep 2004 11:53:49 +0100 Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 2004-09-07 at 11:33 -0400, John R Levine wrote: > > [ Tony Finch ] > > > BATV is not a message data verification system. It simply allows you to > > > link a bounce to an original message sent by you. ... > > [ Michael Thomas ] > > If I as a spammer simply need to capture a *single* BATV > > verification header for, oh say, aol.com and attach whatever > > spam content I desire and bounce it through some dupe relay, > > that is a *significant* problem. > > I think you're reading way too much into BATV. Indeed. Like John, I've been been using a scheme like BATV for a while. We've been calling it 'Signed Envelope Sender', which was a term coined by Meng Weng Wong when the idea was discussed on the spf-discuss mailing list in February. It doesn't give the recipient a 100% guarantee that the message really did come from me, but it does _instantly_ stem the flood of backscatter. The beauty of the scheme is that it is unilateral -- it doesn't require any third party to upgrade to co-operate; you just stop accepting the bounces to mail you didn't actually send. That in _itself_ is enough. Of course, BATV _can_ be used to give a benefit to (potential) recipients too. Those using SMTP callouts (no heckling please) automatically get the benefit. It has also been suggested that the use of a 'stunt DNS' server and the SPF-Classic/marid-mailfrom 'exists' mechanism could be used to let potential recipients reject faked mail. I think BATV has immediate benefits for the deploying user which would be hard to achieve with any other mechanism. Yes, it has some problems which I deem to be minor. First there's the fact that some recipients (ezmlm mailing lists in particular) like a constant envelope sender. To fix this, we can define a standard form for the signature, and ask such recipients to strip the address back to its original form before doing their checks. However it would be stupidly naïve to assume that the whole world will upgrade to help us implement any new scheme we come up with, so we can _also_ work around the problem by using fixed address-signatures for certain 'problem recipients'. Also there's the possibility of replay attacks. One possible answer is to merely declare that the likelihood of these is low and that we hence don't care -- the signed reverse-path is rarely made public since it's changed by mailing lists and generally omitted by mailing list archives. Also, the uptake of BATV (or indeed any scheme) will never be universal and there will always be easier pickings. Certainly that's been my answer for the last seven months; but maybe there are better answers too. One suggestion made recently has been to generate a hash of the message body itself, and include that in the reverse-path. While body-signing schemes at the RFC2822 level need extra complexity to deal with the possibility that the message may be modified in transit (qv), this is less true for a signature in the reverse-path. A simple md5sum of the message could be included as part of a 'standard' BATV address format, and the recipient could check the body of the message against that. This wouldn't be as fragile as signatures tied to the RFC2822 identities because the most common offender -- mailing lists adding footers and stripping MIME parts -- is going to change the RFC2821 'MAIL FROM' address anyway. And the other most common offenders -- the addition of a pointless disclaimer or a free advert for some virus checking system -- can be done either at the sending site _before_ generating the md5sum, or at the receiving site _after_ checking it. It's an open question as to whether the extra complexity of including a message digest is actually worth the benefit, or whether verification of message content should be left to complementary schemes such as DK. But the current BATV draft offers the choice of multiple 'public' address signature schemes, so perhaps it would be sufficient to merely define a public scheme including such a hash of the message, and permit the implementing sites to choose whether to use that or a private scheme? Another possibility is to include in the reverse-path not a hash of the whole body, but only a hash of the DomainKeys header, in the case where DK is used. Thus, BATV and DK would serve as an ideal complement to each other. (for DK please read 'your RFC2822 message signing system of choice'. I haven't got that far... yet) [ Not all the ideas above are my own, btw. Some discussion has taken place in relative seclusion on a mailing list which was set up to discuss 'SES' without polluting the SPF discussion list further. ] -- dwmw2 From owner-ietf-mailsig Fri Sep 17 06:12:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HDCYpW065146 for ; Fri, 17 Sep 2004 06:12:34 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HDCY24065145 for ietf-mailsig-skb; Fri, 17 Sep 2004 06:12:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HDCX0S065132 for ; Fri, 17 Sep 2004 06:12:33 -0700 (PDT) (envelope-from mike@mtcc.com) Received: from mtcc.com.mtcc.com (fasolt.mtcc.com [216.102.208.10]) by mtcc.com (8.12.10/8.12.10) with ESMTP id i8HDC7xq009277; Fri, 17 Sep 2004 06:12:07 -0700 From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16714.58023.571367.519474@mtcc.com> Date: Fri, 17 Sep 2004 06:12:07 -0700 To: David Woodhouse Cc: John R Levine , Michael Thomas , Tony Finch , Dave Crocker , "ietf-mailsig@imc.org" , Sam Silberman Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: <1095418429.31730.76.camel@imladris.demon.co.uk> References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> <16701.49629.838294.283453@mtcc.com> <1095418429.31730.76.camel@imladris.demon.co.uk> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! IIM-SIG: v:"1"; h:"fasolt.mtcc.com"; d:"mtcc.com"; z:"home"; m:"krs"; t:"1095426730.40112"; x:"432000"; a:"rsa-sha1"; b:"nofws:6075"; e:"Iw=="; n:"nVv0qboMtb/jcj1UT0mvfTvYyyFXXGzpd98dYJEDa/uux2xfeB+A0e9dSQ07c" "42LbmgdqdIvWuQzlXIdGJ77Qy9oz3RP5a38E2H5O9oPfQNGtaKOiJ6/gELwFy" "6wij+H/UTnHFcKILxF9lBlB7xIoFrXH675Blkho/iM/LDLxNk="; s:"BuUvsqxqWZQv1PzD7V2QR+34oIleCfP/7OPzq6Ro6iojNxzHz+qCZAWV4vzT8" "eqcYkkVahghbGvEwGvJFMrhvK/zMc3Ek8ic7T7Tfw2M2Dd8XyF5oQt3rL22yO" "VaJtXK5/SW6+epZCR+r/TXtRLkmt9QoivvnX6yELpBitQswbU="; c:"From: Michael Thomas "; c:"Date: Fri, 17 Sep 2004 06:12:07 -0700"; c:"Subject: Re: at last: draft-levine-mass-batv-00" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"fasolt.mtcc.com"; c:"message from fasolt.mtcc.com verified; " Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8HDCY0S065139 Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The problem here is that the draft does not explain how it deals with the cut and paste attack. I've specifically asked about that and have been told yet again that I'm "reading way too much into it" -- a non answer. With none of the body included in a hash, a spammer can simply cut a valid signature and append whatever spam to the body they want. That's not good. If you counter this by putting some or all of the body into the hash, the whole process looks like the more general purpose solution (eg, IIM). As I've said, I've tested IIM to see if it works against the bounce reflection attack -- it does. The big question is how to make this tradeoff against of hash survivability through bouncers and the cut and paste attack. What I don't see is why a completely different mechanism for this attack is necessary. Mike David Woodhouse writes: > On Tue, 2004-09-07 at 11:33 -0400, John R Levine wrote: > > > [ Tony Finch ] > > > > BATV is not a message data verification system. It simply allows you to > > > > link a bounce to an original message sent by you. ... > > > > [ Michael Thomas ] > > > If I as a spammer simply need to capture a *single* BATV > > > verification header for, oh say, aol.com and attach whatever > > > spam content I desire and bounce it through some dupe relay, > > > that is a *significant* problem. > > > > I think you're reading way too much into BATV. > > Indeed. Like John, I've been been using a scheme like BATV for a while. > We've been calling it 'Signed Envelope Sender', which was a term coined > by Meng Weng Wong when the idea was discussed on the spf-discuss mailing > list in February. > > It doesn't give the recipient a 100% guarantee that the message really > did come from me, but it does _instantly_ stem the flood of backscatter. > > The beauty of the scheme is that it is unilateral -- it doesn't require > any third party to upgrade to co-operate; you just stop accepting the > bounces to mail you didn't actually send. That in _itself_ is enough. > > Of course, BATV _can_ be used to give a benefit to (potential) > recipients too. Those using SMTP callouts (no heckling please) > automatically get the benefit. It has also been suggested that the use > of a 'stunt DNS' server and the SPF-Classic/marid-mailfrom 'exists' > mechanism could be used to let potential recipients reject faked mail. > > I think BATV has immediate benefits for the deploying user which would > be hard to achieve with any other mechanism. > > Yes, it has some problems which I deem to be minor. First there's the > fact that some recipients (ezmlm mailing lists in particular) like a > constant envelope sender. To fix this, we can define a standard form for > the signature, and ask such recipients to strip the address back to its > original form before doing their checks. However it would be stupidly > naïve to assume that the whole world will upgrade to help us implement > any new scheme we come up with, so we can _also_ work around the problem > by using fixed address-signatures for certain 'problem recipients'. > > Also there's the possibility of replay attacks. One possible answer is > to merely declare that the likelihood of these is low and that we hence > don't care -- the signed reverse-path is rarely made public since it's > changed by mailing lists and generally omitted by mailing list archives. > Also, the uptake of BATV (or indeed any scheme) will never be universal > and there will always be easier pickings. Certainly that's been my > answer for the last seven months; but maybe there are better answers > too. > > One suggestion made recently has been to generate a hash of the message > body itself, and include that in the reverse-path. While body-signing > schemes at the RFC2822 level need extra complexity to deal with the > possibility that the message may be modified in transit (qv), this is > less true for a signature in the reverse-path. A simple md5sum of the > message could be included as part of a 'standard' BATV address format, > and the recipient could check the body of the message against that. > > This wouldn't be as fragile as signatures tied to the RFC2822 identities > because the most common offender -- mailing lists adding footers and > stripping MIME parts -- is going to change the RFC2821 'MAIL FROM' > address anyway. And the other most common offenders -- the addition of a > pointless disclaimer or a free advert for some virus checking system -- > can be done either at the sending site _before_ generating the md5sum, > or at the receiving site _after_ checking it. > > It's an open question as to whether the extra complexity of including a > message digest is actually worth the benefit, or whether verification of > message content should be left to complementary schemes such as DK. But > the current BATV draft offers the choice of multiple 'public' address > signature schemes, so perhaps it would be sufficient to merely define a > public scheme including such a hash of the message, and permit the > implementing sites to choose whether to use that or a private scheme? > > Another possibility is to include in the reverse-path not a hash of the > whole body, but only a hash of the DomainKeys header, in the case where > DK is used. Thus, BATV and DK would serve as an ideal complement to each > other. > > (for DK please read 'your RFC2822 message signing system of choice'. I > haven't got that far... yet) > > [ Not all the ideas above are my own, btw. Some discussion has taken > place in relative seclusion on a mailing list which was set up to > discuss 'SES' without polluting the SPF discussion list further. ] > > -- > dwmw2 From owner-ietf-mailsig Fri Sep 17 06:53:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HDrOaJ069276 for ; Fri, 17 Sep 2004 06:53:24 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HDrOav069275 for ietf-mailsig-skb; Fri, 17 Sep 2004 06:53:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HDrNnb069261 for ; Fri, 17 Sep 2004 06:53:24 -0700 (PDT) (envelope-from mike@mtcc.com) Received: from mtcc.com.mtcc.com (fasolt.mtcc.com [216.102.208.10]) by mtcc.com (8.12.10/8.12.10) with ESMTP id i8HDrHxq014913; Fri, 17 Sep 2004 06:53:17 -0700 From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16714.60492.980014.691219@mtcc.com> Date: Fri, 17 Sep 2004 06:53:16 -0700 To: Michael Thomas Cc: David Woodhouse , John R Levine , Tony Finch , Dave Crocker , "ietf-mailsig@imc.org" , Sam Silberman Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: <16714.58023.571367.519474@mtcc.com> References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> <16701.49629.838294.283453@mtcc.com> <1095418429.31730.76.camel@imladris.demon.co.uk> <16714.58023.571367.519474@mtcc.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! IIM-SIG: v:"1"; h:"fasolt.mtcc.com"; d:"mtcc.com"; z:"home"; m:"krs"; t:"1095429197.355272"; x:"432000"; a:"rsa-sha1"; b:"nofws:6914"; e:"Iw=="; n:"nVv0qboMtb/jcj1UT0mvfTvYyyFXXGzpd98dYJEDa/uux2xfeB+A0e9dSQ07c" "42LbmgdqdIvWuQzlXIdGJ77Qy9oz3RP5a38E2H5O9oPfQNGtaKOiJ6/gELwFy" "6wij+H/UTnHFcKILxF9lBlB7xIoFrXH675Blkho/iM/LDLxNk="; s:"FCXHndwUF5nEMGJnovy1iRkoTU8mhw2B5nwd1TBoHnPd0yNxrs8HCZxM/k8Lp" "gj57dDtVkuLn6DvAhYbqa3XQSHuxq/oI69k9jXEdVXXlEMzbik0GofwwmcHq/" "vdpnghhKTuBLxbjSdAynHCZ54nGfdUiC4U4/cH+pHQGFRU7K8="; c:"From: Michael Thomas "; c:"Date: Fri, 17 Sep 2004 06:53:16 -0700"; c:"Subject: Re: at last: draft-levine-mass-batv-00" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"fasolt.mtcc.com"; c:"message from fasolt.mtcc.com verified; " Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8HDrOnb069270 Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Just to be clear, I'm not trying to dump on the authors here, but more to point out that this problem is very likely a second harmonic of the primary problem -- forgery. And it almost certainly has all of the requirements to deal with the primary problem and quite likely adds more. Fleshing out the unique requirements for the bounce reflection attack from the simple forgery attack would be an extremely useful exercise IMO. Mike Michael Thomas writes: > > The problem here is that the draft does not explain how it > deals with the cut and paste attack. I've specifically asked > about that and have been told yet again that I'm "reading > way too much into it" -- a non answer. With none of the body > included in a hash, a spammer can simply cut a valid > signature and append whatever spam to the body they > want. That's not good. If you counter this by putting some > or all of the body into the hash, the whole process looks > like the more general purpose solution (eg, IIM). As I've > said, I've tested IIM to see if it works against the bounce > reflection attack -- it does. The big question is how to > make this tradeoff against of hash survivability through > bouncers and the cut and paste attack. What I don't see is > why a completely different mechanism for this attack is > necessary. > > Mike > > > David Woodhouse writes: > > On Tue, 2004-09-07 at 11:33 -0400, John R Levine wrote: > > > > [ Tony Finch ] > > > > > BATV is not a message data verification system. It simply allows you to > > > > > link a bounce to an original message sent by you. ... > > > > > > [ Michael Thomas ] > > > > If I as a spammer simply need to capture a *single* BATV > > > > verification header for, oh say, aol.com and attach whatever > > > > spam content I desire and bounce it through some dupe relay, > > > > that is a *significant* problem. > > > > > > I think you're reading way too much into BATV. > > > > Indeed. Like John, I've been been using a scheme like BATV for a while. > > We've been calling it 'Signed Envelope Sender', which was a term coined > > by Meng Weng Wong when the idea was discussed on the spf-discuss mailing > > list in February. > > > > It doesn't give the recipient a 100% guarantee that the message really > > did come from me, but it does _instantly_ stem the flood of backscatter. > > > > The beauty of the scheme is that it is unilateral -- it doesn't require > > any third party to upgrade to co-operate; you just stop accepting the > > bounces to mail you didn't actually send. That in _itself_ is enough. > > > > Of course, BATV _can_ be used to give a benefit to (potential) > > recipients too. Those using SMTP callouts (no heckling please) > > automatically get the benefit. It has also been suggested that the use > > of a 'stunt DNS' server and the SPF-Classic/marid-mailfrom 'exists' > > mechanism could be used to let potential recipients reject faked mail. > > > > I think BATV has immediate benefits for the deploying user which would > > be hard to achieve with any other mechanism. > > > > Yes, it has some problems which I deem to be minor. First there's the > > fact that some recipients (ezmlm mailing lists in particular) like a > > constant envelope sender. To fix this, we can define a standard form for > > the signature, and ask such recipients to strip the address back to its > > original form before doing their checks. However it would be stupidly > > naïve to assume that the whole world will upgrade to help us implement > > any new scheme we come up with, so we can _also_ work around the problem > > by using fixed address-signatures for certain 'problem recipients'. > > > > Also there's the possibility of replay attacks. One possible answer is > > to merely declare that the likelihood of these is low and that we hence > > don't care -- the signed reverse-path is rarely made public since it's > > changed by mailing lists and generally omitted by mailing list archives. > > Also, the uptake of BATV (or indeed any scheme) will never be universal > > and there will always be easier pickings. Certainly that's been my > > answer for the last seven months; but maybe there are better answers > > too. > > > > One suggestion made recently has been to generate a hash of the message > > body itself, and include that in the reverse-path. While body-signing > > schemes at the RFC2822 level need extra complexity to deal with the > > possibility that the message may be modified in transit (qv), this is > > less true for a signature in the reverse-path. A simple md5sum of the > > message could be included as part of a 'standard' BATV address format, > > and the recipient could check the body of the message against that. > > > > This wouldn't be as fragile as signatures tied to the RFC2822 identities > > because the most common offender -- mailing lists adding footers and > > stripping MIME parts -- is going to change the RFC2821 'MAIL FROM' > > address anyway. And the other most common offenders -- the addition of a > > pointless disclaimer or a free advert for some virus checking system -- > > can be done either at the sending site _before_ generating the md5sum, > > or at the receiving site _after_ checking it. > > > > It's an open question as to whether the extra complexity of including a > > message digest is actually worth the benefit, or whether verification of > > message content should be left to complementary schemes such as DK. But > > the current BATV draft offers the choice of multiple 'public' address > > signature schemes, so perhaps it would be sufficient to merely define a > > public scheme including such a hash of the message, and permit the > > implementing sites to choose whether to use that or a private scheme? > > > > Another possibility is to include in the reverse-path not a hash of the > > whole body, but only a hash of the DomainKeys header, in the case where > > DK is used. Thus, BATV and DK would serve as an ideal complement to each > > other. > > > > (for DK please read 'your RFC2822 message signing system of choice'. I > > haven't got that far... yet) > > > > [ Not all the ideas above are my own, btw. Some discussion has taken > > place in relative seclusion on a mailing list which was set up to > > discuss 'SES' without polluting the SPF discussion list further. ] > > > > -- > > dwmw2 From owner-ietf-mailsig Fri Sep 17 06:56:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HDuK4w069465 for ; Fri, 17 Sep 2004 06:56:20 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HDuKrJ069464 for ietf-mailsig-skb; Fri, 17 Sep 2004 06:56:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HDu6Fu069449 for ; Fri, 17 Sep 2004 06:56:19 -0700 (PDT) (envelope-from SRS0+4accd74db7714a56ae55+390+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8JDN-0003ry-4e; Fri, 17 Sep 2004 14:55:56 +0100 Subject: Re: at last: draft-levine-mass-batv-00 From: David Woodhouse To: Michael Thomas Cc: John R Levine , Tony Finch , Dave Crocker , "ietf-mailsig@imc.org" , Sam Silberman In-Reply-To: <16714.58023.571367.519474@mtcc.com> References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> <16701.49629.838294.283453@mtcc.com> <1095418429.31730.76.camel@imladris.demon.co.uk> <16714.58023.571367.519474@mtcc.com> Content-Type: text/plain Message-Id: <1095429345.17821.154.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Fri, 17 Sep 2004 14:55:45 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 2004-09-17 at 06:12 -0700, Michael Thomas wrote: > The problem here is that the draft does not explain how it > deals with the cut and paste attack. I've specifically asked > about that and have been told yet again that I'm "reading > way too much into it" -- a non answer. A partial answer. Followed by a number of paragraphs of more detailed consideration. > With none of the body included in a hash, a spammer can simply > cut a valid signature and append whatever spam to the body they > want. That's not good. Agreed. Not ideal -- but not actually a showstopper either. Even with this limitation, BATV still gives a huge benefit, instantly. > If you counter this by putting some or all of the body into > the hash, the whole process looks like the more general purpose > solution (eg, IIM). As I've said, I've tested IIM to see if it > works against the bounce reflection attack -- it does. The > big question is how to make this tradeoff against of hash > survivability through bouncers and the cut and paste attack. > What I don't see is why a completely different mechanism for > this attack is necessary. BATV would appear to make an ideal _complement_ to other message signing solutions. By signing mail we seek to achieve two things -- firstly to allow the potential recipient to reject mail which is not genuine, and secondly to allow ourselves to reject 'bounces' to messages which we did not in fact send. The RFC2822 signature methods such as IIM/DK/etc allow participating recipients to achieve the first objective, but without ubiquitous deployment they can never achieve the second. They can achieve _limited_ success at the second objective, but there are just too many systems out there which when generating a bounce will omit whatever signature headers we use, and we'd always have the problem of deciding what do to with a bounce which just lacks the appropriate header. By using the SMTP reverse-path as our signature, we fix that problem without the potential to throw away _legitimate_ bounces. On whether we want to include a hash of the body (or a hash of the RFC2822-signature header alone) in the BATV reverse-path itself: I'm still not sure -- I'd be interested in a discussion of that idea. Putting a hash into the BATV reverse-path does protect against the replay attack. But stop and think about it for a second more -- putting that hash into the BATV reverse-path helps to stop reception of the fake only by _participating_ recipients. Non-participants aren't going to check the contents against the hash, and are going to accept the message anyway -- and later maybe generate a bounce anyway. The hash in the BATV reverse-path is only going to stop _participating_ recipients from accepting the mail. I would suggest that there will be a _huge_ correlation between those participating in a BATV scheme and those participating in whatever RFC2822-level scheme we standardise. Thus, those who'd be looking at the BATV hash of the message content would be looking for the IIM/DK/whatever signature _anyway_ and would have rejected the mail in question _anyway_ due to the lack of such. So would we really gain anything by putting that hash there? I suppose that depends on the correctness of my assumption about the correlation between those who check BATV signatures, and those who check RFC2822 signatures. Since BATV signatures can trivially be checked in the MTA and don't need complex algorithms to allow (slight) modification in-transit, and RFC2822 signatures are necessarily more complex, perhaps I could be wrong about that, and the simple BATV body-md5sum could be more widely verified in practice? Answers on a postcard to... -- dwmw2 From owner-ietf-mailsig Fri Sep 17 09:19:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HGJeYq081430 for ; Fri, 17 Sep 2004 09:19:40 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HGJef6081429 for ietf-mailsig-skb; Fri, 17 Sep 2004 09:19:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HGJd6b081420 for ; Fri, 17 Sep 2004 09:19:40 -0700 (PDT) (envelope-from SRS0+4accd74db7714a56ae55+390+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8LST-0004MW-BC for ietf-mailsig@imc.org; Fri, 17 Sep 2004 17:19:38 +0100 Subject: Rambings on RFC2822 signatures. From: David Woodhouse To: ietf-mailsig@imc.org Content-Type: text/plain Message-Id: <1095437975.17821.383.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Fri, 17 Sep 2004 17:19:36 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here are some of the criteria which I think any RFC2822-level signature scheme should meet. First, it should handle multiple signatures. A recipient may quite reasonably want to verify and or all of the addresses in the From:, Sender, Resent-From: and/or Resent-Sender: headers. Second, it should be resilient to the common mangling which messages may encounter in transit -- in particular the addition of text to the end of a mail by mailing lists, by idiotic disclaimers and by self-advertising virus checkers. Also, as an adjunct to the above, it should ideally survive the stripping of MIME parts which some mailing lists perform. Signing each MIME part separately would be useful, rather than signing the message as a whole. By way of example, consider the following mail: -------------- Resent-From: Joe Resent-To: Sleuth Resent-Message-Id: <102@server.company.com> Resent-Date: Tue, 24 Feb 2004 11:30:02 +0000 From: Fred Sender: Jane Message-ID: <101@server.company.com> To: Staff Date: Mon, 23 Feb 2004 14:20:34 +0000 You're all going to be fired next week. Sucks to be you. -- Fred. This mail was checked for viruses by some company's free advert. -------------- Each of Joe, Fred and Jane might wish to disavow their part in this email, the recipient may be interested in verifying the signature from each of them. A similar situation arises even with just the different From: and Sender: encountered in most mailing list traffic. If you receive a mail with reverse-path 'owner-ietf-mailsig@mail.imc.org' your mail filters may well put it into this mail folder, but did it _really_ go to all the recipients of the list? And, of course, was it really sent by the person from whom it claims to have been sent? Now, the problem of stuff being added to the message in transit. This doesn't seem particularly difficult to deal with. Consider the mail above -- Fred sent only four lines of that, and the rest was added later. So Fred's signature should _say_ so, and give a way to find those four lines. This can be done by augmenting the real, secure hash of the content with a simple way of finding the four lines which Fred really wrote -- the number of lines and a cheap rolling checksum, where you can add one line and subtract another as you move your 'window' down the text in question to find the match. Let us for the moment completely ignore the details of what the headers might be called, and how we might do the _secure_ signatures. But Fred may have added a header which identifies himself, and the signs the content he generated: X-Auth-1-hash-content: 4,3d58b23a,hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh You'd check his signature by looking for four lines in the text which match that cheap checksum, then verify the stronger hash. As the actual sender, Jane will also have added an identical signature of her own on the content, and also signatures of the Date: and Message-Id: headers, having canonicalised the headers by folding whitespace and discarding comments: X-Auth-2-hash-content: 4,3d58b23a,iiiiiiiiiiiiiiiiiiiiiiiiiiiiiii X-Auth-2-hash-Date: jjjjjjjjjjjj X-Auth-2-hash-Message-Id: kkkkkkkkkkkkkkk Now when Joe resends it, he adds his own headers, including a signature on the silly virus-scanner advert: X-Auth-3-hash-content: 5,5c2d7823,mmmmmmmmmmmmmmmmmmmmmmmm X-Auth-3-hash-Resent-Date: lllllllllllllllllll X-Auth-3-hash-Message-Id: nnnnnnnnnnnnnnnnnnnnn ( maybe also resign the original Date: and Message-Id:) Now, there is the question of how to authenticate all those separate hashes of content and headers. Perhaps each party would add a cover-all header with the identity of their public key, and a signature identifying and encompassing all the signatures which are present. By doing it like this, you get to sign different parts of the message separately and as resilient as possible to damage in transit. Obviously this is far from being a coherent and complete method, but maybe there are ideas which could be useful. -- dwmw2 From owner-ietf-mailsig Fri Sep 17 09:28:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HGS0J4081916 for ; Fri, 17 Sep 2004 09:28:00 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HGS0Su081915 for ietf-mailsig-skb; Fri, 17 Sep 2004 09:28:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HGS0F5081908 for ; Fri, 17 Sep 2004 09:28:00 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8HGS0g11888 for ; Fri, 17 Sep 2004 09:28:00 -0700 From: Dave Crocker To: "ietf-mailsig@imc.org" X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Reply-To: Dave Crocker Date: Fri, 17 Sep 2004 09:27:59 -0700 Message-ID: <200491792759.288825@bbprime> In-Reply-To: <1095429345.17821.154.camel@hades.cambridge.redhat.com> Subject: Re: at last: draft-levine-mass-batv-00 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, On Fri, 17 Sep 2004 14:55:45 +0100, David Woodhouse wrote: > On whether we want to include a hash of the body (or a hash of the > RFC2822-signature header alone) in the BATV reverse-path itself: I'm > still not sure -- I'd be interested in a discussion of that idea. One of the ways to validate a line of thinking is to see whether it gets replicated indpendently. David has done a very nice job of independently producing the reason for having BATV present a framework, rather than a single mechanism. (The other is that there is no public key 'winner' yet, so we could not choose just one.) When one thinks of classic approaches to doing encryption-based security, the solution space for RFC2821.MailFrom signing that is acceptable is rather remarkable. It appears that astonishingly weak mechanisms can often be useful. d/ -- Brandenburg InternetWorking dcrocker@brandenburg.com +1.408.246.8253 From owner-ietf-mailsig Fri Sep 17 09:42:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HGgukk082969 for ; Fri, 17 Sep 2004 09:42:56 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HGgu7p082968 for ietf-mailsig-skb; Fri, 17 Sep 2004 09:42:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HGgu2R082961 for ; Fri, 17 Sep 2004 09:42:56 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 17 Sep 2004 12:42:57 -0400 id 002135A7.414B1411.000007AB In-Reply-To: <200491792759.288825@bbprime> References: <200491792759.288825@bbprime> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9F09EA76-08C8-11D9-9584-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: "ietf-mailsig@imc.org" From: Andrew Newton Subject: Re: at last: draft-levine-mass-batv-00 Date: Fri, 17 Sep 2004 12:42:53 -0400 To: Dave Crocker X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 17, 2004, at 12:27 PM, Dave Crocker wrote: > When one thinks of classic approaches to doing encryption-based > security, the > solution space for RFC2821.MailFrom signing that is acceptable is > rather > remarkable. It appears that astonishingly weak mechanisms can often > be useful. I agree. -andy From owner-ietf-mailsig Fri Sep 17 12:18:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HJICwm096027 for ; Fri, 17 Sep 2004 12:18:12 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HJICYi096026 for ietf-mailsig-skb; Fri, 17 Sep 2004 12:18:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from web14930.mail.yahoo.com (web14930.mail.yahoo.com [216.136.225.159]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8HJIBfq096019 for ; Fri, 17 Sep 2004 12:18:11 -0700 (PDT) (envelope-from mlibbeymail-mailsig@yahoo.com) Message-ID: <20040917191813.52092.qmail@web14930.mail.yahoo.com> Received: from [216.145.54.158] by web14930.mail.yahoo.com via HTTP; Fri, 17 Sep 2004 12:18:13 PDT Date: Fri, 17 Sep 2004 12:18:13 -0700 (PDT) From: Miles Libbey Reply-To: mlibbeymail-mailsig@yahoo.com Subject: Re: Rambings on RFC2822 signatures. To: David Woodhouse , ietf-mailsig@imc.org In-Reply-To: <1095437975.17821.383.camel@hades.cambridge.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- David Woodhouse wrote: > Second, it should be resilient to the common mangling which messages > may > encounter in transit -- in particular the addition of text to the end > of > a mail by mailing lists, by idiotic disclaimers and by > self-advertising > virus checkers. We should be careful in this requirement. Poking holes in authentication means more chances for abusers. If we were to allow any content at the end for instance, spammers may be able to figure out how to replay legit messages and append their phishing information to the end. miles From owner-ietf-mailsig Fri Sep 17 13:33:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKXEJM003663 for ; Fri, 17 Sep 2004 13:33:14 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HKXEnx003662 for ietf-mailsig-skb; Fri, 17 Sep 2004 13:33:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from baythorne.infradead.org (imladris.demon.co.uk [193.237.130.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKX0gf003643 for ; Fri, 17 Sep 2004 13:33:13 -0700 (PDT) (envelope-from SRS0+91e1762fa1729a0111fb+390+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8PPj-0000au-QQ; Fri, 17 Sep 2004 21:33:03 +0100 Subject: Re: Rambings on RFC2822 signatures. From: David Woodhouse To: mlibbeymail-mailsig@yahoo.com Cc: ietf-mailsig@imc.org In-Reply-To: <20040917191813.52092.qmail@web14930.mail.yahoo.com> References: <20040917191813.52092.qmail@web14930.mail.yahoo.com> Content-Type: text/plain Message-Id: <1095453183.31730.104.camel@imladris.demon.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Fri, 17 Sep 2004 21:33:03 +0100 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 2004-09-17 at 12:18 -0700, Miles Libbey wrote: > --- David Woodhouse wrote: > > Second, it should be resilient to the common mangling which messages > > may encounter in transit -- in particular the addition of text to the end > > of a mail by mailing lists, by idiotic disclaimers and by self-advertising > > virus checkers. > > We should be careful in this requirement. Poking holes in > authentication means more chances for abusers. If we were to allow any > content at the end for instance, spammers may be able to figure out how > to replay legit messages and append their phishing information to the > end. True. But I'd observe that the sender can happily convey the information about precisely what was sent -- and it's up to the recipient to determine how much mangling is acceptable. If you don't want to accept a five-line signed message with 100 lines of addition, you're probably right. If you don't want to accept a 100-line signed message with two lines added, that's probably your right. -- dwmw2 From owner-ietf-mailsig Fri Sep 17 17:12:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I0CHBE019742 for ; Fri, 17 Sep 2004 17:12:17 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I0CHqS019741 for ietf-mailsig-skb; Fri, 17 Sep 2004 17:12:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I0CFuB019735 for ; Fri, 17 Sep 2004 17:12:16 -0700 (PDT) (envelope-from sb0-067970b59b-johnl@iecc.com) Received: (qmail 3155 invoked by uid 100); 18 Sep 2004 00:12:21 -0000 Date: 18 Sep 2004 00:12:21 -0000 Message-ID: <20040918001221.3154.qmail@xuxa.iecc.com> From: John Levine To: ietf-mailsig@imc.org Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: <16714.58023.571367.519474@mtcc.com> Organization: I.E.C.C., Trumansburg NY USA Cc: mike@mtcc.com Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >The problem here is that the draft does not explain how it deals with >the cut and paste attack. There is no cut and paste attack. All that BATV does is to let you test whether an alleged bounce is from someone who is responding to a message from you. A bounce need not contain any of the text of the original message, and if the target address was a mail exploder, it's quite legitimate to get multiple bounces in reply to a single message. A bad guy could send you a zillion bounces to the same message (or more likely, a buggy MTA) but I don't see that as a big enough threat to be worth a large amount of mechanism to avoid. If it is a problem, a simple band-aid that counts the amount of mail to each BATV address and rejects mail beyond some per-address limit seems as effective as anything else and doesn't need any support from standards. My prototype does put a timestamp in the signature, but I do that because I've noted that address scraping from the web is a major source of spam targets, and that's a way to make scraping of old archives less effective. In particular, BATV is NOT a way for recipients to verify the authenticity of arbitary senders. I agree that remotely verifiable bounce address signatures are an interesting idea, but this isn't it. I also happen to think that the only reasonable way to do them is to wait for MASS to do its thing and piggyback on top of whatever key distribution scheme it uses rather than trying to invent our own. As Dave C. has noted, BATV is a framework, and I'm sure there'll be plenty of clever ideas of stuff to put into the framework. But we're not gonna put it all there just yet. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", said Tom, revealingly. From owner-ietf-mailsig Fri Sep 17 23:37:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I6bMeK079324 for ; Fri, 17 Sep 2004 23:37:22 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I6bME7079323 for ietf-mailsig-skb; Fri, 17 Sep 2004 23:37:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I6bMim079278 for ; Fri, 17 Sep 2004 23:37:22 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 17 Sep 2004 23:38:39 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8I6bCbs002830; Fri, 17 Sep 2004 23:37:13 -0700 (PDT) Received: from fenton-w2k01.cisco.com (stealth-10-32-245-100.cisco.com [10.32.245.100]) by imail.cisco.com (8.12.5/8.12.10) with SMTP id i8I6kBZJ008097; Fri, 17 Sep 2004 23:46:14 -0700 Message-Id: <4.3.2.7.2.20040917230814.0446db80@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 Sep 2004 23:14:31 -0700 To: David Woodhouse , mlibbeymail-mailsig@yahoo.com From: Jim Fenton Subject: Re: Rambings on RFC2822 signatures. Cc: ietf-mailsig@imc.org In-Reply-To: <1095453183.31730.104.camel@imladris.demon.co.uk> References: <20040917191813.52092.qmail@web14930.mail.yahoo.com> <20040917191813.52092.qmail@web14930.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1095489974.697961"; x:"432000"; a:"rsa-sha1"; b:"nofws:1518"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"R85FnEb2acicr0MvSz18o06Ym36pKN+QuwmJ9uFrbFMfSUFCqYgfZzrQPWoRI" "44PtbkdaLNZHUumugCJmdKA6ZMStEUiFHnq31xIYTQXfc9poExVNP98geKIPV" "vXt9AJgaRfpTIZFHN/Tyf5+jY7JkWEj2J7PtiSl+SA68c3dEI="; c:"Date: Fri, 17 Sep 2004 23:14:31 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: Rambings on RFC2822 signatures." IIM-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:33 PM 9/17/2004 +0100, David Woodhouse wrote: >On Fri, 2004-09-17 at 12:18 -0700, Miles Libbey wrote: >> --- David Woodhouse wrote: >> > Second, it should be resilient to the common mangling which messages >> > may encounter in transit -- in particular the addition of text to the end >> > of a mail by mailing lists, by idiotic disclaimers and by self-advertising >> > virus checkers. >> >> We should be careful in this requirement. Poking holes in >> authentication means more chances for abusers. If we were to allow any >> content at the end for instance, spammers may be able to figure out how >> to replay legit messages and append their phishing information to the >> end. > >True. But I'd observe that the sender can happily convey the information >about precisely what was sent -- and it's up to the recipient to >determine how much mangling is acceptable. Which raises a good question: shouldn't the sender have something to say about this? Might some senders insist that their messages are sent perfectly in order to verify their signature, while others might be more lax (perhaps because they know they're going through a mailing list)? Both DomainKeys and the next revision of IIM have provision for specifying a canonicalization (see the b: tag on the IIM-Sig header on this message for a sample). Should we have a signature for the strict (non-canonicalized) form of the message as well, to give that option to the recipient as well? -Jim From owner-ietf-mailsig Fri Sep 17 23:37:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I6bhKa079451 for ; Fri, 17 Sep 2004 23:37:43 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I6bhkL079450 for ietf-mailsig-skb; Fri, 17 Sep 2004 23:37:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from ind-iport-1.cisco.com (ind-iport-1-sec.cisco.com [64.104.129.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I6bgXO079383 for ; Fri, 17 Sep 2004 23:37:43 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 18 Sep 2004 12:22:58 +0530 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8I6al2s024472; Fri, 17 Sep 2004 23:36:49 -0700 (PDT) Received: from fenton-w2k01.cisco.com (stealth-10-32-245-100.cisco.com [10.32.245.100]) by imail.cisco.com (8.12.5/8.12.10) with SMTP id i8I6kBZH008097; Fri, 17 Sep 2004 23:46:11 -0700 Message-Id: <4.3.2.7.2.20040917232222.036726e8@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 Sep 2004 23:37:07 -0700 To: David Woodhouse , John R Levine From: Jim Fenton Subject: Re: at last: draft-levine-mass-batv-00 Cc: Michael Thomas , Tony Finch , Dave Crocker , "ietf-mailsig@imc.org" , Sam Silberman In-Reply-To: <1095418429.31730.76.camel@imladris.demon.co.uk> References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> <16701.49629.838294.283453@mtcc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1095489974.73424"; x:"432000"; a:"rsa-sha1"; b:"nofws:1173"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"HEZg9bVpat4oSf+sQ5I3pdcc+pVSZa84W6YmdhlxnbWHny9+BnPEdAGP/pPXI" "TORMzlz87Nm+wYMxvc7MgoI2XuRXsEPxO24Rr9YgQfQs2ftfBLTzVIqYhaSqz" "zZ1dXEJWdgeuCPycG24Ib2AcEPTEp4HvXK5UUGfqliX70XPCE="; c:"Date: Fri, 17 Sep 2004 23:37:07 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: at last: draft-levine-mass-batv-00" IIM-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:53 AM 9/17/2004 +0100, David Woodhouse wrote: >Also there's the possibility of replay attacks. One possible answer is >to merely declare that the likelihood of these is low and that we hence >don't care -- the signed reverse-path is rarely made public since it's >changed by mailing lists and generally omitted by mailing list archives. There are other sources from which the signed reverse-path can be gotten. The best example I can think of is that a Trojaned MUA would have access to signed reverse-paths from all of the messages that the user had received. If you do need to assume that the reverse-path addresses are somewhat private, I wonder if it would be reasonable to just set the envelope-from on messages to some specific address, like fenton12345@cisco.com, and just not accept bounces to, for example, the 2822 "from" address. It doesn't allow for the prevention of the bounce in the first place, but it's real simple to do. The only thing that would be new is the ability to reject messages to certain addresses based on a null 2821 mail-from, indicating a bounce. I feel like I must be missing something here -- what is it? -Jim From owner-ietf-mailsig Sat Sep 18 00:25:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I7Pq8S096130 for ; Sat, 18 Sep 2004 00:25:52 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I7Pqgn096129 for ietf-mailsig-skb; Sat, 18 Sep 2004 00:25:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from Mail-Out.Odessa.Net (Mail-OUT.Odessa.Net [195.66.204.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I7PnDk096072 for ; Sat, 18 Sep 2004 00:25:51 -0700 (PDT) (envelope-from ietf-mxcomp@spam.24.odessa.ua) Message-Id: <200409180725.i8I7PnDk096072@above.proper.com> Received: (qmail 76755 invoked by uid 1166); 18 Sep 2004 10:33:22 +0300 Received: from ietf-mxcomp@spam.24.odessa.ua by mail.odessa.net by uid 89 with qmail-scanner-1.20 (f-prot: 4.3.3/3.14.8. Clear:RC:1(62.16.6.18):. Processed in 0.598497 secs); 18 Sep 2004 07:33:22 -0000 Received: from unknown (HELO tag) (62.16.6.18) by mail.odessa.net with SMTP; 18 Sep 2004 10:33:21 +0300 From: "Andriy G. Tereshchenko" To: Subject: RE: Rambings on RFC2822 signatures. Date: Sat, 18 Sep 2004 10:25:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4.3.2.7.2.20040917230814.0446db80@mira-sjc5-1.cisco.com> Thread-Index: AcSdR01m1J0h0MflSpOFZKFS0I1ylwABtMEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1218 X-Qmail-Scanner-Message-ID: <109549280265276750@mail.odessa.net> Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Somebody, possibly Jim Fenton wrote on Saturday, September 18, 2004 9:15 AM (I'm unsure) this text: > Both DomainKeys and the next revision of IIM have provision for > specifying a canonicalization (see the b: tag on the IIM-Sig > header on this message for a sample). Should we have a > signature for the strict (non-canonicalized) form of the > message as well, to give that option to the recipient as well? > I may propose other scheme for signatures. Instead of always doing canonization create a two-step signing process. 1. Compute hash code for message in canonicated form. 2. Put this information about this hash and current timestamp in email header. 3. Apply a digital signature on information from this header and To: Cc: (or Bcc: ) header. 4. Put a signature in email header. Thus people can verify if signature match hash, timestamp and their address first. And paranoid one can verify content of message after this. Thus we can solve problems with somebody can not perform canonicatation requested or message was altered in transit. People will still be able to check if this message looks like legit or clearly a forgery. If we will not store hash code for message - then nobody will be able to tell if signature is incorrect or something really bad happened with message. Replay will be avoided using timestamp and hashcode collision checks. Remailers can use additional Bcc: field data created by hashcode header. Hash for message can be an optional header and will be possible (theoretically only) to avoid in future. -- Andriy G. Tereshchenko Odessa, Ukraine From owner-ietf-mailsig Sat Sep 18 01:48:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I8m6FP022952 for ; Sat, 18 Sep 2004 01:48:06 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I8m6af022951 for ietf-mailsig-skb; Sat, 18 Sep 2004 01:48:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I8m5oU022943 for ; Sat, 18 Sep 2004 01:48:06 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i8I90R4R022460; Sat, 18 Sep 2004 02:00:27 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8I90Rws022457; Sat, 18 Sep 2004 02:00:27 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 18 Sep 2004 02:00:27 -0700 (PDT) From: "william(at)elan.net" To: David Woodhouse cc: ietf-mailsig@imc.org Subject: Re: Rambings on RFC2822 signatures. In-Reply-To: <1095437975.17821.383.camel@hades.cambridge.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004, David Woodhouse wrote: > > Here are some of the criteria which I think any RFC2822-level signature > scheme should meet. > > First, it should handle multiple signatures. A recipient may quite > reasonably want to verify and or all of the addresses in the From:, > Sender, Resent-From: and/or Resent-Sender: headers. The signature should in itself contain "from" lines at the time email was signed so as to allow to verify it at any point in the future. > Second, it should be resilient to the common mangling which messages may > encounter in transit -- in particular the addition of text to the end of > a mail by mailing lists, by idiotic disclaimers and by self-advertising > virus checkers. Obsolutely. > Also, as an adjunct to the above, it should ideally survive the > stripping of MIME parts which some mailing lists perform. Signing each > MIME part separately would be useful, rather than signing the message as > a whole. This was originally in my system in the version never publicy published, but I found it too much extra work to deal with each mime part necessry and that in 99.9999% of the cases mime do not get reordered or changed. The change I made then was to have one central signature for entire body but to have sender (first MTA that deals with message) have an option of adding signature for each mime part and in case central signature fails the final recepient can then go through that original signature and verify each mime part individually. For more info see sections 3.4.2 and step 3 of signature verification in section 3.7.2 of http://www.elan.net/~william/asrg/mta_signatures.htm I'll note that my MTA Signatures proposal is the only one that is capable of dealing with additions of emails text and new mime parts at the end of email (by very design of the proposal it has no problems with such additions) and still pass signature end-end and not move this system to authenticing only the very last signature. The next version of proposal (0.06 to be released in October) will have a refined system that takes care of some canonicalization errors and allows to double-check on the body of the message to see if it has been changed (prior to checking the signature) and should cut chance of falsely labeling email as having failed signature verification to almost 0. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam Research Worksite: http://www.elan.net/~william/asrg/ From owner-ietf-mailsig Sat Sep 18 02:11:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I9BGcW030420 for ; Sat, 18 Sep 2004 02:11:16 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I9BG99030419 for ietf-mailsig-skb; Sat, 18 Sep 2004 02:11:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I9B2pI030334 for ; Sat, 18 Sep 2004 02:11:15 -0700 (PDT) (envelope-from SRS0+19bad5fc43a4758fd958+391+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8bF9-00045d-9T; Sat, 18 Sep 2004 05:10:55 -0400 Subject: Re: Rambings on RFC2822 signatures. From: David Woodhouse To: Jim Fenton Cc: mlibbeymail-mailsig@yahoo.com, ietf-mailsig@imc.org In-Reply-To: <4.3.2.7.2.20040917230814.0446db80@mira-sjc5-1.cisco.com> References: <20040917191813.52092.qmail@web14930.mail.yahoo.com> <20040917191813.52092.qmail@web14930.mail.yahoo.com> <4.3.2.7.2.20040917230814.0446db80@mira-sjc5-1.cisco.com> Content-Type: text/plain Date: Sat, 18 Sep 2004 10:05:59 +0100 Message-Id: <1095498359.5065.53.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 2004-09-17 at 23:14 -0700, Jim Fenton wrote: > Which raises a good question: shouldn't the sender have something to > say about this? Might some senders insist that their messages are > sent perfectly in order to verify their signature, while others might > be more lax (perhaps because they know they're going through a mailing > list)? IMHO, no. Too many people add pointless virus-checker adverts and disclaimers in transit. Personally I'd _like_ to sign my message with a prohibition on such idiotic additions, but I don't think that really promotes interoperability and hence isn't really something we as a working group should advocate. The message contains a clear indication of what the sender _did_ write. The MUA could display that part in a different colour, or on a different background -- or even choose to omit the additions altogether. I would be inclined to suggest that this is enough. > Both DomainKeys and the next revision of IIM have provision for > specifying a canonicalization (see the b: tag on the IIM-Sig header on > this message for a sample). Should we have a signature for the strict > (non-canonicalized) form of the message as well, to give that option > to the recipient as well? I don't think so. I find it hard to imagine an attach in which canonicalisation gives you a way to abuse mail. Perhaps if the canonicalisation were to fold all whitespace, someone's answer could be moved from one column in a table to another column? But that's a somewhat different problem -- I really don't see how it could be abused as a spam vector. If people are sending mail which is _so_ important to keep precisely as it was sent, there are existing schemes which address that -- PGP and S/MIME. That's not an interesting problem space, I think. -- dwmw2 From owner-ietf-mailsig Sat Sep 18 02:21:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I9L4xB033661 for ; Sat, 18 Sep 2004 02:21:04 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I9L4Vi033660 for ietf-mailsig-skb; Sat, 18 Sep 2004 02:21:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from joy.songbird.com (clint.songbird.com [208.184.79.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I9L45p033652 for ; Sat, 18 Sep 2004 02:21:04 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8I9Kdg13308; Sat, 18 Sep 2004 02:20:39 -0700 From: Dave Crocker To: Jim Fenton , David Woodhouse , CC: X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Reply-To: Dave Crocker Date: Sat, 18 Sep 2004 02:20:36 -0700 Message-ID: <200491822036.106670@bbprime> In-Reply-To: <4.3.2.7.2.20040917230814.0446db80@mira-sjc5-1.cisco.com> Subject: Re: Rambings on RFC2822 signatures. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004 23:14:31 -0700, Jim Fenton wrote: > tag on the IIM-Sig header on this message for a sample). Should we have a signature for the strict (non-canonicalized) form of the message as well, to give that option to the recipient as well? unfortunately, options are not free. they carry all sorts of system-level costs for adoption and use. mostly, options should be provided because it is clear they do something extremely important, rather than merely because they are nice. -- Brandenburg InternetWorking dcrocker@brandenburg.com +1.408.246.8253 From owner-ietf-mailsig Sat Sep 18 02:51:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I9pTDq044476 for ; Sat, 18 Sep 2004 02:51:29 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I9pTus044475 for ietf-mailsig-skb; Sat, 18 Sep 2004 02:51:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I9pRO5044452 for ; Sat, 18 Sep 2004 02:51:27 -0700 (PDT) (envelope-from SRS0+19bad5fc43a4758fd958+391+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8bs6-00048L-4Q; Sat, 18 Sep 2004 05:51:11 -0400 Subject: Re: at last: draft-levine-mass-batv-00 From: David Woodhouse To: Jim Fenton Cc: John R Levine , Michael Thomas , Tony Finch , Dave Crocker , "ietf-mailsig@imc.org" , Sam Silberman In-Reply-To: <4.3.2.7.2.20040917232222.036726e8@mira-sjc5-1.cisco.com> References: <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> <16701.49629.838294.283453@mtcc.com> <4.3.2.7.2.20040917232222.036726e8@mira-sjc5-1.cisco.com> Content-Type: text/plain Date: Sat, 18 Sep 2004 10:46:12 +0100 Message-Id: <1095500773.5065.71.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 2004-09-17 at 23:37 -0700, Jim Fenton wrote: > At 11:53 AM 9/17/2004 +0100, David Woodhouse wrote: > >Also there's the possibility of replay attacks. One possible answer is > >to merely declare that the likelihood of these is low and that we hence > >don't care -- the signed reverse-path is rarely made public since it's > >changed by mailing lists and generally omitted by mailing list archives. > > There are other sources from which the signed reverse-path can be > gotten. The best example I can think of is that a Trojaned MUA would > have access to signed reverse-paths from all of the messages that the > user had received. It has been suggested that over time, MTAs could start stripping BATV reverse-paths back to the original address upon final delivery. I'm dubious about that idea -- too many people use POP3 and then use the Return-Path: header when reintroducing the mail, and there's the point which I've often made elsewhere that anything which relies on third parties to implement _anything_ is doomed. > If you do need to assume that the reverse-path addresses are somewhat > private, I wonder if it would be reasonable to just set the envelope- > from on messages to some specific address, like fenton12345@cisco.com, > and just not accept bounces to, for example, the 2822 "from" address. > It doesn't allow for the prevention of the bounce in the first place, > but it's real simple to do. The only thing that would be new is the > ability to reject messages to certain addresses based on a null 2821 > mail-from, indicating a bounce. > > I feel like I must be missing something here -- what is it? Possibly the fact that the BATV reverse-paths are expected to be dated? You only accept bounces to them for a limited period of time -- I personally use seven days. So if one _is_ harvested, it has to be a recent one for it to matter. Your suggestion of 'fenton12345@cisco.com' is just the start of a progression of slightly harder-to-forge BATV-like reverse-paths. Yes, it would instantly stop you getting a lot of backscatter. You could move from that to 'fenton20040918', and give some protection against the Trojaned MUA situation you spoke of by time-limiting the address. You could then perhaps put a simple crypto hash on that to prevent malicious forgery. And then you're fairly close to what I'm doing at the moment. What I'm doing at the moment is _also_ extremely simple to do -- it's a bunch of lines of Exim configuration and no actual 'code'. It'd be even simpler if I wasn't keeping a list of recipient domains for which I could do SRS too (although actually I'm going to drop that bit). http://david.woodhou.se/eximconf/include/routers-ses -- dwmw2 From owner-ietf-mailsig Sat Sep 18 03:30:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IAUPbs058288 for ; Sat, 18 Sep 2004 03:30:25 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IAUPM8058287 for ietf-mailsig-skb; Sat, 18 Sep 2004 03:30:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from outbound3.mail.tds.net (outbound3.mail.tds.net [216.170.230.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IAUOPM058263 for ; Sat, 18 Sep 2004 03:30:24 -0700 (PDT) (envelope-from sethg@GoodmanAssociates.com) Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186]) by outbound3.mail.tds.net (8.12.10/8.12.2) with SMTP id i8IAUHNg009182 for ; Sat, 18 Sep 2004 05:30:22 -0500 (CDT) Reply-To: From: "Seth Goodman" To: Subject: RE: at last: draft-levine-mass-batv-00 Date: Sat, 18 Sep 2004 05:30:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20040918001221.3154.qmail@xuxa.iecc.com> Importance: Normal Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: John Levine > Sent: Friday, September 17, 2004 7:12 PM > > > > >The problem here is that the draft does not explain how it deals with > >the cut and paste attack. > > There is no cut and paste attack. Due to trojaned PC's sitting behind MTA's that don't strip the return-path signature, I'm afraid that is not a realistic assessment. <...> > A bad guy could send you a zillion bounces to the same message (or > more likely, a buggy MTA) but I don't see that as a big enough threat > to be worth a large amount of mechanism to avoid. If it is a problem, > a simple band-aid that counts the amount of mail to each BATV address > and rejects mail beyond some per-address limit seems as effective as > anything else and doesn't need any support from standards. I believe these were the same methods, which we worked with and have mostly abandoned in SES, that led you to declare: > From: John Levine [mailto:johnl@iecc.com] > Sent: Thursday, September 16, 2004 8:03 PM > To: ses-devel@codeshare.ca > Subject: Re: [SES-DEVEL] SES patent <...> > I've been on the SES list all along, but I concluded quite a while ago > that SES has gotten so complicated that it's not going to be practical > to use other than in toy systems. Though we have worked out ways to do it, validation counting in a large MTA array is not easy. Setting the threshold is a guessing game at best due to the unknown forwarding relationships of the recipients. Putting in a message body hash completely stops replay with very little extra overhead at either end and makes tracking the state of individual messages unnecessary. It also facilitates end-to-end validation by the recipient asking the sender to validate the relatively short return-path via UDP followed by the recipient validating the message body with the hash. This was not the original goal of SES, either, but it has turned out to be a very welcome side-effect. > > My prototype does put a timestamp in the signature, but I do that > because I've noted that address scraping from the web is a major > source of spam targets, and that's a way to make scraping of old > archives less effective. That will prevent replay of old signatures, but not of fresh ones. Since the signature lifetime needs to be at least a week or so to allow for temporary delivery failures to resolve, there is plenty of time to harvest fresh return-paths. > > In particular, BATV is NOT a way for recipients to verify the > authenticity of arbitrary senders. I agree that remotely verifiable > bounce address signatures are an interesting idea, but this isn't it. > I also happen to think that the only reasonable way to do them is to > wait for MASS to do its thing and piggyback on top of whatever key > distribution scheme it uses rather than trying to invent our own. SES didn't start out with that idea in mind either, but it has become clear it is a good way to do this at lower overhead than competing methods. It is far lighter weight than PK schemes and has lower DDoS potential. It is simpler than SPF as neither published records nor parser nor recursive DNS lookups are required. The two return-path validation schemes we are playing with for SES are a custom UDP validation service running on the MTA but addressed through the domain MX and a "stunt" DNS server who's only task in life is to validate these signatures. Both approaches require a single-packet UDP validation request followed by a single-packet UDP response. The computational load for the sender of creating an HMAC and body hash and validating an HMAC is orders of magnitude less than creating a PK signature. The results can be cached at both ends of the link to improve performance. Similarly, calculating a body hash at the recipient is orders of magnitude less effort than validating a PK signature, so it is a win from the recipient's standpoint as well. Including a strong enough body hash in the return-path and signing it with an HMAC of sufficient length gives you more than enough forgery protection for normal email, especially considering that the signature has a limited lifetime. We have studied the cryptography enough to permit a sender to easily determine how much forgery protection they get. They choose the HMAC and message hash lengths according to their site bandwidth, signature expiration time, assumed computational strength of an attacker (size of zombie array) and likelihood of an attacker being able to succeed in a chosen text attack or guess an HMAC before the signature expires. The resulting formulae are quite simple. Validation through signed return-paths also avoids all key distribution issues and senders wishing to use this method don't have to publish _anything_ additional in their DNS. This is a very simple scheme that has some very powerful properties. Everyone has pretty much assumed that PK crypto is the only way to do real authentication, but working with this simple scheme has convinced me that is not really necessary. I think that using signed return-paths for both forged null-sender protection and originator authentication deserves serious consideration. -- Seth Goodman From owner-ietf-mailsig Sat Sep 18 08:02:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IF2csd085446 for ; Sat, 18 Sep 2004 08:02:38 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IF2cc9085445 for ietf-mailsig-skb; Sat, 18 Sep 2004 08:02:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IF2bct085438 for ; Sat, 18 Sep 2004 08:02:37 -0700 (PDT) (envelope-from sb0-067970b59b-johnl@iecc.com) Received: (qmail 18348 invoked by uid 100); 18 Sep 2004 15:02:39 -0000 Date: 18 Sep 2004 15:02:39 -0000 Message-ID: <20040918150239.18347.qmail@xuxa.iecc.com> From: John Levine To: ietf-mailsig@imc.org Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: sethg@GoodmanAssociates.com Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> There is no cut and paste attack. > Due to trojaned PC's sitting behind MTA's that don't strip the > return-path signature, I'm afraid that is not a realistic > assessment. Any host that has a message in hand with you can send you a bounce, or more than one bounce, now or with BATV, and the bounce can contain anything that host wants. That's not a cut and paste attack, that's the way bounces work. We all realize that a hostile host with a message in hand can send you a whole lot of bounces, and those bounces can contain unpleasant stuff. That's still not a cut and paste attack. Since those hosts can send you the exact spam anyway, with or without a BATV address, that's not a problem that BATV addresses, or could address. BATV deals with the specific problem of other people sending you bounces for mail you didn't send. >> My prototype does put a timestamp in the signature, ... >That will prevent replay of old signatures, but not of fresh ones. Correct. That's not a bug. That's what it's designed to do. >> In particular, BATV is NOT a way for recipients to verify the >> authenticity of arbitrary senders. > SES didn't start out with that idea in mind either, but it has > become clear it is a good way to do this at lower overhead than > competing methods. We'll have to disagree there, since the overhead required for sending hosts to remember all the mail they've sent and to respond to per-message inquiries is enormous, and trying to guess when a signature has had "too many" bounces will cause both false positives and false negatives. If you're trying to use PK bounce address signatures to let recipients verify arbitrary bounce addresses, I agree there are cut and paste problems, and complexity of trying to deal with them are also great. Since you have to read the message anyway to see if it matches the signature, I see no meaningful advantage of bounce signatures over something like domain keys. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I shook hands with Senators Dole and Inouye," said Tom, disarmingly. From owner-ietf-mailsig Sat Sep 18 09:02:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IG2odr089221 for ; Sat, 18 Sep 2004 09:02:50 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IG2o8l089220 for ietf-mailsig-skb; Sat, 18 Sep 2004 09:02:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from web14927.mail.yahoo.com (web14927.mail.yahoo.com [216.136.225.85]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8IG2ns0089214 for ; Sat, 18 Sep 2004 09:02:49 -0700 (PDT) (envelope-from mlibbeymail-mailsig@yahoo.com) Message-ID: <20040918160252.2859.qmail@web14927.mail.yahoo.com> Received: from [67.169.100.133] by web14927.mail.yahoo.com via HTTP; Sat, 18 Sep 2004 09:02:52 PDT Date: Sat, 18 Sep 2004 09:02:52 -0700 (PDT) From: Miles Libbey Reply-To: mlibbeymail-mailsig@yahoo.com Subject: Re: Rambings on RFC2822 signatures. To: ietf-mailsig@imc.org In-Reply-To: <1095498359.5065.53.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- David Woodhouse wrote: > I don't think so. I find it hard to imagine an attach in which > canonicalisation gives you a way to abuse mail. Perhaps if the > canonicalisation were to fold all whitespace, someone's answer could > be > moved from one column in a table to another column? This may allow a spammer to replay a message and add their own special content. Imagine a spammer taking a message from a bank and redefining css tags to hide the 'legit' content from the user, and appending their own special phishing text. Spammers have been attacking spam filter's 'canonicalizations' for years to hide their content. Sophos has a nice list of different attacks they have seen over the years http://www.sophos.com/spaminfo/explained/fieldguide.html Spammmers will have years and years to figure out how to take advantage of whatever canonicalization schemes are used. I doubt we'll be able to accurately predict all the attacks that will appear. miles From owner-ietf-mailsig Sat Sep 18 09:58:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IGwNmI092352 for ; Sat, 18 Sep 2004 09:58:23 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IGwNCV092351 for ietf-mailsig-skb; Sat, 18 Sep 2004 09:58:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IGwKjv092340 for ; Sat, 18 Sep 2004 09:58:20 -0700 (PDT) (envelope-from fenton@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Sep 2004 10:09:42 +0000 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8IGwFbs018728; Sat, 18 Sep 2004 09:58:16 -0700 (PDT) Received: from fenton-w2k01.cisco.com (stealth-10-32-245-100.cisco.com [10.32.245.100]) by imail.cisco.com (8.12.5/8.12.10) with SMTP id i8IH7MZH008837; Sat, 18 Sep 2004 10:07:23 -0700 Message-Id: <4.3.2.7.2.20040918094747.0453d5a0@mira-sjc5-1.cisco.com> X-Sender: fenton@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 18 Sep 2004 09:58:10 -0700 To: David Woodhouse From: Jim Fenton Subject: Re: at last: draft-levine-mass-batv-00 Cc: John R Levine , Michael Thomas , Tony Finch , Dave Crocker , "ietf-mailsig@imc.org" , Sam Silberman In-Reply-To: <1095500773.5065.71.camel@localhost.localdomain> References: <4.3.2.7.2.20040917232222.036726e8@mira-sjc5-1.cisco.com> <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> <16701.49629.838294.283453@mtcc.com> <4.3.2.7.2.20040917232222.036726e8@mira-sjc5-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1095527244.669072"; x:"432000"; a:"rsa-sha1"; b:"nofws:1568"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"mN73HCt255R3zECP21w8JZ+ImoNYjyWHpfX13G+xNYJmfFCqvWACPol25tl/u" "ZqpLnbb0SZe2J2qYlgxZn7W3u1InyPKnaYrAFmP5fUaj2PRPWiycrPUBdxMkF" "hi3un+wAPs3zEVeJdAdNN2GlgR2uM0PRjzU+O2Z4Ib6n+Jn7s="; c:"Date: Sat, 18 Sep 2004 09:58:10 -0700"; c:"From: Jim Fenton "; c:"Subject: Re: at last: draft-levine-mass-batv-00" IIM-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:46 AM 9/18/2004 +0100, David Woodhouse wrote: >> If you do need to assume that the reverse-path addresses are somewhat >> private, I wonder if it would be reasonable to just set the envelope- >> from on messages to some specific address, like fenton12345@cisco.com, >> and just not accept bounces to, for example, the 2822 "from" address. >> It doesn't allow for the prevention of the bounce in the first place, >> but it's real simple to do. The only thing that would be new is the >> ability to reject messages to certain addresses based on a null 2821 >> mail-from, indicating a bounce. >> >> I feel like I must be missing something here -- what is it? > >Possibly the fact that the BATV reverse-paths are expected to be dated? >You only accept bounces to them for a limited period of time -- I >personally use seven days. > >So if one _is_ harvested, it has to be a recent one for it to matter. Sure; I glossed over that detail. You would keep a couple of addresses that are valid for bounces, and then rotate them (maybe every 4 days or so). I'm guessing that this is close to what you're already doing. So my question is: Beyond this technique, does the crypto piece add enough additional value to be worth the trouble of key management, etc.? There was the idea of having BATV include the signature from some other signature scheme (DK, IIM, etc.) in order to limit the replay attack, and this warrants further thought. My question of about the value of the crypto piece refers just to BATV operating by itself. -Jim From owner-ietf-mailsig Sat Sep 18 10:31:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IHVCIr095713 for ; Sat, 18 Sep 2004 10:31:12 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IHVCFO095712 for ietf-mailsig-skb; Sat, 18 Sep 2004 10:31:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IHVBgs095706 for ; Sat, 18 Sep 2004 10:31:11 -0700 (PDT) (envelope-from sb0-067970b59b-johnl@iecc.com) Received: (qmail 25965 invoked by uid 100); 18 Sep 2004 17:31:14 -0000 Date: 18 Sep 2004 17:31:14 -0000 Message-ID: <20040918173114.25964.qmail@xuxa.iecc.com> From: John Levine To: ietf-mailsig@imc.org Subject: Re: at last: draft-levine-mass-batv-00 In-Reply-To: <4.3.2.7.2.20040918094747.0453d5a0@mira-sjc5-1.cisco.com> Organization: I.E.C.C., Trumansburg NY USA Cc: fenton@cisco.com Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Sure; I glossed over that detail. You would keep a couple of >addresses that are valid for bounces, and then rotate them (maybe >every 4 days or so). I'm guessing that this is close to what you're >already doing. That's basically what I'm doing. The signed bounce includes a day number and a few characters of hash so bad guys can't guess what a day's signature would be. Using the hash also means that the SMTP server can reconstruct any day's signature on the fly, so it doesn't have to keep a history of what address was used when. > So my question is: Beyond this technique, does the crypto piece add > enough additional value to be worth the trouble of key management, > etc.? To me the answer is clearly no unless it can piggybank on key management from another system like DK. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I shook hands with Senators Dole and Inouye," said Tom, disarmingly. From owner-ietf-mailsig Sat Sep 18 10:47:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IHlHUt097026 for ; Sat, 18 Sep 2004 10:47:17 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IHlHAi097025 for ietf-mailsig-skb; Sat, 18 Sep 2004 10:47:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IHl3pw096990 for ; Sat, 18 Sep 2004 10:47:16 -0700 (PDT) (envelope-from SRS0+19bad5fc43a4758fd958+391+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8jIW-0004vt-2i; Sat, 18 Sep 2004 13:46:56 -0400 Subject: Re: at last: draft-levine-mass-batv-00 From: David Woodhouse To: Jim Fenton Cc: John R Levine , Michael Thomas , Tony Finch , Dave Crocker , "ietf-mailsig@imc.org" , Sam Silberman In-Reply-To: <4.3.2.7.2.20040918094747.0453d5a0@mira-sjc5-1.cisco.com> References: <4.3.2.7.2.20040917232222.036726e8@mira-sjc5-1.cisco.com> <167502538.20040907191053@brandenburg.com> <16701.44787.905804.971494@mtcc.com> <16701.48357.274821.69478@mtcc.com> <16701.49629.838294.283453@mtcc.com> <4.3.2.7.2.20040917232222.036726e8@mira-sjc5-1.cisco.com> <4.3.2.7.2.20040918094747.0453d5a0@mira-sjc5-1.cisco.com> Content-Type: text/plain Date: Sat, 18 Sep 2004 18:41:54 +0100 Message-Id: <1095529314.5065.136.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 2004-09-18 at 09:58 -0700, Jim Fenton wrote: > >So if one _is_ harvested, it has to be a recent one for it to matter. > > Sure; I glossed over that detail. You would keep a couple of > addresses that are valid for bounces, and then rotate them (maybe > every 4 days or so). I'm guessing that this is close to what you're > already doing. Close enough. I use one address per day and don't actually bother with rotation. I used to have more -- I used to have a more precise timestamp in the domain part. But that interacted badly with some greylisting implementations -- because I generated the SES reverse-path at _delivery_ time, it was different each time. So it got greylisted anew each time :) > So my question is: Beyond this technique, does the crypto piece add > enough additional value to be worth the trouble of key management, > etc.? The trouble of key management? There's not really any trouble. The key was generated when the configuration was rolled out, and it's been there ever since. You can see that there's a way to temporarily accept bounces with one of _two_ keys, but the need to _change_ keys has been purely academic so far. The only time it would be any _trouble_ is if you wanted to change keys. And presumably you'd only ever want to change keys is if someone had got your key somehow and was maliciously using it in forged messages. And in that case presumably the crypto part _is_ worth it, because if they wanted to do that _without_ the hash in the reverse-path, it would have been trivial. So either it's absolutely no hassle, or it's worth having. I don't see much middle ground. Either way I'd say yes, the crypto _does_ add enough additional value to be worth the trouble. Others have talked about the possibility of rotating keys so that they're not in use for long enough to be cracked. I think that's overkill. A trivial hash on the address costs almost nothing in terms of management, and seems to foil the most obvious of forgeries by making sure the attacker at least has to have something you sent in the first place. But I suppose I'm not saying that from the point of view of a cryptographic expert. > There was the idea of having BATV include the signature from some > other signature scheme (DK, IIM, etc.) in order to limit the replay > attack, and this warrants further thought. I'm still ambivalent about it. It limits the replay attack only to those recipients who _check_ it. And to a large extent those recipients will be the same people who would be checking the RFC2822 scheme _anyway_ and hence wouldn't actually get any extra benefit from it. But using a signature present in a BATV reverse-path in lieu of public- key crypto perhaps merits further investigation. -- dwmw2 From owner-ietf-mailsig Sat Sep 18 11:15:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IIFCG9099229 for ; Sat, 18 Sep 2004 11:15:12 -0700 (PDT) (envelope-from owner-ietf-mailsig@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IIFC19099228 for ietf-mailsig-skb; Sat, 18 Sep 2004 11:15:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IIFBG4099222 for ; Sat, 18 Sep 2004 11:15:12 -0700 (PDT) (envelope-from SRS0+19bad5fc43a4758fd958+391+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C8jju-0004xw-JG; Sat, 18 Sep 2004 14:15:15 -0400 Subject: Re: Rambings on RFC2822 signatures. From: David Woodhouse To: mlibbeymail-mailsig@yahoo.com Cc: ietf-mailsig@imc.org In-Reply-To: <20040918160252.2859.qmail@web14927.mail.yahoo.com> References: <20040918160252.2859.qmail@web14927.mail.yahoo.com> Content-Type: text/plain Date: Sat, 18 Sep 2004 19:10:12 +0100 Message-Id: <1095531012.5065.161.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mailsig@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 2004-09-18 at 09:02 -0700, Miles Libbey wrote: > --- David Woodhouse wrote: > > I don't think so. I find it hard to imagine an attach in which > > canonicalisation gives you a way to abuse mail. > > Spammers have been attacking spam filter's 'canonicalizations' for > years to hide their content. Sophos has a nice list of different > attacks they have seen over the years > http://www.sophos.com/spaminfo/explained/fieldguide.html > > Spammmers will have years and years to figure out how to take advantage > of whatever canonicalization schemes are used. I doubt we'll be able > to accurately predict all the attacks that will appear. Let's separate canonicalisation and permissiveness. Canonicalisation means stuff like undoing base64 encoding, converting charsets to UTF-8, folding whitespace in _headers_ and maybe most of text/html (outside 

, etc) but not in text/plain.

The bit with allowing the addition of lines -- or at least being able to
tell that the signed part is still valid despite the addition of lines
(I didn't say that/when the recipient had to _allow_ it) -- is
permissiveness, and that's what seems to be needed to allow most of the
attacks in the field guide you reference.

Speaking personally, I'm most concerned about the additions by mailing
lists, and on text/plain MIME parts.

I would be more than happy to allow _no_ permissiveness on text/html
parts. Because an attacker could start with '<-- ' and end with ' -->'
followed by a line or two of their own text, and still have a tiny
percentage of 'addition'.

Anyone who wants us to be permissive on text/html should be prepared to
put forward very good arguments that it cannot be exploited. On
text/plain I think we're a lot safer to allow a few lines added at start
and/or end of the original.

-- 
dwmw2


From owner-ietf-mailsig Sat Sep 18 11:37:39 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IIbd1C000524
	for ; Sat, 18 Sep 2004 11:37:39 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8IIbd1a000523
	for ietf-mailsig-skb; Sat, 18 Sep 2004 11:37:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from sokol.elan.net (sokol.elan.net [216.151.192.200])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IIbbV8000517
	for ; Sat, 18 Sep 2004 11:37:37 -0700 (PDT)
	(envelope-from william@elan.net)
Received: from sokol.elan.net (localhost.localdomain [127.0.0.1])
	by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i8IIo6gj005481;
	Sat, 18 Sep 2004 11:50:06 -0700
Received: from localhost (william@localhost)
	by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8IIo25t005478;
	Sat, 18 Sep 2004 11:50:02 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Sat, 18 Sep 2004 11:50:02 -0700 (PDT)
From: "william(at)elan.net" 
To: David Woodhouse 
cc: mlibbeymail-mailsig@yahoo.com, 
Subject: Re: Rambings on RFC2822 signatures.
In-Reply-To: <1095531012.5065.161.camel@localhost.localdomain>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sat, 18 Sep 2004, David Woodhouse wrote:

> Let's separate canonicalisation and permissiveness. Canonicalisation
> means stuff like undoing base64 encoding, converting charsets to UTF-8,
> folding whitespace in _headers_ and maybe most of text/html (outside
> 
, etc) but not in text/plain.

And these canonicalisaion problems are not easy to deal with unfortunetly.
But I also found that almost all conversion of message (especially more
serious ones like charset conversion, etc) occurs at the time of message
delivery to final recepient. That means if we require MDA to verify
signature prior to doing these conversions, we're mostly ok. But things
like base64 conversions are more common by intermediate remailers and
do have to be dealt with.

> The bit with allowing the addition of lines -- or at least being able to
> tell that the signed part is still valid despite the addition of lines
> (I didn't say that/when the recipient had to _allow_ it) -- is
> permissiveness, and that's what seems to be needed to allow most of the
> attacks in the field guide you reference.

It would be MUA that need to identify part that is signed and that 
references certain identity and part that was not signed by same way.
And I think this can be implemented in the way so that even ordinary
luser will see that forgery is being attempted.

Additionally there are other ways to protect from having one signed
email reused inappropriatly. That includes embeding message id and 
timestamp of the message as part of the signature and as well as having 
public key that is used expire, etc.
 
> Speaking personally, I'm most concerned about the additions by mailing
> lists, and on text/plain MIME parts.
Exactly.
 
> I would be more than happy to allow _no_ permissiveness on text/html
> parts. Because an attacker could start with '<-- ' and end with ' -->'
> followed by a line or two of their own text, and still have a tiny
> percentage of 'addition'.
Agreed. One fully created MIME part should stay the way it is.
But new MIME parts (text or html) it should be possible to add to email
message and without disturbing original signature (i.e. it should
still be possible to verify that signature by any consequitive system)

---
William Leibzon, Elan Networks:
 mailto: william@elan.net
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/


From owner-ietf-mailsig Sat Sep 18 13:49:31 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IKnVDh009102
	for ; Sat, 18 Sep 2004 13:49:31 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8IKnVtx009101
	for ietf-mailsig-skb; Sat, 18 Sep 2004 13:49:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound1.mail.tds.net (outbound1.mail.tds.net [216.170.230.91])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IKnUlb009093
	for ; Sat, 18 Sep 2004 13:49:30 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound1.mail.tds.net (8.12.10/8.12.2) with SMTP id i8IKnUif022501
	for ; Sat, 18 Sep 2004 15:49:33 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: 
Subject: RE: at last:  draft-levine-mass-batv-00
Date: Sat, 18 Sep 2004 15:49:34 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <20040918150239.18347.qmail@xuxa.iecc.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: John Levine
> Sent: Saturday, September 18, 2004 10:03 AM

<...>

> >> My prototype does put a timestamp in the signature, ...
>
> >That will prevent replay of old signatures, but not of fresh ones.
>
> Correct.  That's not a bug.  That's what it's designed to do.

So you want to get replay attacks based on freshly harvested signatures?
That is a feature only in Microsoft lingo.  When something is designed to
perform an undesirable action, most people call that a bug :)

>
>
> >> In particular, BATV is NOT a way for recipients to verify the
> >> authenticity of arbitrary senders.
>
> > SES didn't start out with that idea in mind either, but it has
> > become clear it is a good way to do this at lower overhead than
> > competing methods.
>
> We'll have to disagree there, since the overhead required for sending
> hosts to remember all the mail they've sent and to respond to
> per-message inquiries is enormous, and trying to guess when a
> signature has had "too many" bounces will cause both false positives
> and false negatives.

The system you refer to above is an older design.  The current scheme no
longer requires the sender to track any mail sent or the number of
validation requests, nor do the return-paths any longer have to be unique
per-message.  We accomplish this by putting a message body hash in the
return-path.  Since this is signed by the HMAC, it permanently ties that
specific message body with that specific return-path.  The replay is foiled
by the recipient, who finds that the message hash does not match the one in
the validated return-path and rejects at the end of data.  This is very low
overhead at both ends.  Since it is stateless, validation results for
return-paths can be cached at both ends until the signature expires.  It is
an HMAC validation via UDP for the sender and if the return-path validates,
the recipient does a body hash computation to check for replay.  Trivial
forgeries can be rejected before data, and replays are rejected at the end
of data.  Either way, no forgeries using signed return-paths that support
validation get through.

>
> If you're trying to use PK bounce address signatures to let recipients
> verify arbitrary bounce addresses, I agree there are cut and paste
> problems, and complexity of trying to deal with them are also great.
> Since you have to read the message anyway to see if it matches the
> signature, I see no meaningful advantage of bounce signatures over
> something like domain keys.

The system described above is, for all practical purposes, as strong an
authentication mechanism as DK.  In fact, if the signing keys at the sender
are per-user, it gives a higher grade of originator authentication.  The
advantages are that there is no key management system required, no public
keys in DNS or PKI and the computational load is orders of magnitude less
that any PK scheme.  PK validation at the recipient is very compute
intensive.  This system substitutes an HMAC validation for a PK signature
validation.  In terms of overall complexity, network resources and
computational load, it's not even close.

--

Seth Goodman


From owner-ietf-mailsig Sat Sep 18 14:02:04 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IL24Gq009741
	for ; Sat, 18 Sep 2004 14:02:04 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8IL24nW009740
	for ietf-mailsig-skb; Sat, 18 Sep 2004 14:02:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound2.mail.tds.net (outbound2.mail.tds.net [216.170.230.92])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IL23uq009734
	for ; Sat, 18 Sep 2004 14:02:03 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound2.mail.tds.net (8.12.10/8.12.2) with SMTP id i8IL21RT020848
	for ; Sat, 18 Sep 2004 16:02:06 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: 
Subject: RE: at last:  draft-levine-mass-batv-00
Date: Sat, 18 Sep 2004 16:02:07 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <1095529314.5065.136.camel@localhost.localdomain>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: David Woodhouse
> Sent: Saturday, September 18, 2004 12:42 PM

<...>

> Others have talked about the possibility of rotating keys so that
> they're not in use for long enough to be cracked. I think that's
> overkill.

Actually, we rotated the keys in the SES scheme to allow a very short
timestamp field, not to prevent key cracking.  If the keys are changed
periodically, the timestamp only has to cover the period of key change.
This prevents replay of old signatures when the truncated date code comes
around again.

Key cracking for the 512-bit HMAC keys we are using is not practical given
the number of messages signed with the same key an attacker has access to.
With less than the optimal number of messages (2^256), an attacker must use
your validation server as a resource.  The number of HMAC result bits is
then chosen so that given the bandwidth of your validation server and the
signature lifetime, a signature guessing attack cannot succeed with
reasonable probability (which you can also specify appropriate to your level
of paranoia).

--

Seth Goodman


From owner-ietf-mailsig Sat Sep 18 14:32:14 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ILWE3o011513
	for ; Sat, 18 Sep 2004 14:32:14 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8ILWEpG011512
	for ietf-mailsig-skb; Sat, 18 Sep 2004 14:32:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound2.mail.tds.net (outbound2.mail.tds.net [216.170.230.92])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ILWDB4011505
	for ; Sat, 18 Sep 2004 14:32:13 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound2.mail.tds.net (8.12.10/8.12.2) with SMTP id i8ILWGRT024148
	for ; Sat, 18 Sep 2004 16:32:17 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: 
Subject: RE: at last:  draft-levine-mass-batv-00
Date: Sat, 18 Sep 2004 16:32:18 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: Seth Goodman
> Sent: Saturday, September 18, 2004 4:02 PM

<...>

> Key cracking for the 512-bit HMAC keys we are using is not practical given
> the number of messages signed with the same key an attacker has access to.
> With less than the optimal number of messages (2^256), an attacker must
> use your validation server as a resource.  The number of HMAC result bits
> is then chosen so that given the bandwidth of your validation server and
> the signature lifetime, a signature guessing attack cannot succeed with
> reasonable probability (which you can also specify appropriate to
> your level of paranoia).

This was not stated as well, as it confuses two types of attack: key
cracking and HMAC guessing.  Key cracking is not what sets the limit for the
number of HMAC result bits.  Key cracking is considered infeasible for any
foreseeable computational capability even with the optimal number of sample
messages.  The number of HMAC result bits needed is determined by the HMAC
guessing attack, where an attacker tries to guess an HMAC that is correct
for a given return-path that they wish to forge.  Since they don't know the
key, having sample signed return-paths is of no use and they must use the
sender's validation server to check their guesses.  The validation server
throughput, which is limited by site communications bandwidth, and signature
lifetime are the limiting values along with desired probably of success of
an attack.  Though we would like it to be zero, you have to settle for some
low probability of successful attack to avoid needing an infinite number of
bits, just like any signature scheme.

--

Seth Goodman



From owner-ietf-mailsig Sat Sep 18 16:41:58 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8INfwRx018451
	for ; Sat, 18 Sep 2004 16:41:58 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8INfw3E018450
	for ietf-mailsig-skb; Sat, 18 Sep 2004 16:41:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8INfvma018443
	for ; Sat, 18 Sep 2004 16:41:57 -0700 (PDT)
	(envelope-from sb0-067970b59b-johnl@iecc.com)
Received: (qmail 15012 invoked by uid 100); 18 Sep 2004 23:42:02 -0000
Date: 18 Sep 2004 23:42:02 -0000
Message-ID: <20040918234202.15011.qmail@xuxa.iecc.com>
From: John Levine 
To: ietf-mailsig@imc.org
Subject: Re: at last:  draft-levine-mass-batv-00
In-Reply-To: 
Organization: I.E.C.C., Trumansburg NY USA
Cc: sethg@GoodmanAssociates.com
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


>> >> My prototype does put a timestamp in the signature, ...
>>
>> >That will prevent replay of old signatures, but not of fresh ones.
>>
>> Correct.  That's not a bug.  That's what it's designed to do.
>
>So you want to get replay attacks based on freshly harvested signatures?

It is increasingly clear that whatever problem SES is purporting to
solve is unrelated to any problem that I can identify in the real world
so I'm out of here.  Bye.

-- 
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711
johnl@iecc.com, Mayor, http://johnlevine.com, 
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail


From owner-ietf-mailsig Sat Sep 18 21:39:28 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J4dSSS033092
	for ; Sat, 18 Sep 2004 21:39:28 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8J4dSnY033091
	for ietf-mailsig-skb; Sat, 18 Sep 2004 21:39:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound1.mail.tds.net (outbound1.mail.tds.net [216.170.230.91])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J4dRV1033085
	for ; Sat, 18 Sep 2004 21:39:27 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound1.mail.tds.net (8.12.10/8.12.2) with SMTP id i8J4dVif011301;
	Sat, 18 Sep 2004 23:39:31 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: "John Levine" 
Cc: 
Subject: RE: at last:  draft-levine-mass-batv-00
Date: Sat, 18 Sep 2004 23:39:35 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <20040918234202.15011.qmail@xuxa.iecc.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: John Levine
> Sent: Saturday, September 18, 2004 6:42 PM
>
>
>
> >> >> My prototype does put a timestamp in the signature, ...
> >>
> >> >That will prevent replay of old signatures, but not of fresh ones.
> >>
> >> Correct.  That's not a bug.  That's what it's designed to do.
> >
> >So you want to get replay attacks based on freshly harvested signatures?
>
> It is increasingly clear that whatever problem SES is purporting to
> solve is unrelated to any problem that I can identify in the real world
> so I'm out of here.  Bye.


I find your attitude curious.  Where shall I start?

No one who currently uses a signed envelope protocol experiences replay
because you can count the number of implementations on the fingers of one
hand.  As more sites use this, the situation will change.  Trojaned PC's
exist and will continue to do so, and when there are enough sites using
signed envelopes, whether for blowback protection or authentication, it will
become worthwhile to exploit.  Ignoring the problem will not make it go
away.

Even if I were to agree with you on this particular issue, there were a lot
of other people who saw this protocol and immediately felt that was a
serious weakness that needed to be addressed.  Personally, I don't think it
will be as bad a problem as some other people have expressed, but it could
easily become a persistent nuisance.  My approach has been to make the
likelihood of a replay attack achieving even a single delivery extremely
low.  If that is made abundantly clear from the outset, my guess is that
spammers will probably not bother, since it is clear they will never earn a
nickel from it.  If they decide to mount a retaliatory DDoS, there are far
more efficient mechanisms for which there are no effective defenses.

One of several real world problems that SES "purports" to solve is
authentication.  Though you have clearly stated your preference for DK, SES
is a real alternative that is lighter weight and has a number of other
useful properties, including the ability to reject domain forgeries before
data with fewer issues than SPF.  This is for real systems, not "toy
systems", and we will be doing some implementations on large sites for proof
of concept.  Both our project and yours would benefit from other cluefull
people participating, but if you think it will turn out better if you do it
all yourself, that is your prerogative.

The SES work started long before you "re-invented it as BATV" (Meng Weng
Wong's words on SPF-Discuss on more than one occasion) and will continue
whether you choose to participate or not.  We were actively working on these
ideas for some time before our forum was established, and the discussion
there has been very active, so I think we have something to contribute.

Since the BATV and SES groups started with the same basic idea, it would be
a pity not to collaborate.  That appears to be your preference, but I hope
that your colleagues are still open to working together.  If the other
members of your group feel as you do, we can proceed with our own
implementation and submit our own draft without the mutual benefit of
cooperation.  What is the preference of the other members of the BATV group
and the chairs of the Mailsig group?

--

Seth Goodman


From owner-ietf-mailsig Sat Sep 18 21:58:05 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J4w55U034875
	for ; Sat, 18 Sep 2004 21:58:05 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8J4w5aN034874
	for ietf-mailsig-skb; Sat, 18 Sep 2004 21:58:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound3.mail.tds.net (outbound3.mail.tds.net [216.170.230.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J4w4gd034868
	for ; Sat, 18 Sep 2004 21:58:04 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound3.mail.tds.net (8.12.10/8.12.2) with SMTP id i8J4w4Ng010530;
	Sat, 18 Sep 2004 23:58:04 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: 
Cc: "David Woodhouse" 
Subject: RE: Rambings on RFC2822 signatures.
Date: Sat, 18 Sep 2004 23:58:08 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <1095531012.5065.161.camel@localhost.localdomain>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: David Woodhouse
> Sent: Saturday, September 18, 2004 1:10 PM

<...>

> The bit with allowing the addition of lines -- or at least being able to
> tell that the signed part is still valid despite the addition of lines
> (I didn't say that/when the recipient had to _allow_ it) -- is
> permissiveness, and that's what seems to be needed to allow most of the
> attacks in the field guide you reference.
>
> Speaking personally, I'm most concerned about the additions by mailing
> lists, and on text/plain MIME parts.

Mailing lists have to resend it as their own outgoing message anyway.  It is
not really necessary to preserve all the signatures through the re-mailing
process.  The mailing list could validate the signature on the incoming
message, add a header or even body line indicating that fact and sign it on
the way out.  I don't really see the need for the end user to be able to
absolutely validate the identities on mailing list posts at the MUA.  That
sounds like a list function.  Lists do it now by the submitting address
(broken ones use the return-path), so they can switch to validating
signatures instead.

The idea that all MUA's would have to change to deal with displaying
multiple signed parts in different colors, as well as noting parts whose
signature doesn't validate does not bode well for adoption.


>
> I would be more than happy to allow _no_ permissiveness on text/html
> parts. Because an attacker could start with '<-- ' and end with ' -->'
> followed by a line or two of their own text, and still have a tiny
> percentage of 'addition'.
>
> Anyone who wants us to be permissive on text/html should be prepared to
> put forward very good arguments that it cannot be exploited. On
> text/plain I think we're a lot safer to allow a few lines added at start
> and/or end of the original.

I suggest we don't have to allow additions at all, in any of the MIME parts.
The irritating virus scan adverts in the message body are usually put on at
the originating or destination ends, so the signatures can be created after
the addition and validated before any subsequent addition.  Any forwarder
that puts anything in the message body rather than the headers deserves to
have his messages rejected.  That will break virtually any signature scheme,
so what is the motivation to allow this poor practice to continue?

--

Seth Goodman


From owner-ietf-mailsig Sat Sep 18 22:20:54 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J5KsPh042412
	for ; Sat, 18 Sep 2004 22:20:54 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8J5KsUh042411
	for ietf-mailsig-skb; Sat, 18 Sep 2004 22:20:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from joy.songbird.com (clint.songbird.com [208.184.79.11])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J5KrUY042401
	for ; Sat, 18 Sep 2004 22:20:53 -0700 (PDT)
	(envelope-from dhc@dcrocker.net)
Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8J5Kug23443;
	Sat, 18 Sep 2004 22:20:56 -0700
From: Dave Crocker 
To: , 
X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION
X-URL: http://www.pocomail.com/
Reply-To: Dave Crocker 
Date: Sat, 18 Sep 2004 22:20:53 -0700
Message-ID: <2004918222053.123988@bbprime>
In-Reply-To: 
Subject: RE: at last:  draft-levine-mass-batv-00
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 



On Sat, 18 Sep 2004 05:30:23 -0500, Seth Goodman wrote:
>    Putting in a
>  message body hash completely stops replay with very little extra overhead at
>  either end and makes tracking the state of individual messages unnecessary.

Once you include a hash of the message body, then validation requires going 
beyond the envelope, to look at the message body.

Hence it is not at all clear that you need to actually put the message hash into 
the RFC2821.MailFrom BATV encoding.  You might want some linkage between the 
two, but that's not the same as "including" the hash.

In any event, these sorts of extended discussions about extended utility are 
fine to have, but it is potentially a rich space to explore.  One needs to 
remember that, to date, no messaging-based (or, for that matter, 
originator-based) public key signing scheme has gained Internet-scale deployment 
and use.  

So we would be wise to take that dependency out of the critical path to the 
underlying MailFrom signing mechanisms.  And, indeed, that is what the current 
BATV spec has done, while leaving things open for infinite experimentation with 
those possible enhancements.

d/
--
Brandenburg InternetWorking
dcrocker@brandenburg.com
+1.408.246.8253




From owner-ietf-mailsig Sun Sep 19 01:05:31 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J85Va3006410
	for ; Sun, 19 Sep 2004 01:05:31 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8J85VdF006409
	for ietf-mailsig-skb; Sun, 19 Sep 2004 01:05:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J85HUo006306
	for ; Sun, 19 Sep 2004 01:05:30 -0700 (PDT)
	(envelope-from SRS0+cc5810394dac36bdc22f+392+infradead.org+dwmw2@canuck.srs.infradead.org)
Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253])
	by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux))
	id 1C8wh7-00067y-Va; Sun, 19 Sep 2004 04:05:14 -0400
Subject: RE: Rambings on RFC2822 signatures.
From: David Woodhouse 
To: sethg@GoodmanAssociates.com
Cc: ietf-mailsig@imc.org
In-Reply-To: 
References: 
Content-Type: text/plain
Date: Sun, 19 Sep 2004 09:00:06 +0100
Message-Id: <1095580806.5065.181.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) 
Content-Transfer-Encoding: 7bit
X-SRS-Rewrite: SMTP reverse-path rewritten from  by canuck.infradead.org
	See http://www.infradead.org/rpr.html
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sat, 2004-09-18 at 23:58 -0500, Seth Goodman wrote:
> Mailing lists have to resend it as their own outgoing message anyway.  It is
> not really necessary to preserve all the signatures through the re-mailing
> process.  The mailing list could validate the signature on the incoming
> message, add a header or even body line indicating that fact and sign it on
> the way out.  I don't really see the need for the end user to be able to
> absolutely validate the identities on mailing list posts at the MUA.  That
> sounds like a list function.  Lists do it now by the submitting address
> (broken ones use the return-path), so they can switch to validating
> signatures instead.

I disagree. That reduces it to a hop-by-hop scheme again. In order to
determine the probability that this message really did come from me,
you'd have to ponder how much you trust the list server to have actually
checked.

> The idea that all MUA's would have to change to deal with displaying
> multiple signed parts in different colors, as well as noting parts whose
> signature doesn't validate does not bode well for adoption.

That's a purely optional optimisation. If any scheme _required_ such a
thing to be implemented by all recipients, the scheme would of course be
doomed.

> I suggest we don't have to allow additions at all, in any of the MIME parts.
> The irritating virus scan adverts in the message body are usually put on at
> the originating or destination ends, so the signatures can be created after
> the addition and validated before any subsequent addition.  Any forwarder
> that puts anything in the message body rather than the headers deserves to
> have his messages rejected.  That will break virtually any signature scheme,
> so what is the motivation to allow this poor practice to continue?

Now you sound like the SPF folks declaring forwarding to be 'poor
practice' or 'forgery'. Let us not consider it 'poor practice'; let us
consider it 'current practice'.

And in the case of mailing lists it's a practice that some will defend
robustly. I _like_ having unsubscription instructions on every mail
which is sent to my lists. People are in general too stupid for me to
omit that.

-- 
dwmw2


From owner-ietf-mailsig Sun Sep 19 01:24:43 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J8OhUp012732
	for ; Sun, 19 Sep 2004 01:24:43 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8J8Ohgn012731
	for ietf-mailsig-skb; Sun, 19 Sep 2004 01:24:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from Mail-Out.Odessa.Net (Mail-OUT.Odessa.Net [195.66.204.51])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J8Of7A012676
	for ; Sun, 19 Sep 2004 01:24:42 -0700 (PDT)
	(envelope-from ietf-mxcomp@spam.24.odessa.ua)
Message-Id: <200409190824.i8J8Of7A012676@above.proper.com>
Received: (qmail 69998 invoked by uid 1166); 19 Sep 2004 11:32:14 +0300
Received: from ietf-mxcomp@spam.24.odessa.ua by mail.odessa.net by uid 89 with qmail-scanner-1.20 
 (f-prot: 4.3.3/3.14.8.  Clear:RC:1(62.16.6.18):. 
 Processed in 1.644953 secs); 19 Sep 2004 08:32:14 -0000
Received: from unknown (HELO tag) (62.16.6.18)
  by mail.odessa.net with SMTP; 19 Sep 2004 11:32:12 +0300
From: "Andriy G. Tereshchenko" 
To: 
Subject: RE: Rambings on RFC2822 signatures.
Date: Sun, 19 Sep 2004 11:24:41 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1218
Thread-Index: AcSdqLWZdk1idMnJSvqg9+h5U10sLAAeMScgAAAOhSA=
X-Qmail-Scanner-Message-ID: <109558273465269981@mail.odessa.net>
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> Let's separate canonicalisation and permissiveness. 

Strongly agree !!

> Canonicalisation means stuff like undoing base64 encoding, con
v              ert
i              ng ch
a             rsets to UTF-8, foldin
g             whitespace in _heade
r              s_ 
a             nd maybe most of text/html (outside 
, etc) but not in text/plain.

--
Andriy G. Tereshchenko
Odessa, Ukraine 


From owner-ietf-mailsig Sun Sep 19 01:43:58 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J8hwM4018647
	for ; Sun, 19 Sep 2004 01:43:58 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8J8hwvf018646
	for ietf-mailsig-skb; Sun, 19 Sep 2004 01:43:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J8hvuh018621
	for ; Sun, 19 Sep 2004 01:43:58 -0700 (PDT)
	(envelope-from SRS0+cc5810394dac36bdc22f+392+infradead.org+dwmw2@canuck.srs.infradead.org)
Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253])
	by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux))
	id 1C8xIX-0005WI-6G; Sun, 19 Sep 2004 04:43:53 -0400
Subject: RE: Rambings on RFC2822 signatures.
From: David Woodhouse 
To: "Andriy G. Tereshchenko" 
Cc: ietf-mailsig@imc.org
In-Reply-To: <200409190824.i8J8Of7A012676@above.proper.com>
References: <200409190824.i8J8Of7A012676@above.proper.com>
Content-Type: text/plain
Date: Sun, 19 Sep 2004 09:38:45 +0100
Message-Id: <1095583125.5065.192.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) 
Content-Transfer-Encoding: 7bit
X-SRS-Rewrite: SMTP reverse-path rewritten from  by canuck.infradead.org
	See http://www.infradead.org/rpr.html
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sun, 2004-09-19 at 11:24 +0300, Andriy G. Tereshchenko wrote:
> > Let's separate canonicalisation and permissiveness. 
> 
> Strongly agree !!
> 
> > Canonicalisation means stuff like undoing base64 encoding, con
> v              ert
> i              ng ch
> a             rsets to UTF-8, foldin
> g             whitespace in _heade
> r              s_ 
> a             nd maybe most of text/html (outside 
, etc) but not in text/plain.

Cute. :)

Even in HTML, that change wouldn't be hidden due to canonicalisation. In
HTML a space may sometimes be considered equivalent to multiple spaces,
but it's not considered equivalent to _zero_ spaces. So the addition of
spaces _within_ words like that would break the signature under any sane
canonicalisation scheme.

Obviously in text/plain no mangling of whitespace should be accepted
under the banner of 'canonicalisation'. With the possible limited
exception of 'format=flowed'.

Whether we want to allow such things under any _permissiveness_ scheme
is a different matter. I'd say 'no' -- the only thing we really need to
deal with is charset/encoding conversions and the common case of a few
lines being added at start or end of the mail -- and maybe MIME parts
being removed from the mail.

-- 
dwmw2


From owner-ietf-mailsig Sun Sep 19 02:23:34 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J9NX3l032149
	for ; Sun, 19 Sep 2004 02:23:33 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8J9NXlJ032148
	for ietf-mailsig-skb; Sun, 19 Sep 2004 02:23:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound3.mail.tds.net (outbound3.mail.tds.net [216.170.230.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8J9NWm4032138
	for ; Sun, 19 Sep 2004 02:23:33 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound3.mail.tds.net (8.12.10/8.12.2) with SMTP id i8J9NSNg005038;
	Sun, 19 Sep 2004 04:23:31 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: "Dave Crocker" , 
Subject: RE: at last:  draft-levine-mass-batv-00
Date: Sun, 19 Sep 2004 04:23:34 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <2004918222053.123988@bbprime>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: Dave Crocker
> Sent: Sunday, September 19, 2004 12:21 AM
>
>
>
>
> On Sat, 18 Sep 2004 05:30:23 -0500, Seth Goodman wrote:
> > Putting in a  message body hash completely stops replay
> > with very little extra overhead at either end and makes
> > tracking the state of individual messages unnecessary.
>
> Once you include a hash of the message body, then validation
> requires going beyond the envelope, to look at the message
> body.

It is a two-step validation process.  First the recipient validates the
return-path itself before data.  If this validation fails, as in the case of
domain forgery, the message can be rejected at this point.  Only if the
sender validates the return-path does the recipient need to go into data.
The only reason for the recipient to match the message body hash with that
in the validated return-path is to detect a replay of a valid return-path
with a new message.


>
> Hence it is not at all clear that you need to actually put the
> message hash into the RFC2821.MailFrom BATV encoding.  You might
> want some linkage between the two, but that's not the same as
> "including" the hash.

So far, we have only come up with two general ways to link the return-path
to the message body in a lightweight and forgery-resistant manner to detect
replay:

1) put a hash of the message body into the return-path and protect it with
an HMAC;

2) protect only the return-path with an HMAC; put a hash that covers the
message body _and_ the return-path into a header and protect it with a
second HMAC;

The second alternative has two signatures to validate.  The first is to
detect domain forgeries and null-sender forgeries before data.  The second
is to detect replay after data.  This would require two validations, so the
first alternative appears more attractive, except for the extra length taken
out of the local-part.  Of course, the signature in the header can be a PK
signature, but then the validation is much more expensive for the recipient
and the sender has to implement a key distribution scheme.  Can you think of
other ways to link the return-path and message body in a lightweight manner
that an attacker cannot forge?


>
> In any event, these sorts of extended discussions about extended
> utility are fine to have, but it is potentially a rich space to
> explore.  One needs to remember that, to date, no messaging-based
> (or, for that matter, originator-based) public key signing scheme
> has gained Internet-scale deployment and use.

I am aware of that reality.  It may be a fine point, but this is not a
public key signature.  It is a one-way keyed hash signature that can only be
validated by the originator.  But your point is well-taken.  A large part of
our motivation lies in the fact that it seems likely that SPF will come to
fruition.  In its present form, it cannot validate originating addresses in
the presence of forwarding and it requires changes to existing mail practice
to even deliver forwarded mail.  These are major problems caused by their
choice of hop-by-hop validation, yet SPF is still moving rapidly towards
adoption.

A signed return-path protocol for validation of forwards will fix both of
these problems inherent in SPF.  It will not fix the other problems of SPF,
such as excessive recursive lookups in DNS and the ability to designate
hosts that don't belong to you, but it would be a major victory to not have
to change current forwarding practices that would break non-compliant
systems.  Having realized that sender validation of signed return-paths can
provide lightweight authentication of forwards, it became obvious that this
would work for direct deliveries as well.  There would be no need for SPF
records or any other special information in DNS for that matter.

The likely deployment of SPF shortens the time window for experimentation if
something like this is going to be used with SPF.  Once a signed return-path
validation protocol is in place as part of SPF, it is our hope that people
will realize that the SPF part really doesn't add much value and the SES
protocol provides originator authentication with less effort and less
breakage than SPF.  It is a compromise between designated sender and public
key schemes.  One might consider it a designated validator scheme.  The
sender applies a signature and then designates a host to validate the
signatures, which happens to always be the domain MX.

>
> So we would be wise to take that dependency out of the critical
> path to the underlying MailFrom signing mechanisms.  And, indeed,
> that is what the current BATV spec has done, while leaving things
> open for infinite experimentation with those possible enhancements.

While that is wise in terms of getting a general BATV spec on the standards
track, we are faced with a fairly narrow time window if we wish to see
something other than SRS or SUBMITTER and changes to 2822 Resent-* header
usage deployed with SPF.  The people who are currently working on SES are
very interesting in finishing a protocol and writing a spec within that time
window.  Most of us feel that SRS, SUBMITTER and the changes to 2822
forwarding practices would be very bad for the internet mail system.  Yet
the SPF crowd does not seem concerned, nor does MARID.  We have to offer a
real alternative, including a proven implementation, if we are to have a
chance at preventing this.  Since one of the people in our group is the
primary author and maintainer of one of the two C SPF libraries, we are in
an excellent position to implement, test and validate something that can
achieve fairly wide distribution in a short time.

I hope this better explains our motivations.  I would welcome your advice.

--

Seth Goodman


From owner-ietf-mailsig Sun Sep 19 04:32:58 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JBWwv1069198
	for ; Sun, 19 Sep 2004 04:32:58 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JBWwJ0069197
	for ietf-mailsig-skb; Sun, 19 Sep 2004 04:32:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JBWj5s069180
	for ; Sun, 19 Sep 2004 04:32:58 -0700 (PDT)
	(envelope-from SRS0+cc5810394dac36bdc22f+392+infradead.org+dwmw2@canuck.srs.infradead.org)
Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253])
	by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux))
	id 1C8zvs-0005gA-Ib; Sun, 19 Sep 2004 07:32:41 -0400
Subject: RE: at last:  draft-levine-mass-batv-00
From: David Woodhouse 
To: sethg@GoodmanAssociates.com
Cc: Dave Crocker , ietf-mailsig@imc.org
In-Reply-To: 
References: 
Content-Type: text/plain
Date: Sun, 19 Sep 2004 12:27:28 +0100
Message-Id: <1095593249.5065.210.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) 
Content-Transfer-Encoding: 7bit
X-SRS-Rewrite: SMTP reverse-path rewritten from  by canuck.infradead.org
	See http://www.infradead.org/rpr.html
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sun, 2004-09-19 at 04:23 -0500, Seth Goodman wrote:
> > In any event, these sorts of extended discussions about extended
> > utility are fine to have, but it is potentially a rich space to
> > explore.  One needs to remember that, to date, no messaging-based
> > (or, for that matter, originator-based) public key signing scheme
> > has gained Internet-scale deployment and use.
> 
> I am aware of that reality.  It may be a fine point, but this is not a
> public key signature.  It is a one-way keyed hash signature that can only be
> validated by the originator.  But your point is well-taken.  A large part of
> our motivation lies in the fact that it seems likely that SPF will come to
> fruition. 

In particular, I believe you're referring to the possibilities for the
recipient to validate an SES reverse-path by use of SPF and the 'exists'
mechanism, and a stunt DNS server. Or some similar technique.

> While that is wise in terms of getting a general BATV spec on the standards
> track, we are faced with a fairly narrow time window if we wish to see
> something other than SRS or SUBMITTER and changes to 2822 Resent-* header
> usage deployed with SPF.  The people who are currently working on SES are
> very interesting in finishing a protocol and writing a spec within that time
> window.  Most of us feel that SRS, SUBMITTER and the changes to 2822
> forwarding practices would be very bad for the internet mail system.  Yet
> the SPF crowd does not seem concerned, nor does MARID.  We have to offer a
> real alternative, including a proven implementation, if we are to have a
> chance at preventing this.

We run the risk of introducing an off-topic argument into a forum which
was previously at least _relatively_ harmonious. But I'll bite the
bullet and state that I'm reticent about the use of SPF itself for
verifying SES signatures. I think the marid-mailfrom draft needs to die
and it looks like it may well do so. If we want to use marid-protocol as
a basis for publishing a _separate_ 'marid-ses' scope option, that might
be a more useful way forward. 

I think we can find a way to do that in conjunction with something very
much like the existing BATV draft.

-- 
dwmw2


From owner-ietf-mailsig Sun Sep 19 05:03:38 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JC3cln070685
	for ; Sun, 19 Sep 2004 05:03:38 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JC3cCE070684
	for ietf-mailsig-skb; Sun, 19 Sep 2004 05:03:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound2.mail.tds.net (outbound2.mail.tds.net [216.170.230.92])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JC3b3Q070678
	for ; Sun, 19 Sep 2004 05:03:37 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound2.mail.tds.net (8.12.10/8.12.2) with SMTP id i8JC3aRT007319;
	Sun, 19 Sep 2004 07:03:37 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: "David Woodhouse" 
Cc: 
Subject: RE: Rambings on RFC2822 signatures.
Date: Sun, 19 Sep 2004 07:03:43 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <1095580806.5065.181.camel@localhost.localdomain>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: David Woodhouse
> Sent: Sunday, September 19, 2004 3:00 AM
>
>
>
> On Sat, 2004-09-18 at 23:58 -0500, Seth Goodman wrote:
> > Mailing lists have to resend it as their own outgoing message
> > anyway.

<...>

> I disagree. That reduces it to a hop-by-hop scheme again. In order to
> determine the probability that this message really did come from me,
> you'd have to ponder how much you trust the list server to have actually
> checked.

Technically, you are of course correct.  For the particular case of mailing
lists, I never considered it terribly important to have strong validation of
originating identity.  It's just list traffic, after all.  It's in the
list's interest to do this authentication of incoming posts to keep out
spam, but you're right, as users we don't really know what goes on.  Maybe
it's just me, but I don't think of list traffic in the same way as my
personal inbox.  If someone feels that it is really important to protect
their identity on a list, they can always use in-line PGP, ugly though it
is, as it survives pre-pending and post-pending of lines.

>
> > The idea that all MUA's would have to change to deal with displaying
> > multiple signed parts in different colors, as well as noting parts whose
> > signature doesn't validate does not bode well for adoption.
>
> That's a purely optional optimisation. If any scheme _required_ such a
> thing to be implemented by all recipients, the scheme would of course be
> doomed.

I knew you felt that way, I was playing devil's advocate.  Since no MUA
today would know how to deal with the multiple signatures anyway, it would
have to be an MTA process and the message would either be accepted or
rejected.  The end user would have no way of knowing who signed what, only
that the MTA figured out that everything was legitimate.  My questions is
how valuable are the multiple signatures if the end user has no way of
knowing who really added and signed what parts?  You could have four people
that signed a message, and the _text_ signatures have no relation to the
crypto signatures.  For example, Bob could add a few lines of text to
Shirley's message disguised as a P.S. from her and sign it with his key
(nasty bugger that Bob), but the recipient wouldn't know that P.S. came from
Bob, not Shirley, even though the MTA validated both signatures.

>
> > I suggest we don't have to allow additions at all, in any of
> > the MIME parts.

<...>

> Now you sound like the SPF folks declaring forwarding to be 'poor
> practice' or 'forgery'. Let us not consider it 'poor practice'; let us
> consider it 'current practice'.

You really know how to hurt a guy.  Of course I don't have anything against
forwarding.  I _do_ have a beef with anyone who changes message content, as
opposed to headers, in transit.  Since I've never used any of the free
services, I am unaware of forwarders that actually change message content.
While I am aware that junk is often added at both ends of the link, I was
unaware of forwarders who actually do that.  If that's what current practice
is, I believe you.  Can S/MIME or the attachment signature of PGP survive
this kind of mangling?  I would guess not.

>
> And in the case of mailing lists it's a practice that some will defend
> robustly. I _like_ having unsubscription instructions on every mail
> which is sent to my lists. People are in general too stupid for me to
> omit that.

Most people appreciate that convenience and not having to look at "how do I
unsubscribe" messages.  Mailing lists are a special case since they have to
re-mail all the posts such that bounces go to them.  They are the message
originator as far as the email system is concerned, even though they are not
from the user's perspective.  What you are proposing is an interesting idea
that effectively accomplishes what in-line PGP signatures do but is somewhat
more opaque, unless your MUA does the fancy highlighting.  I still don't
think it is important to have that level of authentication on mailing lists,
but that's a personal opinion.  The more important question is the potential
for mischief, as in my example above, when the end user can't see who added
and signed what part as they can with in-line PGP.

I'm not arguing to use in-line PGP, as that is awful to look at.  What I am
observing is that your scheme cries out for some MUA assistance to show the
user what happened, and it may not be usable without it.  Maybe you could do
something along the lines of in-line PGP where there are visible separators
that delimit the signed parts, but all the crypto stuff for them is hidden
in the headers.  You'd have to make sure it was a uniform separator that
people would always recognize, not something that could be turned into
white-on-white in HTML.  The aesthetics could be improved, but here's what I
mean:


Resent-From:
Resent-To:
Resent-Date: Friday 17 Sept 2004 13:00:00 -0500
Resent-Message-ID:
X-Resent-Sig: "bob is a blob", "zq1DeP7"
From:
To:
Date: Friday 17 Sept 2004 12:30:00 -0500
Message-ID:
X-Sig: "shirley eats tires", "XqgTu4"


*** Start Shirley.the.boss@acme.com Signed Part ***

To all managers,

Times are bad and we're broke.  Everyone
has to work Saturday from now on for no
pay.  Don't even think about complaining.

Shirley

*** End Shirley.the.boss@acme.com Signed Part ***




*** Start Bob.future.ex-employee@acme.com Signed Part ***

P.S.  On second thought, money isn't everything.
Life is too short.  Forget what I said and give
everyone every Friday afternoon off with pay.

Shirley

*** End Bob.future.ex-employee@acme.com Signed Part ***



--

Seth Goodman


From owner-ietf-mailsig Sun Sep 19 05:05:06 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JC56ZR070780
	for ; Sun, 19 Sep 2004 05:05:06 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JC56qo070779
	for ietf-mailsig-skb; Sun, 19 Sep 2004 05:05:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from Mail-Out.Odessa.Net (Mail-OUT.Odessa.Net [195.66.204.51])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JC54j2070770
	for ; Sun, 19 Sep 2004 05:05:05 -0700 (PDT)
	(envelope-from ietf-mxcomp@spam.24.odessa.ua)
Message-Id: <200409191205.i8JC54j2070770@above.proper.com>
Received: (qmail 58706 invoked by uid 1166); 19 Sep 2004 15:12:44 +0300
Received: from ietf-mxcomp@spam.24.odessa.ua by mail.odessa.net by uid 89 with qmail-scanner-1.20 
 (f-prot: 4.3.3/3.14.8.  Clear:RC:1(62.16.6.18):. 
 Processed in 0.664322 secs); 19 Sep 2004 12:12:44 -0000
Received: from unknown (HELO tag) (62.16.6.18)
  by mail.odessa.net with SMTP; 19 Sep 2004 15:12:43 +0300
From: "Andriy G. Tereshchenko" 
To: 
Subject: User-to-User or  Server-to-Server mail encryption 
Date: Sun, 19 Sep 2004 15:05:06 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1218
Thread-Index: AcSeQOcZGChFk9QGQSu1ELRcY0Uq+A==
X-Qmail-Scanner-Message-ID: <109559596465258696@mail.odessa.net>
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


Currently this list discuss one of problems - validation of email author to _possibly_ prevent spam/abuse.

But how about email privacy ? 
Nobody at post-office allowed to read your regular (paper) mail. 
But why all kinds of email filters constantly dig for keywords inside your messages ?

Why nobody discuss email-encryption/signing solutions ?
If we will send each-other a  gzip-compressed, encrypted and signed files - this will definitely solve a lot of problems.
 
No worry about canocalization, no worry about prepended/appended content at old non-compatible MTAs, no worry about your email read
by business competitors, no worry about email author, as well this can result in email traffic decrease (useless feature nobody care
about ;-)

Each mail server can announce in DNS that it accept such a emails and decoding will done at server-side or optionally if user really
need this - at end-user computer.
Everything will be transparent. 

In contrast from SSL/TLS - this will be sender-receiver encryption, not a hop-to-hop.
In contrast from user-level SMIME/PGP - this will offer some transparency for users. 
Offload key management and signing/decryption to email servers or email-proxies (this is much easy compared to change all MUA
software).

What do you think about this ?
How about making content of all emails secure ?
--
Andriy G. Tereshchenko
Odessa, Ukraine


From owner-ietf-mailsig Sun Sep 19 05:36:52 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JCaqJd072117
	for ; Sun, 19 Sep 2004 05:36:52 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JCapjP072116
	for ietf-mailsig-skb; Sun, 19 Sep 2004 05:36:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from sokol.elan.net (sokol.elan.net [216.151.192.200])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JCapVH072110
	for ; Sun, 19 Sep 2004 05:36:51 -0700 (PDT)
	(envelope-from william@elan.net)
Received: from sokol.elan.net (localhost.localdomain [127.0.0.1])
	by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i8JCnOcN010257;
	Sun, 19 Sep 2004 05:49:24 -0700
Received: from localhost (william@localhost)
	by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8JCnOB6010254;
	Sun, 19 Sep 2004 05:49:24 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Sun, 19 Sep 2004 05:49:24 -0700 (PDT)
From: "william(at)elan.net" 
To: Seth Goodman 
cc: ietf-mailsig@imc.org, David Woodhouse 
Subject: RE: Rambings on RFC2822 signatures.
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 



> Mailing lists have to resend it as their own outgoing message anyway.  It is
> not really necessary to preserve all the signatures through the re-mailing
> process.  

I disagree. The signatures are important to validate the email, we're
not expecting mail list to get rid of S/MIME or PGP signature are we?
In fact if they did, a lot of people would complain that their email
is not properly seen by the recepient can not be validated.

Also in reality, mail list is just one type of forwarder that forwards 
email to multiple recepients and adds additional identification information
regarding its processing stage. We need to either support forwarders (all 
types of them) or we end up with signature that can only deal with email
going directly from sender to recepient which is not reality of real world
email system.

So when considering if we want to support mail lists, it comes back to
if we want to support on-hop only signature validation system or if
want to build true end-end signature system. If we want to built one-hop
only cryptographic system, then I suggest we don't bother with signatures
and just focus or communication channel and require TLS and provide means
of validating certificates between different servers. If we want to build
true end-end system, then signature added by any one servers in email path 
should survive the transmission and it be possible to validate it by any
other server in the email path.

> The mailing list could validate the signature on the incoming
> message, add a header or even body line indicating that fact and sign it on
> the way out. 

Mail lists are going to validate signature as well as any other mail server
at some future point. But lets for a moment consider situation in the adoption
process where not everyone supports new signature system. Lets say I'm early
adoptor and my mail server added signature to my email. When I email 
somebody signature is there and destination server can validate it.

Lets say that there are servers in between that don't support signature
system but if email is not changed (only forwarded with no changes in the 
body) then the destination can still verify the message. This is a clear
benefit to early adaptors that it is not necessary for ENTIRE email system
to be upgraded. It also allows to not only rely on signature as a whitelist
but go futher as envisoned we are expecting to reject email with bad signature.
Additionally we're expecting in some future point early adaptors whose servers
are always adding the signature would public that as part of the policy record.
In that case, the recepient is expected to reject the message if it does not
contain a valid signature from the sender. 

The problem is that this does not work with email lists. If instead of a 
forwarder we have a mail list, then email is going to be changed in such
a way that signature verification would fail. So early adaptor can not
really publish that all his servers are adding signatures. Nor can early
adaptor expect that emails that are frudelently using his name are going
to be rejected, so all phishing and forging would still continue.

> I don't really see the need for the end user to be able to
> absolutely validate the identities on mailing list posts at the MUA. That
> sounds like a list function.  Lists do it now by the submitting address
> (broken ones use the return-path), so they can switch to validating
> signatures instead.
I disagree. I also would point out that mail lists are expected to carry 
cyrptographic signature forward and so both S/MIME and PGP signatures 
survive mail list posts and if they did not many people would object.

> The idea that all MUA's would have to change to deal with displaying
> multiple signed parts in different colors, as well as noting parts whose
> signature doesn't validate does not bode well for adoption.

I agree with you that it does not sound good. I see it more as an advanced
function for somebody who really wants to examine the email message.
But MUAs can still choose to display signature and verified sender whose
data compromises majority of the email and this is usefull in identifying
possible forgeries and reuse of email signature. I however think that such
scenarios can be stopped by cryptographic mechanisms that relay on other
data to verify if its original transmission and that good filter at MDA
will identify forgery attempts.

> I suggest we don't have to allow additions at all, in any of the MIME parts.

I agree. MIME part should stay as is, if somebody wants to add new data,
it should be done as new MIME part.

> The irritating virus scan adverts in the message body are usually put on at
> the originating or destination ends, so the signatures can be created after
> the addition and validated before any subsequent addition. 
Also agree here. I don't think virus scanners are a problem is signature
verification is done on proper level (MSA after Virus scan or MDA before it).

> Any forwarder that puts anything in the message body rather than the 
> headers deserves to have his messages rejected. 

As I indicated, mail lists are type of forwarders where message is forwarded
to more then one recepient. There are very legitimate reasons whey forwarders
may want to or need to change headers.

> That will break virtually any signature scheme,

It will not break "MTA Signatures" system as verification will still work 
if there were changes in email headers or if there was additional text 
added at the end as part of body (or in the beginning if it was part of 
text body and all mime parts are separately signed).

---
William Leibzon, Elan Networks:
 mailto: william@elan.net
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/


From owner-ietf-mailsig Sun Sep 19 07:46:46 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JEkk6r078972
	for ; Sun, 19 Sep 2004 07:46:46 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JEkkjD078971
	for ietf-mailsig-skb; Sun, 19 Sep 2004 07:46:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JEkc9J078958
	for ; Sun, 19 Sep 2004 07:46:45 -0700 (PDT)
	(envelope-from SRS0+cc5810394dac36bdc22f+392+infradead.org+dwmw2@canuck.srs.infradead.org)
Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253])
	by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux))
	id 1C92xZ-0006Bp-0W; Sun, 19 Sep 2004 10:46:38 -0400
Subject: RE: Rambings on RFC2822 signatures.
From: David Woodhouse 
To: sethg@GoodmanAssociates.com
Cc: ietf-mailsig@imc.org
In-Reply-To: 
References: 
Content-Type: text/plain
Date: Sun, 19 Sep 2004 15:41:23 +0100
Message-Id: <1095604883.5065.232.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) 
Content-Transfer-Encoding: 7bit
X-SRS-Rewrite: SMTP reverse-path rewritten from  by canuck.infradead.org
	See http://www.infradead.org/rpr.html
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sun, 2004-09-19 at 07:03 -0500, Seth Goodman wrote:
> > From: David Woodhouse
> > Sent: Sunday, September 19, 2004 3:00 AM
> >
> > I disagree. That reduces it to a hop-by-hop scheme again. In order to
> > determine the probability that this message really did come from me,
> > you'd have to ponder how much you trust the list server to have actually
> > checked.
> 
> Technically, you are of course correct.  For the particular case of mailing
> lists, I never considered it terribly important to have strong validation of
> originating identity.  It's just list traffic, after all. 

I consider it _more_ important to authenticate list traffic. Perhaps not
to avoid spam, but because saying something in _public_ is far more
important than saying it in private. It's _more_ important for people to
know that it really was you, and to know precisely what you said.

> > > The idea that all MUA's would have to change to deal with displaying
> > > multiple signed parts in different colors, as well as noting parts whose
> > > signature doesn't validate does not bode well for adoption.
> >
> > That's a purely optional optimisation. If any scheme _required_ such a
> > thing to be implemented by all recipients, the scheme would of course be
> > doomed.
> 
> I knew you felt that way, I was playing devil's advocate.  Since no MUA
> today would know how to deal with the multiple signatures anyway, it would
> have to be an MTA process and the message would either be accepted or
> rejected.  The end user would have no way of knowing who signed what, only
> that the MTA figured out that everything was legitimate.  My questions is
> how valuable are the multiple signatures if the end user has no way of
> knowing who really added and signed what parts? 

But the end user _can_ know who signed what, if they happen to use an
MUA which supports that, and if they care.

If an MUA did this it should probably use the signature corresponding to
the From: header by default, and should need to be _asked_ for any other
signature.

> You really know how to hurt a guy.  Of course I don't have anything against
> forwarding.  I _do_ have a beef with anyone who changes message content, as
> opposed to headers, in transit.  Since I've never used any of the free
> services, I am unaware of forwarders that actually change message content.
> While I am aware that junk is often added at both ends of the link, I was
> unaware of forwarders who actually do that.  If that's what current practice
> is, I believe you.  Can S/MIME or the attachment signature of PGP survive
> this kind of mangling?  I would guess not.

Current practice for many mailing lists, yes. Not really for
'forwarders'.

And no, in general PGP/MIME and S/MIME don't survive. If they _did_, we
could just start publishing some kind of record which says "All mail
from dwmw2@infradead.org will be GPG-signed", and give recipients the
chance to reject for lack of signature. But that would be utterly broken
in the real world today, just like certain other schemes we've
discussed :)

-- 
dwmw2


From owner-ietf-mailsig Sun Sep 19 08:57:57 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JFvvGi085151
	for ; Sun, 19 Sep 2004 08:57:57 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JFvvMU085150
	for ietf-mailsig-skb; Sun, 19 Sep 2004 08:57:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JFvvC9085143
	for ; Sun, 19 Sep 2004 08:57:57 -0700 (PDT)
	(envelope-from andy@hxr.us)
Received: from [10.0.1.3] ([::ffff:64.83.8.178])
  (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA)
  by zak.ecotroph.net with esmtp; Sun, 19 Sep 2004 11:57:56 -0400
  id 002133A2.414DAC85.000054F0
In-Reply-To: <20040918173114.25964.qmail@xuxa.iecc.com>
References: <20040918173114.25964.qmail@xuxa.iecc.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
Cc: fenton@cisco.com, ietf-mailsig@imc.org
From: Andrew Newton 
Subject: Re: at last:  draft-levine-mass-batv-00
Date: Sun, 19 Sep 2004 11:57:55 -0400
To: John Levine 
X-Mailer: Apple Mail (2.619)
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 



On Sep 18, 2004, at 1:31 PM, John Levine wrote:

>> So my question is: Beyond this technique, does the crypto piece add
>> enough additional value to be worth the trouble of key management,
>> etc.?
>
> To me the answer is clearly no unless it can piggybank on key 
> management
> from another system like DK.

I agree, and I thought this was the intent all along.

-andy


From owner-ietf-mailsig Sun Sep 19 11:26:52 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JIQqfL094802
	for ; Sun, 19 Sep 2004 11:26:52 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JIQqFk094801
	for ietf-mailsig-skb; Sun, 19 Sep 2004 11:26:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from sokol.elan.net (sokol.elan.net [216.151.192.200])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JIQpfL094794
	for ; Sun, 19 Sep 2004 11:26:51 -0700 (PDT)
	(envelope-from william@elan.net)
Received: from sokol.elan.net (localhost.localdomain [127.0.0.1])
	by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i8JIdVi5018866;
	Sun, 19 Sep 2004 11:39:31 -0700
Received: from localhost (william@localhost)
	by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8JIdU8L018863;
	Sun, 19 Sep 2004 11:39:31 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Sun, 19 Sep 2004 11:39:30 -0700 (PDT)
From: "william(at)elan.net" 
To: "Andriy G. Tereshchenko" 
cc: ietf-mailsig@imc.org
Subject: Re: User-to-User or  Server-to-Server mail encryption 
In-Reply-To: <200409191205.i8JC54j2070770@above.proper.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 



1. Encrypting and decrypting entire message is a lot more cpu 
   resource-consuming process then just signing it. It SHOULD NOT be 
   default choice for either end-user or MTA (but I'll not that
   some have proposed to make a default choice for unknown or
   unauthenticated senders to force them to use more resources). 

2. It is undertood that AUTHOR of the email is the person who can best
   decide about needed level of privacy for his email communication.
   This author can in fact encrypt the message with S/MIME or PGP
   in current email system, so we already achieve needed level of
   privacy as is. There is a problem, however, that author does not
   know for sure if recepient would be able to read his email, so 
   some kind of email policy record indicating that end user or
   his MTA can accept and decrypt S/MIME and/or PGP signed emails
   can indeed be helpfull.

3. Email system is more complicated then just end-end. There are
   various email servers that are involved in email transmission
   and none of them want to accept a bad email for somebody else.
   Another problem is that with all the email forwarding, author
   does not actually know for sure who the recepient would be.

P.S. I actually disagree with those that think signed S/MIME or PGP
   messages would not pass through end-end in current email system.
   I sign messages with S/MIME for one of my account and with
   OpenPGP for another. I've never seen any emal where signature
   would not be passed through by email list or similar forwarder.
   Its another question that I really dont know if recepient has
   capabilities to verify either S/MIME or PGP signature. And this
   problem with no "one and only" email signing standard has caused
   serious problems in adaption of this technology by end-users.

On Sun, 19 Sep 2004, Andriy G. Tereshchenko wrote:

> 
> Currently this list discuss one of problems - validation of email author to _possibly_ prevent spam/abuse.
> 
> But how about email privacy ? 
> Nobody at post-office allowed to read your regular (paper) mail. 
> But why all kinds of email filters constantly dig for keywords inside your messages ?
> 
> Why nobody discuss email-encryption/signing solutions ?
> If we will send each-other a  gzip-compressed, encrypted and signed files - this will definitely solve a lot of problems.
>  
> No worry about canocalization, no worry about prepended/appended content at old non-compatible MTAs, no worry about your email read
> by business competitors, no worry about email author, as well this can result in email traffic decrease (useless feature nobody care
> about ;-)
> 
> Each mail server can announce in DNS that it accept such a emails and decoding will done at server-side or optionally if user really
> need this - at end-user computer.
> Everything will be transparent. 
> 
> In contrast from SSL/TLS - this will be sender-receiver encryption, not a hop-to-hop.
> In contrast from user-level SMIME/PGP - this will offer some transparency for users. 
> Offload key management and signing/decryption to email servers or email-proxies (this is much easy compared to change all MUA
> software).
> 
> What do you think about this ?
> How about making content of all emails secure ?
> --
> Andriy G. Tereshchenko
> Odessa, Ukraine


From owner-ietf-mailsig Sun Sep 19 11:50:33 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JIoXdb095984
	for ; Sun, 19 Sep 2004 11:50:33 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JIoXms095983
	for ietf-mailsig-skb; Sun, 19 Sep 2004 11:50:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from joy.songbird.com (clint.songbird.com [208.184.79.11])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JIoW8S095977
	for ; Sun, 19 Sep 2004 11:50:32 -0700 (PDT)
	(envelope-from dhc@dcrocker.net)
Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8JIoag12626
	for ; Sun, 19 Sep 2004 11:50:36 -0700
From: Dave Crocker 
To: 
X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION
X-URL: http://www.pocomail.com/
Reply-To: Dave Crocker 
Date: Sun, 19 Sep 2004 10:46:15 -0700
Message-ID: <2004919104615.852983@bbprime>
In-Reply-To: 
Delivery-Date: Sun, 19 Sep 2004 10:46:14 -0000
Subject: Re: at last:  draft-levine-mass-batv-00
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


Folks,

>  >> So my question is: Beyond this technique, does the crypto piece add
>  >> enough additional value to be worth the trouble of key management,
>  >> etc.?
> > To me the answer is clearly no unless it can piggybank on key
> > management
> > from another system like DK.
>  I agree, and I thought this was the intent all along.

For reference, this is the reason that the current BATV specification no longer 
attempts to specify the details of a publicly verifiable RFC2821.MailFrom 
signature.  

The more the design team talked about the issue, the more compelling was the 
requirement that the any public mailfrom signing technique piggyback on an 
existing scheme.  And since there is not yet any clear winner for that job, and 
since new candidates seem to be appearing, we decided that the BATV spec should 
dodge the topic entirely, and rely on the scheme-naming extensibility of the 
batv syntax.  

--
Brandenburg InternetWorking
dcrocker@brandenburg.com
+1.408.246.8253




From owner-ietf-mailsig Sun Sep 19 12:26:07 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JJQ6t3097972
	for ; Sun, 19 Sep 2004 12:26:07 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JJQ60L097971
	for ietf-mailsig-skb; Sun, 19 Sep 2004 12:26:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JJQ6KE097964
	for ; Sun, 19 Sep 2004 12:26:06 -0700 (PDT)
	(envelope-from rand@sendmail.com)
Received: from snoopy.smi.sendmail.com ([10.210.202.22])
	by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i8JJQ5Wo025935
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Sun, 19 Sep 2004 12:26:05 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i8JJQ5Wo025935
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns;
	b=Ba5dJsvc53GVT4CeBev26/e6VtWHUseL9ORKhZ3rEeKf7y++aggK3vIFtMdkRgUQ/
	6GwvGkLSIIGk9swTOQu6g2ud7SQRh5NLq/OlKcAgPRFYtnuVlCCntqekUs+BCvj8gcv
	bTcDVzObC8mRRZvYSkvJL68al1s+jYIJJgoIfVc=
Date: Sun, 19 Sep 2004 12:26:05 -0700 (PDT)
From: Rand Wacker 
X-X-Sender: rand@snoopy.smi.sendmail.com
To: David Woodhouse 
cc: sethg@GoodmanAssociates.com, ietf-mailsig@imc.org
Subject: RE: Rambings on RFC2822 signatures.
In-Reply-To: <1095580806.5065.181.camel@localhost.localdomain>
Message-ID: 
References: 
 <1095580806.5065.181.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sun, 19 Sep 2004, David Woodhouse wrote:

> On Sat, 2004-09-18 at 23:58 -0500, Seth Goodman wrote:

> > Lists do it now by the submitting address (broken ones use the
> > return-path), so they can switch to validating signatures instead.
>
> I disagree. That reduces it to a hop-by-hop scheme again. In order to
> determine the probability that this message really did come from me,
> you'd have to ponder how much you trust the list server to have actually
> checked.

When handling mail list mail, I would *much* rather be checking for
whitelisting/reputation information about the address of the *list* than
the address of individuals posting to it.  Specifically, I don't want to
take the risk of having different posts to the same thread being treated
differently based on who they are from (almost as risky as today's
content-filtering approaches).

Its not that Seth's suggestion "reduces" the crypto solution to a
hop-by-hop scheme, but that the mailing list really *should* be taking
responsibility for the message.

Now a very interesting engineering problem is to allow multiple
signatures, so that you can verify the original content of the posters
message if you care to, and then verify the full text of the mail-list
modified message came from the mail list server.  For day-to-day usage
though, only the latter is really all that interesting IMO.

-Rand


From owner-ietf-mailsig Sun Sep 19 12:32:25 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JJWPow098251
	for ; Sun, 19 Sep 2004 12:32:25 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JJWPMO098250
	for ietf-mailsig-skb; Sun, 19 Sep 2004 12:32:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JJWOY9098244
	for ; Sun, 19 Sep 2004 12:32:25 -0700 (PDT)
	(envelope-from fanf2@hermes.cam.ac.uk)
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42593)
	by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25)
	with esmtp (Exim 4.34)
	id 1C97QA-0002La-7G (return-path fanf2@hermes.cam.ac.uk)
	for ietf-mailsig@imc.org; Sun, 19 Sep 2004 20:32:26 +0100
Received: from fanf2 (helo=localhost)
	by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34)
	id 1C97Q9-0006wO-RW; Sun, 19 Sep 2004 20:32:25 +0100
Date: Sun, 19 Sep 2004 20:32:25 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: "william(at)elan.net" 
cc: ietf-mailsig@imc.org
Subject: Re: User-to-User or  Server-to-Server mail encryption 
In-Reply-To: 
Message-ID: 
References: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
X-Cam-AntiVirus: No virus found
X-Cam-SpamDetails: Not scanned
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sun, 19 Sep 2004, william(at)elan.net wrote:
>
> 2. It is undertood that AUTHOR of the email is the person who can best
>    decide about needed level of privacy for his email communication.

That may be true in principle, if you assume a knowledgable author.
However in practice they will be acting under the advice of the software
they run and their local computer support staff, and won't change their
settings from one message to the next.

Tony.
-- 
f.a.n.finch    http://dotat.at/
LOUGH FOYLE TO CARLINGFORD LOUGH: WEST 5 OR 6 BACKING SOUTHWEST 5 TO 7,
LOCALLY GALE 8 IN NORTHWEST WEATHER: SHOWERS AT FIRST AND TONIGHT, RAIN THIS
AFTERNOON AND EVENING. MODERATE OR GOOD, OCCASIONALLY POOR IN RAIN. MODERATE
OR ROUGH, LOCALLY VERY ROUGH IN NORTHWEST LATER.


From owner-ietf-mailsig Sun Sep 19 15:05:38 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JM5c5K006407
	for ; Sun, 19 Sep 2004 15:05:38 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JM5cIh006406
	for ietf-mailsig-skb; Sun, 19 Sep 2004 15:05:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JM5ck4006400
	for ; Sun, 19 Sep 2004 15:05:38 -0700 (PDT)
	(envelope-from andy@hxr.us)
Received: from [10.0.1.3] ([::ffff:64.83.8.178])
  (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA)
  by zak.ecotroph.net with esmtp; Sun, 19 Sep 2004 18:05:40 -0400
  id 001B7A96.414E02B5.00006E18
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0A697630-0A88-11D9-9584-000A95B3BA44@hxr.us>
Content-Transfer-Encoding: 7bit
Cc: ietf-mailsig@imc.org
From: Andrew Newton 
Subject: Re: User-to-User or  Server-to-Server mail encryption 
Date: Sun, 19 Sep 2004 18:05:39 -0400
To: "william(at)elan.net" 
X-Mailer: Apple Mail (2.619)
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 



On Sep 19, 2004, at 2:39 PM, william(at)elan.net wrote:

> P.S. I actually disagree with those that think signed S/MIME or PGP
>    messages would not pass through end-end in current email system.
>    I sign messages with S/MIME for one of my account and with
>    OpenPGP for another. I've never seen any emal where signature
>    would not be passed through by email list or similar forwarder.

Really?  Have you ever sent a message through Yahoo Groups?  Many of 
the public list services like to tack adds on to the email causing the 
signatures not to validate.

-andy


From owner-ietf-mailsig Sun Sep 19 15:45:51 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JMjoiA008914
	for ; Sun, 19 Sep 2004 15:45:50 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8JMjoKX008913
	for ietf-mailsig-skb; Sun, 19 Sep 2004 15:45:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8JMjoDZ008907
	for ; Sun, 19 Sep 2004 15:45:50 -0700 (PDT)
	(envelope-from fanf2@hermes.cam.ac.uk)
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55118)
	by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25)
	with esmtp (Exim 4.34)
	id 1C9ARN-0004yq-GO (return-path fanf2@hermes.cam.ac.uk)
	for ietf-mailsig@imc.org; Sun, 19 Sep 2004 23:45:53 +0100
Received: from fanf2 (helo=localhost)
	by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34)
	id 1C9ARN-000883-6I; Sun, 19 Sep 2004 23:45:53 +0100
Date: Sun, 19 Sep 2004 23:45:53 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Andrew Newton 
cc: ietf-mailsig@imc.org
Subject: Re: User-to-User or  Server-to-Server mail encryption 
In-Reply-To: <0A697630-0A88-11D9-9584-000A95B3BA44@hxr.us>
Message-ID: 
References: 
 <0A697630-0A88-11D9-9584-000A95B3BA44@hxr.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
X-Cam-AntiVirus: No virus found
X-Cam-SpamDetails: Not scanned
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sun, 19 Sep 2004, Andrew Newton wrote:
>
> Really?  Have you ever sent a message through Yahoo Groups?  Many of the
> public list services like to tack adds on to the email causing the signatures
> not to validate.

The framing used by PGP means that mailing list bumf falls outside the
signed portion of the message, so the signature is robust.

Tony.
-- 
f.a.n.finch    http://dotat.at/
SHETLAND ISLES: SOUTH VEERING SOUTHWEST 6 TO GALE 8, VEERING NORTHWEST 6
LATER. RAIN OR SHOWERS. MODERATE OR GOOD. ROUGH OR VERY ROUGH.


From owner-ietf-mailsig Sun Sep 19 18:38:47 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K1clia020746
	for ; Sun, 19 Sep 2004 18:38:47 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8K1clVf020744
	for ietf-mailsig-skb; Sun, 19 Sep 2004 18:38:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound3.mail.tds.net (outbound3.mail.tds.net [216.170.230.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K1chEl020732
	for ; Sun, 19 Sep 2004 18:38:44 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound3.mail.tds.net (8.12.10/8.12.2) with SMTP id i8K1chNg022711;
	Sun, 19 Sep 2004 20:38:43 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: "Tony Finch" , "Andrew Newton" 
Cc: 
Subject: RE: User-to-User or  Server-to-Server mail encryption 
Date: Sun, 19 Sep 2004 20:38:54 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: Tony Finch
> Sent: Sunday, September 19, 2004 5:46 PM
>
>
>
> On Sun, 19 Sep 2004, Andrew Newton wrote:
> >
> > Really?  Have you ever sent a message through Yahoo Groups?  Many of the
> > public list services like to tack adds on to the email causing
> > the signatures not to validate.
>
> The framing used by PGP means that mailing list bumf falls outside the
> signed portion of the message, so the signature is robust.

I believe that's true of the in-line PGP signatures only.  I don't think the
PGP attachment signature is robust in the same way, but I'm willing to be
corrected on that.

S/MIME is easily broken by mailing list additions at the end of the text.

--

Seth Goodman


From owner-ietf-mailsig Sun Sep 19 19:07:11 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K27BAI025340
	for ; Sun, 19 Sep 2004 19:07:11 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8K27BSh025339
	for ietf-mailsig-skb; Sun, 19 Sep 2004 19:07:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound3.mail.tds.net (outbound3.mail.tds.net [216.170.230.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K27ANd025326
	for ; Sun, 19 Sep 2004 19:07:10 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound3.mail.tds.net (8.12.10/8.12.2) with SMTP id i8K27ENg002246;
	Sun, 19 Sep 2004 21:07:15 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: "David Woodhouse" 
Cc: 
Subject: RE: Rambings on RFC2822 signatures.
Date: Sun, 19 Sep 2004 21:07:26 -0500
Message-ID: 
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <1095604883.5065.232.camel@localhost.localdomain>
Content-Type: multipart/signed;
	micalg=SHA1;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_0022_01C49E8C.A9D62410"
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


This is a multi-part message in MIME format.

------=_NextPart_000_0022_01C49E8C.A9D62410
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> From: David Woodhouse
> Sent: Sunday, September 19, 2004 9:41 AM

<...>

> > > > The idea that all MUA's would have to change to deal with
displaying
> > > > multiple signed parts in different colors, as well as noting parts
> > > > whose signature doesn't validate does not bode well for adoption.
> > >
> > > That's a purely optional optimisation. If any scheme _required_ such
a
> > > thing to be implemented by all recipients, the scheme would of
course
> > > be doomed.
> >
> > I knew you felt that way, I was playing devil's advocate.  Since no
MUA
> > today would know how to deal with the multiple signatures anyway, it
> > would have to be an MTA process and the message would either be
accepted
> > or rejected.  The end user would have no way of knowing who signed
what,
> > only that the MTA figured out that everything was legitimate.  My
> > questions is how valuable are the multiple signatures if the end user
> > has no way of knowing who really added and signed what parts?
>
> But the end user _can_ know who signed what, if they happen to use an
> MUA which supports that, and if they care.
>
> If an MUA did this it should probably use the signature corresponding to
> the From: header by default, and should need to be _asked_ for any other
> signature.

Well, I don't think you can have it both ways.  Either there is wide MUA
support for this or there isn't.  Since it is a completely new scheme, we
have to assume that there is no MUA support for it.  In that case, doesn't
my example show that this scheme actually _facilitates_ fraud when the
user has a conventional MUA?

When there is an MUA that shows the user who signed what, it is a
terrific, general purpose anti-forgery tool.  The multiple signatures are
a very interesting problem and your approach to it appears workable.  As
long as there is an MUA that can show what has occured, the only objection
that I have is that it permits reordering of parts, which can change the
meaning of a message when the parts come from different people.  The main
overall problem I see is that it requires a special MUA to prevent you
from being fooled by malicious parties.

<...>

> > While I am aware that junk is often added at both ends of the
> > link, I was unaware of forwarders who actually do that.

<...>

> Current practice for many mailing lists, yes. Not really for
> 'forwarders'.
>
> And no, in general PGP/MIME and S/MIME don't survive. If they _did_, we
> could just start publishing some kind of record which says "All mail
> from dwmw2@infradead.org will be GPG-signed", and give recipients the
> chance to reject for lack of signature. But that would be utterly broken
> in the real world today, just like certain other schemes we've
> discussed :)

I didn't think forwarders did this, so we are really just talking about
mailing lists, which is a well-known problem.  As far as using an existing
protocol that already works, I believe that the in-line version of PGP
signatures survive mailing lists, though they are not pretty to look at.
I can verify that S/MIME does not survive mailing lists, unless there is a
variant of it that I am unaware of.  I signed this one with S/MIME.

--

Seth Goodman



------=_NextPart_000_0022_01C49E8C.A9D62410
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcjCCAvow
ggJjoAMCAQICAwy9HTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDQwNzIyMjIyMTA2WhcNMDUwNzIyMjIyMTA2WjBkMRAwDgYDVQQE
EwdHb29kbWFuMQ0wCwYDVQQqEwRTZXRoMRUwEwYDVQQDEwxTZXRoIEdvb2RtYW4xKjAoBgkqhkiG
9w0BCQEWG3NldGhnQEdvb2RtYW5Bc3NvY2lhdGVzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAL8QRk+HKbaNa1F5Tg8LBUUj2T4508/ET+dumJTqk+5wCY4DhTQ4v6L2tPeQdXwl
zUctll+eDJAcedQ0JJ+wm8dnU5nvti+FrIz/TpaCrnaMU/PoW5jTyTcZYcDQU+zl7n8a/9gCFIK7
4B7UZdRk4CdcLQ+c8zMUT5cSwks+p7lKATkghpr29JQ9Es+rBpul68tpc/Ki9Qv2UdzVFjQe/zuJ
osGJAtqVZGmOBZaH2/1C/WcNuVDpt9iloeMNPrkAwk0efc6gJHdSIMz4EENlMPKezN4YEOaEBGgM
YyJb9byemSwZHF/adg3WoesRSnWZ9E/fr77S08p8O58osx1+U90CAwEAAaM4MDYwJgYDVR0RBB8w
HYEbc2V0aGdAR29vZG1hbkFzc29jaWF0ZXMuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEE
BQADgYEAEiPPzCAsfxcuZmC1NV/iZ3GstPBIrjOkYa5enjKSaJDsKb8Xf/qOk2g9GatsWl0DSYmU
/piJs4UKOIUY1PvzsSN5RrxCFQWCF8jjG/QQBeEuRnvQIhn83k6BIGqDdGmSvf02G9t6KyPWMk8K
Cs3xMiq/llK8J/hLh05UO6VOw68wggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY
BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz
IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG
9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAx
MjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE
BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlm
aWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6
QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNd
bnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8E
BTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w
+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+Nxf
IyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMIIDPzCCAqigAwIBAgIBDTAN
BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy
dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy
ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X
DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoe
aMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwL
B+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3
+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDov
L2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEG
MCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF
AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD
2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj
ViF4gtwhGTXeJLHTHUb/XV9lTzGCArYwggKyAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBAgMMvR0wCQYFKw4DAhoFAKCCASIwGAYJKoZIhvcNAQkDMQsGCSqG
SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwOTIwMDIwNzI1WjAjBgkqhkiG9w0BCQQxFgQUlm38
Eiw51rpnsQzCOKl+RN0XEGQwSQYJKoZIhvcNAQkPMTwwOjAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwBwYFKw4DAhowCgYIKoZIhvcNAgUweAYJKwYBBAGCNxAEMWswaTBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwy9HTANBgkqhkiG9w0BAQEF
AASCAQCchE0uApOYXXl7m5iSh3Pj/tv3upgwpIdg1IQrcS99wO2Y/z4vHYwJnY816SXOOAy3Wb4X
CXAx909PUl9tPVMxjjVaGCHy3ULAJEF/4CNOvrE0FH0V9VgSY78RVgdwe0dC0oRO3SS/Mv/hE7sV
+v5cz4srKipcqwCWIPA/JoQccbL0hLQLexdyp+GHoQenecL3+IRcqIThBJdv2+zMh2nAO8UHRIxp
DBiLv7DHn46nVpkSwUWP3v68hfrj8zAI5DmLoL2wit157aAm4V4OilB01C+V6a1qIre9mLGJcr0O
5U65JPLBpSzzNKjGvgNxL7mR1qVL+VH735kNn9KIAgV3AAAAAAAA

------=_NextPart_000_0022_01C49E8C.A9D62410--


From owner-ietf-mailsig Sun Sep 19 19:24:09 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K2O8MY026577
	for ; Sun, 19 Sep 2004 19:24:08 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8K2O8k3026576
	for ietf-mailsig-skb; Sun, 19 Sep 2004 19:24:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound2.mail.tds.net (outbound2.mail.tds.net [216.170.230.92])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K2O8kg026567
	for ; Sun, 19 Sep 2004 19:24:08 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound2.mail.tds.net (8.12.10/8.12.2) with SMTP id i8K2NqRT027285;
	Sun, 19 Sep 2004 21:23:54 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: , "David Woodhouse" 
Cc: 
Subject: RE: Rambings on RFC2822 signatures.
Date: Sun, 19 Sep 2004 21:24:05 -0500
Message-ID: 
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: 
Content-Type: multipart/signed;
	micalg=SHA1;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_003D_01C49E8E.FCC0E0A0"
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


This is a multi-part message in MIME format.

------=_NextPart_000_003D_01C49E8E.FCC0E0A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> From: Seth Goodman
> Sent: Sunday, September 19, 2004 9:07 PM

<...>

> I can verify that S/MIME does not survive mailing lists, unless there is
a
> variant of it that I am unaware of.  I signed this one with S/MIME.

Wouldn't you know it, this listserve made a liar out of me.  The S/MIME
sig survived as the list properly retained the From: header and didn't add
anything to the beginning or end of the message content.  This is the
first time I've seen an S/MIME sig survive a mailing list, but I'd say
it's the exception that proves the rule.

--

Seth Goodman

------=_NextPart_000_003D_01C49E8E.FCC0E0A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcjCCAvow
ggJjoAMCAQICAwy9HTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDQwNzIyMjIyMTA2WhcNMDUwNzIyMjIyMTA2WjBkMRAwDgYDVQQE
EwdHb29kbWFuMQ0wCwYDVQQqEwRTZXRoMRUwEwYDVQQDEwxTZXRoIEdvb2RtYW4xKjAoBgkqhkiG
9w0BCQEWG3NldGhnQEdvb2RtYW5Bc3NvY2lhdGVzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAL8QRk+HKbaNa1F5Tg8LBUUj2T4508/ET+dumJTqk+5wCY4DhTQ4v6L2tPeQdXwl
zUctll+eDJAcedQ0JJ+wm8dnU5nvti+FrIz/TpaCrnaMU/PoW5jTyTcZYcDQU+zl7n8a/9gCFIK7
4B7UZdRk4CdcLQ+c8zMUT5cSwks+p7lKATkghpr29JQ9Es+rBpul68tpc/Ki9Qv2UdzVFjQe/zuJ
osGJAtqVZGmOBZaH2/1C/WcNuVDpt9iloeMNPrkAwk0efc6gJHdSIMz4EENlMPKezN4YEOaEBGgM
YyJb9byemSwZHF/adg3WoesRSnWZ9E/fr77S08p8O58osx1+U90CAwEAAaM4MDYwJgYDVR0RBB8w
HYEbc2V0aGdAR29vZG1hbkFzc29jaWF0ZXMuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEE
BQADgYEAEiPPzCAsfxcuZmC1NV/iZ3GstPBIrjOkYa5enjKSaJDsKb8Xf/qOk2g9GatsWl0DSYmU
/piJs4UKOIUY1PvzsSN5RrxCFQWCF8jjG/QQBeEuRnvQIhn83k6BIGqDdGmSvf02G9t6KyPWMk8K
Cs3xMiq/llK8J/hLh05UO6VOw68wggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY
BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz
IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG
9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAx
MjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE
BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlm
aWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6
QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNd
bnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8E
BTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w
+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+Nxf
IyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMIIDPzCCAqigAwIBAgIBDTAN
BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy
dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy
ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X
DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoe
aMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwL
B+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3
+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDov
L2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEG
MCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF
AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD
2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj
ViF4gtwhGTXeJLHTHUb/XV9lTzGCArYwggKyAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBAgMMvR0wCQYFKw4DAhoFAKCCASIwGAYJKoZIhvcNAQkDMQsGCSqG
SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwOTIwMDIyNDAzWjAjBgkqhkiG9w0BCQQxFgQU8GQk
G2Ken/hq0qFoU8Tv9cJU7mMwSQYJKoZIhvcNAQkPMTwwOjAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwBwYFKw4DAhowCgYIKoZIhvcNAgUweAYJKwYBBAGCNxAEMWswaTBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwy9HTANBgkqhkiG9w0BAQEF
AASCAQA9Xd1JjQF3AgtkFbd1C1/dzr7qfwIOBG7kitz89bRPhE0nBZVZZCvEuiJb7z5/HsxnjGZZ
F1GKNTQB82lz/dTO8fZxILt78p+6JWVbj6njK5d9qvM6CG2e6pj0JMLBlA39gP2nLN2YVTXDw51w
90licw2xCihBz6ElHO+F3v8HLwXmj+Q6kp+LgsoB6kTkQU1sx6rcQlUT1ZYUiMtIvdyf6gSOCsWa
sPnOhpccvyJm0S4eirwbO72Ol+lbLehPJ9aiJb6CQ10s1PW0cAUncYTztLs79TsHBnEXwsasQKYA
8sJNuYzbhFMg3ZoyI41VEyrkGxwVz8OsDW/ZDyTecPjcAAAAAAAA

------=_NextPart_000_003D_01C49E8E.FCC0E0A0--


From owner-ietf-mailsig Sun Sep 19 20:24:12 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K3OCHm032512
	for ; Sun, 19 Sep 2004 20:24:12 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8K3OCgI032511
	for ietf-mailsig-skb; Sun, 19 Sep 2004 20:24:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from sokol.elan.net (sokol.elan.net [216.151.192.200])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K3OBcT032505
	for ; Sun, 19 Sep 2004 20:24:11 -0700 (PDT)
	(envelope-from william@elan.net)
Received: from sokol.elan.net (localhost.localdomain [127.0.0.1])
	by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i8K3awo6001787;
	Sun, 19 Sep 2004 20:36:58 -0700
Received: from localhost (william@localhost)
	by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8K3awZD001784;
	Sun, 19 Sep 2004 20:36:58 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Sun, 19 Sep 2004 20:36:58 -0700 (PDT)
From: "william(at)elan.net" 
To: Andrew Newton 
cc: ietf-mailsig@imc.org
Subject: Re: User-to-User or  Server-to-Server mail encryption 
In-Reply-To: <0A697630-0A88-11D9-9584-000A95B3BA44@hxr.us>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sun, 19 Sep 2004, Andrew Newton wrote:

> On Sep 19, 2004, at 2:39 PM, william(at)elan.net wrote:
> 
> > P.S. I actually disagree with those that think signed S/MIME or PGP
> >    messages would not pass through end-end in current email system.
> >    I sign messages with S/MIME for one of my account and with
> >    OpenPGP for another. I've never seen any emal where signature
> >    would not be passed through by email list or similar forwarder.
> 
> Really?  Have you ever sent a message through Yahoo Groups?  Many of 
> the public list services like to tack adds on to the email causing the 
> signatures not to validate.

I did. It still validated, the extra text was outside the signature 
content (same as most other mail list footers).

-- 
William Leibzon
Elan Networks
william@elan.net


From owner-ietf-mailsig Sun Sep 19 20:35:56 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K3Zt02034285
	for ; Sun, 19 Sep 2004 20:35:55 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8K3ZtRg034284
	for ietf-mailsig-skb; Sun, 19 Sep 2004 20:35:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from sokol.elan.net (sokol.elan.net [216.151.192.200])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K3ZtJL034275
	for ; Sun, 19 Sep 2004 20:35:55 -0700 (PDT)
	(envelope-from william@elan.net)
Received: from sokol.elan.net (localhost.localdomain [127.0.0.1])
	by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i8K3mfC5002017;
	Sun, 19 Sep 2004 20:48:41 -0700
Received: from localhost (william@localhost)
	by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8K3meF6002014;
	Sun, 19 Sep 2004 20:48:41 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Sun, 19 Sep 2004 20:48:40 -0700 (PDT)
From: "william(at)elan.net" 
To: Seth Goodman 
cc: David Woodhouse , 
Subject: RE: Rambings on RFC2822 signatures.
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 



On Sun, 19 Sep 2004, Seth Goodman wrote:

> > I can verify that S/MIME does not survive mailing lists, unless there is
> > a variant of it that I am unaware of.  I signed this one with S/MIME.
> 
> Wouldn't you know it, this listserve made a liar out of me.  The S/MIME
> sig survived as the list properly retained the From: header and didn't add
> anything to the beginning or end of the message content.  This is the
> first time I've seen an S/MIME sig survive a mailing list, but I'd say
> it's the exception that proves the rule.
I could verify your S/MIME signature. 

The additions  of text by Mail Lists should not cause signature to be 
broken, because if you examine the email with addition, this new text
I (should be)  added not as part of existing MIME component but as new 
text part. Its another question entirely that mail clients have problems 
when you have multiple parts where only one part is actually signed. 

-- 
William Leibzon
Elan Networks
william@elan.net


From owner-ietf-mailsig Sun Sep 19 22:56:47 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K5ul8J067399
	for ; Sun, 19 Sep 2004 22:56:47 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8K5ulh8067397
	for ietf-mailsig-skb; Sun, 19 Sep 2004 22:56:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K5ulwQ067276
	for ; Sun, 19 Sep 2004 22:56:47 -0700 (PDT)
	(envelope-from fenton@cisco.com)
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 19 Sep 2004 22:58:32 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8K5ugbs006190;
	Sun, 19 Sep 2004 22:56:43 -0700 (PDT)
Received: from fenton-w2k01.cisco.com (stealth-10-32-245-100.cisco.com [10.32.245.100])
	by imail.cisco.com (8.12.5/8.12.10) with SMTP id i8K66HZH017202;
	Sun, 19 Sep 2004 23:06:18 -0700
Message-Id: <4.3.2.7.2.20040919223948.04349328@mira-sjc5-1.cisco.com>
X-Sender: fenton@mira-sjc5-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 19 Sep 2004 22:48:17 -0700
To: , 
From: Jim Fenton 
Subject: RE: Rambings on RFC2822 signatures.
Cc: "David Woodhouse" 
In-Reply-To: 
References: <1095531012.5065.161.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1095660378.967687"; x:"432000"; a:"rsa-sha1"; b:"nofws:2379";
	e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda"
	"s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7"
	"674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek=";
	s:"BROTxF5R6gkGoKdBmvWpLXgKfO4BJWgpXbs73CmPtteHvTfaY7svVzVDMmAxg"
	"pKwq9HiMxuO6bfILRhNncY5sgLZoWj03iFnWKAljXz5NcWP+qcxuok1lpvRE3"
	"iD8aqvTsCfF4YyIMhobhCkRhhTiP2ZRM+m4RavGHk5LzftMe8=";
	c:"Date: Sun, 19 Sep 2004 22:48:17 -0700";
	c:"From: Jim Fenton ";
	c:"Subject: RE: Rambings on RFC2822 signatures."
IIM-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


At 11:58 PM 9/18/2004 -0500, Seth Goodman wrote:

>> From: David Woodhouse
>> Sent: Saturday, September 18, 2004 1:10 PM
>
><...>
>
>> The bit with allowing the addition of lines -- or at least being able to
>> tell that the signed part is still valid despite the addition of lines
>> (I didn't say that/when the recipient had to _allow_ it) -- is
>> permissiveness, and that's what seems to be needed to allow most of the
>> attacks in the field guide you reference.
>>
>> Speaking personally, I'm most concerned about the additions by mailing
>> lists, and on text/plain MIME parts.
>
>Mailing lists have to resend it as their own outgoing message anyway.  It is
>not really necessary to preserve all the signatures through the re-mailing
>process.  The mailing list could validate the signature on the incoming
>message, add a header or even body line indicating that fact and sign it on
>the way out.  I don't really see the need for the end user to be able to
>absolutely validate the identities on mailing list posts at the MUA.  That
>sounds like a list function.  Lists do it now by the submitting address
>(broken ones use the return-path), so they can switch to validating
>signatures instead.

While it would be a good for mailing lists to sign their outgoing messages, I don't think we can expect that will happen with all lists on Day One.  In cases where it's possible for user signatures to be made to work through mailing lists, we can live with those mailing lists being a little slower to adopt message signing.  It's also a stronger statement if the user signature as well as the mailing list signature verifies correctly -- we can then attribute the message to the original sender and not just to the mailing list.

In practice, some canonicalization helps the original user signatures get through.  For example, how many people have noticed that this mailing lists adds an extra CRLF at the beginning of the body?  I think the benefit of getting intact signatures through such lists outweighs the likely abuses of such a scheme.



>The idea that all MUA's would have to change to deal with displaying
>multiple signed parts in different colors, as well as noting parts whose
>signature doesn't validate does not bode well for adoption.

Right.  I vote for requiring no MUA modifications at initial deployment.

-Jim


From owner-ietf-mailsig Sun Sep 19 22:56:47 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K5ulp2067398
	for ; Sun, 19 Sep 2004 22:56:47 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8K5ulVb067395
	for ietf-mailsig-skb; Sun, 19 Sep 2004 22:56:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K5ulwR067276
	for ; Sun, 19 Sep 2004 22:56:47 -0700 (PDT)
	(envelope-from fenton@cisco.com)
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 19 Sep 2004 22:58:34 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8K5uibs006201;
	Sun, 19 Sep 2004 22:56:44 -0700 (PDT)
Received: from fenton-w2k01.cisco.com (stealth-10-32-245-100.cisco.com [10.32.245.100])
	by imail.cisco.com (8.12.5/8.12.10) with SMTP id i8K66HZJ017202;
	Sun, 19 Sep 2004 23:06:19 -0700
Message-Id: <4.3.2.7.2.20040919224834.031b77f8@mira-sjc5-1.cisco.com>
X-Sender: fenton@mira-sjc5-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 19 Sep 2004 22:56:39 -0700
To: Dave Crocker ,
        David Woodhouse , 
From: Jim Fenton 
Subject: Re: Rambings on RFC2822 signatures.
Cc: 
In-Reply-To: <200491822036.106670@bbprime>
References: <4.3.2.7.2.20040917230814.0446db80@mira-sjc5-1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1095660380.324510"; x:"432000"; a:"rsa-sha1"; b:"nofws:1411";
	e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda"
	"s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7"
	"674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek=";
	s:"ewFsbkAGgvanpNY+a/isM2Fqdi5fiGDbitKocQIjw9ofvX6kzb77hho6GVAml"
	"a6pKXvnBBLYR6Y5b/V2MOGs0n6mzgGa9XfkYht1vL92wY4YPLHUcDjvG5sJXq"
	"u6AsoXl3laH1RV6MbCa4Wb0Esggw4dPWN6Qp4VBkWfGdZ2XGE=";
	c:"Date: Sun, 19 Sep 2004 22:56:39 -0700";
	c:"From: Jim Fenton ";
	c:"Subject: Re: Rambings on RFC2822 signatures."
IIM-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


At 02:20 AM 9/18/2004 -0700, Dave Crocker wrote:


>On Fri, 17 Sep 2004 23:14:31 -0700, Jim Fenton wrote:
>>  tag on the IIM-Sig header on this message for a sample).  Should we have a 
>signature for the strict (non-canonicalized) form of the message as well, to 
>give that option to the recipient as well?
>
>
>unfortunately, options are not free.  they carry all sorts of system-level costs 
>for adoption and use.
>
>mostly, options should be provided because it is clear they do something 
>extremely important, rather than merely because they are nice.

Agreed, they're not free.  Here are the two cases that I think motivate the option here:

1. "Typical" sender who sometimes sends messages through a mailing list (like this one, that adds an extra CRLF at the beginning of the body, or the ASRG list, which adds a trailer).  This sender probably wants to have the signatures survive these modifications, and wants a canonicalization that does that.  Lists will probably start signing messages at some point, but we can't expect that to happen instantly.

2. Paranoid (?) sender who does not expect to be sending through a mailing list.  Perhaps a bank communicating with individual customers.  Such a sender may not want to allow spacing to be adjusted nor appending to be allowed.  They would use a strict (null) canonicalization.

Does this seem extremely important?

-Jim


From owner-ietf-mailsig Mon Sep 20 02:25:55 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K9PtPX043186
	for ; Mon, 20 Sep 2004 02:25:55 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8K9PtpZ043185
	for ietf-mailsig-skb; Mon, 20 Sep 2004 02:25:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K9PhsY043091
	for ; Mon, 20 Sep 2004 02:25:54 -0700 (PDT)
	(envelope-from SRS0+a280400b026b5778d77b+393+infradead.org+dwmw2@canuck.srs.infradead.org)
Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253])
	by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux))
	id 1C9KQS-00081p-TD; Mon, 20 Sep 2004 05:25:38 -0400
Subject: Re: Rambings on RFC2822 signatures.
From: David Woodhouse 
To: Jim Fenton 
Cc: Dave Crocker , mlibbeymail-mailsig@yahoo.com,
        ietf-mailsig@imc.org
In-Reply-To: <4.3.2.7.2.20040919224834.031b77f8@mira-sjc5-1.cisco.com>
References: <4.3.2.7.2.20040917230814.0446db80@mira-sjc5-1.cisco.com>
	 <4.3.2.7.2.20040919224834.031b77f8@mira-sjc5-1.cisco.com>
Content-Type: text/plain
Date: Mon, 20 Sep 2004 10:20:13 +0100
Message-Id: <1095672014.5065.276.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) 
Content-Transfer-Encoding: 7bit
X-SRS-Rewrite: SMTP reverse-path rewritten from  by canuck.infradead.org
	See http://www.infradead.org/rpr.html
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sun, 2004-09-19 at 22:56 -0700, Jim Fenton wrote:
> Here are the two cases that I think motivate the option [ of including
> a signature for the strict non-canonicalised message ] here:
> 
> 1. "Typical" sender who sometimes sends messages through a mailing list
> 2. Paranoid (?) sender who does not expect to be sending through a mailing list. 
>
> Does this seem extremely important?

Not really. Canonicalisation, by definition, wouldn't harm the meaning
of the mail. There's no real reason for the bank to _insist_ that the
mail arrive in ISO8859-15 encoding as they sent it instead of UTF-8, for
example. I cannot imagine a situation in which you'd really want to
include a signature on the non-canonicalised mail.

If you were thinking of permissiveness -- actually allowing text to be
added to the mail in transit -- that's different. We'd already _include_
the signature on the original mail, and the information which allows
permissiveness is my suggested rolling checksum and linecount to help
the recipient locate the original text within the mail on final
delivery. If the bank _really_ wants to avoid any mangling of its
outgoing mail, by mailing lists or otherwise, it could omit that extra
information and include _only_ a signature on the original body. But I
don't actually think such a requirement is _important_, no. This isn't a
scheme to help prevent people from sending mail where they didn't intend
to.

-- 
dwmw2


From owner-ietf-mailsig Mon Sep 20 02:35:30 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K9ZU0f046822
	for ; Mon, 20 Sep 2004 02:35:30 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8K9ZULs046821
	for ietf-mailsig-skb; Mon, 20 Sep 2004 02:35:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8K9ZTNm046810
	for ; Mon, 20 Sep 2004 02:35:30 -0700 (PDT)
	(envelope-from SRS0+a280400b026b5778d77b+393+infradead.org+dwmw2@canuck.srs.infradead.org)
Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253])
	by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux))
	id 1C9KZo-00082W-FF; Mon, 20 Sep 2004 05:35:17 -0400
Subject: RE: Rambings on RFC2822 signatures.
From: David Woodhouse 
To: Jim Fenton 
Cc: sethg@GoodmanAssociates.com, ietf-mailsig@imc.org
In-Reply-To: <4.3.2.7.2.20040919223948.04349328@mira-sjc5-1.cisco.com>
References: <1095531012.5065.161.camel@localhost.localdomain>
	 <4.3.2.7.2.20040919223948.04349328@mira-sjc5-1.cisco.com>
Content-Type: text/plain
Date: Mon, 20 Sep 2004 10:29:54 +0100
Message-Id: <1095672594.5065.283.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) 
Content-Transfer-Encoding: 7bit
X-SRS-Rewrite: SMTP reverse-path rewritten from  by canuck.infradead.org
	See http://www.infradead.org/rpr.html
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sun, 2004-09-19 at 22:48 -0700, Jim Fenton wrote:
> While it would be a good for mailing lists to sign their outgoing
> messages, I don't think we can expect that will happen with all lists
> on Day One.  In cases where it's possible for user signatures to be
> made to work through mailing lists, we can live with those mailing
> lists being a little slower to adopt message signing.  It's also a
> stronger statement if the user signature as well as the mailing list
> signature verifies correctly -- we can then attribute the message to
> the original sender and not just to the mailing list.

Question: If we _don't_ want multiple signatures, why are we doing this
at the RFC2822 level instead of just using the reverse-path? One other
potential solution to the problem of messages getting munged is to
observe that the worst offenders also change the reverse-path. So we
could tie our signature to our own RFC2821.MailFrom and not _care_ about
mailing lists and the need for permissiveness.

> In practice, some canonicalization helps the original user signatures
> get through.  For example, how many people have noticed that this
> mailing lists adds an extra CRLF at the beginning of the body?  I
> think the benefit of getting intact signatures through such lists
> outweighs the likely abuses of such a scheme.

I agree. Especially if we keep a strict distinction between
canonicalisation and permissiveness. Canonicalisation is by definition
always harmless. The policy of precisely what kind of additions to
permit can be per-site and doesn't have to be defined in an RFC.

> >The idea that all MUA's would have to change to deal with displaying
> >multiple signed parts in different colors, as well as noting parts whose
> >signature doesn't validate does not bode well for adoption.
> 
> Right.  I vote for requiring no MUA modifications at initial deployment.

Absolutely agreed. I was pointing that out as an extra benefit which
could perhaps come later -- not as something which would require
immediate support.

-- 
dwmw2


From owner-ietf-mailsig Mon Sep 20 17:49:00 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L0mx0Q048369
	for ; Mon, 20 Sep 2004 17:48:59 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8L0mxms048368
	for ietf-mailsig-skb; Mon, 20 Sep 2004 17:48:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L0mx3W048359
	for ; Mon, 20 Sep 2004 17:48:59 -0700 (PDT)
	(envelope-from mike@mtcc.com)
Received: from mtcc.com.mtcc.com (fasolt.mtcc.com [216.102.208.10])
	by mtcc.com (8.12.10/8.12.10) with ESMTP id i8L0n4xq027660;
	Mon, 20 Sep 2004 17:49:04 -0700
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16719.31360.339875.897946@mtcc.com>
Date: Mon, 20 Sep 2004 17:49:04 -0700
To: mlibbeymail-mailsig@yahoo.com
Cc: ietf-mailsig@imc.org
Subject: Re: Rambings on RFC2822 signatures.
In-Reply-To: <20040918160252.2859.qmail@web14927.mail.yahoo.com>
References: <1095498359.5065.53.camel@localhost.localdomain>
	<20040918160252.2859.qmail@web14927.mail.yahoo.com>
X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
IIM-SIG: v:"1"; h:"fasolt.mtcc.com"; d:"mtcc.com"; z:"home"; m:"krs";
	t:"1095727744.782312"; x:"432000"; a:"rsa-sha1"; b:"nofws:1377";
	e:"Iw=="; n:"nVv0qboMtb/jcj1UT0mvfTvYyyFXXGzpd98dYJEDa/uux2xfeB+A0e9dSQ07c"
	"42LbmgdqdIvWuQzlXIdGJ77Qy9oz3RP5a38E2H5O9oPfQNGtaKOiJ6/gELwFy"
	"6wij+H/UTnHFcKILxF9lBlB7xIoFrXH675Blkho/iM/LDLxNk=";
	s:"PoA9aQjC3rJA0KnLcrjWvUoGSx6ZDcdK++zYowfSflAQekNK+jc/9bJLR0Rgp"
	"F1NuKzY5nXndFdI2XjV5TSCrgCnwEteTg2e7CTwG3hPUfLj6Nkg5W0A7tLK7I"
	"GiWbM3B7EAnZ/7/Mzt2bUR4Za00B6tB7YU9HwqHYgxZF88o1A=";
	c:"From: Michael Thomas ";
	c:"Date: Mon, 20 Sep 2004 17:49:04 -0700";
	c:"Subject: Re: Rambings on RFC2822 signatures."
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"fasolt.mtcc.com";
	c:"message from fasolt.mtcc.com verified; "
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


Miles Libbey writes:
 > 
 > --- David Woodhouse  wrote:
 > > I don't think so. I find it hard to imagine an attach in which
 > > canonicalisation gives you a way to abuse mail. Perhaps if the
 > > canonicalisation were to fold all whitespace, someone's answer could
 > > be
 > > moved from one column in a table to another column?
 > 
 > This may allow a spammer to replay a message and add their own special
 > content.  Imagine a spammer taking a message from a bank and redefining
 > css tags to hide the 'legit' content from the user, and appending their
 > own special phishing text.  

As I mentioned to Nathaniel Borenstein at IETF, the "no
white space" canonicalization could conceivably lead to an
attack of the ascii art variety: just keep the original
content but through the creative insertion of tabs,
newlines, etc, display Viagra ads. Here it's possible and
quite reasonable for senders to have different tolerance
levels for whether they are willing to tolerate such an
attack; many people will, but some risk adverse senders may
not.

In any case, the long term goal here should be to put body
manglers at an evolutionary disadvantage, and that the
"plain" canonicalization (eg all bits in ==> hash out) is
really the ultimate goal. Steps in between are compromises
to deal with current reality.

	     Mike


From owner-ietf-mailsig Mon Sep 20 18:25:40 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L1Pejj052409
	for ; Mon, 20 Sep 2004 18:25:40 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8L1Pe58052408
	for ietf-mailsig-skb; Mon, 20 Sep 2004 18:25:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L1PdBg052402
	for ; Mon, 20 Sep 2004 18:25:39 -0700 (PDT)
	(envelope-from mike@mtcc.com)
Received: from mtcc.com.mtcc.com (fasolt.mtcc.com [216.102.208.10])
	by mtcc.com (8.12.10/8.12.10) with ESMTP id i8L1Pfxq032360;
	Mon, 20 Sep 2004 18:25:41 -0700
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16719.33557.351416.496649@mtcc.com>
Date: Mon, 20 Sep 2004 18:25:41 -0700
To: Rand Wacker 
Cc: David Woodhouse , sethg@GoodmanAssociates.com,
        ietf-mailsig@imc.org
Subject: RE: Rambings on RFC2822 signatures.
In-Reply-To: 
References: 
	<1095580806.5065.181.camel@localhost.localdomain>
	
X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
IIM-SIG: v:"1"; h:"fasolt.mtcc.com"; d:"mtcc.com"; z:"home"; m:"krs";
	t:"1095729941.894053"; x:"432000"; a:"rsa-sha1"; b:"nofws:2061";
	e:"Iw=="; n:"nVv0qboMtb/jcj1UT0mvfTvYyyFXXGzpd98dYJEDa/uux2xfeB+A0e9dSQ07c"
	"42LbmgdqdIvWuQzlXIdGJ77Qy9oz3RP5a38E2H5O9oPfQNGtaKOiJ6/gELwFy"
	"6wij+H/UTnHFcKILxF9lBlB7xIoFrXH675Blkho/iM/LDLxNk=";
	s:"Iq/ToS6x5lDg5tWZ1Jq9zQhm8v2x3jSEoaSKbn4uFAxsix3QzXWvjdswsms3n"
	"Xq+ZP9SvrZGbtmQbVangEmBPVdaxph4TyiU09CpltqglDIGAFXw/JAYlOO8oy"
	"JLg0LXo0R8c4BvMSUR4oJLbRDvBOYa6QgfwuZi65oF1a0+0EQ=";
	c:"From: Michael Thomas ";
	c:"Date: Mon, 20 Sep 2004 18:25:41 -0700";
	c:"Subject: RE: Rambings on RFC2822 signatures."
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"fasolt.mtcc.com";
	c:"message from fasolt.mtcc.com verified; "
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


Rand Wacker writes:
 > 
 > On Sun, 19 Sep 2004, David Woodhouse wrote:
 > 
 > > On Sat, 2004-09-18 at 23:58 -0500, Seth Goodman wrote:
 > 
 > > > Lists do it now by the submitting address (broken ones use the
 > > > return-path), so they can switch to validating signatures instead.
 > >
 > > I disagree. That reduces it to a hop-by-hop scheme again. In order to
 > > determine the probability that this message really did come from me,
 > > you'd have to ponder how much you trust the list server to have actually
 > > checked.
 > 
 > When handling mail list mail, I would *much* rather be checking for
 > whitelisting/reputation information about the address of the *list* than
 > the address of individuals posting to it.  Specifically, I don't want to
 > take the risk of having different posts to the same thread being treated
 > differently based on who they are from (almost as risky as today's
 > content-filtering approaches).

It strikes me that trying to decide whether Sender, From,
etc is "best" is not really a worthwhile prediction to make.
The fact is, both From and Sender's identities are
interesting pieces of information, and may tell you
different things. From that standpoint, it seems that more
information rather than "best" information is a better hedge
for the future.

 > Its not that Seth's suggestion "reduces" the crypto solution to a
 > hop-by-hop scheme, but that the mailing list really *should* be taking
 > responsibility for the message.

To the degree that it can, of course. It can ultimately boot
a user from the list, but counting on that kind of
enforcement is going to be a longer term proposition. I
suspect that -- as now with receiver based content filtering
-- a "preponderance of evidence" is still going to rule the
day. Having both From and Sender authorized give you two
reputations to develop that judgement. That seems like a
nice feature, not a bug, and by allowing both we get to
defer which is *really* most interesting to actual real live
deployments.

		Mike


From owner-ietf-mailsig Tue Sep 21 18:59:38 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8M1xc7q094638
	for ; Tue, 21 Sep 2004 18:59:38 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8M1xcRk094637
	for ietf-mailsig-skb; Tue, 21 Sep 2004 18:59:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from machshav.com (machshav.com [147.28.0.16])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8M1xbih094631
	for ; Tue, 21 Sep 2004 18:59:37 -0700 (PDT)
	(envelope-from smb@research.att.com)
Received: by machshav.com (Postfix, from userid 512)
	id 85D45FB27D; Tue, 21 Sep 2004 21:59:41 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 2475AFB262
	for ; Tue, 21 Sep 2004 21:59:41 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP id 1EC3C1AE7E
	for ; Tue, 21 Sep 2004 21:59:40 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: ietf-mailsig@imc.org
Subject: Re: Draft minutes for MASS BoF 
In-Reply-To: Your message of "Tue, 31 Aug 2004 10:09:37 PDT."
             <4.3.2.7.2.20040831100340.0408dc10@mira-sjc5-1.cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Sep 2004 21:59:40 -0400
Message-Id: <20040922015940.1EC3C1AE7E@berkshire.research.att.com>
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 



During the meeting in San Diego, we had the following exchange:
>
>Q: Does Microsoft claim any IPR on this?
>
>A: Don't know.  The original author is on LOA.
>


Does anyone -- and in particular anyone from Microsoft -- have any new 
information?

		--Steve Bellovin, http://www.research.att.com/~smb



From owner-ietf-mailsig Wed Sep 22 05:29:19 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MCTI4D045648
	for ; Wed, 22 Sep 2004 05:29:18 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8MCTIBE045647
	for ietf-mailsig-skb; Wed, 22 Sep 2004 05:29:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MCTIGu045640
	for ; Wed, 22 Sep 2004 05:29:18 -0700 (PDT)
	(envelope-from andy@hxr.us)
Received: from [10.0.1.3] ([::ffff:64.83.8.178])
  (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA)
  by zak.ecotroph.net with esmtp; Wed, 22 Sep 2004 08:29:17 -0400
  id 001B7A92.4151701D.000066DC
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <026BBE4A-0C93-11D9-BE1D-000A95B3BA44@hxr.us>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: ietf-mailsig@imc.org
From: Andrew Newton 
Subject: SES docs
Date: Wed, 22 Sep 2004 08:29:12 -0400
X-Mailer: Apple Mail (2.619)
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


Excuse me for being dense, but where can I find documentation on SES?

-andy


From owner-ietf-mailsig Wed Sep 22 07:37:05 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MEb5ow055968
	for ; Wed, 22 Sep 2004 07:37:05 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8MEb59M055967
	for ietf-mailsig-skb; Wed, 22 Sep 2004 07:37:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from joy.songbird.com (clint.songbird.com [208.184.79.11])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MEb5PF055960
	for ; Wed, 22 Sep 2004 07:37:05 -0700 (PDT)
	(envelope-from richard@shockey.us)
Received: from RSHOCKEY-LTXP.shockey.us (neustargw.va.neustar.com [209.173.53.233])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i8MEaPq17072;
	Wed, 22 Sep 2004 07:36:25 -0700
Message-Id: <6.1.0.6.2.20040922103501.04156030@joy.songbird.com>
X-Sender: richard@joy.songbird.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6
Date: Wed, 22 Sep 2004 10:36:11 -0400
To: ietf@ietf.org
From: Richard Shockey 
Subject: FYI - US Government requesting information on E-Mail
  Authentication
Cc: ietf-mailsig@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 



For Release: September 15, 2004

FTC, NIST to Host E-mail Authentication Summit

Adoption of Technology Could Help Thwart Spam

The Federal Trade Commission and National Institute of
Standards and Technology (NIST) will co-host a two-day
"summit" November 9-10 to explore the development and
deployment of technology that could reduce spam. The
E-mail Authentication Summit will focus on challenges
in the development, testing, evaluation, and
deployment of domain-level authentication systems.

A Federal Register Notice to be published today notes
that the FTC's National Do Not
E-mail Registry Report to Congress stated that
"significant security, enforcement, practical and
technical challenges rendered a registry an
ineffective solution to the spam problem." The report
identified domain-level authentication as a promising
technology that would enable Internet Service
Providers (ISPs) and others to better filter spam, and
would provide law enforcers a tool to locate and
identify spammers.

The Notice states that the Simple Mail Transfer
Protocol (SMTP) currently in use for
e-mail allows spammers to use techniques like
"spoofing," open relays, open proxies, and "zombie
drones" to remain anonymous, evade spam filters, and
elude law enforcers. "To remove this cloak of
anonymity, ISPs and others involved with the e-mail
system have proposed domain-level authentication
systems that would enable a receiving mail server to
verify that an e-mail message actually came from the
sender's purported domain," the notice says.

The FTC is seeking public comment on:

     * Whether any of the proposed authentication
standards (either alone or in conjunction with other
existing technologies) would result in a significant
decrease in the amount of spam received by consumers;

     * Whether ISPs that do not participate in an
authentication regime would face any challenges
providing e-mail services. If so, what types of
challenges these ISPs would face and whether these
challenges would in any way prevent them from
continuing to be able to provide e-mail services;

     * Whether an Internet-wide authentication system
could be adopted within a reasonable amount of time.
Description of industry and standard-setting efforts,
whether there is an implementation schedule in place
and, if so, the time frames of the implementation
schedule;

and 27 other questions listed in the Federal Register
Notice that will be discussed or addressed at the
summit.

Parties who wish to participate in the Summit must
send a statement to the FTC and NIST setting forth
their expertise in, or knowledge of, the issues by
September 30, 2004. The FTC and NIST will select
participants who submitted timely responses that
demonstrate expertise in or knowledge of the issues,
and whose participation would promote the
representation of a balance of interests at the
Summit.

The Commission vote to publish the Federal Register
Notice was 4-0-1 with Commissioner Jon Leibowitz not
participating.

Written comments should be identified as "E-mail
Authentication Summit-Comments," and written requests
to participate in the E-mail Authentication Summit
should be identified as "E-mail Authentication
Summit-Request to Participate." Written comments and
requests to participate should be submitted to:
Secretary, Federal Trade Commission, Room 159-H (Annex
V), 600 Pennsylvania Ave., N.W., Washington, DC 20580.
If submitting in paper form, parties must submit an
original and three copies of each document. The FTC
requests that any comment filed in paper form be sent
by courier or overnight service, since U.S. postal
mail in the Washington area and at the Commission is
subject to delay due to heightened security
precautions. In the alternative, parties may e-mail
comments and requests to participate to
authenticationsummit@ftc.gov. To ensure that the
Commission considers an electronic comment, you must
file it with the FTC at this e-mail address. For
further requirements concerning the filing of comments
and requests to participate, please consult the
Request for Comments and Requests to Participate
sections of the Federal Register Notice for the E-mail
Authentication Summit (linked to this news release on
the FTC Web site: www.ftc.gov.



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141@fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
 or 
 ; 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


From owner-ietf-mailsig Wed Sep 22 07:47:27 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MElRKr056621
	for ; Wed, 22 Sep 2004 07:47:27 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8MElRU0056620
	for ietf-mailsig-skb; Wed, 22 Sep 2004 07:47:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from web14930.mail.yahoo.com (web14930.mail.yahoo.com [216.136.225.159])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i8MElQ63056606
	for ; Wed, 22 Sep 2004 07:47:26 -0700 (PDT)
	(envelope-from mlibbeymail-mailsig@yahoo.com)
Message-ID: <20040922144729.16378.qmail@web14930.mail.yahoo.com>
Received: from [67.169.100.133] by web14930.mail.yahoo.com via HTTP; Wed, 22 Sep 2004 07:47:29 PDT
Date: Wed, 22 Sep 2004 07:47:29 -0700 (PDT)
From: Miles Libbey 
Reply-To: mlibbeymail-mailsig@yahoo.com
Subject: signatures and keys -- what can one know
To: ietf-mailsig@imc.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


Hey folks-
Given a private key, its coresponding public key, and a digital 
signature (but no content), can one prove the signature was generated
using the private key?  If so, which combinations of the above can
prove it? 

miles


From owner-ietf-mailsig Wed Sep 22 07:54:14 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MEsErx057583
	for ; Wed, 22 Sep 2004 07:54:14 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8MEsESH057582
	for ietf-mailsig-skb; Wed, 22 Sep 2004 07:54:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MEsDaP057576
	for ; Wed, 22 Sep 2004 07:54:14 -0700 (PDT)
	(envelope-from fanf2@hermes.cam.ac.uk)
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42123)
	by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25)
	with esmtp (Exim 4.34)
	id 1CA8VZ-0001jb-Lr (return-path fanf2@hermes.cam.ac.uk)
	for ietf-mailsig@imc.org; Wed, 22 Sep 2004 15:54:13 +0100
Received: from fanf2 (helo=localhost)
	by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34)
	id 1CA8VZ-0001Dt-55; Wed, 22 Sep 2004 15:54:13 +0100
Date: Wed, 22 Sep 2004 15:54:13 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Andrew Newton 
cc: ietf-mailsig@imc.org
Subject: Re: SES docs
In-Reply-To: <026BBE4A-0C93-11D9-BE1D-000A95B3BA44@hxr.us>
Message-ID: 
References: <026BBE4A-0C93-11D9-BE1D-000A95B3BA44@hxr.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
X-Cam-AntiVirus: No virus found
X-Cam-SpamDetails: Not scanned
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Wed, 22 Sep 2004, Andrew Newton wrote:
>
> Excuse me for being dense, but where can I find documentation on SES?

Website:       http://ses.codeshare.ca
Latest Draft:  http://ses.codeshare.ca/files/ses_proposal.pdf

Tony.
-- 
f.a.n.finch    http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE FORTIES: NORTHWEST 5 TO 7, OCCASIONALLY GALE
8 AT FIRST IN FORTIES. SHOWERS. GOOD.


From owner-ietf-mailsig Wed Sep 22 08:35:12 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MFZCGN062136
	for ; Wed, 22 Sep 2004 08:35:12 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8MFZCGQ062135
	for ietf-mailsig-skb; Wed, 22 Sep 2004 08:35:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from pentafluge.infradead.org ([213.146.154.40])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MFZ49c062118
	for ; Wed, 22 Sep 2004 08:35:11 -0700 (PDT)
	(envelope-from SRS0+ba6e40e72d677e93dd28+395+infradead.org+dwmw2@pentafluge.srs.infradead.org)
Received: from [213.86.99.236] (helo=[172.16.18.64])
	by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux))
	id 1CA990-0008DH-0A; Wed, 22 Sep 2004 16:35:01 +0100
Subject: Re: SES docs
From: David Woodhouse 
To: Tony Finch 
Cc: Andrew Newton , ietf-mailsig@imc.org
In-Reply-To: 
References: <026BBE4A-0C93-11D9-BE1D-000A95B3BA44@hxr.us>
	 
Content-Type: multipart/mixed; boundary="=-VtKPoEZTGctS5g8LprsB"
Message-Id: <1095867296.17821.1452.camel@hades.cambridge.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) 
Date: Wed, 22 Sep 2004 16:34:57 +0100
X-Spam-Score: 0.0 (/)
X-SRS-Rewrite: SMTP reverse-path rewritten from  by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 



--=-VtKPoEZTGctS5g8LprsB
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Wed, 2004-09-22 at 15:54 +0100, Tony Finch wrote:
> On Wed, 22 Sep 2004, Andrew Newton wrote:
> >
> > Excuse me for being dense, but where can I find documentation on SES?
> 
> Website:       http://ses.codeshare.ca
> Latest Draft:  http://ses.codeshare.ca/files/ses_proposal.pdf

That's a little out of date -- Seth says he should update it soon. Some
information and a brief discourse on the pros and cons can also be found
in my mail to the SPF list many moons ago:
http://archives.listbox.com/spf-discuss@v2.listbox.com/200402/0900.html

Also attached.

-- 
dwmw2

--=-VtKPoEZTGctS5g8LprsB
Content-Disposition: inline
Content-Type: message/rfc822

Subject: Re: [spf-discuss] General Status of SPF
From: David Woodhouse 
To: spf-discuss@v2.listbox.com
In-Reply-To: <20040227214943.GC20156@dumbo.pobox.com>
References: 
	 <1077825254.11584.1067.camel@imladris.demon.co.uk>
	 <70ED8D32-68C3-11D8-96A9-00039358205C@omniti.com>
	 <1077877827.6336.221.camel@hades.cambridge.redhat.com>
	 <1077910806.14059.25.camel@zelda.corporate>
	 <20040227195514.GX20156@dumbo.pobox.com>
	 <1077916748.6336.601.camel@hades.cambridge.redhat.com>
	 <20040227214943.GC20156@dumbo.pobox.com>
Message-Id: <1077923677.6336.732.camel@hades.cambridge.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-8.dwmw2.2) 
Date: Fri, 27 Feb 2004 23:14:38 +0000
X-Evolution-Transport: 
	smtp://dwmw2;auth=CRAM-MD5@pentafluge.infradead.org/;use_ssl=always
X-Evolution-Account: dwmw2@infradead.org
X-Evolution-Fcc: imap://dwmw2@pentafluge.infradead.org/outgoing
X-Evolution-Format: text/plain
Content-Type: text/plain; charset=us-ascii
X-Evolution-Source: imap://dwmw2@pentafluge.infradead.org/
Content-Transfer-Encoding: 7bit

On Fri, 2004-02-27 at 16:49 -0500, Meng Weng Wong wrote:
> So forwarders have to adapt.

This is easier to say if there's actually something concrete to adapt
_to_. But that isn't currently the case; the strategies are still being
debated.

> If there's a different technology that has a better adoption dynamic,
> I'm all ears.  It's never too late to find a better way.

I don't know.

I'm currently experimenting, as I believe I already mentioned, with SRS
on my _own_ outgoing mail, coupled with rejecting bounces to my 'raw'
email address.

It's only been in place a few days, so I haven't actually started
rejecting bounces yet. I've been monitoring though, and the only mails
with empty reverse-path that have arrived to the 'raw' address have been
joe-joe bounces. I'll roll out the actual rejection of bounces over the
weekend (although I've already been doing that for some time for other
old addresses which are forwarded to my current address).

The idea is that there is never valid MAIL FROM:;
only MAIL FROM:

Therefore, I can reject anything with empty reverse-path to the 'raw'
address dwmw2@infradead.org.

Since I do this, any third party who implements sender callouts will
observe that I'm not accepting bounces, and can correctly determine that
it should reject the mail it was trying to verify the sender of.

In this way, my email address is protected from joe-jobbing -- at least
in that _I_ won't receive bounces and third parties implementing some
fairly basic checks won't receive the faked mail. That's all we can hope
for, right?

It's obviously not a _perfect_ scheme, but it seems to work --
admittedly for all of a few days to far on a somewhat limited test set
of one address. I've noted one or two minor problems so far, but nothing
serious. They are:

- Some sites do callouts with postmaster@ rather than MAIL FROM:<>.
It was necessary to make the valid SRS addresses accept such mail in
order to let me send mail to, for example, pobox.com. That's not really 
a problem, except that I didn't think do to so originally. In fact I
think mail from postmaster@ probably ought to be accepted to those
addresses anyway. Since they're limited-lifetime, hash-signed addresses
it doesn't hurt to be a bit permissive.

- Some sites do callouts with postmaster@ rather than MAIL FROM:<>.
Yes I did just say that twice. Sites who call out with postmaster@
rather than the empty SMTP reverse-path don't get the benefit of
rejecting mail with my address faked. Not a _fundamental_ problem, since
this just lumps them in with sites who don't do callouts at all. It
didn't break; it just didn't help them. Still helps _me_ -- since if
they later have to bounce the joe-job for other reasons I won't accept
it because they _will_ be using MAIL FROM:<> at _that_ time.

I'm trying to think back now to what else I've changed since the first
version. I implemented case sensitive hash signing because the localpart
is sometimes forced to lower case elsewhere before it gets back to you.
I think that's about it.

Doing the rewriting in the MTA at SMTP time means it _doesn't_ end up in
the Sender: header, so I don't believe Outlook users see the horrid:
'SRS0+noisynoisynoisynoisynoisy@srs.infradead.org on behalf of David
Woodhouse' which was originally a potential concern.

The only other potential 'problem' I can think of off-hand is with
broken autoresponders. And by 'broken' I mean those which are _already_
considered broken in the Old World, before taking anything above into
account and without changing the rules.

There are two forms of breakage you occasionally see from
autoresponders. Firstly they may reply to the From: address rather than
the SMTP reverse-path, and secondly they may reply with a non-empty
reverse-path in their _own_ mail.

Either of these problems will cause the autoreply to be bounced -- it'll
either be a bounce to the 'raw' address or a 'real' mail to the SRS
address respectively. Of course, if the autoresponder commits _both_ of
the above sins then its mail will get through; more by luck than
judgement. There is a correlation between both forms of brokenness, so
some autoreplies may well get through that way, but some will inevitably
be lost.

I'm happy with that loss -- I'd probably have been reporting such
autoresponders to the abuse contact at the upstream network provider
_anyway_, and the value out-of-office replies is generally low.

To accept that loss is a policy decision which I'm happy enough to make,
but which others may be less happy about. Certainly it's less of a
problem than the false bounces I'd get with a strict implementation of
SPF, and it's fixable by getting people to apply what is _already_
considered common sense, rather than a new form of same.




On the receiving side, you obviously need to do callouts to get the
benefit. Some people consider callouts to be impractically expensive;
that's a matter of opinion and I disagree. 

More importantly: as mentioned above, in order to get the benefit of
this you need to do callouts with MAIL FROM:<>. This is a _real_ problem
for some people, if they have to accept mail from sites in
dsn.rbl-ignorant.org. However, I believe (and this is untested) that it
should be possible to do a callout with MAIL FROM:<> but if the MAIL
command is rejected, then try MAIL FROM:> instead.

That way if the target accepts MAIL FROM:<> you get the real benefit of
checking whether they accept _bounces_, not just real mail -- but if
they don't like that you can still verify the address receives mail from
postmaster@. As I said; that's untested since I do all callouts with
empty reverse-path anyway.

The opposite applies to _recipient_ verification callouts. These must be
done with a _real_ reverse-path. But doing r-v callouts to _unknown_
sites, rather than just between a backup MX and the hosts it's relaying
for, is I think fairly rare. And already breaks if you do it with empty
reverse-path to things like mailing lists, which are increasingly
nowadays starting to reject bounces to the list-submission address.

So in general, it looks promising. 

-- 
dwmw2
--=-VtKPoEZTGctS5g8LprsB--


From owner-ietf-mailsig Wed Sep 22 10:37:21 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MHbLMb072103
	for ; Wed, 22 Sep 2004 10:37:21 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8MHbLUQ072102
	for ietf-mailsig-skb; Wed, 22 Sep 2004 10:37:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound2.mail.tds.net (outbound2.mail.tds.net [216.170.230.92])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MHbKab072083
	for ; Wed, 22 Sep 2004 10:37:20 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound2.mail.tds.net (8.12.10/8.12.2) with SMTP id i8MHbJRT026639
	for ; Wed, 22 Sep 2004 12:37:20 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: 
Subject: RE: signatures and keys -- what can one know
Date: Wed, 22 Sep 2004 12:37:29 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <20040922144729.16378.qmail@web14930.mail.yahoo.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: Miles Libbey
> Sent: Wednesday, September 22, 2004 9:47 AM
>
>
>
> Hey folks-
> Given a private key, its coresponding public key, and a digital
> signature (but no content), can one prove the signature was generated
> using the private key?  If so, which combinations of the above can
> prove it?

I don't believe so.  The signature is created by performing a series of
mathematical functions on the data using the private key.  The corresponding
operation at the recipient is to perform a series of mathematical operations
on the data and the signature using the public key and looking for a known
result.  So to answer your question, the recipient needs the same data that
the sender signed, the signature and the public key to validate, or prove
invalid, the data and signature.

--

Seth Goodman


From owner-ietf-mailsig Wed Sep 22 10:53:22 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MHrMfl072947
	for ; Wed, 22 Sep 2004 10:53:22 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8MHrMxJ072946
	for ietf-mailsig-skb; Wed, 22 Sep 2004 10:53:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MHrMlO072935
	for ; Wed, 22 Sep 2004 10:53:22 -0700 (PDT)
	(envelope-from john.thielens@tumbleweed.com)
Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP (
 Tumbleweed MMS SMTP Relay (Email Firewall v6.0.0)); Wed, 22 Sep 2004
 10:54:28 -0700
X-Server-Uuid: 261D3D77-EF07-4933-A3F2-C3D2C3570679
Received: from JOHNT ([172.20.1.22]) by pigeon.corp.tumbleweed.com with
 SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id
 TJMVVD1G; Wed, 22 Sep 2004 10:53:09 -0700
Message-ID: <005401c4a0cd$085478b0$13321fac@corp.tumbleweed.com>
From: "John Thielens" 
To: mlibbeymail-mailsig@yahoo.com
cc: ietf-mailsig@imc.org
References: <20040922144729.16378.qmail@web14930.mail.yahoo.com>
Subject: Re: signatures and keys -- what can one know
Date: Wed, 22 Sep 2004 10:53:13 -0700
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-WSS-ID: 6D4F63DE2ZG361520-01-02
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> Given a private key, its coresponding public key, and a digital
> signature (but no content), can one prove the signature was generated
> using the private key?  If so, which combinations of the above can
> prove it?

Under CMS, the signature is produced as follows (using typical algorithm
choices):
    content -> sha1 -> content-digest
    content-digest + other signed attributes -> sha1 -> digest-to-sign
    digest-to-sign -> ASN.1 wrapper and DER encoding-> digestInfo
    digestInfo -> EMSA-PKCS1-v1_5 encoding -> big-ol'-int
    big-ol'-int -> private key operation -> signature

So if you have the signature and the public key, you can reverse the last
step to retrieve the big-ol'-int and verify that it looks 1.5 encoded -- 
this would prove that the corresponding private key was used.  The remaining
verification steps serve to bind the signature with the content and/or other
signed attributes.

YMMV with other signing schemes.



From owner-ietf-mailsig Wed Sep 22 23:51:28 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N6pSmF071555
	for ; Wed, 22 Sep 2004 23:51:28 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8N6pSob071554
	for ietf-mailsig-skb; Wed, 22 Sep 2004 23:51:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from main.gmane.org (main.gmane.org [80.91.229.2])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N6pQnR071539
	for ; Wed, 22 Sep 2004 23:51:27 -0700 (PDT)
	(envelope-from gim-ietf-mailsig@gmane.org)
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1CANRt-0005vP-00
	for ; Thu, 23 Sep 2004 08:51:25 +0200
Received: from footbone.midwestcs.com ([206.222.212.237])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for ; Thu, 23 Sep 2004 08:51:25 +0200
Received: from wayne by footbone.midwestcs.com with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for ; Thu, 23 Sep 2004 08:51:25 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-mailsig@imc.org
From: wayne 
Subject: Re: Draft minutes for MASS BoF
Date: Thu, 23 Sep 2004 01:22:39 -0500
Lines: 19
Message-ID: 
References: <4.3.2.7.2.20040831100340.0408dc10@mira-sjc5-1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: footbone.midwestcs.com
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, linux)
Cancel-Lock: sha1:YabXY9GTFFWVqW38zBi5Q2rAsD4=
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


In <4.3.2.7.2.20040831100340.0408dc10@mira-sjc5-1.cisco.com> Jim Fenton  writes:

> 7. Conclusion
>
> Word-smithing the charter will be done on the mailing list, which is
> ietf-mailsig@imc.org (see http://www.imc.org/ietf-mailsig/)
>
> Consensus via hum that effort in this area should go forward.


Has this WG been approved?  I've been only checking in once and a
while since the BoF, but there seems to be a large increase in the
volume in the last couple of weeks since I last checked.

I also noticed that this mailing list isn't listed on
http://www.imc.org


-wayne


From owner-ietf-mailsig Thu Sep 23 04:47:33 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NBlXg5063582
	for ; Thu, 23 Sep 2004 04:47:33 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8NBlXfA063581
	for ietf-mailsig-skb; Thu, 23 Sep 2004 04:47:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from pentafluge.infradead.org ([213.146.154.40])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NBlIlV063547
	for ; Thu, 23 Sep 2004 04:47:33 -0700 (PDT)
	(envelope-from SRS0+7be4efd306a2f1eef3cf+396+infradead.org+dwmw2@pentafluge.srs.infradead.org)
Received: from [213.86.99.236] (helo=[172.16.18.64])
	by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux))
	id 1CAS47-0002df-FH
	for ietf-mailsig@imc.org; Thu, 23 Sep 2004 12:47:12 +0100
Subject: RFC2821 vs. RFC2822 signatures.
From: David Woodhouse 
To: ietf-mailsig@imc.org
Content-Type: text/plain
Message-Id: <1095940030.17821.1711.camel@hades.cambridge.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) 
Date: Thu, 23 Sep 2004 12:47:10 +0100
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-SRS-Rewrite: SMTP reverse-path rewritten from  by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


At what level do we want to sign mail?

Using the RFC2822 identities allows us to do the cute stuff I suggested
in <1095437975.17821.383.camel@hades.cambridge.redhat.com>
about having multiple signatures so you can authenticate any or all of
the From:, Sender:, Resent-{From,Sender}: addresses. But how often will
that actually get used in _practice_?

But using RFC2822 identities means that if you want it to actually
_work_ in today's world, you have to deal with evil stuff like mailing
lists adding extra lines to the text, etc. It's painful.

On the other hand, we could use the RFC2821 MAIL FROM address as the
entity which must sign the mail. By doing that you basically remove the
need to be permissive about signatures -- you _only_ need to
canonicalise it w.r.t charset, etc. Wouldn't that be easier to implement
and deploy?

The disadvantage of using the RFC2821 reverse-path is that it's not
always displayed to the _recipient_ by their MUA. But then the Sender:
and Resent-From: addresses are often not displayed _either_ -- I don't
think that's too much of a problem. It still allows automatic rejection
by the MTA; and in fact it makes it _easier_.

-- 
dwmw2


From owner-ietf-mailsig Thu Sep 23 07:34:49 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NEYneA079219
	for ; Thu, 23 Sep 2004 07:34:49 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8NEYnIZ079218
	for ietf-mailsig-skb; Thu, 23 Sep 2004 07:34:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NEYlU0079202
	for ; Thu, 23 Sep 2004 07:34:48 -0700 (PDT)
	(envelope-from mike@mtcc.com)
Received: from mtcc.com.mtcc.com (fasolt.mtcc.com [216.102.208.10])
	by mtcc.com (8.12.10/8.12.10) with ESMTP id i8NEYjxq010712;
	Thu, 23 Sep 2004 07:34:45 -0700
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16722.57093.468104.148646@mtcc.com>
Date: Thu, 23 Sep 2004 07:34:45 -0700
To: 
Cc: 
Subject: RE: signatures and keys -- what can one know
In-Reply-To: 
References: <20040922144729.16378.qmail@web14930.mail.yahoo.com>
	
X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
IIM-SIG: v:"1"; h:"fasolt.mtcc.com"; d:"mtcc.com"; z:"home"; m:"krs";
	t:"1095950085.739007"; x:"432000"; a:"rsa-sha1"; b:"nofws:1310";
	e:"Iw=="; n:"nVv0qboMtb/jcj1UT0mvfTvYyyFXXGzpd98dYJEDa/uux2xfeB+A0e9dSQ07c"
	"42LbmgdqdIvWuQzlXIdGJ77Qy9oz3RP5a38E2H5O9oPfQNGtaKOiJ6/gELwFy"
	"6wij+H/UTnHFcKILxF9lBlB7xIoFrXH675Blkho/iM/LDLxNk=";
	s:"ClB5LMGCtzdBvIIKrADSZtigBVbT1gvmVN5OaFgQsfLIlQq4kV2sv3mrolOUQ"
	"6LlZ7F6M08KvaXJjGHk5KjAafndGynSJNBn/3h3wS7UW4c0MpVeEIiixLtCyn"
	"n7pzExnJO9m71QjhnryQEQJ1Y/g9usWfBvBNO8qJpiDnACR9M=";
	c:"From: Michael Thomas ";
	c:"Date: Thu, 23 Sep 2004 07:34:45 -0700";
	c:"Subject: RE: signatures and keys -- what can one know"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"fasolt.mtcc.com";
	c:"message from fasolt.mtcc.com verified; "
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


Seth Goodman writes:
 > 
 > > From: Miles Libbey
 > > Sent: Wednesday, September 22, 2004 9:47 AM
 > >
 > >
 > >
 > > Hey folks-
 > > Given a private key, its coresponding public key, and a digital
 > > signature (but no content), can one prove the signature was generated
 > > using the private key?  If so, which combinations of the above can
 > > prove it?
 > 
 > I don't believe so.  The signature is created by performing a series of
 > mathematical functions on the data using the private key.  The corresponding
 > operation at the recipient is to perform a series of mathematical operations
 > on the data and the signature using the public key and looking for a known
 > result.  So to answer your question, the recipient needs the same data that
 > the sender signed, the signature and the public key to validate, or prove
 > invalid, the data and signature.

More to the point, an RSA signature is nothing more than an
encryption using the private key. What you encrypt is rather
up to you, and in the case of a signature it's a one way
hash of some dataset that the verifier can also run when it
receives the message. So I'd say that it's sort of
definitional that if you don't have a hash, or that the
hash is of the null dataset, that it isn't a "signature".

	Mike


From owner-ietf-mailsig Thu Sep 23 08:11:23 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NFBNh3082762
	for ; Thu, 23 Sep 2004 08:11:23 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8NFBNTb082761
	for ietf-mailsig-skb; Thu, 23 Sep 2004 08:11:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NFBN8B082744
	for ; Thu, 23 Sep 2004 08:11:23 -0700 (PDT)
	(envelope-from fenton@cisco.com)
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-5.cisco.com with ESMTP; 23 Sep 2004 08:11:24 -0700
X-BrightmailFiltered: true
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8NFBESI021287;
	Thu, 23 Sep 2004 08:11:14 -0700 (PDT)
Received: from fenton-w2k01.cisco.com (stealth-10-32-245-100.cisco.com [10.32.245.100])
	by imail.cisco.com (8.12.5/8.12.10) with SMTP id i8NFLnZH026516;
	Thu, 23 Sep 2004 08:21:49 -0700
Message-Id: <4.3.2.7.2.20040923080901.04647bf0@mira-sjc5-1.cisco.com>
X-Sender: fenton@mira-sjc5-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 Sep 2004 08:11:11 -0700
To: wayne , ietf-mailsig@imc.org
From: Jim Fenton 
Subject: Re: Draft minutes for MASS BoF
In-Reply-To: 
References: <4.3.2.7.2.20040831100340.0408dc10@mira-sjc5-1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1095952910.833501"; x:"432000"; a:"rsa-sha1"; b:"nofws:870";
	e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda"
	"s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7"
	"674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek=";
	s:"KvEjHqNURPrdocFK50fcIw0pWUJQ3qkZV8NSiLiVp1tJgNSrcajiGMbf5CuXH"
	"6Li7S2uZxuA8Q3I3tTlvk2C8d4Qm1PNgQFA4my/G4Vf0ASzfer5FSpgnQtJzQ"
	"1BHh3xdBgVH0L3cBAyjHmSBOQiv8L7MoX5vzslk5p4xSVgeWE=";
	c:"Date: Thu, 23 Sep 2004 08:11:11 -0700";
	c:"From: Jim Fenton ";
	c:"Subject: Re: Draft minutes for MASS BoF"
IIM-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


At 01:22 AM 9/23/2004 -0500, wayne wrote:

>In <4.3.2.7.2.20040831100340.0408dc10@mira-sjc5-1.cisco.com> Jim Fenton  writes:
>
>> 7. Conclusion
>>
>> Word-smithing the charter will be done on the mailing list, which is
>> ietf-mailsig@imc.org (see http://www.imc.org/ietf-mailsig/)
>>
>> Consensus via hum that effort in this area should go forward.
>
>
>Has this WG been approved?  I've been only checking in once and a
>while since the BoF, but there seems to be a large increase in the
>volume in the last couple of weeks since I last checked.

Not yet; there is still the issue of the proposed WG charter to work out.  Planning is proceeding for a second BoF at the November IETF.


>I also noticed that this mailing list isn't listed on
>http://www.imc.org

Thanks for noticing; I'll mention that to Paul Hoffman.

-Jim


From owner-ietf-mailsig Thu Sep 23 08:28:30 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NFSUFJ085375
	for ; Thu, 23 Sep 2004 08:28:30 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8NFSU5n085374
	for ietf-mailsig-skb; Thu, 23 Sep 2004 08:28:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from machshav.com (machshav.com [147.28.0.16])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NFSToQ085365
	for ; Thu, 23 Sep 2004 08:28:30 -0700 (PDT)
	(envelope-from smb@research.att.com)
Received: by machshav.com (Postfix, from userid 512)
	id AC0AAFB27D; Thu, 23 Sep 2004 11:28:30 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP
	id 347F3FB279; Thu, 23 Sep 2004 11:28:30 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id F30001AE86; Thu, 23 Sep 2004 11:28:28 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: Steve Bellovin 
To: ietf-mailsig@imc.org
Subject: plans for Washington
Cc: housley@vigilsec.com, hardie@qualcomm.com, jis@Mit.edu, klensin@jck.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Sep 2004 11:28:28 -0400
Message-Id: <20040923152828.F30001AE86@berkshire.research.att.com>
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


Given the confusion in San Diego about the mission of this group -- 
and, frankly, given what's happening with MARID -- the ADs involved 
have decided that we need another BoF in Washington to sort that out.  
More specifically, we're going to hold a BoF whose sole purpose is to 
produce a narrow, tightly focused charter.  To aid in that, we've asked 
two experienced former ADs -- Jeff Schiller (Security) and John 
Klensin (Applications) -- to chair the next meeting.  They're not 
involved in the subject, and not in any particular camp; they do have 
the expertise to narrow in on a single focus for this group.  We have 
*not* asked either of them to chair any possible future working group; 
this is a one-shot deal.

It's probably wise for the discussion on this list to concentrate on 
the charter issue -- let's get as much done as possible before the 
meeting.

		--Steve Bellovin, http://www.research.att.com/~smb



From owner-ietf-mailsig Thu Sep 23 13:50:33 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NKoXfE013905
	for ; Thu, 23 Sep 2004 13:50:33 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8NKoXBB013904
	for ietf-mailsig-skb; Thu, 23 Sep 2004 13:50:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NKoVgs013897
	for ; Thu, 23 Sep 2004 13:50:32 -0700 (PDT)
	(envelope-from sb0-0684722c78-johnl@iecc.com)
Received: (qmail 11187 invoked by uid 100); 23 Sep 2004 20:50:32 -0000
Date: 23 Sep 2004 20:50:32 -0000
Message-ID: <20040923205032.11186.qmail@xuxa.iecc.com>
From: John Levine 
To: ietf-mailsig@imc.org
Subject: What's in the charter
In-Reply-To: <20040923152828.F30001AE86@berkshire.research.att.com>
Organization: I.E.C.C., Trumansburg NY USA
Cc: smb@research.att.com
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


>It's probably wise for the discussion on this list to concentrate on
>the charter issue -- let's get as much done as possible before the
>meeting.

Yes, indeed.  Here's some questions that relate to a charter that
occur to me:

How extensive is the group's goal?  Spec out a signature scheme for
draft standard?  Rough out the parameters but leave the details for
experimental deployment?  Lay out all the options and leave it at that?

Also, it might be useful to figure out in what areas everyone agrees,
and in what there are differences to be worked out.

I think we all agree that the goal is to define or create a scheme in
which senders can put signatures on mail messages and recipients can
verify them.  The recipients need some way to fetch the verification
key.  Do all the schemes use DNS for that, or are there others?

It is my impression that one large vendor prefers to to verification
and perhaps signing in the MUA, while all the rest prefer the MTA.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web


From owner-ietf-mailsig Thu Sep 23 14:23:17 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NLNHed016420
	for ; Thu, 23 Sep 2004 14:23:17 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8NLNHmM016419
	for ietf-mailsig-skb; Thu, 23 Sep 2004 14:23:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound1.mail.tds.net (outbound1.mail.tds.net [216.170.230.91])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NLNGFv016413
	for ; Thu, 23 Sep 2004 14:23:16 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound1.mail.tds.net (8.12.10/8.12.2) with SMTP id i8NLNJif015466;
	Thu, 23 Sep 2004 16:23:19 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: 
Cc: 
Subject: RE: What's in the charter
Date: Thu, 23 Sep 2004 16:23:23 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <20040923205032.11186.qmail@xuxa.iecc.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: John Levine
> Sent: Thursday, September 23, 2004 3:51 PM

<...>

> I think we all agree that the goal is to define or create a scheme in
> which senders can put signatures on mail messages and recipients can
> verify them.  The recipients need some way to fetch the verification
> key.  Do all the schemes use DNS for that, or are there others?

The SES scheme uses a custom UDP service or DNS to do signature
verification.  So there are mechanisms outside DNS, but more importantly,
this scheme has the sender validating the signature instead of the
recipient.  It shouldn't be a problem for one syntax to allow signature
validation to occur in a variety of ways.  In some cases, the request for
external validation _is_ a DNS request.

--

Seth Goodman


From owner-ietf-mailsig Thu Sep 23 15:31:21 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NMVL2b020378
	for ; Thu, 23 Sep 2004 15:31:21 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8NMVLiv020377
	for ietf-mailsig-skb; Thu, 23 Sep 2004 15:31:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from sokol.elan.net (sokol.elan.net [216.151.192.200])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NMVKd4020365
	for ; Thu, 23 Sep 2004 15:31:20 -0700 (PDT)
	(envelope-from william@elan.net)
Received: from sokol.elan.net (localhost.localdomain [127.0.0.1])
	by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i8NMiaD4020130;
	Thu, 23 Sep 2004 15:44:36 -0700
Received: from localhost (william@localhost)
	by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i8NMiair020127;
	Thu, 23 Sep 2004 15:44:36 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Thu, 23 Sep 2004 15:44:36 -0700 (PDT)
From: "william(at)elan.net" 
To: John Levine 
cc: ietf-mailsig@imc.org, 
Subject: Re: What's in the charter
In-Reply-To: <20040923205032.11186.qmail@xuxa.iecc.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 



On 23 Sep 2004, John Levine wrote:

> I think we all agree that the goal is to define or create a scheme in
> which senders can put signatures on mail messages and recipients can
> verify them. 
This all depends what you define sender to be. 

I would limit it only to that email servers put signatures and other mail 
servers and recepients can verify it. Putting signatures by "senders"
is already covered by S/MIME and PGP. 

> The recipients need some way to fetch the verification
> key.  Do all the schemes use DNS for that, or are there others?
Yes there are.
Cisco Identified Mail is using web based verification.

MTA Signatures is not bound to one signature verification system at all 
and designed with ability to support ones that are based on http, beep,
dns, etc. I described two basic methods to start with - dns and web based
certificate retrieval and next one I'm going to describe is SCVP based.

For future I would envision system to be some key verification server that
can run on either httpd or beep (including beep over udp - as alternative
to dns) and can support "web of trust" verification.
 
> It is my impression that one large vendor prefers to to verification
> and perhaps signing in the MUA, while all the rest prefer the MTA.
Correct. Seems only Verisign wants MUAs

---
William Leibzon, Elan Networks:
 mailto: william@elan.net
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/


From owner-ietf-mailsig Thu Sep 23 15:59:59 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NMxxhf023622
	for ; Thu, 23 Sep 2004 15:59:59 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8NMxxXj023621
	for ietf-mailsig-skb; Thu, 23 Sep 2004 15:59:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from joy.songbird.com (clint.songbird.com [208.184.79.11])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NMxwku023614
	for ; Thu, 23 Sep 2004 15:59:59 -0700 (PDT)
	(envelope-from dcrocker@brandenburg.com)
Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8NN03q25377
	for ; Thu, 23 Sep 2004 16:00:04 -0700
From: Dave Crocker 
To: "ietf-mailsig@imc.org" 
X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION
X-URL: http://www.pocomail.com/
Date: Thu, 23 Sep 2004 16:00:02 -0700
Message-ID: <20049231602.759608@bbprime>
Subject: candidate MASS charter
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


Folks,

The enclosed an outgrowth from the previous BOF.  I have tried to fold 
in some comments that were made about the draft circulated then, 
although this is essentially a new draft.  It tries to be very tightly 
focused, have an aggressive schedule, and produce something of clear and 
immediate utility.

Whether any of this is actually feasible will depend upon the resolve of 
the working group participants to meet the schedule and make the 
necessary compromises.  



>  DRAFT CHARTER
>
>    Message Authentication Signature Service (MASS)
>
>  CHAIR(S)
>  APPLICATION AREA DIRECTOR(S):
>  AREA ADVISOR
>  MAILING LISTS:
>
>  DESCRIPTION OF WORKING GROUP:
>
>  Internet mail transfers are increasingly subject to fraudulent
>  claims of content authorship. Classic encryption-based
>  authentication techniques can be applied to this problem. However
>  the task of protecting the transfer phase of email may permit
>  tailored solutions that would not be appropriate for longer-term
>  authentication requirements. The MASS working group will produce
>  specifications that support transfer-related, encryption-based
>  authentication of an email message and its contents.
>
>  Existing standardized mechanisms, for attaching a digital signature
>  to an email message, are designed for different use than is required
>  in this application. These distinctive requirements and
>  characteristics may include:
>
>    -  Automated signing of outgoing messages by any SMTP-initiating
>       entity.
>    -  Minimal computational and transactional overhead for high-volume
>       email servers.
>    -  Anonymity when when desired by the sender
>    -  Short term protection for purposes of transit
>    -  DNS-based key-related queries
>    -  Facilitating offline validation
>
>  The working group will review and revise this list, in order to
>  provide a clear statement of the engineering constraints and
>  freedoms that apply to this work.
>
>  There are several proposals for a mechanism by which outgoing
>  messages may offer limited proof of verifiable identity. They will
>  serve as input to the working group.
>
>    -  DomainKeys, draft-delany-domainkeys-base-01.txt
>    -  Identified Internet Mail, draft-fenton-identified-mail-00.txt
>    -  E-mail Postmarks, http://www.lessspam.org/EmailPostmarks.pdf
>    -  MTA Signatures, http://www.elan.net/~william/mta_signatures.htm
>    -  Entity-to-Entity S/MIME, draft-hallambaker-entity-00.txt
>       
>  The working group will seek to produce a minimal set of
>  specifications, using as much prior work as possible.
>  The following work items are explicitly ruled out of the scope of
>  MASS:
>
>    -  Authentication based on IP Address
>    -  Rating services for conveying accreditation information
>       about the signing entities
>
>  DELIVERABLES:
>
>  The MASS working group will specify an Internet mail mechanism for
>  transit-time use, to cryptographically authentic the author or
>  sender of a message and its content; the working group will
>  determine which is used. The working group will determine which
>  portions of the Internet mail protocols to modify.
> 
>  The MASS mechanism will include the following characteristics:

>    -  A threat analysis for this mechanism

>    -  Specification of the precise message contents being signed
>       (notably which headers)
>     
>    -  A method for signing the message and its content, using public
>       key technology

>    -  The parametric information to be included in the message, to
>       permit validation of the signature. This may include a key
>       identifier or a key-holder identifier or a copy of the key.
>       This also may include DNS resolution and/or may include
>       additional Internet queries.
>     
>    -  Recommended procedures for message senders when they encounter
>       message receivers that do not support the MASS mechanisms

>  The following work items are explicitly ruled out of the scope of
>  MASS:

>    -  Address-based authentication
>    -  Rating services for conveying accreditation information about
>       the signing entities
>
>  GOALS AND MILESTONES:
>
>  Oct 04   Initial discussion
>           Circulate written proposals
>
>  Nov 04   Consensus statement of threat analysis and requirements
>
>  Dec 04   Consensus statement on design approach
            Consensus statement on canonicalization
>           Obtain external design reviews
>
>  Feb 05   Stable drafts for review
>           Obtain external reviews
>
>  Apr 05   Final WG draft
>           WG Last Call
>           IETF Last Call

d/
--
Dave Crocker  
Brandenburg InternetWorking  





From owner-ietf-mailsig Thu Sep 23 16:11:49 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NNBnHG024401
	for ; Thu, 23 Sep 2004 16:11:49 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8NNBnri024400
	for ietf-mailsig-skb; Thu, 23 Sep 2004 16:11:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from mynah.mail.pas.earthlink.net (mynah.mail.pas.earthlink.net [207.217.120.228])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NNBnuZ024394
	for ; Thu, 23 Sep 2004 16:11:49 -0700 (PDT)
	(envelope-from dmayne@corp.earthlink.net)
Received: from nat-1.sea.fw.earthlink.net ([165.121.0.80] helo=[10.110.4.98])
	by mynah.mail.pas.earthlink.net with asmtp (Exim 4.34)
	id 1CAV3B-0006yJ-5q
	for ietf-mailsig@imc.org; Thu, 23 Sep 2004 07:58:25 -0700
Message-ID: <4152E4A0.9020702@corp.earthlink.net>
Date: Thu, 23 Sep 2004 07:58:40 -0700
From: David Mayne 
User-Agent: Mozilla Thunderbird 0.6 (Macintosh/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-mailsig@imc.org
Subject: Re: RFC2821 vs. RFC2822 signatures.
References: <1095940030.17821.1711.camel@hades.cambridge.redhat.com>
In-Reply-To: <1095940030.17821.1711.camel@hades.cambridge.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 5acf2cae3254f99c5e89bb4777695beb702e37df12b9c9ef2371cebc097792443e7d683c027ac7ec350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 165.121.0.80
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


David Woodhouse wrote:

>The disadvantage of using the RFC2821 reverse-path is that it's not
>always displayed to the _recipient_ by their MUA. But then the Sender:
>and Resent-From: addresses are often not displayed _either_ -- I don't
>think that's too much of a problem. It still allows automatic rejection
>by the MTA; and in fact it makes it _easier_.
>
>  
>
While there are  advantages to having some form of encrypton in RFC2821 
return path  checking, I'd hate to see that as the only thing this group 
focuses on, just because it is perceived to be easier. All it buys is 
some form of bounce address verification, which could have nothing to do 
with the author of a message, a place where I believe crypto has very 
disctinct advantages over channel based IP authentication and/or 
authorization.

We take in many millions of messages a day, but I still don't see 
automatic rejection of mail at the MTA RFC2821 level to be a very 
significant win. Other factors, besides an address where bounces should 
be sent, will factor in scoring the message, so we need to take it in 
anyway.

David


From owner-ietf-mailsig Thu Sep 23 16:19:26 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NNJQPR024949
	for ; Thu, 23 Sep 2004 16:19:26 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8NNJQ2n024948
	for ietf-mailsig-skb; Thu, 23 Sep 2004 16:19:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from joy.songbird.com (clint.songbird.com [208.184.79.11])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NNJQXT024942
	for ; Thu, 23 Sep 2004 16:19:26 -0700 (PDT)
	(envelope-from dhc@dcrocker.net)
Received: from 192.168.0.3 (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with SMTP id i8NNJVq26290;
	Thu, 23 Sep 2004 16:19:31 -0700
From: Dave Crocker 
To: 
CC: 
X-Mailer: PocoMail 3.1 (1880) - EVALUATION VERSION
X-URL: http://www.pocomail.com/
Reply-To: Dave Crocker 
Date: Thu, 23 Sep 2004 16:19:28 -0700
Message-ID: <2004923161928.138396@bbprime>
In-Reply-To: <20040923205032.11186.qmail@xuxa.iecc.com>
Subject: Re: What's in the charter
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


>  I think we all agree that the goal is to define or create a scheme in
>  which senders can put signatures on mail messages and recipients can
>  verify them.  The recipients need some way to fetch the verification
>  key.  Do all the schemes use DNS for that, or are there others?

A point to consider:  Information in the DNS can always be obtained from 
elsewhere.  The DNS might contain the 'master' copy, or it might contain 
a 'secondary' copy.  In any event, schemes do better when they 
distinguish between the information that is needed, versus how it is 
obtained.  This permits obtaining it through alternative mechanisms.


>  It is my impression that one large vendor prefers to to verification
>  and perhaps signing in the MUA, while all the rest prefer the MTA.

Another point to consider:  An architecture that presumes implementation 
in the infrastructure cannot be implemented at the endpoints.  An 
architecture that presumes implementation at the endpoints often can 
have infrastructure agents implement them "on behalf of" the endpoints.


d/
--
Dave Crocker  
Brandenburg InternetWorking  





From owner-ietf-mailsig Thu Sep 23 18:25:41 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8O1PfCU032320
	for ; Thu, 23 Sep 2004 18:25:41 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8O1Pfbg032319
	for ietf-mailsig-skb; Thu, 23 Sep 2004 18:25:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound3.mail.tds.net (outbound3.mail.tds.net [216.170.230.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8O1Pe4D032313
	for ; Thu, 23 Sep 2004 18:25:40 -0700 (PDT)
	(envelope-from sethg@GoodmanAssociates.com)
Received: from cray3 (mdsnwinas03pool0-a186.mdsnwi.tds.net [216.165.148.186])
	by outbound3.mail.tds.net (8.12.10/8.12.2) with SMTP id i8O1PcNg013196;
	Thu, 23 Sep 2004 20:25:42 -0500 (CDT)
Reply-To: 
From: "Seth Goodman" 
To: "John Levine" , 
Cc: 
Subject: RE: What's in the charter
Date: Thu, 23 Sep 2004 20:25:48 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <20040923205032.11186.qmail@xuxa.iecc.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


> From: John R Levine [mailto:johnl@iecc.com]
> Sent: Thursday, September 23, 2004 4:36 PM
> To: Seth Goodman
> Subject: RE: What's in the charter
>
>
> > The SES scheme uses a custom UDP service or DNS to do signature
> > verification.
>
> I don't consider the unscalable UDP hack to be a serious proposal.  But
> you already knew that.
>
> R's,
> John

I believe it does scale, as do numerous others, and it is as serious a
proposal as yours.  I see no reason why a single-purpose UDP service is a
hack, nor do the other people who have worked on this.  You are certainly
entitled to your opinion, but please stop sending me off-list insults unless
you want them posted.  I ignored the first few, but enough is enough.

--

Seth Goodman


From owner-ietf-mailsig Thu Sep 23 21:13:21 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8O4DLn0044354
	for ; Thu, 23 Sep 2004 21:13:21 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8O4DL9m044353
	for ietf-mailsig-skb; Thu, 23 Sep 2004 21:13:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from web14923.mail.yahoo.com (web14923.mail.yahoo.com [216.136.225.7])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i8O4DKMh044345
	for ; Thu, 23 Sep 2004 21:13:20 -0700 (PDT)
	(envelope-from mlibbeymail-mailsig@yahoo.com)
Message-ID: <20040924041325.48083.qmail@web14923.mail.yahoo.com>
Received: from [67.169.100.133] by web14923.mail.yahoo.com via HTTP; Thu, 23 Sep 2004 21:13:25 PDT
Date: Thu, 23 Sep 2004 21:13:25 -0700 (PDT)
From: Miles Libbey 
Reply-To: mlibbeymail-mailsig@yahoo.com
Subject: Re: candidate MASS charter
To: "ietf-mailsig@imc.org" 
In-Reply-To: <20049231602.759608@bbprime>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-mailsig@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


I wondering if the charter should clarify the first sentence's problem
statement.  It seems to me that there are (at least) 2 distinct
problems in that 1st sentence:
- Forgery from an end user's point of view: if the mail says "From: X,"
X should have authorized the sending of that mail.
- Joe-jobs: A user should only get bounce notifications to mail that
the user authorized to be sent.

I think it perfectly reasonable to attack both problems, but probably
in separate specs.  

miles
--- Dave Crocker  wrote:

> 
> Folks,
> 
> The enclosed an outgrowth from the previous BOF.  I have tried to
> fold 
> in some comments that were made about the draft circulated then, 
> although this is essentially a new draft.  It tries to be very
> tightly 
> focused, have an aggressive schedule, and produce something of clear
> and 
> immediate utility.
> 
> Whether any of this is actually feasible will depend upon the resolve
> of 
> the working group participants to meet the schedule and make the 
> necessary compromises.  
> 
> 
> 
> >  DRAFT CHARTER
> >
> >    Message Authentication Signature Service (MASS)
> >
> >  CHAIR(S)
> >  APPLICATION AREA DIRECTOR(S):
> >  AREA ADVISOR
> >  MAILING LISTS:
> >
> >  DESCRIPTION OF WORKING GROUP:
> >
> >  Internet mail transfers are increasingly subject to fraudulent
> >  claims of content authorship. Classic encryption-based
> >  authentication techniques can be applied to this problem. However
> >  the task of protecting the transfer phase of email may permit
> >  tailored solutions that would not be appropriate for longer-term
> >  authentication requirements. The MASS working group will produce
> >  specifications that support transfer-related, encryption-based
> >  authentication of an email message and its contents.
> >
> >  Existing standardized mechanisms, for attaching a digital
> signature
> >  to an email message, are designed for different use than is
> required
> >  in this application. These distinctive requirements and
> >  characteristics may include:
> >
> >    -  Automated signing of outgoing messages by any SMTP-initiating
> >       entity.
> >    -  Minimal computational and transactional overhead for
> high-volume
> >       email servers.
> >    -  Anonymity when when desired by the sender
> >    -  Short term protection for purposes of transit
> >    -  DNS-based key-related queries
> >    -  Facilitating offline validation
> >
> >  The working group will review and revise this list, in order to
> >  provide a clear statement of the engineering constraints and
> >  freedoms that apply to this work.
> >
> >  There are several proposals for a mechanism by which outgoing
> >  messages may offer limited proof of verifiable identity. They will
> >  serve as input to the working group.
> >
> >    -  DomainKeys, draft-delany-domainkeys-base-01.txt
> >    -  Identified Internet Mail, draft-fenton-identified-mail-00.txt
> >    -  E-mail Postmarks, http://www.lessspam.org/EmailPostmarks.pdf
> >    -  MTA Signatures,
> http://www.elan.net/~william/mta_signatures.htm
> >    -  Entity-to-Entity S/MIME, draft-hallambaker-entity-00.txt
> >       
> >  The working group will seek to produce a minimal set of
> >  specifications, using as much prior work as possible.
> >  The following work items are explicitly ruled out of the scope of
> >  MASS:
> >
> >    -  Authentication based on IP Address
> >    -  Rating services for conveying accreditation information
> >       about the signing entities
> >
> >  DELIVERABLES:
> >
> >  The MASS working group will specify an Internet mail mechanism for
> >  transit-time use, to cryptographically authentic the author or
> >  sender of a message and its content; the working group will
> >  determine which is used. The working group will determine which
> >  portions of the Internet mail protocols to modify.
> > 
> >  The MASS mechanism will include the following characteristics:
> 
> >    -  A threat analysis for this mechanism
> 
> >    -  Specification of the precise message contents being signed
> >       (notably which headers)
> >     
> >    -  A method for signing the message and its content, using
> public
> >       key technology
> 
> >    -  The parametric information to be included in the message, to
> >       permit validation of the signature. This may include a key
> >       identifier or a key-holder identifier or a copy of the key.
> >       This also may include DNS resolution and/or may include
> >       additional Internet queries.
> >     
> >    -  Recommended procedures for message senders when they
> encounter
> >       message receivers that do not support the MASS mechanisms
> 
> >  The following work items are explicitly ruled out of the scope of
> >  MASS:
> 
> >    -  Address-based authentication
> >    -  Rating services for conveying accreditation information about
> >       the signing entities
> >
> >  GOALS AND MILESTONES:
> >
> >  Oct 04   Initial discussion
> >           Circulate written proposals
> >
> >  Nov 04   Consensus statement of threat analysis and requirements
> >
> >  Dec 04   Consensus statement on design approach
>             Consensus statement on canonicalization
> >           Obtain external design reviews
> >
> >  Feb 05   Stable drafts for review
> >           Obtain external reviews
> >
> >  Apr 05   Final WG draft
> >           WG Last Call
> >           IETF Last Call
> 
> d/
> --
> Dave Crocker  
> Brandenburg InternetWorking  
> 
> 
> 
> 
> 


From owner-ietf-mailsig Thu Sep 23 22:03:26 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8O53Q3j048224
	for ; Thu, 23 Sep 2004 22:03:26 -0700 (PDT)
	(envelope-from owner-ietf-mailsig@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i8O53QWD048223
	for ietf-mailsig-skb; Thu, 23 Sep 2004 22:03:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mailsig@mail.imc.org using -f
Received: from outbound1.mail.tds.net (outbound1.mail.tds.net [216.170.230.91])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i8O53PlJ048213
	for ; Thu, 23 Sep 2004 22:03:26 -0700 (PDT)
	(envelope-from