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

Dmitry Belyavsky <beldmit@gmail.com> Tue, 27 May 2014 14:32 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 ACA561A0366 for <trans@ietfa.amsl.com>; Tue, 27 May 2014 07:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.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, 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 7c6KPlxYTaaz for <trans@ietfa.amsl.com>; Tue, 27 May 2014 07:32:51 -0700 (PDT)
Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262031A034E for <trans@ietf.org>; Tue, 27 May 2014 07:32:51 -0700 (PDT)
Received: by mail-yh0-f52.google.com with SMTP id z6so7483535yhz.11 for <trans@ietf.org>; Tue, 27 May 2014 07:32:47 -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=CIWXjjy1wyn/o1PgF4CsQMBHwx1ujmbyvU7Xink6qpk=; b=OXr7Hvkg8IdI41JqEDXpe1/t0A6d8XsrNeArlnDVQ/7IC7qCNTYeCNJZecgap+c6i6 n0bbeYxXeDuSPDCLoGbCMZjR6X33+C8E2cgbq3+PTDQ3bbXoib7yvfhs8IBFTCWq0qZg rd/WpCRO5YNmx2iVAYx0osxGhdru4u1DEUk3VTO8lN4Qhzcvu4ncdwHvUorBdAychBjv w6QBRLeWB+UDO9BJwiX1QNDWEhO2SC2Rt6GyvcNiBwTWiwsdv58Nz6/FHUtSHBOXXERQ o+f73wItRVo0XXKEdjtw8UCNQGE/hB66/ZWTvQWy2GGWnmRyykKUL8/eswoj4WIOvJDi i39Q==
MIME-Version: 1.0
X-Received: by 10.236.93.195 with SMTP id l43mr47294920yhf.40.1401201167535; Tue, 27 May 2014 07:32:47 -0700 (PDT)
Received: by 10.170.91.85 with HTTP; Tue, 27 May 2014 07:32:47 -0700 (PDT)
In-Reply-To: <537E3E13.30709@bbn.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <CAMm+Lwieij8Tm8V-gpE0eAfwie1dgtFL_Ga8dPkJFKJKLQDAcA@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>
Date: Tue, 27 May 2014 18:32:47 +0400
Message-ID: <CADqLbzJdCoULnaaa_LLois49yxFTqtmMgo7TUabCN6UEXbN7kg@mail.gmail.com>
From: Dmitry Belyavsky <beldmit@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="20cf3010e34dd9968e04fa629102"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/1jtHK9kdMjJKps_awJ6tz2tEERs
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, 27 May 2014 14:32:53 -0000

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

   Any log-server can select the list of acceptable CAs. I think that
   “important logs” should cover all the CAs supported by major browsers.
   3.

   Any log server can select the algorithm of hash for Merkle Tree and for
   its key signing the SCTs.
   4.

   Each browser should provide an editable way of managing logs. By default
   it should be a reasonable subset of “important” logs.
   5.

   Each CA can be accepted by more than one log.
   6.

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

   I think that warning is acceptable in case of an absence of SCTs, but in
   case of cryptographic errors the error should be generated.





On Thu, May 22, 2014 at 10:12 PM, Stephen Kent <kent@bbn.com> wrote:

>  Dimitry,
>
> Thanks for posting the list below.
>
> I have become very concerned that the doc we're working on describes a
> mechanism,
> but we seem to lack a good description of the architectural context in
> which CT
> is supposed to work. The intro text for the I-D is not at all adequate for
> this.
> Maybe the charter for this WG would have included the need to publish a
> doc of
> this sort if we had gone through the usual BoF process :-).
>
> I'd like to see a doc that addresses a number of points that are now
> beginning to
> be raised by several folks:
>     - who is expected to operate logs, does every log cover all CAs, is one
> log per CA (even if operated by someone else) adequate, how are users
> supposed to
> select logs (what the UI like?), etc.
>     - how are browsers expected to deal with missing SCTs, missing or
> non-matching
> log entries, (crypto) invalid log entries, etc. are browser actions
> supposed to be
> effect in real time or is this deferred activity model?
>     - hard fail vs. warnings for CT "exceptions?"
>     - how are browsers expected to deal with certs from CAs that are not
> part of the Web PKI?
>     - what are the fallback plans if some number of the Web PKI CAs elect
> to not
> participate?
>     - same question for major browser vendors?
>     - what are the plans for alg aglity, for logs?
>
> CT is a system, not just a handful of mechanisms. It needs to be described
> that way.
>
> Although not perfect, I suggest the set of RFCs that describe the RPKI is
> illustrative
> of the many aspects of a global system (with PKI aspects) that need to be
> documented.
>
> Steve
>
>
>>
>  Here are my ideas about "strict" behaviour of the TLS client:
>
>  ==============
>  TLS clients supporting CT are supposed to have a preconfigured set of
> logs and
> their public keys.
>
>  In addition to normal validation of the certificate and its chain, they
> should
> validate the SCTs received during the TLS connection.
>
>  The client fully conforming to the specification SHOULD perform the
> following
> steps before establishing the connection for every certificate in the
> chain:
>
>  1. If no SCTs are provided, the client SHOULD reject the connection.
>
>  2. The client MUST ignore all the SCTs provided by unknown logs.
>
>  3. TLS clients MUST reject SCTs whose timestamp is in the future.
>
>  4. If no SCTs has left after steps 2-3, the client SHOULD reject the
> connection.
>
>  5. If any of SCTs left after steps 2-3 has invalid signature, the client
> SHOULD reject the connection.
>
>  Client MAY check whether the certificate is present in the log
> corresponding to the passed SCT.
> If the certificate is not present in the log, the connection MUST be
> rejected.
>  =============
>
>  Can it be a starting point or you want something else?
>
>  --
> SY, Dmitry Belyavsky
>
>
> _______________________________________________
> Trans mailing listTrans@ietf.orghttps://www.ietf.org/mailman/listinfo/trans
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>


-- 
SY, Dmitry Belyavsky