Re: [saag] Direct trust between users

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 26 April 2019 14:17 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E0A120145 for <saag@ietfa.amsl.com>; Fri, 26 Apr 2019 07:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 LsxPlXIqUQ4n for <saag@ietfa.amsl.com>; Fri, 26 Apr 2019 07:17:28 -0700 (PDT)
Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (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 EDF4C12004B for <saag@ietf.org>; Fri, 26 Apr 2019 07:17:27 -0700 (PDT)
Received: by mail-oi1-f179.google.com with SMTP id t81so3025302oig.10 for <saag@ietf.org>; Fri, 26 Apr 2019 07:17:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5o6OrXVcWg4EoqIzZxXavWSBSP5BKz9Wj2puppX01yI=; b=f2gbaGtTpHzt9JkEzpPaLNj3sB9Ixnr7D4yTu3rVn9NuQQSXjYr6LLxpV1QRKu8u0s v0A+NoyugXVhn62S/nRn2mZ7U+XGegBZVZh/23IDBceIIVJaSL5LQbIDkl8bUp3UfRqo erDTcIi2u73cYNC1gLdsHWoxwsJRVbT+lMHie2H81ZQsoBQX18mFmPd7VlE4untLKlRJ pjMvcvsvRliUfsZGCtsIduCW4WLTpAkqKq9uQUzXlPw5zySfLL5U6U1mYLcWfnjvFMX1 mBMiYxcfuYM77nq2hRFPm0EadMR1RdU3IjtA4sOjnMTfKPVT1Wo3RlQj+BHcwR2w+qu7 vj/w==
X-Gm-Message-State: APjAAAVSA3fTjUNwYC12bF7VuAzX68z99dDzZwOHXIMZGt4L/M/6wKvg AYemvUIIocvMLHRlbieu7Lp7vFUWRmFkv8CfV40=
X-Google-Smtp-Source: APXvYqwyAc0op9mtJPrkO5Jwj+8FDtQ8VIRnw90NDNbZ7Osn5X1AD6nayg8dIVm2STgwabn1WmhavChuDwmJ80s8tbY=
X-Received: by 2002:aca:5a89:: with SMTP id o131mr7529593oib.17.1556288246849; Fri, 26 Apr 2019 07:17:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+LwheS8mP8guk4++VNSfcp19kqcOZLxCHaV0=F02xyc7Aow@mail.gmail.com> <CABrd9SSyAYuQAuBcJhtgQUnsLah88Vbiz+a3BofCZ=XjyMikbQ@mail.gmail.com>
In-Reply-To: <CABrd9SSyAYuQAuBcJhtgQUnsLah88Vbiz+a3BofCZ=XjyMikbQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 26 Apr 2019 10:17:15 -0400
Message-ID: <CAMm+Lwi0=0Ao_LDtUD_MMkTuVLu_fjzZTP22c94i6GxWHsDMug@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Cc: IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001f252905876f984f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/NMWbaxDOfV3bVXSLdJGoLISmSQo>
Subject: Re: [saag] Direct trust between users
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 14:17:30 -0000

On Fri, Apr 26, 2019 at 4:42 AM Ben Laurie <benl@google.com> wrote:

>
>
> On Wed, 24 Apr 2019 at 18:57, Phillip Hallam-Baker <phill@hallambaker.com>
> wrote:
>
>> Nico asked about the Mesh Trust model and I said that I was trying to
>> avoid imposing one. I do have metrics for measuring the quality of trust
>> established in terms of a work factor however:
>>
>> http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html
>>
>> This is not a computational work factor as we are used to. It is a social
>> work factor nominally denominated in currency (USD) and bounded in time.
>>
>> Let us say that we did some key signing even open to IETF meeting
>> attendees only. It would cost an attacker $325 plus travel minimum to
>> impersonate me. Not an impossible sum if they really really want to
>> impersonate me but enough to stop a large number of attacks. Furthermore,
>> there is a significant risk of being caught if they attempt the
>> impersonation on any large scale. So the social work factor might be $1000.
>>
>
> Presumably $1,000 buys more than one impersonation, and of anyone you want
> (there's no list of who was actually at IETF, AFAIK).
>

The design of VeriSign Class 3 was intended to mitigate the risk of
impersonation by making it unprofitable for the attacker. In particular it
was intended to make crime impractical for repeat offenders.

So the first step in the chain was to make it so that a party has to commit
a crime to obtain a fraudulent certificate. The next was to limit the
validity so that they had a narrow window of opportunity to make a return.
So if they paid $300 for the cert, they would have to make that back in
five days to turn a profit. Not impossible but requires them to make some
effort and that adds cost.

But even if they get away with a profit of $5K per time, that isn't going
to last them long. So they have to do it again and register/impersonate
another company etc. etc. And they will probably go about it the same way
so that they begin to establish a pattern of behavior. And each time they
do it, they are committing more crimes in the registration process. So they
are either repeat offenders in one jurisdiction increasing the probability
of being investigated or they are offending in multiple jurisdictions
increasing the probability of being investigated.

So yes, the work factor isn't insurmountable but it isn't zero either. Carl
Ellison's point about ceremony may be relevant here.

Lets say that the attacker attempts to register themselves multiple times.
We could defeat that by binding the assertion to their conference
registration number. Perhaps we print the QR code or a part of it on their
badge and it can only be used once. Perhaps we also require validation to
the email address they registered for the conference.

At the end of the day, the data is dumped into a blockchain and so we have
a tool that allows us to roll back attacks after the event. Which is why I
did not suggest taking pictures of the person registering.