[Taps] Roman Danyliw's Discuss on draft-ietf-taps-interface-24: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Mon, 08 January 2024 20:32 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 16CD4C14F60A; Mon, 8 Jan 2024 12:32:11 -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.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <170474593108.56200.14211704546607049395@ietfa.amsl.com>
Date: Mon, 08 Jan 2024 12:32:11 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/dTAd0-7ZpPkWsTVG8ztS9JAc-gc>
Subject: [Taps] Roman Danyliw's Discuss on draft-ietf-taps-interface-24: (with DISCUSS and 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: Mon, 08 Jan 2024 20:32:11 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-taps-interface-24: Discuss

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:


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.


Thank you to Sean Turner for the SECDIR review.