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

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

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