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

Dmitry Belyavsky <beldmit@gmail.com> Tue, 17 June 2014 09:55 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 014131A033E for <trans@ietfa.amsl.com>; Tue, 17 Jun 2014 02:55:08 -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 Mu1vRP76_9vA for <trans@ietfa.amsl.com>; Tue, 17 Jun 2014 02:55:05 -0700 (PDT)
Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF451A0337 for <trans@ietf.org>; Tue, 17 Jun 2014 02:55:05 -0700 (PDT)
Received: by mail-yh0-f50.google.com with SMTP id t59so5296830yho.37 for <trans@ietf.org>; Tue, 17 Jun 2014 02:55:05 -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=F9y0ABK2vNNaHu/8GQhlZaaOt4aIdamuZM9A+6IZFI0=; b=XyBuJ3s2sxPpvY7Iv0nQashfmBZU22DdDScq4tsVE6o7krIZHLIy3fh6dZa7DaoMor rkhGylVhQEiDLjItHhlBjvzFGONlPLjN2TctzFdhWo+xQI3abILEh3e09prG/c48RCzZ rez7VAWNMEJu/w357jhnJwUTLhnWW8oxyvYaxvZZyGufkxvrrsuge4vlSAv8EkgxtXt4 fXMDuPa4hiO3knEYHq8OAoySm5l5Hqduf8tgJPGJJLh9e9CFM/fqaPVp31oapmN7rBCa wfcXjwZfGu+BtOQI7rizj0j2m/qLn2n2cm3r5HzoEgc5ruhLuideROTGZ0+SXSKb0ils GDtw==
MIME-Version: 1.0
X-Received: by 10.236.113.69 with SMTP id z45mr43001032yhg.0.1402998904917; Tue, 17 Jun 2014 02:55:04 -0700 (PDT)
Received: by 10.170.120.2 with HTTP; Tue, 17 Jun 2014 02:55:04 -0700 (PDT)
In-Reply-To: <CABrd9SS51Sh93rvgdYaCpidYs1U7hpQofGmp0oJX9f2x5TXqNw@mail.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> <539F408B.5050600@bbn.com> <CABrd9SS51Sh93rvgdYaCpidYs1U7hpQofGmp0oJX9f2x5TXqNw@mail.gmail.com>
Date: Tue, 17 Jun 2014 13:55:04 +0400
Message-ID: <CADqLbzLw3sqy3eD=ZZ-JVYJo5pT+8xwKfH+Jnr+O18orOyo3LA@mail.gmail.com>
From: Dmitry Belyavsky <beldmit@gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary=20cf3010eb11591af804fc05235d
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/F29HnpRQXsjsI332q6qhrBc7xsM
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: Tue, 17 Jun 2014 09:55:08 -0000

Hello Ben,


On Tue, Jun 17, 2014 at 1:34 PM, Ben Laurie <benl@google.com> wrote:

>
>
>
> On 16 June 2014 20:07, Stephen Kent <kent@bbn.com> wrote:
>>
>>
>>
>>
>>    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.
>>
>
> I agree. However, there is a security risk here: a client that includes a
> log that is not audited has opened themselves up to abuse via mis-issue.
>

Well, now a client is able to add bad CA as trusted. I do not see extra
security risks here.


>
>
>>
>
>>
>>    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.
>>
>
> The IETF is far too slow-moving to get involved in browser UI, at least
> for new/experimental features. Nor do I get much sense that we have the
> necessary expertise in this WG.
>

I agree. But I think that it's a correct behavior of any CT-compliant
client. Browsers, being interactive, can suggest an user to make a choice
(yes, he will push the button "Add security exception" in 99%).
Non-interactive software is to have command-line settings/config/etc.



>
>>
>>
>>    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?
>>
>
> For EV certificates, there will be no warning in Chromium: instead, there
> will be no EV indication.
>

Even in case of invalid SCT?


>
> We have not yet decided exactly how things will work when we start
> requiring CT for all certificates.
>
>
>>
>> Steve
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>>
>
>
> --
> Certificate Transparency is hiring! Let me know if you're interested.
>



-- 
SY, Dmitry Belyavsky