Ballot for conflict-review-bruckert-brainpool-for-tls13
Yes
No Objection
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
I have some comments about the draft (below), though probably not relevant for the conflict review response. With respect to the conflict review response, the authors are doing exactly the right thing w.r.t. IETF processing -- the TLS WG considered this work and decided that the new "specification required" registry policy is designed to let work such as this proceed through the independent stream or other publication channels, and does not need to be gated through the WG. Abstract they had little usage. There are no security concerns in using the ECC Brainpool Curves, and there is some interest in using several of these curves in TLS 1.3. "no security concerns" is unfortunately subjective (in addition to being an unverifiable absolute statement that may not be accurate in the future), and remains a matter of some debate. It is true to say that they were removed from TLS 1.3 due to low usage as opposed to a concrete security concern, but it remains the case that some prominent cryptographic practitioners sow seeds of doubt (without concrete evidence of flaws) as to the worthiness of the brainpool curves. (https://mailarchive.ietf.org/arch/msg/cfrg/yyZ8LiE8m_U243vzEcJVC7JQTmk and thereabouts are perhaps a decent reference.) (It's also surprising to see this only listed in the Abstract but not expounded upon in the Introduction.) Section 3 According to [RFC8446], the name space NamedGroup is used for the negotiation of elliptic curve groups for key exchange during a handshake starting a new TLS session. This document adds new nit(?): I think it's less confusing to talk about "Supported Groups" than "NamedGroup", and it's not entirely accurate to say that it's used for elliptic curve groups, since it is used for other groups as well. enum { brainpoolP256r1tls13(31), brainpoolP384r1tls13(32), brainpoolP512r1tls13(33) } NamedGroup; I note that RFC 8446 uses a different formatting for the values (e.g., 0x001f) and that having one specifciation use hexidecimal and another use decimal notation could cause confusion as to the interpretation of the values. (Yes, the IANA registry is the source of truth, so the risk is fairly minimal, but there is also stylistic motivation for consistency of representation.) Section 4 It might be worth noting that TLS 1.3 differs from previous versions in that the has function used to hash the message for signing is now bound to the SignatureScheme codepoint, whereas in the previous versions it was a separately negotiated parameter. So it's not just a matter of "notation" to "clarify that an ECDSA signature is calculated over the hashed message", it's an actual protocol requirement to nail down the hash function as part of the signature scheme. Section 5 The "Description" column for the SignatureScheme entries is different than the current registry contents; it's not clear to me that the "tls13" in the name is necessary. Section 6 In order to achieve a maximum security level when using one of the elliptic curves from Table 1 for key exchange and / or one of the signature algorithms from Table 2 for authentication in TLS, the key derivation function, the algorithms and key lengths of symmetric encryption and message authentication as well as the algorithm, bit length and hash function used for signature generation should be chosen according to the recommendations of [NIST800-57] and [RFC5639]. [...] This perhaps gives too great an authority to SP800-57 and RFC 5639; if I was writing this it would be something like "should be chosen at commensurate strenghts, for example according to the recommmendations of [...]". Not that I disagree with those recommendations per se, but they're not exactly the only game in town. When using ECDHE key agreement with the curves brainpoolP256r1tls13, brainpoolP384r1tls13 or brainpoolP512r1tls13, the peers MUST validate each other's public value Q by ensuring that the point is a valid point on the elliptic curve. I suggest mentioning the consequences of failing to perform this check (e.g., that an attacker can force the key exchange into a small subgroup and the resulting value essentially loses its unguessability).