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

[Sara Dickinson <[e-mail]>]

> On 10 Mar 2022, at 01:46, Benjamin Kaduk via Datatracker <[e-mail]> 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/
> 
> 

Hi Ben, 

Many thanks for the comments and further feedback - please see the updates in version -11 which was just published, which we hope addresses your comments. 

The issue containing discussion of your comments is : https://github.com/huitema/dnsoquic/issues/156 and the PR with final changes and some further discussion is https://github.com/huitema/dnsoquic/pull/166.

Best regards

Sara. 


> 
> ----------------------------------------------------------------------
> 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/
> 
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy