Hi Eric,
Eric Allman wrote:
That's a lot of nits.
Only because the document's worth reading closely!
Deleted bits where there's nothing to say other than "ok".
Other than the new text resolving 1193, which should have a
thread of its own, none of these need hold up issuing base-01.
#1 Overview is still somewhat sales-ish. A bit more objectivity
would arguably be more appropriate. E.g. "requires minimal new
infrastructure" would be better stated as "reqiures no extensive
new infrastructure", "transparent to..." is also a bit inaccurate,
since there are some cases where DKIM is not transparent, e.g. some
mailing list cases.
I guess I disagree with you on this one --- I think you're being a bit
over-sensitive. What's the difference between "minimal" and "no
extensive"? From a "sales-ish" point of view they seem equivalent to
me. I did change the "transparency" comment to "is compatible with the
existing email infrastructure and transparent to the fullest extent
possible" though.
It is a totally subjective thing so I'm fine with the above.
#5 section 3.3.3: "keys smaller than... are subject to brute
force.." The fact is that every algorithm is subject to brute
force. Whether or not factoring is considered brute force is also
perhaps debatable. I suggest replacing with something like "using
keys with a modulus shorter than 1024 bits may be considered unwise"
I've changed this to read:
<t>Selecting appropriate key sizes is a trade-off between
cost, performance and risk. Since short RSA keys more easily
succumb to off-line attacks, signers MUST use RSA keys of at
least 1024 bits for long-lived keys. Verifiers MUST be able
to validate signatures with keys ranging from 512 bits to
2048 bits, and they MAY be able to validate signatures with
larger keys. Security policies may use the length of the
signing key as one metric for determining whether a signature
is acceptable.</t>
<t>Factors that should influence the key size choice include:
<list
style="symbols">
<t>The practical constraint that a 2048 bit key is the
largest key that fits within a 512 byte DNS UDP response
packet</t>
<t>The security constraint that keys smaller than 1024 bits
are subject to brute force attacks.</t>
I'll shut up about it, but you *will* get comments that factoring
is not "brute force" which is a "technical term", in this case I
guess meaning trying all possible values for the decryption exponent.
<t>Larger keys impose higher CPU costs to verify and sign
email</t>
<t>Keys can be replaced on a regular basis, thus their
lifetime can be relatively short</t>
<t>The security goals of this specification are modest
compared to typical goals of public-key systems</t>
</list>
</t>
I suspect that this section will generate some more suggested
re-wordings - maybe it'd be good to pass it by some crypto type,
just to catch crypto-buzzword nits, e.g. some of the above is
specific to RSA, some isn't, and the text isn't always exactly
right in how it expresses that, e.g. s/2048 bit key/2048 bit
RSA modulus/ Again though I wouldn't hold up the document to
fix it - can be done later.
#13 section 3.7 would be better off talking about the signature
input bytes rather than hash calculations which will often happen
inside some signature API. (This might change if the existing issue
about separate body and header hashes gets accepted.)
I didn't understand this point.
I think its the same point as EKR made that this document shouldn't
be a tutorial on how signature calculations work.
> In any case, the separate hashes has
been accepted. The whole section now reads:
That, I think, is not a nit-fix and deserves a thread of its
own - any chance you could start that? (Without angle brackets:-)
#16 (like #13 above) section 6.3, last bullet: "Compare the
decrypted signature to the message hash..." is wrong. PKCS#1 (and
later) signature schemes require more, in the case of pkcs#1v1.5
there should be an algorithm OID in the recovered plaintext as
well. As before, suggest rephrasing this in terms of calculating
the bytes input to a signature verification API.
I don't understand this one either.
Same as EKR's above point again - don't go into details about how
the crypto works, that's specified elsewhere (which ought be
referenced if it's not now) and a description here will inevitably
be inaccurate or incomplete in some way.
Cheers,
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html