[Anima] Re: Iotdir last call review of draft-ietf-anima-brski-cloud-11

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 02 January 2025 18:52 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A589C14F6A2; Thu, 2 Jan 2025 10:52:48 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 C_SbI4KEQ46J; Thu, 2 Jan 2025 10:52:44 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5334C14F696; Thu, 2 Jan 2025 10:52:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 261111800F; Thu, 2 Jan 2025 13:52:40 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavis, port 10024) with LMTP id guHEdEGPU48a; Thu, 2 Jan 2025 13:52:37 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1735843957; bh=0LU1E1YDOm3Us9cpKLaRcHAhJam8Hq1Tf3mY2JKPyHY=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=RwvmgZ8a4vg8j0yLJWVBYh0iL9xLRZn9yPmGG3E4yJ0P5hvIA3E2m299JKa4vadAU hXPZ1zQKUle4EmJVztmE0CZLax7GNOha3bdZPq01dCE0dgar9VJVwBCquwx2ky68yU HrSIvJ4LsXyC3QpXGROEuZQU7cqk+E8BC85wml7OhJVO4wph6wC0bKh5Xbzo0Bf78M tk3SZN9NVh/f4dzV8LbsniXKfrCs+RzMUItxuhI27C/C4F92HzXtXZnmPdlpzEqsry gF54/xS+3wrG16WTsZ2AcJn/YaUun32tPSeHGBi4OSXWEDBWMm3HIwxc+6poiVIlt/ OcfCwCesNU2ow==
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 57C321800C; Thu, 2 Jan 2025 13:52:37 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 53969467; Thu, 2 Jan 2025 13:52:37 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Qin Wu <bill.wu@huawei.com>
In-Reply-To: <173563010037.1087536.12522372087477841558@dt-datatracker-65f549669d-2xld9>
References: <173563010037.1087536.12522372087477841558@dt-datatracker-65f549669d-2xld9>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 02 Jan 2025 13:52:37 -0500
Message-ID: <28705.1735843957@obiwan.sandelman.ca>
Message-ID-Hash: JP4FVCC46MEPVTAC74ALOL2L37YUZ5GO
X-Message-ID-Hash: JP4FVCC46MEPVTAC74ALOL2L37YUZ5GO
X-MailFrom: mcr+ietf@sandelman.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-anima.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: iot-directorate@ietf.org, anima@ietf.org, draft-ietf-anima-brski-cloud.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Anima] Re: Iotdir last call review of draft-ietf-anima-brski-cloud-11
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/HZosjf44MdPirXgJM0du5G7dEx0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Owner: <mailto:anima-owner@ietf.org>
List-Post: <mailto:anima@ietf.org>
List-Subscribe: <mailto:anima-join@ietf.org>
List-Unsubscribe: <mailto:anima-leave@ietf.org>

Qin Wu via Datatracker <noreply@ietf.org> wrote:
    > infrastructure. I believe this document is well written. Here is a few
    > comments and suggestions I would like authors of this draft to
    > consider:

Your comments have been collected into this pull request:

https://github.com/anima-wg/brski-cloud/pull/177

    > 1. Section 1 said: “This document further specifies use of a BRSKI
    > Cloud Registrar and clarifies operations that are not sufficiently
    > specified in BRSKI.” [Qin]: Do we need to update BRSKI for these
    > clarification on operations which haven’t been specified in BRSKI. “

Added updates:
https://github.com/anima-wg/brski-cloud/pull/177/commits/e312384e44cf25d78fed023878b64f3bcac889eb

    > 2. Section 1.2 s/specifies and standardizes/specifies
    > s/Resller/Reseller

