Re: [Trans] DNSSEC also needs CT

Paul Wouters <paul@nohats.ca> Thu, 22 May 2014 17:55 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873BA1A026C for <trans@ietfa.amsl.com>; Thu, 22 May 2014 10:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] 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 AZxwxc0EK4-6 for <trans@ietfa.amsl.com>; Thu, 22 May 2014 10:54:59 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200FC1A0289 for <trans@ietf.org>; Thu, 22 May 2014 10:54:56 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5B1FB802BF; Thu, 22 May 2014 13:54:54 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1400781294; bh=dm4Cl97q0zS0HhsslwZawqAybGUJnxM8suRXtlHuZDY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LpOWQn/r0xZLYxupyNIqMGcESIIwG+Bnjgdk4kJpGwVbvm06rgHPd5qohZLPYAABT rihMjh+ZjmyER6dVCKBvMjYUusieLczb4kuvHgQNTypJgxSMaam3tImLRQyNEPcrkQ Sn4m/Pfi6X1mRVsnQVewO7ZMRx+J3Ezj7uQwzYjA=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4MHsrT1006830; Thu, 22 May 2014 13:54:54 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Thu, 22 May 2014 13:54:53 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: "Osterweil, Eric" <eosterweil@verisign.com>
In-Reply-To: <1C7BC1B3-B792-43F4-BC8F-C75FC8965B6E@verisign.com>
Message-ID: <alpine.LFD.2.10.1405221348060.23782@bofh.nohats.ca>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <537E3229.4070402@bbn.com> <1C7BC1B3-B792-43F4-BC8F-C75FC8965B6E@verisign.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_WgO7diOtdwP_W_ejAu8p8eeoBo
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] DNSSEC also needs CT
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 17:55:10 -0000

On Thu, 22 May 2014, Osterweil, Eric wrote:

> Without implying an presumption of expertise on DNS, I would argue that DNSSEC avoids the problems CT seems to be trying to solve by coupling its key learning (and verification) methods to the hierarchical namespace.  As Steve said (I believe) PKIX != Web PKI, and the problems addressed by CT seem to be focused more on the latter.  I don't think there is a key learning/verification dilemma in DNSSEC that CT is appropriate for.

There are some very visible and vocal people that have rejected DNSSEC
flat out because it can be circumvented or co-erced by the higher up
parental zones. They have an inherent distrust of the US Government,
Verisign, ICANN, etc. In fact, they are often trying to replace the
DNS with some peer-to-peer type solution for this very reason. I see
CT-DNSSEC as a way to address that concern, and get those people onboard
for DNS with DNSSEC security without the need for an alternative to DNS.

Paul