Re: [Anima-bootstrap] brsky concern1: separating audit-log retrieval from voucher generation

Michael Richardson <> Sat, 12 November 2016 02:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FEDB129536 for <>; Fri, 11 Nov 2016 18:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LpezPb_EcyFA for <>; Fri, 11 Nov 2016 18:56:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32CC61294C0 for <>; Fri, 11 Nov 2016 18:56:14 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPS id B79AD1F906; Sat, 12 Nov 2016 02:56:12 +0000 (UTC)
Received: by (Postfix, from userid 179) id 2255B321D; Fri, 11 Nov 2016 21:56:10 -0500 (EST)
In-reply-to: <>
References: <>
Comments: In-reply-to Toerless Eckert <> message dated "Tue, 01 Nov 2016 21:15:23 +0100."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
From: Michael Richardson <>
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sat, 12 Nov 2016 11:56:10 +0900
Message-ID: <>
Archived-At: <>
Cc: Toerless Eckert <>
Subject: Re: [Anima-bootstrap] brsky concern1: separating audit-log retrieval from voucher generation
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Nov 2016 02:56:15 -0000

Toerless Eckert <> wrote:
    > As discussed today on the call, restated for the rest of the team with
    > more detail:

    -> pledge connects to two networks, A, B.  Pledge tries to well-behave,
    -> only offers nonce to one network first, A.  (registrar of) A gets
    -> voucher. A looks at audit-log. Audit log is fine.
    >    Ultimately, A decides not to enroll pledge though.

It might be a good idea to understand why... I think it matters why here,
because it would affect if the registrar ought to have told the MASA
something or not... your next sentence says that something was audited.

    -> Pledge offers nonce to B, B gets voucher and audit-log.
    >    Audit log shows A, so B is concerned. B rejects device.  Without the
    > entry in audit log, B would have enrolled device.

    > My worry is that the current audit log approach can too easily create
    > false positives that will make enrolment fail if a device has multiple
    > network connections:

Agreed, this is a problem.

    > It's impossible for A to get an audit-log without also getting a
    > voucher, which in return would make another domain suspicious and
    > likely make it decide not to accept the device.

    > Separating out request for voucher from request for audit-log could
    > work like this:

    >   MASA: request audit-log for (pledge,nonce1)
    >   MASA: audit-log entry: "A requested audit log for pledge,
    > hash(nonce1)" [1]
    > A: reply: audit-log

    >   ... A makes up its mind if it wants pledge and decides that it does
    > NOT.

I agree, we need something like this.
I think we have a race condition here, but I think we can solve it once we
have established what the problem is, and decide what are the compromises.
I think we actually need to do a threat analysis here...
I am pretty sure Max has it all in his head, but we'll need to explain to