[Trans] Log checking should be asynchronous (Re: Volunteer opportunity! (was Re: DNSSEC also needs CT))

Nico Williams <nico@cryptonector.com> Mon, 02 June 2014 16:57 UTC

Return-Path: <nico@cryptonector.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 CF4BA1A023A for <trans@ietfa.amsl.com>; Mon, 2 Jun 2014 09:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 BfHgmHw4YFLQ for <trans@ietfa.amsl.com>; Mon, 2 Jun 2014 09:57:25 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D75211A024F for <trans@ietf.org>; Mon, 2 Jun 2014 09:57:25 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 9161D200B9993 for <trans@ietf.org>; Mon, 2 Jun 2014 09:57:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=j+2E4QuQb/iY8u1a/Kyn+zDDplw=; b=KkzsVew5CdR a5Gx3/k0/u/Ld6pbYRiC5Y/s/ZDIh1UsoQwO1hF6vKHjBTw1INr/tGg19E9rqyBc gmMtUrhT2T+vEYvGtCpipSr8MNlOPWB0Qr6PpwmeNP5mfLDHAwOSAITgznG5HlQm VJuzcOzjaU2LM42a46dTeXWluRxMq46E=
Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 40C45200B9990 for <trans@ietf.org>; Mon, 2 Jun 2014 09:57:20 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id u56so5571055wes.0 for <trans@ietf.org>; Mon, 02 Jun 2014 09:57:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.212.77 with SMTP id ni13mr23781816wic.5.1401728239055; Mon, 02 Jun 2014 09:57:19 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 2 Jun 2014 09:57:19 -0700 (PDT)
Date: Mon, 2 Jun 2014 11:57:19 -0500
Message-ID: <CAK3OfOgPuOnRBC+_-Hwfgk+yTMtHWQyTwQZVCy5fnVhm6nLyEQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Dmitry Belyavsky <beldmit@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wQ9a2VmIkCb7E6vCWGCpkrHboE4
Cc: Melinda Shore <melinda.shore@gmail.com>, "trans@ietf.org" <trans@ietf.org>
Subject: [Trans] Log checking should be asynchronous (Re: 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: Mon, 02 Jun 2014 16:57:27 -0000

On Tue, May 13, 2014 at 3:41 AM, Dmitry Belyavsky <beldmit@gmail.com> wrote:
> Here are my ideas about "strict" behaviour of the TLS client:
>
> [...]

IMO log checking should be mostly asynchronous.  This means that CT
couldn't detect MITMing CAs in real-time, but that's OK because CT is
about CA reputation, and all we care about is that when we detect
lying CAs we can report them.

This means that clients mostly should only reject TLS connections when
there's no evidence of server certs being logged in an acceptable log.

It also means we need some mechanism for reporting lying CAs.  Thus
far reporting via blogs, news outlets, and trust anchor set managers,
has been good enough, and I'm not sure that we need anything more than
any async notification to users (and upstreams) by browsers (and other
clients).

There are privacy protection considerations in reporting lying CAs:
report the name about which they lied, just the log entry(ies) that
are missing, or just an assertion that they lied?

Again, as I see it CT is purely a reputation-based system.  Reputation
is established (and blemished/destroyed) asynchronously.

This is important: we cannot be adding too much latency to TLS.  By
doing log checking asynchronously we won't be.

Nico
--