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

Ben Laurie <benl@google.com> Tue, 17 June 2014 09:34 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 5B8151A033D for <trans@ietfa.amsl.com>; Tue, 17 Jun 2014 02:34:10 -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 uzJiisMqvEK1 for <trans@ietfa.amsl.com>; Tue, 17 Jun 2014 02:34:07 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D811A033C for <trans@ietf.org>; Tue, 17 Jun 2014 02:34:07 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id il7so6046787vcb.41 for <trans@ietf.org>; Tue, 17 Jun 2014 02:34:06 -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=ipAiUqbINAUz3So3vjGcoB/aYdKGWrC915KDytk8JoQ=; b=T5lFWj09Iu6WKMwuRu6tkpipQcVSBki65IvP/ct1ufv6Obx2pRlzNZH0gtF8z8Hf2o lXXSyJGf1b78vWBrlguWmGzW8SqNI2TTckKdAJgJkHB+bRIvVeTtO+cpHDuUfdThcOVK OWT7vBAG2sYbCKriQrVA+TAdSX+NrVmPg2MK4rnaxFTITe+8szbcTsWdTrl6gByuKRLN y4pzXHe6Y6snv+Nj8bUfK9b29/9Hx2AyJHcZN9xh06hzbzNRaDXIy9WJneetdEzKzKTX 8yz3HbfpzzToGjlSQZJ1HmDhpbugCcGJUczUT9y8nhUpelFVaIYdXTaTcAGs4WGuUrkq cUAQ==
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=ipAiUqbINAUz3So3vjGcoB/aYdKGWrC915KDytk8JoQ=; b=UsCjjVbMXMYjGogLW1Sj5wHiMQYPd+OZ7t53wTsshJJWq+Ek6pXGR9yPtikTC0HAlj H1ul5eg71hZqbWnUhEkuFjWSpFjwkr/aNc+D4XytQAF6hhvZfLK026WERP4q0cLa8U4e vVM0geEFSO4Oz/w8Z8tZaLQAqV9OiwE/L+ElO8j/q6yvsooQ9rSRG1VP6r/m4RDHnuc5 rNhG9/NFpdIWUp8k08Ch08/HAf448svFLt1o1wfSYUgMU5y6WeoBj4ScINrKjj6JVkql iLRETTPs7UHn5sMIQsxJvVd/YZRXoFQk/J9w+9tCBZdowS7/k9Egy8/abWLbhR3pBb1n 9OWw==
X-Gm-Message-State: ALoCoQnuaWCEkbN4hmWafwzYZcWtF0PfvhaptjzH1tmX/svUy5AZSv4LbvtuHmOtWRcoaWujTUeg
MIME-Version: 1.0
X-Received: by 10.220.80.70 with SMTP id s6mr4243vck.44.1402997646279; Tue, 17 Jun 2014 02:34:06 -0700 (PDT)
Received: by 10.52.29.179 with HTTP; Tue, 17 Jun 2014 02:34:06 -0700 (PDT)
In-Reply-To: <539F408B.5050600@bbn.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>
Date: Tue, 17 Jun 2014 10:34:06 +0100
Message-ID: <CABrd9SS51Sh93rvgdYaCpidYs1U7hpQofGmp0oJX9f2x5TXqNw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary=047d7b3a8f8453e85e04fc04d814
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/qNqb5xY7fMqkURYphVVodAalFog
Cc: "trans@ietf.org" <trans@ietf.org>, Dmitry Belyavsky <beldmit@gmail.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:34:10 -0000

On 16 June 2014 20:07, Stephen Kent <kent@bbn.com> wrote:

>  Dmitry,
>
> My replies are inline. sorry that my mail program renumbered each of your
> bullets as I inserted my replies :-(.
>
>
>   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.
>
>  As you note, the notion of establishing some logs as "important" would
> borrow from the
> CABF, but we're the IETF and this is intended to be an IETF standard. So,
> I think this
> doc needs to address this issue in a fashion consistent with IETF
> procedures.
>

How would this work? From my POV it seems that users choose the logs they
pay attention to, probably mostly via choices made by their browser vendor.
How would the IETF get involved in that process?


>
>
>    1.
>
>    Any log-server can select the list of acceptable CAs. I think that
>    “important logs” should cover all the CAs supported by major browsers.
>
>  The doc suggests this, but again, this has a CABF feel to it. IETF
> standards do not endorse
> implementations and use decisions by vendors to drive standards.
>

Again, what do you suggest as an alternative?


>
>
>    1.
>
>    Any log server can select the algorithm of hash for Merkle Tree and
>    for its key signing the SCTs.
>
>  That's not what the doc says; it establishes two MTI algs that all
> clients must support, while log operators are allowed to pick form between
> the two. This seems a bit backwards to me, in that it imposes the greater
> burden on the larger # of implementations.
>

This seems like physics to me. You might want it to be the other way around
(we could debate the burden, but that seems beside the point), but I don't
see how it can be.


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


>
>
>    1.
>
>    Each CA can be accepted by more than one log.
>
>  "Might be" is the more accurate characterization, based on the current
> doc. There is no requirement that any log operator accept submissions from
> a specific CA. Each log operator indicates what CAs/TAs it supports.
>

Again, I don't see how you propose the IETF involves itself in this.
Clearly we can't say "logs must accept all CAs" because that defeats the
anti-spam objective of limiting the list of CAs.


>
>

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


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

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.