Re: [DNSOP] [Int-area] Review request- DNS Secure authentication

Roland Bless <roland.bless@kit.edu> Tue, 09 September 2014 17:36 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD741A7004; Tue, 9 Sep 2014 10:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level:
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 JMIYzNJLMIqM; Tue, 9 Sep 2014 10:36:45 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 0DEC81A02F1; Tue, 9 Sep 2014 10:36:43 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1XRPKq-0002Vr-0c; Tue, 09 Sep 2014 19:36:08 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id F06B6A800AA; Tue, 9 Sep 2014 19:36:40 +0200 (CEST)
Message-ID: <540F3AA6.7010702@kit.edu>
Date: Tue, 09 Sep 2014 19:36:38 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Hosnieh Rafiee <ietf@rozanak.com>, Int-area@ietf.org, DNSOP@ietf.org
References: <000901cfcab0$b1eda4b0$15c8ee10$@rozanak.com>
In-Reply-To: <000901cfcab0$b1eda4b0$15c8ee10$@rozanak.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1410284168.
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/RjEY8x4zJlNKBuotFxoxx7hlYoY
X-Mailman-Approved-At: Tue, 09 Sep 2014 10:43:37 -0700
Subject: Re: [DNSOP] [Int-area] Review request- DNS Secure authentication
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 17:36:47 -0000

Hi,

Am 07.09.2014 um 17:30 schrieb Hosnieh Rafiee:
> I just wonder whether or not any of you had a chance to take a look on the
> new version of cga-tsig. If you haven't yet take a look please do it. I
> welcome your inputs. 
> 
> Do you think the problem statement is clear? 

No, IMHO it is not. Usually you need clear attacker models
to explain existing vulnerabilities. The current problem
statement is quite a mixup of various different security aspects
and thus not clear.

Just a few examples:
"DNS records can become compromised." => this is an attack
on the _integrity_, but it can be launched at different
locations and at different levels (e.g., in the DNS databased,
with the DNS server, on the wire in transit, etc.)

(TSIG)
"No protection against IP spoofing and DNS amplification"
- spoofed IP addresses are not a problem if the DNS RR
  integrity is assured...

- "Does not easily protect DNS data confidentiality"
  -> confidentiality where? Against an attacker on the
  wire? The DNS (recursive) resolver provider will always know what
  has been asked for...

and so on. Section 1 is therefore quite confusing.
Clearly define an attacker model and describe why
existing protocols do not protect against these
attacks.

Regards,
 Roland