Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-crypto-types-20

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Sep 2021 14:33:50 +0000

Hi Valery,

Reducing to just the open bits…

>> Is your concern that the certificate’s content would be visible to the administrators?  Is your comment on end-entity certificates (containing personally-identifying information), more than trust-anchor-certificates?
>>  
>>           Yes, it’s mostly on end-entity certificates, however there may be quite a lot of interesting private information besides certificates.
>>  
>>           If this information is only visible to the administrators and the used management protocols must have mutual authentication, then it’s probably not a big deal. I would have still added a sentence about privacy of the stored data (i.e. that persons, that are allowed to access this data are able to learn quite a lot of private information from it). I don’t insist though, it’s up to you.
>  
> I added the following to Section 3.8 (The "ietf-crypto-types" YANG Module).
>  
>              The "cert-data" node:
> 
>                    The "cert-data" node, defined in both the "trust-anchor-cert-grouping"
>                     and "end-entity-cert-grouping" groupings, is additionally sensitive to
>                     read operations, as certificates sometimes convey personally identifying
>                     information (especially end-entity certificates).  However, as it is
>                     commonly understood that certificates are "public", the NACM extension
>                     "nacm:default-deny-write" (not "default-deny-all") has been applied. It
>                     is RECOMMENDED that implementations adjust read-access to certificates
>                     to comply with local policy.
> 
> Is this okay?
>  
>           Yes, thanks.
>  
> Separately, I thought about if there are any other values in the module that may have privacy concerns but was unable to locate any.
>  
>           certificate-signing-request?

Of course, CSRs contain similar information as certs but, from the “crypto-types” module perspective, CSRs are never *configured*, as they are only conveyed in dynamic RPCs, and therefore the readability of them from any other than the originator is negligent.  Hence I do not believe that extending the comment above to CSRs is warranted.  Thoughts?

>  
>  
>>> Section 3.5.
>>> While I understand and support the idea, expressed in this section, I think that
>>> the way it is expressed makes it difficult to follow in practice. In general, it's
>>> not always obvious how to estimate the "strength" of the underlying secure transport.
>>> For this reason it's not clear for me how it is supposed to "compare" the 
>>> "strength" of the transport with the "strength" of the keys being transported.
>  
>  
> All comments from this point to the end regard the Security Consideration "Strength of Keys Conveyed” (was "Strength of Keys Configured”).  I rewrote the section as follows.  Can you please check for accuracy?
>  
>       Strength of Keys Conveyed
> 
>            When accessing key values, it is desireable that implementations
>             ensure that the strength of the keys being accessed is not greater
>             than the strength of the underlying secure transport connection
>             over which the keys are conveyed.  However, comparing key strengths
>             can be complicated and difficult to implement in practice.
> 
>            That said, expert Security opinion suggests that already it is
>             infeasible to break a 128-bit key using a classical computer, and 
>  
>           s/key/symmetric key/

amended.

>             thus the concern for conveying higher-strength keys begins to lose 
>             its allure.
> 
>             Implementations SHOULD only use transport algorithms to those 
> 
>           s/transport algorithms/secure transport/
> 
That substitution by itself seems to result in an incomplete sentence.  How about this:  

	"Implementations SHOULD only use secure transport algorithms meeting local policy.”

>             meeting local policy.  A reasonable policy may, e.g., state that 
>             only algorithms listed as "recommended" by the IETF be used.
> 
>           s\algorithms/ciphersuites/
> 

Done.

>             Another reasonable policy may be to only use quantum-resistant 
>             algorithms.
> 
>           Works for me with changes above. I would only add a few words at the end of the second para that things may change in the future (e.g. if full-size quantum computers appear), so it is recommended to follow up-to-date advise from crypto community when protecting transport channel.
> 
>           I would also remove the last sentence in the last para, mostly because
>           it’s difficult to follow in practice (we still know not much about post-quantum crypto and generally it’s not yet widely supported in protocols like TLS) and instead reference RFC 7525 which contains recommendations how to use TLS in applications.  I don’t know in similar RFC exists for SSH, sorry...
> 

I removed the last sentence but did NOT add “a few words”, because the existing text already covers the “need to stay current” angle.  The current “last” paragraph reads:

            Implementations SHOULD only use secure transport algorithms 
            meeting local policy.  A reasonable policy may, e.g., state that
            only ciphersuites listed as "recommended" by the IETF be used.

Good?

Kent

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 14 Sep 2021 17:59:03 +0300

Hi Kent,

Hi Valery,

             The "cert-data" node:

Is this okay?

          Yes, thanks.

 

          OK, thanks for the explanation.

 

Section 3.5.

          s/key/symmetric key/

amended.

          I was trying to avoid using combination of words “transport algorithm”

          just to make text more accurate (usually we have transport protocols,

          which are implemented using some crypto algorithms, if we talk

          about secure transports). So how about:

          Implementations SHOULD only use secure transport protocols meeting local policy.

          ?

Done.

Good?

          Works for me if you replace “algorithms” with “protocols” :-)

          (I still think that referencing RFC 7525 would be helpful, but it’s up to you, it’s definitely not a big deal).

          Thank you,
          Valery.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Sep 2021 17:03:26 +0000

Hi Valery,

Done.

>           Works for me if you replace “algorithms” with “protocols” :-)

Done (per above)

>           (I still think that referencing RFC 7525 would be helpful, but it’s up to you, it’s definitely not a big deal).

Added.   Resulting diffs here: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-21.txt <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-21.txt>

>           Valery.

No, thank you!  :)

K.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 15 Sep 2021 14:57:45 +0300

Hi Kent,

Added.   Resulting diffs here: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-21.txt

          Good, my concerns are resolved. Thank you for your patience and collaboration.

          Regards,

          Valery.