Re: [netconf] ssh/tls key generation support

Dhruv Dhody <dhruv.ietf@gmail.com> Tue, 22 March 2022 07:31 UTC

Return-Path: <dhruv.ietf@gmail.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 A59873A0B7C for <netconf@ietfa.amsl.com>; Tue, 22 Mar 2022 00:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u7lbEjEe8jbp for <netconf@ietfa.amsl.com>; Tue, 22 Mar 2022 00:31:14 -0700 (PDT)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5DA3A0B7B for <netconf@ietf.org>; Tue, 22 Mar 2022 00:31:14 -0700 (PDT)
Received: by mail-il1-x12e.google.com with SMTP id b9so11881091ila.8 for <netconf@ietf.org>; Tue, 22 Mar 2022 00:31:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZcOPr145R/WELvATcfvsy12MY1q6MIpl4SLf5MlUVmE=; b=b7gWGza4waM0r+SPGQphuh6l+hBRKbE/C4oksv0P2NQSX5H2tiKDTPmAQ4kpEc7kex zZlG5bS7KDMkKP0/KQCAsV05L+bahQPvnhlXXZZmlhB/23HWIbvEEuYq7fjmIbvdFPZz 3F+4Xer/QjPI6LvL48Q/9GhWzqElxmo2KMMrnpxJbDB0IdDsEhUnAszx1dA9C41u/CLs 4I8kymwWwW+/ocuf9Np1W5QCej5o5iOspOCDyqg9cx5eRpmEtozhfnr74xlsk4yjhJvV jTDoLmRo2kD6oCqEH3KXqv2iyswO96amBPTziZ8SIIYzvYIjhEIcEaMboKAv8q0srdtf yFXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZcOPr145R/WELvATcfvsy12MY1q6MIpl4SLf5MlUVmE=; b=x1IjEAi+1Guj7wKw7ni6LC4ku4joWaKC3Mg29J/O1a6819pQ8Ei9VpPcRB9C3F2nX4 tHdOMQThTJvsScYr1Y3Nki2XZcqZ99uh3SpjSteJHJod0FT+lbWP3f2sNX30EvupzCue h7EJF7rbiRumLB3lXqtRH02xsn+T3iyswh8Held2H+XCPlQbtGsl/uWh3NOIMGjE0F77 fuaX8ydO45BcHC5OB0Nyuw1OMvTgNtNRPgaGx2UnJ981fTiHZk8ss37HcDy2IqcOl8Eo TRXSsIQisBFsUSIHMUijTlV1ZBFur0vLbEX2PeXP5h3lRQNfoVgUwIWverE0D6XofOIS +fmw==
X-Gm-Message-State: AOAM530gRataH+wcukDYIk5LXYe56ayAOp4zNpNhMTisL3+dgFXVzFA9 kByoJo743a3PgGb1NjfMLgoMJXXcD6b788ZqUrY=
X-Google-Smtp-Source: ABdhPJwg484vJ2C5nJBbuwHye0U2C0lFqMpomWYEVRYtlTbGhsvH4SHiUiFSd3pnAsTuwFSAXRX2BlSPC5uToAg5wqQ=
X-Received: by 2002:a92:6907:0:b0:2bc:4b18:e671 with SMTP id e7-20020a926907000000b002bc4b18e671mr10753958ilc.299.1647934272788; Tue, 22 Mar 2022 00:31:12 -0700 (PDT)
MIME-Version: 1.0
References: <20220322065600.c26vr26mdlevccgo@anna>
In-Reply-To: <20220322065600.c26vr26mdlevccgo@anna>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Tue, 22 Mar 2022 13:00:36 +0530
Message-ID: <CAB75xn7GsGMzRdy8ipzXGsj57JUpkqdUe31Y8utQG-5TVrqQDg@mail.gmail.com>
To: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>, netconf@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f15c3005dac99886"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/eLB8VJVbUpOB_OUCRSw7UfooJvI>
Subject: Re: [netconf] ssh/tls key generation support
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, 22 Mar 2022 07:31:22 -0000

Hi WG,

I agree!

And as an author of the PCEP YANG model which is dependent on
draft-ietf-netconf-tls-client-server
<https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/>;
we would really like to see it published SOON!

Thanks!
Dhruv

On Tue, Mar 22, 2022 at 12:26 PM Jürgen Schönwälder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> Kent asked for feedback concerning key generation support. My view is
> the following:
>
> - As long as you can trust your device to generate good keys, it is
>   good idea to generate keys on the device so that keys are never sent
>   around and they may be kept in protected storage.
>
> - As stated by others during the WG meeting, the proposal in
>   draft-ietf-netconf-ssh-client-server-27.txt should be more explicit
>   that it is about generating key pairs and in particular hostkey
>   pairs.
>
> - Generating server key pairs is just a step of a more complex
>   process. In SSH, clients traditionally built trust into hostkeys
>   using an ad-hoc process, in TLS this is traditionally done using
>   certificates. Hence, at least for TLS, we get into the territory of
>   generating certificates, either creating self-signed certs, hooking
>   into an automated certification system like lets encrypt, or
>   handling a full blown cert process (generating csrs etc).
>
> - If we got the YANG modules right, then it should be possible to add
>   support for server key generation without changes to the existing
>   definitions (i.e., we can do this later if we decide to do so, there
>   is not reason why this needs to be done now).
>
> - The SSH and TLS documents started as WG documents in July 2016, we
>   are getting close to 6 years in the WG and it is somewhat unclear
>   what the uptake of these documents will be. If we get into
>   certificate territory, I fear we add at least another year of delay.
>
> My take is that we should leave key generation for future work and
> instead try to deliver what we have. Note that the documents highly
> interrelated and they have overall grown to a significant size (even
> if we leave out the IANA algorithm registry modules, this is
> substantial).
>
>   | Pages | Lines | Draft                                            |
>   |-------+-------+--------------------------------------------------|
>   |    63 |  3528 | draft-ietf-netconf-crypto-types-22.txt           |
>   |    51 |  2856 | draft-ietf-netconf-keystore-24.txt               |
>   |    31 |  1736 | draft-ietf-netconf-http-client-server-09.txt     |
>   |    60 |  3360 | draft-ietf-netconf-netconf-client-server-25.txt  |
>   |    56 |  3136 | draft-ietf-netconf-restconf-client-server-25.txt |
>   |   137 |  7672 | draft-ietf-netconf-ssh-client-server-27.txt      |
>   |    34 |  1904 | draft-ietf-netconf-tcp-client-server-12.txt      |
>   |   146 |  8176 | draft-ietf-netconf-tls-client-server-27.txt      |
>   |    39 |  2184 | draft-ietf-netconf-trust-anchors-17.txt          |
>
> /js
>
> --
> Jürgen Schönwälder              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
>