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 explor