Re: [dnsext] Clarifying the mandatory algorithm rules

Edward Lewis <Ed.Lewis@neustar.biz> Mon, 22 November 2010 12:58 UTC

Return-Path: <Ed.Lewis@neustar.biz>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B243A6A4A for <dnsext@core3.amsl.com>; Mon, 22 Nov 2010 04:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.81
X-Spam-Level:
X-Spam-Status: No, score=-98.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MANGLED_LOW=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-pTHZ2h0HoT for <dnsext@core3.amsl.com>; Mon, 22 Nov 2010 04:58:34 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E1EEF3A6A62 for <dnsext@ietf.org>; Mon, 22 Nov 2010 04:58:33 -0800 (PST)
Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oAMCxKd9030972; Mon, 22 Nov 2010 07:59:21 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Received: from [192.168.128.163] by Work-Laptop-2.local (PGP Universal service); Mon, 22 Nov 2010 07:59:28 -0500
X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 22 Nov 2010 07:59:28 -0500
Mime-Version: 1.0
Message-Id: <a06240801c9101620d463@[192.168.128.163]>
In-Reply-To: <4CE51293.5040605@nlnetlabs.nl>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <4CE51293.5040605@nlnetlabs.nl>
Date: Mon, 22 Nov 2010 07:58:53 -0500
To: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Nov 2010 12:58:35 -0000

At 12:48 +0100 11/18/10, W.C.A. Wijngaards wrote:

>Several people have complained that unbound is too strict, and I keep
>defending this.  I do claim to be RFC conformant; and I want to oppose
>the change.  (but not the clarification of signing rules).

Add me to that list.  I think Unbound is not acting in the best 
interests of the network at large.

>This is what I do, I want to avoid a downgrade attack.  A proper signed
>zone has these signatures.  They are missing.  Something is wrong.

What is wrong is that Unbound is not adhering to the spirit of 
DNSSEC.  DNSSEC is designed to protect against cache poisoning.  If 
there is a chain of trust to an RRSet, then the set validates, it has 
proven source authenticity and data integrity.

Since time began (for DNS), there is always something wrong 
somewhere.  The goal is a robust system, not a tightly correct system.

>Yes.  Even though one signature worked, because the other did not work
>(was 'stripped off') it was obvious that there was a downgrade attack.
>Signatures had been removed from the answer.  To be safe, unbound blocks
>this suspect content.

I question the use of the word "obvious."  Recall how the TC bit 
works - if a message cannot include all of the required records, the 
message contains what it can.  The receiver has the option to request 
the full answer over TCP or live with what it has already gotten - 
with the chance that what matters was received.

Stripping of records has always been accommodated in the protocol. 
DNSSEC shouldn't forget that.

>Operationally, something really bad is happening.

You do not know that. ;)

>You must not be lenient with security.

Security must be as lenient as possible without allowing badness. 
(If you illegally cross the street, should the police track you down, 
arrest you, question you, etc., if there was no other record than a 
CCTV image?  Sorry, I hate analogies.)

>I disagree, I am not violating the RFC.  I choose to reject zones that
>are not signed properly.  You understand that unbound gets
>algorithm-downgrade-protection from applying this policy?  There is
>actual security benefit to this policy?

You aren't violating a specific RFC but you are causing "false 
positive" situations.

>Yes, people should know how to keep it signed properly.

Remember, there is more than a signer and authority involved, there 
are caches, etc.  The big cooperative Internet and all that. 
End-to-end principle.

>I do not agree with this, because it diminishes security.

Security isn't the goal - robustness, resiliency, and response is. 
(Think about that one for a while.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?