Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03

From: David Blacka <[email-masked]>
Date: Mon, 3 Nov 2003 13:36:48 -0500

On Tuesday 28 October 2003 08:11 pm, Mike StJohns wrote:

> 2.2 pg7, 4th para after bullets beginning "There MUST be..."  This 
> continues to feel like the tail wagging the dog.  The DS RR was added to 
> prevent the requirement for close consultation between parent and child 
and 
> this seems to have way too close coordination between parent and child.  
It 
> also seems strange to require every RRset in a zone to be signed by ALL 
> algorithms...

The reason why this paragraph doesn't make sense is that it is only half of 
a solution to a problem that was discussed on this list.  I will quote the 
paragraph here (protocol-03, section 2.2):

   There MUST be an RRSIG for each RRset generated using at least one
   DNSKEY of each algorithm in the parent zone's DS RRset and each
   additional algorithm, if any, in the apex DNSKEY RRset.  The apex
   DNSKEY RRset itself MUST be signed by each algorithm appearing in the
   DS RRset.

The purpose of this paragraph (I think) is to prevent a downgrade attack.  
However, it doesn't make any sense at the moment, because there is no 
language describing the downgrade that this rule would prevent.

Unless I'm totally misinterpreting things here, this is from Sam's 
suggestion about how to deal with unknown algorithms (or, alternately, how 
we might make it possible to one day move from RSA to some other 
algorithm).

The idea, as I understood it, was for resolver to treat zones (or answers) 
as valid but insecure if it was only signed by unknown algorithms.  
However, this language does not appear in protocol-03.  Actually, I 
couldn't find any direction on what to do with RRSIGs with unknown 
algorithms at all.

Personally, I feel that Sam's proposal on this matter is important and 
should be completely included.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

--
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: Samuel Weiler <[email-masked]>
Date: Tue, 4 Nov 2003 21:14:12 -0500 (EST)

On Wed, 29 Oct 2003, Mike StJohns wrote:

> ... that's the wrong answer I think.  If we don't mandate the set
> of algorithms the resolver has to implement, then its possible that the
> resolver won't be able to resolve  part of the tree if its signed by an
> algorithm the resolver doesn't understand.  Mandating how the tree is
> signed is the wrong answer - because we can't control what people
> do.  Mandating how the resolver works is the right answer.

It's not that the resolver won't be able to resolve that part of the
tree, it's just that that part of the tree will appear as insecure,
which is fine and dandy.  The alternative is to forbid zone owners
from ever experimenting with new algorithms.  Oops -- that's back to
imposing constraints on the zone owner.

You're partially right: we need to mandate client behavior when a zone
is signed with a non-understood algorithm and when a zone doesn't
follow the rules.  But we need the rules, too.

See Olaf's message on 24 September for pointers to the lengthy
discussion (Subject: DNSSECbis Q-2: degradation attack).  Note, in
particular, the safety property: properly signing a zone should not
cause the zone to be less resolvable.  This is the same premise that
drove the type code roll.

> We still have the problem where we add new algorithms, delete old ones and
> haven't updated the resolvers, but that seems to be a lot less problematic
> than the current language (e.g. its a "lesser included offense"  :-)

As should surprise no one who followed the discussion of the algorithm
rules, I disagree.  If we ignored this, it would be difficult if not
impossible to deploy new algorithms, and I would agree with Paul's
assessment (on 18 August) that we should just manadate RSA/SHA-1 and
give up on ever switching algorithms.  Remove all of the algorithm
fields, get rid of the IANA registries which have been plaguing the
TCR draft (even after IESG approval), and plow ahead with a single
algorithm for all time (or until RSA or SHA-1 is broken and we have to
work on DNSSECbisbis).