On Jan 28, 2009, at 8:49 PM, Dave CROCKER wrote:
Steve Atkins wrote:
All of these advantages to the receiver could probably be provided
by something a tenth the complexity of DKIM,
Really? Wow.
While I tend to believe that bits of the current spec weren't really
necessary, I believe that the core mechanism is pretty lean, for the
goal it has.
So I'd be interested in seeing your basis for believing that it is
an order of magnitude more complex that it needs to be...
Look at the current thread. Removing just i= and it's friends would
reduce the confusion *of people who are deeply involved in the spec*
by a large factor. It's going to be a lot worse when you start talking
to implementors, coders, sysadmins and marketing folks. That's a good
measure of complexity. I think that considering just "i=" and it's
friends could get me close to an order of magnitude of unneeded
complexity on it's own.
But there's other complexity that's been added either because someone
thinks it might be useful some day, or because someone has an overly
complex use case they're thinking of, one that really doesn't add much
value to the sender or recipient. I know why a lot of this stuff was
added, but if simplicity of spec and ease of implementation were an
overriding goal there's an awful lot that could be removed without
causing significant weakening of the protocol in typical usage.
Going through the spec point by point, and painting big red circles
around each element that adds more complexity than value isn't really
the point[1], but look and see that many of the fields are OPTIONAL or
RECOMMENDED and have reasonable defaults. What would the spec look
like if they all went away and were replaced by the defaults? For the
signer it would look much the same, as they can ignore all those
fields anyway. For the verifier it would be much, much less complex.
There's also ill-defined implementation/semantics of multiple
signatures, though I suspect local policy will likely make the
vagueness in spec less of an issue, and it'll probably be cleaned up
by a best practices document eventually (if it hasn't already).
Cheers,
Steve
[1] At least not in the body of the email. Please don't consider any
of the following as picking a fight, or even demanding a response,
it's mostly just for completeness.
Signature a=. Doubles the work and the QA for that section of verifier
code, and there's no real need for it.
Signature c=. Four times the work and QA for that section of verifier
code and maybe twice the bugs, quite apart from the additional mind
space it takes up.
Signature l=. This adds little to no value, yet makes the analysis of
security and evasion techniques much, much more complex, especially in
an environment as rich in tools ripe for misuse as email is (MIME,
HTML). The complexity this adds to a security analysis of the protocol
as a whole is huge, for fairly small benefit. (Arguably you can reduce
that analysis cost just by observing that senders should never use l=,
and that doing so will likely cause security issues, but that seems to
sidestep the point).
Signature h=. I can see why it's there for extensibility, but hard-
wiring it would remove complexity, with only some loss of flexibility
in use. The spec has a SHOULD list for this which would be suitable.
(Actually, this and key n= are the two cases where I think the
additional value *does* clearly outweigh the complexity, myself).
Signature q=. Does anyone believe that they'll see anything other than
q=dns/txt in a signature with v=1? Again, extensibility is good, but I
don't think there's a need for this, and should reality demonstrate
otherwise, that's what v=2 is for. Slash it out and you reduced
complexity a little further.
Signature t=. Anti-replay defense is nice, I guess, but this isn't
going to be that useful in providing such a thing, and it adds
complexity to the spec and so consumes mind space, even if a verifier
decides to ignore it.
Signature x=. Like t=, but more so. And even if one were considered
useful, why both?
Signature z=. I'm sure there are edge cases where it's useful, but are
they important enough to justify the complexity they add? Key g=. More
complexity that adds little to no value.
Key h=. Same issues as Signature a=.
Key k=. Same as Key h=.
Key s=. Extensibility is fine, but until we've got some use case (and
experience with the default value) leave it for v=2? Key t=y. I know
why it's there, but I'm not sure that it's justified.
Key t=s. All the same complexity vs value issues as Signature i=.
And if you, or anyone else reading this, had to think for even a
moment about what any of those fields were, that goes some way towards
demonstrating my point.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html