https://github.com/anima-wg/brski-cloud/pull/177/commits/55583ee237f3b5c237b76d8552e6eb55a8bbfae7

    > 3. Section 1.2 said: “A typical example is an employee who is deploying
    > a Pledge in a home or small branch office, where the Pledge belongs to
    > the employer. There is no local domain Registrar, the Pledge needs to
    > discover and bootstrap with the employer's Registrar which is deployed
    > within the employer's network, and the Pledge needs the keying material
    > to trust the Registrar. For example, an employee is deploying an IP
    > phone in a home office and the phone needs to register to an IP PBX
    > deployed in their employer's office.”

    > Suggest to remove the last sentence, since it looks duplicated to have
    > two examples in the same paragraph.

I have rewritten as:
https://github.com/anima-wg/brski-cloud/pull/177/commits/d694527499b3310ad0bdda1e1f0774c40346b244

-A typical example is an employee who is deploying a Pledge in a home or small branch office, where the Pledge belongs to the employer.
+This mechanism is useful to help an employee who is deploying a Pledge in a home or small branch office, where the Pledge belongs to the employer.
 As there is no local domain Registrar in the employee's local network, the Pledge needs to discover and bootstrap with the employer's Registrar which is deployed within the employer's network, and the Pledge needs the keying material to trust the Registrar.

-For example, an employee is deploying an IP phone in a home office and the phone needs to register to an IP PBX deployed in their employer's office.
+As a very specific example, an employee is deploying an IP phone in a home office and the phone needs to register to an IP PBX deployed in their employer's office.

I did not remove the example, because I think it's important to emphasis the point.

    > 4. Section 2 said: “ For use case one, as described in Section 1.2.1,
    > the Cloud Registrar redirects the Pledge to an Owner Registrar in order
    > to complete bootstrap with the Owner Registrar. When bootstrapping
    > against an Owner Registrar, the Owner Registrar will interact with a CA
    > to assist in issuing certificates to the Pledge. This is illustrated in
    > Figure 1. For use case two, as described Section 1.2.2, the Cloud
    > Registrar issues a voucher itself without redirecting the Pledge to an
    > Owner Registrar, the Cloud Registrar will inform the Pledge what domain
    > to use for accessing EST services in the voucher response. In this
    > model, the Pledge interacts directly with the EST service to
    > enroll. The EST service will interact with a CA to assist in issuing a
    > certificate to the Pledge. This is illustrated in Figure 2.

    > ” Use case one doesn’t describe how MASA works together with Pledge,
    > Owner Registrar and CA described in figure 1, suggest to remove MASA
    > from the figure 1.

    > Use case two doesn’t describe how MASA works together with Pledge,
    > Owner Registrar, Cloud Registrar and CA described in figure 2, suggest
    > to remove MASA from the figure 2.

I've amended the figure to include BRSKI-MASA as the protocol.
It's unchanged from RFC8995.
Removing it from the diagram would be more confusing.
https://github.com/anima-wg/brski-cloud/pull/177/commits/1f47e48dc65910d7865727d37fa4ae256ecb7716

    > 5. Section 2 also said: “ As depicted in Figure 1 and Figure 2, there
    > are a number of parties involve in the process. The Manufacturer, or
    > Original Equipment Manufacturer (OEM) builds the device, but also is
    > expected to run the MASA, or arrange for it to exist. ” What role does
    > MASA play, who is expected to run the MASA? It is not clear this should
    > be described in the scope

It's the same as RFC8995.

    > 6. Section 2.1 Can you provide a reference to WPS?

Yes, maybe.
https://github.com/anima-wg/brski-cloud/pull/177/commits/378eec962adb2cfaa4613aa3d0b65a90cc155b7e
references: https://www.wi-fi.org/discover-wi-fi/wi-fi-protected-setup now.
which has a marketing click-through, which many BigTech employees are
forbidden from clicking through.    So I don't know how to cite WPS.

    > 7. Section 3.1.2 said: “ Unlike the Provisional TLS procedures
    > documented in BRSKI section 5.1, the Pledge MUST NOT establish a
    > Provisional TLS connection with the Cloud Registrar. “ Please provide
    > referenced RFC to BRSKI ?

