Hi Duane, On 31 Oct 2018, at 19:03, Wessels, Duane <dwess...@verisign.com> wrote:
>> Section 1.2 >> >> I don't understand the benefits of suggesting that verification of a zone >> digest "would be implemented in name server software". The inference is that >> software that normally concerns itself with responding to queries should be >> extended to check zone digests, which seems unnecessary and contentious; in >> general it's not the libraries or executables in which the software live >> that is important but rather that there be a trusted relationship between >> the verification process and the software that consumes the validated zone >> data. I think the final paragraph could just be removed. > > The thinking here is that its best to have the verification part as close to > the serving part as possible. If there is agreement that this text is an > unnecessary distraction, then it would be okay to remove it. It doesn't > affect the protocol itself. There is understandable sensitivity to the idea that new protocol development work makes diversity of implementation of nameserver software more expensive, since the list of specifications to support gets ever longer. I think there's value in emphasising that this protocol is optional by avoiding any inference that modifications to nameservers are required to use it. While that's certainly an option, it's an implementation decision, not a requirement. >> I think supporting multiple ZONEMD records per zone using different digest >> types might be useful if it was specified in such a way that it ensured that >> consumers of the ZONEMD RRSet should not fall back to other digest types if >> their preferred type did not work. I understand the concern about downgrade >> attacks in general, but in this case if the ZONEMD RRSet is signed, a >> downgrade attack would require the ability to replace the covering RRSIG, >> and if you can do that you don't need to force a downgrade, you can just >> replace the ZONEMD RRs' RDATA with your own and re-sign illicitly. > > I think you might be the first person to argue for supporting multiple ZONEMD > algorithms per zone. I actually expected more. > > What you're saying is that a recipient would have a list of supported > algorithms, ordered by its own preference. It finds the most-preferred > ZONEMD RR, and uses only that one for verification, ignoring all others. > Correct? That seems reasonable, although I'm not convinced I fully understand the restriction on checking only one. Seems to me that could also be left to local policy, along with the interpretation of the case where some subset of ZONEMD RRs in a set fail verification. >> Section 2.2 >> >> You don't specify the representation of unsigned decimal integers clearly >> enough for me to know whether leading zeros are tolerated or preferred. > > I emulated RFC 4034 here. I guess I'm not aware of any decimal presentation > fields that prefer leading zeroes. How would you like to see it specified? If it's good enough for 4034 then I guess it's good enough for this draft. I just always find it imprecise to specify that a value should be presented (or provided) as a decimal integer without confirming whether 123 0123 000123 and 1.23E2 are equivalently acceptable. >> Section 3.1.2 >> >> I think that in the specific case mentioned the two SOA RRs are expected to >> be identical. I wonder whether it's worth generalising the advice to confirm >> that where there are multiple identical instances of RRs within a single >> RRSet (same owner name, RRType, RDATA, class, TTL) only one is included in >> the calculation of the zone digest? > > It sounds wrong to me to say that identical instances of RRs would not be > allowed in a zone. It's true though, right? It's not meaningful to include more than one resource record with the same (owner,type, class, TTL, RDATA) in the same RRSet, and hence also not meaningful to include such duplicates in a single zone (which is a particular set of RRSets). I don't think RFC 1034 is explicit about this, but it's surely implied. I don't know of any nameserver software that would allow duplicates like that, though, with the possible exception of the SOA. Quite possibly I have just typed more nonsense about this than the world ever needed to see. >> Perhaps SOA is the only example of this. For the precise reasons given, >> calling SOA out as a well-known example would make sense even if the >> specification was generalised as suggested above. > > Mukund informed me that repeated SOAs are likely less common than I believed, > and probably due to > thinking in terms of "zone files" rather than zones. Perhaps the bullet > about multiple SOAs should > just be removed. Repeated SOAs are specified in RFC 5936 section 2.2; even if a retrieved zone never touches a disk the AXFR response is still bracketed by identical SOA RRs. I think it's reasonable to consider that framing though and not the presence of a duplicate RR in a zone structure. >> Section 3.3 >> >> I don't see the point of ZONEMD in the absence of DNSSEC. This section to me >> suggests that there might be a point to it. I don't know what that might be. > > The only point would be so that you could discover accidental zone > corruption, rather than intentional fiddling. Oh, true. That might be worth spelling out. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
