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
> 
> 
> 
>