[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: scottr@antd.nist.gov (Scott Rose)
Cc: bmanning@isi.edu, dnssec@cafax.se
From: Bill Manning <bmanning@isi.edu>
Date: Tue, 17 Sep 2002 11:14:03 -0700 (PDT)
In-Reply-To: <01d101c25e72$76c1f2e0$b9370681@BARNACLE> from Scott Rose at "Sep 17, 2 01:48:42 pm"
Sender: owner-dnssec@cafax.se
Subject: Re: key length & fragmentation

% Personally, I think key lengths should be chosen for security reasons, not
% DNS server implementation reasons.  However, since any DNSSEC aware
% resolver/server should also be EDNS aware, so truncation/fragmentation will
% be a worry when big keysets are in the picture (multiple algorithms, etc).

	Except it might be an issue earlier than some people think.
	(I think that in an ideal world, security reasons (whatever
	that means) may be the only vector for selecting length.  This
	being the "real" world, I think 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.)

% In the tests - what were the average size of the KEY RRsets?

	single keys.  RSA/SHA1 - 512 & 1024, which generated
	"reasonable" packets.  RSA/SHA1 - 4096 bits, which generated
	UDP fragmentation.

	multiple keys do aggrevate the problem. And this is not a question
	wrt server/resolver implementation, its more focused on the
	impact UDP fragmentation has on infrastructure things, like IDS
	systems/firewalls that are sensitive to those types of things
	as "attack" vectors.

% OTOH, I don't see why having a shorter key (that may have to be rolled over
% more often) is less secure than a longer key.  The operational lifetime of a
% key can be measured by how much data is has to sign and how often it resigns
% the zone data.  There are guidelines in some hardcore security policies from
% NSA/DoD - I can't name the off hand.

	then there is the whole "exposure" thing.  The more often one
	gets out the keys, the more likely it will be exposed to attack.
	Short keys that roll frequently vs. long keys that roll slowly.
	A mix of both methodologies looks like a good match.

	pointers to real guidelines would be appreciated.

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

	See the point above. If IDS/firewalls toss UDP fragments,
	we loose.

% 
% Scott
% ----- Original Message -----
% From: "Bill Manning" <bmanning@isi.edu>
% 
% 
% > resend from last week.
% >
% >
% >         putzing about with 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?
% >
% >
% > --
% > --bill
% 


-- 
--bill

Home | Date list | Subject list