[ietf-dkim] editorials and nits

[Eric Allman]

--On July 4, 2006 10:40:38 AM +0100 Stephen Farrell >>> #1 saying 
"proof" and "non-repudiation" in the abstract is a
>>> mistake and potentially misleading. Rephase to use less difficult
>>> terms, e.g.  talk about signatures being evidence rather than
>>> proof.
>>
>> Given the sensitivity over the exact wording of the abstract, I'm
>> not  willing to make this change without discussion of some
>> proposed wording.
>
> Ok, I'll back off on this. DKIM isn't the only document that
> includes
> such phrases (but if you could even just not say "non-repudiation"
> that'd be great).

Personally I have no problem with making a modification, but given 
the sensitivity of this wording I don't feel I can just come up with 
it myself.  Perhaps we should have this as a (hopefully short) agenda 
item in Montreal.

> ...
>
>>> #3 1.1, 2nd set of bullets. dkim *does* require a ttp - the DNS.
>>> Better to say that dkim requires no *new* ttp.
>>
>> I don't see DNS as a "third party" in the same sense as a CA for
>> certs.   Yes, DNS has to work, but it isn't a third party (unless
>> you want to  count the root servers, I suppose).  By this logic,
>> we should also  include the multiple third parties that run the
>> routers and all the rest  of the infrastructure.
>
> In my little PKI-riddled mind, the DNS is a TTP since it supplies
> the public keys and if/when DNSSEC were used, it starts to look
> quite like a PKI. The routers etc. won't ever really be supplying
> signed key records. But if no-one else thinks the same, leaving
> as-is if of course right.

I think of TTP as an administrative entity, not as a piece of 
software.  If I have a key service controlled by the owner of that 
key, then I don't have a third party at all, even if there is another 
piece of software involved.

As soon as the key data is in the hands of a third party then the 
situation changes.  I guess that implies that if I outsource my DNS 
then there in fact is a TTP.  But I can outsource my mail system 
today and people don't seem to deem that to be a TTP situation even 
if it really is once you peek under the hood.  But outsourcing isn't 
a requirement for DKIM, even if someone might choose to implement it 
that way.

Hmm...  given the amount of heat this has generated, the best thing 
is probably to say "does not require any additional TTPs" and leave 
it at that.

>>> #5 3.3.1 and 3.3.1, phraseology is still a bit odd. Suggest
>>> changing from: "That hash is then signed by the signer using the
>>> RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]; in
>>> particular see section 5.2) with an exponent of 65537 as the
>>> crypt-alg and the signer's private key.  The hash MUST NOT be
>>> truncated or converted into any form other than the native binary
>>> form before being signed." ...to... "The signature is calculated
>>> using the RSA algorithm with a fixed public exponent of 65537 - if
>>> a different public exponent is required, then a new DKIM signing
>>> algorithm must be defined."
>>
>> Adding the specific reference was specifically requested by
>> another  reviewer --- in fact, I think your proposal changes it
>> back to almost  exactly what was objected to before.  I think this
>> requires some  discussion.
>
> Sorry - you're right about the reference, I just forgot to include
> it, you could change text suggestion to: "The signature is
> calculated using the RSA signature algorithm as specified in PKCS#1
> version 1.5 [RFC3447], and with a fixed public exponent of 65537 -
> if a different public exponent is required, then a new DKIM signing
> algorithm tag value must be defined."

I made the change as you suggest --- but this left me wondering: when 
you use openssl "genrsa", does that produce something that contains 
the exponent or not?  If it does, then we shouldn't be mentioning 
65537 at all.  If that is implied, then we should.  [IIRC I got this 
wording from Jon --- perhaps he can add something.]

> ...
>
>>> #19, 3.7. This talks about two hashes all the time, which is
>>> correct, but a bit misleading since any sensible API will include
>>> both hashing and private key application inside a "sign()"
>>> function. The end result is that the dkim programmer calls
>>> "hash()" once and either "sign()" or "verify()" once. Suggest
>>> adding a sentence along these lines to clear that up. If someone
>>> ever calculated "sign(hash())" then they'd be wrong and this text
>>> sort of suggests that. Similar comment about the pseudo-code at
>>> the end where I'd rather see something like:
>>>
>>>        body-hash = hash( canon_body )
>>>        signature = sign( canon_header || DKIM-SIG )
>>
>> I disagree.  This section has nothing to do with what an API would
>> look  like, it's about what algorithms have to be applied and
>> when. For  example, I can easily see your change being interpreted
>> to mean that you  don't hash the header at all.
>
> Fair enough. Its hard to get right either way. But can we add an
> informative note somewhere like:
>
>     INFORMATIVE NOTE: Many digital signature APIs provide both
> hashing
>     and application of the RSA private key using a single "sign()"
>     primitive. When using such an API the DKIM signature calculation
>     pseudo-code might look more like:
>           body-hash = hash( canon_body )
>           signature = sign( canon_header || DKIM-SIG )
>     Were an implementer to mistakenly include a second "hash()"
> call,
>     i.e.,
>           signature = sign( hash (canon_header || DKIM-SIG ) )
>     they would sign and verify their own messages with no apparent
>     problems, but could not interoperate with correct
> implementations.

