Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
On Jun 7, 2023, at 1:05 AM, Philip Homburg wrote: > >> We still have time to add those known operational considerations. >> In fact, we should be listing those even if this is an experimental >> RFC. > > The experiment could just be to gain operational experience. We can be upfront > that we don't know what will happen, and encourage people to be careful. That's true with every new protocol from the IETF. It would be good to understand what is different about this protocol for such an experiment. >> If so, they are not following the draft: >> >> An authoritative server implementing DoT or DoQ MUST authoritatively >> serve the same zones over all supported transports. If both DoT >> and DoQ are offered, a nameserver's reply to a particular query >> MUST be the same on both transports (with the possible exception >> of how the TC bit is set). >> >> Which authoritative servers are serving different content on 853, >> and what are the differences? We should certainly discuss that in >> the draft. > > Of course they are not following this draft. After all this is just a draft. > They are following RFC 7858 (DoT) and are running a recursive resolver on > this port. Serving from port 853 in RFC 7858 (DoT) only applies to the client-facing side of recursive resolvers. It doesn't apply to authoritative servers at all. > I don't know if they also have a recursor on port 53, that is very > well possible. The problem is that they have an authoritative on 53 but not > on 853. > > The problem is that this draft is essentially updating RFC 7858 without > explicitly doing so. It is not updating RFC 7858 at all. RFC 7858 explicitly applies to the stub resolver and the client-facing side of recursive resolvers. This draft applies to the server-facing side of recursive resolvers and authoritative server. There is zero overlap. >From your response above, I take it that you don't have any examples of >authoritative servers already serving on port 853. Please let me know if >that's wrong; if so, please give at least one example. >> How to reach them: no idea. How to deal with that: it's prohibited >> with MUST-level language. > > The obvious 'solution' is to move this draft to a new port, because 853 is > already in use for other traffic. That was discussed in the WG, and rejected. > Just adding a MUST that is in conflict with current practice makes for a poor > standard. If the problem is small, then experimental is fine and we can > start telling people that they have to stop doing this. Again, you haven't shown any current practice of authoritative servers serving on port 853. If you can show that, it would very helpful. > >> Are you talking about authoritative servers or the client-facing >> side of recursive resolvers? If the latter, that's very clearly >> out of scope for this document (or any document other than the DoT >> spec). But if it authoritative servers doing something else on 853, >> we should certainly cover it. > > Yes, I'm talking about recursive. And that's why I said, the operational > aspects are not sufficiently discussed. Marking recursive out of scope does > not help when other recursive resolvers connect to such servers. This is unclear. If a recursive resolver has an NS record with addresses, when would those addresses ever be the client-facing side of a different resolver? >> If you have suggestions for what more could be said, we'd be happy >> to add them. Note that the DNS traffic will not automatically switch >> to TLS or QUIC: probe traffic will increase. The DNS traffic will >> only switch if the authoritative server operators turn on the >> service. The increase in probe traffic is covered throughout the >> document, but if you think that adding more in a particular place >> would help reduce negative impacts, please say where and we can >> add it. > > No, I'm saying it should be experimental because we don't know and should > experiment. Please be specific about what we don't know so that we can be specific in the draft. > >> I don't understand this. All security protocols are optional. The >> existence of this draft, when it becomes an RFC, does not force >> any client to use it, just as no resolver is forced to set the DO >> bit on queries and then interpret the DNSSEC material in the >> responses. > > Usually, if you say you implement a security standard, it should actually be > secure if you follow the standard. It is a bad security standard, if the > standard says that you can stop being secure if you are overloaded. That > only leads to problems later on. > > What if TLS would say that you can stop encrypting data if you get overloaded. > People would get very upset. Ah, OK. You are asking for the non-opportunistic version of this protocol, with authenticated probing and never falling back to using Do53. The WG was not able to get any traction on that idea, despite many attempts. > >> Yep, that's what we are discussing. What criteria
Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
Hi Paul, On second read, it is better if I address the whole section. The more correct version of the changes is the following: Text in "4.6.2. Receiving a Response over Do53" could change FROM -- If Q is not in Do53-queries[X]: Process it no further (do not respond to a cleartext response to a query that is not outstanding) Otherwise: Remove Q from Do53-queries[X] If R is successful: If Q is in Do53-queries[X]: R is further processed by the resolver For each supported encrypted transport E: If Q is in E-queries[X]: Proceed to the steps in Section 4.6.9 But if R is unsuccessful (e.g. timeout or connection closed): if Q is not in any of *-queries[X]: Return SERVFAIL to the client -- TO -- If Q is not in Do53-queries[X]: Discard R and process it no further (do not respond to a cleartext response to a query that is not outstanding) Otherwise: Remove Q from Do53-queries[X] If Q is already processed: Discard R and process it no further If R is successful: If Q is in Do53-queries[X]: R is further processed by the resolver For each supported encrypted transport E: If Q is in E-queries[X]: Mark Q as already processed But if R is unsuccessful (e.g. timeout or connection closed): if Q is not in any of *-queries[X]: Return SERVFAIL to the client -- Text in "4.6.9. Receiving a Response over Encrypted Transport" could change FROM -- If Q is not in E-queries[X]: Discard R and process it no further (do not respond to an encrypted response to a query that is not outstanding) Otherwise: Remove Q from E-queries[X] Set E-last-activity[X] to T5 Set E-last-response[X] to T5 If R is successful: R is further processed by the resolver For each supported encrypted transport N other than E: If Q is in N-queries[X]: Remove Q from N-queries[X] If Q is in Do53-queries[X]: Remove Q from Do53-queries[X] But if R is unsuccessful (e.g. timeout or connection closed): If Q is not in Do53-queries[X] or in any of *-queries[X]: Return SERVFAIL to the requesting client -- TO -- If Q is not in E-queries[X]: Discard R and process it no further (do not respond to an encrypted response to a query that is not outstanding) Otherwise: Remove Q from E-queries[X] Set E-last-activity[X] to T5 Set E-last-response[X] to T5 If Q is already processed: Discard R and process it no further If R is successful: R is further processed by the resolver For each supported encrypted transport N other than E: If Q is in N-queries[X]: Mark Q as already processed If Q is in Do53-queries[X]: Mark Q as already processed But if R is unsuccessful (e.g. timeout or connection closed): If Q is not in Do53-queries[X] or in any of *-queries[X]: Return SERVFAIL to the requesting client -- Best regards, -- Yorgos On 07/06/2023 13:52, George (Yorgos) Thessalonikefs wrote: Hi all, As for the experimental/standard discussion I have a maybe naive observation, but if this draft is experimental and the experiment succeeds (whatever succeeds means, in my view gathering useful operational experience and paving the road for DoT/DoQ on authoritatives) I don't expect this to become a standard afterwards. If the experiment succeeds and we know how to run authoritatives with encryption and that the world will not end, I expect the standard following this document to be about explicitly signaling support and thus adhering to the security/privacy aspect of encryption. (I see now that this is more or less what Philip also said earlier) On 05/06/2023 21:31, Paul Hoffman wrote: > We have turned in -07, which covers Yorgos' issues (thanks!) and the int-dir review (thanks!). We believe it is ready to move to IETF Review. > > --Paul Hoffman Paul, Thanks for addressing this but I do believe this is not quite right yet. It may even be more confusing now since when a Do53 answer is received, the resolver proceeds to act as if an encrypted answer was also received. Maybe a better approach are the following changes: Text in "4.6.2. Receiving a Response over Do53" could change FROM -- If R is successful: If Q is in Do53-queries[X]: R is further processed by the resolver For each supported encrypted transport E: If Q is in E-queries[X]: Proceed to the steps in Section 4.6.9 -- TO
Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
On Jun 6, 2023, at 8:42 PM, Rob Sayre wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, Jun 6, 2023 at 11:23 AM Hollenbeck, Scott mailto:40verisign@dmarc.ietf.org>> wrote: Measurement of CPU and memory use between Do53 and DoT or DoQ. Measurement of query response rates between Do53 and DoT or DoQ. Measurement of server authentication successes and failures. Measurement and descriptions of observed attack traffic, if any. Hi, I don't think this kind of argument is reasonable. Just let them propose a standard. There is nothing requiring anyone to implement it, as the IETF has no enforcement function. [SAH] It would be unreasonable if we were discussing a proposal that had no impact on root and TLD name servers. Under some conditions, this proposal can affect their ability to perform their primary function of responding to DNS queries. Those conditions need to be understood. Additionally, some of the operators of those services are subject to regulators who commonly require them to implement, deploy, and operate IETF standards. That’s another good reason to do our best to understand the operational impact before this becomes a proposed standard. Scott ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
Hi all, As for the experimental/standard discussion I have a maybe naive observation, but if this draft is experimental and the experiment succeeds (whatever succeeds means, in my view gathering useful operational experience and paving the road for DoT/DoQ on authoritatives) I don't expect this to become a standard afterwards. If the experiment succeeds and we know how to run authoritatives with encryption and that the world will not end, I expect the standard following this document to be about explicitly signaling support and thus adhering to the security/privacy aspect of encryption. (I see now that this is more or less what Philip also said earlier) On 05/06/2023 21:31, Paul Hoffman wrote: > We have turned in -07, which covers Yorgos' issues (thanks!) and the int-dir review (thanks!). We believe it is ready to move to IETF Review. > > --Paul Hoffman Paul, Thanks for addressing this but I do believe this is not quite right yet. It may even be more confusing now since when a Do53 answer is received, the resolver proceeds to act as if an encrypted answer was also received. Maybe a better approach are the following changes: Text in "4.6.2. Receiving a Response over Do53" could change FROM -- If R is successful: If Q is in Do53-queries[X]: R is further processed by the resolver For each supported encrypted transport E: If Q is in E-queries[X]: Proceed to the steps in Section 4.6.9 -- TO -- If R is successful and Q is not already processed: If Q is in Do53-queries[X]: R is further processed by the resolver For each supported encrypted transport E: If Q is in E-queries[X]: Mark Q as already processed -- Text in "4.6.9. Receiving a Response over Encrypted Transport" could change FROM -- If Q is not in E-queries[X]: Discard R and process it no further (do not respond to an encrypted response to a query that is not outstanding) Otherwise: Remove Q from E-queries[X] Set E-last-activity[X] to T5 Set E-last-response[X] to T5 If R is successful: R is further processed by the resolver For each supported encrypted transport N other than E: If Q is in N-queries[X]: Remove Q from N-queries[X] If Q is in Do53-queries[X]: Remove Q from Do53-queries[X] -- TO -- If Q is not in E-queries[X]: Discard R and process it no further (do not respond to an encrypted response to a query that is not outstanding) Otherwise: Remove Q from E-queries[X] Set E-last-activity[X] to T5 Set E-last-response[X] to T5 If R is successful and Q is not already processed: R is further processed by the resolver For each supported encrypted transport N other than E: If Q is in N-queries[X]: Mark Q as already processed If Q is in Do53-queries[X]: Mark Q as already processed -- These changes add an extra step of marking the waiting query as already processed by another transport reply, so the resolver can do the necessary bookkeeping for the current transport (if any) and ignore the "late" reply from the current transport. Best regards, -- Yorgos ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
> We still have time to add those known operational considerations. > In fact, we should be listing those even if this is an experimental > RFC. The experiment could just be to gain operational experience. We can be upfront that we don't know what will happen, and encourage people to be careful. > If so, they are not following the draft: > > An authoritative server implementing DoT or DoQ MUST authoritatively > serve the same zones over all supported transports. If both DoT > and DoQ are offered, a nameserver's reply to a particular query > MUST be the same on both transports (with the possible exception > of how the TC bit is set). > > Which authoritative servers are serving different content on 853, > and what are the differences? We should certainly discuss that in > the draft. Of course they are not following this draft. After all this is just a draft. They are following RFC 7858 (DoT) and are running a recursive resolver on this port. I don't know if they also have a recursor on port 53, that is very well possible. The problem is that they have an authoritative on 53 but not on 853. The problem is that this draft is essentially updating RFC 7858 without explicitly doing so. > How to reach them: no idea. How to deal with that: it's prohibited > with MUST-level language. The obvious 'solution' is to move this draft to a new port, because 853 is already in use for other traffic. Just adding a MUST that is in conflict with current practice makes for a poor standard. If the problem is small, then experimental is fine and we can start telling people that they have to stop doing this. > Are you talking about authoritative servers or the client-facing > side of recursive resolvers? If the latter, that's very clearly > out of scope for this document (or any document other than the DoT > spec). But if it authoritative servers doing something else on 853, > we should certainly cover it. Yes, I'm talking about recursive. And that's why I said, the operational aspects are not sufficiently discussed. Marking recursive out of scope does not help when other recursive resolvers connect to such servers. > If you have suggestions for what more could be said, we'd be happy > to add them. Note that the DNS traffic will not automatically switch > to TLS or QUIC: probe traffic will increase. The DNS traffic will > only switch if the authoritative server operators turn on the > service. The increase in probe traffic is covered throughout the > document, but if you think that adding more in a particular place > would help reduce negative impacts, please say where and we can > add it. No, I'm saying it should be experimental because we don't know and should experiment. > I don't understand this. All security protocols are optional. The > existence of this draft, when it becomes an RFC, does not force > any client to use it, just as no resolver is forced to set the DO > bit on queries and then interpret the DNSSEC material in the > responses. Usually, if you say you implement a security standard, it should actually be secure if you follow the standard. It is a bad security standard, if the standard says that you can stop being secure if you are overloaded. That only leads to problems later on. What if TLS would say that you can stop encrypting data if you get overloaded. People would get very upset. > Yep, that's what we are discussing. What criteria would you use to > determine the success of the experiment? The success of the experiement is that operational issues are documented, including operational practices and the feedback of the experiment is used in a new draft that is intended to become a standard. >From https://www.ietf.org/standards/process/informational-vs-experimental/ "If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental. This is the typical case of not being able to decide which protocol is "better" before we have experience of dealing with them from a stable specification. Case in point: "PGM Reliable Transport Protocol Specification" (RFC 3208)" So I think it best to no longer delay this draft, publish it as experimental and gain experience in how this actually works. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
