Re: [netconf] crypto-types fallback strategy

Martin Bjorklund <mbj@tail-f.com> Wed, 25 September 2019 06:36 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 8CFE21208FF; Tue, 24 Sep 2019 23:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 fFMfhqj6UF1v; Tue, 24 Sep 2019 23:36:47 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2691120934; Tue, 24 Sep 2019 23:36:47 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id D68301AE0115; Wed, 25 Sep 2019 08:36:44 +0200 (CEST)
Date: Wed, 25 Sep 2019 08:36:20 +0200 (CEST)
Message-Id: <20190925.083620.220579291789643978.mbj@tail-f.com>
To: jholland@akamai.com
Cc: rsalz@akamai.com, netconf@ietf.org, taps@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <3F71FEE6-3679-4482-B210-6585A15E0BA7@akamai.com>
References: <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> <AFB2FE43-947F-428B-8087-A8BB22445E2D@akamai.com> <3F71FEE6-3679-4482-B210-6585A15E0BA7@akamai.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/nJkT63p-N7yJ9Jr4nGTcLNEpAC8>
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: Wed, 25 Sep 2019 06:36:51 -0000

Hi,

Just a quick comment on the usage of YANG in this document.  Since it
doesn't define configuration data to be used over a management
protocol like NETCONF or RESTCONF, you may want to have a look at
https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext, which
introduces a YANG extenstion statement to define "structures" (with no
predefined semantics), and replace your:

  container preconnection { ... }

with:

  sx:structure preconnection { ... }



/martin



"Holland, Jake" <jholland@akamai.com> wrote:
> (+taps)
> Hi,
> 
> Thanks for taking a look at that model, Tom.  I'll give just a
> little background:
> 
> The current taps-api structure was driven basically by an attempt to
> support the examples given in the taps-interface draft, for instance
> in section 5.3.1:
> https://tools.ietf.org/html/draft-ietf-taps-interface-04#section-5.3.1
> 
> I didn't do much (or any? don't recall...) of a search for crypto
> models before throwing together the early ietf-taps-api.yang drafts,
> including the security config stuff.  I mostly worked off the API
> examples, with intent to look for a more serious answer later as
> we try to integrate the secure connection support into a reference
> implementation or 2.
> 
> What's there now hasn't been through any kind of security review, and
> I'd characterize it as a placeholder, at the moment.  (The taps use of
> yang is still relatively immature.)
> 
> I'd be very grateful for a grouping or object of some kind that I
> could pull in by import from another module, and would support
> using it in taps-api-yang if we can use it to do what we need (which
> is to configure connection endpoints to allow secured connections,
> for either client or server endpoints).  I think that would make for
> a very helpful improvement.
> 
> Part of the point of using yang in taps was to be able to better exploit
> yang work from other wgs, and this would be an excellent opportunity to
> put that into practice, I think.  So I would be very delighted to import
> a model that does this right.
> 
> Best,
> Jake
> 
> On 2019-09-24, 13:02, "Salz, Rich" <rsalz@akamai.com> wrote:
> 
> Jake,
> 
> As the author of the draft referenced below, do you care to comment?
> 
> The crypto-types document in the netconf WG is undergoing some pretty drastic surgery.
> 
> 
> On 9/24/19, 4:50 AM, "tom petch" <ietfc@btconnect.com> wrote:
> 
>     Going back a bit, since this is a more generic comment, I get a
>     different, simpler perspective in
>     draft-jholland-taps-api-yang
>     which has me wondering just how complicated this needs to be for it to
>     be useful in other WGs.
>     
>     The I-D defines
>       identity security-algorithm {description "Base identity for security
>     algorithms."
>       identity cipher-suite { base security-algorithm;description "Base
>     identity for security cipher suites.";
>       identity signature-algorithm {base security-algorithm;
>     description "Base identity for security signature algorithms.";
>       identity ed25519 {base signature-algorithm;
>       identity TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 {
>         base cipher-suite;
>     
>     and
>     
>       grouping security-credentials {
>         leaf identity { type string;
>         leaf trust-ca { type string;
>         leaf algorithm { type identityref {base security-algorithm;
>         leaf pre-shared-key { type string;
>         leaf private-key { type string;
>         leaf private-key-callback-handle {type string;
>         leaf public-key {type string;
>     
>     (No SSH but that does not surprise me:-)
>     
>     Again a more general comment, the IETF often starts simple and adds lots
>     later, which sometimes goes wrong because no allowance was made for
>     slotting in extras, but an approach which, I think, more often leads to
>     successful adoption.
>     
>     Thus will TAPS consider using
>     draft-ietf-netconf-crypto-types
>     or will they RYO?
>     
>     Tom Petch
>     
>     ----- Original Message -----
>     From: <Schönwälder>; "Jürgen" <J.Schoenwaelder@jacobs-university.de>
>     To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
>     Cc: "Russ Housley" <housley@vigilsec.com>om>; <netconf@ietf.org>rg>; "Sean
>     Turner" <sean@sn3rd.com>om>; "Rifaat Shekh-Yusef" <rifaat.ietf@gmail.com>
>     Sent: Wednesday, September 18, 2019 5:36 PM
>     
>     > On Wed, Sep 18, 2019 at 03:37:14PM +0000, Rob Wilton (rwilton) wrote:
>     > > >From the gist of the discussion, the punch list appears to be:
>     > >
>     > > - revert back to using identities, as they were in the -08 revision.
>     > > - only define base identities for what's needed immediately for TLS
>     and SSH and keystore key-encryption.
>     > > - define these base identities in distinct YANG modules
>     > > - have each identity's description statement indicate what the
>     binary key data is encoded.
>     > > [RW]
>     > > I think that this matches my view, except for "define these base
>     identities in distinct YANG modules".  I don't feel particularly
>     strongly about this, but I was thinking that the base identities would
>     still be defined in crypto-types.yang, which might help keep the import
>     references simple.
>     >
>     > I tend to agree that sometimes less modules is more. For me, the
>     > problem is likely more that I am not entirely sure what the proper
>     > base types would be, which may depend on what exactly they are used
>     > for. I guess I wait until I see the description text...
>     >
>     > > A bit separate from the above, but still in mind:
>     > >
>     > >   - specify that all TLS public-keys are a DER-encoded
>     SubjectPublicKeyInfo structure
>     > >   - specify that all SSH public-keys are a "ssh-public-key-type"
>     type (see below)
>     > >   - specify that all encrypted symmetric keys are a DER-encoded
>     OneSymmetricKey structure
>     > >   - specify that all encrypted asymmetric keys are a DER-encoded
>     OneAsymmetricKey structure
>     >
>     > I would check what is commonly used in existing configuration
>     > interfaces. We are not inventing the wheel here. And whatever we
>     > define better is usable with existing implementations and tools.
>     >
>     > > The "ssh-public-key" type would be defined as:
>     > >
>     > >      typedef ssh-public-key-type {
>     > >          type binary;
>     > >          mandatory true;
>     > >          description
>     > >            "The binary public key data for this SSH key, as
>     > >             specified by RFC 4253, Section 6.6, i.e.:
>     > >
>     > >               string    certificate or public key format
>     > >                         identifier
>     > >               byte[n]   key/certificate data.";
>     > >          reference
>     > >            "RFC 4253: The Secure Shell (SSH) Transport
>     > >                       Layer Protocol";
>     > >           }
>     >
>     > The SSH implementations that I use have the binary key data rendered
>     > in ASCII. In fact, the whole key record is rendered in ASCII. I
>     > strongly suggest to use formats that are well established.
>     >
>     > /js
>     >
>     > --
>     > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>     >
>     > _______________________________________________
>     > netconf mailing list
>     > netconf@ietf.org
>     > https://www.ietf.org/mailman/listinfo/netconf
>     
>     _______________________________________________
>     netconf mailing list
>     netconf@ietf.org
>     https://www.ietf.org/mailman/listinfo/netconf
>     
> 
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf