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 <[email protected]> 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 > resumption, issue https://github.com/huitema/dnsoquic/issues/103 by > Martin Thomson. If the client address did not change, session resumption > and long duration sessions have similar effects on client privacy, and > the text needs to reflect that. > > DPRIVE members may want to discuss these issues on the mailing list. > > -- Christian Huitema > > > > > On 10/14/2021 7:38 PM, Martin Thomson wrote: > > I've reviewed this document (straight from GitHub in this case). > > > > I've opened a few issues: > https://github.com/huitema/dnsoquic/issues/created_by/martinthomson > > > > You will observe that some of these issues are old and remain > unaddressed. It is my opinion that the document is not ready and it needs > another pass to improve a number of problems. > > > > To be clear, I think that the core protocol definition is good. > > > > I found a large number of editorial issues when I was reviewing it. I > provided pull requests for some, but there are a great many more that would > benefit from a careful proof read and cleanup. Martin Duke found several > issues to add to this; those also need to be addressed. > > > > However, there are a number of substantive problems in the supporting > material that I think need to be fixed. For instance, some of these are > false or misleading claims about security properties. There are enough of > these that I don't think that this document is fit to give to the IESG. I > don't think that any of these are hard to address, but there are rather a > lot of them. > > > > Regards, > > Martin > > > > On Wed, Oct 13, 2021, at 22:30, Brian Haberman wrote: > >> DPRIVE & QUIC WG Participants, > >> > >> This starts a 2-week DPRIVE WG Last Call for advancing > >> draft-ietf-dprive-dnsoquic-05 as a Proposed Standard. Please send all > >> substantive comments to the DPRIVE mailing list. Editorial comments > >> should be directed to the document editors. This last call will end > >> 11:59pm UTC on Oct. 27, 2021. > >> > >> Regards, > >> Brian & Tim > >> > >> _______________________________________________ > >> dns-privacy mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/dns-privacy > >> > >> Attachments: > >> * OpenPGP_signature > > _______________________________________________ > > dns-privacy mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
