Re: [dns-privacy] Murray Kucherawy's No Objection ondraft-ietf-dprive-dnsoquic-10: (with COMMENT)

[Jørgen Hovland ☁️ <[e-mail]>]

> Clients SHOULD monitor the idle time incurred on their connection to
> the server, defined by the time spent since the last packet from the
> server has been received. When a client prepares to send a new DNS
> query to the server, it will check whether the idle time is
> sufficiently lower than the idle timer. If it is, the client will
> send the DNS query over the existing connection. If not, the client
> will establish a new connection and send the query over that
> connection.

Just my point of view, but this approach generally opens for permanent tracking for higher traffic clients or solutions that try to circumvent privacy by sending constant "ping" requests.

I would rather define "idle time" as the delta time between the first packet sent and current time. If the delta time is higher than XX seconds, a new connection will be performed regardless of when the last packet was sent.

An alternative for systems without proper knowledge of time is to define a maximum amount of requests per connection before it is reset (with or without regarding time).

Cheers,

Jørgen

At 09:40 22/03/2022 (UTC), Sara Dickinson wrote:



> On 10 Mar 2022, at 04:53, Murray Kucherawy via Datatracker <[e-mail]> wrote:
>
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-dprive-dnsoquic-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Now THAT is a well done shepherd writeup.
>
> Thanks for this work, which was an interesting read. It's great to see this so
> quickly on the heels of QUIC itself.

Many thanks for the comments - please see the updates in version -11 which was just published, which we hope address your comments.

>
> Just a couple of BCP 14 things to point out. In Section 5.4, we have this:
>
> Clients SHOULD monitor the idle time incurred on their connection to
> the server, defined by the time spent since the last packet from the
> server has been received. When a client prepares to send a new DNS
> query to the server, it will check whether the idle time is
> sufficiently lower than the idle timer. If it is, the client will
> send the DNS query over the existing connection. If not, the client
> will establish a new connection and send the query over that
> connection.
>
> There's a blanket SHOULD, followed by two "will"s. I read those as normative
> requirements, even though they don't use BCP 14 language. But that means they
> conflict with the SHOULD. IMHO, this needs to be resolved.

Agreed - we’ve updated the following ‘wills' to SHOULDs.


>
> In Section 5.5:
>
> Clients SHOULD consider potential privacy issues associated with
> session resumption before deciding to use this mechanism. [...]
>
> I find "SHOULD consider" to be far too vague for this to be meaningful. If
> I've thought about it, have I met my burden here?

There are several things to evaluate here - we’ve updated this text to:
“Clients SHOULD consider
potential privacy issues associated with session resumption before deciding to use
this mechanism and specifically evaluate the trade-offs presented in the various sections of this document. The privacy issues are detailed…"

Does that address your concern or can you suggest text?

All nits fixed - thanks!

Sara.

>
> Thank you for including Section 7.
>
> And now, some nits.
>
> Abstract:
>
> * "... similar properties to that provided by ..." -- s/that/those/
>
> Section 1:
>
> * "DNS over QUIC is referred here as ..." -- s/referred/referenced/ or
> s/referred/referred to/
>
> Section 5.2:
>
> * The second-last paragraph is missing a closing parenthesis.
>
>
>

_______________________________________________
dns-privacy mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dns-privacy