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
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
