[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DNSSECbis Q-2: degradation attack
At 14:00 8/18/2003, Paul Vixie wrote:
> 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,
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
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 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/>
--
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/>