Re: [babel] Babel DTLS and YANG

Donald Eastlake <> Fri, 13 August 2021 18:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21D783A2186 for <>; Fri, 13 Aug 2021 11:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.848
X-Spam-Status: No, score=-0.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dzwoiWLBD0q5 for <>; Fri, 13 Aug 2021 11:20:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED4513A2187 for <>; Fri, 13 Aug 2021 11:20:54 -0700 (PDT)
Received: by with SMTP id y1so14457214iod.10 for <>; Fri, 13 Aug 2021 11:20:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PXlm3BCbAVhly/Hqo3Dzov0ahyM+03T2Ep1rCrr+2WI=; b=AHs9Pap2ZddaBkJnrQh5dOP3C/qNcVclHn6HqP/1xO/wEmwkUEB9XtnYUou/rkuanH WO2vnaZSEVsVzx34PH/V7FN9LXQZD54OxzXzhFws1T3AMQ54+zbAjEf2VBFn+PczUtmS 5rDKeduBk3zQGju7jChAhDDyTvWV+Lm/LE1AuhINmTvgx5RJo3MmNPLPtW4fdHdbLFPm cT763HzMD3KR5KHYS3/sZ5+gQsJpkORMPru0DTxeDsoug4ycFJlM066FZigdgivqgK9J vMybyEFGE/Ku81OawrxFJTlsg16DPW4p2u5NLDQcgxOmenAEILDgY/7tubHyzUtV5ro0 +q1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PXlm3BCbAVhly/Hqo3Dzov0ahyM+03T2Ep1rCrr+2WI=; b=WrBn/ypqKTis9rYXwXcCSpMPgMh9IMySfPqxoTmJ/Wzfw+q5yQvfOf/cQdEMGFuNBO BHx6Ncf1pGySwq6N8xkM+yGNTu38S5LC6LDgC82ftph56t2MqdTT74cHQxSxKMYB0o9s +5FyBF/+1JooKBxZb2GuNK5HQISvGkmv53NeFozDJLht3x4ggtAIAeIpOintSeF8bQe9 BtZ5vGfWrkfVFQmiOssRwoiUj89dbx3MDI7SDdPrQBsNSGx4WbN5qICXRhKlFjJeq/zO WCeiqGTzzdvAnkwZ5iB/fGZUtKy7IYWy1YDW4i3Epf2kSK4X0flMX4atEBMm8AVMRxzA /4DA==
X-Gm-Message-State: AOAM530OZ0PZzVlIKZLrdHSxUVCxQhrdMv9U0uFWuMTZyczILvSynvfG M0jmBoFu9KCMVevzW8XLvvGFtai7WzOh12VpYUw=
X-Google-Smtp-Source: ABdhPJwV4bHTe7c1IWYP7dJ6IYrin2AnK7mxrMvE/JlttAial6eKbtYFhS1QM9dtJYdUhs1jEIaMI8q77JinR51gQlw=
X-Received: by 2002:a5d:8986:: with SMTP id m6mr2910167iol.87.1628878853338; Fri, 13 Aug 2021 11:20:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Donald Eastlake <>
Date: Fri, 13 Aug 2021 14:20:42 -0400
Message-ID: <>
To: Mahesh Jethanandani <>
Cc: "" <>, "STARK, BARBARA H" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [babel] Babel DTLS and YANG
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 18:21:00 -0000

Hi Mahesh,

Since no one has objected, you can go ahead with the changes.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA

On Thu, Aug 5, 2021 at 8:07 PM Mahesh Jethanandani
<> wrote:
> Hi Babel WG,
> We, the authors, have not heard from the WG on this thread, so here are a list of suggested changes we are proposing to address the comments received as part of IESG review. Since the changes are substantial, we need to make sure that the WG is ok with these changes.
> The first is address the question Barbara raises below. 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 is where the bad news comes in, is that the ietf-crypto-types module is part of draft-ietf-netconf-crypto-types. Yes, it is a draft, though in LC, so most likely this draft will end up in MISSREF queue.
> The third, 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 are now protected by something called ‘default-deny-all’, which per RFC 8341 defines it as:
>          "Used to indicate that the data model node
>           controls a very sensitive security system parameter.
>           If present, the NETCONF server will only allow the designated
>           'recovery session' to have read, write, or execute access to
>           the node.  An explicit access control rule is required for all
>           other users.
> 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, which describes the flag as:
>          "Used to indicate that the data model node
>           represents a sensitive security system parameter.
>           If present, the NETCONF server will only allow the designated
>           'recovery session' to have write access to the node.  An
>           explicit access control rule is required for all other users.
> If you have objections to these changes, please raise it now. Otherwise, silence will be considered consensus 🤐. Donald, would you say a week is plenty of time to raise any objection?
> Cheers.
> On Aug 3, 2021, at 8:11 AM, STARK, BARBARA H <> wrote:
> Hi Babelers,
> We're getting some comments on the YANG model that we need a little help with.
> Specifically, we need help with the modeling of the DTLS private key.
> For DTLS, we've included data model support for X.509 certificates and Raw Public Key.
> The certificate type (X.509 or Raw Public Key) is specified for every certificate.
> Both have distinct public and private keys.
> Public keys are provided via the data model in PEM format.
> The public key PEM file includes info about the cipher suite that was used to create the pair (RSA, Elliptic Curve, etc.) and therefore needs to be negotiated in DTLS handshaking.
> But for the private key, we had come to a consensus that the Babel implementation just wanted the binary private key value.
> If the private key were expressed in PKCS#8 (generic key format) PEM, we would have:
> -----END PRIVATE KEY-----
> Within the base64 encoded data the following DER structure is present:
> -------------------------------------
> PrivateKeyInfo ::= SEQUENCE {
>  version         Version,
>  algorithm       AlgorithmIdentifier,
>  PrivateKey      OCTET STRING
> }
> AlgorithmIdentifier ::= SEQUENCE {
>  algorithm       OBJECT IDENTIFIER,
>  parameters      ANY DEFINED BY algorithm OPTIONAL
> }
> ---------------------------------------
> AlgorthmIdentifier identifies the cipher suite.
> But it sounds like the binary private key value Babel is providing is just the "PrivateKey" part of this.
> Is that correct? If so, doesn't the implementation need to know the "AlgorithmIdentifier"? Or (since we supply the public key with the private key) can or does the Babel implementation pick this up from the associated public key?
> Thx,
> Barbara
> _______________________________________________
> babel mailing list
> Mahesh Jethanandani
> _______________________________________________
> babel mailing list