Re: [babel] Babel DTLS and YANG

Donald Eastlake <d3e3e3@gmail.com> Mon, 09 August 2021 04:36 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF4F3A26E4 for <babel@ietfa.amsl.com>; Sun, 8 Aug 2021 21:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.848
X-Spam-Level:
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: 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 EK0jWkip8XQG for <babel@ietfa.amsl.com>; Sun, 8 Aug 2021 21:36:01 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 4A4563A26E5 for <babel@ietf.org>; Sun, 8 Aug 2021 21:36:01 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id l20so23633303iom.4 for <babel@ietf.org>; Sun, 08 Aug 2021 21:36:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ny99i3HApF7ZsJbX2uADLt2B7BceGHGODoRiTCusw6A=; b=c88yg6YMOlMAFTme2snsrjYu0KNZyTodLq/Ma8fcQu+1elpR2+SxvbXeVh0KwZlyK/ P7pyAkRe60E6QrgogEo2oUtlNorTORgW54n2Z9vOZDUTlB3E3E1O7iix7LLSZNTLdHhv FXSHNhtHeAxf18IlWAZKXHeYr+1Dtq4u7VlISh3l/M5EX4stvuviLtSOVwhTHPeOZ5ko x75L3eSIL3tCcrKIhoC4WWoyIvbwWJ7hZgJwwJwtSwb24ClYzFp54DlHV1SYGHO+Z9ul bqexDpc5Xtv11YEf12w3Gh+5zf5KO2D7uYaWmfurBBitme+cARzqi3+Xx8OYNdqROLOO yTkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ny99i3HApF7ZsJbX2uADLt2B7BceGHGODoRiTCusw6A=; b=OdAkI4IwvYgXQMrNXc/3P2Ky8No8HuMwafBz7CD8YlfjypYyzCCnE9up4f9NhO7d+C ls6EqrblXxlewq+TLwCHKyUpWZaVTImz0MtwLutHHj/G2toaHNTBATnal70r7hKktRDu oRwhthcvkI5PO8J33/Br/TBrmpdkTIrYb2hERbvKWMxWtFePAwgegYGwkHqAtMAli4DW 0FPfc9s5trWWdkmao2yvu2BAOz+wGfbgrWrK7hcR8+Q6pzFWMBDrqmOnlImdvITOnzkd xG1akzZBuRSDE9t8j3Qpj340poaEWEKh1rznnXqsOd0hldHTnjVJrTkMaB9bSdT5DmO3 Ur4A==
X-Gm-Message-State: AOAM532x/9cd6RlaLBE9tkyPFgOklZ+Q+EE7C5Ft06vEEsSzHUiEvTfo fy/EMxTbcHRQdqqwuDDfYgCiXJCVRkOM9zjBL4s=
X-Google-Smtp-Source: ABdhPJx6sRlAS18I8cWElyKSLtI7RYe7Yuh2egnTZT/2l1Oiq1Xw3Ktyo6OpesTlmQJ5KMEeLd3XEDik4yYTJ/z4tz0=
X-Received: by 2002:a5e:830b:: with SMTP id x11mr100368iom.185.1628483759628; Sun, 08 Aug 2021 21:35:59 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR02MB69240809030DD2B249100282C3F09@DM6PR02MB6924.namprd02.prod.outlook.com> <828CE2EA-5DED-4E96-B3E3-B4F94D96A4F2@gmail.com>
In-Reply-To: <828CE2EA-5DED-4E96-B3E3-B4F94D96A4F2@gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 9 Aug 2021 00:35:48 -0400
Message-ID: <CAF4+nEFRPmSPbeYhk5t_SHTSMG6PVeigr9JhQLOqFxJ1rzLZHA@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: "babel@ietf.org" <babel@ietf.org>, "STARK, BARBARA H" <bs7652@att.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/yzNBjwGoHJzXF0YpIL30KJAh9N0>
Subject: Re: [babel] Babel DTLS and YANG
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Aug 2021 04:36:06 -0000

Hi Mahesh,

I would agree that a week is a reasonable length of time for people to
complain if they object to these changes.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

On Thu, Aug 5, 2021 at 8:07 PM Mahesh Jethanandani
<mjethanandani@gmail.com> 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 <bs7652@att.com> 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:
> -----BEGIN PRIVATE KEY-----
> BASE64 ENCODED DATA
> -----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
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel