Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing

[Paul Hoffman <[e-mail]>]

On Jun 7, 2023, at 1:05 AM, Philip Homburg <[e-mail]> 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 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.

Can you be more specific about "operational issues"? Every new protocol has operational issues. Which are you concerned about here, and can they be measured?

> 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)"

Earlier in that same document, it says what is an expriemental protocol, and this draft doesn't match that description at all.

> So I think it best to no longer delay this draft, publish it as experimental
> and gain experience in how this actually works.

Without more detail about what you want to observe or measure in this experiment that wouldn't be observed or measured for any normal standard, it's hard to agree with that assessment.

--Paul Hoffman