Hi all,
I have a number of comments on what I believe is the latest draft
charter (from August 22nd [1]), that I'd like to see discussed on
the list before we get to Vancouver. I've also suggested some new
text which I'd like to offer for consideration.
The comments are based on sitting through the Paris BoF; reading
mailing list traffic and also the excellent jabber log from Paris.
Apologies in advance if I'm flogging what ought to be dead horses here.
The draft seems to me to have the following failings:
1. It doesn't say why dkim is good or useful - it assumes that the
reader knows - while that may be ok for the readers of this list it
clearly isn't ok in general, nor was it ok in Paris where this was
one of the comments made loudly and often. I think the charter has
to say why dkim is good/useful
2. Those milestones just aren't going to happen. Aiming to get all the
core specs to the IESG during 2006 is IMO much more likely to be
achievable, though still a bit optimistic.
3. The charter doesn't contain any text which would correct the
misapprehension that dkim will "solve" spam, or phishing or whatever.
This again was noted in Paris and is a fair comment - we should add
some "truth in advertising" text to ensure that readers don't get
overly optimistic about what we can achieve.
4. The phrase "minimal change" just doesn't belong in a charter for
a charter like this - its use just offers a very handy stick for
anyone who wants to beat up on the charter. I believe that the real
requirement isn't so much minimal change, but that all changes need
to take into account that there is already deployed technology for
this purpose and we should not make the (required) migration any
more difficult than needs to be the case. Its implicit in any WG
charter (or ought be) that gratuitous changes aren't what we
do - trying to hammer it home in this way is just counter productive.
I'd also suggest some improvements, along the following lines:
5. Add a new deliverable - a dkim overview informational rfc which
is not on the critical path (i.e. can be delivered last) and which
can contain all of the "sales pitch" and "my favourite useful
extension" bits of text we accumulate as we go. In a couple of
contexts I've found this to be a useful way to insulate
the core specs from well-intentioned but currently distracting
contributions. Its also a good way to archive those truly useful
contribitions which are basically too early but can be re-considered
once the core deliverables have been done.
6. I would allow for the later addition of a few deliverables which
can handle changes to ciphersuites, improved/fixed canonicalisation,
and/or alternative ways to distribute publc keys. The logic here is
that these are areas where specs. have been shown to need additional
malleability over the last few years, due to developments in crypto
(e.g. hash fncs>, the discovery of broken c14n (e.g. xml sig) or just
because some specs don't arrive on time (e.g. scvp). I wouldn't start
by planning to have any of these types of spec written but would
like the charter to specifically give the chairs the flexibility to
allow new drafts in these specific areas if they do end up being needed.
7. I think that Russ wanted the threat analysis to be finished before
the WG started. However, I hope that he'll now agree that where we are
now is sufficient for starting a WG so long as we guarantee to finish
the threat analysis (to his satisfaction) before any of the other
documents can progress. This leads to a weird looking, but probbaly
sensible dependency between the proposed milestones. I'm checking this
with Russ at the moment. (Note: even if we take this approach, I'd
also like the threat analysis to have progressed further before
Vancouver, but that's a separate topic.)
So, if someone did agree with all the above, they might come up with
the attached - just to be clear though: I don't mind whether we address
these issues starting from the attached or via some other edits to the
Aug 22nd version, but I really would like to see each of the above
issues addressed,
Regards,
Stephen.
[1] http://mipassoc.org/dkim/dkim-charter-05dc.txt
DRAFT IETF WORKING GROUP CHARTER
11 Oct 2005
Domain Keys Identified Message (DKIM)
CHAIRS:
TBD
AREA DIRECTORS:
Russell Housley, Sam Hartman
AREA ADVISOR:
Russell Housley <housley(_at_)vigilsec(_dot_)com>
MAILING LISTS:
General Discussion: ietf-DKIM(_at_)mipassoc(_dot_)org
To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-DKIM
Archive: http://mipassoc.org/pipermail/ietf-DKIM/
DESCRIPTION OF WORKING GROUP:
The DKIM working group will produce standards-track RFCs specifying how to
sign message headers based on domain name identifiers.
Supporting integrity for the headers that indicate message origin will
allow new and better mail handling services to be built. For example:
- if a domain publishes a policy to the effect that it signs all outbound
email, then detecting mail which pretends to be, but isn't, from that
domain becomes possible - this should allow for many current spam
messages to be more confidently eliminated (though not all, nor will
it prevent new spamming schemes being developed),
- if a verifier can authenticate the mail as being from a domain, then mail
handling policies (e.g. routing, dropping, running more or fewer filters)
for that message can be applied with more confidence in the outcome - this
could help increase the efficiency with which inbound mail is handled and
help safeguard against potential increases in the number of false
positive emails which are wrongly considered spam,
- if most signers take proper care of their signing keys, then domain
signed email should increase accountability, by making it easier to
establish the domain that actually sourced or forwarded a message -
this should improve the ability to track back to the sources of
messages (whether spam or not).
The working group is not intended to, will not, and cannot, "solve" the spam
problem. The technology defined by the working group should however form an
additional weapon in ongoing efforts to deal with spam. Specifically, while
the working group's output may provide ways to deal with some phishing
attacks, since phishing is essentially a social-engineering attack, DKIM
clearly cannot "prevent" phishing attacks.
The public keys required for signature verification may be stored in, or
sourced via, the responsible identity's DNS hierarchy. In the case where the
keys are not directly sourced from the DNS, the working group will use some
existing key distribution technology (e.g. XKMS, SCVP, or DKIM-in-band key
distribution) and will not otherwise develop new key distribution protocols
for this purpose.
The specification will be based on the following drafts:
- draft-allman-DKIM-base-00.txt
- draft-allman-DKIM-ssp-00.txt
- draft-fenton-DKIM-threats-00.txt
Since there is some deployed technology (ref?), the working group should,
other things being equal, avoid making the necessary migration to DKIM harder
than will otherwise be the case.
The following are out of scope of the working group:
- ways to implement reputation and accreditation systems
- message encryption
- signatures which are intended to make long-term assertions
- signatures which attempt to make strong assertions of the
real-world identity of any entity
- duplication of work done by XKMS, PKIX
? duplication of other secure mail protocols (S/MIME, PGP)
? supporting multiple signatures on single messages
? specifying user level signing and/or verificaiton of messages
(though support for this in future may be a goal of this or some
other working group)
?? delegation of signing capabilities
Once the initial goals below are met, 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 outputs will be:
- an informational RFC providing an overview of the area and of DKIM
- an informational RFC presenting a detailed threat analysis of DKIM
- a standards track specification for the signer/verifier protocol
- a standards track specification for DKIM policy handling
? a standards track specification for a DNS resource record
? optional additional specifications which flesh out options allowed
by the base protocol in the following areas:
- message canonicalisation
- key distribution
- cryptographic transforms (e.g. use of new hash algorithms)
GOALS AND MILESTONES:
Unlike most WGs, these milestones contain a mandatory dependency.
The WG cannot meet any of the later goals unless and until the
threat analysis has been approved for submission to the IESG by
the relevant AD.
11/05 Vancouver BoF
01/06 WG formed, initial drafts submitted
05/06 WG last call on threat analysis
07/06 AD accepts threat analysis for IESG agenda
09/06 WG last call on signer/verifier specification
12/06 WG last call on DKIM policy specification
12/06 WG last call on DNS RR specification
12/06 WG last call on overview document
01/07 possible re-charter
_______________________________________________
ietf-dkim mailing list
http://dkim.org