[dns-operations] (struct DNSSEC_DNSKEY_RR *) Exponent lengths

[Edward Lewis]

If you are into DNSSEC key/cryptographic minutia, otherwise skip:

    (This is thrown for discussion, if any, this is merely something that's caught my eye.)
    
    Long time ago, there was some concern over the exponents in use in DNSSEC keys.  (Ref: ImperialViolet.org's blog by Adam Langley, 16 Mar 2012, "RSA public exponent size", or https://www.imperialviolet.org/2012/03/16/rsae.html)
    
    As a result of that blogpost, some of my older DNSKEY resource record inspection code would document whether a key's exponent was small (exponent length=1), large (3) or obese (5), obese because it triggered the carry over error mentioned in the blog [via reference to Daniel Bleichenbacher].
    
    Over the ensuing years, I would run the code but never looked closely at the resulting analysis.  In the last week my attention returned to the code.  I noticed something interesting in a run looking at DNSKEY sets in gTLD zones:
    
    Exponent Sizes
          7 unknown-8 (i.e., 7 keys had an exponent length of 8 octets)
          8 unknown-4
         27 unknown-2
        379 small
       2598 obese
     486046 none
    2464864 large
    
    "none" = 486,046 keys have no exponent (elliptic curve), they shouldn't that is.
    
    The "unknown-$size" values caught my eye.  I asked for confirmation, this isn't a bug in my code.  There are keys with even-*sized* ({2,4,8}) exponents.  (NO, not even exponents, the length is.)
    
    I'm curious why these keys exist.  I mean - apparently they work (no one complains/notices) but oddballs in operations aren't tolerated well.  Harking back to when I developed the code, I found keys that were one bit shy of 1024 and one bit shy of 2048 in length.  Nonetheless they "worked", however, this one-off was confirmed to a bug in a commercial code base.)
    
    I could include the names of the keys, but I refrain from naming names...although here it is tempting.  There's one high-profile operator in the list, but I  haven't yet found a good contact for them.
    
    Trying to break this down, by DNSSEC security (and crypto) algorithm and then by role:
    
          2 DSA-SHA1-N SEP
          2 DSA-SHA1-N ZONE
          2 DSA-SHA1 SEP
          3 DSA-SHA1 ZONE
          3 RSA-SHA1 SEP
          3 RSA-SHA1 ZONE
          3 RSA-SHA512 ZONE
          4 RSA-SHA256 SEP
          4 RSA-SHA512 SEP
          6 RSA-SHA1-N SEP
         10 RSA-SHA256 ZONE
    
    Hmmm - well bets are off with DSA, but RSA?: SHA1, w/ w/o NSEC3, SHA256 and SHA512 (the whole gamut of RSA).
    
    And algorithm+size:
    
          1 DSA-SHA1 1614
          1 DSA-SHA1 3162
          1 DSA-SHA1 3165
          1 DSA-SHA1-N 2429
          1 DSA-SHA1-N 2430
          1 DSA-SHA1-N 3166
          1 DSA-SHA1-N 3168
          2 DSA-SHA1 3168
          3 RSA-SHA1 1024
          3 RSA-SHA1 2048
          3 RSA-SHA256 2048
          3 RSA-SHA512 2048
          4 RSA-SHA512 1024
          6 RSA-SHA1-N 2048
         11 RSA-SHA256 1024
    
    I bet there's some key generation software out there, in use by a few organizations, making these keys.  On the surface there's no operational issue, it's just that when I've ever found niche cases like this, there's something off-kilter.  Requests for the list of keys will be considered, in you are motivated to dig into this, this isn't a name and shame worthy thing.