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

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> 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
others..