Subject: [dns-privacy] Two issues on draft-ietf-dprive-dnsodtls-04.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 14 Mar 2016 16:06:32 +0100

On Fri, Jan 22, 2016 at 05:51:22AM +0000,
 Tirumaleswar Reddy (tireddy) <[email-masked]> wrote 
 a message of 62 lines which said:

> This revision addresses comments from Christian and refers to draft-dgr-dprive-dtls-and-tls-profiles.
>         Title           : DNS over DTLS (DNSoD)
> 	Filename        : draft-ietf-dprive-dnsodtls-04.txt

> If the DNS client receives a hard ICMP error [RFC1122], it MUST
> immediately cease attempts to re-transmit its ClientHello.

Isn't there a risk of downgrade attack here? ICMP errors are not
authentified so an active attacker, even if off-path, could convince a
client to disable DNS over DTLS. May be add a reference RFC 5927 to
emphasize that the credibility of ICMP errors should be challenged?
(RFC 5927 is for TCP, I do not find an equivalent for UDP, where the
problem is more complicated, we cannot use the sequence numbers to
check the ICMP message.)

> The existing Query ID allows multiple requests and responses to be
> interleaved in whatever order they can be fulfilled by the DNS
> server.

Only the Query ID? RFC 7766 (a DTLS session, in one way, is a bit like
a TCP connection) says "Since pipelined responses can arrive out of
order, clients MUST match responses to outstanding queries on the same
TCP connection using the Message ID.  If the response contains a
question section, the client MUST match the QNAME, QCLASS, and QTYPE
fields." For DNS over ordinary UDP, I do not find a RFC with clear
rules but RFC 3833 section 2.2 and RFC 5452 section 4 both use more
than the Query ID. Since we are protected by DTLS, we may be more lax
but draft-ietf-dprive-dns-over-tls-04 is not "Since pipelined
responses can arrive out-of-order, clients MUST match responses to
outstanding queries using the ID field, query name, type, and class."

> Implementing DNSoD on root servers is outside the scope of this
> document.

Should be deleted (why only the root servers?)

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 14 Mar 2016 13:48:47 -0700

On 14-Mar-2016 08:06 am, Stephane Bortzmeyer <[email-masked]> wrote:
> client to disable DNS over DTLS.

> May be add a reference RFC 5927 to

Yeah, so we can adopt same position as DNS-over-TLS, which says in its security considerations:

  "    1.  There are known attacks on TLS, such as person-in-the-middle and
       protocol downgrade.  These are general attacks on TLS and not
       specific to DNS-over-TLS; please refer to the TLS RFCs for
       discussion of these security issues.  Clients and servers MUST
       adhere to the TLS implementation recommendations and security
       considerations of [RFC7525] or its successor.  DNS clients
       keeping track of servers known to support TLS enables clients to
       detect downgrade attacks.  For servers with no connection history
       and no apparent support for TLS, depending on their Privacy
       Profile and privacy requirements, clients may choose to (a) try
       another server when available, (b) continue without TLS, or (c)
       refuse to forward the query."

-d

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy