Subject: [DNSOP] Proposed changes to RFC 4641: differentiation between trust anchors and keys with parent zones

From: Paul Hoffman <[email-masked]>
Date: Sun, 28 Sep 2008 21:14:38 -0700

In the last paragraph of 3.1.1, change:
    These
    can include the registry of the parent zone or administrators of
    verifying resolvers that have the particular key configured as secure
    entry points.
to:
    If there is a parent zone, these
    can include the registry of the parent zone or administrators of
    verifying resolvers that have the particular key configured as secure
    entry points. If this is a trust anchor, everyone relying on the trust
    anchor needs to roll over to the new key, which is a very big deal.

Remove all of 3.1.2. Longer keys are not useful because the crypto
guidance is that everyone should use keys that no one can break. Also,
it is impossible to judge which zones are more or less valuable to an
attacker. An attack can only be used if the compromise is unnoticed
and the attacker can act as an MITM in an unnoticed way. If .com is
compromised and the attacker forges answers for somebank.com and sends
them out as an MITM, when the attack is discovered it will be simple
to prove that .com has been compromised and the KSK will be rolled.
Defining a long-term successful attack is difficult for keys at any
level.

Remove the first phrase of the fourth paragraph of 3.3. At the end of
the paragraph, add:
    Note that if a trust anchor replacement is done incorrectly, the
    entire zone that the trust anchor covers will become bogus until
    the trust anchor is corrected.

Here's the biggie. Separate all of section 4 into two distinct
sections: zones publishing trust anchors, and zones publishing DS
records to a parent. Make each heading clear which one is being
discussed.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop