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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 29 Jan 2020 06:18:42 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-6lo-ap-nd-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. I found the document easy to
read. Please find below a trivial-to-fix DISCUSS (and I am requesting a reply
and/or action on this one) plus some non-blocking COMMENTs and NITs.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 4.4 --
The length of the reserved field is not specified. Or am I missing something
obvious ?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

== COMMENTS ==

-- Section 4.2 --
While status is set to 0 when sending a NS, what is the expected behavior of a
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.

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

-- References --
Is there a reason why the crypto algorithms RFC 7748 and 8032 are not 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.

-- Section 6 --
s/may use a same Crypto-ID/may use the same Crypto-ID/ ?

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Jan 2020 07:37:51 -0800

> The length of the reserved field is not specified. Or am I missing something

Well, it's clear from the diagram: 8 bits, and 32 bits.  But, yes, I
agree that it would good to both explicitly say that and to explicitly
say the usual "MUST be set to zero on send and ignored on receipt"
thing.

Barry

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 Jan 2020 15:38:26 +0000

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.

> The length of the reserved field is not specified. Or am I missing something

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.

Changed to 
"
In NS messages it MUST be set to 0 by the sender and ignored by the receiver.
"
 
> 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

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.

> Is there a reason why the crypto algorithms RFC 7748 and 8032 are not

Interestingly they are informational. So that would be a downref. 

CC'ing SEC-DIR: Please help: should we make these refs normative? 

> each document. Else, the current section 2.2 mostly forces the readers to read

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?

> 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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 29 Jan 2020 15:46:33 +0000

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)" <[email-masked]> wrote:

    Hello Eric : )

     

    
    Changed to 
    "

    
    
    Where:

    Works?

    

    

    
    
    Works?

    Done
    
    Many thanks again Eric!

    
    Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 Jan 2020 16:51:36 +0000

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) <[email-masked]>
> Sent: mercredi 29 janvier 2020 16:47
> To: Pascal Thubert (pthubert) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; Shwetha Bhandari (shwethab)
> <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Éric Vyncke's Discuss on draft-ietf-6lo-ap-nd-13: (with DISCUSS and
> COMMENT)
> 
> Pascal
> 
> 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
> 
>     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 --
> be
>     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:
> 
>     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 --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 Jan 2020 10:22:45 +0000

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

> Subject: Re: Éric Vyncke's Discuss on draft-ietf-6lo-ap-nd-13: (with DISCUSS
> and COMMENT)
> 
> Pascal
> 
> 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
>     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.
> 
> 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 --

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 31 Jan 2020 19:13:51 +0000

Thank you very much Pascal and the other authors.

As soon as I am back-online, I am clearing my DISCUSS.

-éric

On 31/01/2020, 11:22, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

    Hello Eric:

    

    Many thanks again
    
    Pascal