Re: [netconf] crypto-types fallback strategy
Martin Bjorklund <mbj@tail-f.com> Tue, 08 October 2019 10:22 UTC
Return-Path: <mbj@tail-f.com>
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 D73B6120169 for <netconf@ietfa.amsl.com>; Tue, 8 Oct 2019 03:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 zbBvl_reSVn4 for <netconf@ietfa.amsl.com>; Tue, 8 Oct 2019 03:22:36 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07EED1200B8 for <netconf@ietf.org>; Tue, 8 Oct 2019 03:22:36 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 58E951AE018B; Tue, 8 Oct 2019 12:22:34 +0200 (CEST)
Date: Tue, 08 Oct 2019 12:22:08 +0200
Message-Id: <20191008.122208.2297815182441890483.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: ietfc@btconnect.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016da8b59883-9c9c21fa-5030-4dd5-867e-5e33bf7b379d-000000@email.amazonses.com>
References: <02f501d57846$e29a3b20$4001a8c0@gateway.2wire.net> <0100016d8834e6b1-d2301e8e-89e5-4fb1-ae58-057e82c4cf7f-000000@email.amazonses.com> <0100016da8b59883-9c9c21fa-5030-4dd5-867e-5e33bf7b379d-000000@email.amazonses.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/U4bbhRbBtiLkSI2Q3U1a1hjpBXk>
Subject: Re: [netconf] crypto-types fallback strategy
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: Tue, 08 Oct 2019 10:22:38 -0000
Hi, Kent Watsen <kent+ietf@watsen.net> wrote: > > > > To put an end to this email, recall above it was said that the > > secondary goal is to pass an "algorithm" parameter into the > > 'generate-symmetric-key' and 'generate-asymmetric-key' actions (what > > kind of key to generate, right?). Most of the above regards the key > > formats (not algorithms, though the OneSymmetricKey and > > OneAsymmetricKey structs do self-identify their algorithms). I don't > > have an answer for this yet, but maybe we can mimic some aspect of the > > above for it? > > > > Comments? > > > Answering myself here. Having identities for "key formats" is useful > and maybe helpfully decouples things, but how to support the actions > remains open and yet critical to support. > > Other than the "IANA registry" based proposal I gave Sep 27th (which I > still think is pretty good), I don't see any other way to do this > other than by going half-way back towards the old identity approach. > By "halfway", I mean to say that it doesn't define all the algorithm > types, just the subset needed for our immediate needs. So, either in > addition or as a replacement to the identities for key formats, I > think we should do the following: > > In ietf-crypto-types: > > // define base identities so they can be referenced by groupings > identity asymmetric-key-algorithm; > identity symmetric-key-algorithm; > identity hash-algorithm; > > In ietf-asymmetric-key-algs.yang: > > identity foo { base "asymmetric-key-algorithm" } > ... > > In ietf-symmetric-key-algs.yang > > identity bar { base "symmetric-key-algorithm" } > ... > > In ietf-hash-algs.yang > > identity baz { base "hash-algorithm" } > ... But isn't this again a bit too much? Why can't we define the base identities in ietf-crypto-types, and then just the algs we need for ssh in a separate module, and the algs we need for tls in another. > The three new modules can also be defined in the crypto-types draft, > but by putting each algorithm-type into a distinct module, and by only > defining a minimum number of algorithm types (there were many more > before), it gets closer to what Rich wants, some modularity and no > grand-unified solution. On the downside, servers would have to > implement more than one module and it we continue to need some > config-false list of algorithms supported by the server (i.e., > implementing the module != supporting all identities in the module). Note that in general, a server may support one set of algs for node A and another set of algs for node B. So just listing the supported set of identities is not sufficient. Which is why I suggest (again) that we don't try to solve this problem here and now. /martin > > Thoughts? Is this something everyone can get behind? Do you think we > should continue to have an identity for the "key format", or combine > it with the definition of the "algorithm" node? > > > PS: Tom, I think this email answers your "big picture" question. > > Kent // contributor > > > >
- [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Per Hedeland
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Per Hedeland
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy tom petch
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- [netconf] FW: crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Holland, Jake
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] [Taps] crypto-types fallback strate… tom petch
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Rob Wilton (rwilton)
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy tom petch
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy tom petch
- Re: [netconf] crypto-types fallback strategy Wang Haiguang
- Re: [netconf] crypto-types fallback strategy Salz, Rich
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Schönwälder
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Kent Watsen
- Re: [netconf] crypto-types fallback strategy Martin Bjorklund