Re: [netconf] AD review of draft-ietf-netconf-over-tls13-02

Sean Turner <sean@sn3rd.com> Wed, 18 October 2023 02:25 UTC

Return-Path: <sean@sn3rd.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 73889C1519BF for <netconf@ietfa.amsl.com>; Tue, 17 Oct 2023 19:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiRsz1oj12O1 for <netconf@ietfa.amsl.com>; Tue, 17 Oct 2023 19:25:45 -0700 (PDT)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 93AC0C1519BD for <netconf@ietf.org>; Tue, 17 Oct 2023 19:25:40 -0700 (PDT)
Received: by mail-qv1-xf2a.google.com with SMTP id 6a1803df08f44-66d36b2a247so25317326d6.1 for <netconf@ietf.org>; Tue, 17 Oct 2023 19:25:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; t=1697595939; x=1698200739; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Zw6fWQIwyFfHYS/vLzRIkN9Sn6ZE/GgmTdqFKnZU2Qk=; b=S9y066G7MzYUHO0INVmxuiesS7xOnl+ZbW1WfiLTF8po79bhfEcWYBn1S9D5L2ns7I jEls7jwY0Bh+VFfq3GOyYzbut7+VI5kuAIiZdQUiK+1CMZzerLdLjhk2AADihMLOhSH8 bheRUYOW0Ka4dmoQi0UxTRtJIKNtL4UCThj68=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697595939; x=1698200739; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Zw6fWQIwyFfHYS/vLzRIkN9Sn6ZE/GgmTdqFKnZU2Qk=; b=njalUXulqm0yLl4LI5leQZhgA3H5DVuMpYdbRzKjXwQyYvd+k9Otf1CDG8UCbK+6KT HKfNhWBRszA036oGqP7RGeg1Hd4Av9vgrlVusSgeaP+VcurDiINGd4hOgsB5aAp2cuyZ MOhDkJ4Oagzx+n1tnPHBNa18s89HDyP7AQb/l5+BPW6ZBfIeUua8GdeiE4Kaz2wi7+AJ OCl8ojIxBVERtBD5keuO+LDm+qErj/j9qZ3Y7q4jam6/vhTZocpv8PIfxs39uKXdev2O JAQL2Wbyhse+xeLMesOEC5KlR1yllqY9R27ISkp6pAKKqx1Mn3HooeEEg5NtcfB9yO53 Pwiw==
X-Gm-Message-State: AOJu0YzCN34pD2rHDLEBfGHMQdLGbB/SY9iONcW8qLy0tbAa/mxH9woB x01Ey9k1DsnI27fL9AkceALWqA==
X-Google-Smtp-Source: AGHT+IHYvLhhgW6Iw99KrUjrRV7vgSQnT40GdWVLiWQL+5ccan0DxBFVeW7xeWbaPs5TpsRtUah/HA==
X-Received: by 2002:a05:6214:408:b0:66d:1edd:1d4c with SMTP id z8-20020a056214040800b0066d1edd1d4cmr5395278qvx.14.1697595939232; Tue, 17 Oct 2023 19:25:39 -0700 (PDT)
Received: from smtpclient.apple ([2600:4040:253b:7300:b19c:e498:fa58:474e]) by smtp.gmail.com with ESMTPSA id h5-20020a05620a400500b0077413b342e9sm1122161qko.128.2023.10.17.19.25.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2023 19:25:38 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <BY5PR11MB41962FEFE7C44751A69EEC59B5D2A@BY5PR11MB4196.namprd11.prod.outlook.com>
Date: Tue, 17 Oct 2023 22:25:38 -0400
Cc: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-over-tls13.all@ietf.org" <draft-ietf-netconf-over-tls13.all@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <28CEF1D2-A881-46D1-A95C-991EA42817F9@sn3rd.com>
References: <BY5PR11MB41962FEFE7C44751A69EEC59B5D2A@BY5PR11MB4196.namprd11.prod.outlook.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
X-Mailer: Apple Mail (2.3654.120.0.1.15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/sKQkUYyAEDGC1I9yZmfSBN4vBAQ>
Subject: Re: [netconf] AD review of draft-ietf-netconf-over-tls13-02
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 18 Oct 2023 02:25:49 -0000

> On Oct 13, 2023, at 06:40, Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
> 
> Hi,
> 
> Thanks for this document.  Here is my AD review of draft-ietf-netconf-over-tls13.  I found this document pretty easy to read, and after all, it is quite short but have a few questions/comments:

Excellent!

> Moderate level comments:
> 
> (1) p 3, sec 5.  Security Considerations
> 
>   For implementations that support TLS 1.3, the Security Considerations
>   of TLS 1.3 [I-D.ietf-tls-rfc8446bis] apply.
> 
> Note, this will create a normative dependency on ietf-tls-rfc8446bis, potentially delaying the doc.  If this was a concern then it would seem that referencing RFC 8446 would be equally valid?

It will, but I think we’re okay with waiting. -rfc8446bis and -rfc8447bis should be coming along shortly; I’m shepherding one and authoring the other ;)

