Re: [Trans] Precertificate format

Stephen Kent <kent@bbn.com> Thu, 11 September 2014 18:20 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 E0B161A8A52 for <trans@ietfa.amsl.com>; Thu, 11 Sep 2014 11:20:18 -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 DAXI6fJ_WJ18 for <trans@ietfa.amsl.com>; Thu, 11 Sep 2014 11:20:17 -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 BDD7E1A8A10 for <trans@ietf.org>; Thu, 11 Sep 2014 11:15:17 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:56256 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XS8u3-0002cp-3T for trans@ietf.org; Thu, 11 Sep 2014 14:15:31 -0400
Message-ID: <5411E6B4.5040401@bbn.com>
Date: Thu, 11 Sep 2014 14:15:16 -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" <trans@ietf.org>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <540E28FD.7050809@gmail.com> <540ECD3A.4040704@primekey.se> <540F4598.5010505@bbn.com> <CABrd9SSg5=wuierLoqAU00pMHxgGx+=ai5mHv4u5t6zm43yDWg@mail.gmail.com> <5410779A.20209@bbn.com> <CABrd9STnjqDBF4-5ABJ86M_d0bwRyjRNjRW6Hnj9UpeYC7Xz9A@mail.gmail.com> <5411BDE4.1060508@bbn.com> <CABrd9STAHzg_KJi=nA7hsvz+k0SMS+bg6c3hcBtUwfOUm=hqTQ@mail.gmail.com>
In-Reply-To: <CABrd9STAHzg_KJi=nA7hsvz+k0SMS+bg6c3hcBtUwfOUm=hqTQ@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/MKe8jk8cg0dqn_bJcjfd2vfiPwE
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: Thu, 11 Sep 2014 18:20:19 -0000

Ben,

> ...
> I managed to miss that proposal. I've found it now.
>
> There seems to be a flaw: if I'm an evil CA wishing to issue an evil
> certificate, I simply log a precert, minus serial, get an SCT*, log a
> certificate containing that SCT*, which I then revoke when requested
> to do so,
>
> In order to attack a user with the evil certificate, I simply issue a
> second copy with a different serial, containing the original SCT*, and
> the certificate works. Yes, the discrepancy should be discovered in
> audit, but that is a significantly weaker protection than we get if
> the serial is included in the pre-certificate.
I agree that the attack you describe would work, but it needs to be
evaluated in the overall context of how CT works in the case of several
different types of attack scenarios. The threat model and attack model text
I just submitted provides a first cut at describing such scenarios. Once we
get agreement on that model, let's revisit the question of whether the 
vulnerability
you noted above is significant relative to other residual vulnerabilities.
> Also this adds quite a lot of complexity in order to allow what
> appears to be, so far, an entirely theoretical use case.
I do know that when VeriSign used the Safekeyper HSM to issue all of its 
certs
(which it did for several years), it would have been impossible to 
generate a
pre-cert and matching final cert. So, the concern I raise would have 
been a show
stopper for them in that time frame. I guess it depends on how one defines a
"theoretical use case" :-)

Separately, the pre-cert model, requires a CA to issue two certs with 
the same
serial number, which is a bad security practice. I think it makes sense to
re-consider forcing CAs to behave this way.

Steve