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

["George (Yorgos) Thessalonikefs" <[e-mail]>]

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