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

[Valery Smyslov <[e-mail]>]

Hi Kent,

 

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?

 

          OK, thanks for the explanation.

 

 

 

 

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

 

          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.

 

          ?





            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?

 

          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