Re: [Trans] Precertificate format

Stephen Kent <kent@bbn.com> Wed, 10 September 2014 16:07 UTC

Return-Path: <kent@bbn.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 1803F1A8766 for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 09:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level:
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 QhAJK0GIvW1F for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 09:07:22 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C508E1A8764 for <trans@ietf.org>; Wed, 10 Sep 2014 09:07:21 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:52081 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XRkQh-000JOD-2h for trans@ietf.org; Wed, 10 Sep 2014 12:07:35 -0400
Message-ID: <54107737.4000000@bbn.com>
Date: Wed, 10 Sep 2014 12:07:19 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com><CAFewVt5kZqw0-W7PqtFHe7yJUsR9PqVJ6C74ZShgo0qs19wLjA@mail.gmail.com><544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><CAFewVt4FpwpXhcrW0mM6atASBh6k9jDb3DCCsDBNppJBrkjwXQ@mail.gmail.com><4c67a3bd-ff97-43d3-8e1f-449954b59f02@email.android.com> <CACsn0ckPm2k9q-aFZJPJLBNVXSwa_KS-pjdXDj6UU4VRGttsSw@mail.gmail.com> <541013D1.8020006@comodo.com>
In-Reply-To: <541013D1.8020006@comodo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/DVSHRDeUO78_aT4obN2I0rrCMLg
Subject: Re: [Trans] Precertificate format
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, 10 Sep 2014 16:07:27 -0000

tRob,

> ...
> Hi Watson.
>
> Without Precertificates, we would have to wait for all of the world's 
> TLS Servers to be updated to support the RFC6962 TLS extension and/or 
> OCSP Stapling before TLS Clients would then be able/willing to abort 
> TLS handshakes when an SCT is not provided. We don't want to have to 
> wait that long!
You noted this rationale previously, when I asked whether we really need 
pre-certs, and
I failed to reply to your message. (lost in the inbox clutter)

I understand the desire to reduced the delay in deployment.

However, the specific mechanism you mentioned, a TLS client aborting a 
handshake because
of a lack of an SCT (embedded or passed explicitly in the handshake) is 
still being debated.
Specifically, I noted that this hard fail approach, does not seem 
compatible with an
incremental deployment model, absent a lot of details. During the IETF 
meeting in Toronto,
Ben stated that he agreed that an incremental deployment model was 
desirable, and thus
requirements for TLS client behavior need to be revisited.

Steve