IETF-64 DKIM BoF BoF Chairs Stephen Farrell Barry Leiba Domain Keys Identified Mail draft charter, mailing list links,… drafts… draft-fenton-dkim-threats-01 draft-allman-dkim-base-01 draft-allman-dkim-ssp-01

Administrivia Agenda & recent version of slides: – Scribes… –Elliot Lear (jabber) –A.N. Other? Jabber... –Room filled up last time, if you just want a chuckle read via the web log –Channelling volunteer? Blue sheets… –Why isn’t there a URL for that too?

DKIM Agenda 1.Farrell Agenda and Introduction (10) 2.Leiba Draft charter walkthrough (15) 3.Leiba Charter Discussion (20+) 4.Fenton Threat Analysis (15) 5.Allman Base Spec (10) 6.Allman Policy Spec (10) 7.Farrell Other Deliverables (10) 8.Farrell Open Discussion (20) 9.Leiba Decisions (10)

Level-setting 1.How many people have read the draft charter, the latest drafts and have paid reasonable attention to recent mailing list discussion? 2.How many have read some version of the drafts? 3.How many do care, but don’t fit into the above categories? –Start reading now: Everyone else: –Nothing else on right now, eh? :-)

What’s DKIM’s goal? Overall: create a standard for MTA-MTA/domain “validation” or “accountability” that will help in the battle against spam and will not harm non-participants Next level down: –Allow sending domains to accept responsibility for mail sent from that domain (enables e.g. whitelisting) –Allow receiving domains to suspect “From” spoofing for originating domains (e.g. those that publish signing policies) –Make DKIM resist simple attacks/work-arounds by spammers –Don’t make non-DKIM folks’ life worse (no harm) –Enable other anti-spam services by increasing the confidence mail handling tools can have in their inputs Care is needed: –XX% of current spam involves spoofing abuse –But so does YY% of genuine , so care is needed –Spammers are not dumb, we must consider their reactions

What’s DKIM provide? Allows a domain to assert that it is accountable for a mail message –By adding a digital signature to the headers Allows a receiving domain to use such signatures as yet another input in anti-spam analysis –May react differently if signature present and valid than if absent or invalid –Standardising reactions is not part of DKIM Incidental benefits –Domain-level “Origin” authentication –Message/header integrity-check(s)

How’s DKIM work? Intended primarily for MTA to MTA (hence “domain”) Outbound MTA signs & adds new header line Public keys & other data in originating domain’s DNS Verifier generally an inbound MTA Signature present & DKIM verifier: (“base”) –DNS lookup public key etc. Signature absent & diligent DKIM verifier –DNS lookup policy to see if e.g. sig is “missing” (“ssp”) Repeat: mandating verifier actions out of scope! Details & problematic cases omitted! –Presented later on.

What’s DIKIM not for? Deleting mail messages – actions subsequent to verifier signature processing are out of scope (no MUSTs there at all) Reputation service – any such service will develop separately from DKIM Confidentiality, or user-level security services – use S/MIME or PGP

Where are we now? There is running code and experimental deployment… IPR situation “in-hand” There is a community who recognise the utility of DKIM, and who have (IMO, anyway): –reached rough consensus on, (starting from) these specifications, and, –a well-worked draft charter, and, –who have reacted well to the Paris BoF. Hopefully, a WG next time…

DKIM Agenda 1.Farrell Agenda and Introduction (10) 2.Leiba Draft charter walkthrough (15) 3.Leiba Charter Discussion (20+) 4.Fenton Threat Analysis (15) 5.Allman Base Spec (10) 6.Allman Policy Spec (10) 7.Farrell Other Deliverables (10) 8.Farrell Open Discussion (20) 9.Leiba Decisions (10)