https://github.com/anima-wg/brski-cloud/pull/177/commits/7bba63442bc78c6a97101a53495013a5f33971d1
now cites RFC8995 section 5.1 with a link.

    > 8. Section 3.1.2 also said: “ unless it is known that Cloud or Owner
    > Registrars for this Pledge implementation will never need to be
    > deployed in a cloud setting requiring the "server_name" extension “
    > What happened if Cloud Owner Registrars doesn’t support server name
    > extension, e.g., using TLS 1.3 and can not obtain the server name?

https://github.com/anima-wg/brski-cloud/pull/177/commits/2a51c3f3c33392fc3e8e6129a30d37ab53daa853
reworked some of the SNI text.
Sending SNI is pretty much mandatory in TLS 1.3, but we are allowed to modify that.
On the Registrar side, the SNI info should be ignored.

I thought that draft-richardson-anima-registrar-considerations had more text
about SNI that didn't get into RFC8995... I thought there was an errata.
Yes, 6648.  But not marked verified.
maybe it's time to adopt registrar-considerations.

I don't know what to do here.

    > 8. Section 3.1.2 said: “ To protect itself against DoS attacks, the
    > Cloud Registrar SHOULD reject TLS connections when it can determine
    > during TLS authentication that it cannot support the Pledge, for
    > example because the Pledge cannot provide an IDevID signed by a CA
    > recognized/supported by the Cloud Registrar.¶

    > ” Looks like this paragraph belongs to security consideration section.

Well, I disagree.
SHOULD/MUST do not belong in Security Considerations, but can be referenced.
I'm not sure this belongs in SC, but I am willing to add a new section.

    > 9. Section 3.2, paragraph 1: s/ In the case of an unknown Pledge a 404
    > is returned, for a malformed request 400 is returned, or in case of
    > server overload 503 is returned./ In the case of an unknown Pledge, a
    > 404 is returned, for a malformed request, 400 is returned, or in case
    > of server overload, 503 is returned.

also in:
https://github.com/anima-wg/brski-cloud/pull/177/commits/2a51c3f3c33392fc3e8e6129a30d37ab53daa853

    > 10. Section 3.2.3 said: “ The voucher MAY include the new
    > "additional-configuration" field. This field points the Pledge to a URI
    > where Pledge specific additional configuration information may be
    > retrieved. “ How does this align with SZTP work in [RFC8572]? It is
    > nice to reference RFC8572 if it aligns.

SZTP specifies a way to use https or SSH to reach out to the cloud, and then
there might be a inversion of the connection, and configuration information
will be downloaded.  I don't think this work aligns with that work at all.

    > 10. Section 3.3.1 said: “ then the Pledge MAY accept a subsequent 307
    > response from this Cloud VAR Registrar.¶ ” How many subsequent 307
    > response does the Pledge allow? Is there any security risk that needs
    > to be considered?

There is a section 7.2 that deals with this.
I've added a clearer forward reference:

https://github.com/anima-wg/brski-cloud/pull/177/commits/eaa7c87e73216e5091dfd1cb6019bcc15ca2dc4a

    > 11. Section 4.2 s/ both [RFC1918] and/ both ipv4 [RFC1918] and
    > s/provided by with/provided with

    > 12. Section 5 s/dependant upon/dependent upon

typos fixed:
https://github.com/anima-wg/brski-cloud/pull/177/commits/b88dff990b3dea58cf6d8510ed9db6b3b19af70e

    > 13. Section 9 said: “ The Pledge is unable to determine whether it has
    > been redirected to another Cloud Registrar that is operated by a VAR,
    > or if it has been redirected to an Owner Registrar, and does not
    > differentiate between the two scenarios. “ Is there any security risk
    > that needs to be considered?

I don't think so.
But, I've rewritten slightly:
https://github.com/anima-wg/brski-cloud/pull/177/commits/39e2096297f9f68c26bc4dfac6b6fa77e3b14ee8

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [