Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-07.txt

[Göran Selander <[e-mail]>]

Hi Michael,

Sorry for delayed response, this got hanging in my outbox. 

> 25 okt. 2018 kl. 19:52 skrev Michael Richardson <[e-mail]>:
> 
> 
> Göran Selander <[e-mail]> wrote:
>> Now, the PSK in the Constrained Join protocol is used as the OSCORE Master
>> Secret, from which the Sender/Recipient Contexts, including Sender/Recipient
>> Keys, are derived. It is these keys, not the PSK, which are used for
>> authentication and communication security in OSCORE, so they need to be
>> unique and independent in each pledge. Since the Sender/Recipient Contexts
>> are derived from the PSK and the pledge identifier using HKDF, the derived
>> keys are expected to get these good properties as long as the input to HKDF
>> is different for different endpoints. So, having unique PSKs is a sufficient
>> condition. But having unique pledge identifiers is also sufficient, even if
>> the same PSK is used: Pledges may be provisioned directly with the
>> Sender/Recipient Context in a 1-touch fashion without access to the PSK, and
>> can then run the Constrained Join protocol. In fact, this is a quite
>> attractive deployment scheme:
> 
>> * The pledges do not need to implement HKDF or SHA-256.
> 
> What I'm hearing is that Pledges may be provisioned (at the factory) with:
>     SRContext = HKDF(PSK, PledgeIdentifier, other-stuff)
> 
> while the JRC can be provisioned with:
>      1) PSK
>      2) list of valid PledgeIdentifiers
> 
> What does not change is that:
>     a) SRContext still must be kept a secret.
>     b) SRcontext is still unique per-pledge (so can't be baked directly into firmware!)
> 
> So this is easier for the JRC, but does not really change anything in the way
> that Pledges have to be "touched".
> 

Right, this was not a comment about changing one-touch, which is the basic assumption of minimal security. This was a note that other secrets can be provisioned in the same one-touch manner with certain benefits to pledge and JRC. 

>> But even if you don’t do that, I propose that you do describe the deployment
>> scheme sketched above, for example in an appendix, and explain in that
>> section why this scheme is secure even though it is not complying with
>> the
> 
> I agree that putting it into an appendix would work.
> A completely separate document might also a good idea. (An operational BCP)
> 
> In particular, leaving it to another document might allow other things that
> need to be baked in uniquely to be described.  I am thinking about a
> connection to the hash-based signature work that the SUIT WG cares about.

I think that having at least a paragraph in an appendix of this draft would be good as it also illustrates how the requirement on PSK uniqueness can be slightly eased. 

Thanks,
Göran