On May 9, 2009, at 10:03 AM, Steve Atkins wrote:
On May 9, 2009, at 8:10 AM, Hector Santos wrote:
John Levine wrote:
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
So you have a itemized list of what you consider useless stuff?
Top 10, 5?
Sure. I'll post it in a new thread a little later today.
Summary of features to keep
===========================
DKIM-Signature Header tags
a: The algorithm used to generate the signature
b: The signature itself
bh: The hash of the canonicalised body
c: Message canonicalization
d: The signing domain
h: List of header fields that are signed
s: The selector
t: Signature timestamp
q: List of query methods (maybe - see notes)
v: Version
i: Additional information about the identity of the user or agent
for which this message was signed
TXT RR tags
v: Version of the DKIM key record
p: Public key data
n: Human readable notes
Summary of features to consider dropping
========================================
DKIM-Signature Header tags
x: Signature expiration
l: Body length count
z: Copied header fields
TXT RR tags
g: Granularity of the key
h: Acceptable hash algorithms
k: Key type
s: Service type
t=y: Domain is testing DKIM
t=s: Require that domain in i= and d= are the same
Other changes to consider
=========================
Drop support for SHA1 entirely.
Discussion
==========
We're at a point where we have some experience with the current drafts
and can usefully consider where the spec can be streamlined. As I
understand the IETF process, this is something we're allowed, even
encouraged, to do at this point (though if someone more familiar with
IETF dogma than I could clarify that, that'd be useful).
The simpler a spec is, the easier it is to develop, test and operate,
and the easier it is to explain to others. Any DKIM verifier needs to
support all the parts of the specification, including the optional
ones, in order to interoperate with all in-spec signers. So every
feature of this spec, even the optional ones, carries a significant,
on-going cost.
It's possible to add new features or reintroduce features that are
dropped here through a separate spec layered on top of this one. In
contrast, the core features retained here are mostly essential for any
DKIM usage. Starting with a minimal spec and extending it as needed
seems to be the approach that many successfully deployed protocols
have used (as opposed to creating a large baseline specification, then
specifying profiled subsets of it).
Discussion of features to keep
==============================
DKIM-Signature Header tags
a: The algorithm used to generate the signature
b: The signature itself
bh: The hash of the canonicalised body
c: Message canonicalization
d: The signing domain
h: List of header fields that are signed
s: The selector
t: Signature timestamp
These are the core elements you're going to find in most any security
approach of this sort. While a couple aren't absolutely essential (a=
and c=) I don't think any of this subset are going to be controversial.
q: List of query methods
I don't think q= is going to be controversial either, but I'm
mentioning it separately as it currently only has one value, the
default, it's unlikely to be extended, and if it were it would require
a whole new RFC to do (which rather than extending the q= header,
could add a "new" q= header). It doesn't hurt to keep it, though, as
it's so simple.
v: Version
I doubt this is actually going to be useful - I think any major
evolution of DKIM to "version 2" is far more likely to be handled at
the 822 level of adding a new header (allowing "DKIMv1" and "DKIMv2"
to work in parallel, much as DomainKeys and DKIM do), and minor
evolutions will need to be backwards compatible enough that it won't
be meaningful to bump the version number. I could be wrong and it
doesn't add any real complexity, though, so the cost of keeping it is
very low
(For both v= and q= we should make sure any interop testing includes
tests against "future" version of q= and v=.)
i: Additional information about the identity of the user or agent
for which this message was signed
This one is more controversial. It adds an awful lot of complexity and
confusion about the semantics of what a signature is and quite a few
people (myself included) would prefer it went away. But there are some
potential uses for it, and some are already invested in it, so it
seems unlikely we'd reach any consensus to drop it.
TXT RR tags
p: Public key data
This is the core of the protocol. Must have.
v: Version of the DKIM key record
This is so simple that it's not worth discussing, even if it isn't
technically needed.
n: Human readable notes
Comments fields are often useful, even though they're not essential in
this sort of protocol - especially given the limited space in the TXT
record. The validator simply needs to know to ignore it, though, and
the signer can make the choice to add it or not.
Discussion of features to consider dropping
===========================================
DKIM-Signature Header tags
x: Signature expiration
Expiration is a fairly common feature in signing specifications. But
DK and DKIM are different in that the public key is not distributed to
others, it's always under the control of the signer. Does this add
anything that removing the DNS TXT record doesn't do? Is it used? Is
it necessary?
l: Body length count
This opens up a whole host of security issues, related to being able
to change the rendered content of the message entirely after signing
without breaking the signature. Removing it would remove a security
hole you can drive a bus through. Is it being used? Are there any
situations where it has proved useful?
z: Copied header fields
Has this been useful? Is it likely to remain useful beyond a testing
phase?
TXT RR tags
h: Acceptable hash algorithms
The spec needs to define the supported set of hash algorithms. There
may be some value in a signer being able to state that they're using
an algorithm that isn't supported, perhaps.
But unless there is a viable attack such that an attacker can craft a
message that validates correctly against the domain owner public key
using a hash supported by the spec (sha1 or sha256), without access to
the domain owners private key, then there's no need for this to be in
the TXT record.
k: Key type
Much the same as h=, with the added issue that there's only one
possible key type right now, and if there were a need for k= in the
future it could be added in the same RFC that adds support for
anything other than RSA.
t=y: Domain is testing DKIM
A "test flag" is a little like the version field, except there's much
less history of it's use in Internet standards. It isn't that useful,
and may cause problems.
It seems a questionable choice to define something into a protocol
that's almost immediately useless. Testing takes place only during
startup, then everyone has to support it forever, even though it's
never used again. In the case of DKIM it's also unclear how this would
be useful, as there's no obvious way for a receiver to communicate to
a sender the result of a DKIM validation in testing mode other than an
arrangement outside of the protocol - in which case the testing flag
wouldn't need to be part of the protocol.
Is anyone supporting t=y in a DKIM validator? What does it do in terms
of delivery and communication with the sender that's different to
normal non-test usage? And is it useful?
g: Granularity of the key
s: Service type
t=s: Require that domain in i= and d= are the same
All three of these exist to ask the DKIM validator to compensate for
the domain owners lack of control over usage inside the domain owners
area of control. They don't belong in the basic DKIM signing mechanism.
If they're thought to be useful to identify and control different
aspects of use, what are they, or what are they thought likely to be?
Discussion of other changes to consider
=======================================
Drop support for SHA1 entirely. It's beginning to look
cryptographically very dubious, and is being dropped by pretty much
everyone else. Even if the attacks against it don't affect the way
it's used in DKIM it seems unwise to suggest it be used at all. At the
very least it seems a poor "marketing" move to include an algorithm
that's been dropped by most everyone else as insecure before this spec
is finalized.
"Verifiers MUST support rsa-sha256 and MAY support rsa-sha1.
Signers SHOULD sign using rsa-sha256 and SHOULD NOT sign using rsa-
sha1." might provide enough wiggle room to allow existing code time to
migrate away from SHA1.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html