MASS / DKIM BOFMASS / DKIM BOFMASS / DKIM BOFMASS / DKIM BOF

IETF – Paris4 Août 2005

dkim.org dkim.org mipassoc.org/mass mipassoc.org/mass

IETF – Paris4 Août 2005

dkim.org dkim.org mipassoc.org/mass mipassoc.org/mass

MIPA

MASS/DKIM BOF 22MIPA

AgendaAgendaAgendaAgenda

NOTE WELL AD Greeting Russ 5 min

Agenda bashing Jim & Dave 5 min

DKIM Review Eric 20 min

IPR comments Miles 5 min

Charter Jim & Dave Review 15 min Open mic 15 min Bashing 45 min DKIM Working Group interest hum 5 min

NOTE WELL AD Greeting Russ 5 min

Agenda bashing Jim & Dave 5 min

DKIM Review Eric 20 min

IPR comments Miles 5 min

Charter Jim & Dave Review 15 min Open mic 15 min Bashing 45 min DKIM Working Group interest hum 5 min

MASS/DKIM BOF 33MIPA

N O T E W E L LN O T E W E L LN O T E W E L LN 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.

Please consult RFC 3978 for details.

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.

Please consult RFC 3978 for details.

MASS/DKIM BOF 44MIPA

Charter Description – Par 1Charter Description – Par 1Charter Description – Par 1Charter 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.

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.

MASS/DKIM BOF 55MIPA

Charter Description – Pars 2 & 3Charter Description – Pars 2 & 3Charter Description – Pars 2 & 3Charter 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.

MASS/DKIM BOF 66MIPA

Goals and MilestonesGoals and MilestonesGoals and MilestonesGoals and Milestones

7/05 Issue initial Internet-Draft[s] of signature specification Issue initial Internet-Draft[s] of signature specification

10/05 Submit to IESG - MASS threats and requirements Submit to IESG - MASS threats and requirements

2/06 Submit to IESG - MASS signature specification Submit to IESG - MASS signature specification

2/06 Submit to IESG - MASS public key Resource Record Submit to IESG - MASS public key Resource Record

5/06 Submit to IESG - MASS policy specification Submit to IESG - MASS policy specification

7/05 Issue initial Internet-Draft[s] of signature specification Issue initial Internet-Draft[s] of signature specification

10/05 Submit to IESG - MASS threats and requirements Submit to IESG - MASS threats and requirements

2/06 Submit to IESG - MASS signature specification Submit to IESG - MASS signature specification

2/06 Submit to IESG - MASS public key Resource Record Submit to IESG - MASS public key Resource Record

5/06 Submit to IESG - MASS policy specification Submit to IESG - MASS policy specification

MASS/DKIM BOF 77MIPA

Open Issues – 1 Open Issues – 1 Open Issues – 1 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?

MASS/DKIM BOF 88MIPA

Open Issues – 2Open Issues – 2Open Issues – 2Open 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…"

MASS/DKIM BOF 99MIPA

Open Issues – 3Open Issues – 3Open Issues – 3Open 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