spinning thread

[Bill Manning <bmanning@isi.edu>]

This is a summary of the thread that I promulgated last month on this list.
Its not ID-worthy, but its useful (to me) to have the thoughts in one place.
	----------------------
        experimenting with DS keys of various lengths shows that
        when keys are over a certain size, UDP fragmentation sets
        in.  In some cases, it is possible to actually get rollover
        to TCP (although this seems to be a corner case)

        now I've been told that UDP fragmentation can be a bad thing,
        leading to all sorts (well some kinds anyway) of odd
        operational failures that are hard to debug.  UDP failure
        and rolling over to TCP is also considered a bad thing.

        so this question, "should key lengths be selected to
        avoid fragmentation/TCP use?"

        if so, why?
        if not, why not?

        testing was done using single keys.  RSA/SHA1 keys of 512 & 1024
        bits, which generated "reasonable" packets.  RSA/SHA1 keys of 4096
        bits, generated UDP fragmentation. Multiple keys will aggrevate the
        issue.

        Somewhat sidenote:  there has been some discussion that RSA keys
        over 2048 in length incurred a significant performance impact over
        smaller keys.  This performance impact hits the resolver though,
        "on the wire" usage wasn't mentioned.  Further testing is needed.


Thoughtful responses follow:

-  "no" I don't think operational issues should dictate key
   lengths, but huge keys don't necessarily mean more secure either :)

-  some IDS/firewalls toss UDP packets larger than 512 bytes. Maybe the
   right answer is to tune the EDNS packet size to avoid UDP
   fragmentation?  4096 is bigger than most MTUs, but 1280 probably isn't,
   and should be enough for most common responses.

- this is not just a server/resolver issue. if transit infrastructure is
  making assumptions on "viable" datagram sizes, we will have to make a
  tradeoff in recommended key lengths.
  In an ideal world, security reasons (whatever that means) may be the only
  vector for selecting length.  This being the "real" world, it may be that
  to be useful, one has to trade of between "enough" crypto-strength and the
  ability to deliver the key(s) to the intended target.)

- one experience is that keeping DNSSEC messages (plus overhead) below a
  MTU of 1500 can be sort of difficult and too restrictive besides.


- a general opinion is that the firewall or router that drops UDP fragments
  or large UDP packets is broken and will need to be upgraded/replaced.
  if clients behind such broken devices set their EDNS0 max buffer size to
  something that will fit in the MTU, everything should work.  There will
  probably be a lot of TCP DNS traffic, but it should work.


Acknowledgements:

        David Blacka  Scott Rose  Brian Wellington
        Mark Andrews  Ed Lewis  Joahn Ihren  Olaf M. Kolkman

--bill manning
-- 
--bill