Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 2 May 2019 22:24:29 +0200
From:   Michal Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
Subject: Re: [PATCH BlueZ] mesh: Add remote dev key support and cleanup
Message-ID: <20190502202429.kxyyql4prcllzpcj@kynes>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
References: <20190423231624.19302-1-brian.gix@intel.com>
 <20190424085945.zmniib4vpy2uiyql@kynes>
 <DEBB0CAA2616974FAE35E4B560B9A4376CB05944@ORSMSX103.amr.corp.intel.com>
 <20190430073809.wdbhglfaiqsvscmc@scytale>
 <DEBB0CAA2616974FAE35E4B560B9A4376CB0C1B5@ORSMSX103.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DEBB0CAA2616974FAE35E4B560B9A4376CB0C1B5@ORSMSX103.amr.corp.intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

On 05/02, Gix, Brian wrote:
> > Right, but I think this is covered by the server/client model behaviour, so I don't
> > think we need to care if the message was encrypted using a known remote
> > device key, or our local device key.
> 
> There is the SHALL paragraph in the specification, under section
> 3.7.4.3:
> 
> "A response message shall always use the same DevKey or AppKey used by
> the corresponding request message."
Indeed, but on the other hand 4.4.1.1 says that:

"The application-layer security on the Configuration Server model shall use the
device key established during provisioning."

So it doesn't make any sense for a server model to accept messages encrypted
with remote device key. I think the only situation where a message using remote
device key should be accepted is processing responses directed to a local
client.

In the end, I agree we need to track the 'kind' of a device key... But, I think we
actually need to expose the local/remote distinction to the application, as an
(boolean?) argument of DevKeyMessageReceived. This is because foundation models
aren't the only models that are allowed to use device-level security.  Also,
you mentioned earlier that the daemon will not expose APIs for all
configuration client operations.

> > I think this means that the API needs to allow using either local or remote
> > device key when *sending* a message (i.e. use remote key for requests and
> > local key for responses), but API for receiving messages needs only to
> > differentiate between device and application keys.
And what about this then?

Because of the above, I don't think it's correct to always (automatically) use
remote device key if one is known.

If the previous comment about an additional argument makes sense, it would also
make sense to add it to DevKeySend.

> > I was more concerned about the CRPL size. At the moment the limit means that
> > a node cannot simultaneously talk to more than 10 remote nodes because of
> > this (mesh/appkey.c:227):
> 
> This will definitely be fixed, and should be following the value
> indicated by the Composition data of each node.
Note that the Composition Data Page 0 indicates a *minimum* CRPL size. A
node is free to use a longer list.

So if I read this right, the plan is to allow the application to declare CRPL
size during CreateNetwork/Join procedure?

> > What are your thoughts on replacing the JSON storage with something more
> > granular?
> >
> We would like to keep Node Storage, at least for the full Linux
> implementation, in JSON format
Got it. Thanks for the additional details.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND