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

Kent Watsen <kent+ietf@watsen.net> Wed, 30 December 2020 21:03 UTC

Return-Path: <01000176b576c690-7bb22a7a-1fb1-485f-bb06-51f3c08d0fdc-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 B352E3A00C9; Wed, 30 Dec 2020 13:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 FT-S0SSKOQwE; Wed, 30 Dec 2020 13:03:50 -0800 (PST)
Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC0E3A00C4; Wed, 30 Dec 2020 13:03:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1609362229; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=uJKDkbzRYh/Fcq3X5jfz1qH5xA6WAvBMcuLtSq4Lx8c=; b=R5vgIUWA9clb7xaGdH6gVz/GEidzeQYF+UOdyAXzm6buHO9/K4FWiFoUoFLO2IP0 JEeC59hW/OJLa99AQ5s/5GffT73ut1bvxK6UjLnIOxIvfmWoAxX/NZaqzWdS2SqOzay IsK64WMd3hbXJoC+RgU+Dme1x2hmxmjq0oWmWB7s=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000176b576c690-7bb22a7a-1fb1-485f-bb06-51f3c08d0fdc-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_05EA0C49-FECA-4115-A0B3-683577EDF065"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 30 Dec 2020 21:03:48 +0000
In-Reply-To: <20201230011701.GO89068@kduck.mit.edu>
Cc: Yoav Nir <ynir.ietf@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>, draft-ietf-netconf-trust-anchors.all@ietf.org, 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>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.12.30-54.240.48.93
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/DHjQkJwnE6iBUApPTovsrowbES0>
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, 30 Dec 2020 21:03:52 -0000

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