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

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

Hello Eric:

First of all, " was never used with this device " should really be " was never used with this keypair ". And then we could add "to the extent possible for the implementation". And then I agree, "random" cannot be asserted for "never used".

I did some homework on the nonce but still would prefer to get recommendation by SEC DIR; I'll note that a mote cannot not necessarily produce good randoms easily and that to my best understanding an incrementing number stored with the keys should do as long as the keys are regenerated when the storage is lost.

Based on that homework I suggest:

"
   The Nonce option MUST contain a Nonce value that, to the extent possible
   for the implementation, was never employed in association with the
   key pair used to generate the ROVR.  An implementation may for instance
  use an  unpredictable cryptographically random value [RFC4086], or an
   incrementing value saved in stable storage.
"

What I found is this:

We inherit from RFC 3971 which says:
"
   Nonce

      A field containing a random number selected by the sender of the
      solicitation message.  The length of the random number MUST be at
      least 6 bytes.  The length of the random number MUST be selected
      so that the length of the nonce option is a multiple of 8 octets.

"

Also:

https://tools.ietf.org/html/rfc6744 requires a random nonce and relies on https://tools.ietf.org/html/rfc4086 to define randomness. We could make that an option.
https://www.rfc-editor.org/rfc/rfc7804.html uses SCRAM (https://www.rfc-editor.org/rfc/rfc5802) which generates nonces based on random strings
 An always incrementing value is simpler but requires stable storage. When it wraps the address must be deregistered and reregistered with a new keypair. That's realistically never with current techs, but who knows?.
https://www.rfc-editor.org/rfc/rfc2617.html says "
     The contents of the nonce are implementation dependent. The quality
     of the implementation depends on a good choice. A nonce might, for
     example, be constructed as the base 64 encoding of
         time-stamp H(time-stamp ":" ETag ":" private-key
"

What do you all think?

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
> 
> 
> 
>