On Mar 6 2012, Paul Wouters wrote:

See part of the dicsussion Miek and I had at the golang group:

http://code.google.com/p/go/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Status%20Stars%20Priority%20Owner%20Reporter%20Summary&groupby=&sort=&id=3161

The bug seems to be that dnssec-keygen upgraded the fermat prime that
is used per default from F0 to F4, but did not change that "-e" would
get you the next fermat number.

This is wrong (although I have seen the same thing stated in a number
of other places). When the default public exponent was changed from
3 to 2^16+1 (change 2088) the one selected by -e was changed from
2^16+1 to 2^30+3 ... *not* 2^32+1. And so it remains today.

As it happens, 2^30+3 is prime while of course 2^32+1 is not, although
that isn't really an issue.

I believe that the DNSKEY records (e.g. in a few TLDs) that do use
2^32+1 as the public exponent come from HSMs, not from dnssec-keygen.

In any case, there is no "bug" involved in any of this, other than
in validating code that cannot cope with large exponents.

                              The result is that people who upgrade
bind and don't notice this changed behaviour are not changing their
scripts that explicitely use "-e".

I would recommend that dnssec-keygen starts ignoring the "-e" parameter
that everyone has put in their scripts to prevent exponent 3 keys, who
are not getting keys with exponent 4294967296 + 1 (F5)

Alternatively, if this is done on purpose, I guess we should all
migrate the 64 bit machines :)

You can detect these starts, as they start with BQE

And you will find that the ones generated by "dnssec-keygen -e" start
BEAAAA...

My personal opinion is that we should stop worrying about people
using buggy pre-2006 versions of OpenSSL and go back to using RSA
public exponents of 3 again most of the time. I notice that this
is what VeriSign do for the DNSKEY records in "com", "net" & "edu".

--
Chris Thompson
Email: c...@cam.ac.uk
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to