Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-yang-model-10: (with DISCUSS and COMMENT)

Mahesh Jethanandani <> Fri, 13 August 2021 23:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CED913A29E7; Fri, 13 Aug 2021 16:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 QaAOwZ1G_Ig9; Fri, 13 Aug 2021 16:08:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC9AC3A29E6; Fri, 13 Aug 2021 16:07:59 -0700 (PDT)
Received: by with SMTP id bo18so17651872pjb.0; Fri, 13 Aug 2021 16:07:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fGDFuJDQS3GDtFbBQuEKOG2UJ0n+0LKgZc77LRXA0qI=; b=f+jE19h0tw4sOV2gwdnvJX39DznBpAOCEGesH8c4eN4t2OhVuAHP5BfgZmwBWxxTCj g4LhxUHeCKGJYzIqLjXOgB7aixoXEnHPdS4fAQIBn8dzylJobg/BOG5o1Rwg9MwurnDk ft+kuHFwUdwjDxvayYMMNnSvupvzgvrrze3TX+EV/60tfbmmTuh9D7+ni/rgsa30i4E0 xIpJ9J+M7zDBvUqugMrS+FmsMv1B4GGNST7gIYvn+psPUq/22UFzxtI05SsHkrnE/lAQ rNMzFELg6pAKVmQHG3CNkwra/a3WXbYvmb259xAtoJtBJIpgtAgptHkTrJTNE8apnDeM EaQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fGDFuJDQS3GDtFbBQuEKOG2UJ0n+0LKgZc77LRXA0qI=; b=szL5AfQH5kGqTW8Q73rftDlSoJQjZO/wIiYUWvJaekWTimemxVOwIWpfeB7PlWL2ei sYREC3X70t1I/ZMLKuJq5CeTyunYSqjmY02Ux5WYRW+J6dmicXjPzz31a3pWehNavMcc qD/4Y92icKRCmGE7rI6XwiD4Sdk1ES7XamlQCj/0O4nvW4SX/d81lYr+3c9vZKNcZyBR TC2xiLi7VaCSTI1Gje97pQjABxZ3NTKnYu/3tRbTHa3TS2502xTo4wGNlDAjP9GPLZGD n8GjH/0KCss47pyPrJqkTPUrdVMDA/PS0KWFpc7EU7XwoZW4efYeiptZHPJ5QwpOGCHV sI9Q==
X-Gm-Message-State: AOAM531Qf3YPlNo+VKmKUtWJNMAe7n/5JC3q2bnzgaFPX2aTWYgOZdtv XFHyOVGN1thQ1jOPZVQxFiM=
X-Google-Smtp-Source: ABdhPJwGi0EpPtBkC9Bal3X9iO3nnJuVs51Hmk9ZHZpdsT7mDAU28m8szB9+bdL+A+vNGJon53lqug==
X-Received: by 2002:a17:902:a988:b029:12c:4609:f182 with SMTP id bh8-20020a170902a988b029012c4609f182mr3769425plb.14.1628896077980; Fri, 13 Aug 2021 16:07:57 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id y23sm3630611pfb.130.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Aug 2021 16:07:57 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FC532DA2-FDB9-4B8D-BD61-B8AE53741D6A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Fri, 13 Aug 2021 16:07:54 -0700
In-Reply-To: <>
Cc: The IESG <>,, babel-chairs <>, Babel at IETF <>, Donald Eastlake <>
To: Benjamin Kaduk <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-yang-model-10: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Aug 2021 23:08:03 -0000

Hi Ben,

There was one AI on my plate to get back to you on. See below.

In addition, I had sent my responses to the remaining comments. Let me know if you are good with them.

