Document: draft-ietf-drip-registries Title: DRIP Entity Tags in the Domain Name System Reviewer: Christian Huitema Review result: Ready I have reviewed draft-ietf-drip-registries-27 as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. The text below details how the draft was improved to address my concerns, and includes two optional suggestions. My security review of draft-26 mentioned that the draft was ready, except for 4 points that could be fixed: 1. Linking the HHIT to the key via a 64 bit Orchid hash does not provide enough security. When DNSSEC is not present, one must recommend a secure verification procedure. 2. The structure of the Canonical Registration Certificate in the HHIT RR is loosely specified as "encoded using X.509 DER". 3. There is a tension between "implementing DNSSEC" and "publishing the HHIT record just in time". If we rely on DNSSEC for security, it is more important to facilitate DNSSEC signature than to try hide the certificate using "just in time" publishing. 4. Some risk that manually writing CBOR decoding code for the HHIT and BRID RR Types could cause exploitable bugs. In draft-27, the first issue is largely fixed. The security considerations have been updated to make DNSSEC mandatory if the HHIT record contains a self-signed certificate; and, if DNSSEC is not used, to require that clients "walk" the tree of certificates to verify that it was properly signed by the relevant authority. This is good. My only regret is that while the recommendations are sound, the text does not explain why they are made -- i.e., because the 64-bit Orchid hash is too short to provide a a secure linkage between the HHIT and the public key used by the UAS. Adding some text to that effect would make the recommendations easier to understand. The second issue is well addressed. The text in section 5.1.2 specifies that "The Canonical Registration Certificate field is for a certificate endorsing registration of the DET. It MUST be encoded as X.509 DER [RFC5280]." The essential is there. We may still argue that the text is a bit awkward, or that something like "(see [draft-ietf-drip-dki])" would be useful, but the authors may or may not decide to do that. The tension between "just in time" and "DNSSEC" is also properly addressed by the new text in section 7.2. My mild concern about the coding risks inherent to complex CBOR syntax is not addressed. It probably does not need to be directly addressed in this document, but it would be nice if WG members somehow provided implementers with test vectors to verify the proper decoding of HHIT and BRID RRs. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
