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

Ben Laurie <benl@google.com> Wed, 28 May 2014 11:12 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 E27EC1A0942 for <trans@ietfa.amsl.com>; Wed, 28 May 2014 04:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level:
X-Spam-Status: No, score=-2.029 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, 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 LSabooJ4Akaj for <trans@ietfa.amsl.com>; Wed, 28 May 2014 04:12:44 -0700 (PDT)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF911A0952 for <trans@ietf.org>; Wed, 28 May 2014 04:12:01 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id hq11so6404994vcb.19 for <trans@ietf.org>; Wed, 28 May 2014 04:11:57 -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=wIM71FiIrksKhyp5p2EQel4ycu/MVukzCWLiwkBLcMA=; b=baRKLSDJSSTKFL+j+BAelrsTwrIAZWrgRjNzSYtvsHCeC2qOWjdlsfRRTe7UfQ593e d8rn5MRJSDnbs/KpibjQgiYdil6l4H1LoRPQpMy3C4VsTLA9fNlHhSzQqWajeaLM3pEA Kwq08UPzLecWR7HngrD2LAoUX0zNhCWCNej2NZAY1r6DQk7vyT1plJD4GEkvtAsOkeji fUAHaQadawTqQEPMnLSsV//+zENzrIxG/eLsPw/o14Ui8aHboBD1ahe+4gefnT8z6kqQ ey1R1CpE+A9eD0Mm5wu9etVbAYfEywaYcqMJQEcLHeqtjURwO0s1HH8nATfTkJznJrgT uFrQ==
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=wIM71FiIrksKhyp5p2EQel4ycu/MVukzCWLiwkBLcMA=; b=G8eT8QiXl6jBOhuMHUpvaUcUKJxKG/VYACrkTi2kpdURP3+Tm1qQRug/h9KwfdE+A9 I9J1VtkYCZvlRRyYSyF9+B2TKRF4y+P7+ZhS0EyOxp/J/7McU3YUU2JyS2bVecp3aAlo OuIRhJNlZTfDF1KHXjUoLPSdDTOZ8vsEAEmUzgQ1g8GBov1PQ0AEVa60SU4WM0Gj6sMd ql6JAdjM2fL3OA2cmLr1NuWYRTEjxencat5hTf8Ttbrpa09LQPqK+9K+wrjKkghzSMdF efC0ZpxPTE083FsetZofY7GJ8mo1tm/vKQm8AB7odfgC1mvw9xLcbvKlUfsn7GhoxznZ u1kg==
X-Gm-Message-State: ALoCoQmr4nljOr3lpbBEJGLPyS4iXaiKBtyr5itJm2Sz5albjeUXFLW6Ng/gaIXE4lLb6ISSf2e6
MIME-Version: 1.0
X-Received: by 10.58.74.38 with SMTP id q6mr32457485vev.7.1401275517258; Wed, 28 May 2014 04:11:57 -0700 (PDT)
Received: by 10.52.107.132 with HTTP; Wed, 28 May 2014 04:11:57 -0700 (PDT)
In-Reply-To: <CADqLbzJdCoULnaaa_LLois49yxFTqtmMgo7TUabCN6UEXbN7kg@mail.gmail.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> <CADqLbzJdCoULnaaa_LLois49yxFTqtmMgo7TUabCN6UEXbN7kg@mail.gmail.com>
Date: Wed, 28 May 2014 12:11:57 +0100
Message-ID: <CABrd9SQyTBTdV5JBqLStGwyoq25fwn8LnV7icDaV0LBDUG3tOQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Dmitry Belyavsky <beldmit@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bacbedc706d0804fa73e19c
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RA6KXbv6h2D4GOLXXOetX4qatoc
Cc: "trans@ietf.org" <trans@ietf.org>, 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:12:48 -0000

On 27 May 2014 15:32, Dmitry Belyavsky <beldmit@gmail.com> wrote:

> 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.
>
>
Google will be publishing its log inclusion policy soon, which covers some
of these points. We have already published our EV/CT plan (
https://docs.google.com/a/google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxjZXJ0aWZpY2F0ZXRyYW5zcGFyZW5jeXxneDo1ZjkwYzYwMjVhYTRmZjY3)TRmZjY3),
which covers some others.

I am not at all convinced that any of them are in scope for
standardisation, though.


>
>
> 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
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>


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