Re: [Trans] DNSSEC also needs CT

Phillip Hallam-Baker <ietf@hallambaker.com> Fri, 23 May 2014 13:12 UTC

Return-Path: <hallam@gmail.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 9DF4F1A01CD for <trans@ietfa.amsl.com>; Fri, 23 May 2014 06:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 Q4wRoMJ6sdEP for <trans@ietfa.amsl.com>; Fri, 23 May 2014 06:12:20 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBA11A01C0 for <trans@ietf.org>; Fri, 23 May 2014 06:12:20 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id a1so4717413wgh.15 for <trans@ietf.org>; Fri, 23 May 2014 06:12:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KPqdZ9qjfIYqC81s98X+YSwJ98cWs+3smmJMDnYaNho=; b=P6durWyGtWl7NstBC4iZ3sgo9KIvliPlkjPhPasw0qPF5w2CzoTRredIXH0Rrr9LbS FUoDiyeQ4fDa7LIf+Ww6RRQEBLlBjEOPZywsBAw5NI9Vt2tYu8uolb1mvT1Hkve/2B3P kXmtEYri5s+DshKderzzL1nXL8Svb+RWSoLRl2n9WrdOYiZGpa08t4O7lInnsSMyej0y tK7miUSAzgPampGY6tdp206z2oZscYeLJSr8kbNYkwUHBIMRpW5siff52lD25OY6AEaS rvHhszfMo2ef+/CGPhl3VQwvn+F3F0qH0l5MZXjbqDBtkR0sH97NUvTsaDNAt4F+9tQM w4QA==
MIME-Version: 1.0
X-Received: by 10.194.62.176 with SMTP id z16mr2100861wjr.76.1400850737483; Fri, 23 May 2014 06:12:17 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.194.79.136 with HTTP; Fri, 23 May 2014 06:12:17 -0700 (PDT)
In-Reply-To: <CABrd9STR=3zpau+hByvW0Sqd3gY_cmUgjn3D7_3yXjaobG7oeg@mail.gmail.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <537E3229.4070402@bbn.com> <1C7BC1B3-B792-43F4-BC8F-C75FC8965B6E@verisign.com> <CABrd9STR=3zpau+hByvW0Sqd3gY_cmUgjn3D7_3yXjaobG7oeg@mail.gmail.com>
Date: Fri, 23 May 2014 09:12:17 -0400
X-Google-Sender-Auth: wJ_fL1_dIuf5jk3P5DiJdVfQMqA
Message-ID: <CAMm+Lwggx42sC1-RaVmACpW3wqKEYsMwrmibXCO3Qe5c1sUQHA@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
To: Ben Laurie <benl@google.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/LNfZQBBgGNJCm4iXnmFHbRLxkSU
Cc: "trans@ietf.org" <trans@ietf.org>, "Osterweil, Eric" <eosterweil@verisign.com>
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: Fri, 23 May 2014 13:12:30 -0000

But Ben, DNSSEC is predicated on the article of faith that DNS
Registrars will never ever make mistakes, get hacked or be run by the
Russian or Ukrainian mafia.

The fact that we have more examples of all of those than CAs being
breached is not going to affect an ideological commitment.

On Fri, May 23, 2014 at 9:00 AM, Ben Laurie <benl@google.com> wrote:
>
>
>
> On 22 May 2014 18:32, Osterweil, Eric <eosterweil@verisign.com> wrote:
>>
>>
>> On May 22, 2014, at 1:21 PM, Stephen Kent <kent@bbn.com>
>>  wrote:
>>
>> > Nico,
>> >> DNSSEC is a PKI [of sorts; please, no need to pick nits about that].
>> > agreed.
>> >> It stands to reason that DNSSEC should have similar trust problems as
>> >> PKIX.  I believe it does indeed.
>> > PKIX, per se, does not have the trust problems that seem to motivate
>> > CT; the Web PKI does. That PKI has always had a serious problem because
>> > any TA can issue a cert for any Subject, irrespective of the Subject
>> > name.
>> > because DNSSEC intrinsically incorporate the equivalent of PKIX Name
>> > Constraints, it does not suffer from that specific problem. That's not
>> > to
>> > say that mis-issuance is not possible in DNSSEC, but rather that its
>> > effects are more limited.
>> >> It follows that things like CT that we're applying to PKIX should be
>> >> applied to DNSSEC as well, where possible.
>> > maybe.
>> >> I don't see any reason why CT couldn't be extended to DNSSEC.  IMO, it
>> >> should be done.
>> > I'll defer to DNS experts on that.
>>
>> 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.
>
>
> I disagree: the purpose of CT is to ensure that those who can mess with the
> signing chain are monitored for correct behaviour. How people get into the
> signing chain does not alter the need to monitor their correct behaviour.
>
>
>>
>>
>> Eric
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
>
>
> --
> Certificate Transparency is hiring! Let me know if you're interested.
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>