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

Dmitry Belyavsky <beldmit@gmail.com> Tue, 17 June 2014 08:10 UTC

Return-Path: <beldmit@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 43F361A030D for <trans@ietfa.amsl.com>; Tue, 17 Jun 2014 01:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 bEn4-ZVLkeU2 for <trans@ietfa.amsl.com>; Tue, 17 Jun 2014 01:10:41 -0700 (PDT)
Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B795D1A030A for <trans@ietf.org>; Tue, 17 Jun 2014 01:10:41 -0700 (PDT)
Received: by mail-yh0-f44.google.com with SMTP id f10so5228449yha.3 for <trans@ietf.org>; Tue, 17 Jun 2014 01:10:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ODyUeSVq3hksgg1EN6HLGo5c/kQcjs9RKLKA/WzbHrA=; b=MYexrMPRhe8641yZK9xUC/CIVX2DKSGdUDzsDKu2VqlNja0EajXzSD2JSFiOQQbQbk 0Dxk+h03uZk9IQrFfQzysKVjiF6QiJR44l3bvXdnChXGiyTEZVz5pgbcN1bV/wMsa2y+ Vtws4/UQL/1Rt64vh+YoAH4wgCxHwGy4pgXeQ8oVPfPIRZNo5VYFC4IZ06g1gbaIza2u SUyv18gftngRRnyEEra16ttbctk3g4TXsY3pVietU3ks4CmgLtI0I3nuYXEHRM3F4076 8BMwYBZ47tImu5bLbZCqpxNGOuTU54mCexfW99HzUeRReYEZvZtjpenoB5tIFBt1w1v3 bFPA==
MIME-Version: 1.0
X-Received: by 10.236.26.72 with SMTP id b48mr42144467yha.59.1402992641025; Tue, 17 Jun 2014 01:10:41 -0700 (PDT)
Received: by 10.170.120.2 with HTTP; Tue, 17 Jun 2014 01:10:40 -0700 (PDT)
In-Reply-To: <539F408B.5050600@bbn.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> <539F408B.5050600@bbn.com>
Date: Tue, 17 Jun 2014 12:10:40 +0400
Message-ID: <CADqLbzKwSFkzhRWV5AjSzcb66ASF3DWGZ69bxnqZaPy9Vd5q2g@mail.gmail.com>
From: Dmitry Belyavsky <beldmit@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary=089e01495296fdad2104fc03ad16
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/YYH4sWfpyg4ZNUjlpMtbglGqzyw
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: Tue, 17 Jun 2014 08:10:44 -0000

Hello Stephen,

Thank you for your reply!
My letter was composed as an answer questions you asked, so not all of my
points are in the scope of IETF.

On Mon, Jun 16, 2014 at 11:07 PM, Stephen Kent <kent@bbn.com> wrote:

>  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.
>

I think that the document should be corrected and optional algorithms
should be taken into account too.


>
>
>    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.
>

Yes.


>
>
>
>    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.
>

Yes.

>
>
>    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.
>

So we need to specify these browser interface requirements, don't we?


>
>
>    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?
>

Yes, thank you for a correct wording. IMHO, The cert MUST be rejected if
any of SCTs is signed incorrectly. If


-- 
SY, Dmitry Belyavsky