Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

Brian E Carpenter <> Mon, 01 October 2018 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9C14130E16; Mon, 1 Oct 2018 14:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KaXNZythURds; Mon, 1 Oct 2018 14:47:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE66A130EC0; Mon, 1 Oct 2018 14:47:31 -0700 (PDT)
Received: by with SMTP id p24-v6so1697129pff.10; Mon, 01 Oct 2018 14:47:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=s6Vur4LMpNXyMO7Jswd2CEC8I24lJS4WG4Odp2xZI9A=; b=IHCUOEelgkVWdqU/TnMM18lAH5AxyF9ulJsjMeUuAzLRfTNSzVw/N9JXGEuOopl08M TmqI3Y0bZrOKVxCNYBIqC1W2nEzQWCBk4R35e+8kCuzBPWDjVFMZxcG+6WTiKzXKjqe2 4xpDE7/juehc7vHw/YSbwI+IDraOH6Qqnxbv4YUtUKEtjqAJrng5rJYzeUhmNaSI7K8a mFownzOE9VfGi2ufiYdQik61K5hKTta+xCQd9WBv8WqMTkhAv7Iu4qS3yzQp5gAu4MSF CLa8ZkO4Z1gEdrtiA+UJKGJ1qPb83wEkAaarKLjPu0UjfDp6kxhEkzmZoeZsCgYDarE5 r8yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=s6Vur4LMpNXyMO7Jswd2CEC8I24lJS4WG4Odp2xZI9A=; b=moon0Tnzt66Yl9IZKeryJN2mQZUMFIy49WX8dQCGNrQ4DkwZ+0lIAM/BEKapW2xVo1 eeXWdn0wfUjCA0RMIwvpKeh8klXiOj2mXK4kp1tx1v9CyQCB1XrUc9tck/BauUB8tPwM Fd+4T2hEKlIU8yMmq52xiZ9aTVNLLVEcC/KewEt4L/yoiMvBBZPjWyC5CAzG+c+jCHm3 2k67wrDcVHneNHlu2oXh4PYmFGlMCdcsXkSr/Fi5A6KgwXulFtdk3HzRn2za0fbmbXr9 bR7yvXKe2cd+Y8KRz9jNIsvBv3Cu5LTvag6DafrJrAWDK0cT4xRvU5NxNX8WYExFnz3o Ox5Q==
X-Gm-Message-State: ABuFfojgRGXwtG9KZZ53e9LsMZdCyihpisTHhu5fm0oPyiGHsEI5UZRO Mi76t4IwGJEYQTodVcjnkhnX387r
X-Google-Smtp-Source: ACcGV63NpOL5ltarTKfVNyuCrAADOkSKKE5jtWOV70og14D15S+UliFXGIEyS+zSbMvrlLsyeC4xEg==
X-Received: by 2002:a17:902:758b:: with SMTP id j11-v6mr13717604pll.5.1538430451047; Mon, 01 Oct 2018 14:47:31 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id v81-v6sm29708505pfj.25.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 14:47:30 -0700 (PDT)
To: Randy Bush <>, Michael Richardson <>
Cc: "Joel M. Halpern" <>, Christian Huitema <>,, IETF discussion list <>,, Security Directorate <>
References: <> <> <> <> <3136.1538342967@localhost> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Tue, 2 Oct 2018 10:44:56 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Oct 2018 21:47:34 -0000

On 2018-10-02 08:36, Randy Bush wrote:
>>> a stunning review as usual.  but i have two questions which you kind
>>> of finessed.  they are simple binary, i.e. yes/no, questions that the
>>> end user, to whom the IETF is ultimately responsible, really cares
>>> about.
>>> if the manufacturer's servers go down, either permanently or even for
>>> a day, does the device i have purchased still work?  i.e. is it fail
>>> soft? [0]
>> First, BRSKI as used by ANIMA is specifically not targetted at Things.
>> (We are developing profiles of BRSKI that are about Things, but I
>> think that this internet-draft should not be be evaluated on that
>> basis).
>> It's targetted at routers and other devices found at ISPs or
>> Enterprises.
> i missed where i said light bulbs.  i do have some of those, but i run
> routers, servers, etc.; and do not want $vendor to break my network for
> *any* reason.
>> Second, the only time the manufacturer's servers need to be alive is
>> when device ownership is claimed.
> i.e. when i sell the router to some other op.  that was my second
> question.
>> Once the device is claimed, it joins *YOUR* network, and trusts your
>> infrastructure, not the manufacturer.  Whether or not the device will
>> *operate* without the manufacturer's servers is really outside of
> ahhh.  we just sell the guns, we do not say how they are used.

It's not quite that.

We sell X's. We cannot control how the X's are used. But if they
are used without calling home to our MASA, we cannot certify that they
are genuine X's. They might be counterfeit X's.

BRSKI is a way of proving that the X announcing its identity as
X12345 really is the one and only X12345.

If you sell it to someone who doesn't care about that, they can use it

Anyway, that's how I understand it.


>>> That answer seems to imply that if the MASA is down before I try to
>>> transfer my device, and if the MASA is still down when the recipient
>>> tries to get my device working, it won't work.
>>> Which seems to mean that once a MASA goes down permanently, any new
>>> can not get a device reliant on that MASA to work.
>>> Seems a pretty severe limitation.
>> You are answering a different question than Randy asked
> no.  he is speaking to the second question i asked.  and his answer
> deeply concerns me.
>> This is a pretty important question and we have discussed it at
>> length.  I remain concerned, but as far as I can see, we have this
>> problem already.
> if i understand correctly, it creates a new problem, needing the
> manufacturer's consent for me to resell my light^Hrouter.
>> It fundamentally depends upon a number of things which unfortunately, the
>> manufacturer has ultimate decision making about.
> see above about guns
> randy