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

Kent Watsen <kent+ietf@watsen.net> Wed, 27 January 2021 23:33 UTC

Return-Path: <01000177463160fb-8dd3e153-dd68-4eba-b370-49aed4d02a87-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@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 <kent+ietf@watsen.net>
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" <netconf@ietf.org>, Yoav Nir <ynir.ietf@gmail.com>, secdir@ietf.org
To: Benjamin Kaduk <kaduk@mit.edu>
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: <https://mailarchive.ietf.org/arch/msg/netconf/0LkbyZhMc892m8xKOWGGIR1XSCQ>
Subject: Re: [netconf] [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jan 2021 23:33:01 -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 <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’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
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf