Done, thanks for the review! I closed the corresponding issues in bitbucket.
Mališa > On 29 Mar 2019, at 07:19, Göran Selander <goran.selan...@ericsson.com> wrote: > > Hi Mališa, > > Thanks for the update, this addresses my concerns. > > Editorial: Replace "entirely defined" with "specified". > > Göran > > On 2019-03-27, 23:16, "Mališa Vučinić" <malisa.vuci...@inria.fr> wrote: > > Dear Göran, > > > Many thanks for the review! As we discussed during the WG meeting, I added > new text in the draft to stress that the procedure in Appendix B.2 of OSCORE > should be used in the case of a failure event occurring at the JRC. The use > of this procedure > is now RECOMMENDED, and in case it is not supported by a particular > pledge implementation, we require the reprovisioning of the affected devices > with fresh parameters. > > > Other comments have also been taken into account and the draft has been > aligned with the references in oscore-16. > > > The related diff providing changes in respect to your comments is > available at: > > https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10-goran#diff > > > Please let me know if this addresses your review. > > > Mališa > > > On 24 Mar 2019, at 23:08, Göran Selander <goran.selan...@ericsson.com> > wrote: > > Dear 6TiSCH, > > Sorry for very late response, here are a some post-2nd WGLC comments on > draft-ietf-6tisch-minimal-security-09: > > Summary: With one exception detailed below the draft seems to be in good > shape and essentially only need some harmonizing updates following the last > changes to OSCORE which has now completed IESG review. > > Main concern: > > Section 8.3: > The recovery from complete failure of the JRC as currently described is > not satisfactory and may lead to loss of confidentiality of data sent from > the JRC to the pledge. During reinitialization of pledges due to complete > failure of JRC, the new JRC cannot > detect replays of old initialization messages, nor does it know the > latest sequence number used by the failed JRC: > > * It is not described how the new JRC reacts to a received CoJP request to > avoid accepting a replay request or why it is not a problem with nonce reuse > in the CoJP response. > * The procedure for the first Parameter Update with randomized payload may > have different known CoAP header parameter values than the message with which > nonce is reused, leading to a two-time pad which may to break > confidentiality. It should at least be described > why this is not an issue. > * There is no security consideration about properties of the encryption > algorithm, in this case AES-CCM, which limits this attack to confidentiality. > > There are different ways to resolve this. Here are two alternatives: > > Appendix B.2 in OSCORE specifies a challenge-response based protocol for > updating the security context based on an exchange of nonces. This protocol > can be directly applied here where the replaced JRC in the role of CoAP > server would trigger the protocol by > responding to the reinitialization request with a new security context as > is detailed in appendix B.2. The pledge then repeats the CoJP request with > another security context and the JRC responds with the CoJP response using > the agreed security context. In > this way the old security context is replaced by a new, thereby removing > the risks associated with accepting replayed messages and reusing nonces. > > > The procedure in the previous paragraph does however not support the > lightweight implementation option in Appendix B of this draft, since the > master secret is needed for deriving the new security context. If this is > very important to support, considering that > CoJP is a special application of OSCORE it may be possible to specify a > bespoke synchronization protocol. One setting for this is based on a reserved > JRC sequence number for responses to reinitialization requests, the Echo > option, and transport of the pledge > record of last used JRC sequence number. This would require a careful > analysis in particular of the use of JRC sequence numbers. > > > A related concern is on the use of persistent memory: > > "In case of a reboot on either side, the retrieval of mutable security > context parameters is feasible from the persistent memory such that there is > no risk of AEAD nonce reuse due to a reinitialized Sender Sequence number, or > of a replay attack due to the reinitialized > replay window." > > Section B.1.1 of OSCORE details some issues with writing to non-volatile > memory that are applicable in particular to the JRC, and this text should be > updated accordingly. Depending on the JRC implementation, this may be another > reason why the pledges/joined > nodes need to support the protocol in Appendix B.2 in the case of JRC > losing context. > > Minor concerns: > > "Implementations MUST ensure that multiple CoAP requests to different JRCs > are properly incrementing the sequence numbers " > > I don't know why this is restricted to different JRCs: Implementations > MUST ensure that multiple CoAP requests properly incrementing the sequence > numbers. > > > OLD > "Since the pledge's OSCORE ID " > > NEW > "Since the pledge's OSCORE Sender ID " > > > " A simple implementation technique is to instantiate the OSCORE security > context with a given PSK only once and use it for all subsequent > requests. " > > Reference 7.5 and/or appendix B.1. Note that these are rewritten so > references here may have changed (see below). > > > OLD > "The (6LBR) pledge and the JRC use the OSCORE security > context parameters (e.g. sender and recipient identifiers) as they > were used at the moment of context derivation, regardless of whether > they currently act as a CoAP client or a CoAP server. " > > I think this text is intended as a clarification of OSCORE functionality, > but it doesn't make clear that that is what it is. Here is an attempt, > perhaps you can do better: > > NEW > Note that when the (6LBR) pledge and JRC changes roles between CoAP client > and CoAP server, the same OSCORE security context as initially derived in > each endpoint remains in use and the derived parameters are unchanged, for > example Sender ID when sending and > Recipient ID when receiving, see section 3.1 of > [I-D.ietf-core-object-security]. > > > "A technique that prevents reuse of sequence numbers, > detailed in Section 7.5.1 of [I-D.ietf-core-object-security], MUST be > implemented. Each update of the OSCORE Replay Window MUST be written > to persistent memory." > > Section 7.5.1 is now B.1.1, and the procedure is slightly different, there > are two parameters to set, K and F. Do you want to recommend any settings > here? > > > Göran > > > > On 2019-03-07, 15:45, "6tisch on behalf of Pascal Thubert (pthubert)" > <6tisch-boun...@ietf.org on behalf of > pthub...@cisco.com> wrote: > > Dear all: > > At the last IETF, we concluded the WGLC on > draft-ietf-6tisch-minimal-security and concluded it was mostly ready. It > received 7 reviews during the last WGLC, all of which had been integrated, > and received reviewers approval. > Two final changes were still needed. Malisa was to discuss those on > the ML, integrate them into a new version of the draft if consensus was > found. There was in particular a dependency / alignlent to be made on OSCORE. > > More in > https://www.mail-archive.com/6tisch@ietf.org/msg02875.html > <https://www.mail-archive.com/6tisch@ietf.org/msg02875.html>. > It appears that the issues are now resolved. Mališa, can you please > summarize the status with OSCORE? > > As promised, the Chairs now open a 1-week WGLC on > https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09 > <https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09> focusing > on those changes, though any bug you can find is good to mention too. > The WGLC ends on Friday March 15th. Please have a good last look at the > spec and let us know. > > Looking forward to meeting you all in Prague, > > The chairs > > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
