[secdir] SecDir review of draft-ietf-6man-dns-options-bis-03

Vincent Roca <vincent.roca@inrialpes.fr> Fri, 25 June 2010 11:05 UTC

Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 5131D3A6895; Fri, 25 Jun 2010 04:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.742
X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 21qyy8k1ewtr; Fri, 25 Jun 2010 04:05:56 -0700 (PDT)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr []) by core3.amsl.com (Postfix) with ESMTP id D7A373A67C0; Fri, 25 Jun 2010 04:05:55 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,480,1272837600"; d="scan'208";a="62125894"
Received: from geve.inrialpes.fr ([]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 25 Jun 2010 13:06:02 +0200
Message-ID: <4C248D9A.5080508@inrialpes.fr>
Date: Fri, 25 Jun 2010 13:06:02 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
Organization: INRIA
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv: Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: secdir@ietf.org, iesg@ietf.org
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-6man-dns-options-bis.all@tools.ietf.org
Subject: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2010 11:05:58 -0000

Dear All,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

IMHO current proposal generates additional security threats,
as explained below:

** Section 7 "Security considerations"
I don't share all the ideas of the authors. If I understand the point
of view, the authors say that the situation is not worse than before,
without these DNS options.
  "...learning DNS information via the RA options cannot be worse than
   learning bad router information via the RA options."

Well, it depends on the security level we consider...
>From the point of view of the ND protocol itself, I agree. But from
the end user point of view, the situation is quite different, since
sending forged packets (for instance) and controlling which DNS server
is trusted by the client opens the way to, for instance, fishing
attacks. This attack enables an attacker to make a client use a
compromised DNS server that behaves perfectly except for one particular
DNS query. If the attacker can send an email to this client, then many
things can happen. This attack could be launched e.g. during next IETF
plenary ;-). The attacker knows the email off all participants, so if
he can control their DNS configuration as well, many things may
happen... IMHO a serious threat is introduced by this document that
needs to be seriously discussed.

** Section 7:
Another point... the authors explain than network devices like
switches can be configured in such a way to disable ND/DHCP from
some ports.  That's great and I agree it helps preventing attacks.
However this is limited to wired networks. Nothing is said concerning
ND configurations in wireless networks. The situation is rather
different since any host can issue ND/DHCP traffic as if it were a
legitimate server if I understand correctly. The document MUST
include this kind of discussion.

** Section 7:
Yet another remark: SEND is listed as one potential solution to
add signatures in ND packets issued from servers.
I don't know SEND at all, so may be my remarks are flawed (but in
that case the text should be at least clarified).
- Shouldn't the use of SEND be RECOMMENDED as a solution to
mitigate attacks? Current document is not clear.
- Does SEND enable an authentication of the sender (the document
only mentions integrity protection)? If there's no sender
authentication, then I agree that the added value of SEND would be
limited. I'd like the authors to clarify this as well.

** Section 7:
Finally, I have the feeling that the text describing the two attacks
in first paragraph (i.e. (1) pretend to be the legitimate server by
fooling the switch, and (2) simply send RA packets) should be
improved. The authors may say explicitly they consider two ND attacks
(in order to show that an attack is feasible and easy if no counter
measure is taken), and then describe them in specific bullets. The
current description of (1) also says that this attack can be used
to "tell the hosts to send their traffic somewhere else." I agree but
we need to focus here on attacks that target DNS, not the client
routing part. It adds some confusion to the text

** Section 5.3.1 "Procedure of DNS configuration"
In the DNS option processing, it's probably worth mentioning that
the RDNSS/DNSSL lifetime entries MUST be carefully checked.
Otherwise an attacker can easily send RA with very short lifetimes
to make legitimate DNS entries quickly timeout in a client and
replace them with his own entries that point to a corrupted
DNS server. This raises another question: can an existing entry
be revised before its expiration? In current text, I read:
  "If the DNS options are valid, the host SHOULD copy the values of
   the options into the DNS Repository and the Resolver
Copy is automatic once the option is validated. It's perhaps too

** Section 5.3.1 "Procedure of DNS configuration"
It is said that:
  "In the case where the DNS options of RDNSS and DNSSL can be
   obtained from multiple sources, such as RA and DHCP, the IPv6
   host can keep some DNS options from RA and some from DHCP..."
Well, this strategy is a little bit strange. Why should it be so and
not something else? If the use of solution 1 is more secure than
solution 2, then the document should say that solution 1 is
RECOMMENDED. This is not the case for the moment.

Also what happens if several ND servers send RA with different DNS
options (e.g. one is sent by a valid ND server and the other one
by the attacker)? This is not considered in the above paragraph.

I hope these comments will be useful in improving the document.
Best regards,