IETF conflict review for draft-bruckert-brainpool-for-tls13
conflict-review-bruckert-brainpool-for-tls13-00

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).