7. Security Considerations

Questa sezione conserva il testo RFC su DNS over CoAP, includendo CoAP FETCH exchanges, application/dns-message Content-Format 553, SVCB docpath discovery, OSCORE and (D)TLS protection, CoAP caching, IANA registrations e operational/security considerations.

Testo RFC originale

7.  Security Considerations

   General CoAP security considerations ([RFC7252], Section 11) apply to
   DoC.  DoC also inherits the security considerations of the protocols
   used for secure communication, e.g., OSCORE ([RFC8613], Section 12)
   as well as DTLS 1.2 or newer ([RFC6347], Section 5 and [RFC9147],
   Section 11).  Additionally, DoC uses request patterns that require
   the maintenance of long-lived security contexts.  Section 2.9 of
   [CoAP-CORR-CLAR] provides insights on what can be done when those are
   resumed from a new endpoint.

   Though DTLS v1.2 [RFC6347] was obsoleted by DTLS v1.3 [RFC9147],
   there are many CoAP implementations that still use v1.2 at the time
   of writing.  As such, this document also accounts for the usage of
   DTLS v1.2 even though newer versions are RECOMMENDED when using DTLS
   to secure CoAP.

   When using unprotected CoAP (see Section 6), setting the ID of a DNS
   message to 0 as specified in Section 4.2.2 opens the DNS cache of a
   DoC client to cache poisoning attacks via response spoofing.  This
   document requires an unpredictable CoAP token in each DoC query from
   the client when CoAP is not secured to mitigate such an attack over
   DoC (see Section 6).

   For secure communication via (D)TLS or OSCORE, an unpredictable ID to
   protect against spoofing is not necessary.  Both (D)TLS and OSCORE
   offer mechanisms to harden against injecting spoofed responses in
   their protocol design.  Consequently, the ID of the DNS message can
   be set to 0 without any concern in order to leverage the advantages
   of CoAP caching.

   A DoC client must be aware that the DoC server may communicate
   unprotected with the upstream DNS infrastructure, e.g., using DNS
   over UDP.  DoC can only guarantee confidentiality and integrity of
   communication between parties for which the security context is
   exchanged.  The DoC server may use another security context to
   communicate upstream with both confidentiality and integrity (e.g.,
   DNS over QUIC [RFC9250]); however, while recommended, this is opaque
   to the DoC client on the protocol level.  Record integrity can also
   be ensured upstream using DNSSEC [BCP237].

   A DoC client may not be able to perform DNSSEC validation, e.g., due
   to code size constraints or the size of the responses.  It may trust
   its DoC server to perform DNSSEC validation; how that trust is
   expressed is out of the scope of this document.  For instance, a DoC
   client may be configured to use a particular credential by which it
   recognizes an eligible DoC server.  That information can also imply
   trust in the DNSSEC validation by that DoC server.