[Taps] Roman Danyliw's Abstain on draft-ietf-taps-interface-24: (with COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Fri, 26 January 2024 23:20 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: taps@ietf.org
Delivered-To: taps@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DD1C14F682; Fri, 26 Jan 2024 15:20:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org, anna.brunstrom@kau.se, anna.brunstrom@kau.se
X-Test-IDTracker: no
X-IETF-IDTracker: 12.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <170631120798.45778.14937431537954681141@ietfa.amsl.com>
Date: Fri, 26 Jan 2024 15:20:07 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/kP1NPAqJtmjxLtw7ElFSj512woY>
Subject: [Taps] Roman Danyliw's Abstain on draft-ietf-taps-interface-24: (with COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2024 23:20:08 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-taps-interface-24: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Sean Turner for the SECDIR review. Thank you for the iteration on my DISCUSS position and the efforts to refine the document in response. I want to acknowledge the significant effort required to produce https://github.com/ietf-tapswg/api-drafts/pull/1463. My recommendation would be to merge it as it improves -24. I am abstaining on this document because there is a degree of specificity in the abstract API in this document that I cannot reconcile with proposed standard status. I would expect to be able to do some basic, repeatable degree of conformance evaluation to understand if a concrete API meets what is described in this abstract API – put more simply, how would I know I have an “API to Transport Services”. Focusing just on the security aspects of the API, I struggled to envision how to do that. To summarize my DISCUSS feedback, it isn’t clear which classes of security parameters require concrete implementation from the abstract API. The subsequent PR improved the editorial presentation (much appreciated!), but the following text created further ambiguity: The set of security parameters defined here is not exhaustive, but illustrative. Implementations SHOULD expose an equivalent to the parameters listed below to allow for sufficient configuration of security parameters, but the details are expected to vary based on platform and implementation constraints. If this text and parameters are “illustrative”, they are examples. What conformance is required for the concrete security API if only examples are provided? How does one unambiguously agree on equivalence relative to examples? If “implementations SHOULD expose”, that means that they can choose not to and still be conformant which degenerates into very little normative guidance around the security aspects of the API. ==[ DISCUSS feedback on -24 ]== Thanks for the revised text in v-22, -23 and -24. I’m still do not understanding what exact Security Parameters that Section 6.3.1 is normatively specifying (and which of them are examples). My confusion is that Section 6.2 has a crisp list of parameters with an explicit names, type, and default value. The equivalent is not present for the security related parameters. Section 6.3 says “except as noted below, as with the rest of the Transport Services API, exact names of parameters and/or values of enumerations (e.g., ciphersuites) used in the security parameters are system and implementation specific, and ought to be chosen to follow the principle of least surprise for users of the platform / language environment in question.” How does one read “except when noted below”? Is this section saying the normative parameters are server-certificate, client-certificate, pinned-server-certificate, alpn, supported-group, ciphersuite, signature-algorithm, max-cached-sessions, cached-session-lifetime-seconds, pre-shared-key OR that “an API should define certificate bundles, certificate chains for pinned certificates, ALPN, session cache management parameters, supported groups/ciphersuite/ parameters, and PSK parameters but no further details are provided here beyond naming these categories of parameters”? I observe that the guidance in Section 4.1 suggests that parameter names are in CamelCase. That isn’t used here (e.g., “server-certificate” should be “ServerCertificate”). This might hint that there are not parameters here. However, the bulleted list in Section 6.3.1. is prefaced with “Security configuration parameters and sample usage follow:” seems to suggest that these are concrete parameters. ==[ DISCUSS ]==
- [Taps] Roman Danyliw's Abstain on draft-ietf-taps… Roman Danyliw via Datatracker