On Sat, Aug 14, 2021 at 3:47 PM Paul Hoffman <paul.hoff...@icann.org> wrote:
> On Aug 13, 2021, at 8:40 AM, Ben Schwartz <bemasc= > 40google....@dmarc.ietf.org> wrote: > > I think we can summarize the recent DS-glue-signing drafts as follows: > > > > * draft-fujiwara-dnsop-delegation-information-signer: One new DS holding > a hash of all the glue records. > > * draft-dickson-dnsop-ds-hack: Each new DS holds the hash of one glue > RRSet > > * draft-schwartz-ds-glue: Each new DS holds one glue record verbatim > > > > These represent three of the six possible combinations of scope (RR, > RRSet, all glue) and encoding (hash vs. verbatim). All six combinations > are possible, with different tradeoffs. > > This concise list also points out a very serious terminology problem that > affects this discussion: unsigned NS records in a response are not glue > records. Similarly, SVCB records are not glue records. > I agree that more conciseness and precision are important to this discussion. Here are some further clarifications from the above list, in no particular order: - draft-fujiwara-dnsop-delegation-information-signer specifies that the parent is responsible for creating/maintaining the DS records - draft-dickson-dnsop-ds-hack specifies (or implies, or will be updated to specify) that the child creates the DS hashes and via one method or another transmits them to the parent (e.g. CDS, CDS polling by Registrar and EPP, etc) - All of the three require new DNSKEY algorithms, and draft-schwartz-ds-glue requires a new "hash" (technically "verbatim" is a type of hash) - All of these would return the DS record(s) in the authority section alongside the NS record, even if the glue data (A/AAAA) were returned in the additional section. > > Proposed differentiation between the drafts: > > * draft-fujiwara-dnsop-delegation-information-signer: One new DS holding a > hash of the NS records in the Authority section and all the address records > in the Additional section > > * draft-dickson-dnsop-ds-hack: Each new DS holds the hash of NS records in > the Authority section, the A records in the Additional section, and the > AAAA records in the Additional section > > * draft-schwartz-ds-glue: Each new DS holds one record verbatim; the > record might not appear in the rest of the response > > For the DRPIVE use cases, draft-schwartz-ds-glue allows a resolver to > discover SVCB records in a response from the parent, even if that parent is > not configured to put SVCB records in the Additional section. > While this is technically accurate, it is (IMNSHO) problematically insecure. SVCB records in a signed child domain would be protected by a real DS record (signed by parental RRSIG), and RRSIG in the child domain. Any SVCB record added to the parent domain via the "ds-glue" mechanism would NOT be signed by the child. The RRSIG of the new DS record would prove that the new DS record was not tampered by an active attacker (etc), but would not provide the data integrity offered by DNSSEC. I'm a strong advocate of discovery and use of SVCB records for both opportunistic and downgrade-resistant (authenticated) use cases. SVCB in the child nameserver name domain is the right place to put SVCB records, as the name server name is the association needed for TLS. The resolver talking TLS will be talking to the name server, to make encrypted queries about a domain served by the name server. (The domain served that is being queried is presumed to not have an in-bailiwick name server, since that particular corner case is a chicken/egg problem.) The alternative (to requiring the SVCB record in the child, signed by the child domain) might be an SVCB-like thing in the parent which contains data signed by the child. Specifically: - A DNSKEY algorithm, or component of the draft-schwartz encoding, which contains (SVCB + RRSIG_name_server_child_ksk(SVCB)) - This would be signed by the parent too, but the critical component the provides the data integrity from the child is the RRSIG_name_server_child_ksk element - Only the operator of the name server's name's domain (which possesses the name_server_child_ksk) can generate this signature - This is much stronger than being able to push data over an EPP channel, which is the mechanism available to a Registrar that polls the Registrant's domain for CDS records - EPP does not have a mechanism currently for validation of supplied DS records - Updates to EPP are not in scope for DNSOP itself Some other clarifications/explanations about draft-dickson-dnsop-ds-hack: - The current draft specifies that the current preferred existing hash algorithm (alg 2, sha2-256) is to be used, precisely and solely because that does not require new hash algorithms to be specified by dnsop via standards action (or whatever is done to change how new algorithms get adopted) and implemented by Registries and Registrars. In other words, the expectation is that use of hash alg 2 reduces or removes barriers to deployment - The one DNSKEY algorithm for each of NS, A, and AAAA encodings is designed to minimize the challenges of matching NS, A, and AAAA records to these DS hashes - The current -00 version has all the NS records lumped together in one RDATA hash. That might change in later revisions to have one DS per NS record to further simplify the matching, and to better handle update processing (specifically the async nature of updates and long-TTL records that may be cached). - The DS hash algorithms and DNSKEY algorithms are orthogonal. The choice of DNSKEY algorithm does not require that DS hash algorithm 2 be used per se; any future DS hash algorithm (including a NULL hash, i.e. verbatim) would be just as useable/deployable, at such time as it is widely deployed by registries and registrars There may be some ability to converge on some elements of these drafts. However, deployability is my main concern, and was a significant driver in the design choices. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
