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

Ben Laurie <benl@google.com> Wed, 28 May 2014 11:16 UTC

Return-Path: <benl@google.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 2CD871A0084 for <trans@ietfa.amsl.com>; Wed, 28 May 2014 04:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.729
X-Spam-Level:
X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, 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 KYJT8JLb-DUR for <trans@ietfa.amsl.com>; Wed, 28 May 2014 04:16:39 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B4A1A0080 for <trans@ietf.org>; Wed, 28 May 2014 04:16:38 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id ij19so12122724vcb.14 for <trans@ietf.org>; Wed, 28 May 2014 04:16:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0OyO1YMz9bM2VS7WjWzY0AdSVuKvwTNyTWhJYl3Tvzc=; b=o5rjN+1OvgUm7UbbCN+YdX5bZ5qDUMyH28qIxLdsMJi2czFKAN+xoVl7kwjLYeMFrq HQWKAAWXJRZefSXAyTI0xIUqO0xhz6CTQ4IwiUMHtj/2qBZc1zE2w5d2zHYxbSjrdi63 MHG7Fvv/G9ZoQ6uBhNfjw8eCLgsHRVG2u4bABSoS8NQdbfMRSgXpTQEV2jO5o0n9TQhY tD7KryAfqGzq4jH5+ba2to/Dn8tqhaQKdWMWwjtDvYdXoukNv5yvPA1NxqMBlXqRs8yE N3GNRC8Rhx1vXUJm23xLksU7aGdqE0YyNKAdXIW/WEEzmPTKtwOpA4L2dEQ6cWvE20kk bZXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0OyO1YMz9bM2VS7WjWzY0AdSVuKvwTNyTWhJYl3Tvzc=; b=IypIeGB4+6660aJhXWvpMQ7V5VRHhsc6hcClYCyyls8J1SfbE0c5fTE3sNI79eQrdl lvIMo484O7rsGQkA3csKStUueVxKg9dXh59yMY/dYF9GV5V/B5Uf249gdXVGHJ/qQUul 3j0hNO2CXXQqUzNJ+2/yosG7P9PSxXiO5Iw0PD8GwZzLXhmh+UsGnblZ+6A/R9gmCi8F aCVj2r3Rt+1wTOEwCugVu8wP7De1KJfId/7Pmis+NHaOBnfWbM3pVVpUawMQ33i+pb1d HsC3wRpwceFUX+BuJEvbdfYCjvw2ty1F8xfOn0U2yDF6keLf+0tKgd8qJToNmsqyHEwp Ufkw==
X-Gm-Message-State: ALoCoQlOlTtp91PCHG/bZWz10MxNXZiNpKJjrttLIZqQeyyT4FRfLIMLMC0q5EQIKJu8qMZDEpHz
MIME-Version: 1.0
X-Received: by 10.52.138.14 with SMTP id qm14mr797199vdb.49.1401275794758; Wed, 28 May 2014 04:16:34 -0700 (PDT)
Received: by 10.52.107.132 with HTTP; Wed, 28 May 2014 04:16:34 -0700 (PDT)
In-Reply-To: <763539E260C37C46A0D6B340B5434C3B09854BEA@AEX06.ejsarea.net>
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> <CADqLbzJdCoULnaaa_LLois49yxFTqtmMgo7TUabCN6UEXbN7kg@mail.gmail.com> <763539E260C37C46A0D6B340B5434C3B09854BEA@AEX06.ejsarea.net>
Date: Wed, 28 May 2014 12:16:34 +0100
Message-ID: <CABrd9SSmVY4YMcDMUj3EYyuSBDN__eGKh3GFzVadG1JEHE9ieQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: =?UTF-8?Q?Barreira_Iglesias=2C_I=C3=B1igo?= <i-barreira@izenpe.net>
Content-Type: multipart/related; boundary=bcaec51b1daffae51e04fa73f153
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/vLcjqARWeeOGpq7sSNfVLmMltMU
Cc: "trans@ietf.org" <trans@ietf.org>, Dmitry Belyavsky <beldmit@gmail.com>, Stephen Kent <kent@bbn.com>
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: Wed, 28 May 2014 11:16:41 -0000

On 27 May 2014 15:47, <i-barreira@izenpe.net> wrote:

> Hi,
>
>
>
> I have some other questions
>
> -          What if a CA can´t belong or it´s not accepted in any log
> server?
>
I would assume that in the very worst case CAs could agree with each other
to log in each other's servers. But I strongly suspect this is not going to
be a problem.

> -          What if you need 3 logs for an EV and only get 2 for whatever
> reasons?
>
Then you had better get a third.


> -          Who´s managing that procedure to accept log servers? Google?
>
For Chrome: yes, Google will.

> Are they going to be registered/publicly available for CAs to choose?
>
Yes.


>
>
> Regards
>
>
>
>
>
> *Iñigo Barreira*
> Responsable del Área técnica
> i-barreira@izenpe.net
>
> 945067705
>
>
>
> [image: Descripción: cid:image001.png@01CE3152.B4804EB0]
>
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
> egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea
> gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi
> erantzuna. KONTUZ!
> ATENCION! Este mensaje contiene informacion privilegiada o confidencial a
> la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por
> error le agradeceriamos que no hiciera uso de la informacion y que se
> pusiese en contacto con el remitente.
>
>
>
> *De:* Trans [mailto:trans-bounces@ietf.org] *En nombre de *Dmitry
> Belyavsky
> *Enviado el:* martes, 27 de mayo de 2014 16:33
> *Para:* Stephen Kent
> *CC:* trans@ietf.org
> *Asunto:* Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs
> CT)
>
>
>
> 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
>
> a.    allow user to accept the cert without CT providing warning about
> absence of CT
>
> b.    allow user to specify absence of log for this or that domain
> (non-public suffix)
>
> c.    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.
>
> d.    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 list
>
> Trans@ietf.org
>
> https://www.ietf.org/mailman/listinfo/trans
>
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>
>
>
> --
> SY, Dmitry Belyavsky
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>


-- 
Certificate Transparency is hiring! Let me know if you're interested.