Re: [netconf] ietf-ssh-server host key

Michal Vasko <> Mon, 05 June 2023 14:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88814C152F1C for <>; Mon, 5 Jun 2023 07:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Status: No, score=-4.397 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q_xOS7C78WNn for <>; Mon, 5 Jun 2023 07:27:32 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 613C4C151B30 for <>; Mon, 5 Jun 2023 07:27:31 -0700 (PDT)
Received: from [IPV6:2001:67c:1220:80c:f6:4a3a:d717:4a09] (unknown [IPv6:2001:67c:1220:80c:f6:4a3a:d717:4a09]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 9167640006F; Mon, 5 Jun 2023 16:27:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=office2-2020; t=1685975248; bh=zcX8Rna39PowVftcsykd4Pvyg6lDlHA2SsAB7JEhGsk=; h=Date:From:Subject:To:Cc:References:In-Reply-To; b=OHw0hypqBNQIWRp4Ldbes1b0r4AS8NAZGUom4vf8ho0fFN76dgm5Gh981Hh7p8IZm 8vWyBfWo2TRk2Q4z8lVLzp6EjgmQB6ebWsuv/CpYAVy9QD8wwBTlTlO95WEJ4+774D y5M5BgqOPo3eWo1CTZpDvh2pfOpoyKEsdI1KOX4wg3m8l1CFbjbRnBnXK1O63Nnf41 jV5G3aNj9TxxCiB/lgACLDOcNXq9gCt0NT+ms47aw5pO8jRICnz7+5w+I7R/idKq2p G44jhpaqNqI5uIZlHjK3ivP+fTCJR3bpJQznxFTcXiIjTKxV/YS3OE+DgHAt36MTUq P9ts6h+79L0Cg==
Message-ID: <>
Date: Mon, 05 Jun 2023 16:27:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2
From: Michal Vasko <>
To: Kent Watsen <>
Cc: "" <>
References: <> <>
Content-Language: en-US
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070106060201020306080107"
Archived-At: <>
Subject: Re: [netconf] ietf-ssh-server host key
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Jun 2023 14:27:37 -0000

Hi Kent,

> Hi Michal,
>> Hello,
>> we are implementing these modules (ietf-netconf-server and imports) 
>> and I have a question regarding the container 
>> `/ietf-netconf-server:netconf-server/listen/endpoint/ssh/ssh-server-parameters/server-identity/host-key/public-key`. 
>> It looks like this
>> +--rw public-key
>>    +--rw (inline-or-keystore)
>>       +--:(inline) {inline-definitions-supported}?
>>       |  +--rw inline-definition
>>       |     +--rw public-key-format     identityref
>>       |     +--rw public-key            binary
>>       |     +--rw private-key-format?   identityref
>>       |     +--rw (private-key-type)
>>       |        +--:(cleartext-private-key) {cleartext-private-keys}?
>>       |        |  +--rw cleartext-private-key?   binary
>>       |        +--:(hidden-private-key) {hidden-private-keys}?
>>       |        |  +--rw hidden-private-key?   empty
>>       |        +--:(encrypted-private-key) {encrypted-private-keys}?
>>       |           +--rw encrypted-private-key
>>       |              +--rw encrypted-by
>>       |              +--rw encrypted-value-format    identityref
>>       |              +--rw encrypted-value           binary
>>       +--:(keystore) {central-keystore-supported,asymmetric-keys}?
>>          +--rw keystore-reference?   ks:asymmetric-key-ref
>> What is there the public key for? For a key to be used as a host key 
>> you only need the private key (technically, you can always generate 
>> the public key from the private key but the public key is not needed 
>> at all in this case) and it is causing us some problems because it is 
>> even required to be in the `ssh-public-key-format` without any 
>> information as to why. Thanks for any explanation.
> You are correct, the "public-key" node typically isn't needed when 
> configuring SSH.
> The reason it is in the `SSH model is because:
> 1) sometimes (I forget which Security person said this) a public-key 
> cannot be extracted from a private-key, thus a generic private-key 
> type seems to be incomplete without its public-key encoded also.  It 
> would be good to reconfirm this claim.

MV: That is indeed interesting and libssh nor OpenSSH sshd would 
probably not be able to use such a key because they expect paths to the 
private key when setting the host key. I must also correct myself, it 
really seems the tools generate the public key themselves because it is 
presented to the client when creating the SSH session.

> 2) albeit unusual, it isn't a hard thing for (my) code to encode the 
> public-key also, so I felt it was a minor nuisance to ensure 
> future-proofing.

MV: The problem is with the required public key formats that make it 
chaotic. Note that we have also defined our own identity for the private 
key format which corresponds to `subject-public-key-info-format` of the 
public key (X.509).

So for SSH:

private key format - rsa-private-key-format, ec-private-key-format (, 
public key format - ssh-public-key-format

And for TLS:

private key format - rsa-private-key-format, ec-private-key-format (, 
public key format - subject-public-key-info-format

Now, some practical information that may also be relevant.

libssh can directly work with:

private key format - rsa-private-key-format, ec-private-key-format
public key format - ssh-public-key-format

And OpenSSL can directly load:

private key format - subject-private-key-info-format
public key format - subject-public-key-info-format

We wanted to support both of these pairs for both SSH and TLS but not to 
mix them because it requires much more code to make it work ("manual" 
key creation using OpenSSL). So, SSH is fine, by default, because libssh 
can be used to load both private and the public key. We have encountered 
the problem when trying to use `subject-private-key-info-format` with 
`subject-public-key-info-format`, the latter was not allowed. But with 
TLS the problem is there already, the allowed formats are not really 
compatible and the private keys need to be created manually to use 
OpenSSL for the TLS connection.

> 3) thus the propagation of the asymmetric-key-pair-grouping (in 
> crypto-types) makes it to the ssh-client-server draft.  FWIW, this is 
> why it's named "asymmetric-key-pair-grouping" and not 
> "private-key-grouping".
> Can you say some more about why its presence is causing problems?
> If this is a real problem (or perhaps even if just a nuisance), the 
> crypto-types drafts could define also a "private-key-grouping" (having 
> just the private-key) and then recast 
> "asymmetric-key-pair-grouping" to use it.  Or, if it turns out the 
> claim (see #1) in unfounded, the "asymmetric-key-pair-grouping" could 
> be discarded altogether.

MV: I tried to describe the problem and I hope it can be understood. I 
am not saying the YANG needs to reflect the APIs of common libraries but 
am then wondering based on what were the restrictions of SSH and TLS 
public key formats added. Furthermore, there can always be new public 
key formats added by deriving from the provided identity and these would 
not be possible to use because of the must conditions. It actually seems 
the public key formats are restricted for all their uses (even for 
SSH/TLS client authentication) so new public key formats can never be 
used and the base identity is useless.

What would make most sense based on our experiences would be to either 
remove the public keys from the host key altogether or, if there really 
are reasons for keeping them there, lift their severe restrictions. 
Ideally, to only allow compatible pairs together but that would require 
some non-trivial modelling work. It would also be possible to remove all 
the conditions and let implementations decide what they exactly support 
because there seems to be too many options although it is always better 
if properly expressed in YANG. And one should never forget to allow for 
new future formats which cannot really be added and used, currently, at 
least for the public key.