1. MASS / DKIM BOF IETF – Paris 4 Août 2005 dkim.org  mipassoc.org/mass IETF – Paris 4 Août 2005 dkim.org  mipassoc.org/mass MIPA

2. 2 2 MASS/DKIM BOF AgendaAgenda  NOTE WELL  AD Greeting Russ 5 min  Agenda bashing Jim & Dave5 min  DKIM Review Eric20 min  IPR comments Miles5 min  Charter Jim & Dave  Review 15 min  Open mic 15 min  Bashing 45 min  DKIM Working Group interest hum5 min  NOTE WELL  AD Greeting Russ 5 min  Agenda bashing Jim & Dave5 min  DKIM Review Eric20 min  IPR comments Miles5 min  Charter Jim & Dave  Review 15 min  Open mic 15 min  Bashing 45 min  DKIM Working Group interest hum5 min

3. 3 3 MIPA MASS/DKIM BOF N O T E W E L L Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to:  the IETF plenary session,  any IETF working group or portion thereof,  the IESG, or any member thereof on behalf of the IESG,  the IAB or any member thereof on behalf of the IAB,  any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices,  the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3978 and RFC 3979.Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice.RFC 3978RFC 3979 Please consult RFC 3978 for details.RFC 3978 Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to:  the IETF plenary session,  any IETF working group or portion thereof,  the IESG, or any member thereof on behalf of the IESG,  the IAB or any member thereof on behalf of the IAB,  any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices,  the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3978 and RFC 3979.Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice.RFC 3978RFC 3979 Please consult RFC 3978 for details.RFC 3978

4. 4 4 MIPA MASS/DKIM BOF Charter Description – Par 1  Forgery of headers that indicate message origin is a problem for users of Internet mail. The MASS working group will produce standards-track specifications that permit authentication of message headers during transit, using public-key signatures and based on domain name identifiers. Keys will be stored in the responsible identity's DNS hierarchy. The specification will be based on the draft-allman-dkim-*.txt Internet-Drafts. The working group will make only the minimal changes deemed useful to improve the viability of services that are based on these specifications. The specifications will contain summaries of the threats, requirements and limitations that are associated with the specified mechanism. The MASS working group will also address mechanisms for advertising "signing policy" so that a recipient can determine whether a valid message signature should be present.

5. 5 5 MIPA MASS/DKIM BOF Charter Description – Pars 2 & 3  The working group will NOT consider related topics, such as reputation and accreditation systems, and message encryption. It will also NOT consider signatures which are intended to make long-term assertions (beyond the expected transit time of a message) nor signatures which attempt to make strong assertions of the identity of the message author.  The working group may also study whether to adopt a work item for specifying a common mechanism to communicate the results of message verification to the message recipient.  The working group will NOT consider related topics, such as reputation and accreditation systems, and message encryption. It will also NOT consider signatures which are intended to make long-term assertions (beyond the expected transit time of a message) nor signatures which attempt to make strong assertions of the identity of the message author.  The working group may also study whether to adopt a work item for specifying a common mechanism to communicate the results of message verification to the message recipient.

6. 6 6 MIPA MASS/DKIM BOF Goals and Milestones Issue initial Internet-Draft[s] of signature specification 7/05 Issue initial Internet-Draft[s] of signature specification Submit to IESG - MASS threats and requirements 10/05 Submit to IESG - MASS threats and requirements Submit to IESG - MASS signature specification 2/06 Submit to IESG - MASS signature specification Submit to IESG - MASS public key Resource Record 2/06 Submit to IESG - MASS public key Resource Record Submit to IESG - MASS policy specification 5/06 Submit to IESG - MASS policy specification Issue initial Internet-Draft[s] of signature specification 7/05 Issue initial Internet-Draft[s] of signature specification Submit to IESG - MASS threats and requirements 10/05 Submit to IESG - MASS threats and requirements Submit to IESG - MASS signature specification 2/06 Submit to IESG - MASS signature specification Submit to IESG - MASS public key Resource Record 2/06 Submit to IESG - MASS public key Resource Record Submit to IESG - MASS policy specification 5/06 Submit to IESG - MASS policy specification

7. 7 7 MIPA MASS/DKIM BOF Open Issues – 1 yes Is the intent of the WG to create standards-track RFCs? no Is the intent of the WG to rubber-stamp the DKIM drafts? ok "minimal changes deemed essential to the viability of the service" too restrictive done "deemed useful to improve the viability of services based on these specifications" Allow extensions that improve functionality by building on the existing core done Should an author (Fenton) be co-chair?

8. 8 8 MIPA MASS/DKIM BOF Open Issues – 2 Several core ideas in META Signatures should be in-scope Wording excludes checking of message content to address header replay Should rendering to users via the MUA be in-scope? done "useful, to improve" should read "useful to improve" done "minimal changes" should read "necessary changes" Add other I-Ds (Murray's, Phil's, or William's) as input documents done Add "most likely" to "keys will be stored…in DNS…"

9. 9 9 MIPA MASS/DKIM BOF Open Issues – 3 Permit key discovery as well as storage Make explicit that interactions with reputation and accreditation systems are in-scope Support advertising locations of X.509 certificates in key records Include investigation of security issues described in draft-housley-mass- sec-review and draft-otis-mass-reputation Should downstream communication of authentication results be out of scope? ok "Document" rather than "communicate" authentication results Alternative key retrieval mechanisms may be defined by future working group process