Manu and I have now published a draft describing this "testing" flag: https://datatracker.ietf.org/doc/draft-manuben-svcb-testing-flag/
While we think this is relevant to DELEG, it is entirely independent and could be used in any SVCB setting (although it doesn't have any obvious utility for HTTPS records at present). --Ben Schwartz ________________________________ From: Manu Bretelle <chan...@gmail.com> Sent: Wednesday, February 7, 2024 2:19 PM 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 On Thu, Feb 1, 2024 at 4: 49 AM Peter Thomassen <peter@ desec. io> wrote: On 2/1/24 13: 34, Edward Lewis wrote: > The proper response will depend on the reason - more accurately the presumed (lacking any out-of-band signals) reason - why ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd On Thu, Feb 1, 2024 at 4:49 AM Peter Thomassen <pe...@desec.io<mailto:pe...@desec.io>> wrote: On 2/1/24 13:34, Edward Lewis wrote: > The proper response will depend on the reason - more accurately the presumed > (lacking any out-of-band signals) reason - why the record is absent. Barring any other information, the proper response should IMHO not depend on the presumed reason, but assume the worst case. Anything else would break expected security guarantees. 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. 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<https://www.spf-record.com/syntax> Manu > From observations of the deployment of DNSSEC, [...] > 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. That latter sentence seems right to me, but it doesn't follow that the protocol needs to tolerate "benign operational mistakes". Another approach would be to accompany protocol deployment with a suitable set of automation tools, so that the chance of operational mistakes goes down. That would be my main take-away from DNSSEC observations. In other words, perhaps we should consider a protocol incomplete if the spec doesn't easily accommodate automation and deployment without it would yield significant operational risk. Let's try to include automation aspects from the beginning. Peter -- https://desec.io/<https://desec.io/> _______________________________________________ DNSOP mailing list DNSOP@ietf.org<mailto:DNSOP@ietf.org> https://www.ietf.org/mailman/listinfo/dnsop<https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
