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

[Christian Huitema <[e-mail]>]

Thanks for the pull request, Ben. Looking at it now.

On the 0RTT point: it is indeed possible for a server to not support 
0RTT at all, and if this is not clear, we should clarify.

I do have a concern about the interaction between "support for 0-RTT" 
and "keep connections alive for a long time". If servers do not support 
0-RTT, clients have incentive to use artificial traffic and keep 
connections alive, and that could be a lot of overhead for servers. But 
people deploying servers can weight that among other factors, and not 
supporting 0RTT is one of many possible choices.

-- Christian Huitema

On 3/9/2022 5:46 PM, Benjamin Kaduk via Datatracker wrote:
> 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/
>
>
>