On 7/19/17, 08:49, "DNSOP on behalf of Rose, Scott (Fed)" <dnsop-boun...@ietf.org on behalf of scott.r...@nist.gov> wrote:
>I think this draft is a good idea and should be adopted, but needs some >improvements first. > Thanks for the review, the current version has items needing wider discussion. I'll pick some items to respond to now: >2. REQ2: What should happen when there are multiple trust anchors, but only >one failed to validate? E.g. a validator has both the root and .exampleTLD in >its trust store, but missed the root rollover. The .exampleTLD key still >validates, but the root doesn't. Should all validation stop? Or set a warning, >but continue to validating (succeeding only for .exampleTLD)? One of my long-standing opinions has been that it is hard to build a secure chain, so if one exists, accept it in face of alternative broken chains. If a validator is too "tight" then it would be trivial to do a denial-of-service by throwing out DNSKEYs, RRSIGs, etc., that will not lead to validation. As far as trust anchors, the level of trust (healthiness in some sense) is individual. One anchor candidate might be "false" (unauthorized) while another anchor candidate might be "true" (authorized). Trust is in the eye-of-the-operator, if the operator establishes trust in a candidate it is best to run with it, again, even if there are untrusted candidates. (Because, if too "tight" it would be trivial to do a denial of service.) >3. REQ18: I don't think I understand this. Wouldn't the best way to see which >algorithm(s) are in use for a given zone would be just to send a query >Authoritative zones really may not "know" any algorithm besides SHA-1, as it >is likely not doing online signing, but serving whatever a signing utility >chose. I'd refrain from "know" and use "use." The signer (not the zone) may or may not have a library for a particular DNSSEC security algorithm's needed cryptographic algorithm and/or hash. That's entirely opaque to the other side of the DNS protocol (as DNSSEC assumed an air gap in the most strictly secure use case). What is in use for a zone is established two ways. One is from the DS RRset. The other is via published secure entry points bootstrapped to the satisfaction of the validator operator's "trust" satisfaction. I.e., I too think that REQ18 needs further review. It would make more sense if there were on-the-fly signing capabilities (which is not something assumed by DNSSEC, although it's not a ludicrous idea, it would be operationally useful). >4. Should there be a mention as to which algorithms a validator should >support? It may not require a direct reference to whichever RFC is current, >but simply listing the IANA maintained registry and say "implement all the >MUSTs and probably the SHOULDs too". Something like the following: For turn-key implementations, I don't think so. For general-purpose implementations, the producer of the software would make a choice based on their objectives. Easing the choice for the tool developer would be good, but I question mandating compliance with features. (I'd leave that to the "purchasing vehicle", which begs a whole'nuther discussion. There would be a need to educate the consumer, for one.) >Algorithm Usage in Validators > >DNSSEC signatures can be generated by different digital signatures algorithms. >The current list of algorithms defined for use with DNSSEC is published in an >IANA maintained registry [insert IANA link here]. Validators have to be able >to understand and validate different algorithms that may be in common use with >DNSSEC. The DNSSEC digital signature registry table is regularly updated with >guidance as to which algorithms are considered MANDATORY and/or RECOMMENDED. >In order to be effective, a validator MUST understand all digital signature >algorithms marked as MANDATORY and SHOULD understand all digital signature >algorithms marked as RECOMMENDED. > >REQXX: Validators MUST implement all MANDATORY digital signature algorithms >and SHOULD implement all RECOMMENDED digital signature algorithms. > >Note: This wording isn't the best, and needs some work. I also don't know if >the SHOULD in the REQ should be changed to a MAY, but I would prefer SHOULD. Thanks for the suggested text, for the most part I think it is on target. But to hark back to my comment before it, I'd change (for example): "Validators have to be able to understand and validate different algorithms that may be in common use with DNSSEC." to: "General purpose validators, in order to be widely adopted and accepted, ought to implement as many of the commonly used DNSSEC security algorithms, with "commonly" interpreted, at least on one way, to include the DNSSEC security algorithms in the IANA registry noted." ...again, wording is loose. My driving concern is that there may be some folks that have a turn-key situation in mind; the IETF famously says it is not the "protocol police."
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
