[ietf-dkim] New Issues: bunch of nits for base

[Stephen Farrell]

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.