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

[Kent Watsen <[e-mail]>]

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