DKIM Crypto Update
charter-ietf-dcrup-02

[Ballot comment]
Editorial comments only:

1: Original:

DCRUP will consider four types of changes to DKIM: additional signing
algorithms such as those based on elliptic curves, changes to key
strength advice and requirements, deprecating the use of SHA1,
and new public key forms, such as
putting the public key in the signature and a hash of the key in the
DNS to bypass bugs in DNS provisioning software that prevent publishing
longer keys as DNS TXT records. 

This sentence is really long, and I got lost in it. It says that there are 4 changes, but the wording makes it hard to figure out which they are.

Proposed (semi-colons to separate from the "such as"). Or, perhaps make this bullets instead?:
DCRUP will consider four types of changes to DKIM: additional signing
algorithms such as those based on elliptic curves; changes to key
strength advice and requirements; deprecating the use of SHA1;
and new public key forms, such as
putting the public key in the signature and a hash of the key in the
DNS to bypass bugs in DNS provisioning software that prevent publishing
longer keys as DNS TXT records.



2: "It will limit itself to existing implemented algorithms and key forms."
The "it will limit itself" sounds odd in a charter;  I'd suggest "It will be limited to..." or something similar (otherwise it sounds like this is an internal decision)

[Ballot comment]
I'm fine with doing this, without external review.

I'm a Yes for this one, but Alexey needs to be a Yes before it's approved, of course. But definitely the right thing to do.

I did see

    DKIM also currently supports use of SHA1 coupled with RSA.  SHA1 has been
formally deprecated due to weakness especially when used in the context
transport security, though the risk of a successful preimage attack is
   
I may be unaware of a well-known term of art, but I'm guessing "context transport security" is missing "of" (so, "context of transport security")?   
   
less severe.  Still, the community wishes to discourage its continued use
in the DKIM context.

[Ballot comment]
Currently DKIM mailing list is not hosted on ietf.org. Should I request creation of a new one or keep using existing one where people already participate?

[Ballot comment]
Agreed with Spencer. I had to read this sentence multiple times.
"The only current algorithm is RSA,
with advice that signing keys should be between 1024 and 2048 bits. While
1024 bit signatures are common, longer signatures are not because bugs in
DNS provisioning software prevent publishing longer keys as DNS TXT records."

Please detail the milestones.

[Ballot comment]
I'm a Yes, although I'm not the responsible AD, because this is the right thing to do.

I wonder if you need to include this in the text:

"The only current algorithm is RSA,
with advice that signing keys should be between 1024 and 2048 bits. While
1024 bit signatures are common, longer signatures are not because bugs in
DNS provisioning software prevent publishing longer keys as DNS TXT records."

With a few re-reads, I can connect the dots between

RSA -> more algorithms
1024-2048 -> I'm guessing guidance for longer signing keys?
signature doesn't fit in a TXT record -> put it somewhere else

that matches the three work areas in the updated charter, but that took a few re-reads, and the updated charter is at least as clear to me without those two sentences :-)

At most, perhaps

OLD

"putting the public key in the signature and a hash of the key in the DNS"

NEW

"putting the public key in the signature and a hash of the key in the DNS to bypass bugs in DNS provisioning software that prevent publishing longer keys as DNS TXT records"

to explain why the charter includes this part (adding algorithms and updating guidance on key lengths doesn't require explanation).

But do the right thing, of course (and I am balloting YES even if you don't change anything).