I added:

        INFORMATIVE NOTE:  Many digital signature APIs provide both
        hashing and application of the RSA private key using a single
        "sign()" primitive.  When using such an API the last two
        steps in the algorithm would probably be combined into a
        single call that would perform both the hash-alg and the
        sign-alg.

>>> #22, 5.2, last para. Change "when the selector containing the
>>> corresponding public key is expected to be removed before the
>>> verifier...", to, "when the public key in the relevant selector is
>>> expected to be revoked before the verifier..." since we're not
>>> recommending removing the selector but rather zeroing out the key.
>>
>> Is that what we are recommending?  I thought that omitting the key
>> was a  way of saying "we're sorry, but we had to pull that key
>> unexpectedly."   In fact, the usual way of dropping a key would be
>> to drop the record  entirely.  Otherwise you would have
>> ever-growing name spaces.
>
> I guess I'm confused then. I thought that including a blank key
> value was better since it could be cached. I would assume that
> you then typically delete the selector record after a while, when
> you no longer see many requests for it or whatever.

I guess we're not completely clear on that either way.  I changed it 
to "revoked or removed" to cover all the bases.

>>> #28, 6.2. The reference to ID-AUTH-RES might be better off being
>>> removed for process reasons.
>>
>> Even as an example?  It's informational, not normative.
>
> I appreciate that, but I bet it'd still slow down base's road
> to rfc-dom.

OK, I pulled it.

>>> #32, A.3, the authentication results header should not, IMO be
>>> included here.
>>
>> I think it is very important to make it clear how one might convey
>> results to higher levels.  Otherwise all of A.3 doesn't have any
>> reasonable example.  It doesn't have to be Authentication-Results,
>> just  something.
>
> An abstract something here is better than a nearly-well-defined
> something IMO. (I mean no criticism of ID-AUTH-RES here either, but
> it may change in all sorts of ways, including the name of the header
> field.)

OK, I used an abstract model.  It happens to be the same as the 
Auth-Res draft using X-Authentication-Results instead of 
Authentication-Results, but honest, it's just something I pulled out 
of thin air.

Seriously, I think it is good to show the kind of information you 
should plan on conveying.  I could reorder or shuffle the syntax a 
bit, but that adds nothing and might imply to someone who implements 
from examples that there is some other formal form they should be 
using.

>>> #33, Appendix B. I expected to see a bit here about the type of
>>> setup we have at IETF meetings, where the IETF's MTA signs and the
>>> verifier has to handle the From being nothing like the signer
>>> identity.
>>
>> Sorry, I don't see any signatures coming from the IETF MTA.  Can
>> you be  more specific?
>
> If I go to a conference or IETF, then I generally use its smtp
> server. If someone was used to mail from me being signed by tcd.ie
> and suddenly see mail from me signed by ietf66.org they might react
> badly. I don't want that to happen. (I know that the IETF meeting
> server doesn't sign now, but I guess it may in future.)
>
> So, my point was that I didn't see an example/use-case that mapped
> to the one above.

Well, depending on how you look at it, B.6 (Third-party Message 
Transmission) might cover it.  Alternatively, we could add a B.7 that 
explicitly discusses the "hotel room" problem.  The two are very 
close but not quite identical.

Any thoughts?

>>> #34, Appendix C. I think that this can be deleted. Others may
>>> disagree. In any case, the text says 768 and the command line
>>> 1024, no  password handling is shown and the last part could
>>> confuse since that signature is not usable for DKIM. So if this
>>> isn't deleted, then a bunch of changes are needed.
>>
>> I fixed the discrepancy, but I don't think it should be deleted.
>> It's  non-normative and will help people understand how to use the
>> standard,  which I think is A Good Thing.
>>
>> I'm not sure what you mean about password handling.  I just ran
>> through  these instructions, and there are no passwords requested.
>
> Sure, you don't have to use passwords with s/w private keys, but you
> really should do at least that much.
>
> If we're going to give this kind of help, we don't want it to
> encourage people to take less secure options without being clear
> that that's what they're doing.

So are you saying that the genrsa step should be using -passin?  I 
can see that as an optional step that we could discuss, but it's not 
strictly required for the algorithm to work.

> ...
>
>>> #6 3.6.1 "k=" says that the public key is in the "p=" value, but
>>> its actually the modulus.
>>
>> I guess I'm confused.  If this isn't the public key, what is?
>
> Me being pedantic again I guess. The public key is the modulus and
> the public exponent (in our case hardcoded to be 65537).

See my question above about the exponent.

eric