Proposed Charter The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (when done illegitimately, it's called "spoofing"). The DKIM working group will produce standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an message and to publish "policy" information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain.

Proposed Charter The DKIM working group will produce a summary of the threats that are addressed by the standards-track specifications, while acknowledging their limitations and scope. The DKIM working group will also produce security requirements to guide their efforts, and will analyze the impact on senders and receivers who are not using DKIM, particularly any cases in which mail may be inappropriately labeled as suspicious or spoofed.

Proposed Charter While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a tool for defense against them by assisting receiving domains in detecting some spoofing of known domains. The standards-track specifications will not mandate any particular action by the receiving domain when a signature fails to validate. That said, with the understanding that guidance is necessary for implementers, the DKIM documents should discuss a reasonable set of possible actions and strategies, and analyze their likely effects on attacks and on normal delivery. The DKIM working group will not attempt to establish requirements for trust relationships between domains or to specify reputation or accreditation systems.

Proposed Charter The signatures will use public-key cryptography and will be based on domain name identifiers. Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. The specifications will be based on the following Internet Drafts: * draft-fenton-dkim-threats * draft-allman-dkim-base * draft-allman-dkim-ssp which represent experimentation and consensus from a number of designers and early implementors. Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications.

Proposed Charter – out of scope * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. * Message content encryption. * Additional key management protocols or infrastructure. * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. * Signatures that attempt to make strong assertions about the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users). * Duplication of prior work in signed , incuding S/MIME and OpenPGP.

Proposed Charter – Deliverables Once the primary goals are met, the DKIM 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 generation of a standards-track specification on this topic will require an update to the DKIM working group charter. The deliverables for the DKIM working group are these: * An informational RFC providing an overview of DKIM and how it can fit into overall messaging systems, and outlining potential DKIM applictions and future extensions. * An informational RFC presenting a detailed threat analysis of, and security requirements for, DKIM. IESG approval of this document is a prerequisite for the submission of the standards-track specifications. * A standards-track specification for DKIM signature and verification. * A standards-track specification for DKIM policy handling. * A standards-track specification for a DKIM DNS Resource Record.

Proposed Goals and Milestones 02/06 WG last call on DKIM threats and security requirements 05/06 WG last call on DKIM signature specification 09/06 WG last call on DKIM policy specification 12/06 WG last call on DKIM DNS Resource Record 12/06 WG last call on overview document

DKIM Agenda 1.Farrell Agenda and Introduction (10) 2.Leiba Draft charter walkthrough (15) 3.Leiba Charter Discussion (20+) 4.Fenton Threat Analysis (15) 5.Allman Base Spec (10) 6.Allman Policy Spec (10) 7.Farrell Other Deliverables (10) 8.Farrell Open Discussion (20) 9.Leiba Decisions (10)

DKIM Agenda 1.Farrell Agenda and Introduction (10) 2.Leiba Draft charter walkthrough (15) 3.Leiba Charter Discussion (20+) 4.Fenton Threat Analysis (15) 5.Allman Base Spec (10) 6.Allman Policy Spec (10) 7.Farrell Other Deliverables (10) 8.Farrell Open Discussion (20) 9.Leiba Decisions (10)

DKIM Agenda 1.Farrell Agenda and Introduction (10) 2.Leiba Draft charter walkthrough (15) 3.Leiba Charter Discussion (20+) 4.Fenton Threat Analysis (15) 5.Allman Base Spec (10) 6.Allman Policy Spec (10) 7.Farrell Other Deliverables (10) 8.Farrell Open Discussion (20) 9.Leiba Decisions (10)

Other Deliverables Overview RFC: –Not on critical path (delivered last) –Gives an overview of DKIM for readers down the road –Can sweep up Things we thought of but won’t do (now) Text from protocol specs that’s out of place Maybe “polish” some aspects of the threat analysis Additional DKIM usage scenarios –Interested authors: get in touch with chairs Have some volunteers already, looking for a security type Other possible RFCs: –Communicating verification results to recipient Needs a charter change before being done, only planned if everything else is going well –Ciphersuite changes Only as required & if events warrant – say if a weakness were found after base protocol RFC published and easier to do this than to cycle base RFC.

DKIM Agenda 1.Farrell Agenda and Introduction (10) 2.Leiba Draft charter walkthrough (15) 3.Leiba Charter Discussion (20+) 4.Fenton Threat Analysis (15) 5.Allman Base Spec (10) 6.Allman Policy Spec (10) 7.Farrell Other Deliverables (10) 8.Farrell Open Discussion (20) 9.Leiba Decisions (10)

DKIM Agenda 1.Farrell Agenda and Introduction (10) 2.Leiba Draft charter walkthrough (15) 3.Leiba Charter Discussion (20+) 4.Fenton Threat Analysis (15) 5.Allman Base Spec (10) 6.Allman Policy Spec (10) 7.Farrell Other Deliverables (10) 8.Farrell Open Discussion (20) 9.Leiba Decisions (10)

Time for a hum… 1.YES: If you think that a DKIM wg should be formed, with the draft charter as discussed Assume charter amended as per earlier meeting- consensus Maybe note consensus charter amendments here 2.NO: disagree with #1