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
