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