From nobody Wed Jan 27 15:33:06 2021 Return-Path: <01000177463160fb-8dd3e153-dd68-4eba-b370-49aed4d02a87-000000@amazonses.watsen.net> X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945863A0D60; Wed, 27 Jan 2021 15:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUzV39IHvAwi; Wed, 27 Jan 2021 15:32:59 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832B23A0D64; Wed, 27 Jan 2021 15:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1611790377; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=40yNJK1r5WqPRwwAwXrbbDBJ0hRRjym+UlJzylnCe3w=; b=cGTHHuq5tiaj7NxqtHwBAWzEJOX+yroHhTpOE4160TcvnGXyCRr/iDFlV9l1dwZp EfP19lo6weVZWLehNrIFlsTc2BOLLHjclVqZRcThl1pHFQLZyO1bKAqOTwfgpXsG4fl E3CH5SJbnjxybGyD2cRLARa+NSq1hKoGKoZrtg28= From: Kent Watsen Message-ID: <01000177463160fb-8dd3e153-dd68-4eba-b370-49aed4d02a87-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 27 Jan 2021 23:32:57 +0000 In-Reply-To: <01000176b576c690-7bb22a7a-1fb1-485f-bb06-51f3c08d0fdc-000000@email.amazonses.com> Cc: draft-ietf-netconf-trust-anchors.all@ietf.org, "netconf@ietf.org" , Yoav Nir , secdir@ietf.org To: Benjamin Kaduk References: <160107496501.14047.597283542214697710@ietfa.amsl.com> <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@email.amazonses.com> <010001768d05bf5b-eb6d3807-2d23-45c8-a905-dfdaf9fe5bb3-000000@email.amazonses.com> <20201230011701.GO89068@kduck.mit.edu> <01000176b576c690-7bb22a7a-1fb1-485f-bb06-51f3c08d0fdc-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.01.27-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 23:33:01 -0000 --Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 =E2=80=9Craw=E2=80=9D and =E2=80=9CCMS=E2=80=9D. 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 =E2=80=9CCMS keys are RECOMMENDED=E2=80=A6=E2= =80=9D? Details: 1) for asymmetric keys - the =E2=80=9Craw=E2=80=9D value is an RSAPrivateKey, = ECPrivateKey, etc. - the =E2=80=9Ccms=E2=80=9D value is an OneAsymmetricKey (from RFC = 5958) - the OneAsymmetricKey structure includes a field called = =E2=80=9Cattributes=E2=80=9D - the =E2=80=9Cattributes=E2=80=9D field is of type = OneAsymmetricKeyAttributes - attribute values van come from, e.g., RFC 7906 2) for symmetric keys - the =E2=80=9Craw=E2=80=9D value is an octet string - the =E2=80=9Ccms=E2=80=9D value is an OneSymmetricKey (from RFC = 6031) - the OneSymmetricKey structure includes a field called = =E2=80=9CsKeyAttrs=E2=80=9D - the sKeyAttrs field is of type Attributes - SKeyAttributes include "at-pskc-keyUsage" Kent > On Dec 30, 2020, at 4:03 PM, Kent Watsen wrote: >=20 > Hi Ben, >=20 >> 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. >=20 > 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)? >=20 > I=E2=80=99m 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=E2=80=99s not added? >=20 > One thing not mentioned before, is that, while the keys are = unconstrained in the three base drafts (crypto-types, keystore, and = truststore), the =E2=80=9Ctis-client-server=E2=80=9D and = =E2=80=9Cssh-client-server=E2=80=9D 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=E2=80=99s use isn=E2=80=99t always necessary... >=20 >=20 >>=20 >> Thanks, >>=20 >> Ben >=20 >=20 > Kent >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 =E2=80=9Craw=E2=80=9D and =E2=80=9CCMS=E2=80=9D.  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 =E2=80=9CCMS keys are = RECOMMENDED=E2=80=A6=E2=80=9D?

Details:

1) = for asymmetric keys
      - the =E2=80=9Craw= =E2=80=9D value is an RSAPrivateKey, ECPrivateKey, etc.
  =     - the =E2=80=9Ccms=E2=80=9D value is an OneAsymmetricKey = (from RFC 5958)
      - the OneAsymmetricKey structure includes a field = called =E2=80=9Cattributes=E2=80=9D
      - = the =E2=80=9Cattributes=E2=80=9D field is of = type OneAsymmetricKeyAttributes
    =   - attribute values van come from, e.g., RFC 7906

2) for symmetric keys
  =     - the =E2=80=9Craw=E2=80=9D value is an octet = string
      - the =E2=80=9Ccms=E2=80=9D value = is an OneSymmetricKey (from RFC 6031)
      - = the OneSymmetricKey structure includes a field = called =E2=80=9CsKeyAttrs=E2=80=9D
      - the sKeyAttrs field is of = type Attributes
      - SKeyAttributes include = "at-pskc-keyUsage"

Kent



On Dec 30, 2020, at 4:03 PM, Kent Watsen = <kent+ietf@watsen.net> 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=E2=80=99m 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=E2=80=99s 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 = =E2=80=9Ctis-client-server=E2=80=9D and =E2=80=9Cssh-client-server=E2=80=9D= 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=E2=80=99s use isn=E2=80=99t always necessary...



Thanks,

Ben


Kent


_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1--