Re: [Taps] [netconf] crypto-types fallback strategy

"Holland, Jake" <jholland@akamai.com> Tue, 24 September 2019 20:39 UTC

Return-Path: <jholland@akamai.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0412094D; Tue, 24 Sep 2019 13:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 Vs6cEVggxuB1; Tue, 24 Sep 2019 13:39:19 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB50120983; Tue, 24 Sep 2019 13:38:36 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8OKQWP1007455; Tue, 24 Sep 2019 21:38:35 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=JQqKUw8KtzlLSzYfTHxZ6AyGItcnRIjI3vc/UbyUYgQ=; b=bSdFa7WMVOCsZQOnPSqleJnQTcNO9uuut/JfaxCUqVfDBIk+fafcAK0c4m5infQKG/bP 83mgkmZoPJh4LJDc944gOIVW2srgWloylZlMTeeXIzT0Favb/yrLX6rsi7URXeo7hcVq wa7wTWnsDrKF1/2U8CQpKssD5Kz+DNSufKpQ4GlAoEGak50QhYIKN/UaBGUjqQxGcBpq 88fGiWm5vlqg7vRY/xdNgoGLxy4sIrd68PtN5++Yb8rW3ObczSPCLXiqwKGHr/kCdLJF X47U5EmWfbmqDtxkor4KbEv5WWZ4Dcd/Io/42h+BESOjceRdqwEUMAahQjS3ZH/lBXgO 9Q==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2v73qb5drw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Sep 2019 21:38:35 +0100
Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8OKXCh3024331; Tue, 24 Sep 2019 13:38:34 -0700
Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint5.akamai.com with ESMTP id 2v73vp29sh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Sep 2019 13:38:34 -0700
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 15:38:33 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.005; Tue, 24 Sep 2019 15:38:32 -0500
From: "Holland, Jake" <jholland@akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
CC: "netconf@ietf.org" <netconf@ietf.org>, "taps@ietf.org" <taps@ietf.org>
Thread-Topic: [netconf] crypto-types fallback strategy
Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqc7VCKA///orIA=
Date: Tue, 24 Sep 2019 20:38:31 +0000
Message-ID: <3F71FEE6-3679-4482-B210-6585A15E0BA7@akamai.com>
References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <MN2PR11MB43669B3A47A39FD93B47292FB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <MN2PR11MB4366B5C09B4348FDAE33E2BCB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <MN2PR11MB4366F20EE2FD6DF04B965125B58E0@MN2PR11MB4366.namprd11.prod.outlook.com> <EBE4757D-E99E-41EB-A52B-A25F023BF4BC@akamai.com> <MN2PR11MB4366E4ECE10DFB018941BA5FB58E0@MN2PR11MB4366.namprd11.prod.outlook.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <MN2PR11MB436617082A8308A7A8928DDFB58E0@MN2PR11MB4366.namprd11.prod.outlook.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> <AFB2FE43-947F-428B-8087-A8BB22445E2D@akamai.com>
In-Reply-To: <AFB2FE43-947F-428B-8087-A8BB22445E2D@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.114.140]
Content-Type: text/plain; charset="utf-8"
Content-ID: <EE2F6B778B0D664DA7F641AF148F79F2@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-24_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909240167
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-24_07:2019-09-23,2019-09-24 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 phishscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 clxscore=1011 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909240167
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/oaopm1bLQ9CovvN6gspl-3XQuzs>
Subject: Re: [Taps] [netconf] crypto-types fallback strategy
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 20:39:23 -0000

(+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>; <netconf@ietf.org>; "Sean
    Turner" <sean@sn3rd.com>; "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