Re: [DNSOP] Encourage by the operator ... Re: [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions
On 2/9/24, 11:02, "pch-b538d2...@u-1.phicoh.com on behalf of Philip Homburg" wrote: > One of the misconceptions in DNSSEC is that the zone administrator > is in control of the situation, dictating the state of signing, > the cryptography in use, and so on. DNSSEC is for the benefit of > the querier, not the responder. A zone administrator can't force > a querier to validate the results, it can't dictate what cryptographic > library support the receiver must have. I don't see how this statement is relevant. This was the text that made me react: # If DELEG is mainly used to signal that a secure transport, such as DoT, DoH, # or DoQ, is available then falling back to NS/DS might be preferred (by the # zone operator) over failure. ...specifically, " then falling back to NS/DS might be ***preferred (by the zone operator)***"... We need to approach the design with the knowledge that the querier is in the driver's seat, it is up to the querier to decide whether to fall back, or not, in any way. The zone operator (the responder) can only present options to the querier (here), not dictate (that's too strong a word) or encourage (a bit softer) or influence (yet milder) how the querier will "act next". It's the querier's prerogative to choose whether they fall back and how, and what privacy enhancement they crave (judging this being a concern by the inclusion of DoT and DoH in the context), not the responder's. I'm not picking on fall back, or privacy - I'm picking on the process of how we design the protocol. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Encourage by the operator ... Re: [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions
> One of the misconceptions in DNSSEC is that the zone administrator > is in control of the situation, dictating the state of signing, > the cryptography in use, and so on. DNSSEC is for the benefit of > the querier, not the responder. A zone administrator can't force > a querier to validate the results, it can't dictate what cryptographic > library support the receiver must have. I don't see how this statement is relevant. The discussion was about possible downgrade attacks if the querier would fallback to NS/DS. Given that we are talking about downgrade attacks, there is already the implicit assumption that the querier is interested in the integrity of the reply. The zone administrator can assist the queriers with making an informed decision, if the protocol allows for extra informaiton to be passed. > The zone administrator is out there in plain > sight, anyone can see the data, anyone can see activity. One can't > (always) identify the receiver, that's what the privacy-enhancing > transports support. With TLS a lot of classical assumptions can change. With emphasis on *can*. For example, client could use TLS to authenticate themselves, the transferred data could be kept confidential. People could take DNS in unexpected directions. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Encourage by the operator ... Re: [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions
On 2/8/24, 09:25, "DNSOP on behalf of Philip Homburg" wrote: >whether fallback to NS/DS is encouraged by the operator of the zone. > >If DELEG is mainly used to signal that a secure transport, such as DoT, DoH, >or DoQ, is available then falling back to NS/DS might be preferred (by the >zone operator) over failure. One of the misconceptions in DNSSEC is that the zone administrator is in control of the situation, dictating the state of signing, the cryptography in use, and so on. DNSSEC is for the benefit of the querier, not the responder. A zone administrator can't force a querier to validate the results, it can't dictate what cryptographic library support the receiver must have. Whatever a zone administrator publishes in a zone on a name server is open to the world, although NSEC3 hashing does help to stem, to some extent, abusive mining of what is published. All choices of how to proceed are made by the recipient. I mention this as a precursor to DELEG design. A zone administrator isn't the beneficiary of secured transports, the receiver is. (The zone administrator already has the data - no need for transporting it.) It is the receiver's choice to attempt to look something up with any receiver-set expectation of privacy, it is the receiver's choice to lower that expectation if it can't be met. The zone administrator is out there in plain sight, anyone can see the data, anyone can see activity. One can't (always) identify the receiver, that's what the privacy-enhancing transports support. A zone administrator may elect to not make data within a zone available via NS/DS delegation, a zone administrator may elect to support only certain transports, akin to only supporting IPv6 but not offering IPv4. The zone administrator does not direct how any fallback happens. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
