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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
