Re: [secdir] Éric Vyncke's Discuss on draft-ietf-6lo-ap-nd-13: (with DISCUSS and COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Eric:

Again many thanks for your review : )

I just published 14, and added text on the Nonce to remove the impossible must. We talked between authors and the indication is same as RFC 3971 that this should be a random.
The quality of the random is linked with the security level that can be obtained from it. Coupling randoms from both parties largely increases the protection, but in an IOT network that reboots, there is still a risk of a replay.
All in all we give the general direction of the random, but allow an ever increasing value as well, which is simpler to obtain for a node and yields the same Nonce benefits.

A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-14

Please let us know if the text now conforms your expectations?

Many thanks again

Pascal


> -----Original Message-----
> From: Eric Vyncke (evyncke) <[e-mail]>
> Sent: mercredi 29 janvier 2020 16:47
> To: Pascal Thubert (pthubert) <[e-mail]>; The IESG
> <[e-mail]>
> Cc: [e-mail]; Shwetha Bhandari (shwethab)
> <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Éric Vyncke's Discuss on draft-ietf-6lo-ap-nd-13: (with DISCUSS
> and COMMENT)
> 
> Pascal
> 
> Thank you for your prompt reply. I will clear my DISCUSS in a moment as you
> will change the text.
> 
> Agreed on all the points except for the 'nonce'. I know the concept of course
> but the sentence "was never used with this device" is still too strong IMHO. To
> comply, it would require to keep the history for ever... I would prefer a less
> stringent wording.
> 
> -éric
> 
> On 29/01/2020, 16:38, "Pascal Thubert (pthubert)" <[e-mail]>
> wrote:
> 
>     Hello Eric : )
> 
>     Many thanks for your review! I cc'ed SEC-DIR because we could really use
> their recommendation to solve some of your questions, more below.
> 
>     Please see below:
> 
>     > == DISCUSS ==
>     >
>     > -- Section 4.4 --
>     > The length of the reserved field is not specified. Or am I missing
> something
>     > obvious ?
> 
>     I concatenated the reserved fields in the picture and declared it as 40 bits.
>     Also added the number of bits in the reserved fields of other structures.
> 
>     > ----------------------------------------------------------------------
>     > COMMENT:
>     > ----------------------------------------------------------------------
>     >
>     > == COMMENTS ==
>     >
>     > -- Section 4.2 --
>     > While status is set to 0 when sending a NS, what is the expected behavior
> of a
>     > receiver ?
> 
>     Changed to
>     "
>     In NS messages it MUST be set to 0 by the sender and ignored by the
> receiver.
>     "
> 
>     > -- Section 4.3 and 4.4 --
>     > Why is the Pad Length field a 8-bit field while the actual padding will
> always be
>     > less than 8 bytes. Suggest to make it a 3 or 4 bits field and extend the
> reserved
>     > field.
> 
>     Actually I thought that if we want to extend the option in the future, it is
> better to indicate the length of the public key as follows:
> 
>        |     Type      |    Length     | Reserved|  Public Key Length  |
> 
>     Where:
> 
>     Public Key Length: 13-bit unsigned integer. The length of the Public Key field
> in bytes.
>     Public Key:  A variable-length field, size indicated in the Public Key Length
> field.
>            	     JWK-Encoded Public Key [RFC7517]
>     >Padding:  A variable-length field completing the Public Key field to align to
> the next 8-bytes boundary.
> 
> 
>     Works?
> 
> 
> 
>     >
>     > -- Section 6.1 --
>     > About "Nonce option MUST contain a random Nonce value that was never
> used
>     > with this device", how can it be done? Keeping a local history? Giving
> some
>     > operational hints would bee welcome. Especially, when there are multiple
> 6LR in
>     > the LLN: how can they synchronize the nonce?
> 
>     The nonce is used once, so there's no synchronization. A new pair is formed
> and exchanged at each validation.
> 
>     The nonce game used here appear to be common practice. Yes, there's
> usually a need of local history, and the fact that we get a nonce from both
> side, apart from guaranteeing that the result is effectively unique to both
> parties, also makes the chances for history to repeat very low.
> 
>     CC'ing SEC-DIR: Please help: if there is a reference for that practice, what it
> takes to maintain a nonce, and why we have a nonce from both sides? Trying
> to reinvent that text does not look like a good idea for this draft.
> 
> 
> 
>     >
>     > -- References --
>     > Is there a reason why the crypto algorithms RFC 7748 and 8032 are not
>     > normative?
> 
>     Interestingly they are informational. So that would be a downref.
> 
>     CC'ing SEC-DIR: Please help: should we make these refs normative?
> 
> 
>     >
>     > == NITS ==
>     >
>     > -- Section 2.2 --
>     > To be honest, I am not a big fan of simply announcing concepts and
> referring to
>     > many other RFCs. Suggest to mention which terms and concepts are
> defined in
>     > each document. Else, the current section 2.2 mostly forces the readers to
> read
>     > all the references.
> 
>     Yes and they are really there as additional reading, not normative.
>     I changed the text to
>     " The reader may get additional context for this specification from the
> following references"
>     I also moved classical ND and SEND references to informational references.
> 
>     Works?
> 
>     > -- Section 6 --
>     > s/may use a same Crypto-ID/may use the same Crypto-ID/ ?
> 
>     Done
> 
>     Many thanks again Eric!
> 
>     Let's see what SEC-DIR thinks
> 
>     And a very happy new year (in France we have till Jan 31st to send wishes
> 😉)
> 
>     Pascal
> 
> 
> 
>