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

Ben Laurie <benl@google.com> Tue, 17 June 2014 10:15 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 C58DB1A0340 for <trans@ietfa.amsl.com>; Tue, 17 Jun 2014 03:15:12 -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 nZRwT4ww9kLq for <trans@ietfa.amsl.com>; Tue, 17 Jun 2014 03:15:10 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1CA1A033D for <trans@ietf.org>; Tue, 17 Jun 2014 03:15:10 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id ik5so6130750vcb.35 for <trans@ietf.org>; Tue, 17 Jun 2014 03:15:09 -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=faZdNOXxc26gDkTXZQQv/U26oGX4KP09BDfUiUk+rME=; b=Q2qAU7m/ROO3WrhHhmnJCqt1fP8sjN5jbp85JHAuN8jnQ3OLQYqw3UYwkE+Lj7eV8D vww5bmd9z/+pKa/ij5U90bVckt9NYmtKKj9X6F3kBKCRIz4QnuwICd+1Cx8ZJTXhy8eU L+PRC2JkbHEC7R+PSl6dcfcBZpOJ/xMACCwdCVGEZ8XlJ/UbjBdESENYLz0bzO8YdDYT M5cg1rC0dddUm65HkxQxUqlsyfLHGrwrJid+zm5C+onwKqSmDD8zX9KAYiyWY6HHp2pT p4//zkGTzynC2jFlB/OeoG9gMkGCxp7OkE7zIy1cGxx6i0YR1y/u6lGUjy2gTZcjj72E QdPA==
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=faZdNOXxc26gDkTXZQQv/U26oGX4KP09BDfUiUk+rME=; b=FRLpklLYFGTeFwn9XiN6A6ikdPMhbnhPp8decrOOkiv5LQKC3yKfcNukPB7bfvziB2 mk10TcYbG6i/nYj/SybsFJvwOYv/yj9jufVhGBhZJg+71udq6PDEQxfdaC4My1fAA73Z X6ADfLQcsYhiUywKw1z+U7S8ilwRv4EcZHx0gtezTAz8KOC/5yjpbrq1IHeM/2sRq5Xs HXa8W/DF/L+19OUIJ/zAPPBGH1Q1NGpVmYhbCGj9vv9ufXKfmwcLAtHoKWTxXkQ0ANsv bsQ9WJLHspNl0rJB+P9xNaIFeE3OXmUiO4u2sUd+HYwuc5zu5wATi7AVFTx9R8amCMHF ulzw==
X-Gm-Message-State: ALoCoQn1uC7c+nNX5/1YfBri0H4AGwlCIt7OSSBatNLYxOiMGApbr30dUQqSbpXZtgvfbnOvyRt7
MIME-Version: 1.0
X-Received: by 10.220.81.194 with SMTP id y2mr7665118vck.29.1403000109589; Tue, 17 Jun 2014 03:15:09 -0700 (PDT)
Received: by 10.52.29.179 with HTTP; Tue, 17 Jun 2014 03:15:09 -0700 (PDT)
In-Reply-To: <CADqLbzLw3sqy3eD=ZZ-JVYJo5pT+8xwKfH+Jnr+O18orOyo3LA@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> <CADqLbzLw3sqy3eD=ZZ-JVYJo5pT+8xwKfH+Jnr+O18orOyo3LA@mail.gmail.com>
Date: Tue, 17 Jun 2014 11:15:09 +0100
Message-ID: <CABrd9SSW1KxE7wsAQUBBkPwtX1E-am=psdvz2CdDQ57VpbsDuQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Dmitry Belyavsky <beldmit@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2d8602702af04fc056b90
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/8pAqykmshYRNJ45T4PbhSd-u8f4
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 10:15:12 -0000

On 17 June 2014 10:55, Dmitry Belyavsky <beldmit@gmail.com> wrote:

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

Even if I agreed, which I don't (if you can't add extra logs, then the
effect of adding bad CAs is reduced :-), this seems beside the point. It is
a security risk that should be considered.


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

Yes, browsers can suggest a choice. Or they can choose not to.


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

I think if the SCT is invalid, you will be able to tell in the connection
information dropdown, but we will otherwise treat it in the same way as a
missing 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
>



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