Re: [Trans] DNSSEC also needs CT

Stephen Kent <kent@bbn.com> Mon, 02 June 2014 17:12 UTC

Return-Path: <kent@bbn.com>
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 49D701A01ED for <trans@ietfa.amsl.com>; Mon, 2 Jun 2014 10:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.152
X-Spam-Level:
X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 T5xP-r3fNkLS for <trans@ietfa.amsl.com>; Mon, 2 Jun 2014 10:12:09 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F6B1A007B for <trans@ietf.org>; Mon, 2 Jun 2014 10:12:09 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:51199 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1WrVmE-000P4I-T5; Mon, 02 Jun 2014 13:12:03 -0400
Message-ID: <538CB061.5070403@bbn.com>
Date: Mon, 02 Jun 2014 13:12:01 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <ietf@hallambaker.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <537E3229.4070402@bbn.com> <CAMm+Lwjbi5t7Efgyf4cNdh-2=DqbeSE4xgxf3TchPZBAyERwug@mail.gmail.com> <537E3E17.8000901@bbn.com> <CAMm+LwhOCwmK=8qXpDRbBpXDiPB3Ei73zV4M1ZkczKQxmfnOwA@mail.gmail.com>
In-Reply-To: <CAMm+LwhOCwmK=8qXpDRbBpXDiPB3Ei73zV4M1ZkczKQxmfnOwA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/749VOEx3bo1wFfucL2akBo98GE8
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: Mon, 02 Jun 2014 17:12:11 -0000

PHB,

...

>> is that really more "serve" than an ability to issue a credential
>> for ANY name, as in the Web PKI?
> At least that is a temporary condition.
If CT is successful, yes.
> Any trust infrastructure that ultimately rests on the common sense of
> the US Congress and President is doomed in the long run. And there
> isn't a better political solution on offer either.
common sense an the U.S. Congress, that's an uncommon pairing :-).
> Finding a technical mechanism that reduces the dependence on the
> political/policy dimension makes it much easier to address that layer.
> If it is possible it is always far easier to eliminate a single point
> of failure than to work out policy level controls to prevent abuse.
agreed.
> ...
> If they already have a PKI then they are probably not interested in
> DNSSEC at all because that problem is already solved and DNSSEC is the
> red herring.
agreed, unless someone convinces them that the shiny new DNSSEC approach
to PKI is better, ...
> Unless that is there is an interesting way to use DNSSEC as an
> extension of the enterprise PKI. In which case it is critical that the
> DNSSEC PKI does not introduce a new point of failure.
agreed,

That's a very confusing last phrase.

> DNSSEC is still raw technology. Saying that it does not need feature X
> before the full set of potential applications is premature. We don't
> know what it is useful for yet. That is what we should find out.
Thanks for the clarification.
>> I understand their concerns. But the lack of a well-articulated architecture
>> for CT, much less a CT for DNSSEC, makes it hard for me to gauge whether
>> this is a good idea.
> I find that looking at an additional field of application is often a
> very good way to improve an underspecified architecture.
I guess so, but I'd really prefer a fully-specified architecture for
what purports to be the motivating case, before we claim its a good
basis for solving other problems. I think the potential DNSSEC mis-issuance
problems are different enough to merit a separate analysis and design 
proposal.
> Trans is rather too closely designed to solve one problem and it is
> not even clear that it does that particularly well. There is a lot of
> fuzziness in the process by which a relying party decides that a
> particular value is the true Merkle tree apex of a particular log.
I agree.

Steve