Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT)

Stephen Kent <kent@bbn.com> Mon, 16 June 2014 19:08 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 C310D1A0177 for <trans@ietfa.amsl.com>; Mon, 16 Jun 2014 12:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 CJK-NonXdmBG for <trans@ietfa.amsl.com>; Mon, 16 Jun 2014 12:07:58 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AE11A0199 for <trans@ietf.org>; Mon, 16 Jun 2014 12:07:58 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:51266 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1WwcGG-000DPV-Uu; Mon, 16 Jun 2014 15:08:09 -0400
Message-ID: <539F408B.5050600@bbn.com>
Date: Mon, 16 Jun 2014 15:07:55 -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.6.0
MIME-Version: 1.0
To: Dmitry Belyavsky <beldmit@gmail.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <CAK3OfOiKjY6YyiyeHiFJrecZfj_uQ-2k+KucKnzb9Yt8VCRPOQ@mail.gmail.com> <CAHw9_iKpN7AXfrH6SzroMukrKTPR5z24U9KfWpVW-F2R_wX3ag@mail.gmail.com> <alpine.LFD.2.10.1405101722240.897@bofh.nohats.ca> <CABrd9ST7K-7RGwGD2G+kDcVSceC2ZJ-5Tz2tdp5NWa3cqBK+-w@mail.gmail.com> <CAOe4Ui=nqmCfjBYNE2CJtEs1jnbavpY4Dv-T3FRDdAwAA2dScg@mail.gmail.com> <CAK3OfOiYMJkXVR+QsCzEV0ir6u53coJz0b-JdGGD5bTTz5YcMg@mail.gmail.com> <CAOe4Ui=u0fkm9_nuXx_6gpH6jHM5pBvzjzru9O8y3bpLkA0qmw@mail.gmail.com> <CAK3OfOi6y=QAMXe_2axiavxwR5nS2Uv8SM4JxQHsvEKbUyNGCA@mail.gmail.com> <CAOe4Uimvc6e6u=fJjM1-iaOTepA33Sx5CBjMV9dB8sSLqtZoWA@mail.gmail.com> <CAK3OfOhdhWdGvvhuaGyE_p5kLy0ZX-V5sAXfoLGP_8d8vPJDgg@mail.gmail.com> <5371ACFB.5020604@gmail.com> <CADqLbzLJWSfOOqZaieBijtX7dDR0BaW5doTZtgi=72-VjOUVMg@mail.gmail.com> <537E3E13.30709@bbn.com> <CADqLbzJdCoULnaaa_LLois49yxFTqtmMgo7TUabCN6UEXbN7kg@mail.gmail.com>
In-Reply-To: <CADqLbzJdCoULnaaa_LLois49yxFTqtmMgo7TUabCN6UEXbN7kg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060207010603050706050803"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/gLWNQQ90wd2-9juMQddZjwrr0ng
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Volunteer opportunity! (was Re: 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, 16 Jun 2014 19:08:01 -0000

Dmitry,

My replies are inline. sorry that my mail program renumbered each of 
your bullets as I inserted my replies :-(.

> Hello Stephen,
>
> Here is my understanding of the question you asked.
> Let Ben or Rob fix me if I'm wrong.
>
> 1.
>
>     Anybody is allowed to operate log. But there should be a procedure
>     (similar to CA/Browser forum) which is determined to register log
>     as "important" (we need a better word). There should be not many
>     "important" log servers, I suppose --- otherwise we are to get the
>     same problem as we have with many CAs.
>
As you note, the notion of establishing some logs as "important" would 
borrow from the
CABF, but we're the IETF and this is intended to be an IETF standard. 
So, I think this
doc needs to address this issue in a fashion consistent with IETF 
procedures.
>
> 1.
>
>     Any log-server can select the list of acceptable CAs. I think that
>     "important logs" should cover all the CAs supported by major browsers.
>
The doc suggests this, but again, this has a CABF feel to it. IETF 
standards do not endorse
implementations and use decisions by vendors to drive standards.
>
> 1.
>
>     Any log server can select the algorithm of hash for Merkle Tree
>     and for its key signing the SCTs.
>
That's not what the doc says; it establishes two MTI algs that all 
clients must support, while log operators are allowed to pick form 
between the two. This seems a bit backwards to me, in that it imposes 
the greater burden on the larger # of implementations.
>
> 1.
>
>     Each browser should provide an editable way of managing logs. By
>     default it should be a reasonable subset of "important" logs.
>
The set of "important" logs might not include a CA that is important for 
a set of clients 9since log operators have complete discretion as to 
which CAs they accept) so it ought to be possible for a client to 
include a pointer to logs outside the default set.
>
> 1.
>
>     Each CA can be accepted by more than one log.
>
"Might be" is the more accurate characterization, based on the current 
doc. There is no requirement that any log operator accept submissions 
from a specific CA. Each log operator indicates what CAs/TAs it supports.
>
> 1.
>
>     Browsers should
>
>     1.
>
>         allow user to accept the cert without CT providing warning
>         about absence of CT
>
>     2.
>
>         allow user to specify absence of log for this or that domain
>         (non-public suffix)
>
>     3.
>
>         allow user to a particular log for this or that domain and
>         return an error if there is no SCT for id provided by this log.
>
>     4.
>
>         there should be a procedure of report about log misbehaviour
>         in case of invalid log records
>
These seem like reasonable suggestions, at least to begin, but none of 
them appear in the doc.
I worry that, absent a description of minimum browser management 
interfaces for CT, we have no sense of whether users will be able to 
deal with incremental deployment.
>
> 1.
>
>     I think that warning is acceptable in case of an absence of SCTs,
>     but in case of cryptographic errors the error should be generated.
>
I presume you mean that if there is a crypto error, the cert should be 
rejected, a hard fail, right?

Steve