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

[Orie Steele <[e-mail]>]

It sounds like "hidden" is being used as a substitute for "non extractable"
or "non exportable", through the use of software or hardware isolation.

I searched
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
briefly, and could not find a better term.

Web crypto and Android use the term "extractable"

- https://developer.mozilla.org/en-US/docs/Web/API/CryptoKey/extractable
-
https://developer.android.com/privacy-and-security/keystore#SecurityFeatures

Apple uses the term "exportable"

-
https://developer.apple.com/documentation/security/1643698-seckeycopyexternalrepresentation

OS

On Wed, Jan 31, 2024 at 11:09 AM Kent Watsen <[e-mail]> wrote:

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

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>