Subject: RE: concerns with TCR as a transition mechanism

From: "Loomis, Rip" <[email-masked]>
Date: Tue, 22 Jun 2004 04:42:26 -0400

Hi Ed--
Trying to reply only to one part of a much more significant
message:

> I suppose that with tools we can make serving both (all) dialects 
> possible - I don't want to have to manage a second set of keys for 
> the new dialect.  (Will reusing key material be a crypto-problem?)

Re-using key material will not inherently be a "crypto-problem"--
given that the plaintext to be signed will be slightly different,
the problem is that the crypto "lifetime" of the key will decrease
at something approximating half the "lifetime" (effectivity period)
that would otherwise be expected [0]--all of a sudden one is signing
(basically) twice as much data so by certain attacks the key would
be expected to be attackable in ~half the time.  However, that
would be expected to be a surmountable problem.

I agree with you that if -bis and -ter are both actively used in
the field simultaneously (which I would expect) then for a maximally
compliant system I would prefer to use the same keying material
for signed DNS in both systems.  I think it's a realistic goal,
although I invite comments in case I missed the bus on something...

  --Rip

[0] Based on all I know of currently published cryptanalysis attacks
on the algorithms in question.  If someone's got more data, please
provide it.  Yes, there may be some interesting differential
cryptanalysis attacks possible based on the fact that the two sets
of plaintext will be _real_real_ similar with only very slight
differences--but for now I'm throwing those out because I don't
think they will be significantly more productive than the "joe
average" attacks against a known plaintext for these algorithms.

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

---

From: Greg Hudson <[email-masked]>
Date: Tue, 22 Jun 2004 10:14:18 -0400

On Tue, 2004-06-22 at 04:42, Loomis, Rip wrote:
> be expected to be attackable in ~half the time.

The idea that one would want to rotate keys twice as often because I'm
signing twice as much data is pretty misguided, I think.  It only
matters if the signing algorithm you're using is broken in a particular
way, such that the key is more likely to be discovered through a
known-plaintext attack than through the usual forms of
leakage--compromised hosts, compromised people, or sloppy key
management.

To borrow from Shneier, by deploying DNSSEC, you've built up some
earthworks (key management) and then driven a single giant stake into
the ground (the cryptosystem) somewhere in the middle.  The security of
your system does not depend on the height of the giant stake.

Note that a signing algorithm is particularly interested in defending
against known-plaintext attacks, since the attacker generally has no
shortage of plaintexts to work with.  A cipher which is subject to a
known-plaintext attack is at somewhat less risk, since the attacker may
or may not have access to any plaintexts, but a cipher is still
considered broken if there is a known-plaintext attack against it with a
practical number of plaintexts.  The situation gets fuzzier when you get
into chosen-plaintext and chosen-ciphertext attacks, which is why NO
records start to get a little bit worrisome.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 23 Jun 2004 10:22:55 +0100

> records start to get a little bit worrisome.

Except that you aren't really choosing the plaintext, since it is hashed 
before signing.

Not that I see why NO records are any more chosen than any other record 
type.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff