Subject: Re: [netconf] [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13

From: Kent Watsen <[email-masked]>
Date: Wed, 27 Jan 2021 23:32:57 +0000

Hi Ben/Yoav,

I forgot to mention before that the draft supports two ways to store symmetric keys and two ways to store private keys.  In general, the two ways are “raw” and “CMS”.  The good news, when using CMS, the structure internally includes a field for the key's usage.  So, perhaps the resolution is for the Security Considerations section to say “CMS keys are RECOMMENDED…”?

Details:

1) for asymmetric keys
      - the “raw” value is an RSAPrivateKey, ECPrivateKey, etc.
      - the “cms” value is an OneAsymmetricKey (from RFC 5958)
      - the OneAsymmetricKey structure includes a field called “attributes”
      - the “attributes” field is of type OneAsymmetricKeyAttributes
      - attribute values van come from, e.g., RFC 7906

2) for symmetric keys
      - the “raw” value is an octet string
      - the “cms” value is an OneSymmetricKey (from RFC 6031)
      - the OneSymmetricKey structure includes a field called “sKeyAttrs”
      - the sKeyAttrs field is of type Attributes
      - SKeyAttributes include "at-pskc-keyUsage"

Kent

> On Dec 30, 2020, at 4:03 PM, Kent Watsen <[email-masked]> wrote:
> 
> Hi Ben,
> 
>> This doesn't really fill me with joy.  In short, constraints are going to
>> have to be applied at *some* level, even if it's not this one, or the
>> system as a whole is likely to have some very surprising security
>> properties.  I recognize that coming up with a new language to describe
>> this sort of constraints is neither fun nor easy (and trying to repurpose
>> an existing language, such as that used by X.509, is not without issues
>> either), but I'd hope we could come up with something to say about how to
>> effectively use constraints on raw public keys.
> 
> You say constraints have to be applied at some level, but is this true when TLS uses a raw key?  Likewise for SSH keys (e.g., ~/.ssh/id_rsa)?
> 
> I’m extremely hesitant to make this change.  Already this work (9 drafts in total) has been in progress for more than 5 years.  Will you object during the IETF Last Call if it’s not added?
> 
> One thing not mentioned before, is that, while the keys are unconstrained in the three base drafts (crypto-types, keystore, and truststore), the “tis-client-server” and “ssh-client-server” drafts refine the base YANG models to assert that the raw public key must be a SubjectPublicInfo structure or an SSH public key, respectively.  In fairness, this only constrains the format of the data, not how the keys are used.   That said, this approach works with OpenSSH and OpenSSL keys, apparently indicating that specifying the raw key’s use isn’t always necessary...
> 
> 
>> 
>> Thanks,
>> 
>> Ben
> 
> 
> Kent
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf