[dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-dnsoquic-10: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dprive-dnsoquic-10: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a 0-RTT-related topic that I'd like to discuss, as the current
situation isn't entirely clear to me.  In particular, TLS 1.3 provides
(and QUIC inherits) a mechanism for a server to advertise that it just
does not support 0-RTT at all, via the (absence of the) "early_data"
extension.  This meshes nicely with the guidance in RFC 8446 that 0-RTT is
to only be used cautiously, and only with specific request from the
application.  However, this specificiation diverges from that requirement
for application opt-in (per §9.1), and so when I read the directive in
§5.5 that "servers MUST adopt one of the following behaviors", I am forced
to wonder if the absence of a "abort the connection, because you do not
enable early data at all" option is intended to forbid a server from
taking that approach and thus require servers to implement and enable
0-RTT at runtime.
I hope that the intent was just for the §5.5 listing to be predicated on
the server using 0-RTT at all, but it's hard to reach that conclusion from
the existing text, so I have to seek clarification.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Phillip Hallam-Baker for the secdir review.  I did want to
reiterate one of his comments, regarding the potential for harmful
interaction between use of DoQ (or really, any encrypted DNS transport)
and captive portals.  While this would accordingly have been best placed
in something generic to DNS privacy mechanisms, such as RFC 9076 or RFC
8932, I think there might still be room to mention it here.  I could
attempt to craft some text, if there is interest.

I made a pull request with some editorial suggestions at
https://github.com/huitema/dnsoquic/pull/154

Section 1

   The specific non-goals of this document are:
   [...]
   2.  No attempt to support server-initiated transactions, which are
       used only in DNS Stateful Operations (DSO) [RFC8490].

RFC 8490 is a proposed standard, so excluding it maybe is a bit in
conflict with claiming that this is a "general-purpose transport for DNS",
absent some other argument that DSO is a special-purpose tool.

Section 5.1.2

   DoQ connections MUST NOT use UDP port 53.  This recommendation
   against use of port 53 for DoQ is to avoid confusion between DoQ and
   the use of DNS over UDP [RFC1035].

Just to clarify: this prohibition is intended to apply even if there would
otherwise be mutual agreement to use port 53?

Section 5.2

   DNS traffic follows a simple pattern in which the client sends a
   query, and the server provides one or more responses (multiple
   responses can occur in zone transfers).

Is this true even for DSO server-initiated transactions?

   The client MUST select the next available client-initiated
   bidirectional stream for each subsequent query on a QUIC connection,
   in conformance with the QUIC transport specification [RFC9000].

Just to note: RFC 9000 does not require the client to *use* the "next
available" stream, instead saying that "a stream ID that is used out of
order results in all streams of that type with lower- numbered stream IDs
also being opened".  So this "MUST select the next available" is a new
requirement for DoQ, and it's not entirely clear to me that it's required
for interop (though it is more efficient than any alternatives).

Section 5.2.1

   This has implications for proxying DoQ message to and from other
   transports.  For example, proxies may have to manage the fact that
   DoQ can support a larger number of outstanding queries on a single
   connection than e.g., DNS over TCP because DoQ is not limited by the
   Message ID space.  This issue already exists for DoH, where a Message
   ID of 0 is recommended.

I'm not sure how often this motivating text is relevant.  The ID field
seems to be 16 bits, thus enabling 65k outstanding queries on a single
connection -- how often is there a need to have that many queries
outstanding at once?  It looks like the motivation presented in RFC 8484
for setting the ID to zero is to improve caching, as otherwise queries
identical at the DNS level would be cached as separate requests by HTTP.
I agree, of course, that the ID field is redundant with the QUIC stream ID
and that it should be set to zero, I am just not sure if the number of
outstanding queries is a relevant motivation for doing so.

(It also looks like RFC 8484 refers to this value as the "DNS ID" rather than
"Message ID".  I guess our options for consistent terminology are somewhat
limited, though.)

Section 5.3

   The following error codes are defined for use when abruptly
   terminating streams, aborting reading of streams, or immediately
   closing connections:

Should we say that these are what QUIC calls "application error code"s?
(Subsequent occurrences of the phrase "error code" might be modified to
"application error code" as well.)

Section 5.3.2

   set to DOQ_INTERNAL_ERROR.  [...]

Is there any further guidance to give on when a DNS SERVFAIL response vs
QUIC RESET_STREAM is preferred (or is the guidance really always to issue
RESET_STREAM)?

Section 5.3.3

   It is noted that the restrictions on use of the above EDNS(0) options
   has implications for proxying message from TCP/DoT/DoH over DoQ.

Was it already rejeted to spend a sentence mentioning that such proxying
would involve translating the messages per the needs of the different
protocols on the different connections?

Section 5.5

   Servers MUST NOT execute non replayable transactions received in
   0-RTT data.  Servers MUST adopt one of the following behaviors:

I think we should clarify whether "execute" means "take any action in
response to" or just "send a response message for".  (I think it needs to
be the former.)

Section 6.4

   Implementations MUST protect against the traffic analysis attacks
   described in Section 9.5 by the judicious injection of padding.  This

I think this is already overtaken by events, but a MUST-level requirement
seems overbearing here.  My understanding is that providing complete
protection against these types of attack is still an open research
question....

   could be done either by padding individual DNS messages using the
   EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see
   Section 8.6 of [RFC9000], the QUIC transport specification.

There is no Section 8.6 in RFC 9000.

Section 6.5.2

   Clients that want to maintain long duration DoQ connections SHOULD
   use the idle timeout mechanisms defined in Section 10.1 of [RFC9000],
   the QUIC transport specification.  Clients and servers MUST NOT send
   the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent
   on a DoQ connection (because it is specific to the use of TCP/TLS as
   a transport).

Should we make some statement (analogous to what RFC 7828 does) that if
such an option is received it MUST be ignored?  In the absence of such
guidance I can imagine implementors feeling a need to enforce the "MUST
NOT send" on the receiving end.

Section 6.7

   [RFC9103] specifies zone transfer over TLS (XoT) and includes updates
   to [RFC1995] (IXFR), [RFC5936] (AXFR) and [RFC7766].  [...]

I note that there is currently no "Updates:" header to indicate this
relationship.

   *  DoQ implementations SHOULD

      -  use the same QUIC connection for both AXFR and IXFR requests to
         the same primary

      -  pipeline such requests (if they pipeline XFR requests in
         general) and MAY intermingle them

      -  send the response(s) for each request as soon as they are
         available i.e. responses MAY be sent intermingled

Given the "SHOULD use the same QUIC connection", what does MAY-level
guidance to "intermingle such requests" mean, in a QUIC context?  Each DoQ
request is on a separate QUIC stream, so I do not see any opportunity for
intermingling other than by virtue of being in the same QUIC connection,
which is already a SHOULD.  This is in contrast to a TCP or TLS situation,
where there is only a single data stream and intermingling has some
natural meaning (or meanings, for the response case specifically, where it
might apply to overall responses (composed of multiple response messages)
or individual response messages).

Section 8

The discussion in §6.5.2 about resource management could be security
relevant at times, if we wanted to backreference it.

   The security considerations of DoQ should be comparable to those of
   DoT [RFC7858].  DoT as specified in [RFC7858] only addresses the stub

The security considerations section of RFC 7858 includes a MUST-level
requirement to adhere to the recommendations of BCP 195.  Does such a
MUST-level requirement apply to DoQ as well?  (I note that BCP 195 is
currently listed as only an informative reference, which would need to
change if a MUST-level requirement was added.)

   to recursive resolver scenario, but the considerations about person-
   in-the-middle attacks, middleboxes and caching of data from clear
   text connections also apply for DoQ to the resolver to authoritative
   server scenario.  [...]

RFC 7858 also lists a fourth consideration, traffic analysis or
side-channel leaks.  Do we want to forward-reference §9.5 for completeness
(or even take the secdir reviewer's suggestion of coalescing the privacy
considerations into the security considerations section as confidentiality
considerations)?

Section 9.1

   The prevention on allowing replayable transactions in 0-RTT data
   expressed in Section 5.5 blocks the most obvious risks of replay

Is the parity of negations correct here ("prevention on allowing")?  I see
§5.5 prohibiting execution of non-replayable transactions in 0-RTT data,
i.e., allowing replayable ones.

Section 10.4

   Provisional reservations share the range of values larger than 0x3f
   with some permanent registrations.  This is by design, to enable
   conversion of provisional registrations into permanent registrations
   without requiring changes in deployed systems.  (This design is
   aligned with the principles set in Section 22 of [RFC9000].)

Do we want to specifically call out the guidance on selecting specific
codepoints from §22.1.2 of RFC 9000?  (Or is it seen as not applicable
here?)

Section 12.1

We currently only specifically reference RFC 6891 in one place, to mention
that its provision for specifying maximum UDP message size is not relevant
for DoQ.  However, since we do define and require (in some cases) use of a
new "Too Early" EDNS(0) error code, it seems that the solution should be
to reference it from more places, rather than to demote it to an
informative reference.

Similarly, we only reference RFC 8914 in the IANA considerations where we
allocate the codepoint, and would likely benefit from sprinkling an
additional reference or two in the main body of the text.

RFC 7828, on the other hand, seems to only be mentioned to say that you
MUST NOT use it, which would probably be fine as an informative reference.

RFC 7873 is referenced for "similar to the DNS Cookies mechanism", which
also sounds solely informative.

   [I-D.ietf-dnsop-rfc8499bis]
              Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in
              Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03,

It's kind of surprising to see DoQ electing to take a normative dependency
on this draft that is not even in WGLC yet.  Wouldn't that risk incurring
substantial (unbounded) delays?

Section 12.2

A SHOULD-level requirement to implement the anti-replay mechanisms from
RFC 8446 seems to promote it to normative status, per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/