Re: [dnsext] resolving IESG comments on draft-ietf-dnsext-dnssec-bis-updates

Patrik Fältström <patrik@frobbit.se> Wed, 11 July 2012 07:06 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF5011E80F4; Wed, 11 Jul 2012 00:06:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1341990387; bh=s/cc9bxyxPoJKo1Vu2qQ1xJQap4LTLfrmtBNrahSKgM=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Z2g8088R3oEzj6wixCDisx1PpYpbsaoQT4fzf5Qy0GBB2ioJYjWMcFhodq2KtPHf6 1wdHBwJa5AIF0hs/XFyzfPvPKluiLF01lMGSeGm9IuxmKFX9rVlgSFUBLzkhwG8EHF TS0cYNB0WCHHO+JEMM060CkY1Jk0g1CfTNXIP4qo=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DDB11E80F4 for <dnsext@ietfa.amsl.com>; Wed, 11 Jul 2012 00:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTlJkCKlMMZJ for <dnsext@ietfa.amsl.com>; Wed, 11 Jul 2012 00:06:24 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 3475011E8098 for <dnsext@ietf.org>; Wed, 11 Jul 2012 00:06:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 588C9142D12CC; Wed, 11 Jul 2012 09:06:52 +0200 (CEST)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goXghhSh9bMy; Wed, 11 Jul 2012 09:06:52 +0200 (CEST)
Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 27CF2142D12C2; Wed, 11 Jul 2012 09:06:52 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Patrik Fältström <patrik@frobbit.se>
In-Reply-To: <D3D58A5F-D4DF-4ECA-AE2E-09008E7FAD52@vpnc.org>
Date: Wed, 11 Jul 2012 09:06:51 +0200
Message-Id: <A74BA8CA-B833-4A43-ACBC-771EBE5D6DFF@frobbit.se>
References: <alpine.BSF.2.00.1207100827380.30040@fledge.watson.org> <D3D58A5F-D4DF-4ECA-AE2E-09008E7FAD52@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1278)
Cc: Samuel Weiler <weiler@watson.org>, dnsext@ietf.org
Subject: Re: [dnsext] resolving IESG comments on draft-ietf-dnsext-dnssec-bis-updates
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On 10 jul 2012, at 16:50, Paul Hoffman wrote:

> The amount of differing opinions about the four states *even among DNSSEC-knowledgeable people* in that thread and others was significant.

The big difference is between people that do think it is a good thing that people in X.509 world themselves can "click" on "continue anyways" on a validation failure. I think personally it is *feature* that with DNSSEC a validator by default do not return anything if validation fails for some reasons, and the end user can not do anything at all about it (part from running its own resolver etc etc).

But I do understand other people do have other views.

Because of this, for me, a no-response in DANE is the same as failed validation, and such a failure that the end user/application should not continue. At all. No "continue anyway" etc.

Giving the ability "to continue" opens the door for denial of service attacks as a way to circumvent DANE security.

So to me there are three states only.

- No DANE in use
- DANE in use, validation succeeds
- All other cases

   Patrik

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext