We seem to have a fairly basic disconnect here. As far as I'm
concerned, an assessor has better things to worry about than the
internal details of the signature. ...
On the other hand, we definitely don't have enough information about
assessors to know what information they need. Saying that the SDID is
the only thing they can depend on getting from the verifier is too
constraining.
As I said, we have a fairly basic disconnect here. The whole point of
defining a standard is to constrain the interface so that multiple parties
can interoperate. Every time we leave something optional or vague, it's
going to cause implementation and operational headaches, as we've already
seen with the confusion about the semantics of i= and whether to give the
assessor i= or d= or both. The more tightly we can constrain the
interface, the better it's going to work.
If we say that assessors can look inside the signature at, e.g., what
headers are signed, we are condemning our users to endless haruspicy,
trying to guess what headers to sign or not to sign in order to make the
best impression based on what they guess the assessors want. Allowing
assessors to use whatever bits they want and assuming we'll sort out later
what we think they mostly do is a recipe for chaos.
We really need to reset our vision from the blacklist model to whitelist.
With blacklists, there's no fundamental difference between the behavior of
bad guys and good guys, we're forced to use complicated ever expanding
heuristics to try to tell the difference, and we constantly have to change
them as bad guys adapt whatever behavior we attribute to good guys. But
with a whitelist model, you say here's what a good guy does, you design it
in a way that bad guys can't fake, and you're done. If it's properly
designed, it doesn't have to change every time there's a slightly
different attack, and the simpler it is, the less likely actual good guys
are to screw it up. Hence simple, constrained interfaces.
The "worthless signature" may not have been so worthless if one of the
header fields in question wasn't present at the time of signing, ... Are
you suggesting that whether that header field is signed or not is
irrelevant to the assessor?
That's an interesting question, with a multipart answer. One part is that
in retrospect, Jon's suggestion is not a great design, and if Doug or
anyone wants to add extra stuff to a DKIM signature that is intended to be
passed to the assessor, it'd be a lot better to invent an extra field or
two, add it to the existing signature, and specifically say that field is
passed along with the d= to the assessor. This both avoids the question
of was it there originally, and also avoids having to match up multiple
signatures with possible multiple extra info headers.
I have my doubts about the utility of any added output, since I don't
believe there's anything a sender can say that will inherently increase
its merit to receivers. The best you can do is to put in hints of where
they might find favorable info from credible sources. Hence the assessor
uses the d= to look in some local database and see what it thinks of the
domain. It's also the way we designed VBR -- it doesn't matter whether
the VBR-Info header is signed, because the recipient isn't going to
believe anything it says without checking first.
I'm certainly not opposed to doing experiments, and if we find that it
will be useful, a possible future DKIM++ that would explicitly export more
data to the assessor. But let's not have a freeforall now.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html