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
