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

[Orie Steele <[e-mail]>]

If it were possible to conform to one of the existing words, I think that
would be preferable, but I don't know if that is achievable at this point.

I think explaining that "hidden" is used to describe keys that are "not
exportable", and "not extractable", would be helpful, especially to readers
who come with familiarity with those terms.

Modifying your suggestion from above:

             "A hidden key is not exportable, and not extractable,
              and therefore, it is of type 'empty' as its value is
              inaccessible via management interfaces.  Hidden keys
              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.";

The reason would be for folks searching for those keywords, just as I
searched for "hidden" in 800-57.

OS


On Thu, Feb 1, 2024 at 9:36 AM Kent Watsen <[e-mail]> wrote:

> Hi Orie,
>
> Thanks for joining the conversation.
>
> On Jan 31, 2024, at 12:50 PM, Orie Steele <[e-mail]>
> wrote:
>
> It sounds like "hidden" is being used as a substitute for "non
> extractable" or "non exportable", through the use of software or hardware
> isolation.
>
>
> That characterization seems fair/accurate.
>
>
> I searched
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
> briefly, and could not find a better term.
>
>
> Thank you for searching, I didn’t think to because the word seemed like
> common English.
>
>
> 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
>
>
> Interesting, but we’d want the negated forms of these words, so maybe
> inextricable or unexportable?
> Yet neither of these seem as short or straightforward as “hidden” -
> thoughts?
>
>
> OS
>
>
> Kent
>
>
>
> 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/>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>