On August 20, as Security Area Director (AD) received an appeal from Eric Rescorla, Richard Barnes and Martin Thomson regarding the TLS WG Chairs decision to "adopt and park draft-reddy-tls-slhdsa". Via the TLS WG Chairs I also received a complaint from Tim Hollebeek that considered the "adopt and park" outcome a "process violation". Executive Summary ----------------- While I believe the WG Chairs handled this case properly, the appeal is granted. For details, see below. The WG Chairs are instructed to mark the document as Not Adopted in the datatracker with a comment that links to this message in the TLS Archive. Received Appeal text -------------------- The following is an appeal under Section 6.5.1 of RFC 2026 of the TLS WG chairs’ judgment that there was consensus to adopt and "park" draft-reddy-tls-slhdsa. This draft has had two adoption calls, neither of which had rough consensus. The most favorable of these to adoption was 23-18 for, which reflects a heavily split WG, not rough consensus. In the framing of RFC 7282, this divide reflects the fact that the proponents have failed to address several objections. In the chair’s message declaring rough consensus to adopt they essentially acknowledge this [3], but argue that there is sufficient interest in favor to proceed despite there being significant opposition. However, sufficient interest is not the IETF standard under RFC 2026, which requires rough consensus. As there is not rough consensus, the chair’s decision should be reversed. Briefly, the history of this decision is as follows: 2025-06-16: The chairs issued an adoption call for this document [0] In response to that adoption call, there were 12 people in favor of adoption and 13 against. 2024-06-18: The chairs declared consensus to adopt the document [1] Eric Rescorla immediately contacted them to object and after a number of back and forth messages, the chairs finally agreed that there wasn’t consensus to adopt. They proposed to do a second adoption call with an applicability statement. 2024-07-14: The chairs started a second adoption call [2] This adoption call had approximately 22 or 23 people in favor, 18 against with 2 unclear. 2025-08-05: After the call concluded, Eric Rescorla contacted the chairs privately to point out that the responses did not reflect consensus. In response the chairs proposed to adopt the draft and "park" it. Eric Rescorla, Richard Barnes, and Martin Thomson all objected privately. 2025-08-19: The chairs announced that there was rough consensus to adopt the draft and that it was adopted [3]. [0] https://mailarchive.ietf.org/arch/msg/tls/o4KnXjI-OpuHPcB33e8e78rACb0/ [1] https://mailarchive.ietf.org/arch/msg/tls/hhLtBBctK5em6l82m7rgM6_hefo/ [2] https://mailarchive.ietf.org/arch/msg/tls/R8jw8Gh3_BGCpXwwFAyrs0YPfS4/ [3] https://mailarchive.ietf.org/arch/msg/tls/YQ3ju1KXzwrT1T2U4ny8YK-ZmU0/ AD evaluation of consensus -------------------------- I have followed RFC 7282's advise in determining the outcome of this appeal: https://datatracker.ietf.org/doc/html/rfc7282 Specifically, I took into account: While counting heads might give a good guess as to what the rough consensus will be, doing so can allow important minority views to get lost in the noise. One of the strengths of a consensus model is that minority views are addressed, and using a rough consensus model should not take away from that. That is why this document talks a great deal about looking at open issues rather than just counting the number of people who do or do not support any given issue. and Humming should be the start of a conversation, not the end AD evaluation of the numbers ---------------------------- I evaluated the numbers of both WG adoption calls. My numbers are basically the same as the numbers from the WG Chairs (and the numbers reported in the appeal text). On the 1st Adoption Call 14 Yes, 11 No voices and on the 2nd Adoption Call 23 Yes, 17 No. Both had 2 cases of Neither. 27 people responded to the first Adoption call, 42 to the second one. The detailed numbers (which are not the full story) can be found here: https://docs.google.com/spreadsheets/d/13l04Je4PhpOevzx3AFXI3c3leXkpXKf_GCaceH6Js2o/edit?gid=0#gid=0 Note that 2 Yes callers in the 1st round did not participate in the 2nd adoption call. Note 1 Yes caller changed to No and 0 No callers changed to Yes, and one No caller changed to neither yes/no. Based on numbers alone, the end results were far closer to an evenly split WG than to a rough consensus. AD evaluation of consensus by statements ---------------------------------------- Noteworthy is that the 2nd Adoption Call, which included the WG Chairs attempt to foster more consensus based on the 1st round of feedback by adding an applicability statement, did not really change the numbers nor did it change individuals opinions. Or in other words, the lack of a motivating use case and lack of general applicability remained a common reason for being against adoption. Below follows what I considered the main arguments made by participants and my interpretation of their importance and weight: It was said that the draft text did not really justify needing to become an RFC over just a code point, as the document was basically just a reference to [FIPS205]. I believe that observation is correct, and moreover, that the TLS WG specifically made efforts in the past to change their IANA registries to facilitate the case of registering an algorithm without requiring an RFC. The arguments in favour of an RFC seem to be aimed at secondary interpretations of what it is that an RFC gives you, such as recognition of the importance, indicating wide support of IETF, or vendor limitations of only implementing RFCs. These are however, not valid considerations in our decision making model. Furthermore, those in favour of adoption are concentrated in the Telco world (3GPP/GSMA) that inflicts these requirements onto IETF. This also makes another consensus attempt effort of trying this document as Experimental instead of Standards Track harder, because those who claim to require an RFC tend to also claim to require a Standards Track RFC. Lastly, an RFC would be needed to get a RECOMMENDED Y value but there is consensus that this is not currently desirable. It was stated that there is a need for an ML-DSA alternative in case this algorithm turns out to be broken. While true, since the applicability statement would say this is not for use for the generic TLS (HTTPS) case, this alternative would be severely limited in scope, and thus this argument is weak. It was noted that SLH-DSA is currently the only post-quantum signature algorithm that is explicitly permitted in its pure form (without requiring composites or hybridization) by all regulators that have issued PQC guidance. ML-DSA is also currently the only available TLS PQ Signature Algorithm, and it was raised that having a second algorithm would be needed in case ML-DSA was broken. While these are important arguments to take into account, the fact that SLH-DSA does not support the generic TLS (HTTPS) use case, significantly weakens that argument. A number of people agreed that options should be reduced, but it seems those individuals operating in the telco world prefers SHAKE and the non-telco world prefers SHA2. This affects those people who said "yes but with reduced options", as it is not clear which options to reduce. There was an argument that providing guidance is important, specifically because the algorithm is not suitable for generic TLS (HTTPS). But that could be interpreted as a band-aid for a solution that should not be adopted as a generic backup for ML-DSA to begin with. The guidance for why HashSLH-DSA is not included seems unnecessary as the code point allocations would simply just not define them. And the 2^64 signature limit guidance seems a bit far fetched as these limits are unlikely to be reached. I assume (but did not verify) that [FIPS205] would also be discussing this and would be part of the normative reference on the code point and would not need to be repeated into a draft or RFC. Even so, the draft text recommendations _could_ be used once it is linked to the code points without requiring an RFC, though it is somewhat controversial within the IETF to use drafts as stable references. People on both sides of the adoption call made claims about which of the outcomes would consume the least resources of the TLS WG. One side argued the document is small and does not have much content, so would not consume many resources. The other side argued there are too many options and discussion would take time. I think the "adopt and park" would have actually consumed the least amount of resources of the TLS WG, but regardless I find the importance of this argument fairly low. AD evaluation of WG Chairs process ---------------------------------- The was one complaint to the WG Chairs and one other voice on the list stating that WG Adoption should be "Yes or No" without further tweaks. How WG Chairs run and manage their WGs is specified in RFC 2418, RFC 7282 and RFC 2026. Guidance in these RFCs focus on building rough consensus, and I believe the WG Chairs did attempt to do so with their compromise of "adopt and park". Perhaps the phrasing could have been better to indicate there was no rough consensus based on the 2nd WG Adoption Call, but the proposed "adopt and park" could be considered an alternative outcome that did seem to carry rough consensus based on the responses. Note that the WG Chairs did consult me as AD on this matter as well, as I also did not note that the phrasing could have been improved. Regardless, the proposed "adopt and park" solution was appealed by three longstanding and respected members of the TLS community as well as one of the document authors, and with this alternative blocked as potential solution, the only other outcome left is to stick to the original YEs vs No consensus output of the 2nd WG Adoption Call that failed to reach consensus both based on numbers and content of the participants on the TLS WG list. Conclusion ---------- Based on the above, I believe the only course of action is to not adopt the document, and re-evaluate this at a future date once circumstances have changed. I do believe the authors should request code points from the Designated Experts, to gather further experience and to support deployment for those who have a non-generic use case that is not hindered by the lack of an RFC. A discussion on the TLS WG list to attempt to reduce the number of code points would be good, but since the document is not adopted, that is ultimately something the authors and the DEs will decide on. I want to thank everyone in the TLS WG, and especially the Chairs, for their time and efforts to attempt to reach a consensus. This discussion has also been notably polite and professional, for which I am grateful. This decision can be appealed as per RFC 2026 Section 6.5.1. Paul Wouters SEC AD _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
