Re: Q2: crypto algorithm requirements for DNSSEC

[Rob Austein <sra+namedroppers@hactrn.net>]

At Wed, 12 Feb 2003 14:20:08 -0500, Rip Loomis wrote:
> 
> Yep.  I haven't in years, but I used to do stuff in assembler for
> 68HC11s and such.  I guess I was hoping that memory was now "cheap"
> everywhere--not that that would really be sufficient justification to
> bloat DNS code with non-useful algorithms.  But read on...

The way it seems to work out is that, as soon as resources become
cheap enough that the current generation of widgets are no longer
resource constrained, a new generation of even cheaper widgets
redefines the meaning of "low end".  As far as I can tell, there will
always be people willing to sweat blood to try to make a go of
marketing some cool new product with profit margins that can only be
detected using an electron microscope.

> OK.  I agree with a previous characterization that if RSA gets
> broken suddenly/cataclysmically, then DNS won't even be *close* to
> the low-hanging fruit on the vulnerability tree.  I can't come up
> with a convincing enough reason, at that point, why DSA is "useful
> enough" to keep as a MUST IMPLEMENT--as long as we believe that letting
> embedded devices drive DNSSEC choices is a Good Idea.

That's fair, but read on :).

> Whether letting embedded devices drive DNSSEC choices really *is* a
> Good Idea I leave to someone with a better big picture of such things.
> From my perspective, the idea that *any* embedded device is actually
> expected to implement a security-aware resolver that can do its own
> signature verification is ludicrous.  It seems more likely to me
> that such a device would implement IPSec to some trusted "mothership"
> which could provide DNSSEC resolution, or that such a device would
> blow off DNSSEC entirely, than that such a device would actually make
> use of SIG and KEY records.

In the long run, I think it's reasonable to expect that small and
highly mobile devices will end up needing to perform their own
verification, precisely because they are mobile and may frequently
find themselves in environments where they have no usable trust
relationship with the local infrastructure.  Tunneling across an
untrusted infrastructure to get back to a home base is another
approach, but it's kinda fragile.

> So my counter-question, after thinking more about this, is:
> Does anyone *really* think that embedded devices should drive the choices
> made in writing DNSSEC specifications?  Note that the answer to that
> question has implications far beyond this single issue.

Drive the choices?  No.  Be considered along with everything else when
making the choices?  Yes.   As I tried to say earlier, give me a
convincing argument that keeping DSA madatory would make the world a
better place and I'll shut up about this.  But, other things being
equal, please don't gratuitously drive up the cost of my toaster :).

> Even if we don't make the choice based solely on embedded devices,
> the argument that "if we have DSA implemented already then we can
> recover a signed tree faster" sounds less and less useful to me.
> As a result I find myself somewhere squarely in the "undecided" category
> overall--so I'll hush now.

Fair enough.  I'll shut up now too unless somebody else wants me to
blather on about it.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>