Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-crypto-types-29: (with DISCUSS and COMMENT)

[Kent Watsen <[e-mail]>]

Hi Roman,

Thank you for your valuable comments.
Please see below for responses.

Kent


> On Jan 29, 2024, at 6:07 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-netconf-crypto-types-29: 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/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> ** hidden key
> 
> --  Section 2.1.4.3.  “The "hidden-key" node is of type "empty" as the real
> value          cannot be presented via the management interface. ” -- YANG. "A
> hidden key.  How such keys are created is outside                 the scope of
> this module.";
> 
> “hidden key” is underspecified.  The above are the two descriptions I found.
> Could a detailed explanation please be added – what is it?  When (how) would
> one use it?  What is the difference between hidden and access controlled?
> 
> I observe that draft-ietf-netconf-keystore suggests that it could be related to
> TPMs and Section 4 of that draft uses it in the context of administrators with
> different privileges.  However, this document is the base reference.

True, a "hidden key” is best implemented via a TPM, albeit neither this draft
nor the “keystore” insist on it.

To your DISCUSS, how about this updated description?
NEW:

             "A hidden key.  It is of type 'empty' as it's value is
              inaccessible via management interfaces.  Though
              hidden to users, such keys are not hidden to the server
              and may be referenced by configuration to indicate which
              key a server should use for a cryptographic operation.
              How such keys are created is outside the scope of this
              module.";

Thoughts?





> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Valery Smyslov for the SECDIR review.
> 
> ** Section 2.1.4.8.  Editorial.
> 
>   *  The "cert-data" node contains a chain of one or more certificates
>      encoded using a "signed-data-cms" typedef discussed in
>      Section 2.1.3.
> 
> I observe that Section 2.1.3 says almost nothing about signed-data-cms

True and, more broadly, that section says very little about any of the typedefs.
This is true also for all nine drafts in the document series.  In general, I struggle
with trying to balance being DRY (don’t repeat yourself, or, in this case, don’t 
repeat what is in the YANG module) and providing nice introductions.

In general, I want to these documents to be as small as possible (they’re already
huge).  Truly, the entire “Data Model Overview” section could be skipped by
anyone reading the YANG module.

The “Data Model Overview” sections (in all the drafts) originally just had a single
YANG tree-diagram, but the WG wanted it to be broken up, with fluffy text, etc.
It’s a bit of a sore point for me.  ;)

In any case, that’s the background.  Since this is just a COMMENT, I think that
I’ve leave it at that for now, and wait to see if others want more text in the 2.1.3
sections.


> ** Section 2.1.4.12.  Editorial. The narrative text doesn’t explain what
> “certificates” are.

This section points to "end-entity-cert-grouping” saying:
	The "end-entity-cert-grouping" grouping is discussed in Section 2.1.4.9.

Section 2.1.4.9 says:
       The "cert-data" node contains a chain of one or more certificates
       encoded using a "signed-data-cms" typedef discussed in
       Section 2.1.3.

This is the text you quoted above - as the same text is in Section 2.1.4.9.  
That said, I do see an opportunity for improvement:

In 2.1.4.8.  (The "trust-anchor-cert-grouping” Groupin
NEW:
       The "cert-data" node contains a chain of one or more certificates
       containing at most one self-signed certificates (the “root” certificate),
       encoded using a "signed-data-cms" typedef discussed in Section 2.1.3.

In 2.1.4.9. (The "end-entity-cert-grouping” Grouping)
NEW:
       The "cert-data" node contains a chain of one or more certificates
       containing at most one certificate that is neither self-signed nor
       having Basic constraint "CA true”, encoded using a 
       "signed-data-cms" typedef discussed in Section 2.1.3.


Thoughts?

> ** Section 3.5.
>   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.
> 
> I don’t understand the guidance in this section.  I would have benefited from
> clarity in the following areas.
> 
> -- Explain the impact of using keys whose strength exceeds the underlying
> transport connection (i.e., it doesn’t offer more security)
> 
> -- The verb “accessing” is confusing.  Let’s say that an implementation notices
> a discrepancy between key strength, what is it supposed to do?
> 
> -- The last sentence (“However, comparing ...) seems to acknowledge (correctly)
> that this advice might not be practical.  Is the WG sure the text is needed?
> 
> ** Section 3.5.
>   That said, expert Security opinion suggests that already it is
>   infeasible to break a 128-bit symmetric key using a classical
>   computer, and thus the concern for conveying higher-strength keys
>   begins to lose its allure.
> 
> Recommend removing this generic statement.  There would be a variety of reasons
> operators might choose to use symmetric keys in excess of 128-bits, policy
> being one of them.

I’m happy to remove Section 3.5 (Strength of Keys Conveyed) entirely.  

IDK if there is any value to keeping it.   I only added it because it is something
I remembered from a past life.  No one ever asked me to add this Section...

Is my understanding from your "Is the WG sure the text is needed?” above
that you lean towards removing Section 3.5?



> ** Section 3.6
>   Implementations SHOULD only use secure transport protocols meeting
>   local policy.  A reasonable policy may, e.g., state that only
>   ciphersuites listed as "recommended" by the IETF be used (e.g.,
>   [RFC7525] for TLS).
> 
> -- Would there be instances where implementation would use secure transport
> that _doesn’t_ meet local policy?

Shouldn’t be, but maybe a rouge new employee doesn’t know it ;)

Is your point that we should s/SHOULD/MUST/ here?


> -- RFC7525 has been obsoleted.  s/RFC7525/RFC9325/
Updated - thanks!


Kent