> (2) p 3, sec 5.  Security Considerations
> 
>      NETCONF is used to access configuration and state information and
>      to modify configuration information.  TLS 1.3 mutual
>      authentication is used to ensure that only authorized users and
>      systems are able to view the NETCONF server's configuration and
>      state or to modify the NETCONF server's configuration.  To this
>      end, neither the client nor the server should establish a NETCONF
>      over TLS 1.3 connection with an unknown, unexpected, or
>      incorrectly identified peer; see Section 7 of [RFC7589].  If
>      deployments make use of a trusted list of Certification Authority
>      (CA) certificates [RFC5280], then the listed CAs should only issue
>      certificates to parties that are authorized to access the NETCONF
>      servers.  Doing otherwise will allow certificates that were issued
>      for other purposes to be inappropriately accepted by a NETCONF
>      server.
> 
> It is unclear which paragraph in RFC 7589 is being modified, and it is unclear to me whether the intent it to append a new paragraph or replace an existing one.  It looks like this is updating the first paragraph of the security considerations (sec 9).  But it could be interpreted that you are replacing a paragraph that would also apply to TLS 1.2 to only apply to TLS 1.3.  Would it be better to add a new paragraph that only covers TLS 1.3.  I.e., the text that you have above minus the first sentence?

It’s about adding new text for TLS 1.3. How about:

OLD:

The following considerations from [RFC7589] has been modified to also
   apply to TLS 1.3 [I-D.ietf-tls-rfc8446bis]:

      NETCONF is used to access configuration and state information and
      to modify configuration information. TLS 1.3 mutual ...

NEW:

As specified in [RFC7589], NETCONF over TLS requires mutual authentication.
For implementations that support TLS 1.3:

   TLS 1.3 mutual …

See the following PR:
https://github.com/netconf-wg/netconf-over-tls13/pull/15

> Minor level comments:
> 
> (3) p 1, sec 1.  Introduction
> 
>   This document updates [RFC7589] to address support
>   requirements for TLS 1.2 [RFC5246] and TLS 1.3
>   [I-D.ietf-tls-rfc8446bis] and the use of TLS 1.3's early data, which
>   is also known as 0-RTT data.
> 
> Did you mean "address support".  Perhaps "to update support requirements for TLS 1.2 ..."?  If you agree to change, then it would be worth making a similar change in the abstract.

I did mean address as in to speak to in a formal way, but maybe that’s not the best way to phrase it.  It does update the 1.2 requirements, but it add 1.3 requirements.  Maybe something like:

This document updates RFC 7589 to update support requirements for TLS 1.2
and add TLS 1.3 support requirements, including restrictions on the
use of TLS 1.3's early data.

See the following PR:
https://github.com/netconf-wg/netconf-over-tls13/pull/15

> (4) p 3, sec 4.  Cipher Suites
> 
>   NETCONF implementations SHOULD follow the recommendations given in
>   [RFC9325].
> 
> I'm not sure that this is actionable, but I was wondering how many of the recommendations in RFC 9325 are relevant for NETCONF and haven't already been stated above.  I.e., I presume it doesn't make sense to cherry pick, or highlight the specific recommendations for RFC 9325 that are relevant?  I also note that this comment is within the Cipher Suites section but it wasn't clear whether the intention was to follow the recommendations more broadly?

RFC 9325 is a BCP about applications implementing TLS so I think it applies more broadly as NETCONF could be thought of as the application. How about we move that bit to the Security Considerations section?

See the following PR:
https://github.com/netconf-wg/netconf-over-tls13/pull/15

> Regards,
> Rob


Cheers,
spt