From tomas at openssl.org Mon Oct 4 14:30:36 2021 From: tomas at openssl.org (Tomas Mraz) Date: Mon, 04 Oct 2021 16:30:36 +0200 Subject: Release stability proposal to be discussed at OTC Message-ID: <27a68d8d308fdca1b927f24fa04096788b5b8ca6.camel@openssl.org> I've prepared this release stability proposal addition to the existing release policy document: https://docs.google.com/document/d/1UFkXiwsmfK-xYpXQfv0HEUKmAbSxxcK25y5s3fAIIzQ/edit?usp=sharing This is just a starting point for further discussion, please feel free to add any comments to the document linked above. I'll also copy the proposed clauses to be added here for tl;dr: - Only bug fixes including fixes for security issues and documentation additions are allowed in stable releases. (The exception above for platform additions to LTS branches still applies.) - A stable release is a patch release from an existing supported minor release branch. - A bug fix is a fix of functionality of the libraries, modules, applications, or the build system that (all or any items might apply): makes the functionality conforming with the existing documentation makes the documentation conforming with the existing behavior of the software - A bug fix is also a fix for an unexpected behavior (not explicitly documented in one way or another) of the software when such unexpected behavior is a security vulnerability. - A bug fix might also be a fix for an unexpected behavior (not explicitly documented in one way or another) where there is no reasonable use-case that might depend on the unexpected behavior. - A documentation addition allowed in stable releases is any addition to the documentation that documents the existing behavior of the software. I.e., the documentation additions in stable releases cannot add new API contract constraints, or implicitly create new bugs in the software by documenting behavior that is different from the existing behavior of the software. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From tomas at openssl.org Tue Oct 5 07:48:33 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 05 Oct 2021 09:48:33 +0200 Subject: Monthly Status Report (September 2021) Message-ID: My key activities this month were: - triage of newly reported issues and responding to questions - participation on the meetings - studying the QUIC RFCs (8999-9002) - studying code (and documentation) of picoquic, ngtcp2, and LSQUIC libraries - infrastructure planning - release review of the 3.0.0 release - reviews of various PRs: ? - I've reviewed about 70 PRs this month ? - Notable PRs reviewed: - obj: make the OBJ_ calls thread safe #15713 - kdf: add PIN verification key KDF to providers #15968 - Fix OSSL_STORE 'file:' scheme implementation so it ignores objects in PEM files that the user isn't interested in #16466 - submitted 8 PRs: ? - In particular: ??? - Last minute NEWS and CHANGES entries for the 3.0 release #16533 - providers: Do not use global EVP_CIPHERs and EVP_MDs #16600 I had also 2 days off. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From matt at openssl.org Tue Oct 5 15:46:12 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 5 Oct 2021 16:46:12 +0100 Subject: Monthly Status Report (September) Message-ID: <7ac6d9db-9b81-e4ce-41e4-e33ca46e749a@openssl.org> As well as normal reviews, responding to user queries, wiki user requests, OMC business, support customer issues, CLA submissions, handling security reports, etc., key activities this month: - Significant amount of time spent on various OMC tasks this month - Prepared various website updates ready for the 3.0 release - Wrote the blog post for the 3.0 release - Liased with mbed tls team (issue #16486) - Clarified the documentation around SSL_set_num_tickets() and SSL_get_session() - Fixed bug to correctly handle extensions in a Certificate message sent by a client - Performed the 1.0.2zb release - Wrote a blog about the FIPS submission - Significant investigation and a draft fix (later superseded) into #16614 Matt From matt at openssl.org Tue Oct 12 12:23:23 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 12 Oct 2021 13:23:23 +0100 Subject: Agenda for the next OTC meeting Message-ID: My proposed agenda for the next OTC meeting (2021-10-19): 1) Nominate a minute taker and confirm agenda 2) Review policy process strawman 3) PR #16725 4) Agree agenda for next meeting 5) AOB Matt From beldmit at gmail.com Tue Oct 12 13:53:06 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 12 Oct 2021 15:53:06 +0200 Subject: Agenda for the next OTC meeting In-Reply-To: References: Message-ID: I'd like to add 2 more items to the agenda: 1. Do we want to restart the GH items review in this or that form? 2. Can we do anything with file load performance regression On Tue, Oct 12, 2021 at 2:23 PM Matt Caswell wrote: > My proposed agenda for the next OTC meeting (2021-10-19): > > 1) Nominate a minute taker and confirm agenda > 2) Review policy process strawman > 3) PR #16725 > 4) Agree agenda for next meeting > 5) AOB > > > Matt > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane.lontis at oracle.com Tue Oct 12 22:51:42 2021 From: shane.lontis at oracle.com (Shane Lontis) Date: Tue, 12 Oct 2021 22:51:42 +0000 Subject: [External] : Agenda for the next OTC meeting In-Reply-To: References: Message-ID: I would like to also discuss code coverage, and in particular adding tests for any new code that is added. ________________________________ From: openssl-project on behalf of Matt Caswell Sent: Tuesday, October 12, 2021 10:23 PM To: openssl-project at openssl.org Subject: [External] : Agenda for the next OTC meeting My proposed agenda for the next OTC meeting (2021-10-19): 1) Nominate a minute taker and confirm agenda 2) Review policy process strawman 3) PR #16725 4) Agree agenda for next meeting 5) AOB Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 13 10:15:00 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 13 Oct 2021 11:15:00 +0100 Subject: OMC Release Requirements Message-ID: FYI, the OMC have agreed the attached release requirements document. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: omc-release-requirements.md Type: text/markdown Size: 3153 bytes Desc: not available URL: From kurt at roeckx.be Wed Oct 13 16:19:06 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 13 Oct 2021 18:19:06 +0200 Subject: [External] : Agenda for the next OTC meeting In-Reply-To: References: Message-ID: > I would like to also discuss code coverage, and in particular adding tests for any new code that is added. It was always my understanding that our policy was that tests need to be added. We have a checkbox in the pull request to indicate that it's been done. But maybe it's not written down in a document that that is what is expected. Kurt From tomas at openssl.org Thu Oct 14 12:54:05 2021 From: tomas at openssl.org (Tomas Mraz) Date: Thu, 14 Oct 2021 14:54:05 +0200 Subject: OTPC#1 Policy change process proposal Message-ID: https://github.com/openssl/technical-policies/pull/1 Overview -------- This proposal provides the process on submitting, editing, finalizing, and approving the changes of the technical policies of the OpenSSL project (i.e., those policies governed by OTC). The reason ---------- The reason for the proposal is that OTC intends to formalize its work a little and to create multiple new technical policies for the project. The process should be open for external input and review. This proposal tries to achieve these goals. OTPC = OpenSSL Technical Policy Change -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From matt at openssl.org Tue Oct 19 10:07:26 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 Oct 2021 11:07:26 +0100 Subject: OTC VOTE: Accept PR#16725 Message-ID: topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the normal review process Proposed by Matt Caswell Public: yes opened: 2021-10-19 closed: 2021-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Dmitry [+0] Matt [+1] Pauli [ ] Tim [-1] Richard [+0] Shane [+1] Tomas [+1] Kurt [ ] Matthias [-1] Nicola [-1] From tomas at openssl.org Tue Oct 19 15:12:58 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 19 Oct 2021 17:12:58 +0200 Subject: OTPC#2 The Public Voting Procedure of OTC proposal Message-ID: https://github.com/openssl/technical-policies/pull/2 Overview -------- This proposal adds a new policy to replace the existing public voting procedure. The private voting procedure is kept as is. The reason ---------- The reason for the proposal is to modernize the procedure to avoid the requirement to use the e-mail for casting the votes and to avoid piling up the recorded votes in a single votes.txt file. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From kurt at roeckx.be Tue Oct 19 18:10:01 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 19 Oct 2021 20:10:01 +0200 Subject: OTC VOTE: Accept PR#16725 In-Reply-To: References: Message-ID: On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote: > topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the > normal review process So we have various people voting -1. Does someone want to explain why they vote -1? Kurt From nic.tuv at gmail.com Tue Oct 19 18:31:21 2021 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Tue, 19 Oct 2021 21:31:21 +0300 Subject: OTC VOTE: Accept PR#16725 In-Reply-To: References: Message-ID: I believe Matt will find the time at some point to post the minutes from today's meeting, but until then here is my recap. The discussion mostly focused on why the changes in #16725 are a bugfix and not a new feature, which would be a prerequisite to be admissible to be merged in the 3.0 branch. As I recall it, there were no objections to the final outcome of the PR to be desirable, the vote is entirely about this being a bugfix or not. It would be on those who voted +1 to properly argument why this is a bugfix and not a new feature, but the short version of that argument is that the outcome of #16725 was the "intended behavior" for 3.0.0. The counterargument is that we could not find written evidence (i.e., GH issues/PRs, documentation, and/or tests) that indeed the project ever committed to have this behavior in 3.0.0. The Strategic Architecture document has some text that could be somewhat related and used to support the "intend behavior" view, but the document clearly states > This document outlines the OpenSSL strategic architecture. It will take multiple releases, starting from 3.0.0, to move the architecture from the current "as-is" (1.1.1), to the future "to-be" architecture. Hence, it does not really prove that this functionality was always planned for the 3.0.0 release. Accepting this PR for the next minor release would not require a vote. I hope this recap is helpful to inform your decision. Cheers, Nicola On Tue, Oct 19, 2021 at 9:10 PM Kurt Roeckx wrote: > > On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote: > > topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the > > normal review process > > So we have various people voting -1. Does someone want to explain > why they vote -1? > > > Kurt > From kurt at roeckx.be Tue Oct 19 18:52:52 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 19 Oct 2021 20:52:52 +0200 Subject: OTC VOTE: Accept PR#16725 In-Reply-To: References: Message-ID: On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote: > topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the > normal review process +1 Kurt From matt at openssl.org Wed Oct 20 07:18:52 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Oct 2021 08:18:52 +0100 Subject: OTC VOTE: Accept PR#16725 In-Reply-To: References: Message-ID: <1ad724a1-faad-b475-1c64-db948023d1d5@openssl.org> On 19/10/2021 19:31, Nicola Tuveri wrote: > I believe Matt will find the time at some point to post the minutes > from today's meeting, but until then here is my recap. We decided in the meeting that posting the minutes to the list wasn't necessary and we would just push them to the repo: https://git.openssl.org/gitweb/?p=otc.git;a=blob;f=meeting-minutes/minutes-2021-10-19.txt;h=8bae2b86ecd7c4f967ba2aa822535dc0facbbfa9;hb=HEAD Matt > > The discussion mostly focused on why the changes in #16725 are a > bugfix and not a new feature, which would be a prerequisite to be > admissible to be merged in the 3.0 branch. > As I recall it, there were no objections to the final outcome of the > PR to be desirable, the vote is entirely about this being a bugfix or > not. > > It would be on those who voted +1 to properly argument why this is a > bugfix and not a new feature, but the short version of that argument > is that the outcome of #16725 was the "intended behavior" for 3.0.0. > The counterargument is that we could not find written evidence (i.e., > GH issues/PRs, documentation, and/or tests) that indeed the project > ever committed to have this behavior in 3.0.0. > > > The Strategic Architecture document has some text that could be > somewhat related and used to support the "intend behavior" view, but > the document clearly states > >> This document outlines the OpenSSL strategic architecture. It will take multiple releases, starting from 3.0.0, to move the architecture from the current "as-is" (1.1.1), to the future "to-be" architecture. > > Hence, it does not really prove that this functionality was always > planned for the 3.0.0 release. > > Accepting this PR for the next minor release would not require a vote. > > > > I hope this recap is helpful to inform your decision. > > > > Cheers, > > Nicola > > On Tue, Oct 19, 2021 at 9:10 PM Kurt Roeckx wrote: >> >> On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote: >>> topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the >>> normal review process >> >> So we have various people voting -1. Does someone want to explain >> why they vote -1? >> >> >> Kurt >> > From tjh at cryptsoft.com Wed Oct 20 08:34:10 2021 From: tjh at cryptsoft.com (Tim Hudson) Date: Wed, 20 Oct 2021 18:34:10 +1000 Subject: OTC VOTE: Accept PR#16725 In-Reply-To: <1ad724a1-faad-b475-1c64-db948023d1d5@openssl.org> References: <1ad724a1-faad-b475-1c64-db948023d1d5@openssl.org> Message-ID: On the basis of further discussion I'm changing my vote to 0 which enables this to pass now. Tim. On Wed, Oct 20, 2021 at 5:18 PM Matt Caswell wrote: > > > On 19/10/2021 19:31, Nicola Tuveri wrote: > > I believe Matt will find the time at some point to post the minutes > > from today's meeting, but until then here is my recap. > > We decided in the meeting that posting the minutes to the list wasn't > necessary and we would just push them to the repo: > > > https://git.openssl.org/gitweb/?p=otc.git;a=blob;f=meeting-minutes/minutes-2021-10-19.txt;h=8bae2b86ecd7c4f967ba2aa822535dc0facbbfa9;hb=HEAD > > Matt > > > > > The discussion mostly focused on why the changes in #16725 are a > > bugfix and not a new feature, which would be a prerequisite to be > > admissible to be merged in the 3.0 branch. > > As I recall it, there were no objections to the final outcome of the > > PR to be desirable, the vote is entirely about this being a bugfix or > > not. > > > > It would be on those who voted +1 to properly argument why this is a > > bugfix and not a new feature, but the short version of that argument > > is that the outcome of #16725 was the "intended behavior" for 3.0.0. > > The counterargument is that we could not find written evidence (i.e., > > GH issues/PRs, documentation, and/or tests) that indeed the project > > ever committed to have this behavior in 3.0.0. > > > > > > The Strategic Architecture document has some text that could be > > somewhat related and used to support the "intend behavior" view, but > > the document clearly states > > > >> This document outlines the OpenSSL strategic architecture. It will take > multiple releases, starting from 3.0.0, to move the architecture from the > current "as-is" (1.1.1), to the future "to-be" architecture. > > > > Hence, it does not really prove that this functionality was always > > planned for the 3.0.0 release. > > > > Accepting this PR for the next minor release would not require a vote. > > > > > > > > I hope this recap is helpful to inform your decision. > > > > > > > > Cheers, > > > > Nicola > > > > On Tue, Oct 19, 2021 at 9:10 PM Kurt Roeckx wrote: > >> > >> On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote: > >>> topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to > the > >>> normal review process > >> > >> So we have various people voting -1. Does someone want to explain > >> why they vote -1? > >> > >> > >> Kurt > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Wed Oct 20 08:43:35 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 20 Oct 2021 18:43:35 +1000 Subject: OTC VOTE: Accept PR#16725 In-Reply-To: References: Message-ID: <5435f313-c3ab-9d6b-fd4e-7ae465e4ce76@openssl.org> 0 Pauli On 19/10/21 8:07 pm, Matt Caswell wrote: > topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to > the normal review process > Proposed by Matt Caswell > Public: yes > opened: 2021-10-19 > closed: 2021-mm-dd > accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) > > ? Dmitry???? [+0] > ? Matt?????? [+1] > ? Pauli????? [? ] > ? Tim??????? [-1] > ? Richard??? [+0] > ? Shane????? [+1] > ? Tomas????? [+1] > ? Kurt?????? [? ] > ? Matthias?? [-1] > ? Nicola???? [-1] > From matt at openssl.org Wed Oct 20 10:10:17 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Oct 2021 11:10:17 +0100 Subject: OTC VOTE: Accept PR#16725 In-Reply-To: <5435f313-c3ab-9d6b-fd4e-7ae465e4ce76@openssl.org> References: <5435f313-c3ab-9d6b-fd4e-7ae465e4ce76@openssl.org> Message-ID: I have now closed this vote: topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the normal review process Proposed by Matt Caswell Public: yes opened: 2021-10-19 closed: 2021-10-20 accepted: yes (for: 4, against: 2, abstained: 4, not voted: 0) Dmitry [+0] Matt [+1] Pauli [ 0] Tim [ 0] # Vote changed 2021-10-20 Richard [+0] Shane [+1] Tomas [+1] Kurt [+1] Matthias [-1] Nicola [-1] On 20/10/2021 09:43, Dr Paul Dale wrote: > 0 > > Pauli > > On 19/10/21 8:07 pm, Matt Caswell wrote: >> topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to >> the normal review process >> Proposed by Matt Caswell >> Public: yes >> opened: 2021-10-19 >> closed: 2021-mm-dd >> accepted:? yes/no? (for: X, against: Y, abstained: Z, not voted: T) >> >> ? Dmitry???? [+0] >> ? Matt?????? [+1] >> ? Pauli????? [? ] >> ? Tim??????? [-1] >> ? Richard??? [+0] >> ? Shane????? [+1] >> ? Tomas????? [+1] >> ? Kurt?????? [? ] >> ? Matthias?? [-1] >> ? Nicola???? [-1] >> > From pauli at openssl.org Wed Oct 27 08:47:13 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 27 Oct 2021 18:47:13 +1000 Subject: OMC vote: changing the web site landing page Message-ID: <0660618c-8043-736c-d32f-bbce03e33dab@openssl.org> topic: Replace the first two sentences of the current openssl.org front page ?????? with the new first paragraph of the OpenSSL Project Overview. The ?????? following sentence on the current website becomes a new paragraph. comment: The new text being: `The OpenSSL Project develops and maintains the ???????? OpenSSL software - a robust, commercial-grade, full-featured toolkit ???????? for general-purpose cryptography and secure communication. The ???????? project's technical decision making is managed by the OpenSSL ???????? Technical Committee (OTC) and the project governance is managed ???????? by the OpenSSL Management Committee (OMC). The project operates ???????? under formal Bylaws.' The vote passed with 6 for, none against, abstaining or not voting. From rsalz at akamai.com Fri Oct 29 15:13:35 2021 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 29 Oct 2021 15:13:35 +0000 Subject: Please change your mind about your announced release plans Message-ID: <871D08A7-60B8-4423-A21A-056D4B58E426@akamai.com> I think the current plan, to do QUIC over a series of releases, is a mistake it seems seriously likely to make OpenSSL less relevant. Some reasons follow. According to https://www.openssl.org/blog/blog/2019/11/07/3.0-update/, the initial target for 3.0 was end of 2019, but the announced release date was moved once to early Q2 2020, then early Q4 2020. It was ultimately released early Q4 2021. That?s a slip of nearly two years. Sure, I know COVID affected many things, but the impact on OpenSSL, whose fellows all worked from home offices, should have been slight. Regardless, the focus of this release was on *cryptography* something which is highly familiar to the team. With this release, as detailed in https://www.mail-archive.com/openssl-project at openssl.org/msg02585.html, it appears that OpenSSL is trying to do two things. Have a more rapid release cadence -- the stated objective is six months -- and implement QUIC over a series of releases. To keep a six-month cycle probably means five months of planning and development. During the 3.0 work, the project hired, and then fired, a project manager to keep things on track. Are you going to hire another? The project has a very bad history of meeting time-bounded deadlines. This is not surprising; software engineers tend to chronically under-estimate the amount of time needed. In addition, an LTS release will be either 3.1 if available by next September, or the current 3.0. Neither alternative is good. The section on QUIC discusses the MVP for that release. Making an LTS release that is based on a radical restructuring of the record layer, not to mention having a half-baked and useless QUIC release, does not meet the community's needs. It is also exceedingly unlikely to be ready within a year, which means 3.0 will be the next LTS release. This means that many issues found by the community while adopting 3.0 will go unaddressed in LTS, as each will have to pass the "is this a bug-fix" barrier or be approved as an exception. Exceptions are *wrong* for an LTS release. The next LTS release should be just cleanup, fixes, and usability enhancements found during 3.0 deployments. The level of technical detail in the release requirements are curious. They go into great detail and greatly constrain the OTC. This was not done for FIPS, where the design was led by the OTC and had involvement from the project sponsors. I know that some OTC members are not pleased with this level of detail, and I don't blame them. It might be useful for the OMC to release a rationale. Why is it necessary to "implement QUIC" when instead the directive could have been "support QUIC"? If the API from https://github.com/openssl/openssl/pull/8797 is so distasteful (yes, enum's in function parameters are not OpenSSL style), it would have been better if the project convened leading TLS and QUIC implementors to come up with a new one. That would have shown true leadership, and I know some of those affected by these plans would have supported that. QUIC is a subtle protocol. Its evolution within the IETF took several years, and the development staff at major implementations includes full-time developers, QA engineers, and documentation writers. Currently OpenSSL has five full-time fellows, and none of them have any recognized experience in implementing transport protocols. Look at the complexity in the BIO code around DNS and handling IPv4/IPv6 address families portably. While the project currently has DTLS, which is a UDP protocol, QUIC is more like the former than the latter. The MVP does not rise to the level of minimally viable: A single-stream client that can be added to the s_client application without significant API changes. There is no mention of server implementation -- will there be one? It's not even mentioned as a stretch goal for the first release. Is that bifurcation of the community intentional? If it's an oversight, it can be seen as yet another indication that the QUIC plan is not well thought out. There are numerous freely available QUIC implementations. For example, look at https://interop.seemann.io/ which shows 14. It is easy to get an implementation added to that, and yet OpenSSL is only promising to interop against one implementation. Why aren't Google, bundled with Chrome and Android, or Microsoft, bundled with Windows, or Apple, bundled into iOS 15, tested? Perhaps the reason is that only client-side is part of the first release. Again, the Internet doesn't need yet another limited client-side-only QUIC implementation, and the plan as currently stated will force anyone deploying a server to go elsewhere. Even if you add single-stream server support to the MVP, that will not be sufficient for any server that wants to support modern browsers. The additional API in PR8797 is under 2000 lines. It supports, at least, Microsoft MSQUIC, Google QUIC, the QUIC implementation in Node.js, and ngtcp2 by Tatsuhiro Tsujikawa. The API devised by David Benjamin and ported by Todd in the PR, is clearly something the QUIC community wants. In addition, Apache Traffic Server implements QUIC and recommends QuicTLS, not OpenSSL. Nginx supports using the QuicTLS fork during their development. A complete QUIC implementation by OpenSSL will take several years and certainly be many times that. An OpenSSL implementation is not something the QUIC community wants. The leaders of the MSQUIC, gQUIC, Curl, and Node projects have all spoken out against OpenSSL implementing QUIC. Many people in the community commented in PR 8797 against the OpenSSL plan, including Lars Eggert, IETF Chair and former QUIC WG Chair, Martin Duke, IETF Transport Area Director, and Lucas Pardue, co-chair of the QUIC WG. It is important to realize that QUIC is not "done." While the initial documents are RFCs, looking at https://datatracker.ietf.org/wg/quic/documents/, shows that there are nearly a dozen drafts in preparation. Certainly not all of them will advance to RFC, but many will. Also, other IETF WG's are using QUIC, include ALPS in the TLS WG, and the multiplexed transport on top of QUIC known as MASQUE WG. There will be *significant* progress on QUIC during the time OpenSSL is distracted by playing catch-up. As little work can be done by anyone on new features until a full-featured implementation is available, OpenSSL will forever lag behind. By focusing on QUIC, the project is also not serving its existing community. The OMC plan has already tossed aside DTLS 1.3, no matter when it is finished. What other worthwhile, standardized, work will be given short shrift? The plan makes no mention of existing PR's, or possible new ones. Now speaking for myself, I am concerned that the the implementation of the stated plan will not be good. The performance impact of the 3.0 provider interface have not been fully quantified, but experience shows the overhead is significant. For example, Microsoft recommends avoiding the 3.0 version of QuicTLS for performance reasons. I also suggest a careful reading of IETF RFC 9001. While it is possible to do a "pluggable" record implementation, that RFC and wide implementation experience, shows that it is not necessary. This is not like a new crypto algorithm or provider; a pluggable record layer to accommodate TLS, DTLS, KTLS, and QUIC, seems like a fool's errand, perhaps brought on by the hubris of thinking that the world needs OpenSSL to implement QUIC. It doesn't. It needs OpenSSL to implement OpenSSL cryptography. Thank you for having read this far. I apologize if my strong language offended anyone, that was not my intent. I only wish to convey, as strongly as possible through the medium of email, that the path the project is on is bad and will force people to leave. To repeat something I've seen posted before, "No matter how far down the wrong road you've gone, turn back." Most sincerely, -rich $alz From pauli at openssl.org Sun Oct 31 22:50:08 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Mon, 1 Nov 2021 08:50:08 +1000 Subject: Monthly Status: October Message-ID: Apart from three weeks of vaction, significant activities throughout October were: * Wrote up developer job desription * Investigated GHE due dates for issues * Fixed the test RNG, updated the documentation and added a unit test * Read through the proposed policy documents * Began an implementation of safe integer mathematical operations In addition were minor pull requests, reviewing, OMC and OTC business, et al. Pauli -------------- next part -------------- An HTML attachment was scrubbed... URL: