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

[Florian Obser <[e-mail]>]

On 2023-06-07 23:12 UTC, Paul Hoffman <[e-mail]> wrote:
> 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.
>

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 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
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy

-- 
In my defence, I have been left unsupervised.