> On Aug 4, 2021, at 11:34 AM, Mahesh Jethanandani <> wrote:
>>>> There's also a few places where we didn't quite clean up all the fallout
>>>> from switching from enumerations to identities (for MAC and
>>>> DTLS-adjacent algorithms), that really ought to get fixed before
>>>> publication.  I try to note them in the COMMENT.
>>>> I also think we need to be a bit more specific about the structure of
>>>> the (binary) private-key leaf/values provided when a certificate entry
>>>> is created.  Ideally this would just be by reference to some other spec,
>>>> but the situation is unfortunately messy.  (It doesn't help that we
>>>> allow DTLS 1.2, which allows certificates that are used for key-exchange
>>>> as opposed to signing, and those are not terribly mainstream.)  We may
>>>> need to pull in some other experts to figure out the right way to write
>>>> about this.
>>> Ok. The way I am reading this is that we need to wait to hear more from the experts that you cite before making any changes.
>>> Note, in WG discussion the ask was for the format of the private-key to be binary. I am not an expert, but would it help if the description said something about using PEM format for the private-key?
>> I think binary is probably fine; a PEM encoding is just base64 encoding and
>> sometimes a little bit of a hint as to what the contained structure is.
>> But my recollection is that the PEM type indication for certificate private
>> keys is not always precise enough to indicate what is to be used, so an
>> implementation would need to consult the "type" sibling leaf anyway in
>> order to process the "private-key"...but it's not entirely clear that just
>> "type" is enough information on its own.
>> It is possible that we can find the necessary references without pulling in
>> an external expert, but if we get stuck I would probably ask Russ Housley
>> or Sean Turner for help.
>> As a starting point, I note that RFC 4211 lists several Private Key
>> structures in Section 4.2.2 in ASN.1 syntax.  We would presumably require
>> that the binary value exposed by the YANG module be the DER-encoded version
>> of that ASN.1 structure.  RFC 5915 has a private-key structure for ECC
>> keys.  The complications then come in specifying how the other YANG
>> elements determine which (DER-encoded) ASN.1 structure is used for the
>> "private-key" contents.  In particular, "dtls-cert-type" indicates only a
>> "certificate type" in the TLS sense -- X.509, raw public key, and the like.
>> Both X.509 certificates and raw public keys can use keys from different
>> cryptosystems or cryptographic algorithms.  So I find it pretty
>> inescapable that we'll need some in-band signaling about whether the
>> private-key is a basic RSA key, or perhaps an RSA-PSS key that has some
>> specific associated parameters, vs a DH or DSA key, or ECDH, ECDSA, EdDSA,
>> etc.  With in-band signaling comes the need for a table or enumeration of
>> what the different (currently supported) key structures are.  It seems that
>> draft-ietf-netconf-crypto-types may have a start at private-key structures
>> of this sort, though I have not been following that work closely (it seems
>> to be in WGLC at the moment).
> We will need to go back to the WG to discuss this. Let us get back to you on this.

This is what I proposed to the WG to resolve this issue, and did not receive any objection. Let me know if you are ok with it.

We would like to introduce a new leaf called ‘algorithm’ which is a identity reference to one of the ‘private-key-formats’ defined in ietf-crypto-types module, that will identify the type of algorithm used to encode the private key. That module identifies three algorithms, RSA, EC, and One Asymmetric. The change will look something like this:

+          leaf algorithm {
+            nacm:default-deny-write;
+            type identityref {
+              base ct:private-key-format;
+            }
+            mandatory true;
+            description
+              "Identifies the algorithm identity with which the
+               private-key has been encoded. This value can only be
+               provided when this instance is created, and is not
+               subsequently writable.";
+          }

The second, and this was my an oversight on my part, are lines which I have introduced new as part of the model to protect any data that we do not want either read or subsequently written; or read at all. In particular, the private key within a cert is now protected by ‘default-deny-all’, per RFC 8341. Similarly, nodes that were identified as “This value can only be provided when this instance is created, and is not subsequently writeable” in the Babel Information Model, are now protected by the flag ‘default-deny-write’ from RFC 8341. There are four instances of this flag in the model, including the one in the above addition. 


Mahesh Jethanandani