From: Manu Bretelle <chan...@gmail.com> Date: Wednesday, February 7, 2024 at 14:19 To: Peter Thomassen <pe...@desec.io> Cc: Edward Lewis <edward.le...@icann.org>, Ben Schwartz <bem...@meta.com>, "dnsop@ietf.org" <dnsop@ietf.org> Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions
>Agreed, I don't think that the protocol should prescribe what to do in case of >"operational error". Differentiating an "operational error" from an actual >malicious interference is very likely going to be a slippery slope. Diagnosis is much more difficult than detecting symptoms, so attempting to differentiate between errors and attacks is bound to be difficult, whether for a human operator or an automated script. >That being said, I think it will be useful for adoption that resolvers provide >a feature to use DELEG and fallback to NS when things are not correct. This is >not something that is to be part of the protocol though. > >What I see could be useful is if we could signal something alike the qualifier >in SPF [0]. This way an operator could onboard their zone into DELEG in >"testing mode", allowing them to enable DELEG with the comfort of falling back >to NS, build confidence and flip the switch. This could have the side effect >of ever having DELEG delegations in "testing mode" though. > >[0] https://www.spf-record.com/syntax >[spf-record.com]<https://urldefense.com/v3/__https:/www.spf-record.com/syntax__;!!PtGJab4!7-se9JpiApxa27fExN-OEjA6EzLuBcOZbd_mdZzmpomrgI-WDlfPK2AD5H44ShDGlaNg4ZBij6vlPDNABueEukjk$> We do need to recognize that one barrier to operator adoption is the risk of taking that first step, hence whatever is defined needs to address that. When it comes to DELEG vs. NS, I don’t see the “fallback to NS” as a downgrade attack. The design of the transition shouldn’t think of a “fallback” as that but just as a transition mechanism. The receiver, though, should be able to know when it should be able to get more information that might be in a DELEG record - setting expectations. If a receiver builds the expectation of getting a DELEG and a needed piece of information to set up a more secured (encrypted?) channel, but can’t get that information, whether the receiver gives up or goes the old route is not part of DELEG, it’s part of the context the receiver is operating within. I don’t think the DNS is capable of supporting any notion that a receiver will get the information that they ought to receive. DNSSEC is about validating what you receive, not ensuring the data gets through. In fact, no system can guarantee delivery - your “wires” may be yanked before the signals come back. Trying to overcome this would … consume an eternity of research budgets.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
