On Sun, Sep 28, 2008 at 09:14:38PM -0700, Paul Hoffman wrote:
> 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.
when is a SEP not a TA?
> 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,
crypto guidance from whom? longer keys are useful for several
reasons.
> it is impossible to judge which zones are more or less valuable to an
value is in the eyes of the zoen admin, not a random hacker.
> 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.
manipulation of the TA/SEP nonces fundamentally changes the validators
view of trust.
one presumes that your assuming a single trust heirarchy and wiggling
one piece to give
a parallax view creates "bogus" data -from the perspective of one view
of a trust heirarchy-.
alternate trust heirarchies will emerge.
>
> 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 protected]
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
