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/>