Martin Duke's ballot comments

[huitema]

Martin Duke 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:

Thanks for this draft! It was very easy to read.

(4.3) says:

"Using QUIC might allow a protocol to disguise its purpose from devices on the
network path using encryption and traffic analysis resistance techniques like
padding. This specification does not include any measures that are designed to
avoid such classification."

but then Sec 6.4 has a detailed, normative discussion of how to use padding to
avoid classification. I suggest you delete or edit the bit in 4.3.

(5.3.1) Clients are allowed to send STOP_SENDING and servers are allowed to
send RESET_STREAM. Servers sending STOP_SENDING break the connection. Given the
prescriptiveness of these rules, it's odd that you don't address clients
sending RESET_STREAM. IMO this should be allowed, but either way it should be
specified.

(6.5.4) and (9.4) I hesitate to write this, as Christian is as well aware as
anyone, but IMO QUIC address migration is not quite as privacy-destroying as
this draft suggests. RFC9000 has a number of normative requirements to reduce
linkability, and work is ongoing to reduce it further. Granted, no
anti-linkability mitigation is perfect, and if this is a primary goal of DoQ
it's OK to discourage migration as you've done here.

[saradickinson]

I think the first point is already addresses in a PR.

On the second point, the cases I can see for a client using STREAM_RESET are:

• if it opens a stream but cannot send a query and so would create a dangling stream - it could send DOQ_INTERNAL_ERROR. This assumes it thinks it can still carry on with the connection and use other streams..... After the query is sent it should send STOP_SENDING until the response is received.
• it wants to shut a dangling stream with a response but no STREAM FIN without yet closing the connection.... (and similarly for servers?). Would they send DOQ_NO_ERROR?? It is really an error that there is no FIN but we don't have another better code if we think this is really needed....? We already cover leaving the streams dangling until the endpoint decided to shut the connection instead so not sure.
  Can you think of other cases?
  Shall we add these to the end of section 5.2 where we discuss dangling streams?

Do you have an opinion on the last point?

[huitema]

The QUIC protocol allows peers to send STREAM RESET or STOP SENDING frames at any time. The basic rules:

• Stream Reset is imperative. It closes the stream, and indicates that no more data will be sent on that stream.
• Stop Sending is indicative. It asks the peer to please stop sending, indicating that the receiver does not need the data any more. The sender that follows suit should send a RESET.
• Reset should not be sent if all the data has already be sent, there is a bit of a gray line for data sent but not received.
• Stop Sending has no effect if the peer has already sent all data.

In our case, since messages are short, that means the server has hardly any option to send a valid stop sending frame: the stream opens after the client sends something, the server learns about it and receives everything. But yes, it could happen if the client leaves the stream dangling. In the other direction, STOP SENDING is meaningful. It means "not interested in that query anymore", and can be sent before receiving the first bits of the reply.