After thinking about the response below a bit, my question would be - when a receiver expects a record to be present, but it isn’t, what is the proper response?
The proper response will depend on the reason - more accurately the presumed (lacking any out-of-band signals) reason - why the record is absent. From observations of the deployment of DNSSEC, most of the time that needed records weren’t present have been from operational errors and not malicious activity. This has led to a mindset that makes new deployments seen as high risk. It’s very important that a secured protocol be able to thwart or limit damage due to malicious behavior, but it also needs to tolerate benign operational mistakes. If mistakes are frequent and addressed by dropping the guard, then the security system is a wasted in investment. I’ve not yet equated a missing DELEG record to a sign of a malicious attack. I can see that during a transitional phase, the absence/presence of a DELEG record may be a matter of one or more operators experiencing roll-out jitters. Or even caching effects, where (apparently) overly long TTLs on existing resource record sets for a zone might have pinned them into memory while servers are now publishing DELEG. That is why the protocol definition needs to treat this as ‘set expectations’ and how to react, rather than assume a mindset of addressing ‘downgrade attacks.’ How one reacts to a benign error is different than the reaction to a malicious attack, in the past protocol definitions have been written as if everything unexpected was malicious. The question remains - can a receiver distinguish between a benign error and a malicious attack? From: Ben Schwartz <bem...@meta.com> Date: Tuesday, January 30, 2024 at 13:59 To: Edward Lewis <edward.le...@icann.org>, "dnsop@ietf.org" <dnsop@ietf.org> Subject: [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions In this line of reasoning, let's remember the "herd immunity" effect. If receivers mostly respond to expectation violations by transparent fallback, an attacker on the wire has more incentive to attempt the downgrade attack. If receivers mostly "fail closed", this incentive is reduced. This is a collective security effect, not something that can be determined unilaterally by each receiver. --Ben Schwartz ________________________________ From: DNSOP <dnsop-boun...@ietf.org> on behalf of Edward Lewis <edward.le...@icann.org> Sent: Tuesday, January 30, 2024 1:21 PM To: dnsop@ietf.org <dnsop@ietf.org> Subject: [DNSOP] General comment about downgrades vs. setting expectations in protocol definitions !-------------------------------------------------------------------| This Message Is From an External Sender |-------------------------------------------------------------------! I hear talk about "downgrade attacks" frequently, across different ideas. Hearing it again in the context of DELEG, I had this thought. We often wind up mired in discussions about downgrades, what they mean, the consequences. I'd suggest, as definers of protocols, we think in terms of ensuring that receivers of messages have an expectation of something. Inside protocol rules, data may be expected and arrive, expected and not, unexpected and arrive, or unexpected and not arrive. A downgrade attack is a diagnosis of "expected and not". A protocol ought to be documented to set up the receiver's expectations and define what the receiver does when they are not met. Apologies for this generic message, when looking at the DELEG documents again, it'll be something I'll keep in mind. I.e., the proposal to define one of the flags in the DNSKEY resource record format is setting up an expectation.... _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!9Kib5s7byH9knE7jhrQHwMERW6OMcWPfc55IGNZKu9OARR3qQfUc8Jef5Vv0DwibGVBtaVRpbgZ6N2ssZQkVyQ$>
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
