ietf-64 dkim bof

IETF-64 DKIM BoF

BoF Chairs

Stephen Farrell Barry [email protected] [email protected]

Domain Keys Identified Mail

draft charter, mailing list links,…http://www.dkim.org/

drafts…draft-fenton-dkim-threats-01draft-allman-dkim-base-01draft-allman-dkim-ssp-01

Administrivia

• Agenda & recent version of slides:– http://www3.ietf.org/proceedings/05nov/agenda/dkim.txt

• Scribes…– Elliot Lear (jabber)– A.N. Other?

• Jabber... – Room filled up last time, if you just want a chuckle read via the

web log• http://www.xmpp.org/ietf-logs/[email protected]/2005-11-07.html

– 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: http://www.dkim.org/

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 email, 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


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 email message and to publish "policy" information about how it applies those signatures. Taken together, these willassist 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 whichmail 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 email 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 email, 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 willrequire 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 requirements05/06 WG last call on DKIM signature specification09/06 WG last call on DKIM policy specification12/06 WG last call on DKIM DNS Resource Record12/06 WG last call on overview document

DKIM Agenda


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


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

ietf-64 dkim bof

Documents

dkim agendafarrellagenda

policiesmake dkim

reactionswhats dkim

domain keys

spam services

receiving domain

dkim folks life worse

verifier signature processing