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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
