At 00:43 10/03/2009, Mark Andrews wrote:
In message <20090310041254.gb4...@vacation.karoshi.com.>,
bmann...@vacation.kar
oshi.com writes:
> On Tue, Mar 10, 2009 at 12:55:51PM +1100, Mark Andrews wrote:
> >
> > In message <f7c89744-a1ca-4fd6-b793-2f4e337e3...@verisign.com>,
David Black
> a wr
> > ites:
> > >
> > > On Mar 9, 2009, at 5:35 PM, Mark Andrews wrote:
> > > >
> > > > On a related issue DS -> DNSKEY translations cannot be
> > > > performed until the DNSKEY is published in the zone. The
> > > > use of DS prevents pre-publishing of keys.
> > >
> > > Huh? You can generate a DS from the DNSKEY record that you have
> > > generated but not yet published, so you can pre-publish the
DS just as
> > > soon as you could pre-publish your DNSKEY. As for actually *using*
> > > the DS as a trust anchor, you can't use either the DS or the DNSKEY
> > > prior to actually publishing and *using* the DNSKEY. Or maybe I just
> > > don't understand your point.
> >
> > When you pre-publish a DS you prevent implementations that
> > use DNSKEYs from taking advantage of that pre-publication.
>
> sounds like an implementation bugll
draft-ietf-dnsop-dnssec-trust-anchor is unfairly trying to
restrict what is can be used as a trust anchor. It is
retroactively changing the specification.
Before this draft there was NO specification what so ever on what trust
anchor configuration should look like.
The trusted-key statement in Bind-9 is OLDER than the DS definition.
One of the disadvantages of being an early adopter is that there frequently
is no guidance on the best way to do things.
draft-ietf-larson-dnsop-trust-anchor-00 was published over 2 years ago.
it was on the agenda of number of DNSOP meetings before begin adopted
14 months ago. This is the first time anyone has raised
an issue with DS being the recommended approach, section 2 has the
justification why DS is better than DNSKEY. Please explain where section
2 is wrong before asking for change in recommendation.
The draft is aiming for Informational status not standards track, thus
implementations are free to ignore the draft, or provide tools that
take a list of DS records and translate that into trusted-key block.
While DS was being defined some people wanted it to be a clone of the
DNSKEY record
but that approach was rejected. DS is based on PGP key finger prints and that
model has held up well in the real world for creating trust relationships.
A security-aware resolver MUST be capable of being configured with at
least one trusted public key or DS RR and SHOULD be capable of being
configured with multiple trusted public keys or DS RRs.
trust-anchor draft does not violate this, just recommends one approach over the
other and explains why that is better practice.
We must learn from history or the same mistakes will be made.
Olafur
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
