Re: [netconf] crypto-types fallback strategy

Kent Watsen <kent+ietf@watsen.net> Tue, 08 October 2019 14:07 UTC

Return-Path: <0100016dabb24e1e-ce4ee331-cf37-4f51-a342-930c95d7a963-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 52FBD12007C for <netconf@ietfa.amsl.com>; Tue, 8 Oct 2019 07:07:35 -0700 (PDT)
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_DNSWL_NONE=-0.0001, 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 LE5ttUen2pq0 for <netconf@ietfa.amsl.com>; Tue, 8 Oct 2019 07:07:34 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79F5120052 for <netconf@ietf.org>; Tue, 8 Oct 2019 07:07:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1570543652; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=CJ5hq+otV0bumeBU0VTViFVkW9HybS5fozYw4baaB/k=; b=URLnhEZYInc+mALGUp7lYGAlTOhKu0wP9TEmWNVZvRwp08gbDl6EvO8z1x8hSeut rjd684CIE2Akt07/nDgA6E3Fb33U68V63S0FGhdqAsHTkqh5nKNCfghtxKGDHXs/4X0 H6RhRuFYVAFkRQeiRopxcM9OKsWvV87GMpCZi5ec=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016dabb24e1e-ce4ee331-cf37-4f51-a342-930c95d7a963-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2227B056-5157-4E4C-A738-57C594EBD4F3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 08 Oct 2019 14:07:32 +0000
In-Reply-To: <20191008.122208.2297815182441890483.mbj@tail-f.com>
Cc: ietfc@btconnect.com, "netconf@ietf.org" <netconf@ietf.org>
To: Martin Bjorklund <mbj@tail-f.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> <20191008.122208.2297815182441890483.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.10.08-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/KWptGdd0Mdnd4GukS7gXn2OehZQ>
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 14:07:36 -0000

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

There is a difference between algorithm primitives and cipher suites
used by protocols.  In crypto types we're trying to define the primitives
that are used by the cipher suites.  Please see my email to Juergen
just now about how the "common" modules in the SSH and TLS
drafts portend to do this.  As for the primitives, the proposal above
is to keep the primitives down to the minimum needed for our 
immediate goals. 


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

Some of these questions are still hanging in the air...


Kent //