Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt

[Martin Thomson <[e-mail]>]

On 10 June 2017 at 19:33, Scott Kitterman <[e-mail]> wrote:
> This is pretty much what we had in -01 and this approach was suggested
> instead.  In XML, sorry, here's the diff:
>
> https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/commit/b3956a026c18b88ac2f47f8a012610598149e286

That's not quite what I was suggesting. I have sent you a PR for what
I think you should say:

https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/pull/1

I think that I got the essence of your changes there.  And it's a lot shorter.

Another issue I encountered when doing this:

         The defining documents specify a single signing algorithm,
<xref target="RFC8017">RSA</xref>
,
        and recommends key sizes of 1024 to 2048 bits (but require
verification of 512 bit keys).
        As discussed in <xref target="VULNOTE">US-CERT
VU#268267</xref>, the operational
        community has recognized that shorter keys compromise the
effectiveness of DKIM.
        While 1024 bit signatures are common, stronger signatures are
not.  Widely used DNS
        configuration software places a practical limit on key sizes,
because the software only
        handles a single 256 octet string in a TXT record, and RSA
keys longer than 1024 bits don't
        fit in 256 octets.

Aside from the extra space after the first xref, there are two
problems with this paragraph.

First, this document doesn't change anything about the recommendations
regarding key sizes.  That makes the whole paragraph a little
misleading.  You give the impression that you are doing something
about key sizes, but then you don't.

Second, you can fit a key larger than 1024 bits in less than 256
octets.  A 1536-bit key isn't that great, but it's a huge amount
better than 1024.  I haven't done the math, but I'm sure that you
could find a number that maximizes key length without blowing the 256
octet limit.  This might be good advice to add (which would also mean
that you can keep the paragraph).