Re: [Trans] Write-up of the "Strict CT" variant

Watson Ladd <watsonbladd@gmail.com> Mon, 12 June 2017 01:22 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B581279E5 for <trans@ietfa.amsl.com>; Sun, 11 Jun 2017 18:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RSGZYUJdYjdz for <trans@ietfa.amsl.com>; Sun, 11 Jun 2017 18:22:57 -0700 (PDT)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 3B0111200C1 for <trans@ietf.org>; Sun, 11 Jun 2017 18:22:57 -0700 (PDT)
Received: by mail-pg0-x236.google.com with SMTP id a70so40088206pge.3 for <trans@ietf.org>; Sun, 11 Jun 2017 18:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ra4RLphNgXq3CwMWSlZCOhf0nPL/nXDK/3XIWU6K4w0=; b=sI5Wm/I3eeWkEqxmvfFr6mBuxSNeI2aVoGaQtpu8j00Yi8zJ2KyGMimIwGem1fG07E ZxH7+mcvhFULEpDQ8A9r+TCPvYcMFtpiOqi40BvjK9aQ2ai3N56mCApiFkwIx1Ssf0fI C565yWrqLj3YVmMH/CU0I1ht9ic6ksIDrM71hlSLnu3WSb5XXtvZVPavNwC7kQlGsZGZ u7DQ1XzFNqFNqMAA91om7b0znVIHXh6piSBTU7OULRiEaB+UTSc4jxyAPRVIyEpHq9ld pSgSJR3coSRvDSqBvXSTWSFbQvD4eNbIT3ZvCyzBkanJXnwUkcbXxoHh8VfU8498Mgpk 2Cxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ra4RLphNgXq3CwMWSlZCOhf0nPL/nXDK/3XIWU6K4w0=; b=RipfQs/mZFKAfqirsVV1fezdZHmsefXLERb5LmYKWP7czwXtYsfECZSolBCLYE2fDT GZJMxwCvx6WMAgbRdIok8ftvjqVbrYo0j40p82UzCwOmIL4jDW0MGud/RG+OzMrigrhz b6Z9+wRZGHZBgk55KgODgwzi6dhGBiEudHK98DUZmFtti04Zci8Fr/XQQr5JqZN/MduN kVuI+CI1/5XLDg2AQfYLJWgw1U8qaSmemjpp5tqgYNok763qZ8OM7NlaX0Ffi98ZdAXK ThBczqcPy3Lnssw/UTgNcvRzJlb7HUWrKWHp+KEIcOMWyM4wAVp6Qn8HmbsI2f0qmwg8 PR7A==
X-Gm-Message-State: AODbwcDUYzTYQVusR9GbQdMJSh42c0MgsHEBQJ/vfVjZvlsfRZNh9zLv JeqLbAYfILPRv7cTwqOdjeguYsxNJg==
X-Received: by 10.98.158.138 with SMTP id f10mr42968568pfk.177.1497230576794; Sun, 11 Jun 2017 18:22:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.225 with HTTP; Sun, 11 Jun 2017 18:22:56 -0700 (PDT)
In-Reply-To: <CAMm+Lwi8gq7pUyvrX5BDndwcZDPYc+PDX9dQfeCWa2dvLyqbEQ@mail.gmail.com>
References: <CALzYgEeUCmj4BgY7uKdMnsvTcbvfAunquuqHxD7FxuzZxY1=Fg@mail.gmail.com> <0dd84938-9625-c6c8-5f31-d5d0d0683c5c@eff.org> <D1C7ADE2-DA28-4F29-A0AB-482435CD2B15@kth.se> <CAErg=HGxU7dnd1kifeCph8jTR6eLJn2GZ9=KehiyLpLgwTne=g@mail.gmail.com> <CAMm+Lwi8gq7pUyvrX5BDndwcZDPYc+PDX9dQfeCWa2dvLyqbEQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Sun, 11 Jun 2017 18:22:56 -0700
Message-ID: <CACsn0cnfPq3-uxeWyy8J1ndocivbKRzne1wmZ7xMB4irxrfAeA@mail.gmail.com>
To: Phillip Hallam-Baker <ietf@hallambaker.com>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, Eran Messeri <eranm@google.com>, Jacob Hoffman-Andrews <jsha@eff.org>, "trans@ietf.org" <trans@ietf.org>, Magnus Ahltorp <map@kth.se>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/S-gI9Q8pXoazLBi80ADcOJ64sXY>
Subject: Re: [Trans] Write-up of the "Strict CT" variant
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 12 Jun 2017 01:22:59 -0000

On Jun 7, 2017 8:45 AM, "Phillip Hallam-Baker" <ietf@hallambaker.com> wrote:



On Wed, Jun 7, 2017 at 9:08 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>
>
>
> On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp <map@kth.se> wrote:
>>
>> Well, that depends on the assurance level, doesn't it? For domain-validated certificates, sure, but those are next to worthless anyway. It would be hard to hold a CA responsible for issuing them, so the need for logging them is really small.
>
>
> Let's not introduce CAs' marketing distinction into the technical discussion.


Marketing is sometimes based on facts. In this case inconvenient facts
for people proposing to trash the WebPKI trust model. If you want to
spread disinformation, then I am going to respond to correct.

https://www.scmagazineuk.com/updated-97-of-malicious-mobile-malware-targets-android/article/535410/

The press have stopped writing articles about 97% of malware targeting
Android because it is no longer news. Apple do have some advantages in
their structure besides enforcing what amounts to EV validation of
developers. But it is the validation of every developer before they
get developer credentials that makes the rest of their model feasible.



>
> Domain validated certificates - the basis for the Web PKI - are the only security level that matter. The holder of such a certificate can impersonate any site named in the certificate - whether from example.com to google.com.


Domain Validation is not the 'basis' for the WebPKI. It did not even
exist until late in the dotCom boom. The WebPKI was originally
designed to establish accountability. It is the bridge between the
online and offline accountability infrastructure.

So I get to sue Verisign if they issue a cert incorrectly? Oh wait,
that isn't actually the case: CAs disclaim all responsibility for what
you say they they are supposed to do. Was it ever the case that this
was possible?