On Thu, Feb 11, 2021 at 12:40:51AM -0200, Viktor Dukhovni wrote: > > There is merit in keeping the combinatorial complexity of TLS 1.3 > as small as possible, reducing implementation attack surface, ... > > The key question, that is difficult to answer is whether the right > balance is adequately accomplished with "N" in the recommended column, > with most implementations then either not supporting said ciphersuites > at all, or disabling them by default. If so, perhaps some specialised > implementations could use them appropriately. On the other hand the > "specialised" applications might get used outside their originally > intended use-cases, in ways the designers never anticipated. > > Do we leave the choice to use TLS wisely to the developers and users, > or we judge that misuse is inevitable, and the use-case not sufficiently > compelling? I am somewhat inclined to do the latter. Despite the fact > that'd I'd otherwise be inclined to argue for anonDH ciphers, which have > reasonable applications in unauthenticated opportunistic TLS, where any > presented certificates are just ignored bloat that increase the attack > surface. I would have liked to see support for these retained in TLS 1.3, > but accept their omission as a legitimate tradeoff. If NULL ciphers are > added (which IMHO are the greater risk), then perhaps I'd have a good > case to make to have anonDH/anonECDH ciphers re-introduced...
The WG has delegated this decision to the Designated Experts that serve for the relevant IANA registry. In point of fact, the experts have already approved ciphersuite codepoints for these ciphers (a couple years ago, IIRC), so in some sense the decisions (or "a decision"?) has already been made. The WG could, of course, decide to provide additional input to the Experts in the form of a new RFC (or a number of other ways), including clarifying how the requirement in Appendix D.5 that "ciphers with a strength less than 112 bits MUST NOT be offered or negotiated for any version of TLS for any reason" is to be interpreted, whether NULL encryption is compatible with an AEAD requirement, etc. On the other hand, I suspect that attempts to make the registration policy too strict would just lead to codepoint squatting, a phenomenon with which we have some real-world experience... -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
