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

[Kent Watsen <[e-mail]>]

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] <mailto:[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] <mailto:[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