Comments (some just nit-picks) inline:
At 04:00 PM 9/23/2004 -0700, Dave Crocker wrote:
DRAFT CHARTER
Message Authentication Signature Service (MASS)
Originally, the second S stood for Standards.
CHAIR(S)
APPLICATION AREA DIRECTOR(S):
AREA ADVISOR
MAILING LISTS:
DESCRIPTION OF WORKING GROUP:
Internet mail transfers are increasingly subject to fraudulent
claims of content authorship. Classic encryption-based
authentication techniques can be applied to this problem. However
the task of protecting the transfer phase of email may permit
"protecting"...a lot of people might read encryption into this; is that
intended?
tailored solutions that would not be appropriate for longer-term
Suggest "be appropriate for" -> "meet"
"longer-term": I think the issue here isn't just the strength of the encryption
(longer keys => longer term) but also the overall strength of the solution to
attack via non-cryptographic means, like DNS compromises. So I think I might
say "more robust" or something like that instead.
authentication requirements. The MASS working group will produce
specifications that support transfer-related, encryption-based
authentication of an email message and its contents.
Existing standardized mechanisms, for attaching a digital signature
to an email message, are designed for different use than is required
The commas should be deleted.
in this application. These distinctive requirements and
characteristics may include:
- Automated signing of outgoing messages by any SMTP-initiating
entity.
- Minimal computational and transactional overhead for high-volume
email servers.
- Anonymity when when desired by the sender
- Short term protection for purposes of transit
Is this again a reference to message encryption?
- DNS-based key-related queries
- Facilitating offline validation
The working group will review and revise this list, in order to
provide a clear statement of the engineering constraints and
freedoms that apply to this work.
There are several proposals for a mechanism by which outgoing
messages may offer limited proof of verifiable identity. They will
serve as input to the working group.
- DomainKeys, draft-delany-domainkeys-base-01.txt
- Identified Internet Mail, draft-fenton-identified-mail-00.txt
- E-mail Postmarks, http://www.lessspam.org/EmailPostmarks.pdf
- MTA Signatures, http://www.elan.net/~william/mta_signatures.htm
- Entity-to-Entity S/MIME, draft-hallambaker-entity-00.txt
The working group will seek to produce a minimal set of
specifications, using as much prior work as possible.
The following work items are explicitly ruled out of the scope of
MASS:
- Authentication based on IP Address
- Rating services for conveying accreditation information
about the signing entities
I would say "Rating services or protocols for conveying accreditation or
reputation information..."
DELIVERABLES:
The MASS working group will specify an Internet mail mechanism for
transit-time use, to cryptographically authentic the author or
sender of a message and its content; the working group will
determine which is used. The working group will determine which
portions of the Internet mail protocols to modify.
The MASS mechanism will include the following characteristics:
- A threat analysis for this mechanism
- Specification of the precise message contents being signed
(notably which headers)
- A method for signing the message and its content, using public
key technology
- The parametric information to be included in the message, to
permit validation of the signature. This may include a key
identifier or a key-holder identifier or a copy of the key.
This also may include DNS resolution and/or may include
additional Internet queries.
- Recommended procedures for message senders when they encounter
message receivers that do not support the MASS mechanisms
Is this statement backwards? We need to tell the receivers what to do, there
is no way for a sender to know whether the receiver is MASS-aware or not.
The following work items are explicitly ruled out of the scope of
MASS:
- Address-based authentication
- Rating services for conveying accreditation information about
the signing entities
Is this a duplicate of the above?
GOALS AND MILESTONES:
Oct 04 Initial discussion
Circulate written proposals
Nov 04 Consensus statement of threat analysis and requirements
Dec 04 Consensus statement on design approach
Consensus statement on canonicalization
Obtain external design reviews
Feb 05 Stable drafts for review
Obtain external reviews
Apr 05 Final WG draft
WG Last Call
IETF Last Call