Ballot for conflict-review-cooley-cnsa-dtls-tls-profile
Yes
No Objection
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
To the IESG: the only bit here that seems potentially interesting from the conflict-review-response perspective is the apparent downgrade from "MUST" to "SHOULD" of RSASSA-PSS signature support in certificates, in Section 5.2, but per the commentary there I do not think there is a hard conflict. Further notes on the document follow, for the benefit of the authors and ISE. Section 1 I note that draft-ietf-tls-oldversions-deprecate is (slowly) making its way toward publication, if there was desire to note that (D)TLS 1.2 and 1.3 are also the only versions considered acceptable by the IETF. (To be clear, I don't think this document's publication needs to be held until that one is finalized; I'm just noting that this is another area of convergence.) This document does not define any new cipher suites; instead, it defines a CNSA compliant profile of TLS and DTLS, and the cipher suites defined in [RFC5288] and [RFC5289]. This profile uses only algorithms in the CNSA Suite. I think that 528[89] are good references only for TLS 1.2 cipher suites; for TLS 1.3 I guess one would need to cite 8446 itself. Section 2 Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically-relevant It might be worth a couple more words about which transition this refers to (IIUC, from RSA+FFDH to elliptic-curve-based mechanisms). Section 4 Key Establishment (includes key agreement and key transport): [...] RSA [PWKE-B] (with a modulus of 3072 or 4096 bits) It might be worth noting that RSA key transport is available only in TLS 1.2 (but was removed from TLS 1.2). Section 5 I mentioned draft-ietf-tls-oldversions-deprecate previously, though it might be a better fit here. (Or both places!) Section 5.1 [RFC8422] defines a variety of elliptic curves. CNSA (D)TLS connections MUST use secp384r1(24) (also called nistp384) and the uncompressed(0) form MUST be used, as required by [RFC8422] and [RFC8446]. (editorial) I'm not sure if all readers will recognize that the 24 and 0 in parenthese indicate the relevant IANA-assigned codepoints. Section 5.2 For (D)TLS 1.3: For certificate signature, RSASSA-PKCS1-v1.5 [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be supported. This SHOULD is somewhat problematic, since Section 9.1 of RFC 8446 has a MUST-level requirement for rsa_pss_rsae_sha256 (both for CertificateVerify and for certificates), which implies a requirement for supporting RSA-PSS signatures on certificates. That said, the referenced section is prefaced by "in the absence of an application profile standard specifying otherwise", so there may not be a hard conflict here. You probably want to say something about RSASSA-PSS PSS vs. RSASSA-PSS RSAE (that is, which OID is used in the certificate) here, e.g., specifically say RSASSA-PSS RSAE, since the last paragraph of the section seems to require rsaEncryption. For signatures in TLS handshake Messages RSASSA-PSS [DSS] MUST be supported. (ditto re cert OID) Section 6 A CNSA (D)TLS server MUST accept one of the CNSA suites above if they are offered in the ClientHello message. This seems to require the server to implement all four cipher suites, and in particular to always accept the static-RSA key exchange. This would be unlikely to garner IETF consensus, but of course that is not relevant for publication via the ISE. Section 6.2, 6.3, 6.4 The linguistic construction of "MUST offer/accept ecdsa_secp384r1_sha384/rsa_pkcs1_sha384 and SHOULD offer/accept rsa_pss_*_sha384" is a bit weird, since a naive reading would have the "MUST accept" overrule the "SHOULD accept". I'd recommend noting that the RSASSA-PSS variants are preferred when supported (if that is indeed the intent). Section 6.4 When a CNSA (D)TLS server is configured to authenticate the client, the server MUST include a CertificateRequest messagespecified in [RFC8446]: nit: "message specified" ecdsa_secp384r1_sha384 rsa_pkcs1_sha384 The text could be more clear on how this is supposed to relate to the CertificateRequest contents -- it looks like the intent is to be the "supported_signature_algorithms", but that requires some domain knowledge to figure out. I recommend clarifying, presumably the TLS 1.2/supported_signature_algorithms case. Section 7.2 A CNSA (D)TLS client MUST include the "signature_algorithms_cert" extension. [...] This is somewhat surprising, since the required values are basically the same as for "signature_algorithms" (and it's allowed to include rsa_pkcs1_sha384 in "signature_algorithms" to indicate the ability to use it for certificate validation). Note that openssl does not support sending "signature_algorithms_cert" from the client, for example. Section 7.4 A CNSA (D)TLS server MAY send a CNSA (D)TLS client a NewSessionTicket extension to enable resumption. A CNSA (D)TLS client MUST request NewSessionTicket is a message, not an extension. "psk_dhe_ke" via the psk_key_exchange_modes ClientHello extension to resume a session. A CNSA (D)TLS client MUST offer ECDHE with SHA- 384, RSA with SHA-384 and/or DHE with SHA-384 in the "psk_key_exchange_modes" extension. This last sentence seems out of place ("psk_key_exchange_modes" does not contain anything that might be described as "ECDHE with SHA-384, RSA with SHA-384, or DHE with SHA-384"). Section 7.5 Certificate Authorities providing certificates to a CNSA (D)TLS server or client MUST provide certificate revocation status information via a Certificate Revocation List (CRL) distribution point or using the Online Certificate Status Protocol (OCSP). A CNSA client SHOULD request according to [RFC8446] Section 4.4.2.1. If nit: this seems like an incomplete sentence? (It also appears in Section 6.7.)