Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
Hi Eric, Same as what Paul said. Thank you Original message From: Paul Hoffman Date: 7/17/23 6:49 AM (GMT-08:00) To: "Eric Vyncke (evyncke)" Cc: d...@fifthhorseman.net, Joey Salazar , Brian Haberman , dns-privacy@ietf.org Subject: Re: [Ext] [dns-privacy] WGLC : draft-ietf-dprive-unilateral-probing On Jul 17, 2023, at 2:59 AM, Eric Vyncke (evyncke) wrote:> > Daniel, Joey, Paul,> > As I am doing my AD review, may I check with the 3 authors whether they are aware of any IPR behind the one cited by Brian below ?> > Thanks, in advance,I responded to the chairs that I didn't know of any IPR on the draft. I make no assertion whether or not the Verisign IPR even applies to the draft.--Paul Hoffman___ 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
On Jul 17, 2023, at 2:59 AM, Eric Vyncke (evyncke) wrote: > > Daniel, Joey, Paul, > > As I am doing my AD review, may I check with the 3 authors whether they are > aware of any IPR behind the one cited by Brian below ? > > Thanks, in advance, I responded to the chairs that I didn't know of any IPR on the draft. I make no assertion whether or not the Verisign IPR even applies to the draft. --Paul Hoffman ___ 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
On Jun 30, 2023, at 9:08 AM, Florian Obser wrote: > > A recursive resolver implementing this draft will probe on 853 without > RD set. ns1.example.com will respond with refused. The recursive > resolver will answer SERVFAIL. > > At least that's how I'm reading 4.6.9. R is successful, (it's not a > timeout or connection closed), so we do this: > > If R is successful: > > * R is further processed by the resolver > > Well, the resolver got REFUSED and there are no more NS to try. It can > only answer SERVFAIL. Therefore example.com is no longer resolvable. > > This draft breaks a valid configuration that has been working since > 2016. That's why I'm saying that a recursive resolver while probing MUST > be prepared to encounter open resolvers on 853 and not assume that > that's a successful probe. Thank you for staying in with me on this; I now understand the problem you are describing and agree that with the current text, it will cause undesired failures. The current wording at the end of 4.6.9 is: But if `R` is unsuccessful (e.g. timeout or connection closed): I believe that changing that to the following would fix the problem you describe: But if `R` is unsuccessful (RCODE other than 0, timeout, connection closed): Does that fix your case and not break other cases? --Paul Hoffman ___ 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
Apologise for the late response, I'm slowly working through a huge pile of emails. On 2023-06-24 22:17 UTC, Paul Hoffman wrote: > On Jun 14, 2023, at 10:08 AM, Florian Obser wrote: >> >> On 2023-06-12 19:48 UTC, Paul Hoffman wrote: >>> On Jun 12, 2023, at 1:46 AM, Florian Obser wrote: On 2023-06-10 22:48 UTC, Paul Hoffman wrote: > On Jun 10, 2023, at 1:38 PM, Philip Homburg > wrote: >> >>> In such a case, resolvers following >>> this protocol will look for authoritative answers to ports 53 and >>> 853 on that system, and the system would need to be able to >>> differentiate queries for recursive answers from queries for >>> authoritative answers. I think this needs some MUST requirements because it's an interop problem. >>> >>> Please say more. Would this be MUST requirements on resolvers, auth >>> servers, or both? What requirements would you suggest? >>> >> >> It's on the recursive resolvers. People have been happily providing open >> resolvers using DoT on port 853. Now a new standard comes out that is >> OPTIONAL for auths and OPTIONAL for recursive resolvers that still >> changes what auths and recursive resolvers are allowed to do. >> >> "Recursive resolvers when implementing this protocol MUST ignore answers >> from recursive resolvers on port 853." >> >> Clearly this needs word smithing. > > Maybe I'm being dense, but I'm not sure how this differs at all from > today on port 53. If someone lists 9.9.9.9 as authoritative for > fournines.com, and a recursive resolver queries it, doesn't it have > *exactly* the same problem as you are saying this document creates for > port 853? > Yes, but that's not what I'm suggesting. Let me try again. Say I have example.com NS ns1.example.com ns1.example.com A 192.0.2.53 ns1.example.com is answering authoritatively for example.com on udp/53 and tcp/53 since November 1987. All recursive resolvers are happy. Come May 2016, RFC 7858 tells me I can run a recursive resolver on port 853 using TLS. I decide to run an open DoT resolver and since I'm out of IPv4 I run this on 192.0.2.53 port 853. Still, all recursive resolvers are happy. They never talk to port 853 and they get authoritative answers on udp/53 and tcp/53. example.com is still resolvable. Stub resolvers are also happy, they use my open DoT resolver and ask for anything with RD flag set, so they get an answer. Now this draft comes along. I do nothing on ns1.example.com. The draft says unilateral and it says it's OPTIONAL for authoritative servers. A recursive resolver implementing this draft will probe on 853 without RD set. ns1.example.com will respond with refused. The recursive resolver will answer SERVFAIL. At least that's how I'm reading 4.6.9. R is successful, (it's not a timeout or connection closed), so we do this: If R is successful: * R is further processed by the resolver Well, the resolver got REFUSED and there are no more NS to try. It can only answer SERVFAIL. Therefore example.com is no longer resolvable. This draft breaks a valid configuration that has been working since 2016. That's why I'm saying that a recursive resolver while probing MUST be prepared to encounter open resolvers on 853 and not assume that that's a successful probe. -- In my defence, I have been left unsupervised. ___ 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
On Jun 14, 2023, at 10:08 AM, Florian Obser wrote: > > On 2023-06-12 19:48 UTC, Paul Hoffman wrote: >> On Jun 12, 2023, at 1:46 AM, Florian Obser wrote: >>> >>> On 2023-06-10 22:48 UTC, Paul Hoffman wrote: On Jun 10, 2023, at 1:38 PM, Philip Homburg wrote: > >> In such a case, resolvers following >> this protocol will look for authoritative answers to ports 53 and >> 853 on that system, and the system would need to be able to >> differentiate queries for recursive answers from queries for >> authoritative answers. >>> >>> I think this needs some MUST requirements because it's an interop >>> problem. >> >> Please say more. Would this be MUST requirements on resolvers, auth servers, >> or both? What requirements would you suggest? >> > > It's on the recursive resolvers. People have been happily providing open > resolvers using DoT on port 853. Now a new standard comes out that is > OPTIONAL for auths and OPTIONAL for recursive resolvers that still > changes what auths and recursive resolvers are allowed to do. > > "Recursive resolvers when implementing this protocol MUST ignore answers > from recursive resolvers on port 853." > > Clearly this needs word smithing. Maybe I'm being dense, but I'm not sure how this differs at all from today on port 53. If someone lists 9.9.9.9 as authoritative for fournines.com, and a recursive resolver queries it, doesn't it have *exactly* the same problem as you are saying this document creates for port 853? >>> An issue with the draft is that it never specifies explicitly >>> what a successful or unsuccessful probe is. My reading is that it >>> decides successful / unsuccessful on the transport layer. E.g. when it >>> can talk TLS to *something* on port 853 that's a success. Nevermind what >>> that something is. >> >> Yes. The document says (in Section 4.6.4) "When an encrypted transport >> connection actually completes (e.g., the TLS handshake completes)...". >> >> How would you change that? I don't think "and it responded to a DNS >> query" will help much, because your concern seems to be a system that >> is responding to both recursive and authoritative queries on 853. How >> can this be clarified for your issue? > > No, that's not my issue, that's clearly broken. My issue is a system > that answers authoritatively for some queries on Do53 (and REFUSED > otherwise). And answers to all recursive queries on 853, like the > ns1.eu.org example. The algorithm will just think that ns1.eu.org is > lame. But it's not, it is currently a perfectly valid setup. It answers > correctly on 53. The problem is that this draft changes what it is > required to do on 853. See above. I don't see where this draft changes what happens on port 853 any more than it does on port 53. The wording here is no different than saying that the unencrypted transpor connection completes for TCP when the SYN-ACK comes back. (Yes, there is no "transport connection" for UDP.) > > For lack of a better term, I use the word 'lame' here: > > If, during probing, a recursive resolver decides that the authoritative > server on port 853 is 'lame', then the recursive resolver should fall back > to port 53. The feeling that I got from the other messages is that the server on 853 is not lame: it is being authoritative for some names and recursive for all others. If so, it's not lame at all. >>> >>> ns1.eu.org is authoritative for eu.org: >>> $ dig +norec +noall +comments @ns1.eu.org eu.org NS >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54105 >>> ;; flags: qr aa; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5 >>> >>> The DoT recursive resolver refuses to talk to as when we turn of RD: >>> $ dig +tls +norec +noall +comments @ns1.eu.org eu.org NS >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9454 >>> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >>> >>> It is happy to give us a recursive answer though, heck, it's even DNSSEC >>> validated: >>> $ dig +tls +noall +comments @ns1.eu.org eu.org NS >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48894 >>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5 >>> >>> >>> From the PoV of the draft (as it currently stands) the DoT probe is >>> successful, because something responded to us. >> >> There is a long and indecisive (so far!) discussion in DNSOP about what >> is "lame". I would agree with you that this qualifies as lame: it is >> supposed to give an authoritative response but instead gives a >> non-authoritative one. >> > > It's worse, it answers refused. So what we currently have in > the draft will lead to the recursive resolver answering refused. Because > it is a successful response. Right. If someone says "that server is authoritative for this name", and that server is a recursive resolver that will answer REFUSED
Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
On 2023-06-12 19:48 UTC, Paul Hoffman wrote: > On Jun 12, 2023, at 1:46 AM, Florian Obser wrote: >> >> On 2023-06-10 22:48 UTC, Paul Hoffman wrote: >>> On Jun 10, 2023, at 1:38 PM, Philip Homburg >>> wrote: > In such a case, resolvers following > this protocol will look for authoritative answers to ports 53 and > 853 on that system, and the system would need to be able to > differentiate queries for recursive answers from queries for > authoritative answers. >> >> I think this needs some MUST requirements because it's an interop >> problem. > > Please say more. Would this be MUST requirements on resolvers, auth servers, > or both? What requirements would you suggest? > It's on the recursive resolvers. People have been happily providing open resolvers using DoT on port 853. Now a new standard comes out that is OPTIONAL for auths and OPTIONAL for recursive resolvers that still changes what auths and recursive resolvers are allowed to do. "Recursive resolvers when implementing this protocol MUST ignore answers from recursive resolvers on port 853." Clearly this needs word smithing. >> An issue with the draft is that it never specifies explicitly >> what a successful or unsuccessful probe is. My reading is that it >> decides successful / unsuccessful on the transport layer. E.g. when it >> can talk TLS to *something* on port 853 that's a success. Nevermind what >> that something is. > > Yes. The document says (in Section 4.6.4) "When an encrypted transport > connection actually completes (e.g., the TLS handshake completes)...". > > How would you change that? I don't think "and it responded to a DNS > query" will help much, because your concern seems to be a system that > is responding to both recursive and authoritative queries on 853. How > can this be clarified for your issue? No, that's not my issue, that's clearly broken. My issue is a system that answers authoritatively for some queries on Do53 (and REFUSED otherwise). And answers to all recursive queries on 853, like the ns1.eu.org example. The algorithm will just think that ns1.eu.org is lame. But it's not, it is currently a perfectly valid setup. It answers correctly on 53. The problem is that this draft changes what it is required to do on 853. > For lack of a better term, I use the word 'lame' here: If, during probing, a recursive resolver decides that the authoritative server on port 853 is 'lame', then the recursive resolver should fall back to port 53. >>> >>> The feeling that I got from the other messages is that the server on >>> 853 is not lame: it is being authoritative for some names and >>> recursive for all others. If so, it's not lame at all. >> >> ns1.eu.org is authoritative for eu.org: >> $ dig +norec +noall +comments @ns1.eu.org eu.org NS >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54105 >> ;; flags: qr aa; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5 >> >> The DoT recursive resolver refuses to talk to as when we turn of RD: >> $ dig +tls +norec +noall +comments @ns1.eu.org eu.org NS >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9454 >> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> It is happy to give us a recursive answer though, heck, it's even DNSSEC >> validated: >> $ dig +tls +noall +comments @ns1.eu.org eu.org NS >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48894 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5 >> >> >> From the PoV of the draft (as it currently stands) the DoT probe is >> successful, because something responded to us. > > There is a long and indecisive (so far!) discussion in DNSOP about what > is "lame". I would agree with you that this qualifies as lame: it is supposed > to give an authoritative response but instead gives a non-authoritative one. > It's worse, it answers refused. So what we currently have in the draft will lead to the recursive resolver answering refused. Because it is a successful response. > I think what you are talking about here is Section 4.6.9, the end of which > currently says: >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 > > Would the following cover your issue? I think so. I would love to hear from recursive resolver implementers though. But I need to go through the full section 4 again. Also for the dnsdir review. >But if R is unsuccessful (e.g. a non-authoritative answer, or is a timeout > or connection closed): > >* If Q is in Do53-queries[X] or in any of *-queries[X]: > > - set E-session[X] to null > > - set E-status[X] to fail > > - set E-completed[X] to T2 > > >* Otherwise: > > - Return SERVFAIL to the requesting client > > --Paul Hoffman > Florian -- In my
Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
On Jun 12, 2023, at 1:46 AM, Florian Obser wrote: > > On 2023-06-10 22:48 UTC, Paul Hoffman wrote: >> On Jun 10, 2023, at 1:38 PM, Philip Homburg >> wrote: >>> In such a case, resolvers following this protocol will look for authoritative answers to ports 53 and 853 on that system, and the system would need to be able to differentiate queries for recursive answers from queries for authoritative answers. > > I think this needs some MUST requirements because it's an interop > problem. Please say more. Would this be MUST requirements on resolvers, auth servers, or both? What requirements would you suggest? > An issue with the draft is that it never specifies explicitly > what a successful or unsuccessful probe is. My reading is that it > decides successful / unsuccessful on the transport layer. E.g. when it > can talk TLS to *something* on port 853 that's a success. Nevermind what > that something is. Yes. The document says (in Section 4.6.4) "When an encrypted transport connection actually completes (e.g., the TLS handshake completes)...". How would you change that? I don't think "and it responded to a DNS query" will help much, because your concern seems to be a system that is responding to both recursive and authoritative queries on 853. How can this be clarified for your issue? >>> >>> For lack of a better term, I use the word 'lame' here: >>> >>> If, during probing, a recursive resolver decides that the authoritative >>> server on port 853 is 'lame', then the recursive resolver should fall back >>> to port 53. >> >> The feeling that I got from the other messages is that the server on >> 853 is not lame: it is being authoritative for some names and >> recursive for all others. If so, it's not lame at all. > > ns1.eu.org is authoritative for eu.org: > $ dig +norec +noall +comments @ns1.eu.org eu.org NS > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54105 > ;; flags: qr aa; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5 > > The DoT recursive resolver refuses to talk to as when we turn of RD: > $ dig +tls +norec +noall +comments @ns1.eu.org eu.org NS > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9454 > ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > It is happy to give us a recursive answer though, heck, it's even DNSSEC > validated: > $ dig +tls +noall +comments @ns1.eu.org eu.org NS > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48894 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5 > > > From the PoV of the draft (as it currently stands) the DoT probe is > successful, because something responded to us. There is a long and indecisive (so far!) discussion in DNSOP about what is "lame". I would agree with you that this qualifies as lame: it is supposed to give an authoritative response but instead gives a non-authoritative one. I think what you are talking about here is Section 4.6.9, the end of which currently says: 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 Would the following cover your issue? But if R is unsuccessful (e.g. a non-authoritative answer, or is a timeout or connection closed): * If Q is in Do53-queries[X] or in any of *-queries[X]: - set E-session[X] to null - set E-status[X] to fail - set E-completed[X] to T2 * Otherwise: - Return SERVFAIL to the requesting client --Paul Hoffman ___ 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
From: Tim Wicinski Sent: Friday, June 9, 2023 9:44 PM To: Hollenbeck, Scott Cc: paul.hoff...@icann.org; dns-privacy@ietf.org Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing 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. Scott On Fri, Jun 9, 2023 at 1:42 PM Hollenbeck, Scott mailto:40verisign@dmarc.ietf.org> > wrote: [SAH] We might be disagreeing on the nature of experimentation, but I most definitely provided examples of specific, measurable metrics that could be used to evaluate an experiment: https://mailarchive.ietf.org/arch/msg/dns-privacy/tA7Wo_cllWhWqjwaQTs50Ses-KI/ <https://secure-web.cisco.com/1rqB_3Wjy4E9-TRoAKzvMoQEKW0JvsNYYOhZ-0tm5cRnZFGoDRTR18vQ0zGASp68NiV85QiHyV-0-455x9gN9gqn7lzlpDlhh0B_uqky1QiwnOD7IBvzDf-lfoEk0i5V3zp7LRPGKUnEkN8xNBXZEKN7HBhIb60ugl5T5CIwKmMscyn2QTmiRv14lHcigy9x1PIvfxAtYmvnc_O7P8UfuKP6AFCz-dc02miE8k9k97LDoCSZQGhv1rV-gHjjDkbPhWSou8yDY9Eb1hzqxXPB4GoCDsQvjrBy_kRDJHcMtD4oy_101l9riAh4YoMY80f92/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdns-privacy%2FtA7Wo_cllWhWqjwaQTs50Ses-KI%2F> WRT observations, we do have a WG wiki we could use: https://wiki.ietf.org/group/dprive <https://secure-web.cisco.com/1swQEBenLfIYyHQGjOabvyt5UKR2YL-XlrbeTlAk5mvQwU1G9AQMDFYiZqLOE5P2J08xcxYnyXXLGun1EQLputcHErJXa48X3MHFUta2xDRaWwnX_go_bVHKK3yl-JQAx5uQXU7EpjT4Qn6QOhoBf3YlX7VP4AJJ6_DPcmStquK530QFGZdBdMpik3WiG0Tdj3OgCN8p6UoEa3EQlso5TeEq7Ksv8e51Pm2BAprbuuXdHHVgQnjoq0WvxtT76rlBxSWyOXjIY2DYg4lGeaPITkv1KxDMZpcOv0Y-sp-tXIc0g3fc4Vs3ed4RBD1VbwG7k/https%3A%2F%2Fwiki.ietf.org%2Fgroup%2Fdprive> Would you be able to produce some of these measurements based on experiments you run? That would be super useful. tim [SAH] I’m looking into what I can and cannot do. 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
On 2023-06-10 22:48 UTC, Paul Hoffman wrote: > On Jun 10, 2023, at 1:38 PM, Philip Homburg > wrote: >> >>> In such a case, resolvers following >>> this protocol will look for authoritative answers to ports 53 and >>> 853 on that system, and the system would need to be able to >>> differentiate queries for recursive answers from queries for >>> authoritative answers. I think this needs some MUST requirements because it's an interop problem. An issue with the draft is that it never specifies explicitly what a successful or unsuccessful probe is. My reading is that it decides successful / unsuccessful on the transport layer. E.g. when it can talk TLS to *something* on port 853 that's a success. Nevermind what that something is. >> >> For lack of a better term, I use the word 'lame' here: >> >> If, during probing, a recursive resolver decides that the authoritative >> server on port 853 is 'lame', then the recursive resolver should fall back >> to port 53. > > The feeling that I got from the other messages is that the server on > 853 is not lame: it is being authoritative for some names and > recursive for all others. If so, it's not lame at all. ns1.eu.org is authoritative for eu.org: $ dig +norec +noall +comments @ns1.eu.org eu.org NS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54105 ;; flags: qr aa; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5 The DoT recursive resolver refuses to talk to as when we turn of RD: $ dig +tls +norec +noall +comments @ns1.eu.org eu.org NS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9454 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 It is happy to give us a recursive answer though, heck, it's even DNSSEC validated: $ dig +tls +noall +comments @ns1.eu.org eu.org NS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48894 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 5 >From the PoV of the draft (as it currently stands) the DoT probe is successful, because something responded to us. > > --Paul Hoffman > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy -- In my defence, I have been left unsupervised. ___ 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
On Jun 10, 2023, at 1:38 PM, Philip Homburg wrote: > >> In such a case, resolvers following >> this protocol will look for authoritative answers to ports 53 and >> 853 on that system, and the system would need to be able to >> differentiate queries for recursive answers from queries for >> authoritative answers. > > For lack of a better term, I use the word 'lame' here: > > If, during probing, a recursive resolver decides that the authoritative > server on port 853 is 'lame', then the recursive resolver should fall back > to port 53. The feeling that I got from the other messages is that the server on 853 is not lame: it is being authoritative for some names and recursive for all others. If so, it's not lame at all. --Paul Hoffman ___ 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
> In such a case, resolvers following > this protocol will look for authoritative answers to ports 53 and > 853 on that system, and the system would need to be able to > differentiate queries for recursive answers from queries for > authoritative answers. For lack of a better term, I use the word 'lame' here: If, during probing, a recursive resolver decides that the authoritative server on port 853 is 'lame', then the recursive resolver should fall back to port 53. ___ 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
Scott On Fri, Jun 9, 2023 at 1:42 PM Hollenbeck, Scott wrote: > > > [SAH] We might be disagreeing on the nature of experimentation, but I most > definitely provided examples of specific, measurable metrics that could be > used to evaluate an experiment: > > > https://mailarchive.ietf.org/arch/msg/dns-privacy/tA7Wo_cllWhWqjwaQTs50Ses-KI/ > > WRT observations, we do have a WG wiki we could use: > > https://wiki.ietf.org/group/dprive Would you be able to produce some of these measurements based on experiments you run? That would be super useful. tim ___ 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
On Fri, Jun 9, 2023 at 3:44 PM Hollenbeck, Scott wrote: > *[SAH] The IESG deliberately chartered this working group to “Investigate > potential solutions for adding confidentiality to DNS exchanges involving > authoritative servers” in an Experimental manner. As Brian noted, that’s a > binding agreement with the IESG. We can either do that or attempt to > re-charter the working group. I’m under the impression that Brian’s last > note to the group was a request to discuss those two options, which could > include discussion of how to conduct the experiment. It’s not an ad-hoc > process at all.* > Hi, I agree that a recharter would be required. However, what you're asking for here exceeds the requirements of a Proposed Standard, so that does seem a bit ad-hoc to me. https://www.rfc-editor.org/rfc/rfc7127.html#section-3.1 In particular this paragraph applies: "The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet." > I never like to read stuff like this. Each of us probably has a regulator > that annoys us in their treatment of some issue. But we can't really make > decisions based on guesses about the future actions of unnamed regulators. > I'm also sure you know the document ladder quite well, but you've used > imprecise terms here. In the first sentence, you say "IETF standards". But > the last sentence says "proposed standard". > > > > > *[SAH] I used those terms deliberately. My employer has contractual > obligations to implement a mix of IETF-developed Proposed Standard and > Standard specifications – that is, “IETF standards”. In the last sentence, > “proposed standard” specifically refers to one possible status for this > draft.* > So, your employer has contractual obligations to implement some IETF-standards track documents. I'm still a little mystified, because I don't think anyone would sign or write such an agreement for documents not-yet-written. I figured the objection would be the typical encryption-related ones (cost, observability, etc). The sort of thing we saw with HTTP2 and DoT/DoH/DoQ. But I also originally wrote that Experimental would work here, even if the label is inaccurate. thanks, Rob ___ 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
Here is my first cut of wording for a new operational considerations section to deal with systems that are both recursive and authoritative on port 853. Comments are welcome. As recursive resolvers implement this protocol, authoritative servers will see more probing on port 853 of IP addresses that are associated with NS records. Such probing of an authoritative server should generally not cause any significant problems: if the authoritative server is not supporting this protocol, it will not respond on port 853, and if it is supporting this protocol, it will act accordingly. However, a system that is a public resolver that supports DoT and/or DoQ may also have an IP address that is associated with NS records. This could be accidental (such as a glue record with the wrong target address) or intentional. In such a case, resolvers following this protocol will look for authoritative answers to ports 53 and 853 on that system, and the system would need to be able to differentiate queries for recursive answers from queries for authoritative answers. ___ 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
> -Original Message- > From: dns-privacy On Behalf Of Paul Hoffman > Sent: Friday, June 9, 2023 10:52 AM > To: dns-privacy@ietf.org > Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : > draft-ietf-dprive-unilateral- > probing > > 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. > > I'm hearing a bit of support for the proposal of changing the WG charter, > but > more support for not changing the charter and issuing the protocol as > experimental. There have been no proposals for specific metrics for how to > judge the experiment, so it is likely to be "two years, add some operational > observations, and move it to standards track". [SAH] We might be disagreeing on the nature of experimentation, but I most definitely provided examples of specific, measurable metrics that could be used to evaluate an experiment: https://mailarchive.ietf.org/arch/msg/dns-privacy/tA7Wo_cllWhWqjwaQTs50Ses-KI/ WRT observations, we do have a WG wiki we could use: https://wiki.ietf.org/group/dprive 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
I'm hearing a bit of support for the proposal of changing the WG charter, but more support for not changing the charter and issuing the protocol as experimental. There have been no proposals for specific metrics for how to judge the experiment, so it is likely to be "two years, add some operational observations, and move it to standards track". I'll issue a new draft with the new status, and add text about recursive resolvers doing DoT and/or DoQ for stub resolvers, as well as being authoritative servers on the same address. --Paul Hoffman ___ 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
From: Rob Sayre Sent: Thursday, June 8, 2023 6:11 PM To: Hollenbeck, Scott Cc: paul.hoff...@icann.org; dns-privacy@ietf.org Subject: [EXTERNAL] Re: Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing 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 Wed, Jun 7, 2023 at 2:05 PM Hollenbeck, Scott mailto:shollenb...@verisign.com> > wrote: On Jun 6, 2023, at 8:42 PM, Rob Sayre mailto:say...@gmail.com> > wrote 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. ... [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. I think the measurements you suggest make perfect sense. I don't think there is anything in the IETF process that leads to the conclusion that this draft must be Experimental as a result, though. So, my objection is about the ad-hoc process created for this draft. I also don't get the impression that this draft would enjoy instant adoption, so there would be time to slowly ramp it up. For example, 23 years separate RFC 2616 from RFC 9112, but they are both on the standards track. [SAH] The IESG deliberately chartered this working group to “Investigate potential solutions for adding confidentiality to DNS exchanges involving authoritative servers” in an Experimental manner. As Brian noted, that’s a binding agreement with the IESG. We can either do that or attempt to re-charter the working group. I’m under the impression that Brian’s last note to the group was a request to discuss those two options, which could include discussion of how to conduct the experiment. It’s not an ad-hoc process at all. 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. I never like to read stuff like this. Each of us probably has a regulator that annoys us in their treatment of some issue. But we can't really make decisions based on guesses about the future actions of unnamed regulators. I'm also sure you know the document ladder quite well, but you've used imprecise terms here. In the first sentence, you say "IETF standards". But the last sentence says "proposed standard". [SAH] I used those terms deliberately. My employer has contractual obligations to implement a mix of IETF-developed Proposed Standard and Standard specifications – that is, “IETF standards”. In the last sentence, “proposed standard” specifically refers to one possible status for this draft. 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
On Wed, Jun 7, 2023 at 2:05 PM Hollenbeck, Scott wrote: > > On Jun 6, 2023, at 8:42 PM, Rob Sayre wrote > > On Tue, Jun 6, 2023 at 11:23 AM Hollenbeck, Scott 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. > > ... > [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. > I think the measurements you suggest make perfect sense. I don't think there is anything in the IETF process that leads to the conclusion that this draft must be Experimental as a result, though. So, my objection is about the ad-hoc process created for this draft. I also don't get the impression that this draft would enjoy instant adoption, so there would be time to slowly ramp it up. For example, 23 years separate RFC 2616 from RFC 9112, but they are both on the standards track. > 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. > I never like to read stuff like this. Each of us probably has a regulator that annoys us in their treatment of some issue. But we can't really make decisions based on guesses about the future actions of unnamed regulators. I'm also sure you know the document ladder quite well, but you've used imprecise terms here. In the first sentence, you say "IETF standards". But the last sentence says "proposed standard". thanks, Rob ___ 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
On Jun 8, 2023, at 6:07 AM, Philip Homburg wrote: > Correct. Port 853 is in use on the addresses used by some > authoritative servers to serve the role of client-facing recursive resolver. > > And that will certainly confuse any recursive resolver that tries to implement > this draft. Thank you for being specific here (and Florian for sending an excellent example for .eu). I agree that this needs to be discussed in more detail in the draft. I still don't think this makes is "experimental", but can see why you do. > Are you claiming that there is no example of this? I was; now I'm not. --Paul Hoffman ___ 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
On Jun 7, 2023, at 11:42 PM, Florian Obser wrote: > Up-thread Stéphane reported ns1.eu.org as an example. Open resolver on > 853 and authority for eu.org on 53: > > | Also, currently, regarding the possible warning to system > | administrators about the need for 53 and 853 to be in sync, we > | currently find in the wild servers that implement different services on > | the two ports. See for instance ns1.eu.org (authoritative for eu.org) > | or ns1-dyn.bortzmeyer.fr (authoritative for dyn.bortzmeyer.fr). Both > | have authoritative on 53 and an open resolver on 853. Should we > | explicitely ban this practice? Thanks for the specifics! We do explicitly ban this practice, but it is definitely also worth noting in the document that this could happen. It is definitely one of the operational considerations. I'll add this. --Paul Hoffman ___ 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
In your letter dated Wed, 7 Jun 2023 23:12:21 + you wrote: >> The experiment could just be to gain operational experience. We can be up= >front >> 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. This is certainly not for every protocols. Some protocols describe a new application domain and have no existing traffic. Other protocols are in use in some shape or form before becoming IETF standards. The question here is, do we really understand the operational implications? My answer is no. And in that case it is prudent to have an experimental protocol. Not go ahead with something that is broken, en then have a protocol with many rounds up patches, confusing future implementors for ever. >> 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. Correct. Port 853 is in use on the addresses used by some authoritative servers to serve the role of client-facing recursive resolver. And that will certainly confuse any recursive resolver that tries to implement this draft. > 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. Except that are talking about a single port. Essentially this draft is squating on a port already in use. There is overlap because some of the addresses that have the client-facing side of recursive resolvers on port 853 appear as the address of NS records. > That was discussed in the WG, and rejected. That creates a broken situation that needs to be resolved carefully. Bassicaly, a choice that makes it hard to publish this as a standard at this time. > 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 claiming that there is no example of this? > 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? Not client-facing. This draft deals with the autoritative-facing side of recursive resolvers. And an NS record is exactly what gets a recursor to connect an authoritative. > >> 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. There are known-unknowns and unknowns-unknowns. The example I gave of a client-facing recursive server on 853 that is shared with an authoritative on port 53 is a clear example of a previous unknown-unknown that just happened to become visible during testing. There is no point in trying to give a complete list of unknown-unknowns. Sitting in a chair thinking about what could happen is no substitute for real world experience. We just don't have that experience. Section 4.2.1 of RFC 2026 says this about Experimental: "The "Experimental" designation typically denotes a specification that "is part of some research or development effort. Such a specification "is published for the general information of the Internet technical "community and as an archival record of the work, subject only to "editorial considerations and to verification that there has been "adequate coordination with the standards process (see below). An "Experimental specification may be the output of an organized Internet "research effort (e.g., a Research Group of the IRTF), an IETF Working "Group, or it may be an individual contribution. Where does it say that anything needs to measured? Who came up with that requirement? It says specifically "[...] or development effort." This is actually what we are doing. We try to develop a new protocol between recursive resolvers and authoritative. We have an experimental protocol can we can use the coming time to evaluate and refine it. I'll stop here. I'm my opinion we lack the real world exprience to turn this into a standard. ___ 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
On 2023-06-07 23:12 UTC, Paul Hoffman wrote: > 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. > Up-thread Stéphane reported ns1.eu.org as an example. Open resolver on 853 and authority for eu.org on 53: | Also, currently, regarding the possible warning to system | administrators about the need for 53 and 853 to be in sync, we | currently find in the wild servers that implement different services on | the two ports. See for instance ns1.eu.org (authoritative for eu.org) | or ns1-dyn.bortzmeyer.fr (authoritative for dyn.bortzmeyer.fr). Both | have authoritative on 53 and an open resolver on 853. Should we | explicitely ban this practice? >>> 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
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
Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
On Tue, Jun 6, 2023 at 11:23 AM Hollenbeck, Scott 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. thanks, Rob ___ 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
> -Original Message- > From: Paul Hoffman > Sent: Tuesday, June 6, 2023 11:05 AM > To: Hollenbeck, Scott > Cc: dns-privacy@ietf.org > Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : > draft-ietf-dprive-unilateral- > probing > > 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 Jun 6, 2023, at 7:49 AM, Hollenbeck, Scott > wrote: > > [SAH] The criteria to conduct the experiment and measure the outcome > > could be documented in the current draft. > > Please propose such criteria. I ask because I feel that the likely criteria > (at least > one resolver implementation, one server implementation, and interop testing > between the two of them) has already been met. [SAH] I'm thinking about experimentation more in the context of measuring operational impact and not so much as a pass/fail thing. For example: 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. Even if these measurements are operator dependent, this is the kind of experimentation that every name server operator will find invaluable in terms of understanding if/how they can implement and deploy the protocol,. > Or are you saying that, if we include the criteria in the current draft, and > show > that they are met, that we can proceed on standards track without changing > the charter? [SAH] No, because the current intended status is inconsistent with the current charter. That needs to be resolved. > > From there: > > > > Publish experimental RFC. > > Conduct experiment. > > Publish RFCbis I-D to document the results of the experiment with > > informational status for failure or standards track for success. > > See above. [SAH] Noted. If we take a measurement approach, and not a pass/fail approach, we can eliminate the "fail" possibility. > > Assuming success, recharter to publish RFCbis I-D on the standards track. > > Adopt RFCbis I-D as a working group document. > > Working group works to publish RFCbis on the standards track. > > > > Paul is correct in noting that there's more IETF effort associated > > with the above. It's worth making that effort to ensure that the risks > > to critical internet infrastructure are minimized. > > How would you put that (legitimate!) concern into a criterion for the > experiment? [SAH] I'd like to see the experiment described more in terms of measurement as I've described above. It doesn't have to be categorized as pass/fail. 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
On Jun 6, 2023, at 8:06 AM, Philip Homburg wrote: > >> One large problem with publishing a protocol as "experimental" is >> there is not objective way to exit that status. There are no criteria >> that say "this experiment succeeded" or "this experiment failed". >> >> It will take much less IETF effort to fix the charter now than it >> will to move the already-deployed protocol to standards track. We >> might as well bit the bureaucratic bullet now and just fix the >> charter. If most folks agree, I can do that work. > > This draft seems fine as an experiment, but as standard, maybe there are > some operational considerations that need to be addressed. 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 first is that at the moment some people are serving different content on > port 853, from what they are serving on port 53. 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. > I can't quickly find > anything in this draft on how to reach those people or how to deal with > that. How to reach them: no idea. How to deal with that: it's prohibited with MUST-level language. > Current users of port 853 are not implementing this draft. So it > may take then considerable time to sort out this issue. 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. > If this draft becomes a standard, 'almost overnight' traffic seen by > authoritative servers may switch from almost exclusively UDP to port 53, to > TLS or QUIC to port 853. It seems that the draft is rather weak in looking at > the operational impact that could have. 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. > We also don't know much on how this affects recursive resolvers. The draft > says in Section 4.6.10: "a recursive resolver following this guidance may > also choose not to initiate new connections for encrypted transport". It > is not great to have security related standards where the implementor may or > may not implement the feature that is discussed. 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. > Maybe we should first experiment, and then create an updated document that > becomes a standard. Yep, that's what we are discussing. What criteria would you use to determine the success of the experiment? --Paul Hoffman ___ 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
> One large problem with publishing a protocol as "experimental" is > there is not objective way to exit that status. There are no criteria > that say "this experiment succeeded" or "this experiment failed". > > It will take much less IETF effort to fix the charter now than it > will to move the already-deployed protocol to standards track. We > might as well bit the bureaucratic bullet now and just fix the > charter. If most folks agree, I can do that work. This draft seems fine as an experiment, but as standard, maybe there are some operational considerations that need to be addressed. The first is that at the moment some people are serving different content on port 853, from what they are serving on port 53. I can't quickly find anything in this draft on how to reach those people or how to deal with that. Current users of port 853 are not implementing this draft. So it may take then considerable time to sort out this issue. If this draft becomes a standard, 'almost overnight' traffic seen by authoritative servers may switch from almost exclusively UDP to port 53, to TLS or QUIC to port 853. It seems that the draft is rather weak in looking at the operational impact that could have. We also don't know much on how this affects recursive resolvers. The draft says in Section 4.6.10: "a recursive resolver following this guidance may also choose not to initiate new connections for encrypted transport". It is not great to have security related standards where the implementor may or may not implement the feature that is discussed. Maybe we should first experiment, and then create an updated document that becomes a standard. ___ 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
On Jun 6, 2023, at 7:49 AM, Hollenbeck, Scott wrote: > [SAH] The criteria to conduct the experiment and measure the outcome could be > documented in the current draft. Please propose such criteria. I ask because I feel that the likely criteria (at least one resolver implementation, one server implementation, and interop testing between the two of them) has already been met. Or are you saying that, if we include the criteria in the current draft, and show that they are met, that we can proceed on standards track without changing the charter? > From there: > > Publish experimental RFC. > Conduct experiment. > Publish RFCbis I-D to document the results of the experiment with > informational status for failure or standards track for success. See above. > Assuming success, recharter to publish RFCbis I-D on the standards track. > Adopt RFCbis I-D as a working group document. > Working group works to publish RFCbis on the standards track. > > Paul is correct in noting that there's more IETF effort associated with the > above. It's worth making that effort to ensure that the risks to critical > internet infrastructure are minimized. How would you put that (legitimate!) concern into a criterion for the experiment? --Paul Hoffman ___ 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
> -Original Message- > From: dns-privacy On Behalf Of Paul Hoffman > Sent: Tuesday, June 6, 2023 9:44 AM > To: dns-privacy@ietf.org > Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : > draft-ietf-dprive-unilateral- > probing > > 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 Jun 5, 2023, at 8:12 PM, Brian Haberman > wrote: > > > > Tim & I checked in with our AD on this. Given that the charter text calls > > out > Experimental, that is a binding agreement with the IESG. > > > > Our choices are simple: > > > > 1) publish as Experimental > > 2) re-charter > > > > If the intended status had just been in the milestones, we would have more > flexibility. > > > > Let’s constructively discuss the above options. > > One large problem with publishing a protocol as "experimental" is there is > not > objective way to exit that status. There are no criteria that say "this > experiment > succeeded" or "this experiment failed". > > It will take much less IETF effort to fix the charter now than it will to > move the > already-deployed protocol to standards track. We might as well bit the > bureaucratic bullet now and just fix the charter. If most folks agree, I can > do > that work. [SAH] The criteria to conduct the experiment and measure the outcome could be documented in the current draft. From there: Publish experimental RFC. Conduct experiment. Publish RFCbis I-D to document the results of the experiment with informational status for failure or standards track for success. Assuming success, recharter to publish RFCbis I-D on the standards track. Adopt RFCbis I-D as a working group document. Working group works to publish RFCbis on the standards track. Paul is correct in noting that there's more IETF effort associated with the above. It's worth making that effort to ensure that the risks to critical internet infrastructure are minimized. 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
On Jun 5, 2023, at 8:12 PM, Brian Haberman wrote: > > Tim & I checked in with our AD on this. Given that the charter text calls out > Experimental, that is a binding agreement with the IESG. > > Our choices are simple: > > 1) publish as Experimental > 2) re-charter > > If the intended status had just been in the milestones, we would have more > flexibility. > > Let’s constructively discuss the above options. One large problem with publishing a protocol as "experimental" is there is not objective way to exit that status. There are no criteria that say "this experiment succeeded" or "this experiment failed". It will take much less IETF effort to fix the charter now than it will to move the already-deployed protocol to standards track. We might as well bit the bureaucratic bullet now and just fix the charter. If most folks agree, I can do that work. --Paul Hoffman ___ 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, I thinks it’s ok to do Experimental. If the authors care, that might be a discussion point. My perspective is that there are many worse documents that are unimplemented but that enjoy “Proposed Standard” status. thanks, Rob On Mon, Jun 5, 2023 at 20:12 Brian Haberman wrote: > Tim & I checked in with our AD on this. Given that the charter text calls > out Experimental, that is a binding agreement with the IESG. > > Our choices are simple: > > 1) publish as Experimental > 2) re-charter > > If the intended status had just been in the milestones, we would have more > flexibility. > > Let’s constructively discuss the above options. > > Regards, > Brian > > On Mon, Jun 5, 2023 at 4:53 PM Hollenbeck, Scott 40verisign@dmarc.ietf.org> wrote: > >> > -Original Message- >> > From: dns-privacy On Behalf Of Paul >> Hoffman >> > Sent: Monday, June 5, 2023 4:02 PM >> > To: Tim Wicinski >> > Cc: dns-privacy@ietf.org >> > Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : >> draft-ietf-dprive-unilateral- >> > probing >> > >> > 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 Jun 5, 2023, at 12:45 PM, Tim Wicinski wrote: >> > > The Chairs and Eric are working on the asumption that the document >> will be >> > parked waiting for another implementation or two and some interopt >> testing >> > > >> > > However, we are usinfg this time for Early area reviews which will >> feel will >> > bei invaluable moving forward. >> > > We focused on the Security area, Int Area, and those pesky DNS folks >> to >> > review the documennt >> > > >> > > I believe at IETF 117 there was some discussion of some interopt >> testing >> > during the hackathon? >> > > I may have made that up also. >> > > >> > > The authors have been working diligently updating their work, and >> Paul is just >> > letting the WG know they've done their part. >> > >> > Er, no, we really do believe that all the interop testing done at IETF >> 116, which >> > is reported in the draft, is sufficient. It is certainly more than the >> amount that >> > many other protocols get before they are published as RFCs. >> > >> > How much more interop testing is needed before the document can proceed? >> > There will be parties like Verisign that will never want this to be on >> standards >> > track, which is fine, but that has never been an acceptable reason to >> block >> > progress when there are others who have already implemented it. >> >> [SAH] To be clear: Verisign, an authoritative name server operator, is >> not opposed to this draft being on the standards track. I support >> publication in a manner that's consistent with the WG charter. I *am* >> opposed to the draft being a candidate for standards track publication as >> long as the charter says "experimental". >> >> Scott >> >> ___ >> dns-privacy mailing list >> dns-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/dns-privacy >> > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > ___ 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
Tim & I checked in with our AD on this. Given that the charter text calls out Experimental, that is a binding agreement with the IESG. Our choices are simple: 1) publish as Experimental 2) re-charter If the intended status had just been in the milestones, we would have more flexibility. Let’s constructively discuss the above options. Regards, Brian On Mon, Jun 5, 2023 at 4:53 PM Hollenbeck, Scott wrote: > > -Original Message- > > From: dns-privacy On Behalf Of Paul > Hoffman > > Sent: Monday, June 5, 2023 4:02 PM > > To: Tim Wicinski > > Cc: dns-privacy@ietf.org > > Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : > draft-ietf-dprive-unilateral- > > probing > > > > 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 Jun 5, 2023, at 12:45 PM, Tim Wicinski wrote: > > > The Chairs and Eric are working on the asumption that the document > will be > > parked waiting for another implementation or two and some interopt > testing > > > > > > However, we are usinfg this time for Early area reviews which will > feel will > > bei invaluable moving forward. > > > We focused on the Security area, Int Area, and those pesky DNS folks to > > review the documennt > > > > > > I believe at IETF 117 there was some discussion of some interopt > testing > > during the hackathon? > > > I may have made that up also. > > > > > > The authors have been working diligently updating their work, and Paul > is just > > letting the WG know they've done their part. > > > > Er, no, we really do believe that all the interop testing done at IETF > 116, which > > is reported in the draft, is sufficient. It is certainly more than the > amount that > > many other protocols get before they are published as RFCs. > > > > How much more interop testing is needed before the document can proceed? > > There will be parties like Verisign that will never want this to be on > standards > > track, which is fine, but that has never been an acceptable reason to > block > > progress when there are others who have already implemented it. > > [SAH] To be clear: Verisign, an authoritative name server operator, is not > opposed to this draft being on the standards track. I support publication > in a manner that's consistent with the WG charter. I *am* opposed to the > draft being a candidate for standards track publication as long as the > charter says "experimental". > > Scott > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > ___ 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
> -Original Message- > From: dns-privacy On Behalf Of Paul Hoffman > Sent: Monday, June 5, 2023 4:02 PM > To: Tim Wicinski > Cc: dns-privacy@ietf.org > Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : > draft-ietf-dprive-unilateral- > probing > > 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 Jun 5, 2023, at 12:45 PM, Tim Wicinski wrote: > > The Chairs and Eric are working on the asumption that the document will be > parked waiting for another implementation or two and some interopt testing > > > > However, we are usinfg this time for Early area reviews which will feel will > bei invaluable moving forward. > > We focused on the Security area, Int Area, and those pesky DNS folks to > review the documennt > > > > I believe at IETF 117 there was some discussion of some interopt testing > during the hackathon? > > I may have made that up also. > > > > The authors have been working diligently updating their work, and Paul is > > just > letting the WG know they've done their part. > > Er, no, we really do believe that all the interop testing done at IETF 116, > which > is reported in the draft, is sufficient. It is certainly more than the amount > that > many other protocols get before they are published as RFCs. > > How much more interop testing is needed before the document can proceed? > There will be parties like Verisign that will never want this to be on > standards > track, which is fine, but that has never been an acceptable reason to block > progress when there are others who have already implemented it. [SAH] To be clear: Verisign, an authoritative name server operator, is not opposed to this draft being on the standards track. I support publication in a manner that's consistent with the WG charter. I *am* opposed to the draft being a candidate for standards track publication as long as the charter says "experimental". 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
On Jun 5, 2023, at 12:45 PM, Tim Wicinski wrote: > The Chairs and Eric are working on the asumption that the document will be > parked waiting for another implementation or two and some interopt testing > > However, we are usinfg this time for Early area reviews which will feel will > bei invaluable moving forward. > We focused on the Security area, Int Area, and those pesky DNS folks to > review the documennt > > I believe at IETF 117 there was some discussion of some interopt testing > during the hackathon? > I may have made that up also. > > The authors have been working diligently updating their work, and Paul is > just letting the WG know they've done their part. Er, no, we really do believe that all the interop testing done at IETF 116, which is reported in the draft, is sufficient. It is certainly more than the amount that many other protocols get before they are published as RFCs. How much more interop testing is needed before the document can proceed? There will be parties like Verisign that will never want this to be on standards track, which is fine, but that has never been an acceptable reason to block progress when there are others who have already implemented it. --Paul Hoffman ___ 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
Scott On Mon, Jun 5, 2023 at 3:36 PM Hollenbeck, Scott wrote: > > -Original Message- > > From: dns-privacy On Behalf Of Paul > Hoffman > > Sent: Monday, June 5, 2023 3:32 PM > > To: Tim Wicinski > > Cc: dns-privacy@ietf.org > > Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : > draft-ietf-dprive-unilateral- > > probing > > > > 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. > > > > 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. > > [SAH] Please help me understand the process we're following here. I > thought that Brian said the document would be parked for a period of > experimentation time before asking for an IETF last call that commonly > precedes IESG review. > > The Chairs and Eric are working on the asumption that the document will be parked waiting for another implementation or two and some interopt testing However, we are usinfg this time for Early area reviews which will feel will bei invaluable moving forward. We focused on the Security area, Int Area, and those pesky DNS folks to review the documennt I believe at IETF 117 there was some discussion of some interopt testing during the hackathon? I may have made that up also. The authors have been working diligently updating their work, and Paul is just letting the WG know they've done their part. tim 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
> -Original Message- > From: dns-privacy On Behalf Of Paul Hoffman > Sent: Monday, June 5, 2023 3:32 PM > To: Tim Wicinski > Cc: dns-privacy@ietf.org > Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : > draft-ietf-dprive-unilateral- > probing > > 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. > > 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. [SAH] Please help me understand the process we're following here. I thought that Brian said the document would be parked for a period of experimentation time before asking for an IETF last call that commonly precedes IESG review. 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
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 ___ 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 Paul, authors, On 26/05/2023 20:00, Paul Hoffman wrote: On Apr 14, 2023, at 11:14 AM, Brian Haberman wrote: All, An update on the status of this draft. I have asked the authors to review all the feedback, provide the mailing list with responses to the comments, and then publish a new version. We believe that -06 deals with all of the WG Last Call issues raised, except one. We didn't understand "## E" in Yorgos' message from April 7. Yorgos: could you reformulate that concern based on the -06 draft? That concern remains the same. I was trying to address two different sections with the same problem at once and as a result my text was not clear enough. I will try to streamline it: 0. I assume that the query is already sent to all destinations that unilateral probing allows. 1. When a Do53 reply comes in, the following text in section "4.6.2. Receiving a Response over Do53" applies: ... If R is successful: ... For each supported encrypted transport E: If Q is in E-queries[X]: Remove Q from E-queries[X] 2. Thus Q is removed from E-queries[X] 3. When a DoQ/T reply comes in, the following text in section "4.6.9. Receiving a Response over Encrypted Transport" applies: If Q is not in E-queries[X]: Discard R and process it no further (do not respond to a 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 The result is that the metrics will not be updated for the encrypted replies, especially when we assume that Do53 replies will be faster in a probing scenario. So the first probe reply (encrypted or not) shadows the other available ones. Admittedly missing E-last-activity and E-last-response is not that serious but still feels wrong. I believe the correct approach is to always update the corresponding timers when an encrypted response is received. And a notice for "Appendix A. Early Implementations" and Unbound, the experimental implementation was more of an exploratory move to see what needs changing in Unbound for probing to happen, rather than an actual implementation. The last state of that was Unbound always working for the unhappy path ;) and falling back to Do53. I would either remove the Unbound mention altogether or note it as in experimental implementation state for DoT. 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
> -Original Message-
> From: dns-privacy On Behalf Of Paul Hoffman
> Sent: Friday, May 26, 2023 2:01 PM
> To: dns-privacy@ietf.org
> Cc: George Thessalonikefs
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC :
> draft-ietf-dprive-unilateral-
> probing
>
> 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 Apr 14, 2023, at 11:14 AM, Brian Haberman
> wrote:
> >
> > All,
> > An update on the status of this draft. I have asked the authors to
> > review all
> the feedback, provide the mailing list with responses to the comments, and
> then publish a new version.
>
> We believe that -06 deals with all of the WG Last Call issues raised, except
> one.
> We didn't understand "## E" in Yorgos' message from April 7. Yorgos: could
> you
> reformulate that concern based on the -06 draft?
[SAH] I'd like to thank the editors for the work they put into addressing the
feedback received during the last call. There is, however, one other issue I
identified that remains open: the intended status of the draft (Standards
Track) and the chartered work item associated with the draft ("Investigate
potential solutions for adding confidentiality to DNS exchanges involving
authoritative servers (Experimental)") remain inconsistent. Brian said that
"We will revisit the status of the document before it gets advanced to our AD"
when he announced the start of the last call on 12 March. In the absence of an
issue tracker for the draft, I'd like to ensure that this isn't forgotten.
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
Thanks Paul ! We've been following the gitlab updates and do like the updated version. Brian, we should change the datatracker to say "Waiting for WG Chairs go-ahead" (me bossing Brian around) tim On Fri, May 26, 2023 at 2:01 PM Paul Hoffman wrote: > On Apr 14, 2023, at 11:14 AM, Brian Haberman > wrote: > > > > All, > > An update on the status of this draft. I have asked the authors to > review all the feedback, provide the mailing list with responses to the > comments, and then publish a new version. > > We believe that -06 deals with all of the WG Last Call issues raised, > except one. We didn't understand "## E" in Yorgos' message from April 7. > Yorgos: could you reformulate that concern based on the -06 draft? > > > Thanks to everyone who has provided feedback to date! > > Indeed! The draft feels much tighter now. > > --Paul Hoffman (for Joey and dkg) > > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > ___ 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
On Apr 14, 2023, at 11:14 AM, Brian Haberman wrote: > > All, > An update on the status of this draft. I have asked the authors to review > all the feedback, provide the mailing list with responses to the comments, > and then publish a new version. We believe that -06 deals with all of the WG Last Call issues raised, except one. We didn't understand "## E" in Yorgos' message from April 7. Yorgos: could you reformulate that concern based on the -06 draft? > Thanks to everyone who has provided feedback to date! Indeed! The draft feels much tighter now. --Paul Hoffman (for Joey and dkg) ___ 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
On Mon, Mar 27, 2023 at 11:03:17AM +, Paul Hoffman wrote a message of 8 lines which said: > Thanks for the implementation work at the Hackathon, and thanks to > Libor and Florian for the comments. Given that we are in WG Last > Call, we (the co-authors) will deal with them in the coming > weeks. We'd love to hear more about implementations and additional > issues; I don't know if you saw it, but ADoT probing in PowerDNS recursor, and their choices, were documented in: https://blog.powerdns.com/2022/06/13/probing-dot-support-of-authoritative-servers-just-try-it/ ___ 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
Thanks for the implementation work at the Hackathon, and thanks to Libor and Florian for the comments. Given that we are in WG Last Call, we (the co-authors) will deal with them in the coming weeks. We'd love to hear more about implementations and additional issues; this will help the final document be more useful. --Paul Hoffman ___ 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
On Mar 22, 2023, at 12:39 PM, Wessels, Duane wrote: > My primary concern with this draft is that, as written, it could > be interpreted as a requirement for DNS providers that operate > under contracts that use language such as "shall comply with relevant > existing RFCs". There are plenty of other DNS-related RFCs that I doubt you comply with because no one cares about them. However, that kind of language is unfortunately not rare. > I'm not sure that was the authors' intention. Our intention, is stated in the first sentence of the Introduction: This document aims to provide guidance to implementers who want to simply enable protection against passive network observers. The "who want" is the key here. There is absolutely no expectation that everyone will implement it. This is no different than, say, QNAME minimization. > For example, section 3 says: > > An authoritative server implementing the protocol described in this > document MUST implement at least one of DoT or DoQ on port 853. > > I can think of a couple ways this guidance could be improved: > > 1. The document could be split into two separate documents for clients > and servers, and the server document could be given Experimental status. > > 2. Clarify that this protocol is optional for servers to deploy. For example: > > The protocol described in this document is OPTIONAL for authoritative > servers. An authoritative server choosing to implement the > protocol described in this document MUST implement at least one > of DoT or DoQ on port 853. Thanks, that sounds good, and we will make that change, and as similar one for resolvers: it is OPTIONAL for them as well. > Also as a point of semantics, when this document uses "implement" > I think maybe it really means "deploy"? I've always thought that > implementation is what developers do and deployment is what operators > do. That is the approach taken with RFCs 7766 (DNS Transport over > TCP - Implementation Requirements) and 9210 (DNS Transport over TCP > - Operational Requirements). The document is talking about both. The mechanics have to be in the implementation, but they have to be turned on in configuration by the operator deploying the implementation. --Paul Hoffman ___ 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
On Mar 12, 2023, at 8:43 AM, Brian Haberman wrote: > > All, > This starts a 2-week WGLC for draft-ietf-dprive-unilateral-probing-05. > This call is to determine if the document is sufficiently complete to > facilitate implementations and interoperability testing. Once that > determination is made, the chairs will park this document in the datatracker > with a state of "Waiting for Implementation" and we will await for the > requested implementations and interoperability reports. > > The chairs will note that the document is currently marked as Proposed > Standard and that there has been a suggestion to move it to Experimental. If > you have an opinion on the status at this time, please include it in your > feedback to the WG mailing list. We will revisit the status of the document > before it gets advanced to our AD. > > This WGLC will end at midnight UTC on March 26, 2023. The authors have heard that there will be implementers working on implementing from this draft at the IETF Hackathon on March 25 and 26. It might be better to have the call for comments end a week after than so the folks at the Hackathon have time to write up their comments. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
