Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Thu, 2021-01-21 at 18:14 -0800, Brian Dickson wrote: > Paul's proposal would still require the parent to produce and serve the > NSRRSIG. However small a change that is, it is still a change. Yes, a change in signers and auths. > When compared with the alternative I proposed, my suggestion does not require > changes on the parent side, only on the Registrar, and possibly the child > authority server, and the validating resolver. > (Reminder, my idea was: use a new DNSSEC algorithm to stuff either the child > NS set or the parent NS set into a DNSKEY record and submit that as a new DS > value via existing EPP paths for updating the DS set.) Yes, I've also informally proposed this in the past, and Fujiwara's draft is the version with signer assistance. > I think both are viable options, where the question of whether both are truly > feasible (universally, i.e. across all TLDs) is the critical issue. > If the answer to that question is "no", then choosing the path that does not > require any TLD changes (at all) would seem (to me) to be the most promising > path. There's another perspective - if TLDs do this (where 'this' is 'whatever variant that gives us signed delegation NSsets'), then a NS owner can 'enable DoT' by publishing TLSA, without having to tell all his users 'please submit this pseudo-DNSKEY record to your TLD'. This strongly argues for "let's put the pain with a few hundred TLD operators" instead of thousands of registrars, their resellers, their clients that use APIs, their clients that use webforms that do not aid them in getting things right, their NS operators that now need to provide 200% more assistance when people change operators. In short, moving this pain into the signers (both of which come from only a handful of vendors!) actually makes a lot of sense to me. Many TLDs will be able to 'implement' CNSRRSIG (or some other variant) through the regular updates I trust they already do. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Thu, Jan 21, 2021 at 3:45 AM Peter van Dijk wrote: > On Thu, 2020-12-10 at 15:48 -0800, Brian Dickson wrote: > > > > > > 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 > > That is what the quoted text means to convey, sorry if that was > unclear! > > > , and I think also require EPP changes. > > I don't see how EPP comes into it at all. The signer signs all NSsets; > the auth serves the signatures with the delegations; done. > My understanding of Paul's idea is that "CNSRRSIG" is RRSIG(child's (apex) NS set), which could be different from the delegation NS set. IFF that is what it is, then the parent would need that information (what the child NS set is), which would require some change, either on the parent (TLD) side to poll for that, or on the Registrar side to submit it (via EPP). My strong suspicion is the EPP path would have less resistance. OTOH, if CNSRRSIG is really NSRRSIG, i.e. RRSIG(delegation NS set), then there is no requirement for any EPP stuff (or for the TLD to poll for the child NS set). Paul's proposal would still require the parent to produce and serve the NSRRSIG. However small a change that is, it is still a change. When compared with the alternative I proposed, my suggestion does not require changes on the parent side, only on the Registrar, and possibly the child authority server, and the validating resolver. (Reminder, my idea was: use a new DNSSEC algorithm to stuff either the child NS set or the parent NS set into a DNSKEY record and submit that as a new DS value via existing EPP paths for updating the DS set.) I think both are viable options, where the question of whether both are truly feasible (universally, i.e. across all TLDs) is the critical issue. If the answer to that question is "no", then choosing the path that does not require any TLD changes (at all) would seem (to me) to be the most promising path. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Thu, 2020-12-10 at 15:48 -0800, Brian Dickson wrote: > > > > 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 That is what the quoted text means to convey, sorry if that was unclear! > , and I think also require EPP changes. I don't see how EPP comes into it at all. The signer signs all NSsets; the auth serves the signatures with the delegations; done. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Dec 10, 2020, at 4:52 PM, Joe Abley wrote: > > On 10 Dec 2020, at 19:41, Paul Hoffman wrote: > >>> "Authenticate authoritative servers" is a bit vague for me. Parent and >>> child are namespace concepts and not relying parties that you'd ordinarily >>> expect to be able to authenticate anything. >> >> A resolver asks a parent what the NS records are for the child. Today, an >> on-path attacker can change the answer and the resolver would not be the >> wiser, so the resolvers cannot trust such answers to do things like look up >> TLSA records. There is a desire for resolvers to be sure that what the child >> NS records they receive from the parent is what the parent has in its zone >> for the child so they can use this information to ask for TLSA records. > Did I read that back correctly? Somewhat, but not completely. > The problems that DNSSEC is trying to solve are with identifying inauthentic > data ultimately requested by applications. If an intermediate referral > response includes an inauthentic NS RRSet with no RRSIGs or an NS RRset with bogus RRSIGs > it cannot be identified as inauthentic, but it doesn't really matter because > any data that is expected to be signed from the inauthentic servers will fail > validation and the application will be protected. > > The problems that dprive is trying to solve concern surveillance > opportunities and information leakage. that if an imtermediate referral > response includes an inauthentic NS RRSet with no RRSIGs it could cause > queries on behalf of an application to be harvested by an untrusted third > party at one of those inauthentic servers, which could represent a > surveillance opportunity. That is true so far, but some folks have informally gotten excited about authenticating intermediate referral responses for other reasons. (They can speak for themselves; that's not my use case yet.) > The proposal is hence to provide a way for an intermediate referral response > that includes an inauthentic NS RRSet to be identified as inauthentic so that > subsequent queries to the untrusted third party servers can be suppressed. Again, this is true so far, but others have hinted that they might use the authentication for more. > I've now typed "inauthentic" enough that I am starting to doubt that it is a > word, but "bogus" has a particular and different meaning in DNSSEC so I was > trying to avoid it. You even skipped using "bogus" once above. :-) --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Thu, Dec 10, 2020 at 4:52 PM Joe Abley wrote: > On 10 Dec 2020, at 19:41, Paul Hoffman wrote: > > >> "Authenticate authoritative servers" is a bit vague for me. Parent and > child are namespace concepts and not relying parties that you'd ordinarily > expect to be able to authenticate anything. > > > > A resolver asks a parent what the NS records are for the child. Today, > an on-path attacker can change the answer and the resolver would not be the > wiser, so the resolvers cannot trust such answers to do things like look up > TLSA records. There is a desire for resolvers to be sure that what the > child NS records they receive from the parent is what the parent has in its > zone for the child so they can use this information to ask for TLSA records. > > The problems that DNSSEC is trying to solve are with identifying > inauthentic data ultimately requested by applications. If an intermediate > referral response includes an inauthentic NS RRSet with no RRSIGs it cannot > be identified as inauthentic, but it doesn't really matter because any data > that is expected to be signed from the inauthentic servers will fail > validation and the application will be protected. > > The problems that dprive is trying to solve concern surveillance > opportunities and information leakage. that if an imtermediate referral > response includes an inauthentic NS RRSet with no RRSIGs it could cause > queries on behalf of an application to be harvested by an untrusted third > party at one of those inauthentic servers, which could represent a > surveillance opportunity. > > The proposal is hence to provide a way for an intermediate referral > response that includes an inauthentic NS RRSet to be identified as > inauthentic so that subsequent queries to the untrusted third party servers > can be suppressed. > > Did I read that back correctly? > > Yes. Brian > I've now typed "inauthentic" enough that I am starting to doubt that it is > a word, but "bogus" has a particular and different meaning in DNSSEC so I > was trying to avoid it. > > > Joe > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On 10 Dec 2020, at 19:41, Paul Hoffman wrote: >> "Authenticate authoritative servers" is a bit vague for me. Parent and child >> are namespace concepts and not relying parties that you'd ordinarily expect >> to be able to authenticate anything. > > A resolver asks a parent what the NS records are for the child. Today, an > on-path attacker can change the answer and the resolver would not be the > wiser, so the resolvers cannot trust such answers to do things like look up > TLSA records. There is a desire for resolvers to be sure that what the child > NS records they receive from the parent is what the parent has in its zone > for the child so they can use this information to ask for TLSA records. The problems that DNSSEC is trying to solve are with identifying inauthentic data ultimately requested by applications. If an intermediate referral response includes an inauthentic NS RRSet with no RRSIGs it cannot be identified as inauthentic, but it doesn't really matter because any data that is expected to be signed from the inauthentic servers will fail validation and the application will be protected. The problems that dprive is trying to solve concern surveillance opportunities and information leakage. that if an imtermediate referral response includes an inauthentic NS RRSet with no RRSIGs it could cause queries on behalf of an application to be harvested by an untrusted third party at one of those inauthentic servers, which could represent a surveillance opportunity. The proposal is hence to provide a way for an intermediate referral response that includes an inauthentic NS RRSet to be identified as inauthentic so that subsequent queries to the untrusted third party servers can be suppressed. Did I read that back correctly? I've now typed "inauthentic" enough that I am starting to doubt that it is a word, but "bogus" has a particular and different meaning in DNSSEC so I was trying to avoid it. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Dec 10, 2020, at 4:35 PM, Joe Abley wrote: > > On Dec 10, 2020, at 19:25, Paul Hoffman wrote: > >> In DPRIVE, there is a desire to TLSA records to authenticate authoritative >> servers. In order to do that without getting into a chicken-and-egg loop, >> the parent needs to authenticate the NS records of the child authoritative >> server. > > I haven't been following dprive recently. Is there a particular document that > expresses the problem statement above in more detail? No. As you know, DPRIVE is not strong on use case documents... > "Authenticate authoritative servers" is a bit vague for me. Parent and child > are namespace concepts and not relying parties that you'd ordinarily expect > to be able to authenticate anything. A resolver asks a parent what the NS records are for the child. Today, an on-path attacker can change the answer and the resolver would not be the wiser, so the resolvers cannot trust such answers to do things like look up TLSA records. There is a desire for resolvers to be sure that what the child NS records they receive from the parent is what the parent has in its zone for the child so they can use this information to ask for TLSA records. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Dec 10, 2020, at 19:25, Paul Hoffman wrote: > In DPRIVE, there is a desire to TLSA records to authenticate authoritative > servers. In order to do that without getting into a chicken-and-egg loop, the > parent needs to authenticate the NS records of the child authoritative server. I haven't been following dprive recently. Is there a particular document that expresses the problem statement above in more detail? "Authenticate authoritative servers" is a bit vague for me. Parent and child are namespace concepts and not relying parties that you'd ordinarily expect to be able to authenticate anything. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Dec 10, 2020, at 4:14 PM, Mark Andrews wrote: > > 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. Asking for stated use cases! Yay! In DPRIVE, there is a desire to TLSA records to authenticate authoritative servers. In order to do that without getting into a chicken-and-egg loop, the parent needs to authenticate the NS records of the child authoritative server. If child NS records were already signed in the parent, that solves this use case. They aren't, so we're thinking of ways to authenticate child NS records from the parent. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Dec 10, 2020, at 19:14, Mark Andrews wrote: > Before going on I would really like to know what operational problem is being > attempted to be solved by signing delegating information? +1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
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 wrote: > > > > On Thu, Dec 10, 2020 at 1:19 PM Peter van Dijk > wrote: > Hello Paul, > > On Mon, 2020-11-30 at 15:43 +, 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
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Thu, Dec 10, 2020 at 1:19 PM Peter van Dijk wrote: > Hello Paul, > > On Mon, 2020-11-30 at 15:43 +, 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
