Subject: Re: DNSSECbis Q-2: degradation attack

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Aug 2003 18:00:00 +0000

>     I am not yet convinced this needs fixing now; pointing to this
>     issue in the protocol doc security section may be sufficient. What
>     do others think?

i think that if we're not going to specify an alg rollover process, or
the interaction when parents/children/resolvers only share a subset of
algs, then we should remove the algid field and just laminate RSA for
all time and assume that we will change port numbers if RSA is cracked.

to that end, i would be an objector during WGLC if this isn't resolved.

--
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: Mike StJohns <[email-masked]>
Date: Tue, 19 Aug 2003 13:54:44 -0400

At 14:00 8/18/2003, Paul Vixie wrote:
>algs,

Actually, at a minimum, the interaction should be specified.  That's a 
protocol question. What probably can't be mandated is the actual contents 
of the zone.  I *think* the current language in describing the resolution 
process actually does the right thing - but it would probably be better to 
explicitly address the issues Sam raised?

Add a section 4.3 to draft-ietf-dnsext-dnssec-protocol describing the case 
where you have a broken chain due to the inability to verify because you 
don't understand a particular algorithm.

The more I think about this, the less I'm inclined to believe its going to 
be a real problem given the current mechanisms.

The resolver either understands or doesn't understand an algorithm
If it understands it, it either trusts it or rejects it. (rejects it 
because its considered broken for ex)
If it trusts it, it will follow a chain signed by it, otherwise it won't.

the resolver may also impose certain minimums on things like key length to 
determine trust/reject?

>then we should remove the algid field and just laminate RSA for