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

[Paul Hoffman <[e-mail]>]

On Jun 14, 2023, at 10:08 AM, Florian Obser <[e-mail]> wrote:
> 
> On 2023-06-12 19:48 UTC, Paul Hoffman <[e-mail]> wrote:
>> On Jun 12, 2023, at 1:46 AM, Florian Obser <[e-mail]> wrote:
>>> 
>>> On 2023-06-10 22:48 UTC, Paul Hoffman <[e-mail]> wrote:
>>>> On Jun 10, 2023, at 1:38 PM, Philip Homburg <[e-mail]> 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 looooong 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 for queries from addresses outside its ACL, you will see that on port 53 and port 853.

> 
>> 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.

I've responded to those now, and will do a new draft early next week after my co-authors have had a chance to review the changes from the SecDir review.


On Jun 14, 2023, at 10:26 AM, Florian Obser <[e-mail]> wrote:
>>> * 3.3.  Server Name Indication
>>> | MUST NOT serve resource records that differ based on SNI
>>> 
>>> The MUST NOT adds a strong restriction on future protocols that
>>> eliminate opportunistic encryption and unilateral probing.  I can
>>> envision a desire to at least respond REFUSED when using the wrong
>>> name.
>>> 
>>> As B.3. puts it:
>>> |   Any new stronger protocol should consider how it interacts with the
>>> |   opportunistic protocol defined here, so that operators are not faced
>>> |   with the choice between widespread opportunistic protection against
>>> |   passive attackers (this document) and more narrowly-targeted
>>> |   protection against active attackers.
>>> 
>>> I would say this protocol should also consider how it might interact with
>>> a new stronger protocol. That is, how can it be forward compatible.
>> 
>> This future-proofing is a good concern, but doesn't the current wording already cover it? The full text is:
>>   An authoritative DNS server that wants to handle unilateral queries
>>   MAY rely on Server Name Indication (SNI) to select alternate server
>>   credentials.  However, such a server MUST NOT serve resource records
>>   that differ based on SNI (or on the lack of SNI) provided by the
>>   client, because a probing recursive resolver that offers SNI might or
>>   might not have used the right server name to get the records it is
>>   looking for.
>> Returning REFUSED is certainly one way to meet "MUST NOT serve resource records". 
>> 
> 
> you cut of "that differ". If querying with the correct SNI you get a
> specific RRset. with the wrong SNI you get the empty set. Those
> sets differ. At least that's how I read it.

There is only so much we can future-proof. I would not suggest that we add anything more to the current text because the resolve cannot know the configuration settings in the authoritative server for when that server would respond with REFUSED, or silence, or anything else.

>>> * 4.1.  High-level Overview
>>> "If the encrypted transport protocol fails"
>>> 
>>> We really need to spell out what "fails" means, somewhere.
>>> 
>>> I am under the impression that draft is only concerned with successful
>>> / unsuccessful probes on the transport layer. As long as something
>>> answers it is a successful probe, it would not even need to be a valid
>>> DNS answer.
>> 
>> In the previous message to the mailing list, I pointed out that this
>> is covered in Section 4.6.4. Having said that, possibly moving the
>> definition up in the document seems fine. However, I think you want a
>> different definition; if so, please specify.
>> 
> 
> I think we are on the right track in the dprive mailing list
> discussion. I think we can resolve it over there.

I will add a pointer from 4.1 to 4.6.4 and the following subsections.

>>> 
>>> * 4.6.7.  Handling Clean Shutdown of an Encrypted Transport Connection
>>> Should we immediately retry E for the outstanding queries?
>> 
>> I don't think so. What is your logic here?
> 
> So this gave me the impression that it's not just about initial probing
> but also about what to do with subsequent queries.
> 
> So we successfully probed, we have a connection open, we send a bunch of
> queries through and then idle for a bit. The auth will not keep sessions
> open indefinitely and after some time without activity shut the session
> down.
> If we then have another query for the server we should open an encrypted
> connection again, because we know it will work. This section seems to
> suggest to do one round trip through Do53.

No, because of the second bullet from 4.6.1:

   For any of the supported encrypted transports E, if either of the
   following holds true, the resolver SHOULD NOT send a query to X over
   Do53:

   *  E-session[X] is in the established state, or

   *  E-status[X] is success, and (T0 - E-last-response[X]) <
      persistence


>>> * 5.  IANA Considerations
>>> odd boiler plate
>> 
>> There is no standard for NXIANA boiler plate. IANA always double-checks the section when documents move to IETF Last Call.


This was also called out in the SecDir review, so we will indeed fix this.

--Paul Hoffman