Christian
Thanks for bringing this up. I make it a point to follow/receive updates
on all the repos of dprive documents, but I missed your repository. The
chairs are advocates for using repositories like github for documents, as
we feel they have positive effects.
I believe the chairs have said this before, but it bears repeating: Please
feel free to use github for issue tracking, especially those involving
editorial discussions. But those issues raised which involve normative
changes to the document itself should be brought to the working group
mailing list for wider discussion and consensus.
I have not read all the issues Martin has raised, but those that look
substantial (such as 0-RTT) should be brought to the list. I suggest
starting separate email threads for each issue, to work through them
individually.
thanks
tim
On Fri, Oct 15, 2021 at 2:51 PM Christian Huitema
wrote:
> As Martin mentions, we had a number of issues opened recently in the
> GitHub repo managed by the authors
> (https://github.com/huitema/dnsoquic/). A lot of them have been opened
> after reviews by members of the QUIC working group. We have a bit of a
> culture clash here. The QUIC WG used GitHub intensely, but DPRIVE is
> usually more cautious, using it for coordination between the authors of
> the draft and possibly for straightforward editorial issues. here is a
> short list of the issues that are definitely not editorial:
>
> * Error code extensibility, and greasing of error codes. Several QUIC
> frames carry application defined error codes: reset stream, stop sending
> and close connection. The draft specifies a small set of error codes to
> use with these frames, and also specifies an extension mechanism to
> register more error codes. Issues
> https://github.com/huitema/dnsoquic/issues/80 and
> https://github.com/huitema/dnsoquic/issues/81, by Lucas Pardue, request
> to specify that receiving an "unknown" error code is not an error, and
> suggest that implementations can test the extensibility mechanism by
> sometimes sending different error codes, a.k.a., greasing. Proposed
> resolution in https://github.com/huitema/dnsoquic/pull/108.
>
> * Request to specify what happens if a node receives data in unexpected
> QUIC streams, issue https://github.com/huitema/dnsoquic/issues/82 by
> Lucas Pardue. DoQ only uses bidirectional QUIC streams opened by the
> client when sending a query, but QUIC permits other type of streams,
> such as unidirectional streams opened by the client or the server, or
> bidirectional streams open by the server. The spec did not specify how
> to handle data received in such streams. The proposed resolution is to
> treat that as a protocol error.
>
> * Getting rid of the text about not deliberately avoiding middle-boxes,
> issue https://github.com/huitema/dnsoquic/issues/90 by Martin Thomson.
> While the text is correct, it does not discuss potential usage of SNI
> encryption or Encrypted Client Hello (ECH), both of which can be used to
> "armor" a TLS based protocol and make it harder to block by
> middle-boxes. Adding a discussion of such mechanism is likely to be
> contentious. The discussion of middle-boxes in section 4.3. is not
> essential in the document, and the simplest solution is to just remove it.
>
> * Clarifying what happens if the client sends a query on a stream but
> fails to close the stream, issue
> https://github.com/huitema/dnsoquic/issues/93 by Martin Thomson. The
> draft specifies that adding a new query after the first one is an error,
> but is silent about failure to close the stream. Waiting for a proposed
> resolution.
>
> * Details on connection closure and client abandoning connections before
> the idle timeout elapses, issue
> https://github.com/huitema/dnsoquic/issues/98. Proposed resolution is
> that the client can always "walk away", and to only require explicitly
> clsoing the connection if transactions are pending.
>
> * Details on usage of 0-RTT with XFR QUERY, issue
> https://github.com/huitema/dnsoquic/issues/99 by Martin Thomson. The
> current text is wrong, because 0-RTT resumption includes carry over of
> the authentication negotiated in the previous connection. We may want to
> not consider XFR Queries as replayable, and ask servers to wait until
> the handshake is complete before processing them.
>
> * Details on the 0-RTT mitigation text, issue
> https://github.com/huitema/dnsoquic/issues/102 by Martin Thomson. The
> current text is based on the original analysis done by DKG years ago,
> which pointed out the risks of replaying 0-RTT packets at attacker
> chosen times. That attack is largely mitigated by the replay protection
> in TLS 1.3, which is mandatory to implement. 0-RTT packets can only be
> replayed within a narrow window, which is only wide enough to account
> for variations in clock skew and network transmission.Need to update the
> text and account for that.
>
> * Comparison of privacy effects of long duration session and session
>
