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(_at_)elan(_dot_)net