the information economics of this draft are all wrong. with all possible respect for the comcast team who is actually validating signatures for 18 million subscribers and is therefore way ahead of the rest of the industry and is encountering the problems of pioneers... this is not supposed to be comcast's problem.
if someone that comcast's customers want to reach, blows their dnssec out by using the wrong keys or using expired signatures or whatever, then the problem ownership should rest with whosoever blows their dnssec -- not with comcast. it's only because comcast is first that comcast has to watch out for the deleterious effects of OPM (other people's mistakes) on comcast's own customers. comcast can't afford the help desk call volume that would come from another wrong-key failure at the social security administration's domain. but that doesn't make it comcast's problem. it would remain the social security administration's problem. we need to move quickly to the point where lots of large eyeball-facing network operators are validating, such that any failure to properly maintain signatures and keys and DS records, is felt most severely by whomever's domain is thus rendered unreachable. if everyone interested in working on this draft would take the time to turn on validation, then we could avoid inverting the information economics here. people who can't manage their keys and signatures properly (and i include my own vanity zones in that, since i'm not yet converted to the bind 9.9 way of doing things) should either expect trouble or uplevel their game or stay out of the game. i'm opposed to negative trust anchors, both for their security implications if there were secure applications in existence, and for their information economics implications. paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
