Re: [Trans] DNSSEC also needs CT

Stephen Kent <kent@bbn.com> Mon, 02 June 2014 17:20 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 B39A21A0253 for <trans@ietfa.amsl.com>; Mon, 2 Jun 2014 10:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 By_v8VSy6K6n for <trans@ietfa.amsl.com>; Mon, 2 Jun 2014 10:20:23 -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 39EC21A01ED for <trans@ietf.org>; Mon, 2 Jun 2014 10:20:23 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:36785 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1WrVuD-000PHc-8j for trans@ietf.org; Mon, 02 Jun 2014 13:20:17 -0400
Message-ID: <538CB250.6080201@bbn.com>
Date: Mon, 02 Jun 2014 13:20:16 -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: trans@ietf.org
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <537E3229.4070402@bbn.com> <CAMm+Lwjbi5t7Efgyf4cNdh-2=DqbeSE4xgxf3TchPZBAyERwug@mail.gmail.com> <537E3E17.8000901@bbn.com> <CAK3OfOgE-0jhSfPBn+EoWw5CJx+jLU6vcKC3k=3NHGNkTDouAw@mail.gmail.com> <537E467C.7010405@bbn.com> <CAK3OfOjJKQ4f5dzb6dRZ46e2szq1mUyygm1Me+nvx2vJeC6K6g@mail.gmail.com>
In-Reply-To: <CAK3OfOjJKQ4f5dzb6dRZ46e2szq1mUyygm1Me+nvx2vJeC6K6g@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/dFBFyhdgm_QrmIQPvu9LJsRUoAA
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:20:24 -0000

Nico,
> On Thu, May 22, 2014 at 1:48 PM, Stephen Kent <kent@bbn.com> wrote:
>>>> That's a very confusing last phrase.
>>> I had no problem reading it.
>>>
>> a literal reading of it is as sarcasm. If that's PHB's intent, fine, but
>> I just wanted to verify that there was no typo.
> I saw no sarcasm in it.
I was just confused, as I said. PHB's reply was helpful.
>
>>> In other words, your concern is about CT in general, not DNSSEC in
>>> particular.  Sounds like a separable issue to me. But if CT makes sense then
>>> it makes sense for DNSSEC.
>>>
>> yes, my complaint about a lack of a doc describing CT architecture is not
>> specific to the CT for DNSSEC discussion.
> We agree.
OK.
>
>> CT may be appropriate for the Web PKI, w/o being a great idea for DNSSEC.
> I take it you concede that lack of name constraints isn't the only
> reason to want CT.
agreed.
> I'll concede that CT for DNSSEC might not be a good idea.  Did I ever
> say it is?  I started the discussion with an inference: CT is for
> PKIs, DNSSEC is a PKI, therefore CT fits DNSSEC, discuss.
I thought you did. I think CT for the Web PKI needs is missing an arch
doc, and absent that doc it's now clear how good CT is for that case.
This I consider it premature to suggest CT for DNSSEC si an obvious next 
step,
as some have suggested.
>
>> Until we have a doc that describes the architecture, we can't evaluate how
>> good
>> it is in either context.
> We have a doc; it's missing important things.  I agree.  But I think
> we can have some of this discussion given what we know now.  Indeed,
> we've been having this discussion, and important things have come up
> (privacy protection, spam).
The experimental RFC does not provide a comprehensive problem statement,
a clear description of all of the elements of a proposed solution, an
explicit discussion of all of the assumptions that appear to underlie the
design, i.e., what must happen for CT achieve its goals, and an
analysis of what happens if some (implicit) assumptions are not satisfied.

I'm going to develop what I see as the missing arch doc, to elicit 
feedback from
the WG and the RFC authors. The WG can decide whether this is necessary, 
but I
believe the exercise will, in any case, be useful.

Steve