Rogue Operator Work Party: Source of zone data
A discussion topic brought up at the last Rogue Operator Work Party call was on where [technically] an RSO fetches their root zone information from. Typically, an RSO will fetch zone data directly from the RZM’s servers [distribution of the zone files among the RSO’s instances is not considered here, just the initial fetch(es) from a source]. What if an RSO obtained their copy of the zone data from an intermediate source? #RootZone The RSO is responsible for publishing the correct IANA zone, as made available by the RZM. Whether they get it directly from the RZM or via some other party should(?) be irrelevant. An intermediate source certainly does introduce additional risk that the zone could have been modified, but it is still the responsibility of the RSO to publish true IANA data. I would not consider it _wise_ to obtain the zone from an intermediate source, but would we go so far as to say that this is a _rogue_ operation? Historically (1998?), fetching from an intermediate was seen as a pre-cursor to rogue operations, where new source may have had intentions of changing the zone, but there seem to be different interpretations of those events. The question to the group is: “Would using an intermediate source of root zone data, by itself, be considered a ROGUE operation?” Regardless of who the intermediate is…, regardless of the authenticity of the zone data… Thoughts? Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr@mail.mil
Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus writes:
... The question to the group is: “Would using an intermediate source of root zone data, by itself, be considered a ROGUE operation?” Regardless of who the intermediate is…, regardless of the authenticity of the zone data…
in my opinion, no. carrier pigeon, /dev/random, hostile nation-state actor, none of that matters. if it's dnssec-authentic using the icann key, then the publication of such data is in-bounds and not-rogue. source, including intermediaries, no longer matters. that's the underlying meaning of dnssec. vixie
On Tue, Oct 06, 2020 at 02:15:21PM -0700, P Vixie wrote:
Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus writes:
... The question to the group is: “Would using an intermediate source of root zone data, by itself, be considered a ROGUE operation?” Regardless of who the intermediate is…, regardless of the authenticity of the zone data…
in my opinion, no. carrier pigeon, /dev/random, hostile nation-state actor, none of that matters. if it's dnssec-authentic using the icann key, then the publication of such data is in-bounds and not-rogue. source, including intermediaries, no longer matters. that's the underlying meaning of dnssec.
The root zone is not entirely signed by DNSSEC (NS records at zonecuts and address glue have no signatures, which could be changed to deny service to specific TLDs). We mention DNSSEC to indicate security but there are details that can be misused. DNSSEC does not prevent replay for as long as the RRSIGs on the data they cover are valid (it needs to be able to replay so data can be served from secondaries and caches). As an example, consider the following NSEC in the root zone at the time this email was written (20201006223000): com. 86400 IN NSEC comcast. NS DS RRSIG NSEC com. 86400 IN RRSIG NSEC 8 1 86400 20201019200000 20201006190000 26116 <snip> As you know, these records can be used as part of a negative proof to prove that there can be no other name between "com." and "comcast.". Consider now (20201006223000), the expiry time of the RRSIG vs. the TTL of the RRsets. If ICANN introduces a new TLD between "com." and "comcast." today and distributes that zone via zone transfer, an intermediate source or on-path attacker can use the insecurity proof previously obtained above to deny access to the new TLD till 2020-10-19, which will verify with a DNSSEC validator. 2020-10-19 is relatively a longer time away, even compared to the SOA.expire field's value in the root zone. I agree that where the root zone or the root keys are sourced from should not matter as long as they can be authenticated as correct and current. draft-ietf-dnsop-dns-zone-digest-11 could be useful for this with its RRSIG's expiry limited suitably.
Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus writes: The question to the group is: “Would using an intermediate source of root zone data, by itself, be considered a ROGUE operation?” Regardless of who the intermediate is…, regardless of the authenticity of the zone data…
If it is provably current and authentic by some mechanism, the source/transport/etc. don't matter. As an analogy, this is one of the main features of DNSSEC for individual positive and negative responses, and other forms of application of crypto such as PGP, that: it doesn't matter who you get the data from or how as long as it is provable that the data is current and authentic. Mukund
Mukund Sivaraman writes:
On Tue, Oct 06, 2020 at 02:15:21PM -0700, P Vixie wrote:
... if it's dnssec-authentic using the icann key, then the publication of such data is in-bounds and not-rogue. source, including intermediaries, no longer matters. that's the underlying meaning of dnssec.
The root zone is not entirely signed by DNSSEC (NS records at zonecuts and address glue have no signatures, which could be changed to deny service to specific TLDs).
this never mattered, and doesn't matter now. if the subzone isn't signed, all hell will break loose, regardless of what's in the root zone. if it is signed, then the DS RRs in the root zone must match the DNSKEY in the subzone. i think we have to stop treating unsigned NS RRs as a shiny object; if they posed any problem to authenticity of DNS content, it would be a very big problem, in no way limited to the topic we are discussing here.
We mention DNSSEC to indicate security but there are details that can be misused. DNSSEC does not prevent replay for as long as the RRSIGs on the data they cover are valid (it needs to be able to replay so data can be served from secondaries and caches). As an example, consider the following NSEC in the root zone at the time this email was written (20201006223000):
com. 86400 IN NSEC comcast. NS DS RRSIG NSEC com. 86400 IN RRSIG NSEC 8 1 86400 20201019200000 20201006190000 26116 <snip>
As you know, these records can be used as part of a negative proof to prove that there can be no other name between "com." and "comcast.". Consider now (20201006223000), the expiry time of the RRSIG vs. the TTL of the RRsets. If ICANN introduces a new TLD between "com." and "comcast." today and distributes that zone via zone transfer, an intermediate source or on-path attacker can use the insecurity proof previously obtained above to deny access to the new TLD till 2020-10-19, which will verify with a DNSSEC validator. 2020-10-19 is relatively a longer time away, even compared to the SOA.expire field's value in the root zone.
icann knows they cannot make zone changes of this kind with short turnaround. if this is a bigger problem then they know about, then the dns technical community should document it in an RFC and bring it to icann's attention.
I agree that where the root zone or the root keys are sourced from should not matter as long as they can be authenticated as correct and current. draft-ietf-dnsop-dns-zone-digest-11 could be useful for this with its RRSIG's expiry limited suitably.
zone-digest doesn't solve any problem that dnssec has. it's for axfr initiator auditing. if you think the root zone should use zone-digest as a sort of belt+suspenders audit check, i'd be interested to see your proposal. vixie
Regardless of the ability to detect a modified response (such as non-validating resolvers), we have determined that it would be _rogue_ for an RSO to serve modified zone data. An intermediate source introduces additional risk of modification and, in the past was interpreted as a pre-cursor to using an alternate root zone. The sense that I'm getting is that "as long as the data served is correct, it's not rogue". Any other interpretations or opinions would be appreciated. Thanks! Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr@mail.mil On 10/6/20, 9:11 PM, "P Vixie" <paul@redbarn.org> wrote: Mukund Sivaraman writes: > On Tue, Oct 06, 2020 at 02:15:21PM -0700, P Vixie wrote: >> ... if it's dnssec-authentic using the icann key, then the >> publication of such data is in-bounds and not-rogue. source, including >> intermediaries, no longer matters. that's the underlying meaning of >> dnssec. > > The root zone is not entirely signed by DNSSEC (NS records at zonecuts > and address glue have no signatures, which could be changed to deny > service to specific TLDs). this never mattered, and doesn't matter now. if the subzone isn't signed, all hell will break loose, regardless of what's in the root zone. if it is signed, then the DS RRs in the root zone must match the DNSKEY in the subzone. i think we have to stop treating unsigned NS RRs as a shiny object; if they posed any problem to authenticity of DNS content, it would be a very big problem, in no way limited to the topic we are discussing here. > We mention DNSSEC to indicate security but there are details that can be > misused. DNSSEC does not prevent replay for as long as the RRSIGs on the > data they cover are valid (it needs to be able to replay so data can be > served from secondaries and caches). As an example, consider the > following NSEC in the root zone at the time this email was written > (20201006223000): > > com. 86400 IN NSEC comcast. NS DS RRSIG NSEC > com. 86400 IN RRSIG NSEC 8 1 86400 > 20201019200000 20201006190000 26116 <snip> > > As you know, these records can be used as part of a negative proof to > prove that there can be no other name between "com." and > "comcast.". Consider now (20201006223000), the expiry time of the RRSIG > vs. the TTL of the RRsets. If ICANN introduces a new TLD between "com." > and "comcast." today and distributes that zone via zone transfer, an > intermediate source or on-path attacker can use the insecurity proof > previously obtained above to deny access to the new TLD till 2020-10-19, > which will verify with a DNSSEC validator. 2020-10-19 is relatively a > longer time away, even compared to the SOA.expire field's value in the > root zone. icann knows they cannot make zone changes of this kind with short turnaround. if this is a bigger problem then they know about, then the dns technical community should document it in an RFC and bring it to icann's attention. > I agree that where the root zone or the root keys are sourced from > should not matter as long as they can be authenticated as correct and > current. draft-ietf-dnsop-dns-zone-digest-11 could be useful for this > with its RRSIG's expiry limited suitably. zone-digest doesn't solve any problem that dnssec has. it's for axfr initiator auditing. if you think the root zone should use zone-digest as a sort of belt+suspenders audit check, i'd be interested to see your proposal. vixie
Ken, As long as the intermediate source hasn’t modified nor tampered with data from the root zone (by verifying the DNSSEC records), then I don’t think it should be classified as rogue. Best, Paul Muchene
On Oct 7, 2020, at 3:36 PM, Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus <rssac-caucus@icann.org> wrote:
Regardless of the ability to detect a modified response (such as non-validating resolvers), we have determined that it would be _rogue_ for an RSO to serve modified zone data. An intermediate source introduces additional risk of modification and, in the past was interpreted as a pre-cursor to using an alternate root zone.
The sense that I'm getting is that "as long as the data served is correct, it's not rogue". Any other interpretations or opinions would be appreciated.
Thanks!
Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr@mail.mil <mailto:kenneth.d.renard.ctr@mail.mil>
On 10/6/20, 9:11 PM, "P Vixie" <paul@redbarn.org <mailto:paul@redbarn.org>> wrote:
Mukund Sivaraman writes:
On Tue, Oct 06, 2020 at 02:15:21PM -0700, P Vixie wrote:
... if it's dnssec-authentic using the icann key, then the publication of such data is in-bounds and not-rogue. source, including intermediaries, no longer matters. that's the underlying meaning of dnssec.
The root zone is not entirely signed by DNSSEC (NS records at zonecuts and address glue have no signatures, which could be changed to deny service to specific TLDs).
this never mattered, and doesn't matter now. if the subzone isn't signed, all hell will break loose, regardless of what's in the root zone. if it is signed, then the DS RRs in the root zone must match the DNSKEY in the subzone. i think we have to stop treating unsigned NS RRs as a shiny object; if they posed any problem to authenticity of DNS content, it would be a very big problem, in no way limited to the topic we are discussing here.
We mention DNSSEC to indicate security but there are details that can be misused. DNSSEC does not prevent replay for as long as the RRSIGs on the data they cover are valid (it needs to be able to replay so data can be served from secondaries and caches). As an example, consider the following NSEC in the root zone at the time this email was written (20201006223000):
com. 86400 IN NSEC comcast. NS DS RRSIG NSEC com. 86400 IN RRSIG NSEC 8 1 86400 20201019200000 20201006190000 26116 <snip>
As you know, these records can be used as part of a negative proof to prove that there can be no other name between "com." and "comcast.". Consider now (20201006223000), the expiry time of the RRSIG vs. the TTL of the RRsets. If ICANN introduces a new TLD between "com." and "comcast." today and distributes that zone via zone transfer, an intermediate source or on-path attacker can use the insecurity proof previously obtained above to deny access to the new TLD till 2020-10-19, which will verify with a DNSSEC validator. 2020-10-19 is relatively a longer time away, even compared to the SOA.expire field's value in the root zone.
icann knows they cannot make zone changes of this kind with short turnaround. if this is a bigger problem then they know about, then the dns technical community should document it in an RFC and bring it to icann's attention.
I agree that where the root zone or the root keys are sourced from should not matter as long as they can be authenticated as correct and current. draft-ietf-dnsop-dns-zone-digest-11 could be useful for this with its RRSIG's expiry limited suitably.
zone-digest doesn't solve any problem that dnssec has. it's for axfr initiator auditing. if you think the root zone should use zone-digest as a sort of belt+suspenders audit check, i'd be interested to see your proposal.
vixie _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Ken, Yes in one sense if it is not modified or tampered with might not rouge as no one would be able to tell the difference but clearly if it was modified it becomes an obvious rouge. But to be safe, I think classifying ANY intermediate as rouge would be the best option. AK On Wed, Oct 7, 2020 at 11:53 PM Paul Muchene <Paul.Muchene@icann.org> wrote:
Ken,
As long as the intermediate source hasn’t modified nor tampered with data from the root zone (by verifying the DNSSEC records), then I don’t think it should be classified as rogue.
Best,
Paul Muchene
On Oct 7, 2020, at 3:36 PM, Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus <rssac-caucus@icann.org> wrote:
Regardless of the ability to detect a modified response (such as non-validating resolvers), we have determined that it would be _rogue_ for an RSO to serve modified zone data. An intermediate source introduces additional risk of modification and, in the past was interpreted as a pre-cursor to using an alternate root zone.
The sense that I'm getting is that "as long as the data served is correct, it's not rogue". Any other interpretations or opinions would be appreciated.
Thanks!
Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr@mail.mil
On 10/6/20, 9:11 PM, "P Vixie" <paul@redbarn.org> wrote:
Mukund Sivaraman writes:
On Tue, Oct 06, 2020 at 02:15:21PM -0700, P Vixie wrote:
... if it's dnssec-authentic using the icann key, then the publication of such data is in-bounds and not-rogue. source, including intermediaries, no longer matters. that's the underlying meaning of dnssec.
The root zone is not entirely signed by DNSSEC (NS records at zonecuts and address glue have no signatures, which could be changed to deny service to specific TLDs).
this never mattered, and doesn't matter now. if the subzone isn't signed, all hell will break loose, regardless of what's in the root zone. if it is signed, then the DS RRs in the root zone must match the DNSKEY in the subzone. i think we have to stop treating unsigned NS RRs as a shiny object; if they posed any problem to authenticity of DNS content, it would be a very big problem, in no way limited to the topic we are discussing
here.
We mention DNSSEC to indicate security but there are details that can be misused. DNSSEC does not prevent replay for as long as the RRSIGs on the data they cover are valid (it needs to be able to replay so data can be served from secondaries and caches). As an example, consider the following NSEC in the root zone at the time this email was written (20201006223000):
com. 86400 IN NSEC comcast. NS DS RRSIG NSEC com. 86400 IN RRSIG NSEC 8 1 86400 20201019200000 20201006190000 26116 <snip>
As you know, these records can be used as part of a negative proof to prove that there can be no other name between "com." and "comcast.". Consider now (20201006223000), the expiry time of the RRSIG vs. the TTL of the RRsets. If ICANN introduces a new TLD between "com." and "comcast." today and distributes that zone via zone transfer, an intermediate source or on-path attacker can use the insecurity proof previously obtained above to deny access to the new TLD till 2020-10-19, which will verify with a DNSSEC validator. 2020-10-19 is relatively a longer time away, even compared to the SOA.expire field's value in the root zone.
icann knows they cannot make zone changes of this kind with short turnaround. if this is a bigger problem then they know about, then the dns technical community should document it in an RFC and bring it to icann's attention.
I agree that where the root zone or the root keys are sourced from should not matter as long as they can be authenticated as correct and current. draft-ietf-dnsop-dns-zone-digest-11 could be useful for this with its RRSIG's expiry limited suitably.
zone-digest doesn't solve any problem that dnssec has. it's for axfr initiator auditing. if you think the root zone should use zone-digest as a sort of belt+suspenders audit check, i'd be interested to see your proposal.
vixie _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Website <http://www.unilorin.edu.ng>, Weekly Bulletin <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal <http://uilugportal.unilorin.edu.ng/> PGPortal <https://uilpgportal.unilorin.edu.ng/>
On Wed, Oct 07, 2020 at 01:11:13AM +0000, P Vixie wrote:
Mukund Sivaraman writes:
On Tue, Oct 06, 2020 at 02:15:21PM -0700, P Vixie wrote:
... if it's dnssec-authentic using the icann key, then the publication of such data is in-bounds and not-rogue. source, including intermediaries, no longer matters. that's the underlying meaning of dnssec.
The root zone is not entirely signed by DNSSEC (NS records at zonecuts and address glue have no signatures, which could be changed to deny service to specific TLDs).
this never mattered, and doesn't matter now. if the subzone isn't signed, all hell will break loose, regardless of what's in the root zone. if it is signed, then the DS RRs in the root zone must match the DNSKEY in the subzone. i think we have to stop treating unsigned NS RRs as a shiny object; if they posed any problem to authenticity of DNS content, it would be a very big problem, in no way limited to the topic we are discussing here.
Sorry Paul, but I wrote that it could be used to deny service to specific TLDs. A resolver can be made to go down a rabbit hole with this.
We mention DNSSEC to indicate security but there are details that can be misused. DNSSEC does not prevent replay for as long as the RRSIGs on the data they cover are valid (it needs to be able to replay so data can be served from secondaries and caches). As an example, consider the following NSEC in the root zone at the time this email was written (20201006223000):
com. 86400 IN NSEC comcast. NS DS RRSIG NSEC com. 86400 IN RRSIG NSEC 8 1 86400 20201019200000 20201006190000 26116 <snip>
As you know, these records can be used as part of a negative proof to prove that there can be no other name between "com." and "comcast.". Consider now (20201006223000), the expiry time of the RRSIG vs. the TTL of the RRsets. If ICANN introduces a new TLD between "com." and "comcast." today and distributes that zone via zone transfer, an intermediate source or on-path attacker can use the insecurity proof previously obtained above to deny access to the new TLD till 2020-10-19, which will verify with a DNSSEC validator. 2020-10-19 is relatively a longer time away, even compared to the SOA.expire field's value in the root zone.
icann knows they cannot make zone changes of this kind with short turnaround. if this is a bigger problem then they know about, then the dns technical community should document it in an RFC and bring it to icann's attention.
This scenario isn't limited just to the root zone. The term "DNSSEC" is used liberally (thrown around) in an absolute security sense and it may be so on paper. In practice, freshness of data also matters in validation - the purpose of the RRSIG.signature_expiration field. As another example (unrelated to .), consider icann.org./DS which is in the org. TLD zone: icann.org. 86400 IN DS 18060 7 2 6BE021818B9F10ED981A03ACBF74F01E31FB15C58680AD0C4BAA464B F37A7523 icann.org. 86400 IN DS 17248 7 2 885CF8A6CF35FD5C619E1D48B59AFB23063BBA9FEC52FF25F99094CB A10910A2 icann.org. 86400 IN DS 23584 7 2 AF57A492640102809209AA005B93C32B7ACC83734BC785CFA50B5168 8299CD61 icann.org. 86400 IN RRSIG DS 7 2 86400 20201022152630 20201001142630 22064 org. ewzWItl/9UI59cpAPD9mHnE11Lzjl2ZS7E4pCYejt26Ua47vPOY1H78L mcgAHWP6pbLebQXYLg4An+3zW9sAlmG0m0xZmVk2N8C6Uextyd69IQ4F s5FebwAFwSmMYLzwnAB3B34tsQSxqVTC5LCnlPFouaN7INfI9/y1uI7e m/Q= icann.org. 86400 IN RRSIG DS 8 2 86400 20201022152630 20201001142630 63858 org. t8EFGtYX1VGozPOYrS7JH8PXsHqSCfbe4PwYJlxrhQO2bXqLqeVO2DY0 hP0Iy271ICBSC4U13+fMmL/fqEsM3B9xhg06h8PYY8cWLWCFPpEjrpVL D5wUZ+876GNKOYf16V3wbW8LzsACKeikJOksxqGlrE1LVIuuAEK3YTYC QcU= The signature for DS corresponding to icann.org./DNSKEY set expires on 2020-10-22 whereas it is 2020-10-07 today. If there is a key compromise of an icann.org's DNSKEY, an on-path attacker can continue to forge answers till 2020-10-22 (unless one specifically looks for forgery) which is ~15 days away. Similarly for NSEC negative answers. Coming back to the root zone case, and the specific case of whether the source of a zone's content matters, it wouldn't matter if the data passes both for correctness and freshness. These are very long recovery times to allow forgery, i.e., 2 weeks old data is very stale in public DNS IMHO.
I agree that where the root zone or the root keys are sourced from should not matter as long as they can be authenticated as correct and current. draft-ietf-dnsop-dns-zone-digest-11 could be useful for this with its RRSIG's expiry limited suitably.
zone-digest doesn't solve any problem that dnssec has. it's for axfr initiator auditing. if you think the root zone should use zone-digest as a sort of belt+suspenders audit check, i'd be interested to see your proposal.
I didn't intend to say zone digest is a replacement for DNSSEC. It uses DNSSEC to sign the ZONEMD RRset. The zone digest would also verify delegation NS records and occluded records within a zone such as address glue. It still remains that the ZONEMD's RRSIG signature expiration time should be suitably picked. I'm perhaps not following what you mean. From section 6.1 in: https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-11
The zone digest allows the recipient of a zone to verify its integrity. In conjunction with DNSSEC, the recipient can authenticate that it is as published by the zone originator.
From the abstract:
This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received.
It doesn't say it's limited to AXFR or zone transfers, but then again, even if it is limited to transfers, it is typically the way nameservers receive zone contents from a "source". Mukund
On Wed, Oct 07, 2020 at 06:12:02PM +0530, Mukund Sivaraman wrote:
On Wed, Oct 07, 2020 at 01:11:13AM +0000, P Vixie wrote:
Mukund Sivaraman writes:
On Tue, Oct 06, 2020 at 02:15:21PM -0700, P Vixie wrote:
... that's the underlying meaning of dnssec.
The root zone is not entirely signed by DNSSEC (NS records at zonecuts and address glue have no signatures, which could be changed to deny service to specific TLDs).
this never mattered, and doesn't matter now. if the subzone isn't signed, all hell will break loose, regardless of what's in the root zone. if it is signed, then the DS RRs in the root zone must match the DNSKEY in the subzone. ...
Sorry Paul, but I wrote that it could be used to deny service to specific TLDs. A resolver can be made to go down a rabbit hole with this.
i hope you can do some game theory here. a bad NS record set is a problem, regardless of dnssec status. but, the problem itself is different without dnssec vs. with dnssec. we (the entire internet technical and governance community) no longer make extra effort for the non-dnssec problem, either with an unsigned tld, or a nonvalidating resolver.
icann knows they cannot make zone changes of this kind with short turnaround. if this is a bigger problem then they know about, then the dns technical community should document it in an RFC and bring it to icann's attention.
This scenario isn't limited just to the root zone.
our work on this committee, however, is thusly limited. broader concerns (such as your icann.org example) should go to the DNSOP WG.
From section 6.1 in: https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-11
The zone digest allows the recipient of a zone to verify its integrity. In conjunction with DNSSEC, the recipient can authenticate that it is as published by the zone originator.
From the abstract:
This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received.
It doesn't say it's limited to AXFR or zone transfers, but then again, even if it is limited to transfers, it is typically the way nameservers receive zone contents from a "source".
one can only verify that the signed zonemd record has a correct checksum if one is in possession of the full zone. that means transfer initiators. -- Paul Vixie
+1 Wondering if same criteria would apply when getting Root Zone using AXFR for Hyperlocal? --Nico On 10/6/20, 18:32, "rssac-caucus on behalf of P Vixie" <rssac-caucus-bounces@icann.org on behalf of paul@redbarn.org> wrote: Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus writes: > ... > The question to the group is: “Would using an intermediate source of root > zone data, by itself, be considered a ROGUE operation?” Regardless of > who the intermediate is…, regardless of the authenticity of the zone data… in my opinion, no. carrier pigeon, /dev/random, hostile nation-state actor, none of that matters. if it's dnssec-authentic using the icann key, then the publication of such data is in-bounds and not-rogue. source, including intermediaries, no longer matters. that's the underlying meaning of dnssec. vixie _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://urldefense.com/v3/__https://www.icann.org/privacy/policy__;!!PtGJab4... ) and the website Terms of Service (https://urldefense.com/v3/__https://www.icann.org/privacy/tos__;!!PtGJab4!pD... ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Going back to the work party statement I read “This work party will examine scenarios where an RSO, or someone acting as an RSO, serves incorrect zone data”. Also Scope refers to: “Outline the types of damage that could be done to different resolver configurations.” Then if someone acting as an RSO serves incorrect zone info to a resolver using Hyperlocal, it may fall into the same issue we are dealing with here... and in that case DNSSEC may not solve it. So may be it’s worth for the Caucus draft to also consider those scenarios even if we do not like them.
El oct. 8, 2020, a la(s) 00:48, P Vixie <paul@redbarn.org> escribió:
Nicolas Antoniello writes:
+1 Wondering if same criteria would apply when getting Root Zone using AXFR for Hyperlocal?
hyperlocal is silliness. and off topic for this work party.
Nicolas Antoniello writes:
Going back to the work party statement I read “This work party will examine scenarios where an RSO, or someone acting as an RSO, serves incorrect zone data”. Also Scope refers to: “Outline the types of damage that could be done to different resolver configurations.”
Then if someone acting as an RSO serves incorrect zone info to a resolver using Hyperlocal, it may fall into the same issue we are dealing with here... [...]
hyperlocals will fetch from servers like yours, which are not RSO's: https://www.dns.icann.org/services/axfr/
So may be it’s worth for the Caucus draft to also consider those scenarios even if we do not like them.
are you speaking for ICANN?
The thread on hyperlocal seems misplaced to me as the co-author of RFC 8806. The text of the document explicitly says "The root zone can be retrieved from anywhere as long as it comes with all the DNSSEC records needed for validation." It seemed to me that the Caucus already shot down the idea that the source of the zone data was relevant. --Paul Hoffman
On 6 Oct 2020, at 13:19, Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus wrote:
A discussion topic brought up at the last Rogue Operator Work Party call was on where [technically] an RSO fetches their root zone information from. Typically, an RSO will fetch zone data directly from the RZM’s servers [distribution of the zone files among the RSO’s instances is not considered here, just the initial fetch(es) from a source]. What if an RSO obtained their copy of the zone data from an intermediate source? #RootZone
The RSO is responsible for publishing the correct IANA zone, as made available by the RZM. Whether they get it directly from the RZM or via some other party should(?) be irrelevant. An intermediate source certainly does introduce additional risk that the zone could have been modified, but it is still the responsibility of the RSO to publish true IANA data. I would not consider it _wise_ to obtain the zone from an intermediate source, but would we go so far as to say that this is a _rogue_ operation? Historically (1998?), fetching from an intermediate was seen as a pre-cursor to rogue operations, where new source may have had intentions of changing the zone, but there seem to be different interpretations of those events.
The question to the group is: “Would using an intermediate source of root zone data, by itself, be considered a ROGUE operation?” Regardless of who the intermediate is…, regardless of the authenticity of the zone data…
to me, the first criteria for declaring rogue is that the operator is not serving the root zone, but a modified version. The only way to really find that is with DNSSEC. In this context, the source of the root zone seems irrelevant to me. Marc.
Thoughts?
Ken Renard
S&TCD Contractor – ICF
Sustaining Base Network Assurance Branch
C5ISR Center, Space and Terrestrial Communications Directorate
Office: 443-395-7809
kenneth.d.renard.ctr@mail.mil
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (9)
-
ABDULKARIM OLOYEDE -
Marc Blanchet -
Mukund Sivaraman -
Nicolas Antoniello -
P Vixie -
Paul Hoffman -
Paul Muchene -
Paul Vixie
-
Renard, Kenneth D CTR USARMY CCDC C5ISR (USA)