[dns-privacy] Two issues on draft-ietf-dprive-dnsodtls-04.txt
Stephane Bortzmeyer <bortzmeyer@nic.fr> Mon, 14 March 2016 15:17 UTC
Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEBA12DC65 for <dns-privacy@ietfa.amsl.com>; Mon, 14 Mar 2016 08:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arGvrO-_oSZa for <dns-privacy@ietfa.amsl.com>; Mon, 14 Mar 2016 08:17:14 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD3D12DC83 for <dns-privacy@ietf.org>; Mon, 14 Mar 2016 08:07:04 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C758C2803B1; Mon, 14 Mar 2016 16:07:02 +0100 (CET)
Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id C242D2802BB; Mon, 14 Mar 2016 16:07:02 +0100 (CET)
Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id BFABD4C002C; Mon, 14 Mar 2016 16:06:32 +0100 (CET)
Date: Mon, 14 Mar 2016 16:06:32 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Message-ID: <20160314150632.GA12485@nic.fr>
References: <20160122054754.30732.9177.idtracker@ietfa.amsl.com> <2fc81367a8d0480eab5f2c886ef20a6b@XCH-RCD-017.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2fc81367a8d0480eab5f2c886ef20a6b@XCH-RCD-017.cisco.com>
X-Operating-System: Debian GNU/Linux stretch/sid
X-Kernel: Linux 4.3.0-1-686-pae i686
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dns-privacy/JO3yUrizwO4QGIglcmsztBX3qyE>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Subject: [dns-privacy] Two issues on draft-ietf-dprive-dnsodtls-04.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2016 15:17:17 -0000
On Fri, Jan 22, 2016 at 05:51:22AM +0000, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> 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?)
- [dns-privacy] I-D Action: draft-ietf-dprive-dnsod… internet-drafts
- [dns-privacy] FW: I-D Action: draft-ietf-dprive-d… Tirumaleswar Reddy (tireddy)
- [dns-privacy] Two issues on draft-ietf-dprive-dns… Stephane Bortzmeyer
- Re: [dns-privacy] Two issues on draft-ietf-dprive… 🔓Dan Wing