IETF Logo Mail Archive

Re: [Trans] can CT defend against dual CA compromise?

Ben Laurie <benl@google.com> Wed, 24 February 2016 14: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 E0CD81B2D9F for <trans@ietfa.amsl.com>; Wed, 24 Feb 2016 06:15:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level:
X-Spam-Status: No, score=-1.384 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.006, SPF_PASS=-0.001] autolearn=no
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 1Mp0C7_Pp4Z2 for <trans@ietfa.amsl.com>; Wed, 24 Feb 2016 06:15:45 -0800 (PST)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467BA1B2CEA for <trans@ietf.org>; Wed, 24 Feb 2016 06:15:45 -0800 (PST)
Received: by mail-io0-x231.google.com with SMTP id 9so40656277iom.1 for <trans@ietf.org>; Wed, 24 Feb 2016 06:15:45 -0800 (PST)
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=/VAv6X0BXvIYUg0pnHsF6E09f4f9Kbche+mfHot/+7Y=; b=NJ1w8q58Omc0RGpcFZCETS9Ahgqkfg2gW+bE9GJu6602VkT5B9C0EAqdSjdQWsRUgH Kjb8EXvMNtwcuGPNDSuiiv19OB4RMN6ljp69vVf0MMxswzpCuvQkFwsJoB+EV67hBV08 l9tnDHTbfly5EG2Afk+5/dktLqdlTA7GC9Q9SaXaYvUwpmY67BVsZZZLfIrXut2ArRcM Go4FzI7mm/CxQj7q0vtHTfD9OS/YhSrRFShLl1OdowqrtBlIvBJ41lQDSfP5aFpca4x/ 1+fZJYRcMEERmAdWCJN1alk/qN1iZG86g5IDE3jMdD1mv0kSNnhe8tGMFnfJ1OJVon32 tuwA==
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=/VAv6X0BXvIYUg0pnHsF6E09f4f9Kbche+mfHot/+7Y=; b=f3BLUg4F47oRr5umofLAzfpS1SAPu7WNRTTIWyOimrs/QW5yFcFHHnvvoIUCeoDmoE dKXF5MIHqb6oufb7cqyaW+/7IwBn1EwtDq/KPw/apq3WWskmR0+Nxx3VP8IkXvHNs9VW LWCnm7SY/WwOOVdJUWNhSOM+0Wn/NrU5yk5atLk71X5BGS5WKFyIL0IPInn5zXh3Fn8i CHPz6ArINfZFS/U3s79dq+mdS+yUg6uU4MGWbWCU95EmXp9Trp1R+UY539kJfSNKOCab BHm1uMJ90qbazg6raF8edl4xu3dikXmgwGwbl5ihsj7tN/tG6t7d6d/jKjBLF/thsmuO atAA==
X-Gm-Message-State: AG10YORFyl5o8IeQQOu+pRX1LIcloDFjsv61/4CKQ7DPwFYegAIat/4BfgTsSoXqFykK6EIzoz66CObTftc7QiIJ
MIME-Version: 1.0
X-Received: by 10.50.142.37 with SMTP id rt5mr5717139igb.37.1456323340654; Wed, 24 Feb 2016 06:15:40 -0800 (PST)
Received: by 10.64.26.98 with HTTP; Wed, 24 Feb 2016 06:15:40 -0800 (PST)
In-Reply-To: <87povm27iu.fsf@alice.fifthhorseman.net>
References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <CABrd9SQh5B8E8phCvgLdUntKBu=u4p2iUHJ7ZrjqMwz8edwLHA@mail.gmail.com> <56CAF5B2.30207@comodo.com> <CA+cU71m7akWkLFPiTVOShuTBHLVWfA+Byw2vXF-AZtH0Byik5A@mail.gmail.com> <CABrd9ST2fUz+JPxoimvuw_XFeoNEmGNhPpS3w-PC22ZQDez7AA@mail.gmail.com> <87povm27iu.fsf@alice.fifthhorseman.net>
Date: Wed, 24 Feb 2016 14:15:40 +0000
Message-ID: <CABrd9SQSMm0Bid_sKwwaK=TX2CD0uNbRJmRCs1CNe-Y0br2=Aw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: multipart/alternative; boundary="001a11c3b5426654be052c84b3d2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/M5R6YOsjTgjHytNkXIH7XfoR8iw>
Cc: "trans@ietf.org" <trans@ietf.org>, Rob Stradling <rob.stradling@comodo.com>, Tom Ritter <tom@ritter.vg>
Subject: Re: [Trans] can CT defend against dual CA compromise?
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: <https://mailarchive.ietf.org/arch/browse/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, 24 Feb 2016 14:15:47 -0000

On 24 February 2016 at 01:59, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> On Tue 2016-02-23 03:06:25 -0800, Ben Laurie wrote:
> > Fair point. At least two ways of doing this:
> >
> > a) Run a log that is not trusted for HTTPS connections.
>
> (trolling: i thought logs didn't have to be trusted...)
>

:-)

It is a fair point, though - perhaps a better way to express it would be
"not used by browsers for transparency".


>
> what encourages any party in the ecosystem to log in this untrutsed log?
>

We log all the certs we see. I think we are not the only ones. But agreed,
this is not as robust as a system which requires logging in order for certs
to be accepted. Given that the whole point is not to accept further certs,
this seems tricky to solve!

> b) Continue to accept certs from X, but don't allow SCTs after the last
> > good timestamp for X.
>
> What does this buy us?  Can't an inclusion proof (post-MMD) from this
> log perform the same role as the SCT?
>

Not sure I understand what you mean by this?

v2.23.0 | Report a Bug | By Email