Ballot for draft-ietf-tls-tls13-pkcs1
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Hi David and Andrei, Thank you for the effort put into this specification. Please find some points for DISCUSSion: # PS for a non-recommended scheme? CURRENT: The "Recommended" column should be set to "N" I understand this is addressing a specific deployment case. I also understand that some interoperability is needed here to follow the guidance in the document. Still, this is about non-recommended scheme. Any reason why are we publishing this as PS? # draft-ietf-tls-rfc8447bis says the following: N: Indicates that the item has not been evaluated by the IETF and that the IETF has made no statement about the suitability of the associated mechanism. This does not necessarily mean that the mechanism is flawed, only that no consensus exists. The IETF might have consensus to leave an items marked as "N" on the basis of its having limited applicability or usage constraints. D: Indicates that the item is discouraged. This marking could be used to identify mechanisms that might result in problems if they are used, such as a weak cryptographic algorithm or a mechanism that might cause interoperability problems in deployment. When marking a registry entry as “D”, either the References or the Comments Column MUST include sufficient information to determine why the marking has been applied. Implementers and users SHOULD consult the linked references associated with the item to determine the conditions under which the item SHOULD NOT or MUST NOT be used. Given there was a design choice to remove support in 8446/8446 bis and reading of the above definitions, it seems that we are more on the D side than the N side. # Clear applicability Scope I think that a clear/dedicated section to LOUDLY describe the applicability scope is needed here. # Update RFC8446/RFC8446bis The provisions in this draft relax what used to be disallowed in 8446/8446bis. This reads like an update.
# FIPS 186-4 ## Please add a reference ## s/with FIPS 186-4/with US FIPS 186-4 # Default CURRENT: TLS implementations SHOULD disable these code points by default. See Section 4. ## Wouldn’t MUST be appropriate here? ## Which part of Section 4 is relevant to this point? I failed to see the logic for that reference. # TLS Registries CURRENT: IANA is requested to create the following entries in the TLS SignatureScheme registry, defined in [RFC8446]. Isn’t draft-ietf-tls-rfc8447bis authoritative here for registry matters? I would replace the 8446 citation with draft-ietf-tls-rfc8447bis. Cheers, Med
Thanks to Rifaat Shekh-Yusef for their secdir review. This specification needs to be PS so that TLS server implementations will modify their TLS offerings where client authentication is necessary. The same situation is true for 'N' vs 'D'. This specification allow clients using hardware storage devices (TPMs, Secure Elements, etc.) to migrate to TLS 1.3. I support those positions.
I've previously reviewed this document, and the changes are minor. It looks like a solid solution for these devices. I believe "N" is an appropriate value since that indicates the value "either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases" -- this document clearly describes why, despite having IETF consensus, it falls into the latter two buckets. However, it does seem clear that this document modifies restrictions in RFC8446(bis). While it defines new codepoints with differing behavior for the SignatureScheme enum and thus isn't changing the definition of those codepoints, it is modifying the requirement in CertificateVerify handling that `RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 algorithms appear in "signature_algorithms".`