Before going on I would really like to know what operational problem is being attempted to be solved by signing delegating information?
Fujiwara-san has presented the draft without specifying what problem it is attempting to solve. The fact the records are not signed is a observation not a problem per say. Mark > On 11 Dec 2020, at 10:48, Brian Dickson <brian.peter.dick...@gmail.com> wrote: > > > > On Thu, Dec 10, 2020 at 1:19 PM Peter van Dijk <peter.van.d...@powerdns.com> > wrote: > Hello Paul, > > On Mon, 2020-11-30 at 15:43 +0000, Paul Hoffman wrote: > > The more I think about draft-fujiwara-dnsop-delegation-information-signer, > > the more I think that it is much more complex than what we are doing now in > > DNSSEC, and therefore undesirable. > > My feelings are similar but not identical - the conversation already > shows that the glue story will be almost impossible to implement. Next > to that, I haven't figured out why we'd want to authenticate glue. > However, authenticating the delegation NSset fills an obvious gap in > various suggested answers to the dprive phase2 question (privacy > between resolvers and authoritatives). > > > If the goal is "a way for a signer in a parent to sign child NS in a way > > that does not affect validators that have not been updated (or don't > > care)", a significantly easier solution would be a new RRtype (maybe called > > "CNSRRSIG") that closely mimics RRSIG but only allows child NS for signing. > > An aware signer included the CNSRRSIG in the zone, and an aware > > authoritative server includes in in the Authority section when serving > > child NS records. An aware resolver can use this, an unware resolver would > > treat it like any other unknown RRtype that appears in the Authority > > section. > > > I think this is close to the mark, but still slightly off. > My take on this is roughly as follows: > • The goal here (as I understand it, or perhaps how I interpret it) is > to have NS data, corresponding to the child apex NS set, published on the > parent zone and signed by the parent (and used by upgraded resolvers without > breaking anything not upgraded). > • This involves at minimum the following elements, presented in a kind > of "reverse Polish" order: > • An RRSIG (or RRSIG-like thing) in the parent zone over > something new (TBD1) > • A way of publishing that "something new" to the parent (TBD2) > • A way of authenticating/validating that "something new" in > the process of publishing to the parent (TBD3) > • A way of linking the published "authenticating/validating" > data with data signed in the child zone, when being used/validated by the > resolver (or client) (TBD4) > • For "TBD1" If we keep the existing RRSIG signatures themselves, the > only question is when to include the "something new" in the delegation > response, along with the matching RRSIG. > • This suggests no need for a new RRSIG-like record type per se. > • Existing 403x/5155 logic handles adding RRSIGs to answers > • For "TBD2", the concern over what "something new" could be, and how > it gets published to the parent. > • Options to consider for "something new" itself are: > • A new RRTYPE with owner name of "apex" > • An existing RRTYPE with owner name of "apex", with > new parameters > • An existing RRTYPE with different owner name > • (For completeness, A new RRTYPE with different owner > name) > • Options to consider for "how it gets published" are basically: > • EPP > • This suggests the fewer "new" things involved, the > better. Zero new things would be ideal. > • This itself leads to preference for "An existing RRTYPE with > owner name of 'apex', with new parameters", specifically: > • Published RRTYPE == DS > • DS value is hash of DNSKEY with new parameters, > specifically a new algorithm > • The new algorithm is "concatenation of child apex NS > RRSET in canonical form and order" (i.e. that is what the DNSKEY 'public key' > field would be comprised of) > • NB: The existing specifications handle this -- new > (unknown) algorithms MUST be treated as if the record didn't exist. > • Some implementations may need to be fixed, > based on some experiments thus far. > • I think TBD3 and TBD4 are flip sides of the same coin. > • RRTYPE == DNSKEY or DS (depending on TLD) transferred via EPP > to the parent > • If RRTYPE transferred is DNSKEY, perform hash to produce DS. > • TBD3 is probably optional as it related to EPP > • TBD4 is the resolver/client validation, in two parts: > • Construct DNSKEY from input data (NS RRSET) > • Hash to create DS > • Compare to published DS > • Check RRSIG over DS > • The use case of getting the glue (and validating it) without actually > sending queries to the auth server itself prior to validating the glue, is a > classic "catch 22". The owner name of the NS set in the child zone, is > "privacy sensitive", at least in most use cases. However: > • Keeping the apex and delegation NS set in sync, and the > DNSKEY and DS in sync, can address this problem: > • Use CDS/CDNSKEY to publish DS/DNSKEY records that > match the current AND updated NS RRSET, prior to changing the NS RRSET > • Use the delegation NS RRSET rather than the child > apex NS RRSET for the validation (ie for recreation of DNSKEY and DS records) > • This would add extra steps when changing NS, but > would still be deterministic and possible to build into a state machine, with > an extra moving part (or two) > • It would then be feasible to get validated glue prior > to querying the authority server (e.g. for its TLSA record) and/or to > establish a TLS connection to the correct IP and name. > The TL;DR: of this is: no EPP changes needed, no new RRTYPEs needed, slightly > more steps in rolling the NS set during a change. > > This makes a ton of sense to me. > > Compared to DiS, registrar complexity is identical (because the > complexity is also hidden in the signer here); signer complexity is > potentially lower. The only real complexity change vs. DiS is in the > auths, that now need to know to serve CNSRRSIG from the parent side in > the additional part of a delegation response. For resolvers, this vs. > DiS is again pretty much moot. > > The CNSRRSIG would also require delegation auths (i.e. TLDs) to make changes, > and I think also require EPP changes. > See above for a very slightly different take on this idea, that avoids these > issues. > (EPP and TLDs are definitely the "long pole in the tent".) > > > > There are probably a few other diffs from the RRSIG definition in RFC 403x, > > but they should be minor. This might make implementation more likely to be > > correct for signers, servers, and resolvers. > > Yes, this calls for some experiments, but I suspect the outcome will be > as you described above - which means no hurdles to incremental rollout. > > (I am not even convinced this needs to be a new type, vs. reusing RRSIG > under the specific semantics you described, but a new type feels > cleaner to me.) > > > Thoughts? > > +1 ! > > +1 for me too. > > Brian > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
