From 57eb4ddaaf49c0b2fe6e82027be3e3da8238cbd1 Mon Sep 17 00:00:00 2001 From: Tommy Pauly Date: Mon, 15 Jan 2024 07:27:07 -0800 Subject: [PATCH] Apply suggestions from code review Co-authored-by: mwelzl --- draft-ietf-taps-interface.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-taps-interface.md b/draft-ietf-taps-interface.md index a2ac8cf0..bd0ce5a3 100644 --- a/draft-ietf-taps-interface.md +++ b/draft-ietf-taps-interface.md @@ -1564,10 +1564,10 @@ for security parameters to be unambiguous. The Transport Services System SHOULD secure defaults for each enumerated security parameter, such that users of the system only need to specify parameters required to establish a secure connection (e.g., `serverCertificate`, `clientCertificate`). Specifying security parameters -from enumerated values (e.g., specific ciphersuites) might constrain the Transport -Protocols that can be selected during connection establishment. +from enumerated values (e.g., specific ciphersuites) might constrain which transport +protocols can be selected during Connection establishment. -Security configuration parameters are specified in the pre-connection phase +Security configuration parameters are specified in the pre-establishment phase and are created as follows: ~~~ @@ -1587,12 +1587,12 @@ they support. For security parameters that are not simple value types, such as certificates and keys, implementations are responsible for exposing types appropriate for the platform / language environment. -Applications SHOULD use common safe defaults for values such as TLS ciphersuite +Applications SHOULD use common safe defaults for values such as TLS ciphersuites whenever possible. However, as discussed in {{?RFC8922}}, many transport security protocols require specific security parameters and constraints from the client at the time of configuration and actively during a handshake. -The set of security parameters defined here are not exhaustive, but illustrative. +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.