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

From: "Jørgen Hovland ☁️" <[email-masked]>
Date: 22 Mar 2022 13:00:43 +0000 (UTC)

> 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 <[email-masked]> 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

[email-masked]

https://www.ietf.org/mailman/listinfo/dns-privacy